linux-kernel - Re: A set of "standard" virtual devices?

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]

Date:	Wed, 4 Apr 2007 15:11:41 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Virtualization Mailing List <virtualization@...ts.osdl.org>,
	Cornelia Huck <cornelia.huck@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	mathiasen@...il.com, virtualization@...ts.linux-foundation.org
Subject: Re: A set of "standard" virtual devices?

On Wednesday 04 April 2007, H. Peter Anvin wrote:
> Configuration space access is platform-dependent.  It's only defined to 
> work in a specific way on x86 platforms.
> 
> "Interrupt swizzling" is really totally independent of PCI.  ALL PCI 
> really provides is up to four interrupts per device (not counting 
> MSI/MSI-X) and an 8-bit writable field which the platform can choose to 
> use to hold interrupt information.  That's all.  The rest is all 
> platform information.
> 
> PCI enumeration is hardly complex.  Most of the stuff that doesn't apply 
> to you you can generally ignore, as is done by other busses like 
> HyperTransport when they emulate PCI.

You still don't get my point: On a platform that doesn't have interrupt
numbers, and where most of the fields in the config space don't correspond
do anything that is already there, you really don't want to invent
a set of new hcalls that implement emulation, to get something as
simple as a pipe.

wc drivers/pci/*.[ch] include/asm-i386/{pci,io}.h lib/iomap*.c \
	arch/i386/pci/*.c kernel/irq/*.c
17015  59037 463967 total

Even if you only need half of that code in reality, reimplementing
all that in both the kernel and in the hypervisor is an enourmous
effort. We've seen that before on the ps3, which initially faked
a virtual PCI bus just for the USB controller, but doing something
like that requires adding abstraction layers, to decide whether to
implement e.g. an inb as a hypercall or as a memory read.

> That being said, on platforms which are PCI-centric, such as x86, this 
> of course makes it a lot easier to produce virtual devices which work 
> across hypervisors, since the device model, of *any* operating system is 
> set up to handle them.

Yes, as I said there are two separate problems. I really think that
a standardized virtual driver interface should be modeled after
kernel <-> user interfaces, not hardware <-> kernel interfaces.

Once we know what operations we want (e.g. read, write and SIGIO,
or some other set of primitives), it will be good to provide a
virtual PCI device that can be used as one transport mechanism
below it. Using PCI device IDs to tell what functionality is
provided by the device would provide a reasonable method for
autoprobing.

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