|
[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 |