[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v6 00/22] Generate ACPI v5.1 tables and expose t

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v6 00/22] Generate ACPI v5.1 tables and expose them to guest over fw_cfg on ARM
Date: Thu, 7 May 2015 17:34:20 +0100

On 7 May 2015 at 10:29, Shannon Zhao <address@hidden> wrote:
> From: Shannon Zhao <address@hidden>
> This patch series generate seven ACPI tables for machine virt on ARM.
> The set of generated tables are:
> - RSDP
> - RSDT
> - MADT
> - GTDT
> - FADT
> - DSDT
> - MCFG (For PCIe host bridge)
> These tables are created dynamically using the function of aml-build.c,
> taking into account the needed information passed from the virt machine
> model. When the generation is finalized, it use fw_cfg to expose the
> tables to guest.
> You can fetch this from following repo:
>         http://git.linaro.org/people/shannon.zhao/qemu.git  ACPI_ARM_v6

Hi. I've had a look through these patches now, and sent some mails
for a couple of specific issues. For the rest, this is what I'd
like to see for me to pull this in to target-arm:

(1) acks or reviewed-by from one of the QEMU ACPI folk for any
patch that's touching generic ACPI code.
(2) series should pass checkpatch.pl (you have a lot of overlong lines
warnings at the moment).
(3) we shouldn't generate any ACPI tables or information where the
corresponding kernel code hasn't been accepted into mainline or
the arm64 tree; if there's anything here which isn't covered by
the accepted ACPI patches we should postpone that til the kernel
parts are in.

If item (3) seems too awkward or harsh as a criterion I'm
open to discussion about it, but my feeling is that I'd
rather not start emitting tables until they're definitely
nailed down in format by being in the kernel.

Finally, if you have some prebuilt images and command lines that
would be helpful, since I can put them into my local set of
things I run to check for breakage before making ARM pull requests.

-- PMM

reply via email to

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