Re: [PATCH] amd-iommu: remove page merging code

From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Jan Beulich' <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Brian Woods <brian.woods@amd.com>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Subject: Re: [PATCH] amd-iommu: remove page merging code
Date: Tue, 27 Nov 2018 15:57:27 +0000	[thread overview]
Message-ID: <555e3908b1354e108304805c315bbb1f@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <5BFD67B3020000780020070F@prv1-mh.provo.novell.com>

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@suse.com]
> Sent: 27 November 2018 15:50
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: Brian Woods <brian.woods@amd.com>; Suravee Suthikulpanit
> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> devel@lists.xenproject.org>
> Subject: RE: [Xen-devel] [PATCH] amd-iommu: remove page merging code
> 
> >>> On 27.11.18 at 15:20, <Paul.Durrant@citrix.com> wrote:
> >>  -----Original Message-----
> >> From: Jan Beulich [mailto:JBeulich@suse.com]
> >> Sent: 27 November 2018 13:07
> >> To: Paul Durrant <Paul.Durrant@citrix.com>
> >> Cc: Brian Woods <brian.woods@amd.com>; Suravee Suthikulpanit
> >> <suravee.suthikulpanit@amd.com>; xen-devel <xen-
> >> devel@lists.xenproject.org>
> >> Subject: Re: [Xen-devel] [PATCH] amd-iommu: remove page merging code
> >>
> >> >>> On 26.11.18 at 18:30, <paul.durrant@citrix.com> wrote:
> >> > The page merging logic makes use of bits 1-8 and bit 63 of a PTE,
> which
> >> used
> >> > to be specified as ignored. However, bits 5 and 6 are now specified
> as
> >> > 'accessed' and 'dirty' bits and their use only remains safe as long
> as
> >> > the DTE 'Host Access Dirty' bits remain clear.
> >>
> >> Upon second thought - is this actually true with the XSA-275
> >> changes in place? As long as the domain is not running yet,
> >> how would A and/or D bits get set?
> >
> > Ok, I can amend the comment. The risk is, as I say, predicated on the
> bits
> > in the DTE anyway but the tables are wired into the DTE *before* being
> > populated so I don't think there is anything to stop h/w DMAing whilst
> they
> > are being constructed.
> 
> This way of thinking recurs: When the tables get constructed, the
> domain doesn't run yet, or has no device assigned yet. In both
> cases I can't see who/what would initiate DMA.
>

Ah yes. I was thinking that the page table construction was asynchronous with the assignment for some reason.

  Paul

> Jan
> 

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