On 31.01.2017 19:11, Alberto Garcia wrote: > On Tue 31 Jan 2017 05:41:23 PM CET, Eric Blake <ebl...@redhat.com> wrote: > >>>> Ideally, it would be nice to fix the block layer to allow larger >>>> requests (since we already have code to auto-fragment down to device >>>> limits, we should be able to rely on that code instead of having to >>>> duplicate artificial constraints everywhere else in the tree). But >>>> that's a bigger task, and this is a good patch in the interim. >>> >>> Related question: what's the largest request than a guest can >>> theoretically submit? >> >> off_t supports up to 2^63 (not 2^64, because it is a signed type). >> Ideally, we should be constrained only by the disk size (as no one >> actually has 2^63 bytes of storage available), by using uint64_t >> offset AND length in all our APIs; but right now, we still have a lot >> of 32-bit length issues, and often signed length limiting us to 2^31 >> depending on the API. > > My question was more like: what happens if the guest submits a request > with the maximum possible size? Does QEMU handle that correctly?
As far as I'm aware we rely on the device emulation code to split the request. Max
signature.asc
Description: OpenPGP digital signature
