Am 23.09.2014 um 08:15 hat Peter Lieven geschrieben: > On 22.09.2014 21:06, Paolo Bonzini wrote: > >Il 22/09/2014 11:43, Peter Lieven ha scritto: > >>This series aims not at touching default behaviour. The default for > >>max_transfer_length > >>is 0 (no limit). max_transfer_length is a limit that MUST be satisfied > >>otherwise the request > >>will fail. And Patch 2 aims at catching this fail earlier in the stack. > >Understood. But the right fix is to avoid that backend limits transpire > >into guest ABI, not to catch the limits earlier. So the right fix would > >be to implement request splitting. > > Since you proposed to add traces for this would you leave those in? > And since iSCSI is the only user of this at the moment would you > go for implementing this check in the iSCSI block layer? > > As for the split logic would you think it is enough to build new qiov's > out of the too big iov without copying the contents? This would work > as long as a single iov inside the qiov is not bigger the max_transfer_length. > Otherwise I would need to allocate temporary buffers and copy around.
You can split single iovs, too. There are functions that make this very easy, they copy a sub-qiov with a byte granularity offset and length (qemu_iovec_concat and friends). qcow2 uses the same to split requests at (fragmented) cluster boundaries. Kevin