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: <1228741409.3609.32.camel@blaa>
Date:	Mon, 08 Dec 2008 13:03:29 +0000
From:	Mark McLoughlin <markmc@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	kvm <kvm@...r.kernel.org>, Anthony Liguori <aliguori@...ibm.com>,
	Michael Tokarev <mjt@....msk.ru>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [PATCH] virtio: make PCI devices take a virtio_pci module ref

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. 

> But there really is no explicit dependency between virtio modules and
> virtio_pci.  There just is for kvm/x86 at the moment, since that is how
> they use virtio.  Running over another bus is certainly possible,
> though may never happen for x86 (happens today for s390).

Right, and in the case of both kvm/s390 and lguest the bus
implementation is built-in, not a module.

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/