On 10/09/15 13:05, Roger Pau Monné wrote: > El 10/09/15 a les 13.48, Julien Grall ha escrit: >> On 10/09/15 12:32, Andrew Turner wrote: >>> On Thu, 10 Sep 2015 16:41:56 +0800 >>> Shannon Zhao <zhaoshenglong@xxxxxxxxxx> wrote: >>> >>>> From: Shannon Zhao <shannon.zhao@xxxxxxxxxx> >>>> >>>> These EFI stub parameters are used to internal communication between >>>> EFI stub and Linux kernel and EFI stub creates these parameters. But >>>> for Xen on ARM when booting with UEFI, Xen will create a minimal DT >>>> providing these parameters for Dom0 and Dom0 is not only Linux >>>> kernel, but also other OS (such as FreeBSD) which will be used in the >>>> future. So here we plan to standardize the names by dropping the >>>> prefix "linux," and make them common to other OS. Also this will not >>>> break the compatibility since these parameters are used to internal >>>> communication between EFI stub and kernel. >>> >>> It is unlikely FreeBSD will use this property when booting ad Xen dom0. >>> The kernel expects to be passed a data structure to find boot this >>> information. >>> >>> My preference would be to have the FreeBSD loader load the xen binary, >>> the FreeBSD kernel, and set up these data structs before passing >>> control to Xen, with the information it needs to boot the kernel. My >>> understanding is this is how it is done on x86. >> >> Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are >> faking a multiboot module which contains all the informations. >> >> I know that the bootloader is at least involved, I don't remember if >> there is some code in FreeBSD to read this boot module. I've CCed Roger >> to confirm. > > The metadata/modules needed by the FreeBSD Dom0 kernel is generated by > the native FreeBSD bootloader (as would be done when booting bare > metal). Then this blob is passed as a multiboot module in the same place > that Linux puts it's initramfs. Xen simply copies this blob straight > into guest memory and sets start_info.mod_start to point to the start > memory address of this blob. > > I've done it this way because I don't see many other options. Xen is > tailored for Linux and only allows passing one module to the Dom0 kernel > (initramfs). For FreeBSD it would be good to be able to pass at least > two modules to the Dom0 kernel, one containing the metadata, and the > other one containing the modules themselves. The new PVH work (HVMlite > or whatever) will hopefully allow passing more than one module to the > Dom0 kernel, and should make the code in the FreeBSD loader simpler. We have a multiboot based on device tree to boot Xen on ARM [1]. It may be possible to create another kind of module storing the FreeBSD metadata and make a trampoline for Xen in FreeBSD to pass the information correctly to the DOM0 kernel. But the main problem is we have to modify those metadata because, AFAICT, the device tree/ACPI blob is part of them. It also seems to be the same for UEFI. That means we need some knowledge in Xen to parse/modify those metadata. Unless they are stable (i.e clearly defined, not changing, place in memory known...), we can't use them in Xen as we would need to adapt for every changes. If it's stable, we have to know that we are using FreeBSD (could be done with the multiboot string). Although, I would be more in favor of the loader using the Xen boot interface with a new multiboot module, Xen jumping on a trampoline in the FreeBSD kernel still using the Guest Boot ABI (similar the the Linux ABI). The trampoline would recreate the metadata with the new DT and jump into the kernel. I will give a look to this when I'm done with the FreeBSD ARM guest support. Regards, [1] http://xenbits.xen.org/docs/unstable/misc/arm/device-tree/booting.txt -- Julien Grall -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
