From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 07/32] xen/x86: fix arch_set_info_guest for HVM guests Date: Fri, 24 Jul 2015 12:28:52 +0100 Message-ID: <1437737332.24746.73.camel@citrix.com> References: <1435923310-9019-1-git-send-email-roger.pau@citrix.com> <1435923310-9019-8-git-send-email-roger.pau@citrix.com> <55A3E0F102000078000903B5@mail.emea.novell.com> <55B0C100.6000308@citrix.com> <55B0EC520200007800094842@prv-mh.provo.novell.com> <1437651718.19412.92.camel@citrix.com> <55B103DD.4030901@citrix.com> <55B125440200007800094BD2@prv-mh.provo.novell.com> <55B10CDB.5010708@citrix.com> <1437667259.24746.12.camel@citrix.com> <55B11316.2000201@citrix.com> <55B130420200007800094CB8@prv-mh.provo.novell.com> <55B11CBE.8050704@citrix.com> <55B1208C.9090207@citrix.com> <55B211D70200007800094FCF@prv-mh.provo.novell.com> <55B20C9D.5070708@citrix.com> <55B21D47.4010109@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIb9w-0004V0-7V for xen-devel@lists.xenproject.org; Fri, 24 Jul 2015 11:29:00 +0000 In-Reply-To: <55B21D47.4010109@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Roger Pau =?ISO-8859-1?Q?Monn=E9?= , Jan Beulich Cc: xen-devel@lists.xenproject.org, Boris Ostrovsky , David Vrabel List-Id: xen-devel@lists.xenproject.org On Fri, 2015-07-24 at 12:11 +0100, Andrew Cooper wrote: > > To avoid making the 32bit (and optionally 16bit) massive as a side > effect of 64bit, can I suggest > > uint32_t flags; > union { > cpu_hvm32_regs; > cpu_hvm64_regs; > }; > > Which allows hvm32_regs to be a far smaller structure. Given that you can't really know apriori which mode an HVM vcpu is in and that having to pick the right half of the union everywhere is faff for everyone on both sides of the API I'd suggest going with a single struct as far as possible Perhaps with a union to allow the use of 32- and 64-bit _names_ for things which are the same underlying register in different widths (rip/pc, eax/rax etc), but that would be it. Ian.