From: Paolo Bonzini <pbonzini@redhat.com> Date: 2012-10-06 12:54:10
Il 05/10/2012 07:43, Rusty Russell ha scritto:
quoted
quoted
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
From: Rusty Russell <hidden> Date: 2012-10-09 05:16:26
Paolo Bonzini [off-list ref] writes:
Il 05/10/2012 07:43, Rusty Russell ha scritto:
quoted
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.
From: Paolo Bonzini <pbonzini@redhat.com> Date: 2012-10-09 07:27:35
Il 09/10/2012 06:59, Rusty Russell ha scritto:
Paolo Bonzini [off-list ref] writes:
quoted
Il 05/10/2012 07:43, Rusty Russell ha scritto:
quoted
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.
From: Rusty Russell <hidden> Date: 2012-10-11 01:10:45
Paolo Bonzini [off-list ref] writes:
Il 09/10/2012 06:59, Rusty Russell ha scritto:
quoted
Paolo Bonzini [off-list ref] writes:
quoted
Il 05/10/2012 07:43, Rusty Russell ha scritto:
quoted
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.
quoted
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.
From: "Michael S. Tsirkin" <mst@redhat.com> Date: 2012-10-11 11:03:07
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
Paolo Bonzini [off-list ref] writes:
quoted
Il 09/10/2012 06:59, Rusty Russell ha scritto:
quoted
Paolo Bonzini [off-list ref] writes:
quoted
Il 05/10/2012 07:43, Rusty Russell ha scritto:
quoted
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.
quoted
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.
From: Rusty Russell <hidden> Date: 2012-10-12 02:30:28
"Michael S. Tsirkin" [off-list ref] writes:
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
quoted
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.
quoted
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.
From: Paolo Bonzini <pbonzini@redhat.com> Date: 2012-10-12 07:38:17
Il 12/10/2012 00:37, Rusty Russell ha scritto:
"Michael S. Tsirkin" [off-list ref] writes:
quoted
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
quoted
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
quoted
quoted
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 [off-list ref] wrote:
"Michael S. Tsirkin" [off-list ref] writes:
quoted
On Thu, Oct 11, 2012 at 10:33:31AM +1030, Rusty Russell wrote:
quoted
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.
quoted
quoted
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.