From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tim Deegan <tim@xen.org>
Subject: Re: [V10 PATCH 09/23] PVH xen: introduce
	pvh_set_vcpu_info() and vmx_pvh_set_vcpu_info()
Date: Mon, 12 Aug 2013 11:24:12 +0100
Message-ID: <20130812102412.GA24410@ocelot.phlegethon.org>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72) (envelope-from <tim@xen.org>)
	id 1V8pIR-0002Um-C3
	for xen-devel@lists.xenproject.org; Mon, 12 Aug 2013 10:24:19 +0000
Content-Disposition: inline
In-Reply-To: <5208B0DA02000078000EB069@nat28.tlf.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>, Keir Fraser <keir.xen@gmail.com>
List-Id: xen-devel@lists.xenproject.org

At 08:54 +0100 on 12 Aug (1376297674), Jan Beulich wrote:
> >>> On 10.08.13 at 01:41, Mukesh Rathor <mukesh.rathor@oracle.com> 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?

Tim.