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
|
Home