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 06:44:26 -0600 Message-ID: <55B24F4A02000078000952CC@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> <55B233890200007800095124@prv-mh.provo.novell.com> <55B22B5A.8020304@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIcL0-0000ex-KF for xen-devel@lists.xenproject.org; Fri, 24 Jul 2015 12:44:30 +0000 In-Reply-To: <55B22B5A.8020304@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: =?UTF-8?Q?Roger=20Pau=20Monn=C3=A9?= Cc: Ian Campbell , Andrew Cooper , David Vrabel , xen-devel@lists.xenproject.org, Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org >>> On 24.07.15 at 14:11, wrote: > El 24/07/15 a les 12.46, Jan Beulich ha escrit: >>>>> On 24.07.15 at 11:59, wrote: >>> __DECL_GP_REG(flags); >> >> r8-r11, selector and descriptor registers, pseudo descriptor registers. >> Or else for all of them their default state would need to be spelled out. > > r8-r15 right? Oh - of course. >>> /* Control registers. */ >>> uint64_t cr[8]; >>> /* Valid on amd64 only. */ >> >> Fields valid/useful in one mode only should probably be put in >> union-ized sub-structures. > > Do you mean something like: > > union { > uint64_t efer; > uint32_t __invalid32; > uint16_t __invalid16; > } > > It seems kind of pointless IMHO, the reason to have the union is to be > able to access the registers using the native nomenclature, but if a > register doesn't exist in a specific bitness I don't see the point of > adding such "invalid" names. No - put side by side an item valid in only a subset modes and an item only valid outside of that subset. > Or your idea was to put all the bitness specific registers inside of > another separate structure and then unionize them? AFAICT the 16 and > 32bit structures are going to be empty. How that? 64-bit mode e.g. doesn't need full descriptor data for many of the segment registers. Jan