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

[Tim Deegan <tim@xxxxxxx>]

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?

Tim.

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