Re: [PATCH] VT-d: Tylersburg errata apply to further steppings

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.08.2021 15:30, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 03, 2021 at 03:16:14PM +0200, Jan Beulich wrote:
>> On 03.08.2021 15:12, Marek Marczykowski-Górecki wrote:
>>> On Tue, Aug 03, 2021 at 03:06:50PM +0200, Jan Beulich wrote:
>>>> On 03.08.2021 15:01, Marek Marczykowski-Górecki wrote:
>>>>> Ok, then, just setting iommu_intremap=false should do the right thing,
>>>>
>>>> ... if "iommu=force" is in use (but not otherwise), ...
>>>
>>> But that's the purpose of iommu=force, no?
>>> With "iommu=force": strictly require IOMMU
>>> Without "iommu=force": use IOMMU on best-effort basis
>>>
>>> It makes sense to refuse the boot if intremap is broken in the first
>>> case. But also, it makes sense to allow using IOMMU without intremp in
>>> the second case.
>>
>> I agree with both statements. What I disagree with is that the latter
>> happens by default (instead of only upon admin override), including
>> the case of intremap being unavailable in the first place.
> 
> "upon admin override" - do I read the code right, that iommu=no-intremap
> will actually achieve this effect?

In the case of this quirk - yes, as the call to the checking function is
gated by a check of iommu_intremap. But by "admin override" I meant a
per-guest attribute, not a host-wide one that isn't explicitly meant to
cover all guests.

> Will that allow to use IOMMU without
> interrupt remapping on a hardware where it's broken? In that case, maybe
> at least add this info to the log message?

You mean to suggest the use of this option? I'd rather not, to be honest.
I don't think options like this should be suggested to be used. I'd
prefer if we had less of such options, i.e. if they went away after some
initial integration phase.

Jan