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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Jun 29, 2011 at 07:50:38AM +0100, Jan Beulich wrote:
> >>> On 28.06.11 at 19:03, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
> >>> wrote:
> > 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.
> 
> That's how it's supposed to be. If we find systems where it lives
> elsewhere, we'll have to add workarounds (in Xen).
> 
> >> 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.
> 
> No, Dom0 has to manage the RTC (and so it does today, at least
> in all non-pvops kernels I know of).

And it looks that the efi set/get vars are important for the efibootmgr, so
that, RTC, and ACPI RSDT pointer must be implemented somehow. The ACPI RSDT
can be potentially piggybacked 
http://marc.info/?i=E8CC3FDD41FF9Findou.takao@xxxxxxxxxxxxxx
by making that variable global. But for the RTC and set/get vars I am not
sure.

The good thing is that I finally got an EFI box so let me play with this.

On another topic - I saw you posted some patches upstream for EFI cleanup -
were you by any chance looking at implementing this in paravirt?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel