From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH v6 24/29] xen/x86: allow HVM guests to use hypercalls to bring up vCPUs Date: Tue, 29 Sep 2015 11:25:24 +0100 Message-ID: <560A6714.7060303@citrix.com> References: <1441368548-43465-1-git-send-email-roger.pau@citrix.com> <1441368548-43465-25-git-send-email-roger.pau@citrix.com> <5600420C02000078000A4234@prv-mh.provo.novell.com> <5609664D.8060604@citrix.com> <560A555402000078000A6625@prv-mh.provo.novell.com> <560A6124.2090404@citrix.com> <560A7EFA02000078000A6846@prv-mh.provo.novell.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 1Zgs6r-0007rf-02 for xen-devel@lists.xenproject.org; Tue, 29 Sep 2015 10:26:09 +0000 In-Reply-To: <560A7EFA02000078000A6846@prv-mh.provo.novell.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: Jan Beulich , roger.pau@citrix.com Cc: George Dunlap , xen-devel@lists.xenproject.org, Stefano Stabellini , Ian Campbell , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 29/09/15 11:07, Jan Beulich wrote: >>>> On 29.09.15 at 12:00, wrote: >> On 29/09/15 08:09, Jan Beulich wrote: >>>>>> + uint32_t cs_base; >>>>>> + uint32_t ds_base; >>>>>> + uint32_t ss_base; >>>>> I continue to question why we have DS here, but not ES (and maybe >>>>> FS and GS too). I.e. either just CS and SS (which are architecturally >>>>> required) or at least all four traditional x86 segment registers. And >>>>> you're also clearly not targeting minimal state, or else there likely >>>>> wouldn't be a need for e.g. R8-R15 in the 64-bit variant. >>>> I'm fine with removing r8-15. Regarding the segment selectors, I don't >>>> have a problem with only allowing CS and SS to be set, or all of them >>>> including FS and GS. But I would like to get a consensus on this, we >>>> have already gone back and forth several times regarding how this >>>> structure should look like, and TBH, I was hoping that this was the last >>>> time. >>> Was there back and forth? I only recall always having asked for >>> consistency here, just like spelled out above. >>> >>>> Andrew, Jan, what would you prefer, either DS is removed or ES, FS and >>>> GS are also added? >>> I voiced my opinion. Andrew? >> DS clearly needs initialising to provide a sane environment in the newly >> running vcpu. Expecting %cs or %ss overrides until a new GDT is loaded >> is unreasonable IMO. > I don't view this as unreasonable: You want to load a GDT first thing > anyway. True. The main question is whether the GDT will be at a fixed linear address. I expect this to be the case in any non-contrived situation. > And I see nothing wrong with that one instruction carrying > an override (and even then only on 32-bit, as a nul DS is fine on > 64-bit). Ah yes. > >> Therefore, we are back to the question of whether to provide all segment >> registers, or specify a flat layout without specific selector values. I >> would prefer the former to the latter. > If we don't go the CS+SS only route, then yes, I'd too prefer > completing the set (I would probably agree with not adding FS > and GS, and even recommend against it in the 64-bit variant, > but I do insist on ES in that case). I would still err on the CS/SS/DS/ES side given a straight choice. It offers more flexibility for rarer usecases. ~Andrew