XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant, Citrix Systems
Report
•1 like•457 views
XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant, Citrix Systems
•1 like•457 views
Download to read offline
Report
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.
Recommended
More Related Content
Similar to XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant, Citrix Systems
Similar to XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant, Citrix Systems(20)
More from The Linux Foundation
More from The Linux Foundation(20)
Recently uploaded
Recently uploaded(20)
XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant, Citrix Systems
- 1. QEMU PV Backend ‘qdevification’ What does it mean? Paul Durrant Senior Principal Software Engineer, Citrix Systems R&D 1
- 2. 2
- 4. Well, here’s the assertion... … but what are ‘qdev’ and ‘QOM’? 4
- 5. qdev 5
- 6. From Markus Armbruster’s 2010 KVM Forum presentation 6
- 7. 7
- 8. Each device is a child of a bus... 8
- 9. ...and may then be the parent of a lower level bus 9
- 11. From Paolo Bonzini’s 2014 KVM Forum presentation 11
- 12. Hierarchical namespace, but not the same as the qdev hierarchy 12
- 13. Back to PV backends... 13
- 14. So we do already have some form of qdev hierarchy... 14
- 16. So let’s see what we can do from the command line... 16
- 17. So let’s see what we can do from the command line... 17
- 18. So let’s see what we can do from the command line... This tells us the qdev hierarchy is there... 18
- 19. So let’s see what we can do from the command line... …but there appears to be no way to configure a backend... 19
- 20. So let’s see what we can do from the command line... …unlike other QEMU devices 20
- 21. So how do backends get created? 21
- 22. So how do backends get created? By open-coding parts of qdev_create() with information from... 22
- 23. So how do backends get created? ...Xenstore 23
- 24. So how do backends get created? This is why PV backends are ‘legacy’ 24
- 25. 25
- 26. So how about we do things properly? 26
- 27. 27
- 28. Firstly, move the old code out of the way... 28
- 29. ...then introduce a new qdev hierarchy 29
- 30. ...then introduce a new qdev hierarchy main-system-bus xen-bridge xen-bus xen-device 30
- 31. But what about configuring these? main-system-bus xen-bridge xen-bus xen-device 31
- 32. xen-device But there’s also a type hierarchy here... DeviceState XenDevice Increasing specialization 32
- 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
- 39. 39
- 40. Hang on… 40 What about the toolstack?
- 41. libxl still puts all of the configuration in xenstore 41
- 42. xen-bus also watches xenstore for new backends and calls registered create and destroy methods 42
- 43. QDict *opts xen_block_device_create() qmp_blockdev_add() qdev_create() qmp_object_add(TYPE_IOTHREAD, …) Create method uses dictionary of xenstore information to ‘fake’ QMP interactions 43
- 44. 44
- 45. 45 This is the generic xen-bus function noticing a new qdisk backend in xenstore
- 46. 46 This is the create method that xen- block registered
- 47. 47 And this is the create method calling blockdev_add
- 48. 48 Finally the device is ‘realized’ and the frontend and backend states are initialized
- 49. Next steps… ● Make other backends into xen-device-s ● Teach libxl how to create backends using QMP 49
- 50. Q & A 50