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 A4973C636D6 for ; Thu, 23 Feb 2023 01:21:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232867AbjBWBVd (ORCPT ); Wed, 22 Feb 2023 20:21:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232382AbjBWBVc (ORCPT ); Wed, 22 Feb 2023 20:21:32 -0500 Received: from mail-pl1-x64a.google.com (mail-pl1-x64a.google.com [IPv6:2607:f8b0:4864:20::64a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2653C199CC for ; Wed, 22 Feb 2023 17:21:29 -0800 (PST) Received: by mail-pl1-x64a.google.com with SMTP id u15-20020a17090341cf00b0019af23e69dcso4527203ple.19 for ; Wed, 22 Feb 2023 17:21:29 -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=Utax3e55p3N2FiK+44m4EPF0IspqZNOsObveiGZKnps=; b=qEb0sRMMQP+D3NIM0EavDhPqQ4MvMH/BkwStlAQZrjsNxsvp5AK1UfYEygcyPWPwJL aw+JkiEqI0Wk8zGQmrouiI1z4upjRMubH9ZbMcD4DfUtX9Kh6wziQif1uoq55HTC3OnT FkqnuFlPOv90b4F9aF2KaT24ghCOlh+8WCOGn6hLcFk+lS1tpcpAs56CWVfDHEhq5Ah+ M5mzL9C5YTPTLkTiGKHI6Qe115kFoyX58YgaW0qYBkv6o9AziLvKdimHbPOGepgb44h4 mzvdFkwJ0UuukAL7MBFDuYqBQ7qmF7FQJtSZrsAyl+BiB9B4nmX4rvZmwl8TcRhOvWlG zxDw== 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=Utax3e55p3N2FiK+44m4EPF0IspqZNOsObveiGZKnps=; b=yKRLcx/5Nithnw0w+8CHKmAHkYs6DUIOOgLg5ApeBDwUV4lyEmQ7FUXDKd+BYCQRbO SWoIcExM1FE+WGI/a66bVQGKTzSCkLxBgwFVa6Bs+VKWXtRFCNekmgzghiOUKe/1+m9T bxv11BymuJ8Oc6NzOBULSQehWh2SC/y+R7UBbpNf+9rI0+uhpK5F+J/qN7mQTlCPIwgE M2eDcdQdygYVjXOeAPCeQoabKTZUG2kjMDXNtj5nSPZYewt4S4fBbmhyiReghRTagaQW 9oKKdtilzf/TXIFEOjM2i2si8Fd9boVoJwTXfpqanOeWEodr236McYyBvUDGlmWlrjbZ hvYA== X-Gm-Message-State: AO0yUKWDXhqc95Nb+gy5yvO2X7cOi6RwFRKKT+pnI9I8VXZb4R4AVrnh sq3yLPL54F7rWrHrMnhMm7wjPiS1+JA= X-Google-Smtp-Source: AK7set8uqJFTeifQRndK5OY7LsjNYEZihFhZGcRxMmqtrSL2SRl7UXNO3Bil4Wyqwogd1sRe6etbqkK7/G4= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a65:66c6:0:b0:4fc:1da2:5f95 with SMTP id c6-20020a6566c6000000b004fc1da25f95mr1307512pgw.7.1677115288904; Wed, 22 Feb 2023 17:21:28 -0800 (PST) Date: Wed, 22 Feb 2023 17:21:27 -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: Borislav Petkov Cc: "Michael Kelley (LINUX)" , Dave Hansen , "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-hyperv@vger.kernel.org On Thu, Feb 23, 2023, Borislav Petkov wrote: > On Wed, Feb 22, 2023 at 02:54:47PM -0800, Sean Christopherson wrote: > > Why? I genuinely don't understand the motivation for bundling all of this stuff > > under a single "feature". > > It is called "sanity". > > See here: > > https://lore.kernel.org/r/Y%2B5immKTXCsjSysx@zn.tnic > > We support SEV, SEV-ES, SEV-SNP, TDX, HyperV... guests and whatever's > coming down the pipe. And all that goes into arch/x86/ kernel proper > code. > > The CC_ATTR stuff is clean-ish in the sense that we have separation by > confidential computing platform - AMD's and Intel's. Hyper-V comes along > and wants to define a different subset of that. And that's only the > SEV-SNP side - there's a TDX patchset too. > > And then some other hypervisor will come along and say, but but, I wanna > have X and Y and a pink pony too. > > Oh, and there's this other fun with MTRRs where each HV decides to do > whatever it wants. The MTRR mess isn't unique to coco guests, e.g. KVM explicitly "supports" VMMs hiding MTTRs from the guest by defaulting to WB if MTTRs aren't exposed to the guest. Why on earth Hyper-V suddenly needs to enlighten the guest is beyond me, but whatever the reason, it's not unique to coco VMs. > So, we have a zoo brewing on the horizon already! > > If there's no clean definition of what each guest is and requires and > that stuff isn't documented properly and if depending on which "feature" > I need to check, I need to call a different function or query > a different variable, then it won't go anywhere as far as guest support > goes. > > The cc_platform_has() thing gives us a relatively clean way to abstract > all those differences away and keep the code sane-ish. For features that are inherent to the platform, I agree, or at least I don't hate the interface. But defining a platform to have specific devices runs counter to pretty much the entire x86 ecosystem. At some point, there _will_ be more devices in private memory than just IO-APIC and TPM, and conversely there will be "platforms" that support a trusted TPM but not a trusted IO-APIC, and probably even vice versa. All I'm advocating is that for determining whether or not a device should be mapped private vs. shared, provide an API so that the hypervisor-specific enlightened code can manage that insanity without polluting common code. If we are ever fortunate enough to have common enumeration, e.g. through ACPI or something, the enlightened code can simply reroute to the common code. This is a well established pattern for many paravirt features, I don't see why it wouldn't work here.