Re: [PATCH] xen/x86: allow Dom0 PVH to call XENMEM_exchange

[Jan Beulich <jbeulich@xxxxxxxx>]

On 09.05.2025 10:32, Roger Pau Monné wrote:
> On Thu, May 08, 2025 at 04:25:28PM -0700, Stefano Stabellini wrote:
>> On Thu, 8 May 2025, Roger Pau Monné wrote:
>>> On Wed, May 07, 2025 at 04:02:11PM -0700, Stefano Stabellini wrote:
>>>> On Tue, 6 May 2025, Roger Pau Monné wrote:
>>>>> On Mon, May 05, 2025 at 11:11:10AM -0700, Stefano Stabellini wrote:
>>>>>> In my opinion, we definitely need a solution like this patch for Dom0
>>>>>> PVH to function correctly in all scenarios.
>>>>>
>>>>> I'm not opposed to having such interface available for PVH hardware
>>>>> domains.  I find it ugly, but I don't see much other way to deal with
>>>>> those kind of "devices".  Xen mediating accesses for each one of them
>>>>> is unlikely to be doable.
>>>>>
>>>>> How do you hook this exchange interface into Linux to differentiate
>>>>> which drivers need to use mfns when interacting with the hardware?
>>>>
>>>> In the specific case we have at hands the driver is in Linux userspace
>>>> and is specially-written for our use case. It is not generic, so we
>>>> don't have this problem. But your question is valid.
>>>
>>> Oh, so you then have some kind of ioctl interface that does the memory
>>> exchange and bouncing inside of the kernel on behalf of the user-space
>>> side I would think?
>>
>> I am not sure... Xenia might know more than me here.
> 
> One further question I have regarding this approach: have you
> considered just populating an empty p2m space with contiguous physical
> memory instead of exchanging an existing area?  That would increase
> dom0 memory usage, but would prevent super page shattering in the p2m.
> You could use a dom0_mem=X,max:X+Y command line option, where Y
> would be your extra room for swiotlb-xen bouncing usage.
> 
> XENMEM_increase_reservation documentation notes such hypercall already
> returns the base MFN of the allocated page (see comment in
> xen_memory_reservation struct declaration).

Except that this looks to be stale. At the bottom of increase_reservation()
we have:

        if ( !paging_mode_translate(d) &&
             !guest_handle_is_null(a->extent_list) )
        {
            mfn_t mfn = page_to_mfn(page);

            if ( unlikely(__copy_mfn_to_guest_offset(a->extent_list, i, mfn)) )
                goto out;
        }

Consistent with us not exposing MFNs elsewhere as well, except for PV.

Jan