Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Paolo Bonzini <pbonzini@redhat.com>]

On 06/11/2014 17:18, Igor Mammedov wrote:
> On Thu, 06 Nov 2014 16:57:47 +0100
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> On 06/11/2014 07:53, Hanjun Guo wrote:
>>>> So the important question is _why_ the guest needs to see an ACPI
>>>> environment. What exactly can ACPI provide to the guest that DT does not
>>>> already provide, and why is that necessary? What infrastrucutre is
>>>> needed for that use case?
>>>
>>> There is important feature called system device dynamic reconfiguration,
>>> you know, hot-add/remove, if a gust need more/less memory or CPU, can we
>>> add or remove them dynamically with DT? ACPI can do this, but I have no
>>> idea if DT can. (Sorry, I don't know much about DT)
>>
>> Indeed hot-add/remove is the single biggest AML user in x86 QEMU.
>> Whether you really need it, it depends on what you are adding/removing.
>>
>> For PCI there is no problem.  We can use PCIe from the beginning, and
>> use PCIe hotplug support that is already in QEMU.
>>
>> Memory and CPU are more problematic.  For memory we could perhaps use a
>> PCI memory device, though I'm not sure if that would require drivers in
>> the OS or everything just works.
> 
> BTW what's PCI memory device? Is there any reference I could read about it?

Just something with a huge BAR.  Like ivshmem, but teaching the OS to
see it as memory.

>> CPU hotplug, however, probably requires AML.  Of course it can be
>> generated in the firmware, like we used to do for x86, but Igor
>> explained why it wasn't a great idea.  That said, one of the problems
>> ("never ending expansion of PV QEMU-BIOS interface") could be less
>> important since ARM DT is a better interface than x86 fw_cfg.
> Unfortunately we still would need to teach UEFI to recognize
> QEMU specific DT entries that were just invented,
> it doesn't matter what transport is used (DT or fw_cfg) to convey
> new information to UEFI/BIOS.

Right, it's just a bit more organized than fw_cfg.

Paolo