AMD/IOMMU: drop command completion timeout
authorJan Beulich <jbeulich@suse.com>
Tue, 8 Jun 2021 17:19:29 +0000 (18:19 +0100)
committerAndrew Cooper <andrew.cooper3@citrix.com>
Tue, 8 Jun 2021 17:36:03 +0000 (18:36 +0100)
commit51278ce831a8fcc4ffb4c841e3442de3fd4ea76b
treeae2519f40ea1d8292731bd4e2965af63ce4d4712
parent766b1f447314dd5e8f14c540440cbfc080f3b998
AMD/IOMMU: drop command completion timeout

First and foremost - such timeouts were not signaled to callers, making
them believe they're fine to e.g. free previously unmapped pages.

Mirror VT-d's behavior: A fixed number of loop iterations is not a
suitable way to detect timeouts in an environment (CPU and bus speeds)
independent manner anyway. Furthermore, leaving an in-progress operation
pending when it appears to take too long is problematic: If a command
completed later, the signaling of its completion may instead be
understood to signal a subsequently started command's completion.

Log excessively long processing times (with a progressive threshold) to
have some indication of problems in this area. Allow callers to specify
a non-default timeout bias for this logging, using the same values as
VT-d does, which in particular means a (by default) much larger value
for device IO TLB invalidation.

This is part of XSA-373 / CVE-2021-28692.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul@xen.org>
(cherry picked from commit e4fee66043120c954fc309bbb37813604c1c0eb7)
xen/drivers/passthrough/amd/iommu_cmd.c