Il 05/10/2012 07:43, Rusty Russell ha scritto:
>> > struct virtio_scsi_req_cmd {
>> > // Read-only
>> > u8 lun[8];
>> > u64 id;
>> > u8 task_attr;
>> > u8 prio;
>> > u8 crn;
>> > char cdb[cdb_size];
>> > char dataout[];
>> > // Write-only part
>> > u32 sense_len;
>> > u32 residual;
>> > u16 status_qualifier;
>> > u8 status;
>> > u8 response;
>> > u8 sense[sense_size];
>> > char datain[];
>> > };
>> >
>> > where cdb_size and sense_size come from configuration space. The device
>> > right now expects everything before dataout/datain to be in a single
>> > descriptor, but that's in no way part of the spec. Am I missing
>> > something egregious?
> Since you wrote it, I hope not :)
Yeah, I guess the confusion came from cdb_size and sense_size being in
configuration space.
> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
> said to Anthony, the best rules are "always" and "never", so I'd really
> rather not have to grandfather that in.
It is, but we can add a rule that if the (transport) flag
VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in
virtio-blk.
Paolo
Paolo Bonzini <[email protected]> writes:
> Il 05/10/2012 07:43, Rusty Russell ha scritto:
>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
>> said to Anthony, the best rules are "always" and "never", so I'd really
>> rather not have to grandfather that in.
>
> It is, but we can add a rule that if the (transport) flag
> VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in
> virtio-blk.
Could we do that? It's the cmd length I'm concerned about; is it always
32 in practice for some reason?
Currently qemu does:
struct sg_io_hdr hdr;
memset(&hdr, 0, sizeof(struct sg_io_hdr));
hdr.interface_id = 'S';
hdr.cmd_len = req->elem.out_sg[1].iov_len;
hdr.cmdp = req->elem.out_sg[1].iov_base;
hdr.dxfer_len = 0;
If it's a command which expects more output data, there's no way to
guess where the boundary is between that command and the data.
Cheers,
Rusty.
Il 09/10/2012 06:59, Rusty Russell ha scritto:
> Paolo Bonzini <[email protected]> writes:
>> Il 05/10/2012 07:43, Rusty Russell ha scritto:
>>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
>>> said to Anthony, the best rules are "always" and "never", so I'd really
>>> rather not have to grandfather that in.
>>
>> It is, but we can add a rule that if the (transport) flag
>> VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in
>> virtio-blk.
>
> Could we do that? It's the cmd length I'm concerned about; is it always
> 32 in practice for some reason?
It is always 32 or less except in very obscure cases that are pretty
much confined to iSCSI. We don't care about the obscure cases, and the
extra bytes don't hurt.
BTW, 32 is the default cdb_size used by virtio-scsi.
> Currently qemu does:
>
> struct sg_io_hdr hdr;
> memset(&hdr, 0, sizeof(struct sg_io_hdr));
> hdr.interface_id = 'S';
> hdr.cmd_len = req->elem.out_sg[1].iov_len;
> hdr.cmdp = req->elem.out_sg[1].iov_base;
> hdr.dxfer_len = 0;
>
> If it's a command which expects more output data, there's no way to
> guess where the boundary is between that command and the data.
Yep, so I understood the problem right.
Paolo
Paolo Bonzini <[email protected]> writes:
> Il 09/10/2012 06:59, Rusty Russell ha scritto:
>> Paolo Bonzini <[email protected]> writes:
>>> Il 05/10/2012 07:43, Rusty Russell ha scritto:
>>>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
>>>> said to Anthony, the best rules are "always" and "never", so I'd really
>>>> rather not have to grandfather that in.
>>>
>>> It is, but we can add a rule that if the (transport) flag
>>> VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in
>>> virtio-blk.
>>
>> Could we do that? It's the cmd length I'm concerned about; is it always
>> 32 in practice for some reason?
>
> It is always 32 or less except in very obscure cases that are pretty
> much confined to iSCSI. We don't care about the obscure cases, and the
> extra bytes don't hurt.
>
> BTW, 32 is the default cdb_size used by virtio-scsi.
>
>> Currently qemu does:
>>
>> struct sg_io_hdr hdr;
>> memset(&hdr, 0, sizeof(struct sg_io_hdr));
>> hdr.interface_id = 'S';
>> hdr.cmd_len = req->elem.out_sg[1].iov_len;
>> hdr.cmdp = req->elem.out_sg[1].iov_base;
>> hdr.dxfer_len = 0;
>>
>> If it's a command which expects more output data, there's no way to
>> guess where the boundary is between that command and the data.
>
> Yep, so I understood the problem right.
OK. Well, Anthony wants qemu to be robust in this regard, so I am
tempted to rework all the qemu drivers to handle arbitrary layouts.
They could use a good audit anyway.
This would become a glaring exception, but I'm tempted to fix it to 32
bytes at the same time as we get the new pci layout (ie. for the virtio
1.0 spec). The Linux driver would carefully be backwards compatible, of
course, and the spec would document why.
Cheers,
Rusty.
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
> Paolo Bonzini <[email protected]> writes:
> > Il 09/10/2012 06:59, Rusty Russell ha scritto:
> >> Paolo Bonzini <[email protected]> writes:
> >>> Il 05/10/2012 07:43, Rusty Russell ha scritto:
> >>>> That's good. But virtio_blk's scsi command is insoluble AFAICT. As I
> >>>> said to Anthony, the best rules are "always" and "never", so I'd really
> >>>> rather not have to grandfather that in.
> >>>
> >>> It is, but we can add a rule that if the (transport) flag
> >>> VIRTIO_RING_F_ANY_HEADER_SG is set, the cdb field is always 32 bytes in
> >>> virtio-blk.
> >>
> >> Could we do that? It's the cmd length I'm concerned about; is it always
> >> 32 in practice for some reason?
> >
> > It is always 32 or less except in very obscure cases that are pretty
> > much confined to iSCSI. We don't care about the obscure cases, and the
> > extra bytes don't hurt.
> >
> > BTW, 32 is the default cdb_size used by virtio-scsi.
> >
> >> Currently qemu does:
> >>
> >> struct sg_io_hdr hdr;
> >> memset(&hdr, 0, sizeof(struct sg_io_hdr));
> >> hdr.interface_id = 'S';
> >> hdr.cmd_len = req->elem.out_sg[1].iov_len;
> >> hdr.cmdp = req->elem.out_sg[1].iov_base;
> >> hdr.dxfer_len = 0;
> >>
> >> If it's a command which expects more output data, there's no way to
> >> guess where the boundary is between that command and the data.
> >
> > Yep, so I understood the problem right.
>
> OK. Well, Anthony wants qemu to be robust in this regard, so I am
> tempted to rework all the qemu drivers to handle arbitrary layouts.
> They could use a good audit anyway.
I agree here. Still trying to understand whether we can agree to use
a feature bit for this, or not.
> This would become a glaring exception, but I'm tempted to fix it to 32
> bytes at the same time as we get the new pci layout (ie. for the virtio
> 1.0 spec).
But this isn't a virtio-pci only issue, is it?
qemu has s390 bus with same limmitation.
How can we tie it to pci layout?
Maybe what you mean is to use a transport feature for this
and tie *that* to new layout in case of pci?
> The Linux driver would carefully be backwards compatible, of
> course, and the spec would document why.
>
> Cheers,
> Rusty.
"Michael S. Tsirkin" <[email protected]> writes:
> On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
>> OK. Well, Anthony wants qemu to be robust in this regard, so I am
>> tempted to rework all the qemu drivers to handle arbitrary layouts.
>> They could use a good audit anyway.
>
> I agree here. Still trying to understand whether we can agree to use
> a feature bit for this, or not.
I'd *like* to imply it by the new PCI layout, but if it doesn't work
we'll add a new feature bit.
I'm resisting a feature bit, since it constrains future implementations
which could otherwise assume it.
>> This would become a glaring exception, but I'm tempted to fix it to 32
>> bytes at the same time as we get the new pci layout (ie. for the virtio
>> 1.0 spec).
>
> But this isn't a virtio-pci only issue, is it?
> qemu has s390 bus with same limmitation.
> How can we tie it to pci layout?
They can use a transport feature if they need to, of course. But
perhaps the timing with ccw will coincide with the fix, in which they
don't need to, but it might be a bit late.
Cornelia?
Cheers,
Rusty.
Il 12/10/2012 00:37, Rusty Russell ha scritto:
> "Michael S. Tsirkin" <[email protected]> writes:
>> On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
>>> OK. Well, Anthony wants qemu to be robust in this regard, so I am
>>> tempted to rework all the qemu drivers to handle arbitrary layouts.
>>> They could use a good audit anyway.
>>
>> I agree here. Still trying to understand whether we can agree to use
>> a feature bit for this, or not.
>
> I'd *like* to imply it by the new PCI layout, but if it doesn't work
> we'll add a new feature bit.
>
> I'm resisting a feature bit, since it constrains future implementations
> which could otherwise assume it.
Future implementations may certainly refuse to start if the feature is
not there. Whether it's a good idea or not, well, that depends on how
much future they are.
Paolo
>>> This would become a glaring exception, but I'm tempted to fix it to 32
>>> bytes at the same time as we get the new pci layout (ie. for the virtio
>>> 1.0 spec).
>>
>> But this isn't a virtio-pci only issue, is it?
>> qemu has s390 bus with same limmitation.
>> How can we tie it to pci layout?
>
> They can use a transport feature if they need to, of course. But
> perhaps the timing with ccw will coincide with the fix, in which they
> don't need to, but it might be a bit late.
>
> Cornelia?
>
> Cheers,
> Rusty.
>
On Fri, 12 Oct 2012 09:07:46 +1030
Rusty Russell <[email protected]> wrote:
> "Michael S. Tsirkin" <[email protected]> writes:
> > On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
> >> OK. Well, Anthony wants qemu to be robust in this regard, so I am
> >> tempted to rework all the qemu drivers to handle arbitrary layouts.
> >> They could use a good audit anyway.
> >
> > I agree here. Still trying to understand whether we can agree to use
> > a feature bit for this, or not.
>
> I'd *like* to imply it by the new PCI layout, but if it doesn't work
> we'll add a new feature bit.
>
> I'm resisting a feature bit, since it constrains future implementations
> which could otherwise assume it.
>
> >> This would become a glaring exception, but I'm tempted to fix it to 32
> >> bytes at the same time as we get the new pci layout (ie. for the virtio
> >> 1.0 spec).
> >
> > But this isn't a virtio-pci only issue, is it?
> > qemu has s390 bus with same limmitation.
> > How can we tie it to pci layout?
>
> They can use a transport feature if they need to, of course. But
> perhaps the timing with ccw will coincide with the fix, in which they
> don't need to, but it might be a bit late.
>
> Cornelia?
My virtio-ccw host code is still going through a bit of rework, so it
might well go in after the fix.
There's also the existing (non-spec'ed) s390-virtio transport. While it
will likely be deprecated sometime in the future, it should probably
get a feature bit for consistency's sake.
>
> Cheers,
> Rusty.
>