[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] x86/save: reserve HVM save record numbers that have been consumed...



> -----Original Message-----
> From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Sent: 19 December 2019 10:52
> To: Durrant, Paul <pdurrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Wei Liu <wl@xxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; Roger Pau Monné
> <roger.pau@xxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH] x86/save: reserve HVM save record numbers
> that have been consumed...
> 
> On 19/12/2019 08:52, Durrant, Paul wrote:
> >> -----Original Message-----
> >> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of
> >> Andrew Cooper
> >> Sent: 18 December 2019 19:45
> >> To: Durrant, Paul <pdurrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> >> Cc: Wei Liu <wl@xxxxxxx>; Jan Beulich <jbeulich@xxxxxxxx>; Roger Pau
> Monné
> >> <roger.pau@xxxxxxxxxx>
> >> Subject: Re: [Xen-devel] [PATCH] x86/save: reserve HVM save record
> numbers
> >> that have been consumed...
> >>
> >> On 18/12/2019 16:09, Paul Durrant wrote:
> >>> ...for patches not (yet) upstream.
> >>>
> >>> This patch is simply reserving save record number space to avoid the
> >>> risk of clashes between existent downstream changes made by Amazon and
> >>> future upstream changes which may be incompatible.
> >>>
> >>> Signed-off-by: Paul Durrant <pdurrant@xxxxxxxxxx>
> >> Is this "you've already used some of these", or you plan to?
> > Already used in code that has been deployed, although I have left some
> headroom because I know there is code in development which is using new
> ones.
> >
> > Where records can be upstreamed in a way that is compatible with
> downstream use, we will keep the existing number. If incompatible changes
> are necessary to get the code upstream then we will have to use a new
> number and maintain downstream compatibility patches.
> 
> Every bump to this number is more wasted memory in Xen.
> 

How much more memory?

> It is not fair or reasonable to include extra headroom in a "oh dear we
> screwed up - will the community be kind enough to help us work around
> our ABI problems" scenario.
> 

I would have thought all the pain you went through to keep XenServer going with 
its non-upstreamed hypercall numbers would have made you a little more 
sympathetic to dealing with past mistakes.

> For now, I'd just leave it as a comment, and strictly only covering the
> ones you have used.  There is no need to actually bump the structure
> sizes in xen for now - simply that the ones you have currently used
> don't get allocated for something different in the future.
>

Ok, we can defer actually bumping HVM_SAVE_CODE_MAX, but it's almost certain to 
happen eventually.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.