On 2013-03-22 07:23, Nakajima, Jun wrote: > On Mon, Mar 4, 2013 at 8:45 PM, Nakajima, Jun <jun.nakajima@xxxxxxxxx> wrote: >> I have some updates on this. We rebased the patched to the latest KVM >> (L0). It turned out that the version of L1 KVM/Linux matters. At that >> time, actually I used v3.7 kernel for L1, and the L2 didn't work as I >> described above. If I use v3.5 or older for L1, L2 works with the EPT >> patches. So, I guess some changes made to v3.6 might have exposed a >> bug with the nested EPT patches or somewhere. We are looking at the >> changes to root-cause it. >> > > Finally I've had more time to work on this, and I think I've fixed > this. The problem was that the exit qualification for EPT violation > (to L1) was not accurate (enough). And I needed to save the exit > qualification upon EPT violation somewhere. Today, that information is > converted to error_code (see below), and we lose the information. We > need to use at least the lower 3 bits when injecting EPT violation to > the L1 VMM. I tried to use the upper bytes of error_code to pass part > of the exit qualification, but it didn't work well. Any suggestion for > the place to store the value? kvm_vcpu? > > ... > /* It is a write fault? */ > error_code = exit_qualification & (1U << 1); > /* ept page table is present? */ > error_code |= (exit_qualification >> 3) & 0x1; > > return kvm_mmu_page_fault(vcpu, gpa, error_code, NULL, 0); I don't have a full picture (already asked you to post / git-push your intermediate state), but nested related states typically go to nested_vmx, thus vcpu_vmx. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux -- 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
