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? 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? 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. What a mess :( -- Nadav Har'El | Monday, Dec 12 2011, nyh@xxxxxxxxxxxxxxxxxxx |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |Hardware, n.: The parts of a computer http://nadav.harel.org.il |system that can be kicked. -- 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
