qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug


From: Vasilis Liaskovitis
Subject: Re: [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
Date: Wed, 19 Dec 2012 12:35:54 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Hi,

On Wed, Dec 19, 2012 at 08:27:36AM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > - multiple memory buses can be registered. Memory buses of the real 
> > hw/chipset
> >   or a paravirtual memory bus can be added.
> 
> IIRC q35 supports memory hotplug natively (picked up in some
> discussion).  Is that correct?
> 
> What does the code emulate?  It doesn't look like it emulates q35 memory
> hotplug ...

correct, only the number of channels and ranks(dimms) per channel has been
emulated so far (2 channels of 4 dimms each). So it is still paravirtual memory
hotplug, not native. Native support still needs to be worked on.

>From previous discussion I also understand that q35 supports native hotplug. 
Sections 5.1 and 5.2 of the spec describe the MCH registers but the native
acpi-memory hotplug specifics are not yet clear to me. Any pointers from the
spec are welcome.

> 
> I think the paravirtual memory hotplug controller should be a PCI device
> (which we then can add as function to the chipset).  Having some fixed
> magic addresses is bad.

ok, so in your opinion a pci-based hotplug controller sounds better than adding
acpi ports to piix4 or ich9?

Magic acpi_ich9 ports can be avoided if q35 native support is implemented. For
i440fx/piix4 it was discussed and more or less decided we would only support
a paravirtual way of memory hotplug. 

In the description. I meant "paravirtual memory bus" to describe a memory bus
with unlimited number of dimm devices. But the "hotplug control" has always
been acpi-based so far and not a pci device.

thanks,

- Vasilis



reply via email to

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