qemu-devel
[Top][All Lists]
Advanced

[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: Eric Farman
Subject: Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX
Date: Mon, 8 May 2017 11:00:45 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0



On 05/08/2017 03:00 AM, Christian Borntraeger wrote:
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.


Sounds good to me. Let me work on getting my very ugly code to be slightly less ugly, and I'll send a v2 here. Thanks, everyone.

 - Eric




reply via email to

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