Re: [Xen-devel] [V10 PATCH 09/23] PVH xen: introduce pvh_set_vcpu_info() and vmx_pvh_set_vcpu_info()

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-08-07 at 11:01 +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 <mukesh.rathor@xxxxxxxxxx> wrote:
> > 
> > > On Mon, 05 Aug 2013 12:08:50 +0100
> > > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > > 
> > > > >>> On 26.07.13 at 02:58, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> > > > >>> wrote:
> > > > > On Thu, 25 Jul 2013 14:47:55 +0100
> > > > > Tim Deegan <tim@xxxxxxx> 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.
> 
> > Meaning, we set CS=0x10, DS/SS = 0x18  in vmcs create code. Then we
> > document that the guest needs to set a boot GDT as:
> > 
> >  0000000000000000 00cf9b000000ffff
> >  00af9b000000ffff 00cf93000000ffff
> 
> That's a pretty ugly interface -- just because it happens to be easy to
> implement in linux doesn't mean it's a good idea.  What about other OSes
> (or linux, if it changes its default GDT settings)?  They should carry
> extra code that makes up a GDT just for this one hypercall and then more
> code to switch away from it after boot?

I'm not sure that it applies here but a proper PV guest is entitled to
expect that certain hardcoded selectors be present in the GDT, in the
last couple of pages which are reserved for Xen but contain convenient
selectors. A PV guest is even launched on those IIRC, but perhaps not
for secondary vcpus, unless the guest chooses to.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel