Re: [RFC PATCH] iommu: make no-quarantine mean no-quarantine

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.04.2021 09:19, Paul Durrant wrote:
> On 28/04/2021 07:15, Jan Beulich wrote:
>> Following the extension to the command line option I'm putting in place
>> in "IOMMU: make DMA containment of quarantined devices optional" (which
>> I still need to get around to address review feedback for and resubmit),
>> I'd be inclined to suggest "iommu=quarantine=always" or
>> "iommu=quarantine=on-assign". Unless of course we'd prefer to have the
>> caller of the assignment operation have full control over the behavior
>> here anyway (in which case a command line option control simply is not
>> necessary).
>>
> 
> I'm still not entirely sure why not quarantining on is a problem,

Well, I continue to think that it is a mistake to hide problems (with
their hardware) from system administrators by default. I guess most
everyone else put usability in foreground, as my view to workarounds
(with non-benign [side-]effects) being enabled by default looks to be
generally different.

> other 
> than it triggering an as-yet undiagnosed issue in QEMU, but I agree that 
> that the expectation of 'no-quarantine' meaning just that (i.e. the old 
> dom0->domU and domU->dom0 transitions are re-instated) is reasonable.

I'm afraid I'm not clear what you're talking about here. What "old
transitions"? The ones prior to the introduction of quarantining? If
so, and if the tool stack is given (some level of) control, I guess
we'd first need to establish who "rules": The command line option,
or the tool stack (which imo ought to be acting whichever particular
way based on admin requests, not to blindly override Xen's defaults).

> Do we really want yet more command line options?

If we can avoid them without sacrificing functionality / flexibility ...

Jan