qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI


From: Igor Mammedov
Subject: Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation
Date: Thu, 6 Nov 2014 17:18:41 +0100

On Thu, 06 Nov 2014 16:57:47 +0100
Paolo Bonzini <address@hidden> 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
> 




reply via email to

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