Avi Kivity <avi.kiv...@gmail.com> wrote: > On 03/03/2015 11:52 AM, Paolo Bonzini wrote: >>> In this >>> case, the VM might expect exceptions when PTE bits which are higher than the >>> maximum (reported) address width are set, and it would not get such >>> exceptions. This problem can easily be experienced by small change to the >>> existing KVM unit-tests. >>> >>> There are many variants to this problem, and the only solution which I >>> consider complete is to report to the VM the maximum (52) physical address >>> width to the VM, configure the VM to exit on #PF with reserved-bit >>> error-codes, and then emulate these faulting instructions. >> Not even that would be a definitive solution. If the guest tries to map >> RAM (e.g. a PCI BAR that is backed by RAM) above the host MAXPHYADDR, >> you would get EPT misconfiguration vmexits. >> >> I think there is no way to emulate physical address width correctly, >> except by disabling EPT. > > Is the issue emulating a higher MAXPHYADDR on the guest than is available > on the host? I don't think there's any need to support that. > > Emulating a lower setting on the guest than is available on the host is, I > think, desirable. Whether it would work depends on the relative priority > of EPT misconfiguration exits vs. page table permission faults.
Thanks for the feedback. Guest page-table permissions faults got priority over EPT misconfiguration. KVM can even be set to trap page-table permission faults, at least in VT-x. Anyhow, I don’t think it is enough. Here is an example My machine has MAXPHYADDR of 46. I modified kvm-unit-tests access test to set pte.45 instead of pte.51, which from the VM point-of-view should cause the #PF error-code indicate the reserved bits are set (just as pte.51 does). Here is one error from the log: test pte.p pte.45 pde.p user: FAIL: error code 5 expected d Dump mapping: address: 123400000000 ------L4: 304b007 ------L3: 304c007 ------L2: 304d001 ------L1: 200002000001 As you can see, the #PF should have had two reasons: reserved bits, and user access to supervisor only page. The error-code however does not indicate the reserved-bits are set. Note that KVM did not trap any exit on that faulting instruction, as otherwise it would try to emulate the instruction and assuming it is supported (and that the #PF was not on an instruction fetch), should be able to emulate the #PF correctly. [ The test actually crashes soon after this error due to these reasons. ] Anyhow, that is the reason for me to assume that having the maximum MAXPHYADDR is better. Nadav -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
