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

[Teddy Astie <teddy.astie@xxxxxxxxxx>]

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.
>
> Jan

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).

Teddy


Teddy Astie | Vates XCP-ng Intern

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech