This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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 
by making that variable global. But for the RTC and set/get vars I am not

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

<Prev in Thread] Current Thread [Next in Thread>