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.web10.14710.1682671275710522119
for <devel@edk2.groups.io>;
Fri, 28 Apr 2023 01:41:16 -0700
Authentication-Results: mx.groups.io;
dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=C6D8kTVQ;
spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1682671274;
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:
in-reply-to:in-reply-to:references:references;
bh=A+kdEVfXiJ3E0X7LDd5YECCPec4WJHb8EDIAyTUzZsU=;
b=C6D8kTVQYWAf2CaMfltLqh/D5h2ZXfC+vHQ2x6LNHyEN/+Fe7CI11RokjfnGhjfjqsyTht
Gl5wK/4XQWiVE01+i0qgp1pTv6uSmflT0fSY4hHpAbrVFqgGWpfjsCPKIqzbTq6u5M2M6S
YREgkcbTUVKIsVGvkG9uO8IxmUzYJA4=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com
[66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
us-mta-438-rBhCr4SfPte1LXkBpixXcw-1; Fri, 28 Apr 2023 04:41:10 -0400
X-MC-Unique: rBhCr4SfPte1LXkBpixXcw-1
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1])
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
(No client certificate requested)
by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1D31485A5A3;
Fri, 28 Apr 2023 08:41:10 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.195.158])
by smtp.corp.redhat.com (Postfix) with ESMTPS id BD26840C2064;
Fri, 28 Apr 2023 08:41:09 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
id 61B051800935; Fri, 28 Apr 2023 10:41:08 +0200 (CEST)
Date: Fri, 28 Apr 2023 10:41:08 +0200
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Tom Lendacky <thomas.lendacky@amd.com>
Cc: "Xu, Min M" <min.m.xu@intel.com>, joeyli <jlee@suse.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>, "Aktas, Erdem" <erdemaktas@google.com>,
James Bottomley <jejb@linux.ibm.com>, "Yao, Jiewen" <jiewen.yao@intel.com>,
Michael Roth <michael.roth@amd.com>
Subject: Re: [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest
Message-ID: <vnwkldwyah347ggit36nrghikiqvbwmkn6t3ivzs5u3nlv6ggv@jns7d6psrwhq>
References: <2xjjrifeaa7khaha4se7gs3hmtdz2kkg2dv4t7njwf5z5mbn2f@qb5s2k7c6225>
<03fed1d7-cbd8-ee45-ebd8-8ecf60971e61@amd.com>
<ujqoq42nx67qyjcujfoyoa3aid66hwga7j2klzbv3c4xjg2qj2@btai6jne2j54>
<c5a1ce9d-47b9-0afd-3f27-ce073ae44360@amd.com>
<gux3maqgxayg6r6wvi4ucbypfsvcbu4smsbvwrjtiggzukltd4@qh53i4jlbxun>
<eff2d185-c20c-7d01-8970-5aa0a008afc0@amd.com>
<fx4c2ihzi5x4xrgvnbit6lcnai54ta6tmdadczhnfdwog4ruw2@cf6m7mkyem44>
<0da93279-d397-c067-cc9f-7abfc9935eea@amd.com>
<ydccabh7bb74bzw4cop7vo5eqckubzhcvo4baszizjjzrkrhbl@e24qj2v2cspv>
<a702082a-808f-73c4-2d9a-47396030ba9f@amd.com>
MIME-Version: 1.0
In-Reply-To: <a702082a-808f-73c4-2d9a-47396030ba9f@amd.com>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi,
> I'd have to dig much deeper to see if there's a way to identify whether a
> VARS file was specified on the Qemu command line. I *think* (please correct
> me if I'm missing something) for SEV and SEV-ES it would be straight forward
> to try and access the memory as shared and check the headers. If they're
> valid, then a VARS file was specified on the command line and should remain
> mapped shared. If they aren't valid, a VARS file wasn't specified and you
> have either the full OVMF.fd file or just the OVMF_CODE.fd with memory
> backing the VARS that, in either case, should be mapped private.
OVMF_CODE.fd + OVMF_VARS.fd is *identical* to just OVMF.fd, i.e. the
guest will see valid varstore headers in both cases.
The split into code part and vars part allows to (a) easily update the
code without screwing up the vars, and (b) map both with different
properties, i.e. code read-only and vars read/write.
Does the patch below help?
take care,
Gerd
>>From 3971f9453ded3032f5918dc9d181ecc0b6f97862 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Fri, 28 Apr 2023 10:34:23 +0200
Subject: [PATCH 1/1] [testing] try setup mmio in QemuFlashBeforeProbe (dxe)
---
.../QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c
index d57f7ca25ccf..3a6280ab9c3a 100644
--- a/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c
+++ b/OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlashDxe.c
@@ -37,9 +37,18 @@ QemuFlashBeforeProbe (
IN UINTN FdBlockCount
)
{
- //
- // Do nothing
- //
+ EFI_STATUS Status;
+
+ if (MemEncryptSevIsEnabled ()) {
+ Status = MemEncryptSevClearMmioPageEncMask (
+ 0,
+ BaseAddress,
+ EFI_SIZE_TO_PAGES (FdBlockSize * FdBlockCount)
+ );
+ if (EFI_ERROR(Status)) {
+ DEBUG ((DEBUG_WARN, "%a: MemEncryptSevClearMmioPageEncMask: %r\n", __func__, Status));
+ }
+ }
}
/**
--
2.40.0