From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Igor Druzhinin <igor.druzhinin@citrix.com>,
xen-devel@lists.xenproject.org
Cc: Juergen Gross <JGross@suse.com>,
kevin.tian@intel.com, sstabellini@kernel.org,
wei.liu2@citrix.com, konrad.wilk@oracle.com,
George.Dunlap@eu.citrix.com, julien.grall@arm.com,
jbeulich@suse.com
Subject: Re: [PATCH] VT-d/DMAR: accept DRHD with non-discoverable PCI devices
Date: Thu, 21 Mar 2019 13:17:07 +0000 [thread overview]
Message-ID: <574cb5d6-fb95-d8e9-c281-2ed24a2f22a5@citrix.com> (raw)
In-Reply-To: <1553113323-14664-1-git-send-email-igor.druzhinin@citrix.com>
On 20/03/2019 20:22, Igor Druzhinin wrote:
> Since commit dcf41790 ("x86/mmcfg/drhd: Move acpi_mmcfg_init() call
> before calling acpi_parse_dmar()") PCI segment 0 is now known early
> which made the sanity check on DRHD definition structure to work.
> This, in turn, caused a regression on some machines (in particular,
> HP PowerEdge R740 with I/O AT DMA disabled) where IOMMU was explicitly
> disabled due to some internal PCI devices being non-discoverable but
> present in DMAR.
>
> While this is indeed a BIOS mistake it seems to be not that critical
> to disable the whole IOMMU. Instead, extend the scope of
> "workaround_bios_bug" option and make it enabled by default. This is
> consistent with our documentation and actually what a user might expect
> from an option with that name. It also doesn't seem safe to simply ignore
> DRHD without initialization so remove this case. But leave the original
> DMAR check in place to still allow error reporting.
>
> Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
This is code which was previously dead. The behaviour of ignoring an
IOMMU because there is unreachable device behind it is awful and
shouldn't exist, but we should at least leave a trace of it in the logs.
TBH, I'd prefer to delete the `workaround_bios_bug` option entirely, and
just print out the bad entries. Nothing the option does is worthy of
shutting the IOMMU down.
CC-ing Juergen as this is a 4.12 regression.
I can easily spin a patch along my suggested route if others agree.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-03-21 13:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 20:22 [PATCH] VT-d/DMAR: accept DRHD with non-discoverable PCI devices Igor Druzhinin
2019-03-21 13:17 ` Andrew Cooper [this message]
2019-03-21 13:50 ` Juergen Gross
2019-03-21 18:04 ` Igor Druzhinin
2019-03-21 16:55 ` Pasi Kärkkäinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=574cb5d6-fb95-d8e9-c281-2ed24a2f22a5@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JGross@suse.com \
--cc=igor.druzhinin@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien.grall@arm.com \
--cc=kevin.tian@intel.com \
--cc=konrad.wilk@oracle.com \
--cc=sstabellini@kernel.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.