> -----Original Message-----
> From: Jan Beulich <jbeul...@suse.com>
> Sent: 19 May 2020 16:34
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' <pdurr...@amazon.com>;
> 'Ian Jackson'
> <ian.jack...@eu.citrix.com>; 'Wei Liu' <w...@xen.org>; 'Andrew Cooper'
> <andrew.coop...@citrix.com>;
> 'George Dunlap' <george.dun...@citrix.com>; 'Julien Grall' <jul...@xen.org>;
> 'Stefano Stabellini'
> <sstabell...@kernel.org>
> 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 <jbeul...@suse.com>
> >> 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
