linux-kernel - Re: Use of virtio device IDs

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: <4732D439.3020703@redhat.com>
Date:	Thu, 08 Nov 2007 10:17:45 +0100
From:	Gerd Hoffmann <kraxel@...hat.com>
To:	Avi Kivity <avi@...ranet.com>
CC:	Gregory Haskins <gregory.haskins.ml@...il.com>,
	Anthony Liguori <aliguori@...ibm.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Dor Laor <dor.laor@...ranet.com>,
	virtualization@...ts.linux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: Use of virtio device IDs

Avi Kivity wrote:
>> You are
>> probably better off designing something that is PV specific instead of
>> shoehorning it in to fit a different model (at least for the things I
>> have in mind).  
> 
> Well, if we design our pv devices to look like hardware, they will fit
> quite well.  Both to the guest OS and to user's expectations.

Disclaimer: Havn't looked at the virtio code much.

I think we should keep the door open for both models and don't nail the
 virtio infrastructure to one of them.

For pure pv devices I don't see the point in trying to squeeze it into
the PCI model.  Also s390 has no PCI, so there effecticely is no way
around that, we must be able have some pure virtual bus like xenbus.

IMHO the PCI model is most useful for emulated devices with a optional
pv path.  Say the usual emulated piix3 IDE controller, give it an
additional pv mode, so the guest can drive it in pv mode if it knows
about it, and use the generic piix ide driver if it doesn't.  That kind
of devices we probably want identify by pci subsystem id.

>> Its not a heck of a lot of code to write a pv-centric
>> version of these facilities.
> 
> It is.  Especially if you consider Windows and a gazillion versions of
> deployed, non-pv-capable Linux systems.  For pv-friendly newer Linux,
> it's probably doable, but why?
> 
> Look at the mess Xen finds itself in.

Uhm, well, yea.  Guess you are refering to the pv-on-hvm drivers.  Been
there, dealt with it.  What exactly do you think is messy there?

IMHO the most messy thing is the boot problem.  hvm bios can't deal with
pv disks, so you can't boot with pv disks only.  "fixed" by having the
(boot) disk twice in the system, once via emulated ide, once as pv disk.
 Ouch.

Other than that I don't see major problems with the virtual bus model.

> It's "necessary" in a pragmatic sense: we want to deliver drivers that
> provide features for a wide variety of guests in a reasonable
> timeframe.  And that means no rewriting guest OS infrastructure.

At least for any udev-based linux distro there is no need to rewrite any
guest os infrastructure.  Your virtual bus driver needs a proper uevent
callback, the virtual device drivers a module alias, and you are done.
udev autoloads your virtual device driver modules nicely, without any
distro tool hacking or config file writing ...

cheers,
  Gerd

-
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/