linux-kernel - Re: [PATCH] virtio: make PCI devices take a virtio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1228902558.5384.19.camel@blaa>
Date:	Wed, 10 Dec 2008 09:49:18 +0000
From:	Mark McLoughlin <markmc@...hat.com>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Anthony Liguori <aliguori@...ibm.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	kvm <kvm@...r.kernel.org>, Michael Tokarev <mjt@....msk.ru>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH] virtio: make PCI devices take a virtio_pci module ref

On Tue, 2008-12-09 at 19:16 +0100, Kay Sievers wrote:
> On Tue, Dec 9, 2008 at 17:41, Mark McLoughlin <markmc@...hat.com> wrote:
> > On Mon, 2008-12-08 at 08:46 -0600, Anthony Liguori wrote:
> >> Mark McLoughlin wrote:
> >> > On Sun, 2008-12-07 at 18:52 +1030, Rusty Russell wrote:
> >> >> 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.
> >> >>>
> >> >> 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.
> >> >
> >> > 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 ...
> >
> >>   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
> >
> > Cheers,
> > Mark.
> >
> > [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.

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

Cheers,
Mark.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/