For many years the QEMU codebase has contained PV backends for Xen guests, giving them paravirtual access to storage, network, keyboard, mouse, etc. however these backends have not been configurable as QEMU devices as their implementation did not fully adhere to the QEMU Object Model (QOM).
Particularly the PV storage backend not using proper QOM devices, or qdevs, meant that the QEMU block layer needed to maintain legacy code that was cluttering up the source. This was causing push-back from the maintainers who did not want to accept any patches relating to that Xen backend until it was 'qdevified'.
In this talk, I'll explain the modifications I made to QEMU to achieve 'qdevification' of the PV storage backend, how compatibility with the libxl toolstack was maintained, and what the next steps in both QEMU and libxl development should be.
Report
Share
Report
Share
1 of 50
Download to read offline
More Related Content
XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant, Citrix Systems
33. ...which means the patch can now add
‘proper’ xen-disk and xen-cdrom devices
DeviceState
XenDevice
XenBlockDevice
XenDiskDevice
DeviceState
XenDevice
XenBlockDevice
XenCdromDevice
33
34. So let’s see what we can do from the command line now...
34
35. So let’s see what we can do from the command line now...
35
36. So let’s see what we can do from the command line now...
Abstract device types are in the
hierarchy but cannot be instantiated
36
37. So let’s see what we can do from the command line now...
These properties are largely common
to the xen-block type...
37
38. So let’s see what we can do from the command line now...
...except this which
is actually common
to the xen-device
type
38