[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-----
> >
> > 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?

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.