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@lists.xen.org https://lists.xen.org/xen-devel