[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sg
From: |
Christian Borntraeger |
Subject: |
Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX |
Date: |
Mon, 8 May 2017 09:00:41 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 05/06/2017 10:24 AM, Paolo Bonzini wrote:
>
>
> 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 thec 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
>
Eric, maybe that would be a safe variant. The bios boot code is not
performance optimized anyway. Lets just always use a maximum size that
will always work.