Clean up virtio device object handling [was Re: [PATCH] virtio: make PCI devices take a virtio_pci module ref]

Quoted 86 lines · Mark McLoughlin

Quoted 77 lines · Kay Sievers

Quoted 76 lines · Mark McLoughlin

Quoted 47 lines · Anthony Liguori

Quoted 46 lines · Mark McLoughlin

Quoted 13 lines · Rusty Russell

Quoted 11 lines · On Saturday 06 December 2008 01:37:06 Mark McLoughlin wrote:

Another example of a lack of an explicit dependency causing problems is Fedora's mkinitrd having this hack:

if echo $PWD | grep -q /virtio-pci/ ; then
findmodule virtio_pci
fi

which basically says "if this is a virtio device, don't forget to include virtio_pci in the initrd too!". Now, mkinitrd is full of hacks, but this is a particularly unusual one.

Quoted 6 lines

Um, I don't know what this does, sorry.

I have no idea how Fedora chooses what to put in an initrd; I can't think of a sensible way of deciding what goes in and what doesn't other than lists and heuristics.

Fedora's mkinitrd creates an initrd suitable to boot the machine you run mkinitrd on, rather than creating an initrd suitable to boot any machine.

So, it goes "ah, / is mounted from /dev/vda, we need to include virtio_blk and it's dependencies". It does that in a generic way that works well for most setups:

1) Find the device name (e.g. vda) below /sys/block

2) Follow the 'device' link to e.g. /sys/devices/virtio-pci/virtio1

3) Find the module need for this through either 'modalias' or the 'driver/module' symlink

4) Use modprobe to list any dependencies of that module

Clearly, virtio-pci won't be pulled in by any of this so we've added a hack to say "oh, it's a virtio device, let's include virtio_pci just in case".

It's not even the case that mkinitrd needs to know how to include the the module for the bus, because in our case that's virtio.ko ... we've pretty effectively hidden the the bus *implementation* from userspace.

Quoted 6 lines

Quoted 4 lines

I don't think this is worth wasting too much time fixing, that's why I'm thinking we should just make virtio_pci built-in by default with CONFIG_KVM_GUEST.

What if we have multiple virtio transports?

I don't think that's so much an an issue (just build in any transport supported by KVM), but rather that you might build a non-pv_ops kernel to run on QEMU which would benefit from using virtio drivers ...

Quoted 4 lines

Is there a way that we can
expose the relationship with virtio-blk and virtio-pci in sysfs? We have a struct device for the PCI device, it's just a matter of making the link visible.

It feels a bit like busy work to generalise this since only virtio_pci can be built as a module, but here's a patch.

The mkinitrd hack turns into:

# Handle finding virtio bus implementations if [ -L ./virtio_module ] ; then
findmodule $(basename $(readlink ./virtio_module))
else if echo $PWD | grep -q /virtio-pci/ ; then
findmodule virtio_pci
fi; fi

Quoted 4 lines

Quoted 1 line

[PATCH] virtio: add a 'virtio_module' sysfs symlink

Doesn't the device have a "driver" link already? If yes, the driver it points to should have a "module" link.

The virtio bus is an abstraction that has several different backend implementations - currently virtio-pci, lguest and kvm-s390.

Quoted 8 lines

So yes, the driver/module link gives us the device driver, but the virtio_module link is to the virtio bus driver (aka implementation, transport, backend, ...):

$> basename $(readlink virtio_module)
virtio_pci
$> basename $(readlink driver/module)
virtio_net

I see. But why not just call it "module", like we do in all other places, when it points to /sys/module/.

To find dependent modules, you would walk up the chain of parents, and include everything that is found by looking for "driver/module" and "module" links?

Wouldn't that make it completely generic, without any virtio specific hacks?