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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C51FC49EA7 for ; Thu, 24 Jun 2021 12:54:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5D0C1613EC for ; Thu, 24 Jun 2021 12:54:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231707AbhFXM5K (ORCPT ); Thu, 24 Jun 2021 08:57:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231262AbhFXM5J (ORCPT ); Thu, 24 Jun 2021 08:57:09 -0400 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BC5FC061574; Thu, 24 Jun 2021 05:54:50 -0700 (PDT) Received: from zn.tnic (p200300ec2f0c1e00b0ee742129e64455.dip0.t-ipconnect.de [IPv6:2003:ec:2f0c:1e00:b0ee:7421:29e6:4455]) (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 935E01EC034B; Thu, 24 Jun 2021 14:54:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1624539288; 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=exWGaN5nlDIIfjw6LKdL5i6bEdP3AlfmgKU5Qi35VZs=; b=OH1tJ1FWIwOyqk5pV85F5ISFN32aCDPduQ56E4e2jBVYcAbLhc0k5JTE+UAy+Gb/l4bjer 2TbZqRl2XDUp7GrXFn0hfpBqzyIwDdJKoBHOLDBPQ3gyuslhsDz2N/IZaxZ/JW9Kqam6h6 qOAkZxpCS9rabjOWu5AiS3lx0aUfhL0= Date: Thu, 24 Jun 2021 14:54:44 +0200 From: Borislav Petkov To: Michael Roth Cc: "Kuppuswamy, Sathyanarayanan" , Dave Hansen , Brijesh Singh , x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Joerg Roedel , Tom Lendacky , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Andy Lutomirski , Sergio Lopez , Peter Gonda , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , tony.luck@intel.com, npmccallum@redhat.com Subject: Re: [PATCH Part1 RFC v3 20/22] x86/boot: Add Confidential Computing address to setup_header Message-ID: References: <20210602140416.23573-1-brijesh.singh@amd.com> <20210602140416.23573-21-brijesh.singh@amd.com> <15568c80-c9a9-5602-d940-264af87bed98@amd.com> <162442264313.98837.16983159316116149849@amd.com> <20210624031911.eznpkbgjt4e445xj@amd.com> <20210624123447.zbfkohbtdusey66w@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210624123447.zbfkohbtdusey66w@amd.com> Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Jun 24, 2021 at 07:34:47AM -0500, Michael Roth wrote: > Well, that's sufficient for the boot/compressed->uncompressed parameter > passing, but wouldn't actual bootloaders still need something in > setup_data/setup_header to pass in the CC blob (for things like non-EFI > environments/containers)? I was under the impression that using > boot_params directly was more of a legacy/ad-hoc thing, is that > accurate? /me goes and rereads your early mail. I'm more confused. You're talking about parsing an EFI table early which contains the ccblob and in it is the CPUID page. Now above you say, "non-EFI environments". I'm guessing you want to support both so you want to either parse an EFI table on EFI environments or pass the blob in a different way in non-EFI envs. Yes, no? Also, you want to pass the previously parsed CPUID page address to kernel proper. For that I suggested to use boot_params. What else? How about you explain in a lot more detail what exactly the requirements and the use cases are so that we can have a common base to discuss it on. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette