[Xen-devel] Re: [PATCH 05/13] Nested Virtualization: CRn & paged real mode

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 16:42 +0100 on 08 Sep (1283964177), Christoph Egger wrote:
> On Wednesday 08 September 2010 17:11:33 Tim Deegan wrote:
> > Hi,
> >
> > > diff -r 0199b689a2d0 -r e0eae5b67977 xen/arch/x86/hvm/hvm.c
> > > --- a/xen/arch/x86/hvm/hvm.c
> > > +++ b/xen/arch/x86/hvm/hvm.c
> > > @@ -54,6 +54,7 @@
> > >  #include <asm/hvm/support.h>
> > >  #include <asm/hvm/cacheattr.h>
> > >  #include <asm/hvm/trace.h>
> > > +#include <asm/hvm/nestedhvm.h>
> > >  #include <asm/mtrr.h>
> > >  #include <asm/apic.h>
> > >  #include <public/sched.h>
> > > @@ -1109,9 +1110,13 @@ int hvm_set_cr0(unsigned long value)
> > >      /* ET is reserved and should be always be 1. */
> > >      value |= X86_CR0_ET;
> > >
> > > -    if ( (value & (X86_CR0_PE | X86_CR0_PG)) == X86_CR0_PG )
> > > +    if ( !nestedhvm_vmentry_emulate(v) &&
> > > +         (value & (X86_CR0_PE | X86_CR0_PG)) == X86_CR0_PG )
> > >          goto gpf;
> >
> > The change above makes perfect sense: nested SVM guests should be
> > allowed to enter paged real mode.
> >
> > But I don't understand either of the changes below.  Can you explain why
> > the cache control bits get special treatment?
> 
> Your question confuses me related to this mail:
> http://lists.xensource.com/archives/html/xen-devel/2010-08/msg00432.html
> 
> Please explain what you want to know.

Sorry, I misread the patch last time. 

| I understand the paged-real-mode case, but why do you also allow CR0.CD
| and CR0.NW for nested VMs?

because the patch seemed to do two things: 
- allow nested VMs to ask for paged real mode; and
- honour CR0.CD and CR0.NW for nested VMs

and I didn't understand the second one.  I see now that it actually
explicitly _doesn't_ honour CR0.CD and CR0.NW for nested VMs, which
makes more sense.  Sorry for the confusing reply.

I don't think that needs to happen -- it's up to the L1 VMM to decide
whether the L2 VMM should be allowed to set cache control bits in CR0,
so only the first change in this patch is needed.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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