> -----Original Message----- > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: 02 August 2018 08:20 > To: Paul Durrant <paul.durr...@citrix.com> > Cc: Julien Grall <julien.gr...@arm.com>; Andrew Cooper > <andrew.coop...@citrix.com>; Wei Liu <wei.l...@citrix.com>; George > Dunlap <george.dun...@citrix.com>; Ian Jackson <ian.jack...@citrix.com>; > Stefano Stabellini <sstabell...@kernel.org>; xen-devel <xen- > de...@lists.xenproject.org>; Konrad Rzeszutek Wilk > <konrad.w...@oracle.com>; Tim (Xen.org) <t...@xen.org> > Subject: Re: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make > page table population preemptible"... > > >>> On 01.08.18 at 15:40, <paul.durr...@citrix.com> 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. > > Well, yes, I would have used that model in said commit if it was reliable, > but it isn't: What if the list of pages changed between two (re-)invocations?
Is that really going to happen? This is the result of a domctl, which is a tools-only hypercall right? > Furthermore, with huge enough a guest even the skipping of the already > processed several million pages may exhaust the time acceptable between > preemption points. Ok, I'll keep a pointer into the page list instead. Paul > > Jan > _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
