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, 23 Dec 2009 16:58:37 -0600
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	"Ira W. Snyder" <iws@...o.caltech.edu>
CC:	Kyle Moffett <kyle@...fetthome.net>,
	Gregory Haskins <gregory.haskins@...il.com>,
	kvm@...r.kernel.org, netdev@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>,
	Avi Kivity <avi@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	torvalds@...ux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Alacrityvm-devel] [GIT PULL] AlacrityVM guest drivers for 2.6.33

On 12/23/2009 01:54 PM, Ira W. Snyder wrote:
> On Wed, Dec 23, 2009 at 09:09:21AM -0600, Anthony Liguori wrote:

> I didn't know you were interested in this as well. See my later reply to
> Kyle for a lot of code that I've written with this in mind.


BTW, in the future, please CC me or CC 
virtualization@...ts.linux-foundation.org.  Or certainly kvm@...r.  I 
never looked at the virtio-over-pci patchset although I've heard it 
referenced before.

>> But both virtio-lguest and virtio-s390 use in-band enumeration and
>> discovery since they do not have support for PCI on either platform.
>>
>
> I'm interested in the same thing, just over PCI. The only PCI agent
> systems I've used are not capable of manipulating the PCI configuration
> space in such a way that virtio-pci is usable on them.

virtio-pci is the wrong place to start if you want to use a PCI *device* 
as the virtio bus. virtio-pci is meant to use the PCI bus as the virtio 
bus.  That's a very important requirement for us because it maintains 
the relationship of each device looking like a normal PCI device.

> This means
> creating your own enumeration mechanism. Which sucks.

I don't think it sucks.  The idea is that we don't want to unnecessarily 
reinvent things.

Of course, the key feature of virtio is that it makes it possible for 
you to create your own enumeration mechanism if you're so inclined.

> See my virtio-phys
> code (http://www.mmarray.org/~iws/virtio-phys/) for an example of how I
> did it. It was modeled on lguest. Help is appreciated.

If it were me, I'd take a much different approach.  I would use a very 
simple device with a single transmit and receive queue.  I'd create a 
standard header, and the implement a command protocol on top of it. 
You'll be able to support zero copy I/O (although you'll have a fixed 
number of outstanding requests).  You would need a single large ring.

But then again, I have no idea what your requirements are.  You could 
probably get far treating the thing as a network device and just doing 
ATAoE or something like that.

Regards,

Anthony Liguori

> Ira

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ