|
From: | Eric Farman |
Subject: | Re: [Qemu-devel] [RFC PATCH v1 0/5] Enable virtio-scsi boot from /dev/sgX |
Date: | Fri, 5 May 2017 12:12:26 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
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.
Thanks, Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |