[PATCH] x86/hvm: reserve another HVM context save record ID for Amazon

[PATCH] x86/hvm: reserve another HVM context save record ID for Amazon

[David Vrabel]

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(-)

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
-- 
2.30.2

Re: [PATCH] x86/hvm: reserve another HVM context save record ID for Amazon

[Jan Beulich]

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

Re: [PATCH] x86/hvm: reserve another HVM context save record ID for Amazon

[David Vrabel]

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