On Wed, Jul 11, 2012 at 05:27:08PM -0400, Shriram Rajagopalan wrote: > On Wed, Jul 11, 2012 at 4:45 PM, Konrad Rzeszutek Wilk < > konrad.wilk@xxxxxxxxxx> wrote: > > > Hey, > > > > There has been some discussion about EFI and SecureBoot and such. > > > > Most of the time I get questions in the form of "How do I get Fedora 17 > > with Xen to do EFI", I am going to concentrate on Fedora, but I think > > this applies to other distros too. > > > > From my reading (I hadn't actually tried EFI yet), there are two ways > > to bootup a system: > > > > - Using grub2.efi. Grub2 does the EFI API calls and calls the Xen > > hypervisor > > as if there were no EFI. This means no need for the EFI calls from > > Linux or Xen are required). > > > > > > - Using xen.efi. Xen can be built as a PE (Portable Executable) and it can > > boot as an EFI image. Naturally you also need to provide a configuration > > file and here are the details on it: > > http://xenbits.xen.org/docs/unstable/misc/efi.html > > > > And you would also need to configure the EFI nvram to execute xen.efi > > instead of grub2.efi. > > > > For the Linux side, the kernel needs to make new EFI variant hypercalls. > > Currently the SLES kernel is capable of it. The upstream Linux kernel > > cannot do it. There were patches proposed for it: > > http://lists.xen.org/archives/html/xen-devel/2012-02/msg02027.html > > > > > Does the Linux side dom0 kernel changes need to be done irrespective of the > two options above ? or does it apply only for booting with xen.efi ? I think the later only. Thought I am not sure how in the first case (GRUB2) how the E820 is made to be passed to the hypervisor kernel. > > 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? > 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. 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. > > 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? > > > 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 mailing list xen@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/xen
