Grant operation batching

Grant operation batching

[Demi Marie Obenour]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

It is well known that mapping and unmapping grants is expensive, which
is why blkback has persistent grants.  Could this cost be mitigated by
batching, and if it was, would it affect the tradeoff of memcpy() vs
grant table operations?

Alternatively, would there be any interest in an “unsafe” mode for
blkback that skips both the copy and the grant operations?  This is
obviously unsafe (hence the name!), but in many cases that unsafety does
not actually matter.  For instance, a Qubes dom0 can execute any shell
command it wants in any Qubes VM via qvm-run.  Much easier than trying
to exploit some UaF or race condition 🙂.  More generally, when the
backend is the all-powerful dom0, trying to defend against a malicious
backend is (at least in the absence of SEV-SNP or TDX) pointless, so one
might as well not bother and take the free performance.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Grant operation batching

[Jan Beulich]

On 20.05.2022 01:22, Demi Marie Obenour wrote:
> It is well known that mapping and unmapping grants is expensive, which
> is why blkback has persistent grants.  Could this cost be mitigated by
> batching, and if it was, would it affect the tradeoff of memcpy() vs
> grant table operations?

Which backend driver are you thinking about? The in-kernel Linux
xen-blkback already batches grant operations, afaics. Such
batching is helpful, but the main cost is assumed (known?) to be
with the (installing and) tearing down of the actual mappings of
the guest pages (into/)from backend address space.

Jan

Re: Grant operation batching

[Demi Marie Obenour]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On Fri, May 20, 2022 at 08:24:48AM +0200, Jan Beulich wrote:
> On 20.05.2022 01:22, Demi Marie Obenour wrote:
> > It is well known that mapping and unmapping grants is expensive, which
> > is why blkback has persistent grants.  Could this cost be mitigated by
> > batching, and if it was, would it affect the tradeoff of memcpy() vs
> > grant table operations?
> 
> Which backend driver are you thinking about? The in-kernel Linux
> xen-blkback already batches grant operations, afaics. Such
> batching is helpful, but the main cost is assumed (known?) to be
> with the (installing and) tearing down of the actual mappings of
> the guest pages (into/)from backend address space.

My thought was that the expensive part of this is TLB flushes, which are
only needed once per batch.  Also, what do you think about the “unsafe”
mode?  It would only be unsafe if the backend is untrusted, but it is
quite common for the backend to be trusted.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Grant operation batching

[Jan Beulich]

On 20.05.2022 14:37, Demi Marie Obenour wrote:
> On Fri, May 20, 2022 at 08:24:48AM +0200, Jan Beulich wrote:
>> On 20.05.2022 01:22, Demi Marie Obenour wrote:
>>> It is well known that mapping and unmapping grants is expensive, which
>>> is why blkback has persistent grants.  Could this cost be mitigated by
>>> batching, and if it was, would it affect the tradeoff of memcpy() vs
>>> grant table operations?
>>
>> Which backend driver are you thinking about? The in-kernel Linux
>> xen-blkback already batches grant operations, afaics. Such
>> batching is helpful, but the main cost is assumed (known?) to be
>> with the (installing and) tearing down of the actual mappings of
>> the guest pages (into/)from backend address space.
> 
> My thought was that the expensive part of this is TLB flushes, which are
> only needed once per batch.

Correct, but as said - such batching is already being made use of by
the in-kernel Linux backend. Of course "once per batch" is not entirely
precise - very large batches would be split internally into smaller
chunks, each of which would be followed by a TLB flush.

>  Also, what do you think about the “unsafe”
> mode?  It would only be unsafe if the backend is untrusted, but it is
> quite common for the backend to be trusted.

Well, I didn't put much thought into that (and hence intentionally
didn't comment on it), so for now it's only "Why not?"

Jan