On 01/07/16 10:31, Shannon Zhao wrote:
>
>
> On 2016/1/7 16:16, Ard Biesheuvel wrote:
>> On 7 January 2016 at 03:47, Shannon Zhao <zhaoshengl...@huawei.com> wrote:
>>>> Hi,
>>>>
>>>> I notice that when booting with DTS UEFI will disable RTC device PL031
>>>> in the DTS by following codes. And it turns out that only rtc-efi shows
>>>> up in guest.
>>>>
>>>> //
>>>> // UEFI takes ownership of the RTC hardware, and exposes its functionality
>>>> // through the UEFI Runtime Services GetTime, SetTime, etc. This means we
>>>> // need to disable it in the device tree to prevent the OS from
>>>> attaching its
>>>> // device driver as well.
>>>> //
>>>> if ((RtcNode != -1) &&
>>>> fdt_setprop_string (DeviceTreeBase, RtcNode, "status",
>>>> "disabled") != 0) {
>>>> DEBUG ((EFI_D_WARN, "Failed to set PL031 status to 'disabled'\n"));
>>>> }
>>>>
>>>> But when booting with ACPI, there are two RTC devices, rtc-efi and
>>>> PL031(PL031 shows up when kenrel PL031 driver adds support to probe it
>>>> via ACPI). And I didn't see any codes in UEFI to handle the RTC node in
>>>> ACPI table.
>>>>
>>>> I think it's hard to modify the DSDT table in UEFI since there is not a
>>>> ACPI lib like libfdt. But for consistency, does it need to handle it too
>>>> when booting with ACPI?
>>>>
>> Yes, it should. I didn't spot this before, or I would have said something.
>>
>> As long as the firmware is driving the RTC, the OS should not be able
>> to attach its driver directly, ACPI or DT alike.
>
> Is there a way to parse DSDT in UEFI or other ways we could use to mask
> the RTC device? I think maybe we could use the STAO table or something
> like it which is added by ACPI 6.0.
Let's see what ways there are for booting an ARM / AARCH64 guest
("virt") machine type:
(1) QEMU's builtin (minimal) firmware, and nothing else. There is
nothing to *consume* ACPI.
(2) QEMU's builtin (minimal) firmware, and a directly booted kernel
(-kernel option). The kernel gets only a DTB -- there is no
architecturally defined way to expose ACPI to the kernel.
(3) explicit firmware (-bios or -pflash option), and whatever gets
booted by the firmware. Firmware here means UEFI, period. The guest OS
gets both DTB and ACPI (unless disabled by -no-acpi).
(4) explicit firmware (-bios or -pflash opton) plus an immediately
booted fw_cfg kernel (i.e. -kernel option as well). Firmware again means
UEFI, the guest OS gets again both DTB and ACPI (unless disabled by
-no-acpi).
So here's what I suggest:
- modify QEMU to drop the RTC device specification from *both* the DTB
and the ACPI generator *if* an explicit firmware is passed (with -bios
or -pflash). Because this means UEFI, and UEFI will take control of the
RTC. Cases (1) and (2) are unaffected, and cases (3) and (4) are handled
correctly.
- modify ArmVirtPkg to remove the above quoted disabling -- QEMU should
handle it for the DTB as well.
See QEMU commit 07abe45c4814, and the "arm_boot_info.firmware_loaded"
field -- that could be used to control the DTB and ACPI generators.
Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
