[Top][All Lists]
[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 14:56:04 +0300 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Stefan Hajnoczi, 2011/06/01
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Michael S. Tsirkin, 2011/06/01
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Paolo Bonzini, 2011/06/01
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Michael S. Tsirkin, 2011/06/01
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Paolo Bonzini, 2011/06/01
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Michael S. Tsirkin, 2011/06/01
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Avi Kivity, 2011/06/01
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Michael S. Tsirkin, 2011/06/02
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Avi Kivity, 2011/06/02
- Re: [Qemu-devel] virtio scsi host draft specification, v2,
Michael S. Tsirkin <=
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Avi Kivity, 2011/06/02
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Paolo Bonzini, 2011/06/01
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Michael S. Tsirkin, 2011/06/02
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Paolo Bonzini, 2011/06/02
- Re: [Qemu-devel] virtio scsi host draft specification, v2, Michael S. Tsirkin, 2011/06/02
Re: [Qemu-devel] virtio scsi host draft specification, v2, Avi Kivity, 2011/06/01