Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp664276ybh; Tue, 10 Mar 2020 06:07:18 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsQ+B1nfz7hwxaqdCOOvsjsmeGaU4WE9ZsP9BiM/5i9KqKdj7u7gz5y2iSSgNDahXdWyWxm X-Received: by 2002:aca:ebc5:: with SMTP id j188mr1083897oih.65.1583845638060; Tue, 10 Mar 2020 06:07:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583845638; cv=none; d=google.com; s=arc-20160816; b=s6DMzcYyuJsfcGzkRvWAZYrpcmHvk7EEvlzRSz7PyajtSiFxJbZFlgNAx1FHcN5HYu VmqX5SD9eYXZ4JpQcd53l8dhUi1qd3MaOjhTIYfXBy1DVQs33tn6Aep9zeeBLxWbr7fq M/ypPy2dynrQBFyzeWpZbQdwalgQ+IJhT1cElPps5oXdBDeNUF3DRh8jzyF64l3dPUna 70jPN+7PyMRZzsyPWC7spH1qQ6q8Y32ZeaoUTEqKzkXi34MYTCgwa12fJ0P8zuGzZ9dZ JtAJmDrmxdNEFQF2Dq8OosdUh2Fv5/z9rqCe+uCitwES7y7qH1ROvGcUIQmOMqMJTsbX DlaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=QGgC2n1tQf5+F1vIk74KLXtETvuVTXFdeNCcHrA7p40=; b=GNMFrcymVLbV0mBZog+d3L+EtpsumBOeAayhPA2tXhMzh9GwqVySKglHBSL0h+VAqI vj7PrLAwmzr4Sls1BwrvtSTcID/sGUNyZ3zhADQv4e2+sbDwf06HBCr5f8d77n4FMMDt qaP595TMP8wNgMbAlpFT+QR6meXoiIIBpEq+keRbkLHgn6phn+EbUg0NBuJtIwVWQKHK ZFPBCsV2YaYfgwWnONBmOUbVEopOdFp8C5kYgLdjP9WutLYNrOePBjqwgiSVppMSOf8w 0ak44ntRcCXNpfKcloDl8Za4oEeglRCEnfV9QlF1VPXbUvYIVeVp4AquiJHzvrVGyuNY fwCQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i6si7316354oth.182.2020.03.10.06.06.46; Tue, 10 Mar 2020 06:07:18 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730206AbgCJND3 (ORCPT + 99 others); Tue, 10 Mar 2020 09:03:29 -0400 Received: from mx2.suse.de ([195.135.220.15]:49684 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730578AbgCJNDZ (ORCPT ); Tue, 10 Mar 2020 09:03:25 -0400 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 9D0CEAECA; Tue, 10 Mar 2020 13:03:23 +0000 (UTC) Date: Tue, 10 Mar 2020 14:03:21 +0100 From: Joerg Roedel To: Borislav Petkov Cc: Tom Lendacky , linux-kernel@vger.kernel.org, x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Bruce Rogers Subject: Re: [PATCH] x86/ioremap: Map EFI runtime services data as encrypted for SEV Message-ID: <20200310130321.GH7028@suse.de> References: <2d9e16eb5b53dc82665c95c6764b7407719df7a0.1582645327.git.thomas.lendacky@amd.com> <20200310124003.GE29372@zn.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200310124003.GE29372@zn.tnic> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 10, 2020 at 01:40:03PM +0100, Borislav Petkov wrote: > On Tue, Feb 25, 2020 at 09:42:07AM -0600, Tom Lendacky wrote: > > @@ -135,6 +135,13 @@ static void __ioremap_check_mem(resource_size_t addr, unsigned long size, > > memset(desc, 0, sizeof(struct ioremap_desc)); > > > > walk_mem_res(start, end, desc, __ioremap_collect_map_flags); > > + > > + /* > > + * The EFI runtime services data area is not covered by walk_mem_res(), > > + * but must be mapped encrypted when SEV is active. > > + */ > > + if (sev_active() && efi_mem_type(addr) == EFI_RUNTIME_SERVICES_DATA) > > + desc->flags |= IORES_MAP_ENCRYPTED; > > } > > Why isn't this done in __ioremap_check_encrypted() which is exactly for > SEV stuff like that? See the comment added in the patch, walk_mem_res() does not iterate over the resource which contains EFI_RUNTIME_SERVICES_DATA, so __ioremap_check_encrypted() will not be called on that resource. walk_system_ram_range() might do the job, but calling it only for EFI_RUNTIME_SERVICES_DATA has some overhead. Regards, Joerg