[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.
On Tue, Nov 03, 2015 at 05:30:32PM +0000, Ian Campbell wrote: > On Mon, 2015-10-26 at 16:03 +0000, Anthony PERARD wrote: > > Hi all, > > > > I've start to look at loading the BIOS and the ACPI tables via the > > toolstack instead of having them embedded in the hvmloader binary. After > > this patch series, hvmloader compilation would be indenpendant from > > SeaBIOS > > and OVMF compilation. > > > > Compare to the V1, this is now done via the struct hvm_start_info from > > Roger's patch series "Introduce HVM without dm and new boot ABI". > > Just to be clear, does this therefore requires the rest of (or some more > of) Roger's series to be applied or just the initial dozen patches which > are already in? The struct in introduced in this patch: <1443800943-17668-30-git-send-email-roger.pau@xxxxxxxxxx> [PATCH v7 29/32] libxc/xen: introduce a start info structure for HVMlite guests And is not yet applied, so yes, it does require the rest of the patch series, I have not look at which patches in particular. > > Here is a general view of the few step to load the BIOS: > > - libxl load the BIOS blob into it's memory and add it to struct > > xc_hvm_build_args.bios_module > > - libxc load the blob into the guest memory and fill the struct > > hvm_start_info, with a cmdline which would contain the order in which the > > modules (bios, acpi_table) are loaded into the modlist. > > - hvmloader read the addresses from the hvm_start_info, find out which > > module are which by reading the cmdline and copy the blob to the right > > place. > > Hrm, it's a shame that the mod list doesn't contain this information, > laundering it via a string cmdline seems a bit sub optimal. I haven't > looked yet but my intuition is that this will involve hvmloader doing some > string parsing, which I'm not keen on. > > Is the modlist a stable API (yet?) or can we extend it if we want? I'm not sure what could be added to it. An extra string that describe the module maybe? Or ... > Failing that perhaps hvmloader and libx? could collude such that the first > module is always some data structure (a private interface between hvmloader > and the tools) which describes the contents of the remaining modules? ... or we could have the modules been allocated in the same order, on a specific position. So BIOS always first, ACPI table always second ..., and if one is missing or not needed, replace it by a module of size 0. > > Right now, this patch series would only work for SeaBIOS and OVMF. I have > > not look into what to do about qemu-xen-traditionnal and rombios. > > FWIW I think it would be fine to leave those legacy components using the > existing mechanisms. No one in their right mind is going to want to use a > system supplied version of rambios... Or if they do then I think it is up > to them to patch it. (Unless actually doing this makes your life easier > somehow WRT your actual goal) I'll think about it. -- Anthony PERARD _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |