[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |