qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [patch] fix scsi-generic


From: adq
Subject: [Qemu-devel] Re: [patch] fix scsi-generic
Date: Wed, 17 Nov 2010 23:33:13 +0000

> On 12 November 2010 10:00, Paolo Bonzini <address@hidden> wrote:
>> On 08/09/2010 01:51 AM, adq wrote:
>>>
>>> Figured out what the problem is - READ DVD STRUCTURE has its xfer
>>> length in an unexpected place, so hw/scsi-bus.c retrieves completely
>>> the wrong value for the transfer length. Attached nasty hacky (!)
>>> patch fixes it as a proof of concept, will see what I can do to clean
>>> it up later. I'd probably want it to warn if it sees SCSI commands it
>>> doesn't know how to explicitly handle to aid debugging this sort of
>>> thing in future.
>>
>> Hi Andrew, are you going to submit a similar patch in definitive form?

Oops, sorry for top replying before.

Anyway, found the patch and it looks to be in good condition (just
missing one last SCSI MMC command and testing, which I shall work on).

However, could someone please check the code for the existing
SEND_VOLUME_TAG code in hw/scsi-bus.c? A doc on this command is h ere:
http://www.t10.org/ftp/t10/document.05/05-414r4.pdf

I'm not certain "req->cmd.xfer *= 40;" is correct. For a type 5 SCSI
command, req->cmd.xfer will be set to the value in bytes 9/8/7/6,
which is defined as PARAMETER LIST LENGTH (i.e. the number of bytes in
the data transfer according to SPC3). The PARAMETER LIST LENGTH for
this command should be 40, so multiplying it by 40 again ain't right
surely?

As I've never seen this command used and have no access to a device
which could generate it, I just don't know....



reply via email to

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