linux-kernel - Re: vbus design points: shm and shm-signals

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: <4A92E3B1.5080002@codemonkey.ws>
Date:	Mon, 24 Aug 2009 14:02:09 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Gregory Haskins <gregory.haskins@...il.com>
CC:	alacrityvm-devel@...ts.sourceforge.net,
	Ingo Molnar <mingo@...e.hu>,
	Gregory Haskins <ghaskins@...ell.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: vbus design points: shm and shm-signals

Gregory Haskins wrote:
> Gregory Haskins wrote:
>   
>> Ingo Molnar wrote:
>>     
>>> We all love faster code and better management interfaces and tons 
>>> of your prior patches got accepted by Avi. This time you didnt even 
>>> _try_ to improve virtio.
>>>       
>> Im sorry, but you are mistaken:
>>
>> http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/02443.html
>>
>>     
>
> BTW: One point that I forgot to point out in this most recent thread
> that I am particularly proud of here is the design of the vbus
> shared-memory model.  Despite some claims to the contrary; not only is
> it possible to improve virtio with vbus (as evident by the patch
> referenced above)...I specifically designed vbus with virtio
> considerations in mind from the start!  In fact, the design is conducive
> to accelerating a variety of other models as well.  Read on for details.
>
> Vbus was designed it to be _agnostic_ to the shm algorithm in general.
> This allows you to, of course, run ring algorithms (such as virtqueues,
> or IOQs), but really any other designs as well, such as shared-tables, etc.
>
> A guest driver sees the following interface:
>
> struct vbus_device_proxy_ops {
> 	int (*open)(struct vbus_device_proxy *dev, int version, int flags);
> 	int (*close)(struct vbus_device_proxy *dev, int flags);
> 	int (*shm)(struct vbus_device_proxy *dev, int id, int prio,
> 		   void *ptr, size_t len,
> 		   struct shm_signal_desc *sigdesc, struct shm_signal **signal,
> 		   int flags);
> 	int (*call)(struct vbus_device_proxy *dev, u32 func,
> 		    void *data, size_t len, int flags);
> 	void (*release)(struct vbus_device_proxy *dev);
> };
>
> note the ops->shm() method.  This allows the driver to register some
> arbitrary pointer (ptr, len) with the host, optionally embedding a
> shm_signal_desc object in the memory.  If "sigdesc" is non-null, the
> connector will allocate and return a fully formed shm_signal object in
> **signal.
>   

Fundamentally, how is this different than the virtio->add_buf concept?

virtio provides a mechanism to register scatter/gather lists, associate 
a handle with them, and provides a mechanism for retrieving notification 
that the buffer has been processed.

vbus provides a mechanism to register a single buffer with an integer 
handle, priority, and a signaling mechanism.

So virtio provides builtin support for scatter/gathers whereas vbus 
models priority.  But fundamentally, they seem like almost identical 
concepts.

If we added priority to virtio->add_buf, would it be equivalent in your 
mind functionally speaking?

What does one do with priority, btw?

Is there something I'm overlooking?

Regards,

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