[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |