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.
