Re: 2 CPU Conformance Issue in KVM/x86

Nadav Amit
2015-03-09T17:51:56Z

Avi Kivity <avi.kivity@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