[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.