xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Anthony PERARD <anthony.perard@citrix.com>, xen-devel@lists.xen.org
Subject: Re: [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.
Date: Tue, 3 Nov 2015 17:30:32 +0000	[thread overview]
Message-ID: <1446571832.16178.55.camel@citrix.com> (raw)
In-Reply-To: <1445875397-2846-1-git-send-email-anthony.perard@citrix.com>

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?

> 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

  parent reply	other threads:[~2015-11-03 17:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-26 16:03 [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader Anthony PERARD
2015-10-26 16:03 ` [RFC PATCH v2 01/16] hvmloader: Fix scratch_alloc to avoid overlaps Anthony PERARD
2015-11-03 17:38   ` Ian Campbell
2015-11-10 16:29   ` Jan Beulich
2015-10-26 16:03 ` [RFC PATCH v2 02/16] libxc: Load BIOS and ACPI table into guest memory Anthony PERARD
2015-11-03 17:45   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 03/16] configure: #define SEABIOS_PATH and OVMF_PATH Anthony PERARD
2015-11-04 10:24   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 04/16] firmware/makefile: install BIOS and ACPI blob Anthony PERARD
2015-11-04 10:35   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 05/16] libxl: Load guest BIOS from file Anthony PERARD
2015-11-04 10:51   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 06/16] libxl: Load guest ACPI table " Anthony PERARD
2015-11-04 10:57   ` Ian Campbell
2015-12-18 14:43     ` Anthony PERARD
2015-10-26 16:03 ` [RFC PATCH v2 07/16] hvmloader: Grab the hvmlite info page and parse the cmdline Anthony PERARD
2015-11-04 10:39   ` Andrew Cooper
2015-11-04 11:02   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 08/16] hvmloader: Locate the BIOS blob Anthony PERARD
2015-11-04 11:05   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 09/16] hvmloader: Load SeaBIOS from hvm_start_info modules Anthony PERARD
2015-11-04 11:11   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 10/16] hvmloader: Load OVMF from modules Anthony PERARD
2015-11-04 11:15   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 11/16] hvmloader: No BIOS ROM image allowed to be compiled in Anthony PERARD
2015-11-04 11:17   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 12/16] hvmloader: Load ACPI tables from hvm_start_info module Anthony PERARD
2015-11-04 11:20   ` Ian Campbell
2015-10-26 16:03 ` [RFC PATCH v2 13/16] hvmloader/makefile: Compile out SeaBIOS and OVMF ROM blob Anthony PERARD
2015-10-26 16:03 ` [RFC PATCH v2 14/16] hvmloader: Always build-in SeaBIOS and OVMF loader Anthony PERARD
2015-10-26 16:03 ` [RFC PATCH v2 15/16] hvmloader: Compile out the qemu-xen ACPI tables Anthony PERARD
2015-10-26 16:03 ` [RFC PATCH v2 16/16] hvmloader: do not depend on SEABIOS_PATH or OVMF_PATH Anthony PERARD
2015-11-03 17:30 ` Ian Campbell [this message]
2015-11-03 17:50   ` [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader Anthony PERARD
2015-11-04 10:18     ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1446571832.16178.55.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).