Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp15183236rwb; Mon, 28 Nov 2022 08:47:48 -0800 (PST) X-Google-Smtp-Source: AA0mqf6VZosKQvrNMo+HkAhwcY2Tr4qcgdqS/9Kl7M8TJLtWMPy8VfoG2hLbKLs4KYJ/W5FIXybn X-Received: by 2002:aa7:d34b:0:b0:46a:914c:9bc9 with SMTP id m11-20020aa7d34b000000b0046a914c9bc9mr19633535edr.418.1669654068421; Mon, 28 Nov 2022 08:47:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669654068; cv=none; d=google.com; s=arc-20160816; b=HlYzbFSRpEyvgnCDJ8B+VX/Cb/S2HAMl2+Q6eK13mOSZH5p1wiFOi+qv3VI6hZZT9a it+Ot+i79gDaZ+JV8eahyojXkvn3PTdMwiPQY6IiMiFTRj/3YCQ7vKkftIrM3EeW4AnM JA4laVw7a9XyhgrkENAl26Mp2R5QKRt45VtrFeFGxP6+XNnt8GgbrJpPH3lEfnHaCkas VfnlGOtWnamo9u2O6k69j6WZhhHiMJjzHVdIUIALzMEJaOeBkdIpvjxdCPds4f10gNVu e72ZWd6EjWuavff1jVvGmsAJ3QfGY7/aKzT6/DR2NEO5SWeK8hIE2kGoqPkRU0gTJM6g FMmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=EkSu+bn5/ZdG6Mdy9WEl50uErDZt1Q23YH5+7wiGeAg=; b=Joe7DKWKFCFKgsY3eXZ6h4erdpHtGcn9buVnemaXOktJa+6MmQ4gYs7KhTjL0qmCfY wrl3Vjv1c+lU8Wcq626zPQY+CfM1VoOeuy0ZqGq1/LKDZ+izEwIG4gaW0KJEeTJoyTmy AAg9LZ15rmoCfmNT2dvFIWE7k4AUVvG4521V76LSOzTEIcwqTsGml3lJvajThS3OTudt rNev+9X2Xw6DKq/7TGp21o/tJDcspEFihQVUXn+bCWb/1dTV6Ifjbh6tSJVZ6UYBKpR3 +s7zXHJgOx/JPaZPCJOIc693jexMBkXU5O0JdoMu4/3Q3nKZ6UCYZFNxa2jnCyppdOam LJfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=DblfEotb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z5-20020a056402274500b0045cecdc1fbcsi11989857edd.9.2022.11.28.08.47.25; Mon, 28 Nov 2022 08:47:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=DblfEotb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232592AbiK1Qdq (ORCPT + 85 others); Mon, 28 Nov 2022 11:33:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231560AbiK1Qdn (ORCPT ); Mon, 28 Nov 2022 11:33:43 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A5A0120F4E; Mon, 28 Nov 2022 08:33:42 -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 316F51EC06AC; Mon, 28 Nov 2022 17:33:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1669653221; 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=EkSu+bn5/ZdG6Mdy9WEl50uErDZt1Q23YH5+7wiGeAg=; b=DblfEotbkHNmwa2p8MaGT0cfAGRLMK+vW9sJd37I3B/E+hScXEcT3rlwTevGqgYvTw6YOk OS/2zXzpf0gG1G6P1TZSyLNhxqgSE2qY1ASAQ6JDdC6hnDVheJwoeDtZhMWDVfqQcJwrnq nCCI8Z2KkjwSaOGbQrxrcHjRo+6zFBg= Date: Mon, 28 Nov 2022 17:33:37 +0100 From: Borislav Petkov To: "Michael Kelley (LINUX)" Cc: "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@infradead.org" , "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" , "Williams, Dan J" , "jane.chu@oracle.com" , "seanjc@google.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 v3 07/14] x86/hyperv: Change vTOM handling to use standard coco mechanisms Message-ID: References: <1668624097-14884-1-git-send-email-mikelley@microsoft.com> <1668624097-14884-8-git-send-email-mikelley@microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 28, 2022 at 02:38:11PM +0000, Michael Kelley (LINUX) wrote: > Any further comment on this patch? I think we're agreement. For > this patch series I propose to change the symbol "CC_VENDOR_HYPERV" > to "CC_VENDOR_AMD_VTOM" and the function name > hyperv_cc_platform_has() to amd_vtom_cc_platform_has(). That doesn't sound optimal to me. So, let's clarify things first: those Isolation VMs - are they going to be the paravisors? I don't see any other option because the unmodified guest must be some old windoze.... So, if they're going to be that, then I guess this should be called CC_ATTR_PARAVISOR to denote that it is a thin layer of virt gunk between an unmodified guest and a hypervisor. And if TDX wants to do that too later, then they can use that flag too. Yes, no? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette