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

[Marcel Apfelbaum <marcel@redhat.com>]

On 06/17/2016 04:18 PM, Eduardo Habkost wrote:
> On Fri, Jun 17, 2016 at 09:15:06AM +0100, Dr. David Alan Gilbert wrote:
>> * Eduardo Habkost (ehabkost@redhat.com) wrote:
>>> On Thu, Jun 16, 2016 at 06:12:12PM +0100, Dr. David Alan Gilbert (git) wrote:
>>>> From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
>>>>
>>>> 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;
>>>

[...]

>
>>     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.
>

Indeed we have a real problem with PCI hotplug. Numerous configurations (RAM size + devices present at boot)
leave us with little (32bit PCI hole - devices present at boot) or none (if 32bit hole is full) MMIO for hotplug.

We need a way to reserve [max-ram-including-hotplug-reserved-mem, x] range for this.
But what is x? I thought cpu-max-addressable-addr is OK, now I don't think is not a good idea anymore
because it will limit the migration only to hosts with at least same limit. (migrations that worked before will not work now)

> 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.
>
> This can be solved by setting x86_64-cpu.phys-bits, but isn't it
> too low level? We could have a higher level mechanism in the PC
> machine class (e.g. a min-extra-phys-addr-space-for-hotplug
> property).
>

I personally prefer  min-extra-phys-addr-space-for-hotplug, but why min?
I would go for phys-addr-space-for-hotplug that starts right after max-ram-including-hotplug-reserved-mem
and is less than cpu-max-addressable-addr.

But how to know cpu-max-addressable-addr? David's cpuid wrapper looks just fine, but I understood
there are Windows versions that are not probing cpuid...


Thanks,
Marcel


[...]




[...]