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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4828AC61DA4 for ; Thu, 23 Feb 2023 21:07:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229596AbjBWVHw (ORCPT ); Thu, 23 Feb 2023 16:07:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229516AbjBWVHv (ORCPT ); Thu, 23 Feb 2023 16:07:51 -0500 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8278057D05 for ; Thu, 23 Feb 2023 13:07:47 -0800 (PST) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-536d63d17dbso129850027b3.22 for ; Thu, 23 Feb 2023 13:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=eDy3vPr0qJRCA9dsWL1NmUMORzwIvttYPURltbFZMpc=; b=qsPE+UzcPzty9BFn6i2GGc1XS/LiY6mDx3u6bSw5CfBlMQflGXG8kD42uIiEB2AWNS 4dFUL7wB9tqtDXyvHDP+y2oMv5JEqfp+WjLmt3Ziws78zc75n0eoHhz+4OyJu7ZL+4T1 6yYwYADt4nzJNT/7/KFqstg5HWZXn3wfcyGrx5q+gj0GT/l68gf4/17J3Y2cfdstZgul lhULaPr7fDFDDnymEJPnUoWZ7fXQrAc+3tn4oGGFz2WbB8+AuiVQ7JQo+ubZHRBNMNAd GZbmLVvMXHX7kdehsO+emNo4UTDXbxZPFnUI9LcMiMG0NWB/G9TQhtlG8zqj5wASBmr9 nqAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eDy3vPr0qJRCA9dsWL1NmUMORzwIvttYPURltbFZMpc=; b=l9NE/+keCRr79gvto8rbOcFi7DzD/uboF+5cwLxqRtcwIaUev4BHhZPxXwHMZnz4Cv l4NzOtPZWPMy5gp3EFvHqF5qJzHQ16zsQUrqptUjtVgxqe0JpcQv7g/+jjxXcrMZ5qnd /9TjZmw4tR7LfxB5uw9X607Tq3pQXx5wxh+CwzyUiDnDD/F7PVxpEqO/xTgauWuUERJK ycEN2MFGFX+GxNdKT2AHl15NF+5nN/0ePb1yeELMDma0D/Xv27TImtBIpcbcuzZSMFvM B8gSpO8fIMNjFKHAsNZ2c3XP9K3nes29uK3dsgB7OsENQ+rYl6FAMr86y+FTRWb78IHE SL2g== X-Gm-Message-State: AO0yUKXXtcmfeT/bcVytrj0SteoTzzxVE3WYsRQNyc9YifSZZZEFr0lp P/QVcgbzXOaWHJoFpb4wogewB4ciCvg= X-Google-Smtp-Source: AK7set89gIznAxeDfaUj5caiC9RMffToP6dOxix8kVKieHwPx9MzyFKOjKWtkt7UHWZt7FyQXZHW+fjVykA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6902:287:b0:8de:ddd5:7f8e with SMTP id v7-20020a056902028700b008deddd57f8emr2447294ybh.4.1677186466736; Thu, 23 Feb 2023 13:07:46 -0800 (PST) Date: Thu, 23 Feb 2023 13:07:45 -0800 In-Reply-To: Mime-Version: 1.0 References: Message-ID: Subject: Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted From: Sean Christopherson To: "Michael Kelley (LINUX)" Cc: Dave Hansen , Borislav Petkov , "hpa@zytor.com" , KY Srinivasan , Haiyang Zhang , "wei.liu@kernel.org" , Dexuan Cui , "luto@kernel.org" , "peterz@infradead.org" , "davem@davemloft.net" , "edumazet@google.com" , "kuba@kernel.org" , "pabeni@redhat.com" , "lpieralisi@kernel.org" , "robh@kernel.org" , "kw@linux.com" , "bhelgaas@google.com" , "arnd@arndb.de" , "hch@lst.de" , "m.szyprowski@samsung.com" , "robin.murphy@arm.com" , "thomas.lendacky@amd.com" , "brijesh.singh@amd.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "dave.hansen@linux.intel.com" , Tianyu Lan , "kirill.shutemov@linux.intel.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "ak@linux.intel.com" , "isaku.yamahata@intel.com" , "dan.j.williams@intel.com" , "jane.chu@oracle.com" , "tony.luck@intel.com" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-arch@vger.kernel.org" , "iommu@lists.linux.dev" Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, Feb 23, 2023, Michael Kelley (LINUX) wrote: > From: Dave Hansen Sent: Thursday, February 23, 2023 12:42 PM > > > > On 2/23/23 12:26, Dave Hansen wrote: > > >> + if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) { > > >> + /* > > >> + * Ensure fixmaps for IOAPIC MMIO respect memory encryption pgprot > > >> + * bits, just like normal ioremap(): > > >> + */ > > >> + if (x86_platform.hyper.is_private_mmio(phys)) > > >> + flags = pgprot_encrypted(flags); > > >> + else > > >> + flags = pgprot_decrypted(flags); > > >> + } > > ... > > > It does seem a bit odd that there's a new CC_ATTR_GUEST_MEM_ENCRYPT > > > check wrapping this whole thing. I guess the trip through > > > pgprot_decrypted() is harmless on normal platforms, though. > > > > Yeah, that's _really_ odd. Sean, were you trying to optimize away the > > indirect call or something? No, my thought was simply to require platforms that support GUEST_MEM_ENCRYPT to implement x86_platform.hyper.is_private_mmio, e.g. to avoid having to check if is_private_mmio is NULL, to explicit document that non-Hyper-V encrypted guests don't (yet) support private MMIO, and to add a bit of documentation around the {de,en}crypted logic. > > I would just expect the Hyper-V/vTOM code to leave > > x86_platform.hyper.is_private_mmio alone unless it *knows* the platform has > > private MMIO *and* CC_ATTR_GUEST_MEM_ENCRYPT. > > Agreed. > > > > > Is there ever a case where CC_ATTR_GUEST_MEM_ENCRYPT==0 and he > > Hyper-V/vTOM code would need to set x86_platform.hyper.is_private_mmio? > > There's no such case. > > I agree that gating with CC_ATTR_GUEST_MEM_ENCRYPT isn't really necessary. > Current upstream code always does the pgprot_decrypted(), and as you said, > that's a no-op on platforms with no memory encryption. Right, but since is_private_mmio can be NULL, unless I'm missing something we'll need an extra check no matter what, i.e. the alternative would be if (x86_platform.hyper.is_private_mmio && x86_platform.hyper.is_private_mmio(phys)) flags = pgprot_encrypted(flags); else flags = pgprot_decrypted(flags); I have no objection to that approach. It does have the advantage of not needing an indirect call for encrypted guests that don't support private MMIO, though I can't imagine this code is performance sensitive.