> -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: 19 May 2020 16:34 > To: [email protected] > Cc: [email protected]; 'Paul Durrant' <[email protected]>; > 'Ian Jackson' > <[email protected]>; 'Wei Liu' <[email protected]>; 'Andrew Cooper' > <[email protected]>; > 'George Dunlap' <[email protected]>; 'Julien Grall' <[email protected]>; > 'Stefano Stabellini' > <[email protected]> > 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 <[email protected]> > >> 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
