Re: [PATCH 3/4] x86-64: EFI runtime code

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

> > I see the need for the VGA console, and that looks easy enough.
> 
> There's no VGA console in modern UEFI, you only get a graphical
> one (with no guarantee that it's VGA).

I meant that the "struct screen_info *screen_info" needs to be populated
properly in the Linux side. And for that we just need to take care of the
extra new XEN_VGATYPE..EFI type.

> > The other information Dom0 needs is the ACPI DSDT to figure out the polarity
> > and trigger for the interrupts. Is the ACPI DSDT "lost" when it is running 
> > from EFI?
> 
> No, but it can't be retrieved the "traditional" way.
.. snip..
> No - ACPI is all the same except for the mechanism to retrieve the
> root pointer.

Ah, here it is: "acpi_os_get_root_pointer" uses the efi.acpi20 or
efi.acpi and the DMI scan uses efi.smbios.

And those physical addresses reside within a reserved E820 region or
a gap I hope.

> > I am just wondering whether Dom0 actually needs to know that EFI exists.
> 
> Yes, it needs to, due to the table pointer retrieval differences. And
> then there's the runtime services (RTC access, EFI variables) that
> the OS ought to use. On the RTC side of things, a legacy free system

I am just looking at the minimal to understand it.
> might not have a CMOS clock, and hence even native Linux is currently
> broken in that respect (because the driver can be built only for IA64).

We do switch to the Xen clock (which is to say that the hypervisor is
responsible for it) ... so I think we could skip the RTC in the Linux kernel.