From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS6VB-0006Ek-Ov for qemu-devel@nongnu.org; Thu, 02 Jun 2011 07:55:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QS6V9-0005x6-VK for qemu-devel@nongnu.org; Thu, 02 Jun 2011 07:55:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS6V9-0005wz-ED for qemu-devel@nongnu.org; Thu, 02 Jun 2011 07:55:47 -0400 Date: Thu, 2 Jun 2011 14:56:04 +0300 From: "Michael S. Tsirkin" Message-ID: <20110602115604.GD7141@redhat.com> References: <4DD6246F.4080802@gnu.org> <20110601084922.GA5863@redhat.com> <4DE62992.9070705@redhat.com> <20110601125124.GB12294@redhat.com> <4DE63F3E.6040805@redhat.com> <20110601143619.GB14626@redhat.com> <4DE6520A.8080005@redhat.com> <20110602104226.GE7943@redhat.com> <4DE7773B.7060106@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE7773B.7060106@redhat.com> Subject: Re: [Qemu-devel] virtio scsi host draft specification, v2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Paolo Bonzini , qemu-devel , Stefan Hajnoczi On Thu, Jun 02, 2011 at 02:42:51PM +0300, Avi Kivity wrote: > On 06/02/2011 01:42 PM, Michael S. Tsirkin wrote: > >On Wed, Jun 01, 2011 at 05:51:54PM +0300, Avi Kivity wrote: > >> On 06/01/2011 05:36 PM, Michael S. Tsirkin wrote: > >> >> > >> >> So, if I am going to give this liberty with buffers to the driver, I > >> >> _have_ to keep the size information. Otherwise, I agree that it is > >> >> redundant and I will remove it. What poison do you prefer? > >> >> > >> > > >> >Ah, I think I understand now. Both sense and data have in > >> >fields that might only be used partially? > >> >In that case I think I agree: it's best to require the use of separate > >> >buffers for them, in this way used len will give you useful information > >> >and you won't need sense_len and data_len: just a flag to > >> >mark the fact that there *is* a sense buffer following. > >> >And the num field does that. > >> > >> > >> Do you mean to use the virtio iovec length to determine information > >> about the message (like splitting it into buffers)? > > > >Exactly the reverse :) > > They're both equally bad. > > >> I think that's a bad idea. Splitting into buffers is a function of > >> memory management. For example, a driver in userspace (or a nested > >> guest) will have additional fragmentation into 4K pages after it > >> passes through the iommu. > >> > >> Let's not mix layers here. > > > >Right. If there are two buffers of variable length there > >should be two add_buf calls. > > No. The guest should be free to use one large continuous buffer of > size N, of N buffers of size 1. That's exactly what I was saying. > -- > error compiling committee.c: too many arguments to function