[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: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation |
Date: |
Thu, 06 Nov 2014 17:27:22 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 |
On 06/11/2014 17:18, Igor Mammedov wrote:
> 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?
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
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, (continued)
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Christoffer Dall, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Mark Rutland, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Peter Maydell, 2014/11/12
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Claudio Fontana, 2014/11/13
- Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Peter Maydell, 2014/11/17
Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation, Hanjun Guo, 2014/11/06