Re: [Qemu-arm] [PATCH] ARM: Virt: Don't generate RTC ACPI node when using UEFI

[Laszlo Ersek]

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?

Yes.

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
blocks (AML).

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.

Thanks
Laszlo