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 C9F74C636D7 for ; Thu, 23 Feb 2023 10:45:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233670AbjBWKp1 (ORCPT ); Thu, 23 Feb 2023 05:45:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233253AbjBWKpY (ORCPT ); Thu, 23 Feb 2023 05:45:24 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AFB9628D0B; Thu, 23 Feb 2023 02:45:23 -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 2A7101EC06D8; Thu, 23 Feb 2023 11:45:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1677149121; 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=8eflZCArBNS2iTHAutvusXrIThQ3jEI6ZgIoi6B+se4=; b=phohTQQkWdVgEHvajC+jqND3J6RrHkQAfEY26jsta89saiUXDjpax72/t8uzsykiPJTRAp wELV5m3c0rpFSuB9kPVe4/xWfwZUbq0+qD7UZZAn5zsd6GJrzIJJ4KLaNv+bRBAxyk8yY4 05KPHD5NTscdl5DEOeJB5BZsKM8fqEU= Date: Thu, 23 Feb 2023 11:45:17 +0100 From: Borislav Petkov To: Sean Christopherson 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" Subject: Re: [PATCH v5 06/14] x86/ioremap: Support hypervisor specified range to map as encrypted Message-ID: References: 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 Wed, Feb 22, 2023 at 05:21:27PM -0800, Sean Christopherson wrote: > 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. Well, TDX can't stomach MTRRs either, reportedly, and I hear we should try to avoid #VEs for them too. And this is the problem: all those guest "enlightening" efforts come up with the weirdest stuff they need to sprinkle around arch/x86/. And if we let that without paying attention to the big picture, that will become an unmaintanable mess. And I'm not proud of some of the stuff we did in arch/x86/ already and some day they'll get on my nerves just enough... > 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. Yah, that would be good. If the device can know upfront how it needs to ioremap its address range, then that is fine - we already have ioremap_encrypted() for example. What I don't like is hooking conditionals into the common code to figure out what to do depending on what we're running on. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette