From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0168DC4360C for ; Wed, 16 Oct 2019 07:51:27 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C9DC22082C for ; Wed, 16 Oct 2019 07:51:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C9DC22082C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=8bytes.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id AC9C9A70; Wed, 16 Oct 2019 07:51:26 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AB9C5949 for ; Wed, 16 Oct 2019 07:51:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from theia.8bytes.org (8bytes.org [81.169.241.247]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 69FA55D3 for ; Wed, 16 Oct 2019 07:51:24 +0000 (UTC) Received: by theia.8bytes.org (Postfix, from userid 1000) id BDA7845B; Wed, 16 Oct 2019 09:51:22 +0200 (CEST) Date: Wed, 16 Oct 2019 09:51:21 +0200 From: Joerg Roedel To: Yian Chen Subject: Re: [PATCH] iommu/vt-d: Check VT-d RMRR region in BIOS is reported as reserved Message-ID: <20191016075120.GB32232@8bytes.org> References: <20191015164932.18185-1-yian.chen@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20191015164932.18185-1-yian.chen@intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Tony Luck , linux-ia64@vger.kernel.org, Ashok Raj , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, David Woodhouse X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org Hi, On Tue, Oct 15, 2019 at 09:49:32AM -0700, Yian Chen wrote: > VT-d RMRR (Reserved Memory Region Reporting) regions are reserved > for device use only and should not be part of allocable memory pool of OS. > > BIOS e820_table reports complete memory map to OS, including OS usable > memory ranges and BIOS reserved memory ranges etc. > > x86 BIOS may not be trusted to include RMRR regions as reserved type > of memory in its e820 memory map, hence validate every RMRR entry > with the e820 memory map to make sure the RMRR regions will not be > used by OS for any other purposes. Are there real systems in the wild where this is a problem? > +static inline int __init > +arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr) > +{ > + u64 start = rmrr->base_address; > + u64 end = rmrr->end_address + 1; > + > + if (e820__mapped_all(start, end, E820_TYPE_RESERVED)) > + return 0; > + > + pr_err(FW_BUG "No firmware reserved region can cover this RMRR [%#018Lx-%#018Lx], contact BIOS vendor for fixes\n", > + start, end - 1); > + return -EFAULT; > +} Why -EFAULT, there is no fault involved? Usibg -EINVAL seems to be a better choice. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu