From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [V10 PATCH 09/23] PVH xen: introduce pvh_set_vcpu_info() and vmx_pvh_set_vcpu_info() Date: Mon, 12 Aug 2013 12:04:25 +0100 Message-ID: <5208DD5902000078000EB24F@nat28.tlf.novell.com> References: <1374631171-15224-1-git-send-email-mukesh.rathor@oracle.com> <1374631171-15224-10-git-send-email-mukesh.rathor@oracle.com> <51FFA43702000078000E936E@nat28.tlf.novell.com> <20130807180549.46941f85@mantra.us.oracle.com> <52035D4902000078000EA1C6@nat28.tlf.novell.com> <20130809164138.38aa9b06@mantra.us.oracle.com> <5208B0DA02000078000EB069@nat28.tlf.novell.com> <20130812102412.GA24410@ocelot.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1V8pvK-000492-SX for xen-devel@lists.xenproject.org; Mon, 12 Aug 2013 11:04:31 +0000 In-Reply-To: <20130812102412.GA24410@ocelot.phlegethon.org> 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: Tim Deegan Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 12.08.13 at 12:24, Tim Deegan wrote: > At 08:54 +0100 on 12 Aug (1376297674), Jan Beulich wrote: >> >>> On 10.08.13 at 01:41, Mukesh Rathor wrote: >> > Since we are loading gdtr and selectors cs/ds/ss, we should also load >> > the hidden fields for cs/ds/ss. That IMO is plenty enough support for >> > the vcpu to come up, and the vcpu itself can then load ldtr, fs base, gs >> > base, etc first thing in it's HVM container. What do you all think? >> >> If you implement loading the hidden fields of CS, then doing the >> same for the LDT shouldn't be that much more code (and if you >> permit a non-null LDT selector, then having it in place would even >> be a requirement before validating the CS selector). But again, >> I had already indicated that I'd be fine with requiring the state to >> be truly minimal: CS -> flat 64-bit code descriptor, SS, DS, ES, FS >> and GS holding null selectors. And CS descriptor validation done >> only in debug mode. > > If you're going that way, please go the whole hog: > - _all_ of cs/ss/ds/es/fs/gs arguments required to be null > (and so documented, and enforced). > - GDT base/limit loaded from the args. > - LDT base/limit args required (documented, enforced) to be zero. > - Guest launches with a flat 32/64bit segments set up in the > hidden part of all segments (or I guess on 32-bit you could have all > but CS invalid). Then it can load its real segment state after boot. > > That way we don't have the weird constraints on the layout/contents > of the guest's GDT or on its segment descriptors. > > Would that be OK? I don't think CS = null is valid. And similarly, for future 32-bit PVH SS = null wouldn't be valid, and DS = null as well as ES = null would likely be a bad idea there. Jan