Linux Virtualization - Jul 2013 - [PATCH] virtio-spec: add field for scsi command size

Il 01/07/2013 01:47, Rusty Russell ha scritto:
> > > 
> > > Mainly because I'm not sure that *all* devices are now safe. 
Are they?
> >
> > virtio-scsi's implementation in QEMU is not safe (been delaying
that for
> > too long, sorry), but the spec is safe.
> 
> Then if we added a transport feature, we couldn't use it :(
Transport feature bits are still negotiated per device though.
virtio-scsi devices in QEMU would not negotiate that feature.

Paolo
> So I think it needs to be a per-device feature bit.

Paolo Bonzini <pbonzini at redhat.com> writes:
> Il 01/07/2013 01:47, Rusty Russell ha scritto:
>> > > 
>> > > Mainly because I'm not sure that *all* devices are now
safe.  Are they?
>> >
>> > virtio-scsi's implementation in QEMU is not safe (been
delaying that for
>> > too long, sorry), but the spec is safe.
>> 
>> Then if we added a transport feature, we couldn't use it :(
>
> Transport feature bits are still negotiated per device though.
> virtio-scsi devices in QEMU would not negotiate that feature.
That's a good point; I tend to think of them as tied to the transport
but there's nothing specifying that, nor any implementation requiring
it.

OK, so VIRTIO_F_ANY_LAYOUT it is?

Cheers,
Rusty.

Message Framing
 
The original intent of the specification was that message framing 
(the particular layout of descriptors) be independent of the 
contents of the buffers. For example, a network transmit buffer 
consists of a 12 byte header followed by the network packet. This 
could be most simply placed in the descriptor table as a 12 byte 
output descriptor followed by a 1514 byte output descriptor, but 
it could also consist of a single 1526 byte output descriptor in 
the case where the header and packet are adjacent, or even three 
or more descriptors (possibly with loss of efficiency in that 
case).

Regrettably, initial driver implementations used simple layouts
and devices came to rely on it, despite this specification 
wording. It is thus recommended that drivers be conservative in 
their assumptions, unless specific device features indicate that 
general layout is permitted using VIRTIO_F_ANY_LAYOUT. In
addition, some implementations may have large-but-reasonable
restrictions on total descriptor size (such as based on IOV_MAX
in the host OS). This has not been a problem in practice: little
sympathy will be given to drivers which create unreasonably-sized
descriptors such as dividing a network packet into 1500
single-byte descriptors!

On Mon, Jul 01, 2013 at 01:57:44PM +0200, Paolo Bonzini
wrote:
> Il 01/07/2013 01:47, Rusty Russell ha scritto:
> > > > 
> > > > Mainly because I'm not sure that *all* devices are now
safe.  Are they?
> > >
> > > virtio-scsi's implementation in QEMU is not safe (been
delaying that for
> > > too long, sorry), but the spec is safe.
> > 
> > Then if we added a transport feature, we couldn't use it :(
> 
> Transport feature bits are still negotiated per device though.
> virtio-scsi devices in QEMU would not negotiate that feature.
> 
> Paolo
> 
> > So I think it needs to be a per-device feature bit.
We don't know that it's helpful for any devices besides -net
so I'd say keep it simple.

-- 
MST

On Tue, Jul 02, 2013 at 03:34:09PM +0930, Rusty Russell
wrote:
> Paolo Bonzini <pbonzini at redhat.com> writes:
> > Il 01/07/2013 01:47, Rusty Russell ha scritto:
> >> > > 
> >> > > Mainly because I'm not sure that *all* devices are
now safe.  Are they?
> >> >
> >> > virtio-scsi's implementation in QEMU is not safe (been
delaying that for
> >> > too long, sorry), but the spec is safe.
> >> 
> >> Then if we added a transport feature, we couldn't use it :(
> >
> > Transport feature bits are still negotiated per device though.
> > virtio-scsi devices in QEMU would not negotiate that feature.
> 
> That's a good point; I tend to think of them as tied to the transport
> but there's nothing specifying that, nor any implementation requiring
> it.
> 
> OK, so VIRTIO_F_ANY_LAYOUT it is?
> 
> Cheers,
> Rusty.
> 
> Message Framing
>  
> The original intent of the specification was that message framing 
> (the particular layout of descriptors) be independent of the 
> contents of the buffers. For example, a network transmit buffer 
> consists of a 12 byte header followed by the network packet. This 
> could be most simply placed in the descriptor table as a 12 byte 
> output descriptor followed by a 1514 byte output descriptor, but 
> it could also consist of a single 1526 byte output descriptor in 
> the case where the header and packet are adjacent, or even three 
> or more descriptors (possibly with loss of efficiency in that 
> case).
> 
> Regrettably, initial driver implementations used simple layouts
> and devices came to rely on it, despite this specification 
> wording. It is thus recommended that drivers be conservative in 
> their assumptions, unless specific device features indicate that 
> general layout is permitted using VIRTIO_F_ANY_LAYOUT. In
> addition, some implementations may have large-but-reasonable
> restrictions on total descriptor size (such as based on IOV_MAX
> in the host OS). This has not been a problem in practice: little
> sympathy will be given to drivers which create unreasonably-sized
> descriptors such as dividing a network packet into 1500
> single-byte descriptors!
That's fine with me too.
So which bit are we using for this?
I'd like to rebase to latest bits and merge the optimization for 3.11.

-- 
MST

Il 04/07/2013 09:39, Michael S. Tsirkin ha scritto:
>>>>> > > > > Mainly because I'm not sure that
*all* devices are now safe.  Are they?
>>>> > > >
>>>> > > > virtio-scsi's implementation in QEMU is not
safe (been delaying that for
>>>> > > > too long, sorry), but the spec is safe.
>>> > > 
>>> > > Then if we added a transport feature, we couldn't use
it :(
>> > 
>> > Transport feature bits are still negotiated per device though.
>> > virtio-scsi devices in QEMU would not negotiate that feature.
>> > 
>> > Paolo
>> > 
>>> > > So I think it needs to be a per-device feature bit.
> We don't know that it's helpful for any devices besides -net
> so I'd say keep it simple.
Then we should stop calling it a "device model bug".

If we call it a bug, we must strive for support in all devices.  If we
don't care, we should stop calling it a bug.

Paolo