Re: [Xen-devel] Hypercalls in Intel-VT

[Mark Williamson <mark.williamson@xxxxxxxxxxxx>]

> so is xen currently mapped in the first  64MB of every guest hvm?

No, it's not.  Only for PV guests, not HVM.

> also, 
> does xen use different GDT for itself or it uses some slots in the GDT of
> every guest hvm?

Root mode, where Xen runs has a separate GDT to non-root mode where guests 
run.

> if you could you guide me to some pointers which mention 
> xen's implementation for intel-vt, that will be really helpful. thanks.

Basically, I think we're getting confused about how VT fundamentally works.

Normal x86 has just 4 protection rings and a bunch of special purpose 
datastructures and registers.  Xen runs in ring 0, guests run in rings 1-3 
(usually they run their kernel in 1, userland in 3).  Xen borrows some GDT 
slots from the guest, and also maps itself into the top of the guest address 
space.  That's how PV works today.

HVM works very differently from the level of the hardware up to the level of 
Xen.

Intel's VT adds two new modes that are orthogonal to protection rings: "root 
mode" and "non-root mode".  A more descriptive way of thinking about these is 
to think of "root mode" as "host mode" and "non-root mode" as "guest mode".  
I'm going to use these terms in the explanation, but they're not the official 
terms for those modes.

Xen runs in "host (root) mode" and is aware of the host processor.  Guests run 
in "guest (non-root) mode".  In guest (non-root) mode there is a separate set 
of control registers that are private to the guest.  The guest isn't allowed 
to touch the privileged control registers of the host, because you can only 
do that if you run in host (root) mode.  The guest doesn't know that it's 
running in non-root mode.

When Xen wants to run an HVM guest on VT it does a VMEnter.  This instructs 
the processor to start using the guest's private registers (EIP, CR3, EAX, 
EBX, etc etc) so that the guest starts running as if it had control over the 
hardware.  The virtual memory space currently in operation is that of the 
guest only.  Xen isn't mapped in there anywhere, because Xen isn't mapped in 
guest (non-root) mode.

If an event happens that Xen needs to attend to, the CPU will jump back out of 
guest (non-root) mode and into host (root) mode where Xen is mapped.  This 
event is a VMExit.  The VMExit swaps back the register state that Xen had 
before the guest was entered, so that Xen can continue running as it was 
before.  Xen can run and do whatever it needs to do.

So, in answer to your original question:

1) Xen isn't mapped into the HVM guest because Xen is not mapped in non-root 
mode.  The guest has the entire virtual address space to itself.

2) Because Xen runs in host (root) mode it uses a completely separate GDT to 
the guest running in non-root mode.  The switch between the two GDTs will 
happen automatically as a consequence of mode switches via VMEnter and 
VMExit.

Does that help?

Cheers,
Mark

> On 10/29/07, Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote:
> >  The way that PV and HVM guests work is very different. Many of the
> > tricks necessary for hosting PV guests, such as stealing address space
> > for the hypervisor, are not necessary for HVM guests.
> >
> >  -- Keir
> >
> > On 29/10/07 07:59, "Ashish Bijlani" <ashish.bijlani@xxxxxxxxx> wrote:
> >
> > if a VM's context is saved to and xen's context is loaded from VMCS upon
> > every VMexit call in VT, the why is xen mapped in the first 64MB region
> > of every guest VM? As far as I know, TLB will also be flushed when xen's
> > context is loaded from VMCS host area.
> >
> > On 10/26/07, *Mark Williamson* <mark.williamson@xxxxxxxxxxxx
> > <mailto:mark.williamson@xxxxxxxxxxxx> <mark.williamson@xxxxxxxxxxxx> >
> >
> > wrote:
> > > thanks for your answers. really appreciate your help. however, i've
> > > some
> > >
> > > more doubts and would appreciate if you could answer the following:
> >
> > We're now getting a bit outside my understanding of VMX, but the other
> > guys
> > may know more.
> >
> > > how
> > > does transition happen from root VMX mode to non-root VMX mode? I mean
> >
> > does
> >
> > > it load Xen's CS, DS from the GDT or does it switch GDT to load Xen's
> >
> > GDT?
> >
> > > Also, does it do TLB flush, provided Xen is mapped in the first 64MB of
> >
> > the
> >
> > > guest  VM? thanks.
> >
> > Well, the hardware probably does something equivalent to this.  But (as
> > far as
> > I know) that's not how it looks to software: from the software's point of
> > view you are just doing a VMEXIT from non-root mode to root mode.  Root
> > mode
> > effectively has a different set of control registers / datastructures to
> > non-root mode.  So software doesn't have to worry so much about the data
> > structures involved.  I don't *think* the software even has to save /
> > restore
> > the guest registers (unless it wants to modify them).
> >
> > Regarding the TLB flush, again, the hardware quite possibly does that.
> >  But
> > I'm not aware of anything in the VMX spec that exposes this detail, so
> > Intel
> > could easily tag the TLB entries as root / non-root to avoid flushing on
> > a
> >
> > VMEXIT / VMENTER.  For all I know, they may do this already!
> >
> > Eddie, did I get that about right? :-)
> >
> > Cheers,
> > Mark
> >
> > > On 10/26/07, Mark Williamson < mark.williamson@xxxxxxxxxxxx
> >
> > <mailto:mark.williamson@xxxxxxxxxxxx> <mark.williamson@xxxxxxxxxxxx> >
> >
> > wrote:
> > > > > that means dom0 doesn't make trap to ring 0 root VMX mode for
> > > > > privileged operations like updating cr3?
> > > >
> > > > Dom0 always runs paravirtualised, it can't be an HVM domain.  So it
> >
> > just
> >
> > > > uses
> > > > the normal paravirtualised interface, regardless of whether VMX is
> > > > available
> > > > in the hardware.
> > > >
> > > > Cheers,
> > > > Mark
> > > >
> > > > > On 10/26/07, Dong, Eddie < eddie.dong@xxxxxxxxx> wrote:
> > > > > >  DOm0 works in ring 1 root VMX mode. Anyway can switch from ring
> > > > > > 1
> >
> > to
> >
> > > > > > ring 0 can be used for accessing privileged resource such as INT
> >
> > xx,
> >
> > > > or
> > > >
> > > > > > thru exception like I/O.
> > > > > >
> > > > > > But HVM works in non root VMX mode though ring=0, so you need to
> > > >
> > > > switch
> > > >
> > > > > > from non root VMX mode to root VMX mode to access privileged
> > > > > > resource.
> > > >
> > > > VM
> > > >
> > > > > > Exit is the only way to do this.
> > > > > >
> > > > > >  ------------------------------
> > > > > > *From:* xen-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:
> > > > > > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] *On Behalf Of *Ashish
> >
> > Bijlani
> >
> > > > > > *Sent:* 2007å10æ26æ 9:14
> > > > > > *To:* xen-devel@xxxxxxxxxxxxxxxxxxx
> > > > > > *Subject:* Re: [Xen-devel] Hypercalls in Intel-VT
> > > > > >
> > > > > > how does dom0 on intel-vt gets privileges to access the hardware
> > > >
> > > > devices?
> > > >
> > > > > > i mean does it get these privileges through superpages?
> > > > > >
> > > > > > On 10/25/07, Cui, Dexuan < dexuan.cui@xxxxxxxxx
> >
> > <mailto:dexuan.cui@xxxxxxxxx> <dexuan.cui@xxxxxxxxx> > wrote:
> > > > > > > > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > > > > > > > [mailto: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx <mailto:
> >
> > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx> ]
> >
> > > > > > > On Behalf Of Ashish Bijlani
> > > > > > >
> > > > > > > > Sent: 2007å10æ26æ 8:20
> > > > > > > > To: xen-devel@xxxxxxxxxxxxxxxxxxx
> > > > > > > > Subject: Re: [Xen-devel] Hypercalls in Intel-VT
> > > > > > > >
> > > > > > > >
> > > > > > > > could there be a way to make a transition into xen without a
> > > >
> > > > vmexit
> > > >
> > > > > > > upon executing an iret inside a guest os krnl?
> > > > > > > I think we are talking about VMX guest -- the answer it NO...
> >
> >  For
> >
> > > > an
> > > >
> > > > > > > VMX guest to return to Xen, a VMexit is a must. You can refert
> >
> > to
> >
> > > > Intel
> > > >
> > > > > > > Software Developer Manual 3B for details.
> > > > > > >
> > > > > > > -- Dexuan
> > > >
> > > > --
> > > > Dave: Just a question. What use is a unicyle with no seat?  And no
> > > > pedals! Mark: To answer a question with a question: What use is a
> > > > skateboard? Dave: Skateboards have wheels.
> > > > Mark: My wheel has a wheel!
> >
> > --
> > Dave: Just a question. What use is a unicyle with no seat?  And no
> > pedals! Mark: To answer a question with a question: What use is a
> > skateboard? Dave: Skateboards have wheels.
> > Mark: My wheel has a wheel!
> >
> >
> > ------------------------------
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel



-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel