Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX

[Paolo Bonzini <pbonzini@redhat.com>]

On 05/05/2017 18:12, Eric Farman wrote:
> 
> 
> On 05/05/2017 11:13 AM, Paolo Bonzini wrote:
>>
>>
>> On 05/05/2017 17:03, Eric Farman wrote:
>>> We get a value of x3fffff when sending that to a scsi-disk from bios
>>> code.  That's fully emulated though, in scsi_disk_emulate_inquiry.  And
>>> that's the scenario that already works.
>>>
>>> While there is indeed code in hw/scsi/scsi-generic.c to wire that in,
>>> that only happens after the I/O goes to the device itself.  The Block
>>> Limits page isn't supported [1] and thus it gets rejected with "invalid
>>> field in cdb".  We never get to that fixup code you reference, since the
>>> returned len is zero.
>>>
>>> Should I be refactoring this code to always patch in that block limit
>>> regardless of a response from the host/device?  (That is, when page xb0
>>> isn't supported by the hw.)
>>
>> What is the BLKSECTGET value you get?
> 
> x140000 bytes when using /dev/sg0 (xa00 sectors when using /dev/sda).
> 
>>  Is there a sensible default value
>> that you can use when page 0xb0 isn't supported by the hardware?
> 
> I was setting max_sectors to x800 with good success, which was the
> power-of-2 floor that BLKSECTGET gave us.  That kept us within the
> limits of the host biovec code.  But it's a long way from the
> virtio-scsi value of xFFFF when max_sectors isn't specified, so don't
> know what side effects that may cause.

It's just slower, but 0x800 is already a megabyte worth of data so it's
not going to be that much slower.

Paolo