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

From: "Jan Beulich" <JBeulich@suse.com>
To: Paul Durrant <paul.durrant@citrix.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 08:48:14 -0700	[thread overview]
Message-ID: <5BFD673E020000780020070C@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <326c82d0833d4388b72c7f213554d374@AMSPEX02CL03.citrite.net>

>>> On 27.11.18 at 15:12, <Paul.Durrant@citrix.com> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@suse.com]
>> Sent: 27 November 2018 13:02
>> 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. The code is also of
>> dubious
>> > benefit and was the subject XSA-275.
>> >
>> > This patch removes the code, freeing up the remaining PTE 'ignored' bits
>> > for other potential use and shortening the source by 170 lines.
>> 
>> No word at all about the performance implications? Do you have
>> any plans to re-introduce properly working page recombining
>> code? I realize VT-d doesn't have any either (the maintainers at
>> some point in the distant past had promised to implement it, but
>> I guess that's long been forgotten), but anyway...
>> 
> 
> I hope to wire through the order parameter to the implementations 
> eventually, which is the right way to do things I think. It also means I'll 
> probably need to tweak the PV-IOMMU interface to handle an order parameter 
> before I send v.next too.

That's going to help only partially, but at least as far as domain
creation goes it should get us back to current state, as guest
memory population should happen in large enough chunks. Very
large guests may then still have more levels than they actually
need on AMD hardware, buts that's a corner case I consider
acceptable.

Re-combination of large pages when the domain is running,
otoh, is not going to start working again with what you describe.
Arguably there may not be too many cases where there
actually is an opportunity to do so.

Jan

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