[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: |
Hanjun Guo |
Subject: |
Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation |
Date: |
Thu, 06 Nov 2014 14:53:03 +0800 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
On 2014-10-31 2:02, Mark Rutland wrote:
> On Thu, Oct 30, 2014 at 05:52:44PM +0000, Peter Maydell wrote:
>> On 30 October 2014 17:43, Alexander Spyridakis
>> <address@hidden> wrote:
>>> Currently, the virt machine model generates Device Tree information
>>> dynamically based on the existing devices in the system. This patch series
>>> extends the same concept but for ACPI information instead. A total of seven
>>> tables have been
>>> implemented in this patch series, which is the minimum for a basic ARM
>>> support.
>>>
>>> The set of generated tables are:
>>> - RSDP
>>> - XSDT
>>> - MADT
>>> - GTDT
>>> - FADT
>>> - FACS
>>> - DSDT
>>>
>>> The tables are created in standalone buffers, taking into account the
>>> needed information passed from the virt machine model. When the generation
>>> is finalized, the individual buffers are compacted to a single ACPI binary
>>> blob, where it is injected on the guest memory space in a fixed location.
>>> The guest kernel can find the ACPI tables by providing to it the physical
>>> address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument).
>>
>> (Sorry, I should have waited for the cover letter to arrive before replying.)
>>
>> I think this is definitely the wrong approach. We already have to
>> generate device tree information for the hardware we have, and having
>> an equivalent parallel infrastructure for generating ACPI as well
>> seems like it would be a tremendous mess. We should support guests
>> that require ACPI by having QEMU boot a UEFI bios blob and have that
>> UEFI code generate ACPI tables based on the DTB we hand it.
>> (Chances seem good that any guest that wants ACPI is going to want
>> UEFI runtime services anyway.)
>
> Depending on why people want ACPI in a guest environment, generating
> ACPI tables from a DTB might not be possible (e.g. if they want to use
> AML for some reason).
Agreed.
>
> 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)
Thanks
Hanjun
- 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, Arnd Bergmann, 2014/11/12
- 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 <=