Re: [Xen-devel] [XenSummit 2017] Notes from the PVH toolstack interface session

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Andrew Cooper writes ("Re: [Xen-devel] [XenSummit 2017] Notes from the PVH 
toolstack interface session"):
> On 17/07/17 10:36, Roger Pau Monné wrote:
> >     kernel = "<path>"
> >     ramdisk = "<path>"
> >     cmdline = "<string>"
> >
> > <path>: relative or full path in the filesystem.
> 
> Please can xl or libxl's (not entirely sure which) path handling be
> fixed as part of this work.  As noted in
> http://xenbits.xen.org/docs/xtf/index.html#errata, path handling is
> inconsistent as to whether it allows paths relative to the .cfg file. 
> All paths should support being relative to the cfg file, as that is the
> most convenient for the end user to use.

Domain config files are conventionally in /etc.  It does not make
sense to look for images there.  OTOH there should be a way to specify
a path which is relative to xl's cwd at startup.  I wouldn't mind some
kind of magic token system either, eg kernel = "%cfgdir%/image" or
soemthing, if we can agree on a syntax.

> > Boot directly into the kernel/ramdisk provided. In this case the
> > kernel must be available somewhere in the toolstack filesystem
> > hierarchy.
> >
> >     firmware = "ovmf | uefi | bios | seabios | rombios | pvgrub"
> 
> What is the purpose of having uefi and bios in there?  ovmf is the uefi
> implementation, and {rom,sea}bios are the bios implementations.

See Roger's comments below.

> How does someone specify ovmf + seabios as a CSM?

EXPN CSM

> > There's no plan to support any bios or pvgrub ATM for PVH, those
> > options are simply listed for completeness. Also, generic options like
> > uefi or bios would be aliases to a concrete implementation by the
> > toolstack, ie: uefi -> ovmf, bios -> seabios most likely.
> 
> Oh - here is the reason.  -1 to this idea.  We don't want to explicitly
> let people choose options which are liable to change under their feet if
> they were to boot the same .cfg file on a newer version of Xen, as their
> VM will inevitable break.

Most VMs will not break simply if booted with a different BIOS.  Your
logic leads inevitably to the libvirt config files, which specify
things in far too much detail and cause lots of trouble.  They can be
un-portable to different versions of libvirt or qemu, let alone
different hypervisors.

> Instead of kernel= and ramdisk=, it would be better to generalise to
> something like modules=[...], perhaps with kernel being an alias for
> module[0] etc.  hvmloader already takes multiple binaries using the PVH
> module system, and PV guests are perfectly capable of multiple modules
> as well.  One specific example where an extra module would be very
> helpful is for providing the cloudinit install config file.

I don't think HVM guests can do direct boot of other than
kernel+ramdisk, can they ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel