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 2C049C636D7 for ; Fri, 10 Feb 2023 19:37:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232834AbjBJTg6 (ORCPT ); Fri, 10 Feb 2023 14:36:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42834 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233329AbjBJTgw (ORCPT ); Fri, 10 Feb 2023 14:36:52 -0500 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0542C30DF; Fri, 10 Feb 2023 11:36:50 -0800 (PST) Received: from zn.tnic (p5de8e9fe.dip0.t-ipconnect.de [93.232.233.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 8DDB11EC050D; Fri, 10 Feb 2023 20:36:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1676057808; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=MCUnDKhNZsvKrZ9QNPESgINSnYhmEBzZTjPQK8LCLnU=; b=i+NQevbA7LtkcbzT2PGrHbq2DIT6X25Rbd3CXV09Dc8ZWcx1vQup1zkH2Wpg/6volIOuly w90ABVMsvyrZ3owzfQHkr/9UmrAgXII6VE6w3OMVsa2PMGUtxuNxfGs3vztWu4Sd2Go3gP +Ir4ttC/7lxJLRG0dghM2/nPfHpGz+I= Date: Fri, 10 Feb 2023 20:36:44 +0100 From: Borislav Petkov To: "Michael Kelley (LINUX)" Cc: Sean Christopherson , 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" Subject: Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted Message-ID: References: <4216dea6-d899-aecb-2207-caa2ae7db0e3@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 10, 2023 at 07:15:41PM +0000, Michael Kelley (LINUX) wrote: > FWIW, I don't think the list of devices to be accessed encrypted is likely > to grow significantly. Is one or two more possible? Perhaps. Does it > become a list of ten? I doubt it. What happens if the next silly HV guest scheme comes along and they do need more and different ones? Do I say, but but, Michael said that he doubted at the time that that list would grow... ;-\ And then all our paths are sprinkled with if (cc_platform_has()) and we can't change sh*t anymore out of fear that some weird guest type will break. > One approach is to go with the individual device attributes for now. > If the list does grow significantly, there will probably be patterns > or groupings that we can't discern now. We could restructure into > larger buckets at that point based on those patterns/groupings. There's a reason the word "platform" is in cc_platform_has(). Initially we wanted to distinguish attributes of the different platforms. So even if y'all don't like CC_ATTR_PARAVISOR, that is what distinguishes this platform and it *is* one platform. So call it CC_ATTR_SEV_VTOM as it uses that technology or whatever. But call it like the platform, not to mean "I need this functionality". And yes, we could do the regroupings later because, yeah, those things are not exposed to userspace so it's not like they're cast in stone but I fear that we will do regroupings and we will break guests. Now if you had CC_ATTR_ then you break (or not) only that platform. Oh, and then there's the thing that this is kernel proper - that code still runs on real hardware, for now, and is not only guests. And not everything is a damn cloud. So I don't want a zoo here and we'd have to agree to distinguish by platform and not by different functionality required. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette