>>> On 02.08.18 at 10:04, <paul.durr...@citrix.com> wrote: >> From: Paul Durrant >> Sent: 02 August 2018 09:03 >> > From: Jan Beulich [mailto:jbeul...@suse.com] >> > Sent: 02 August 2018 08:20 >> > >>> 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? > > Oh, I see what you mean... the guest could do something like a > decrease_reservation... I was overlooking that setting up the iommu is > happening while the guest is live. Would it be reasonable to domain_pause() > for safety then?
I'm hesitant to see domains (or vcpus) paused other than when absolutely necessary. If everyone else thinks this is a good idea here, I think I won't object, but please don't forget that any pausing for perhaps an extended period of time may cause the guest to misbehave subsequently. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
