Re: [Xen-devel] [PATCH 07/14] Nested Virtualization: trap

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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).

> > 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).

> > 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?

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