Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests

[Peter Lieven <pl@kamp.de>]

On 08.09.2014 17:13, ronnie sahlberg wrote:
> On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 08/09/2014 16:35, Peter Lieven ha scritto:
>>>>>> messages. :)
>>>>> So you would not throw an error msg here?
>>>> No, though a trace could be useful.
>>> Is there a howto somewhere how to implement that?
>> Try commit 4ac4458076e1aaf3b01a6361154117df20e22215.
>>
>>> Whats your opinion changed the max_xfer_len to 0xffff regardsless
>>> of use_16_for_rw in iSCSI?
>> If you implemented request splitting in the block layer, it would be
>> okay to force max_xfer_len to 0xffff.
> I think it should be OK if that is a different series. This only
> affects the iSCSI transport since it is the only transport so far to
> record or report a max transfer length.
> If a guest generates these big requests(i.e. not multiwrite) we
> already fail them due to the READ10 limitations. We would just fail
> the request at a different layer in the stack with these patches.
>
>
> What I would like to see would also be to report these limitations to
> the guest itself to prevent it from generating too large I/Os.
> I am willing to do that part once the initial max_xfer_len ones are finished.

Yes, I also think this approach is straightforward. We should avoid
big requests at the beginning and not fix them at the end.
I had a look it shouldn't be too hard. There are default values for
virtio-scsi HD inquiry emulation which are set if no cmdline values
are specified. It should be possible to feed them from bs->bl if set.

Peter