[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-arm] [PATCH] ARM: Virt: Don't generate RTC ACPI node when usin
Re: [Qemu-arm] [PATCH] ARM: Virt: Don't generate RTC ACPI node when using UEFI
Wed, 13 Jan 2016 11:09:49 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
On 01/12/16 16:30, Peter Maydell wrote:
> On 12 January 2016 at 15:24, Shannon Zhao <address@hidden> wrote:
>> When booting VM through UEFI, UEFI takes ownership of the RTC hardware.
>> To DTB UEFI could call libfdt api to disable the RTC device node, but to
>> ACPI it couldn't do that. Therefore, we don't generate the RTC ACPI
>> device in QEMU when using UEFI.
> I don't really understand this. I thought that if we were
> using ACPI then we would always be doing it via UEFI?
Let my try to summarize here too:
- kernel booted without UEFI: consumes DTB, accesses RTC directly
- kernel booted with UEFI, consumes DTB: UEFI owns RTC, kernel uses UEFI
services, UEFI keeps kernel from directly accessing the RTC by disabling
the RTC node in the DTB, using libfdt
- kernel booted with UEFI, consumes ACPI: UEFI owns RTC, kernel uses
UEFI services, UEFI keeps kernel from directly accessing the RTC by...,
well, it can't, because we don't *parse* AML in UEFI.
> Also I think if UEFI wants to take command of some of the
> hardware it ought to be UEFI's job to adjust the tables
> accordingly before it passes them on to the guest OS.
In theory, maybe.
In practice, no; we have the ACPI linker/loader for that. Either the
generated AML must not contain the RTC node, or else some linker/loader
script command(s) have to be added that cause the guest firmware's
linker/loader client to patch the device out. Generally speaking
however, the linker/loader can only patch data tables, not definition
You might ask why the DTB is different then. Why aren't I suggesting, in
paralle, that the DTB generator behave similarly in QEMU? The answer is
that the firmware needs the RTC node in the DTB for its *own* purposes
as well, so the RTC node must be in the DTB in any case.
ACPI is different. The firmware downloads it, patches it blindly (=
processes the linker/loader script), then passes it to the OS. That's all.
Formatting AML is doable in the firmware; parsing / modifying AML that
was originally generated by QEMU is practically impossible. If you
recall the *original* introducion of the ACPI interpreter into the
kernel -- there was a huge uproar. Today Linux has a customized version
of the ACPI CA framework. edk2 doesn't, and shouldn't.
Plus, *intelligently* modifying AML in the firmware defeats the purpose
of the ACPI linker/loader -- which is to allow the firmware to remain
ignorant about ACPI.