[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 3/6] remove late (on-demand) construction of IOMMU page tables
> -----Original Message----- [snip] > > > > On 30.07.2019 15:44, Paul Durrant wrote: > > > NOTE: This patch will cause a small amount of extra resource to be used > > > to accommodate IOMMU page tables that may never be used, since the > > > per-domain IOMMU flag enable flag is currently set to the value > > > of the global iommu_enable flag. A subsequent patch will add an > > > option to the toolstack to allow it to be turned off if there is > > > no intention to assign passthrough hardware to the domain. > > > > In particular if the default of this is going to be "true" (I > > didn't look at that patch yet, but the wording above makes me > > assume so), in auto-ballooning mode without shared page tables > > more memory should imo be ballooned out of Dom0 now. It has > > always been a bug that IOMMU page tables weren't accounted for, > > but it would become even more prominent then. > > Ultimately, once the whole series is applied, then nothing much should change > for those specifying > passthrough h/w in an xl.cfg. The main difference will be that h/w cannot be > passed through to a > domain that was not originally created with IOMMU pagetables. > With patches applied up to this point then, yes, every domain will get IOMMU > page tables. I guess I'll > take a look at the auto-ballooning code and see what needs to be done. > Ok, I've had a look... I could make a rough calculation in libxl_domain_need_memory() based on the domain's max_memkb and an assumption of a 4 level translation with 512 PTEs per level, or would prefer such guestimation to be overridable using an xl.cfg parameter in a broadly similar way to shadow_memkb? Paul _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |