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.
