netdev - Re: [PATCH 0/3] virtio-net: inline header support

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: <5073D1D8.3060905@redhat.com>
Date:	Tue, 09 Oct 2012 09:27:20 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Rusty Russell <rusty@...tcorp.com.au>
CC:	kvm@...r.kernel.org, "Michael S. Tsirkin" <mst@...hat.com>,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Sasha Levin <levinsasha928@...il.com>,
	virtualization@...ts.linux-foundation.org,
	Thomas Lendacky <tahm@...ux.vnet.ibm.com>, avi@...hat.com
Subject: Re: [PATCH 0/3] virtio-net: inline header support

Il 09/10/2012 06:59, Rusty Russell ha scritto:
> Paolo Bonzini <pbonzini@...hat.com> writes:
>> Il 05/10/2012 07:43, Rusty Russell ha scritto:
>>> That's good.  But virtio_blk's scsi command is insoluble AFAICT.  As I
>>> said to Anthony, the best rules are "always" and "never", so I'd really
>>> rather not have to grandfather that in.
>>
>> It is, but we can add a rule that if the (transport) flag
>> VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in
>> virtio-blk.
> 
> Could we do that?  It's the cmd length I'm concerned about; is it always
> 32 in practice for some reason?

It is always 32 or less except in very obscure cases that are pretty
much confined to iSCSI.  We don't care about the obscure cases, and the
extra bytes don't hurt.

BTW, 32 is the default cdb_size used by virtio-scsi.

> Currently qemu does:
> 
>     struct sg_io_hdr hdr;
>     memset(&hdr, 0, sizeof(struct sg_io_hdr));
>     hdr.interface_id = 'S';
>     hdr.cmd_len = req->elem.out_sg[1].iov_len;
>     hdr.cmdp = req->elem.out_sg[1].iov_base;
>     hdr.dxfer_len = 0;
> 
> If it's a command which expects more output data, there's no way to
> guess where the boundary is between that command and the data.

Yep, so I understood the problem right.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html