Re: [Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.
On Tue, 2015-11-03 at 17:50 +, Anthony PERARD wrote: > On Tue, Nov 03, 2015 at 05:30:32PM +, Ian Campbell wrote: > > On Mon, 2015-10-26 at 16:03 +, 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@citrix.com> > [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. OK, I'll keep it in mind and not try to apply this one if it ends up ready first. > > > 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 ... I should have CCd Roger, now done. I think this new interface (is going to) form part of the PVH boot ABI, which is currently not formally stabilised but it means any semantics we choose to give it need to be considered in that light and not just in the "internal between tools and hvmloader" one. I'm not sure what this means for adding a type to it, but on first glance that seems like an "internal between tools and hvmloader" thing not a public ABI thing. > > 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. Since this would be an "internal interface" I think we could do, although it might be more convenient for developers trying to change this in the future to include a little more flexibility? (e.g. co-bisection of tools and hvmloader over a change to the list ordering) In the end if this is an "internal interface" I suppose it doesn't matter too much what colour we paint it to start with. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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 +, Ian Campbell wrote: > On Mon, 2015-10-26 at 16:03 +, 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@citrix.com> [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@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.
On Mon, 2015-10-26 at 16:03 +, 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? > 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? 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? > 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) > > A git tree can be found here: > git://xenbits.xen.org/people/aperard/xen-unstable.git > tag: hvmloader-with-separated-bios-v2 > > Regards, > > Anthony PERARD (16): > hvmloader: Fix scratch_alloc to avoid overlaps > libxc: Load BIOS and ACPI table into guest memory > configure: #define SEABIOS_PATH and OVMF_PATH > firmware/makefile: install BIOS and ACPI blob ... > libxl: Load guest BIOS from file > libxl: Load guest ACPI table from file > hvmloader: Grab the hvmlite info page and parse the cmdline > hvmloader: Locate the BIOS blob > hvmloader: Load SeaBIOS from hvm_start_info modules ... > hvmloader: Load OVMF from modules > hvmloader: No BIOS ROM image allowed to be compiled in > hvmloader: Load ACPI tables from hvm_start_info module > hvmloader/makefile: Compile out SeaBIOS and OVMF ROM blob > hvmloader: Always build-in SeaBIOS and OVMF loader > hvmloader: Compile out the qemu-xen ACPI tables > hvmloader: do not depend on SEABIOS_PATH or OVMF_PATH ... > > .gitignore | 1 + > tools/configure.ac | 12 +++- > tools/firmware/Makefile| 15 ++-- > tools/firmware/hvmloader/Makefile | 32 - > tools/firmware/hvmloader/acpi/Makefile | 8 ++- > tools/firmware/hvmloader/config.h | 11 +-- > tools/firmware/hvmloader/hvmloader.c | 127 > - > tools/firmware/hvmloader/ovmf.c| 34 - > tools/firmware/hvmloader/seabios.c | 33 - > tools/firmware/hvmloader/util.c| 2 +- > tools/libxc/include/xc_dom.h | 4 ++ > tools/libxc/xc_dom_hvmloader.c | 44 +--- > tools/libxc/xc_dom_x86.c | 90 +++ > tools/libxl/libxl_dom.c| 83 + > tools/libxl/libxl_types.idl| 2 + > tools/libxl/xl_cmdimpl.c | 14 +++- > 16 files changed, 394 insertions(+), 118 deletions(-) > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.
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". 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. 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. A git tree can be found here: git://xenbits.xen.org/people/aperard/xen-unstable.git tag: hvmloader-with-separated-bios-v2 Regards, Anthony PERARD (16): hvmloader: Fix scratch_alloc to avoid overlaps libxc: Load BIOS and ACPI table into guest memory configure: #define SEABIOS_PATH and OVMF_PATH firmware/makefile: install BIOS and ACPI blob ... libxl: Load guest BIOS from file libxl: Load guest ACPI table from file hvmloader: Grab the hvmlite info page and parse the cmdline hvmloader: Locate the BIOS blob hvmloader: Load SeaBIOS from hvm_start_info modules ... hvmloader: Load OVMF from modules hvmloader: No BIOS ROM image allowed to be compiled in hvmloader: Load ACPI tables from hvm_start_info module hvmloader/makefile: Compile out SeaBIOS and OVMF ROM blob hvmloader: Always build-in SeaBIOS and OVMF loader hvmloader: Compile out the qemu-xen ACPI tables hvmloader: do not depend on SEABIOS_PATH or OVMF_PATH ... .gitignore | 1 + tools/configure.ac | 12 +++- tools/firmware/Makefile| 15 ++-- tools/firmware/hvmloader/Makefile | 32 - tools/firmware/hvmloader/acpi/Makefile | 8 ++- tools/firmware/hvmloader/config.h | 11 +-- tools/firmware/hvmloader/hvmloader.c | 127 - tools/firmware/hvmloader/ovmf.c| 34 - tools/firmware/hvmloader/seabios.c | 33 - tools/firmware/hvmloader/util.c| 2 +- tools/libxc/include/xc_dom.h | 4 ++ tools/libxc/xc_dom_hvmloader.c | 44 +--- tools/libxc/xc_dom_x86.c | 90 +++ tools/libxl/libxl_dom.c| 83 + tools/libxl/libxl_types.idl| 2 + tools/libxl/xl_cmdimpl.c | 14 +++- 16 files changed, 394 insertions(+), 118 deletions(-) -- Anthony PERARD ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
