Re: [PATCH 0/10] nEPT: Nested EPT support for Nested VMX

[Avi Kivity <avi@redhat.com>]

On 11/13/2011 10:52 AM, Nadav Har'El wrote:
> Hi,
>
> On Thu, Nov 10, 2011, Avi Kivity wrote about "Re: [PATCH 0/10] nEPT: Nested EPT support for Nested VMX":
> > This patchset is missing a fairly hairy patch that makes reading L2
> > virtual addresses work.
>
> This was supposed to be part of the nested TDP code that is already in
> the code. To read an L2 virtual address, the code is supposed, if I
> understand correctly, to walk the "walk" mmu (EPT01 and guest_cr3)
> and then use the EPT table - just like the normal EPT case which uses
> the EPT table and the guest_cr3.
>
> I even believed that this inner "walk mmu" will work fine without any
> rewrite needed for ia32/ept differences, because it works (or so I believed)
> just like normal EPT, with the first table being an EPT table, and the second
> table being a normal page table.

The code that walks the guest page table (walk_addr_generic) is not able
to parse EPT PTEs these days.

> I also believed that the fault injection part was also correct: I
> thought that the code already knows when to handle the fault in L2 (when
> the address is missing in cr3), in L1 (when the translation is missing
> in EPT12) or else, in L0.

It does, but it needs to propagate the fault code correctly.  The exit
reason (ept violation vs ept misconfiguration) is meaningless, since we
don't encode anything about it from ept12 into ept02.  In particular an
ept violation could lead to

- no fault, ept02 updated, instruction retried
- no fault, instruction emulated
- L2 fault
- ept violation, need to compute ept12 permissions for exit qualification
- ept misconfiguration

(the second and third cases occur when it is impossible to create an
ept02 mapping - when L0 emulates a gpa that L1 assigns to L2 via ept12).

> So what is the "hairy" missing part?

The EPT parser, and the code for figuring out the type of L1 fault.

>
> > The standard example is L1 passing a bit of
> > hardware (emulated in L0) to a L2; when L2 accesses it, the instruction
> > will fault and need to be handled in L0, transparently to L1.  The
> > emulation can cause a fault to be injected to L2, or and EPT violation
> > or misconfiguration injected to L1.
>
> I don't understand the example. You are refering to nested device
> assignment from L1 to L2 (so L1 stops caring about the device)? Since we
> don't emulate an IOMMU for L1, how can that be done?

You can have device assignment without an IOMMU.  Say, L1 assigns an
HPET block to L2.

A simple test case is L1 assigning a gpa to an L2 that doesn't exist in L0.

-- 
error compiling committee.c: too many arguments to function