Re: [RFC XEN PATCH v3 5/5] xen/public: Introduce PV-IOMMU hypercall interface

[Jan Beulich <jbeulich@xxxxxxxx>]

On 12.07.2024 14:46, Teddy Astie wrote:
> Hello Jan,
> 
> Le 12/07/2024 à 12:46, Jan Beulich a écrit :
>> On 11.07.2024 21:20, Alejandro Vallejo wrote:
>>> On Thu Jul 11, 2024 at 3:04 PM BST, Teddy Astie wrote:
>>>> --- /dev/null
>>>> +++ b/xen/common/pv-iommu.c
>>>> @@ -0,0 +1,328 @@
>>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>>> +/*
>>>> + * xen/common/pv_iommu.c
>>>> + *
>>>> + * PV-IOMMU hypercall interface.
>>>> + */
>>>> +
>>>> +#include <xen/mm.h>
>>>> +#include <xen/lib.h>
>>>> +#include <xen/iommu.h>
>>>> +#include <xen/sched.h>
>>>> +#include <xen/pci.h>
>>>> +#include <xen/guest_access.h>
>>>> +#include <asm/p2m.h>
>>>> +#include <asm/event.h>
>>>> +#include <public/pv-iommu.h>
>>>> +
>>>> +#define PVIOMMU_PREFIX "[PV-IOMMU] "
>>>> +
>>>> +#define PVIOMMU_MAX_PAGES 256 /* Move to Kconfig ? */
>>>
>>> It probably wants to be a cmdline argument, I think.
>>
>> For Dom0. For DomU-s it wants to be a guest config setting, I suppose. Then
>> again I wonder if I understand the purpose of this correctly: The number 
>> looks
>> surprisingly small if it was something the guest may use for arranging its
>> mappings.
> 
> Makes sense to be a guest setting for DomUs. I don't think this limit is 
> too small, actually it means that we can can map up to 1M of contiguous 
> memory in a single hypercall, in the guest case (e.g Linux), it very 
> rarely goes beyond this limit.
> 
> I put this limit to prevent the guest from trying to map millions of 
> pages, which is going to take a while (and may cause stability issues). 
> And to actually give a chance for Xen to preempt the guest (and keep the 
> ability to shut it down between 2 hypercalls).

Oh, this is a per-hypercall limit. Then the identifier is misleading.
Plus I don't see why bigger batches would need rejecting. They only need
breaking up using hypercall continuations.

Jan