Re: [Xen-devel] [PATCH] VTd/dmar: Tweak how the DMAR table is clobbered

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 10.04.15 at 11:08, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 10/04/15 02:23, Tian, Kevin wrote:
>>> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
>>> Sent: Thursday, April 09, 2015 3:45 AM
>>>
>>> Intead of clobbering DMAR -> XMAR and back, clobber to RMAD instead.
>>> This
>>> means that changing the signature does not alter the checksum, which allows
>>> the clobbering/unclobbering to be peformed atomically and idempotently,
>>> which
>>> is an advantage on the kexec path which can reenter acpi_dmar_reinstate().
>>>
>>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> CC: Yang Zhang <yang.z.zhang@xxxxxxxxx>
>>> CC: Kevin Tian <kevin.tian@xxxxxxxxx>
>> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx>
>>
>> and curious do you observe a real atomic issue in kexec or just catch this
>> potential issue when reading code? :-)
> 
> I have run over it once in the past, but mainly it is one small thing on
> a very long list of tweaks to make the crash path for reliable.
> 
> As indicated in the other thread, I think the best direction moving
> forwards is to see about positively preventing dom0 having access,
> rather than simply hiding the table, but that is a job for another time.

And possibly not doable, as this might crash Dom0. What made me
wonder for a very long time though is why similar clobbering isn't
needed for AMD.

In any event, David's point of the now chosen signature perhaps
posing a higher risk of colliding with a real table is an issue that
shouldn't have been discarded before committing. Unless Kevin or
Yang object, I'd therefore suggest reverting the change. Once
we determined why VT-d needs what AMD Vi doesn't need, and
once we settled on the risk of name collision (perhaps using an
underscore prefixed name would further reduce this risk), we could
then do this another way (zap the table from XSDT/RSDT instead?),
or leave it as it was without the change.

(Apart from the above I also don't really see why RMAD was
chosen - this doesn't really resemble anything similar to DMAR
except for using the same letters. If at least it had been the
properly reversed string ...)

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel