From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmkUf-0008Q3-Tp for qemu-devel@nongnu.org; Mon, 27 Apr 2015 10:58:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YmkUb-0002zQ-T3 for qemu-devel@nongnu.org; Mon, 27 Apr 2015 10:58:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YmkUb-0002zK-O9 for qemu-devel@nongnu.org; Mon, 27 Apr 2015 10:58:41 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 51425A10CA for ; Mon, 27 Apr 2015 14:58:41 +0000 (UTC) Message-ID: <553E4E9D.6020502@redhat.com> Date: Mon, 27 Apr 2015 16:58:37 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1430144304-13514-1-git-send-email-mst@redhat.com> <553E469F.1000605@redhat.com> <20150427163730-mutt-send-email-mst@redhat.com> In-Reply-To: <20150427163730-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC] virtio: add virtqueue_fill_partial List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org On 27/04/2015 16:38, Michael S. Tsirkin wrote: > > "If you never leave holes unwritten in the iov, use virtqueue_fill > > instead. >=20 > Is it just holes? Never data you are unsure about? Then "unwritten (or possibly unwritten)"? If the data you are unsure is at the end, it's okay. This is what virtio-scsi does when it has a failure (the "!=3D VIRTIO_SCSI_S_OK" case)= . > > If the guest is not relying on iov boundaries, it should never > > be necessary to use this function." >=20 > You never know what guest does though, do you? I think that this sentence is wrong, but only because you cannot know the format of _all_ request headers/footers and thus it's wrong to make such a sweeping generalization. Anyhow, I'll describe what I had in mind. Consider the case I gave before, where you have a 1 sector (512-bytes) read. Consider now two guests, both of them passing 2049 bytes for the device-writable area. Guest 1 doesn't have anylayout; it placed 2048 bytes in iovec 0 and 1 byte in iovec 1. The device thus has to write bytes 0-511 and byte 2048. In this case host_len =3D 2049, guest_len =3D 512. Guest 2 has anylayout (or uses virtio v1). It placed 2048 bytes in iovec 0 and 1 byte in iovec 1. The device however "knows" that the read is just 512 bytes in length; it writes bytes 0-512 (the last byte is the status) and ignores bytes 513-2048. In this case host_len =3D guest_len = =3D 513. However, there could be a legitimate reason for a device to leave some bytes uninitialized in the middle, possibly for optimization reasons. In this case, you might have to use virtqueue_fill_partial. ... Oh wait, that's exactly what happens with virtio-scsi! sense_len in the response header is usually zero, and in that case we don't write the sense[] array. So, I guess virtio-scsi in the common case should return just the offset up to sense_len? Paolo