|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] virtio scsi host draft specification, v2 |
Date: | Thu, 02 Jun 2011 14:42:51 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Lightning/1.0b3pre Thunderbird/3.1.10 |
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.
-- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |