On 12/12/2011 01:37 PM, Nadav Har'El wrote: > On Sun, Nov 13, 2011, Avi Kivity wrote about "Re: [PATCH 0/10] nEPT: Nested EPT support for Nested VMX": > > > 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). > > I'm now trying to figure out this part, and I think I am beginning to > understand the mess you are referring to: > > In nested_ept_inject_page_fault I now assume the exit reason is always EPT > VIOLATION and have > > vmcs12->exit_qualification = fault->error_code; > > But fault->error_code is not in the exit qualification format but in > the PFERR_* format, which has different meanings for the bits... > Moreover, PFERR_RSVD_MASK should cause an EPT MISCONFIG, not EPT > VIOLATION. Is this what you meant above? In spirit yes. In practice rather than translating from PFERR format to EPT VIOLATION EXIT_QUALIFICATION format, walk_addr() should directly compute the exit qualification (and an additional bit: whether it's an EPT VIOLATION or EPT MISCONFIGURATION. > I didn't quite understand what you meant in the 4th case about needing > to compute ept12 permissions. I'm assuming that if the EPT violation > was caused because L0 decreased permissions from what L1 thought, then L0 > will solve the problem itself and not inject it to L1. So if we are injecting > the fault to L1, don't we already know the correct fault reason and don't > need to compute it? If we're injecting an EPT VIOLATION to L1 (because we weren't able to resolve it; say L1 write-protected the page), then we need to compute EXIT_QUALIFICATION. Bits 3-5 of EXIT_QUALIFICATION are computed from EPT12 paging structure entries (easy to derive them from pt_access/pte_access). > > There's another complication: when the fault comes from an EPT violation > in L2, handle_ept_violation() calls mmu.page_fault() with an error_code of > exit_qualification & 0x3. This means that the error_code in this case is > *not* in the expected PFERR_* format, and we need to know that in > nested_ept_inject_page_fault. Moreover, in the original EPT visolation's > exit qualification, there were various other bits which we lose (and don't > have a direct parallel in PFERR_* anyway), so when we reinject the fault, > L1 doesn't get them. struct x86_exception already has 'bool nested', which indicates whether it's an L1 or L2 fault. You need to extend that, perhaps by adding another bool, to distinguish between EPT VIOLATION and EPT_QUALIFICATION. The error_code field should be extended to 64 bits for EXIT_QUALIFICATION (though only bits 0-12 are defined). You need another field for the guest linear address. EXIT_QUALIFICATION has to be calculated, it cannot be derived from the original exit. Look at kvm_propagate_fault(). > What a mess :( If you have a splitting headache, you're on the right track. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
