> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 27 August 2019 08:49 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: 'JulienGrall' <julien.gr...@arm.com>; 'Alexandru Isaila' > <aisa...@bitdefender.com>; 'Petre > Pircalabu' <ppircal...@bitdefender.com>; 'Razvan Cojocaru' > <rcojoc...@bitdefender.com>; Andrew Cooper > <andrew.coop...@citrix.com>; George Dunlap <george.dun...@citrix.com>; Ian > Jackson > <ian.jack...@citrix.com>; Roger Pau Monne <roger....@citrix.com>; > 'VolodymyrBabchuk' > <volodymyr_babc...@epam.com>; 'Stefano Stabellini' <sstabell...@kernel.org>; > 'xen- > de...@lists.xenproject.org' <xen-devel@lists.xenproject.org>; 'Konrad > Rzeszutek Wilk' > <konrad.w...@oracle.com>; 'Tamas K Lengyel' <ta...@tklengyel.com>; Tim > (Xen.org) <t...@xen.org>; 'Wei > Liu' <w...@xen.org> > Subject: Re: [Xen-devel] [PATCH 3/6] remove late (on-demand) construction of > IOMMU page tables > > On 14.08.2019 11:39, Paul Durrant wrote: > >> -----Original Message----- > >> From: Xen-devel <xen-devel-boun...@lists.xenproject.org> On Behalf Of Paul > >> Durrant > >> Sent: 12 August 2019 17:26 > >> To: 'Jan Beulich' <jbeul...@suse.com> > >> Cc: 'Petre Pircalabu' <ppircal...@bitdefender.com>; 'Stefano Stabellini' > >> <sstabell...@kernel.org>; > >> 'Wei Liu' <w...@xen.org>; 'Razvan Cojocaru' <rcojoc...@bitdefender.com>; > >> 'Konrad Rzeszutek Wilk' > >> <konrad.w...@oracle.com>; Andrew Cooper <andrew.coop...@citrix.com>; Tim > >> (Xen.org) <t...@xen.org>; > >> George Dunlap <george.dun...@citrix.com>; 'Julien Grall' > >> <julien.gr...@arm.com>; 'Tamas K Lengyel' > >> <ta...@tklengyel.com>; Ian Jackson <ian.jack...@citrix.com>; 'Alexandru > >> Isaila' > >> <aisa...@bitdefender.com>; 'xen-devel@lists.xenproject.org' > >> <xen-devel@lists.xenproject.org>; > >> 'VolodymyrBabchuk' <volodymyr_babc...@epam.com>; Roger Pau Monne > >> <roger....@citrix.com> > >> Subject: 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? > >> > > > > I think I'm going to say no to this anyway since, as you say, the overhead > > as never been accounted > for and having to make assumptions about the IOMMU table structure is not > very attractive. Given that > any issue is going to be transient (i.e. until patch #6 is committed) I don't > think fixing auto- > ballooning ought to be in scope for this series. > > I'm afraid I disagree: The series extends a pre-existing problem > affecting some guests to all ones (at least by default).
TBH I've seen sufficient numbers of domain create failures when using auto-ballooning that I stopped using it some time ago (besides the fact that it's slow). If you're happy with the simplistic double-the-page-table-reservation calculation then I can add that but IMO it would be better to add another patch to just remove auto-ballooning. Paul > > Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
