> -----Original Message----- > From: Roger Pau Monne > Sent: 01 August 2018 17:15 > To: Paul Durrant <[email protected]> > Cc: [email protected]; Stefano Stabellini > <[email protected]>; Wei Liu <[email protected]>; George Dunlap > <[email protected]>; Andrew Cooper > <[email protected]>; Ian Jackson <[email protected]>; Tim > (Xen.org) <[email protected]>; Julien Grall <[email protected]>; Jan Beulich > <[email protected]> > Subject: Re: [Xen-devel] [PATCH v4 01/15] re-work commit 3e06b989 > "IOMMU: make page table population preemptible"... > > On Wed, Aug 01, 2018 at 02:40:14PM +0100, Paul Durrant wrote: > > ...to simplify the implementation and turn need_iommu back into a > boolean. > > > > As noted in [1] the tri-state nature of need_iommu after commit 3e06b989 > is > > confusing, as is the implementation of pre-emption using relmem_list. > > > > This patch instead uses a simple count of pages already populated stored in > > the x86 variant of struct arch_iommu and skips over that number of pages > > if arch_iommu_populate_page_table() is re-invoked after pre-emption. > > Urg, all this is quite ugly. It would be quite better if the need for > an IOMMU was decided before populating the p2m (ie: at domain_create > time by passing an extra XEN_DOMCTL_CDF_iommu or some such), so that > the normal addition of RAM would also populate the IOMMU page tables > if not shared.
Given the problems that Jan has highlighted with using a skip count and essentially being forced to mess with the domain's page list, I think your suggestion is best. Then we can entirely bin arch_iommu_populate_page_table(). That is a bigger piece of work though so in the interest of no blocking the rest of this series I'll drop this patch and replace it with a simpler patch that's just sufficient to make need_iommu boolean again. Paul > > > [1] https://lists.xenproject.org/archives/html/xen-devel/2018- > 07/msg01870.html > > > > Signed-off-by: Paul Durrant <[email protected]> > > Reviewed-by: Roger Pau Monné <[email protected]> > > Thanks, Roger. _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
