Re: [Xen-devel] [PATCH V2 2/3] xen/vm_event: Support for guest-requested events

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 06/30/2015 05:48 PM, Lengyel, Tamas wrote:
>>> --- a/xen/include/asm-x86/domain.h
> 
>     >> +++ b/xen/include/asm-x86/domain.h
>     >> @@ -342,13 +342,15 @@ struct arch_domain
>     >>
>     >>      /* Monitor options */
>     >>      struct {
>     >> -        uint16_t write_ctrlreg_enabled       : 4;
>     >> -        uint16_t write_ctrlreg_sync          : 4;
>     >> -        uint16_t write_ctrlreg_onchangeonly  : 4;
>     >> -        uint16_t mov_to_msr_enabled          : 1;
>     >> -        uint16_t mov_to_msr_extended         : 1;
>     >> -        uint16_t singlestep_enabled          : 1;
>     >> -        uint16_t software_breakpoint_enabled : 1;
>     >> +        uint32_t write_ctrlreg_enabled       : 4;
>     >> +        uint32_t write_ctrlreg_sync          : 4;
>     >> +        uint32_t write_ctrlreg_onchangeonly  : 4;
>     >> +        uint32_t mov_to_msr_enabled          : 1;
>     >> +        uint32_t mov_to_msr_extended         : 1;
>     >> +        uint32_t singlestep_enabled          : 1;
>     >> +        uint32_t software_breakpoint_enabled : 1;
>     >> +        uint32_t request_enabled             : 1;
>     >> +        uint32_t request_sync                : 1;
>     >
>     > Can you please switch to plain unsigned int if you already have to
>     > touch this? There's no reason I can see to use a fixed width integer
>     > type here.
> 
>     Ack, will make it plain int.
> 
> 
> IMHO having it fix-width is easier to read when adding new elements to
> see how many bits we have left free. I would not want this changed
> unless there is a clear benefit to doing so.

There's also another case to be made for your view, and that is that
where bitfields are concerned the current Xen style uses fixed width
types. This can be seen by, e.g. "grep -R ": 1" *" in xen/include.

I'll leave it as uint32_t for now, and hopefully Jan will let us know
more when he returns from his vacation.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel