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

Re: [Xen-devel] Xen, Linux and EFI.



On Thu, Jul 12, 2012 at 9:31 AM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
>
> I spent a week trying to get Xen boot with grub2.efi (ubuntu 12.04).
> I ended up getting "Not enough memory to relocate domain 0".
>
> So I presume that the dom0 kernel EFI support needs to be done for both
> cases (grub2.efi and xen.efi) ?
>
>
> Additional info:
>  Hardware: IBM System X server.
>
>  It appeared that when booting xen under grub2.efi, xen was picking up a
> e-801 map

Huh. E801 is from the ancient days. I am a bit surprised that grub2.efi would
manufacture such ancient map.

So just to make sure I am not confused - you ran GRUB2 and ran with the
normal hypervisor and Linux kernel. What did you serial output look like?


Yes. 
I dont have the serial output now. I wiped out the server and installed
SLES 11 SP2 on it. :(


>  instead of the e-820 map that was on the system. I forced xen code to a
> multiboot
>  e-820 map instead of the native one ( based on a forum post I saw).
>  That didnt help much.

What does the memory map look like when you booted with GRUB2.efi + Linux.

Sorry. I dont have that info now, since I uninstalled ubuntu from it.

 
Was the memory map the same or different? I am trying to figure out if
the issue is that Xen needs extra code to deal with a GRUB2 manufactured
E801 map - and that the baremetal kernel already has such logic.


I do have the memory map when I forced xen to follow the multiboot-e820 logic.
I posted about this issue on xen-users.

The hack (patch) is available in the above post. The e820 map that xen saw was
(XEN) Multiboot-e820 RAM map:
(XEN)  0000000000000000 - 000000000006c000 (usable)
(XEN)  000000000006c000 - 000000000006d000 (ACPI NVS)
(XEN)  000000000006d000 - 000000000009f000 (usable)
(XEN)  000000000009f000 - 00000000000a0000 (ACPI NVS)
(XEN)  0000000000100000 - 000000007c11d000 (usable)
(XEN)  000000007c11d000 - 000000007ec92000 (reserved)
(XEN)  000000007ec92000 - 000000007f7bf000 (ACPI NVS)
(XEN)  000000007f7bf000 - 000000007f7ff000 (ACPI data)
(XEN)  000000007f7ff000 - 000000007f800000 (usable)
(XEN)  0000000080000000 - 0000000090000000 (reserved)
(XEN)  00000000fed1c000 - 00000000fed20000 (reserved)
(XEN)  00000000ff800000 - 0000000100000000 (reserved)
(XEN)  0000000100000000 - 0000001080000000 (usable)
(XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126]

The machine booted. But xen saw only one CPU out of 16.

FYI, I checked the memory map that xen sees now (xen 4.1.2 sles11sp2 version)
and its the same. Except the ACPI errors arent there. xen recognizes all 16 cpus.

 
>
> So I ended up booting with a SLES kernel. Not even sure if opensuse 12.1
> will work.

With what hypervisor? Same one you used when you tried GRUB2 with Xen earlier?
>

As stated above. SLES11 SP2. The hypervisor is the one that comes packaged in 
the distro xen 4.1.2_14-0.5.5 and the sles11 kernel 3.0.13-0.27-xen


>
>    which were mostly ports of how SLES did it (And they should reflect
> >    the proper ownership, which they don't have right now).
> >
> >    The EFI maintainer (Matthew) commented
> >    http://lists.xen.org/archives/html/xen-devel/2012-02/msg00815.html
> >    that he would like a better abstraction model for it. Mainly to
> >    push those calls deeper down (so introduce the registration in the
> >    the efi_calls). Or perhaps by providing in
> > boot_params.efi_info.efi_systab
> >    a finely crafted structure pointing to Linux functions that would
> >    do the hypercalls.
> >
> > And there you have it. In other words it needs somebody willing to
> > look at the patches as a baseline and do some exciting new work.
> > I sadly don't have right now the time to address this :-(
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> >


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

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