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.129.124]) by mx.groups.io with SMTP id smtpd.web11.41401.1674637870057358433 for ; Wed, 25 Jan 2023 01:11:10 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VWJdkXmV; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1674637869; 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=1O32j17c4xdRy0yIW84iQl6sxeMJ8OcV9AlkQwF3CJg=; b=VWJdkXmV+4cOon34LGyuo7UywwYEkDhEpu9QkNNY04ymAriE9uzgMkMCde+rQrrHz1Hfif zsgFvSd7l7exQpzrMLACidSyCuOWTL3Xag8eAOMxuzPijW3KKmvDtegyc26rNsCSRSp+t8 OK6DweuBRRoborn/+wjfp1Y7vjg4EA4= 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-401-2-EO9uV-NLGLy-Qp8s1ujQ-1; Wed, 25 Jan 2023 04:11:04 -0500 X-MC-Unique: 2-EO9uV-NLGLy-Qp8s1ujQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BA97A1875053; Wed, 25 Jan 2023 09:11:03 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.186]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 65B5D14171BB; Wed, 25 Jan 2023 09:11:03 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id B9F111800623; Wed, 25 Jan 2023 10:11:01 +0100 (CET) Date: Wed, 25 Jan 2023 10:11:01 +0100 From: "Gerd Hoffmann" To: Tom Lendacky Cc: devel@edk2.groups.io, Jiewen Yao , Oliver Steffen , =?utf-8?B?TMOhc3psw7Mgw4lyc2Vr?= , Ard Biesheuvel , Pawel Polawski , Jordan Justen Subject: Re: [edk2-devel] [PATCH v4 3/5] OvmfPkg/PlatformInitLib: Add PlatformAddHobCB Message-ID: <20230125091101.rtxlviabpxg5uqq3@sirius.home.kraxel.org> References: <20230117121629.2149112-1-kraxel@redhat.com> <20230117121629.2149112-4-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 24, 2023 at 04:33:48PM -0600, Tom Lendacky wrote: > On 1/17/23 06:16, Gerd Hoffmann via groups.io wrote: > > Add PlatformAddHobCB() callback function for use with > > PlatformScanE820(). It adds HOBs for high memory and reservations (low > > memory is handled elsewhere because there are some special cases to > > consider). This replaces calls to PlatformScanOrAdd64BitE820Ram() with > > AddHighHobs = TRUE. > > > > Write any actions done (adding HOBs, skip unknown types) to the firmware > > log with INFO loglevel. > > > > Also remove PlatformScanOrAdd64BitE820Ram() which is not used any more. > > Hi Gerd, > > A problem was reported to me for an SEV-ES guest that I bisected to this > patch. It only occurs when using the OVMF_CODE.fd file without specifying > the OVMF_VARS.fd file (i.e. only the one pflash device on the qemu command > line, but not using the OVMF.fd file). I don't ever boot without an > OVMF_VARS.fd file, so I didn't catch this. > > With this patch, SEV-ES terminates now because it detects doing MMIO to > encrypted memory area at 0xFFC00000 (where the OVMF_VARS.fd file would > normally be mapped). Prior to this commit, an SEV-ES guest booted without > issue in this configuration. > > First, is not specifying an OVMF_VARS.fd a valid configuration for booting > given the CODE/VARS split build? No. > If it is valid, is the lack of the OVMF_VARS.fd resulting in the 0xFFC00000 > address range getting marked reserved now (and thus mapped encrypted)? I have no clue offhand. The patch is not supposed to change OVMF behavior. Adding the HOBs was done by the (increasingly messy) PlatformScanOrAdd64BitE820Ram() function before, with this patch in place PlatformScanE820() + PlatformAddHobCB() handle it instead. The end result should be identical though. OVMF does MMIO access @ 0xFFC00000, to check whenever it finds flash there or not (to handle the -bios OVMF.fd case). That happens at a completely different place though (see OvmfPkg/QemuFlashFvbServicesRuntimeDxe/QemuFlash.c). > Let me know if you need me to provide any output or testing if you can't > boot an SEV-ES guest. Yes, the firmware log hopefully gives clues what is going on here. thanks, Gerd