[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hello,

I didn't actually take notes, so this is from the top of my head. If
anyone took notes or remember something different, please feel free to
correct it.

This is the output from the PVH toolstack interface session. The
participants where: Ian Jackson, Wei Liu, George Dunlap, Vincent
Legout and myself.

We agreed on the following interface for xl configuration files:

    type = "hvm | pv | pvh"

This is going to supersede the "builder" option present in xl. Both
options are mutually exclusive. The "builder" option is going to be
marked as deprecated once the new "type" option is implemented.

In order to decide how to boot the guest the following options will be
available. Note that they are mutually exclusive.

    kernel = "<path>"
    ramdisk = "<path>"
    cmdline = "<string>"

<path>: relative or full path in the filesystem.

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"

This allows to load a firmware inside of the guest and run it in guest
mode. Note that the firmware needs to support booting in PVH mode.

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.

    bootloader = "pygrub"

Run a specific binary in the toolstack domain that's going to provide
a kernel, ramdisk and cmdline as output. This is mostly pygrub, that
accesses the guest disk image and extracts the kernel/ramdisk/cmdline
from it.

We also spoke about the libxl interface. This is going to require
changes to libxl_domain_build_info, which obviously need to be
performed in an API compatible way.

A new libxl_domain_type needs to be added (PVH) and the new "type"
config option is going to map to the "type" field in the
libxl_domain_create_info struct.

While looking at the contents of the libxl_domain_build_info we
realized that there was a bunch of duplication between the
domain-specific fields and the top level ones. Ie: there's a top level
"kernel" field and one inside of the pv nested structure. It would be
interesting to prevent adding a new pvh structure, and instead move
all the fields to the top level structure (libxl_domain_build_info).

I think that's all of it, as said in the beginning, if anything is
missing feel free to add it.

Regarding the implementation work itself, I'm currently quite busy
with other PVH stuff, so I would really appreciate if someone could
take care of this.

I think this should be merged in 4.10, so that the toolstack finally
has a stable interface to create PVH guests and we can start
announcing this. Without this work, even if the PVH DomU ABI is
stable, there's no way anyone is going to use it.

Thanks, Roger.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.