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

[Gerd Hoffmann]

  Hi,

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

Ok.

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

Yes.  We should go that route for q35.

> For
> i440fx/piix4 it was discussed and more or less decided we would only support
> a paravirtual way of memory hotplug. 

Sure, there is no other way to do it.

It is probably a good idea to model piix4 paravirtual to work simliar to
q35 native.

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

It still can (and should) be acpi-based.  It is just that:

  (a) Instead of using get_system_io() as parent memory region you use
      create a pci device and place the memory region in one of the PCI
      bars.
  (b) Instead of using OperationRegion($name, SystemIO, $magicaddress)
      you use OperationRegion($name, PciBarTarget, ...) to access the
      registers.

cheers,
  Gerd