From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web11.5440.1634274501481446604 for ; Thu, 14 Oct 2021 22:08:21 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=DDnj601L; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1634274500; 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=PFF8xQPBNBTCwMkUK0U4fqzJGVU8tNV46kEijOnojNc=; b=DDnj601LRFzxZrZzWsxvKaL5/IcmJ9OmJzsky8y+R7YO9KMtwBz/I3XJ403LsrKl975BJx OXJX0oBVOqMjKg5J4itFVQrM+rcN7vHFBzNE/pjqCMBW2sbHtrjEnatWOAAfnIMQ8C5wXH vcIPmi2S4qwFTCgu3l2RWYsRkzKEhiw= 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-183-Qd2B-K2fNrqBHnkBzjR7Yw-1; Fri, 15 Oct 2021 01:08:13 -0400 X-MC-Unique: Qd2B-K2fNrqBHnkBzjR7Yw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C2D9D362F8; Fri, 15 Oct 2021 05:08:11 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 291F51972D; Fri, 15 Oct 2021 05:08:11 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 358AB1800393; Fri, 15 Oct 2021 07:08:09 +0200 (CEST) Date: Fri, 15 Oct 2021 07:08:09 +0200 From: "Gerd Hoffmann" To: Brijesh Singh Cc: devel@edk2.groups.io, James Bottomley , Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel , Erdem Aktas , Michael Roth Subject: Re: [PATCH v9 04/32] OvmfPkg/ResetVector: introduce SEV metadata descriptor for VMM use Message-ID: <20211015050809.2obx5svugn5yfc6q@sirius.home.kraxel.org> References: <20211013165713.727815-1-brijesh.singh@amd.com> <20211013165713.727815-5-brijesh.singh@amd.com> <20211014070832.sy2ezblvl6olpbtd@sirius.home.kraxel.org> <72e8129a-4e9a-0914-6c4f-879e3b53ff5a@amd.com> MIME-Version: 1.0 In-Reply-To: <72e8129a-4e9a-0914-6c4f-879e3b53ff5a@amd.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Oct 14, 2021 at 02:51:47PM -0500, Brijesh Singh wrote: > > On 10/14/21 12:08 AM, Gerd Hoffmann wrote: > > On Wed, Oct 13, 2021 at 11:56:45AM -0500, Brijesh Singh wrote: > >> BZ: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.tianocore.org%2Fshow_bug.cgi%3Fid%3D3275&data=04%7C01%7Cbrijesh.singh%40amd.com%7Cee86130b95964399c70b08d98ee17462%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637697921262987036%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IkLqCEO9p%2FZxx4ryumEZzBvn8DCR%2Byxl%2Fd%2BdS5dqqbs%3D&reserved=0 > >> > >> The OvmfPkgX86 build reserves memory regions in MEMFD. The memory regions > >> get accessed in the SEC phase. AMD SEV-SNP require that the guest's > >> private memory be accepted or validated before access. > >> > >> Introduce a Guided metadata structure that describes the reserved memory > >> regions. The VMM can locate the metadata structure by iterating through > >> the reset vector guid and process the areas based on the platform > >> specific requirements. > > Acked-by: Gerd Hoffmann > > > > (does it make sense to migrate over the existing SEV_FW_HASH_BLOCK_BASE > > and SEV_LAUNCH_SECRET_BASE blocks?) > > I don't see a strong reason t move over unless someone else sees a real > need for it. We anyway have to maintain the backward compatibility > because older qemu will look for those region through other GUID. Yes, we would need both for a while for backward compatibility reasons. The new format needs less space in the reset vector, there is just one guid for the region list compared to one guid per region. Also a nice cleanup. But, yes, just keeping things as-is is an option too, there is no strong reason to switch over. take care, Gerd