From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: [V10 PATCH 09/23] PVH xen: introduce pvh_set_vcpu_info() and vmx_pvh_set_vcpu_info() Date: Wed, 7 Aug 2013 18:27:15 -0700 Message-ID: <20130807182715.4bc3bddf@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> <20130725134755.GB87903@ocelot.phlegethon.org> <20130725175840.1bfc124d@mantra.us.oracle.com> <51FFA3E202000078000E936B@nat28.tlf.novell.com> <20130805183436.7046527e@mantra.us.oracle.com> <20130806185313.393efcc8@mantra.us.oracle.com> <20130807100121.GB54382@ocelot.phlegethon.org> 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 1V7F0d-0005PW-PK for xen-devel@lists.xenproject.org; Thu, 08 Aug 2013 01:27:23 +0000 In-Reply-To: <20130807100121.GB54382@ocelot.phlegethon.org> 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.xen@gmail.com, Jan Beulich List-Id: xen-devel@lists.xenproject.org On Wed, 7 Aug 2013 11:01:21 +0100 Tim Deegan wrote: > At 18:53 -0700 on 06 Aug (1375815193), Mukesh Rathor wrote: > > On Mon, 5 Aug 2013 18:34:36 -0700 > > Mukesh Rathor wrote: > > > > > On Mon, 05 Aug 2013 12:08:50 +0100 > > > "Jan Beulich" wrote: > > > > > > > >>> On 26.07.13 at 02:58, Mukesh Rathor > > > > >>> wrote: > > > > > On Thu, 25 Jul 2013 14:47:55 +0100 > > > > > Tim Deegan wrote: > > ....... > > > > > > >> At 18:59 -0700 on 23 Jul (1374605957), Mukesh Rathor wrote: > > > > > That was an option discussed with Jan, walking and reading > > > > > the GDT entries from the gdtaddr the guest provided to load > > > > > the hidden parts. But, I agree with him, that for the initial > > > > > cpu boot we can restrict the ABI to say: 0 base addr, ~0 > > > > > limit, and "read/write, accessed" default attributes for the > > > > > hidden part (64bit guest). > > > > > > > > That must be a misunderstanding then (also see my other reply) > > > > - I always meant to require that you either properly load the > > > > hidden register portions from the descriptor tables, or at > > > > least verify that the descriptor table entries referenced match > > > > the defaults you enforce. > > > > > > Ok, I thought you just wanted to be documented, If I'm gonna write > > > the code to verify, i might as well just write the hidden > > > porions, an option I'd proposed. That way there are no > > > constraints. I'm currently working on just doing that, and will > > > be in the next version of the patch. > > > > Ok, I've mostly got code to set the hidden fields, but the more I > > think about it, the more I feel that the right/better thing to do > > is to just not set any selectors at all, instead default them in > > the VMCS. > > Why do you think that's better? Why on earth wouldn't a VCPU > context-setting hypercall that takes segment selectors as arguments > just DTRT? The principle of least astonishment should apply here. Ok. looks like the common denometer is to just set the hidden fields, so I'll just do that. thanks, mukesh