| Design document | |
|---|---|
| Revision | v1 |
| Status | proposed |
| Review | create new issue |
Xen’s ioreq-server feature allows for several device emulator
processes to be attached to the same domain, each emulating different
sets of virtual hardware. This makes it possible, for example, to
emulate network devices in a separate process for improved security
and isolation, or to provide special purpose emulators for particular
virtual hardware devices.
ioreq-server is currently used in XenServer to support vGPU, where it
is configured via the legacy toolstack interface. These changes will make
multiple emulators usable in open source Xen via the new libxl interface.
The singleton device_model_version, device_model_stubdomain and device_model fields in the b_info structure will be replaced by a list of (version, stubdomain, model, arguments) tuples, one for each emulator.
libxl_domain_create_new() will be changed to spawn a new device model for each entry in the list.
It may also be useful to spawn the device models separately and only
attach them during domain creation. This could be supported by
making each device_model entry a union of pid | parameter_tuple.
If such an entry specifies a parameter tuple, it is processed as above;
if it specifies a pid, libxl_domain_create_new(), the existing device
model with that pid is attached instead.
Patches to make QEMU register with Xen as an ioreq-server have been submitted upstream, but not yet applied.
QEMU’s --machine none and --nodefaults options should make it
possible to create an empty machine and add just a host bus, PCI bus
and device. This has not yet been fully demonstrated, so QEMU changes
may be required.
ioreq-server has only been used to connect one extra
device model, in addition to the default one. Multiple emulators
should work, but there is a chance that bugs will be discovered.This functionality will only be available through the experimental Xenlight-based xenopsd.
VM_build clause in the atomics_of_operation function will be
changed to fill in the list of emulators to be created (or attached)
in the b_info structvGPU support is implemented mostly in xenopsd, so no Xapi changes are required to support vGPU through the generic device model mechanism. Changes would be required if we decided to expose the additional device models through the API, but in the near future it is more likely that any additional device models will be dealt with entirely by xenopsd.