Re: [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set

[Paolo Bonzini]

On 17/06/2016 15:18, Eduardo Habkost wrote:
> On Fri, Jun 17, 2016 at 09:15:06AM +0100, Dr. David Alan Gilbert wrote:
>> * Eduardo Habkost (address@hidden) wrote:
>>> On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. David Alan Gilbert (git) 
>>> wrote:
>>>> From: "Dr. David Alan Gilbert" <address@hidden>
>>>>
>>>> Currently QEMU sets the x86 number of physical address bits to the
>>>> magic number 40.  This is only correct on some small AMD systems;
>>>> Intel systems tend to have 36, 39, 46 bits, and large AMD systems
>>>> tend to have 48.
>>>>
>>>> Having the value different from your actual hardware is detectable
>>>> by the guest and in principal can cause problems;
>>>
>>> What kind of problems?
>>>
>>> Is it a problem to have something smaller from the actual
>>> hardware, or just if it's higher?
>>
>> I'm a bit vague on the failure cases; but my understanding of the two
>> cases are;
>>
>> Larger is a problem if the guest tries to map something to a high
>> address that's not addressable.

        (Note: this is a problem when migrating to hosts with _smaller_
               phys-bits)

>> Smaller is potentially a problem if the guest plays tricks with
>> what it thinks are spare bits in page tables but which are actually
>> interpreted.   I believe KVM plays a trick like this.

        (Note: this is a problem when migrating to hosts with _larger_
               phys-bits)

> If both smaller and larger are a problem, we have a much bigger
> problem than we thought. We need to confirm this.
> 
> So, what happens if the guest play tricks in bits 40-45 when QEMU
> sets the limit to 40 but we are running in a 46-bit host? Is it
> really a problem? I assumed it would be safe.

The guest expects a "reserved bit set" page fault, but doesn't get one.

>>    2) While we have maxmem settings to tell us the top of VM RAM, do
>>       we have anything that tells us the top of IO space? What happens
>>       when we hotplug a PCI card?
> 
> (CCing Marcel and Michael, as we were discussing this recently.)
> 
> That's a good question. When calculating how many bits the
> machine requires, machine code could choose to reserve a
> reasonable amount of space for hotplug by default.
> 
> Whatever we choose as the default, in some corner cases (e.g.
> almost-32GB VMs running in a 39-bit host) we will still need to
> let the user choose between having extra space for hotplug and
> being able to safely migrate to 36-bit hosts.

No, this is not possible unfortunately.  If you set phys-bits <
host-phys-bits, the guest may expect some bits to be reserved, when they
actually aren't.  In practice this doesn't happen for the reason I
mentioned in my other message (tl;dr: 1-the trick is rarely used though
KVM uses it, 2-if they use bit 51 they're safe in practice).  But still
making phys-bits smaller than host-phys-bits is a bad idea.

Making the guest's phys-bits larger than host-phys-bits would be okay if
you reserve the area in the e820 and assume the guest doesn't touch it.
But it is not a great idea too, because e820 describes RAM, so you're
telling the guest "look, there's 64 TB of reserved RAM up there".

>>    3) Is it better to stick to sizes that correspond to real hardware
>>       if you can?  For example I don't know of any machines with 37 bits
>>       - in practice I think it's best to stick with sizes that correspond
>>       to some real hardware.
> 
> Yeah, "as small as possible" could be actually "the smallest
> possible value from a set of known-to-exist values". e.g. if we
> find out that we need 37 bits, it's probably better to simply use
> 39 bits.
> 
> Choosing from a smaller set of values also makes corner cases
> (like the example above) less likely to happen.

Not really, because any value that doesn't match the host is
problematic, albeit in different ways.

Paolo