From mboxrd@z Thu Jan  1 00:00:00 1970
From: Razvan Cojocaru <rcojocaru@bitdefender.com>
Subject: Re: [PATCH V2 2/3] xen/vm_event: Support for
 guest-requested events
Date: Tue, 30 Jun 2015 18:22:29 +0300
Message-ID: <5592B435.1040107@bitdefender.com>
References: <1434359007-9302-1-git-send-email-rcojocaru@bitdefender.com>
	<1434359007-9302-3-git-send-email-rcojocaru@bitdefender.com>
	<558D152B0200007800089FD4@mail.emea.novell.com>
	<558CFC75.9000905@bitdefender.com>
	<CAD33N+4-agvUhakTyoc=o_fRg2bZ_UpzJxoHU2CZg1jfVMPx2A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CAD33N+4-agvUhakTyoc=o_fRg2bZ_UpzJxoHU2CZg1jfVMPx2A@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Lengyel, Tamas" <tlengyel@novetta.com>
Cc: kevin.tian@intel.com, Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Jun Nakajima <jun.nakajima@intel.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Tim Deegan <tim@xen.org>, Daniel De Graaf <dgdegra@tycho.nsa.gov>, Xen-devel <xen-devel@lists.xen.org>, eddie.dong@intel.com, Aravind.Gopalakrishnan@amd.com, Jan Beulich <JBeulich@suse.com>, suravee.suthikulpanit@amd.com, boris.ostrovsky@oracle.com, keir@xen.org, Ian Jackson <ian.jackson@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

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.

I don't really have a preference one way or the other about this based
on readability, so I'm fine with going either way.

However, while in practice this modification is safe, AFAIK the C
standard does not guarantee that an (unsigned) int is at least 32-bits
wide, so it might raise the question of what might happen if somebody
builds the hypervisor with a 16-bit int compiler (though I would imagine
there would be some compile-time warning / error in that case). Do we
care about that?


Thanks,
Razvan