From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mukesh Rathor <mukesh.rathor@oracle.com>
Subject: Re: [V10 PATCH 09/23] PVH xen: introduce
 pvh_set_vcpu_info() and vmx_pvh_set_vcpu_info()
Date: Tue, 13 Aug 2013 19:21:06 -0700
Message-ID: <20130813192106.697d79f8@mantra.us.oracle.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>
	<20130812172702.6b6dd055@mantra.us.oracle.com>
	<520A2B7202000078000EB7DA@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 <mukesh.rathor@oracle.com>) id 1V9Qi4-0007ws-Or
	for xen-devel@lists.xenproject.org; Wed, 14 Aug 2013 02:21:16 +0000
In-Reply-To: <520A2B7202000078000EB7DA@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>, Tim Deegan <tim@xen.org>
List-Id: xen-devel@lists.xenproject.org

On Tue, 13 Aug 2013 11:49:54 +0100
"Jan Beulich" <JBeulich@suse.com> wrote:

> >>> On 13.08.13 at 02:27, Mukesh Rathor <mukesh.rathor@oracle.com>
> >>> wrote:
> > On Mon, 12 Aug 2013 08:54:34 +0100 "Jan Beulich"
..
> If you think so, then you're not clear of the implications, including
> that this - being part of the hypervisor/guest interface - needs to
> be fixed _now_ rather than later. What I think you neglect here is
> that struct vcpu_guest_context is also used for save/restore, and
> there you _need_ to properly represent the LDT. So you have two
> choices: Keep the structure the way it is and require the guest to
> do LDT management the PV way (which will be very hard, as you
> have no spare selectors to use for it), or do things the HVM way
> (having the guest use the LDT instruction, implying that it's the
> selector and nothing else that needs to be saved/restored).
> 
> If you go that latter, more natural route, then you next need to
> (immediately) decide whether the extra context will also be save/
> restored HVM-like (via struct hvm_hw_cpu), in which case the LDT
> related fields mentioned above are just unused on the PVH case
> (and you'd want to validate that they're zeroed).

I completely intend for save/restore to be the HVM way, that would make
most sense. This brings back to patch version 0, LDT related fields
are unused on PVH :). 

thanks,
mukesh