On 06/11/2014 17:18, Igor Mammedov wrote:
> On Thu, 06 Nov 2014 16:57:47 +0100
> Paolo Bonzini <pbonz...@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
