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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 27 November 2018 15:58
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Brian Woods <brian.woods@xxxxxxx>; Suravee Suthikulpanit
> <suravee.suthikulpanit@xxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH v2] amd-iommu: remove page merging code
> 
> >>> On 27.11.18 at 15:58, <paul.durrant@xxxxxxxxxx> 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 unused by Xen.
> 
> ... or as long the two page table bits don't get made use of
> (by Xen or hardware) before the domain starts running (i.e.
> the "hardware" part is always true afaict).
> 

Yes, that would also be true. I still don't like the re-use of bits that are no 
longer marked explicitly as ignored though.

> > The code was also the subject of XSA-275 and, since then, has been
> disabled
> > after domain creation.
> >
> > This patch removes the code, freeing up the remaining PTE 'ignored' bits
> > for other potential use and shortening the source by 170 lines. There
> may
> > be some marginal performance cost since higher order mappings will now
> be
> > ruled out until a mapping order parameter is passed to iommu_ops.
> 
> "Marginal" is a guess, or supported by actual measurements? With
> heavy S/G of small blocks of data I could easily see this become
> more than a marginal increase of overhead. How bad it is certainly
> also depends on IOTLB capacity.

Yes, it is down to IOTLB capacity and therefore I do not know what the reality 
of the performance cost is. I saw no problem in manual testing of a GPU but I 
don't have comparative benchmark numbers.

> 
> What I would find more convincing would be if there was a reason
> why a fair part of the large page mappings get shattered anyway
> today.
> 

Well, I could just leave PV-IOMMU unimplemented for AMD h/w if you think the 
page merging code is more important since, without the spare ignored bits, I 
have no way to track pages added by the hypercall vs. those added at start of 
day. I personally think that the simpler code is worthwhile in itself but I 
guess you disagree.


  Paul

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