[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC XEN PATCH v3 5/5] xen/public: Introduce PV-IOMMU hypercall interface
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |