[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [PATCH v3 4/5] common/domain: add a domain context record for shared_info...
> -----Original Message----- > From: Jan Beulich <jbeulich@xxxxxxxx> > Sent: 19 May 2020 16:34 > To: paul@xxxxxxx > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; 'Paul Durrant' <pdurrant@xxxxxxxxxx>; > 'Ian Jackson' > <ian.jackson@xxxxxxxxxxxxx>; 'Wei Liu' <wl@xxxxxxx>; 'Andrew Cooper' > <andrew.cooper3@xxxxxxxxxx>; > 'George Dunlap' <george.dunlap@xxxxxxxxxx>; 'Julien Grall' <julien@xxxxxxx>; > 'Stefano Stabellini' > <sstabellini@xxxxxxxxxx> > Subject: Re: [PATCH v3 4/5] common/domain: add a domain context record for > shared_info... > > On 19.05.2020 17:21, Paul Durrant wrote: > >> From: Jan Beulich <jbeulich@xxxxxxxx> > >> Sent: 19 May 2020 15:08 > >> > >> On 14.05.2020 12:44, Paul Durrant wrote: > >>> --- a/xen/include/public/save.h > >>> +++ b/xen/include/public/save.h > >>> @@ -73,7 +73,16 @@ struct domain_save_header { > >>> }; > >>> DECLARE_DOMAIN_SAVE_TYPE(HEADER, 1, struct domain_save_header); > >>> > >>> -#define DOMAIN_SAVE_CODE_MAX 1 > >>> +struct domain_shared_info_context { > >>> + uint8_t has_32bit_shinfo; > >>> + uint8_t pad[3]; > >> > >> 32-(or 16-)bit flags, with just a single bit used for the purpose? > >> > > > > I debated that. Given this is xen/tools-only would a bit-field be > > acceptable? > > Looking at domctl.h and sysctl.h, the only instance I can find is a > live-patching struct, and I'd suppose the addition of bitfields there > was missed in the hasty review back then. While it might be > acceptable, I'd recommend against it. It'll bite us the latest with > a port to an arch where endianness is not fixed, and hence may vary > between hypercall caller and callee. The standard way of using > #define-s looks more future proof. > Ok, I'll go with a flag. Probably is better in the long run. Paul > Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |