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
