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, 29 Jun 2011 06:00:18 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Hannes Reinecke <hare@...e.de>
Cc:	"Michael S. Tsirkin" <mst@...hat.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Linux Virtualization <virtualization@...ts.linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	qemu-devel <qemu-devel@...gnu.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
	Christoph Hellwig <chellwig@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: virtio scsi host draft specification, v3

On Tue, Jun 14, 2011 at 05:30:24PM +0200, Hannes Reinecke wrote:
> Which is exactly the problem I was referring to.
> When using more than one channel the request ordering
> _as seen by the initiator_ has to be preserved.
> 
> This is quite hard to do from a device's perspective;
> it might be able to process the requests _in the order_ they've
> arrived, but it won't be able to figure out the latency of each
> request, ie how it'll take the request to be delivered to the
> initiator.
> 
> What we need to do here is to ensure that virtio will deliver
> the requests in-order across all virtqueues. Not sure whether it
> does this already.

This only matters for ordered tags, or implicit or explicit HEAD OF
QUEUE tags.  For everything else there's no ordering requirement.
Given that ordered tags don't matter in practice and we don't have
to support them this just leaves HEAD OF QUEUE.  I suspect the
HEAD OF QUEUE semantics need to be implemented using underlying
draining of all queues, which should be okay given that it's
usually used in slow path commands.

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