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

[Ian Campbell <ian.campbell@citrix.com>]

On Tue, 2015-11-03 at 17:50 +0000, Anthony PERARD wrote:
> 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@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