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