From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web12.7534.1618906507786760648 for ; Tue, 20 Apr 2021 01:15:07 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Y2m6A3WQ; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618906507; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I3fBT21v01rZD23dzYJqQZYCu2yknmZzWFDHmTOLdhA=; b=Y2m6A3WQ8WCOX239GRzjac8zvFZTlDAMe7hVa7hdWNcDW2b7Z1WbfoXDeuQqB2qP6dKRqR NDuMbT+tkIgXXB+ge+3cO/4Ihq+hXv4TUquY06XkcCFi1NcCl1+g9nT1yx+GIXHe9s1eWR pdt7dO8jNDcH07sxDTzJcndXG9gNNtU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-32-1ubRN0KbOUuSkPmFUm8LgA-1; Tue, 20 Apr 2021 04:14:53 -0400 X-MC-Unique: 1ubRN0KbOUuSkPmFUm8LgA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id B5C2E83DEB0; Tue, 20 Apr 2021 08:14:51 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-171.ams2.redhat.com [10.36.114.171]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0881660C5F; Tue, 20 Apr 2021 08:14:49 +0000 (UTC) Subject: Re: [RFC PATCH 01/19] OvmfPkg: Reserve the Secrets and Cpuid page for the SEV-SNP guest To: Brijesh Singh , devel@edk2.groups.io Cc: James Bottomley , Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel References: <20210324153215.17971-1-brijesh.singh@amd.com> <20210324153215.17971-2-brijesh.singh@amd.com> <6bfc9b77-57ae-02ea-5be1-eeb15eab446b@amd.com> <778bc927-94b0-56cb-708b-612d2498dc4b@redhat.com> From: "Laszlo Ersek" Message-ID: <8e3c3d5a-6cc4-1997-b5ce-e38ad4f0242e@redhat.com> Date: Tue, 20 Apr 2021 10:14:49 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 04/19/21 23:42, Brijesh Singh wrote: > > On 4/13/21 4:49 AM, Laszlo Ersek wrote: >> On 04/12/21 16:52, Brijesh Singh wrote: >>> Hi James and Laszlo, >>> >>> I was planning to work to add the support to reserve the Secrets and >>> CPUID page in E820 map and then create the EFI configuration table entry >>> for it so that guest OS can reach to it. We have two packages >>> "SecretDxe" and "SecretPei" in OvmfPkg/AmdSev. Any issues if I use them >>> in the OvmfPkg.dsc ? Here is what I was thinking: >>> >>> 1) Rename the PcdSevLaunchSecretBase -> PcdSevSecretsBase >>> >>> 2) When SNP is enabled then VMM use this page as secrets page for the SNP >>> >>> 3) When SEV or SEV-ES is enabled then VMM uses this page as a launch >>> secret page >>> >>> This will allow me to drop PcdOvmfSnpSecretsBase. This will not just >>> save 4-bytes but also minimize the code duplication. >> I'm pretty unhappy about needing a separate page for each such purpose. >> We're wasting room in MEMFD. The GUIDed structs that we expose to QEMU >> seem to be flexible enough to describe non-page-aligned addresses, >> right? Can we pack larger amounts of cruft into MEMFD pages? >> >> I'm not looking forward to the day when we run out of slack in MEMFD and >> we get to shift PEIFV / DXEFV. (Every time we need to increase the DXEFV >> size, the same risk exists -- which is why I've been thinking for a >> while now that OVMF includes too many features already.) This can >> introduce obscure changes to the UEFI memory map, which has caused >> compat problems in the past, for example with the "crash" utility. > > > What's your take to move all SEV-specific reserved pages at the end of > PcdOvmfDecompressionScratchEnd ? I have not tried yet, but I can give > try to make sure the ES works after such moves. I don't recommend that, without a serious audit anyway. While we use PCDs in the source code rather than open-coded constants, and so it's relatively easy to change the value of a PCD, the source code may very well rely on the *relations* between PCDs. If you change PCDs such that their relations change (by moving around areas), things can break. If you absolutely need more room, I'd prefer enlarging the currently available gap in-place (pushing up everything that's currently above it). > What is a general rule of thump to what goes in MEMFD ? Is this all the > data pages accessed during the SEC phase ? More or less; it lets us lay out ranges, with symbolic names, that are needed very early (reset vector, SEC), during normal boot or ACPI S3 resume. If something can be allocated manually during PEI or later, yielding a variable address, then it arguably doesn't beling on MEMFD. > If so, then we probably can't > do everything after the PcdOvmfDecompressionScratchEnd. The only thing > which we can quickly move out is a secret page. IIRC, PcdOvmfDecompressionScratchEnd stands for the highest RAM address overwritten during ACPI S3 resume. I wouldn't like to put anything above it through MEMFD. Thanks Laszlo > > >> The feature creep in OVMF has gone off the rails in the last few years, >> really. (Not that I'm not guilty myself.) >> >> Thanks, >> Laszlo >> >