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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.11.18 at 15:20, <Paul.Durrant@xxxxxxxxxx> wrote:
>>  -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: 27 November 2018 13:07
>> 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] amd-iommu: remove page merging code
>> 
>> >>> On 26.11.18 at 18:30, <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 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.

Jan



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