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;
Cc:     baolu.lu@linux.intel.com, iommu@lists.linux-foundation.org,
        x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] iommu/vt-d bad RMRR workarounds
To:     Barret Rhoden <brho@google.com>,
        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>
References: <20191211194606.87940-1-brho@google.com>
From:   Lu Baolu <baolu.lu@linux.intel.com>
Message-ID: <35f49464-0ce5-9998-12a0-624d9683ea18@linux.intel.com>
Date:   Thu, 12 Dec 2019 10:43:45 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.1
MIME-Version: 1.0
In-Reply-To: <20191211194606.87940-1-brho@google.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi,

On 12/12/19 3:46 AM, Barret Rhoden via iommu wrote:
> I can imagine a bunch of ways around this.
> 
> One option is to hook in a check for buggy RMRRs in intel-iommu.c.  If
> the base and end are 0, just ignore the entry.  That works for my
> specific buggy DMAR entry.  There might be other buggy entries out
> there.  The docs specify some requirements on the base and end (called
> limit) addresses.
> 
> Another option is to change the sanity check so that unmapped ranges are
> considered OK.  That would work for my case, but only because we're
> hiding the firmware bug: my DMAR has a bad RMRR that happens to fall into a
> reserved or non-existent range.  The downside here is that we'd
> presumably be setting up an IOMMU mapping for this bad RMRR.  But at
> least it's not pointing to any RAM we're using.  (That's actually what
> goes on in the current, non-kexec case for me.  Phys page 0 is marked
> RESERVED, and I have an RMRR that points to it.)  This option also would
> cover any buggy firmwares that use an actual RMRR that pointed to memory
> that was omitted from the e820 map.
> 
> A third option: whenever the RMRR sanity check fails, just ignore it and
> return 0.  Don't set up the rmrru.  Right now, we completely abort DMAR
> processing.  If there was an actual device that needed to poke this
> memory that failed the sanity check (meaning, not RESERVED, currently),
> then we're already in trouble; that device could clobber RAM, right?  If
> we're going to use the IOMMU, I'd rather the device be behind an IOMMU
> with*no*  mapping for the region, so it couldn't clobber whatever we
> happened to put in that location.
> 
> I actually think all three options are reasonable ideas independently of
> one another.  This patchset that does all three.  Please take at least
> one of them.  =)  (May require a slight revision if you don't take all
> of them).

The VT-d spec defines the BIOS considerations about RMRR in section 8.4:

"
BIOS must report the RMRR reported memory addresses as reserved (or as
EFI runtime) in the system memory map returned through methods such as
INT15, EFI GetMemoryMap etc.
"

So we should treat it as firmware bug if the RMRR range is not mapped as
RESERVED in the system memory map table.

As for how should the driver handle this case, ignoring buggy RMRR with
a warning message might be a possible choice.

Best regards,
baolu