Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue,  7 Jan 2020 14:16:08 -0500
Message-Id: <20200107191610.178185-1-brho@google.com>
Mime-Version: 1.0
Subject: [PATCH v2 0/2] iommu/vt-d bad RMRR workarounds
From:   Barret Rhoden <brho@google.com>
To:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Joerg Roedel <joro@8bytes.org>,
        Yian Chen <yian.chen@intel.com>,
        Sohil Mehta <sohil.mehta@intel.com>
Cc:     linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
        x86@kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Commit f036c7fa0ab6 ("iommu/vt-d: Check VT-d RMRR region in BIOS is
reported as reserved") caused a machine to fail to boot for me, but only
after a kexec.

Buggy firmware provided an RMRR entry with base and end both == 0.  That
is an invalid RMRR format, and only happens to pass the RMRR sanity
check.  After a kexec, that entry fails the RMRR sanity check, due to a
slight change in the first e820 mapping.  See the v1 link for details.

v1->v2:
v1: https://lore.kernel.org/lkml/20191211194606.87940-1-brho@google.com/
- Added the TAINT_FIRMWARE_WORKAROUND
- Dropped the commit that treated missing e820 regions as "RMRR OK"


Barret Rhoden (2):
  iommu/vt-d: skip RMRR entries that fail the sanity check
  iommu/vt-d: skip invalid RMRR entries

 drivers/iommu/intel-iommu.c | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

-- 
2.24.1.735.g03f4e72817-goog