[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v1 00/15] Xen PV backend support for KVM/Xen guests
From: |
Joao Martins |
Subject: |
Re: [RFC PATCH v1 00/15] Xen PV backend support for KVM/Xen guests |
Date: |
Tue, 10 Jan 2023 17:26:07 +0000 |
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.
- [RFC PATCH v1 04/15] hw/xen: Pass grant ref to gnttab unmap, (continued)
- [RFC PATCH v1 04/15] hw/xen: Pass grant ref to gnttab unmap, David Woodhouse, 2023/01/10
- [RFC PATCH v1 13/15] hw/xen: Implement soft reset for emulated gnttab, David Woodhouse, 2023/01/10
- [RFC PATCH v1 07/15] hw/xen: Move xenstore_store_pv_console_info to xen_console.c, David Woodhouse, 2023/01/10
- [RFC PATCH v1 03/15] hw/xen: Add gnttab operations to allow redirection to internal emulation, David Woodhouse, 2023/01/10
- [RFC PATCH v1 06/15] hw/xen: Add xenstore operations to allow redirection to internal emulation, David Woodhouse, 2023/01/10
- [RFC PATCH v1 01/15] hw/xen: Add evtchn operations to allow redirection to internal emulation, David Woodhouse, 2023/01/10
- [RFC PATCH v1 02/15] hw/xen: Add emulated evtchn ops, David Woodhouse, 2023/01/10
- Re: [RFC PATCH v1 00/15] Xen PV backend support for KVM/Xen guests, Joao Martins, 2023/01/10