From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH v3 07/32] xen/x86: fix arch_set_info_guest for HVM guests Date: Fri, 24 Jul 2015 05:49:29 -0600 Message-ID: <55B2426902000078000951B9@prv-mh.provo.novell.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> <1437737332.24746.73.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbTp-0000Ad-Dj for xen-devel@lists.xenproject.org; Fri, 24 Jul 2015 11:49:33 +0000 In-Reply-To: <1437737332.24746.73.camel@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: Andrew Cooper , David Vrabel , xen-devel@lists.xenproject.org, Boris Ostrovsky , roger.pau@citrix.com List-Id: xen-devel@lists.xenproject.org >>> On 24.07.15 at 13:28, wrote: > 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. While I had considered that too (not the least based on what you've said ARM has), it has its own downsides (the hypervisor needing to verify that everything that can't be represented is zero), which is why I wasn't certain whether to suggest that. Jan