On 09/08/2018 12:47, speck for Andrew Cooper wrote:
>>> and the CPUID maxphysaddr hasn't been
>>> levelled for heterogeneous migration safety
>> I don't know about Xen PV, but when using EPT you cannot do that, the
>> maxphyaddr is not virtualizable (obviously not to guest-maxphyaddr >
>> host-maxphyaddr, but guest-maxphyaddr < host-maxphyaddr cannot be
>> emulated either).
> There is nothing wrong with telling a guest it has maxphysaddr smaller
> than the real maxphysaddr.  Just like CPUID feature levelling, it says
> "don't go playing there".
> 
> No software is permitted to rely on the behaviour of reserved bits.

That's just not true for page tables.  Bits maxphyaddr:51 are documented
to generate a page fault with the reserved bits set.  In the future the
behavior may change (unlikely) but it would be keyed against e.g. a new
CR4 bit.

In fact, Intel has been stashing new functionality in previously ignored
bits, of course keying the interpretation on bits from CR4 (e.g.
protection keys) or VMCS execution controls (e.g. EPT mode-based
execution control aka XS/XU).

I tried emulating guestphysaddr < hostphysaddr in KVM, but generating
the reserved bits page fault from EPT violations doesn't work.  If the
host processor thinks the bits are not reserved and generates e.g. a
present-but-not-writable fault, no EPT violation happens and the guest
will get an unexpected page fault error code.  This can cause
malfunctioning.

Paolo