qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH 4/5] x86: Allow physical address bits to be set
Date: Fri, 17 Jun 2016 17:24:57 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

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 (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;


[...]


    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


[...]




[...]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]