1.
QEMU PV Backend
‘qdevification’
What does it mean?
Paul Durrant
Senior Principal Software Engineer,
Citrix Systems R&D
1

2.
2

3.
Well, here’s the
assertion...
3

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

10.
QOM
10
QEMU Object Model

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

15.
main-system-bus
xen-sysdev
xen-sysbus
xen-backend
15

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