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:	Mon, 24 Feb 2014 11:23:43 +0100
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	"Nicholas A. Bellinger" <nab@...erainc.com>,
	target-devel <target-devel@...r.kernel.org>
CC:	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	kvm-devel <kvm@...r.kernel.org>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
	Sagi Grimberg <sagig@...lanox.com>,
	Nicholas Bellinger <nab@...ux-iscsi.org>
Subject: Re: [RFC 0/6] vhost/scsi: Add T10 PI SGL passthrough support

Il 24/02/2014 06:32, Nicholas A. Bellinger ha scritto:
> AFAICT up until this point the ->prio field has been unused, but
> I'm certainly open to better ways of signaling (to vhost) that some
> number of metadata iovs are to be expected..  Any thoughts..?

Hi nab,

the virtio-scsi side of the patch is nice and readable.  As requested, 
here are my thoughts on how to add it to the standard.

The ->prio field is there to mimic SAM's command priority field (8.7 in 
my copy of the standard).  I'd rather leave it alone; I understand this 
is the main reason why this patch is RFC.

Since we have a new feature bit, we can add a new element before the 
cdb.  It could be a count of scatter/gather list like you did here, or 
it could be a byte count.  Even better, we can add _two_ new fields, one 
for protection data out and one for protection data in.

Also, do we need an equivalent of the residual field, but for metadata?

Finally, any reason why you put the data sg elements before the metadata 
sg elements?  I would have thought that processing is a bit simpler if 
either the metadata comes first, or you store in the command header the 
data count (either sg or byte).  Because the virtio buffers form a 
linked list, it's a bit backwards to put metadata last, and store 
metadata count in the command header; it prevents you from processing 
the buffers online because you don't know when the metadata starts. 
Even though the Linux virtio layer always gives you a buffer count, this 
need not be the case in general.

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