| Message ID | 20220107125542.212725-1-dvrabel@amazon.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/hvm: reserve another HVM context save record ID for Amazon | expand |
On 07.01.2022 13:55, David Vrabel wrote: > Amazon's guest transparent live migration work needs another save > record (for event channel upcall vectors). Reserve another HVM context > save record ID for this. I have to admit that I have reservations: I didn't really like seeing the original range getting reserved. Even less so I'd like to see extensions / further such reservations. The more that iirc the original reservation was accepted based on a (perhaps vague) promise of the respective uses actually getting upstreamed. Yet that hasn't happened (nor even started to happen) in slightly over 2 years time, iirc. What I could see as a compromise is to have, say, vendor ranges higher up in number space. Jan > Signed-off-by: David Vrabel <dvrabel@amazon.co.uk> > --- > I've added it to the end, keeping the unused ID at 21. > --- > xen/include/public/arch-x86/hvm/save.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h > index 773a380bc2..2de3dfd9bb 100644 > --- a/xen/include/public/arch-x86/hvm/save.h > +++ b/xen/include/public/arch-x86/hvm/save.h > @@ -641,7 +641,7 @@ struct hvm_msr { > > #define CPU_MSR_CODE 20 > > -/* Range 22 - 34 (inclusive) reserved for Amazon */ > +/* Range 22 - 35 (inclusive) reserved for Amazon */ > > /* > * Largest type-code in use
On 14/01/2022 07:08, Jan Beulich wrote: > On 07.01.2022 13:55, David Vrabel wrote: >> Amazon's guest transparent live migration work needs another save >> record (for event channel upcall vectors). Reserve another HVM context >> save record ID for this. > > I have to admit that I have reservations: I didn't really like seeing > the original range getting reserved. Even less so I'd like to see > extensions / further such reservations. The more that iirc the > original reservation was accepted based on a (perhaps vague) promise > of the respective uses actually getting upstreamed. Yet that hasn't > happened (nor even started to happen) in slightly over 2 years time, > iirc. I think this is fair. I hadn't realized we'd sat on this work for so long. > What I could see as a compromise is to have, say, vendor ranges > higher up in number space. I (personally) would accept removing the reservation entirely -- we didn't follow the upstreaming process, so we take the cost of fixing up any compatibility issues. David
diff --git a/xen/include/public/arch-x86/hvm/save.h b/xen/include/public/arch-x86/hvm/save.h index 773a380bc2..2de3dfd9bb 100644 --- a/xen/include/public/arch-x86/hvm/save.h +++ b/xen/include/public/arch-x86/hvm/save.h @@ -641,7 +641,7 @@ struct hvm_msr { #define CPU_MSR_CODE 20 -/* Range 22 - 34 (inclusive) reserved for Amazon */ +/* Range 22 - 35 (inclusive) reserved for Amazon */ /* * Largest type-code in use
Amazon's guest transparent live migration work needs another save record (for event channel upcall vectors). Reserve another HVM context save record ID for this. Signed-off-by: David Vrabel <dvrabel@amazon.co.uk> --- I've added it to the end, keeping the unused ID at 21. --- xen/include/public/arch-x86/hvm/save.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)