Re: [Xen-devel] [RFC PATCH v2 00/16] Load BIOS via toolstack instead of been embedded in hvmloader.

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

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