Re: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...

From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	George Dunlap <George.Dunlap@citrix.com>,
	Julien Grall <julien.grall@arm.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@citrix.com>
Subject: Re: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make page table population preemptible"...
Date: Thu, 2 Aug 2018 08:49:02 +0000	[thread overview]
Message-ID: <39f0f20acabb48f8a0152f09bf7b21b7@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5B62BE5602000078001DA2E3@prv1-mh.provo.novell.com>

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 02 August 2018 09:19
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Julien Grall <julien.grall@arm.com>; Andrew Cooper
> <Andrew.Cooper3@citrix.com>; George Dunlap
> <George.Dunlap@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>; Stefano Stabellini <sstabellini@kernel.org>; xen-
> devel <xen-devel@lists.xenproject.org>; Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com>; Tim (Xen.org) <tim@xen.org>
> Subject: RE: [PATCH v4 01/15] re-work commit 3e06b989 "IOMMU: make
> page table population preemptible"...
> 
> >>> On 02.08.18 at 10:04, <Paul.Durrant@citrix.com> wrote:
> >> From: Paul Durrant
> >> Sent: 02 August 2018 09:03
> >> > From: Jan Beulich [mailto:JBeulich@suse.com]
> >> > Sent: 02 August 2018 08:20
> >> > >>> On 01.08.18 at 15:40, <paul.durrant@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.
> 

Yes, true, but I also wonder how safe it is to empty the page_list of a running guest. I guess it may be the best way but I think having a dedicate page_list in the iommu struct to host pages that have already been mapped and then transfer them back at the end would be cleaner and should allow need_iommu to stay boolean.

Also, given the expense of the operation to set up the mappings, I guess it may also be a good idea to leave them alone until domain destruction once the set-up has been done rather than removing them when the last device is de-assigned.

  Paul

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel