linux-kernel - Re: [RFC PATCH v2 00/19] virtual-bus

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:	Fri, 05 Jun 2009 10:44:40 -0400
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	Gregory Haskins <ghaskins@...ell.com>,
	"Michael S. Tsirkin" <mst@...hat.com>, Avi Kivity <avi@...hat.com>,
	linux-kernel@...r.kernel.org, agraf@...e.de, pmullaney@...ell.com,
	pmorreale@...ell.com, anthony@...emonkey.ws,
	netdev@...r.kernel.org, kvm@...r.kernel.org,
	bhutchings@...arflare.com, andi@...stfloor.org, gregkh@...e.de,
	herber@...dor.apana.org.au, chrisw@...s-sol.org,
	shemminger@...tta.com
Subject: Re: [RFC PATCH v2 00/19] virtual-bus

Rusty Russell wrote:
> On Fri, 5 Jun 2009 09:26:48 pm Gregory Haskins wrote:
>   
>> Hi Rusty,
>>
>> Rusty Russell wrote:
>>     
>>> On Fri, 5 Jun 2009 04:19:17 am Gregory Haskins wrote:
>>>       
>>>> Avi Kivity wrote:
>>>>         
>>>>> Gregory Haskins wrote:
>>>>> One idea is similar to signalfd() or eventfd()
>>>>>           
>>>> And thus the "kvm-eventfd" (irqfd/iosignalfd) interface project was
>>>> born. ;)
>>>>         
>>> The lguest patch queue already has such an interface :)
>>>       
>> Cool!  Ultimately I think it will be easier if both lguest+kvm support
>> the same eventfd notion so this is good you are already moving in the
>> same direction.
>>     
>
> Not really; lguest doesn't do PCI.
>   

Thats ok.  I see these eventfd interfaces as somewhat orthogonal to
PCI.  I.e. if both lguest and kvm have an eventfd mechnism for signaling
in both directions (e.g. interrupts and io), it would make it easier to
support the kind of thing I am striving for with a unified backend. 
That is: one in-kernel virtio-net that works in both (or even many) HV
environments.  I see that as a higher layer abstraction than PCI, per se.
>   
>>> And I have a partially complete in-kernel virtio_pci patch with the same
>>> trick.
>>>       
>> I thought lguest didn't use pci?  Or do you just mean that you have an
>> in-kernel virtio-net for lguest?
>>     
>
> No, this was for kvm.  Sorry for the confusion.
>   

Ah, sorry.  Well, if its in any kind of shape to see the light of day,
please forward it over.  Perhaps Michael and I can craft it into a
working solution.

>   
>> Other than the potential rcu issues that Paul already addressed, looks
>> good.  FWIW: this looks like what we are calling "iosignalfd" on the kvm
>> land (unless I am misunderstanding).  Do you have the equivalent of
>> "irqfd" going the other way?
>>     
>
> Yes; lguest uses write() (offset indicates cpu #) rather than ioctls, but 
> anyone can do the LHREQ_IRQ write to queue an interrupt for delivery.
>
> So the threads just get the same /dev/lguest fd and it's simple.
>   

Ah, ok.  Thats workable, too.  (This kind of detail would be buried in
the "lguest connector" for vbus anyway, so it doesn't have to have a
uniform "eventfd_signal()" interface to work.  The fd concept alone is
sufficiently flexible).

Thanks Rusty,
-Greg


Download attachment "signature.asc" of type "application/pgp-signature" (267 bytes)