Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant, Citrix Systems

16 views

Published on

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.

Published in: Software
  • Be the first to comment

  • Be the first to like this

XPDDS19: QEMU PV Backend 'qdevification'... What Does it Mean? - Paul Durrant, Citrix Systems

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

×