Re: [RFC PATCH v1 00/15] Xen PV backend support for KVM/Xen guests

[Joao Martins <joao.m.martins@oracle.com>]

On 10/01/2023 16:52, David Woodhouse wrote:
> On Tue, 2023-01-10 at 15:43 +0000, Joao Martins wrote:
>> On 10/01/2023 12:37, David Woodhouse wrote:
>> The only user of multi-gref mapping is the block xen driver ... and only for
>> mapping the shared ring if I understood correctly. But even there you could
>> probably twist it... considering that the multi-gref ring is contiguous is guest
>> address space, thus the gref -> HVA conversion ius contiguous too (?). So that
>> way you could still return a single HVA (provided that map-grant implementation
>> validates the backing frame contiguosity).
> 
> There's no reason a guest couldn't vmalloc its multi-page ring and have
> a virtually contiguous view for itself, while the actual GPAs are
> discontiguous. Sure, that's probably not the common case, but I didn't
> really want to have a multi-page mapping succeed *sometimes*.
> 
Right. I don't remember that ever being the case on frontends, but I could be
very wrong

This was just a suggesting not trying too hard to fix the problem while
maintaining single/contiguous gref limitation (if it didn't meant much more work
to you). Provided this only happens when configuring device. An alternative is
to /try finding GPA contiguosity/ and should it not be, then you switch device
xenbus status to error if you fail to map the guest grefs (This is a valid
scenario still in Xen kernel backends IIRC). Sadly backends don't re-read
features when re-connecting so probably not exposing ring-order at all as safest
if it can only be supported "half way"

>>> So for now we'll limit the
>>> back ends to mapping a single grant ref at a time.
>>
>> Which is not a practical limitation right now.
> 
> That sentence can be read both ways. I first read it as "that
> limitation is impractical". But prefer to read it as "that doesn't
> limit us in practice", and I *think* the latter is what you meant from
> the rest of the paragraph...
> 
Correct. The latter sounds like proper english on what I wanted to say

>>  One grant ref is actually fine
>> for the everything else that is not the block shared-ring.  Xen devices in Qemu
>> seem to be using the legacy backend interface, and thus (un)mapping one grant at
>> a time, or otherwise copying grefs.
> 
> Right. We can absolutely live with that limitation for now; we'll teach
> xen-block not to advertise a higher max-ring-page-order if ring_order
> if the MAP_MULTIPLE feature isn't set.
> 
> And I absolutely don't give a crap about 9p or usb just yet. :)
> 
:)

9p is actually for rings as well (same as block). USB is the only one where it
uses it in the datapath, which is likely to see issues more often.