Re: [PATCH 07/14] Nested Virtualization: trap

[Christoph Egger <Christoph.Egger@amd.com>]

On Tuesday 10 August 2010 14:56:19 Tim Deegan wrote:
> Hi,
>
> At 13:25 +0100 on 10 Aug (1281446710), Christoph Egger wrote:
> > > I don't see why this change is needed.  AFAICS, all cases are covered
> > > by unconditionally calling hvm_inject_exception() here.  *-on-hap never
> > > takes this path at all because L0 doesn't intercept #PF when it uses
> > > HAP, so the only difference this makes is to catch the case where L1
> > > didn't intercept #PF and it was injected directly into L2.
> >
> > Correct. How should L1 fix its shadow page table in this case?
> > I expect L2 to go wild because of that.
>
> L1 might not be using shadow pagetables.  It might be some sort of
> cooperative microkernel allowing the L2 to do its own paging.  Even in
> Xen, if we started using HVM containers for performance of 64-bit
> direct-paged guests, we might consider having guest pagefaults delivered
> straight to the guest (well, except that it would break ptwr_foo).

Ok, I didn't have such microkernels in mind.

> > > But this is an acceptable thing for the L1 to do (even though Xen
> > > doesn't ever behave that way), so I think it's wrong to crash the
> > > guest.
> >
> > Ok, that is the point where our opinions differ. Can you explain me why
> > this is acceptable? As I said above, I expect the L2 guest to go wild in
> > this case.
>
> Quite possibly, but it's (a) exactly what would happen on real hardware,
> and (b) not L0's problem if L1 misbehaves (except to protect other L1s
> from it).

I see. Ok, I will change hvm_inject_exception() back to return void.

> > > What was the reason for calling svm_inject_exception() directly in some
> > > cases?
> >
> > svm_inject_exception() always injects a #PF into running L1 or L2. It
> > never injects a VMEXIT into L1.
>
> Yes; but _why_ do we need to inject directly into L2?

Not at all. This shouldn't happen in practise. The 'goto out' should prevent 
this.

The reason is, this last line also runs with nestedhvm disabled in the guest 
config file. We don't want to break the non-nestedhvm case, right?
Oh, I see now: hvm_inject_exception() does the right thing for all cases.
We can just leave it there as it is in the upstream source.

Christoph

-- 
---to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Alberto Bozzo, Andrew Bowd
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632