Re: [Xen-devel] [PATCH v2] x86 / iommu: set up a scratch page in the quarantine domain

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.12.2019 10:16, Durrant, Paul wrote:
>> -----Original Message-----
>> From: Jürgen Groß <jgross@xxxxxxxx>
>> Sent: 10 December 2019 09:07
>> To: Jan Beulich <jbeulich@xxxxxxxx>
>> Cc: Tian, Kevin <kevin.tian@xxxxxxxxx>; Durrant, Paul
>> <pdurrant@xxxxxxxxxx>; Andrew Cooper <andrew.cooper3@xxxxxxxxxx>; xen-
>> devel@xxxxxxxxxxxxxxxxxxxx; Roger Pau Monné <roger.pau@xxxxxxxxxx>; Wei
>> Liu <wl@xxxxxxx>
>> Subject: Re: [PATCH v2] x86 / iommu: set up a scratch page in the
>> quarantine domain
>>
>> On 10.12.19 09:57, Jan Beulich wrote:
>>> On 10.12.2019 09:12, Jürgen Groß wrote:
>>>> On 10.12.19 09:05, Jan Beulich wrote:
>>>>> On 10.12.2019 08:16, Tian, Kevin wrote:
>>>>>> While the quarantine idea sounds good overall, I'm still not
>> convinced
>>>>>> to have it the only way in place just for handling some known-buggy
>>>>>> device. It kills the possibility of identifying a new buggy device
>> and then
>>>>>> deciding not to use it in the first space... I thought about whether
>> it
>>>>>> will get better when future IOMMU implements A/D bit - by checking
>>>>>> access bit being set then we'll know some buggy device exists, but,
>>>>>> the scratch page is shared by all devices then we cannot rely on this
>>>>>> feature to find out the actual buggy one.
>>>>>
>>>>> Thinking about it - yes, I think I agree. This (as with so many
>>>>> workarounds) would better be an off-by-default one. The main issue
>>>>> I understand this would have is that buggy systems then might hang
>>>>> without even having managed to get a log message out - Paul?
>>>>>
>>>>> Jürgen - would you be amenable to an almost last minute refinement
>>>>> here (would then also need to still be backported to 4.12.2, or
>>>>> the original backport reverted, to avoid giving the impression of
>>>>> a regression)?
>>>>
>>>> So what is your suggestion here? To have a boot option (defaulting to
>>>> off) for enabling the scratch page?
>>>
>>> Yes (and despite having seen Paul's reply).
>>
>> I'd release ack such a patch in case you come to an agreement regarding
>> the default soon.
>>
> 
> Ok. The default is not that crucial. Perhaps it's just me who thinks
> defaults should be chosen on the basis of being most likely to result
> in a working system.

If it wasn't for quirky hardware (or firmware to cover the general case,
in particular to avoid getting quoted on this wrt my position on EFI
workarounds), I'd agree. But personally I think Kevin's point takes
priority here: Admins should at least be aware of running quirky
hardware, and hence I'd prefer the default to be logging of faults
rather than their silencing. Documentation of the new (sub-)option may
give suitable hints, and we may even go as far as providing a Kconfig
option for the default to be chosen at build time.

Main question now is - who's going to make a patch? Will you? Should I?

Jan

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