qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] virtio scsi host draft specification, v2


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] virtio scsi host draft specification, v2
Date: Thu, 2 Jun 2011 13:42:26 +0300
User-agent: Mutt/1.5.21 (2010-09-15)

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 :)

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

> -- 
> error compiling committee.c: too many arguments to function



reply via email to

[Prev in Thread] Current Thread [Next in Thread]