From patchwork Thu Feb 27 11:14:45 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Beulich X-Patchwork-Id: 11408331 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 517B814E3 for ; Thu, 27 Feb 2020 11:16:05 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (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 319902468F for ; Thu, 27 Feb 2020 11:16:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 319902468F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1j7H7n-0000UX-PG; Thu, 27 Feb 2020 11:14:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1j7H7m-0000US-Gt for xen-devel@lists.xenproject.org; Thu, 27 Feb 2020 11:14:38 +0000 X-Inumbo-ID: 572ab162-5952-11ea-b0f0-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 572ab162-5952-11ea-b0f0-bc764e2007e4; Thu, 27 Feb 2020 11:14:37 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id CA49CAE52; Thu, 27 Feb 2020 11:14:36 +0000 (UTC) To: "xen-devel@lists.xenproject.org" From: Jan Beulich Message-ID: Date: Thu, 27 Feb 2020 12:14:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Language: en-US Subject: [Xen-devel] [PATCH] VT-d: fix and extend RMRR reservation check X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" First of all in commit d6573bc6e6b7 ("VT-d: check all of an RMRR for being E820-reserved") along with changing the function used, the enum- like value passed should have been changed too (to E820_*). Do so now. (Luckily the actual values of RAM_TYPE_RESERVED and E820_RESERVED match, so the breakage introduced was "only" latent.) Furthermore one of my systems surfaces RMRR in an ACPI NVS E820 range. The purpose of the check is just to make sure there won't be "ordinary" mappings of these ranges, and domains (including Dom0) won't want to use the region to e.g. put PCI device BARs there. The two ACPI related E820 types are good enough for this purpose, so allow them as well. Signed-off-by: Jan Beulich Reviewed-by: Kevin Tian --- a/xen/drivers/passthrough/vtd/dmar.c +++ b/xen/drivers/passthrough/vtd/dmar.c @@ -632,7 +632,9 @@ acpi_parse_one_rmrr(struct acpi_dmar_hea * not properly represented in the system memory map and * inform the user */ - if ( !e820_all_mapped(base_addr, end_addr + 1, RAM_TYPE_RESERVED) ) + if ( !e820_all_mapped(base_addr, end_addr + 1, E820_RESERVED) && + !e820_all_mapped(base_addr, end_addr + 1, E820_NVS) && + !e820_all_mapped(base_addr, end_addr + 1, E820_ACPI) ) printk(XENLOG_WARNING VTDPREFIX " RMRR [%"PRIx64",%"PRIx64"] not in reserved memory;" " need \"iommu_inclusive_mapping=1\"?\n",