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.web08.6196.1623236445620988061 for ; Wed, 09 Jun 2021 04:00:45 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NY6fBFWB; 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=1623236444; 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=Iagc/0sQ6N2fmAHTIjlKgRqy36H8i5+0QJatRkhkSRQ=; b=NY6fBFWBs8Y3HE0ngJb/2hOwmSTlGKJkOxiY2dO+nHA2VcZbKlU6OUHMVj+FQF6nQ+K/8u go9zkEg5Gn+QQ9mUmSdrDdOYwFFpaxsrsi0VBKQhW2v/Lygjm7jE5NiVQrqbpQFaFr0zk1 AJPdnQWU/y3Xn4rMQg3gR9NkVhLeYcU= 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-232-v0PMWIivOsGKt-NmxtzcKg-1; Wed, 09 Jun 2021 07:00:43 -0400 X-MC-Unique: v0PMWIivOsGKt-NmxtzcKg-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 EAF729F932; Wed, 9 Jun 2021 11:00:41 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-249.ams2.redhat.com [10.36.113.249]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8DA5C19C45; Wed, 9 Jun 2021 11:00:35 +0000 (UTC) Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF To: "Xu, Min M" , "devel@edk2.groups.io" , "jejb@linux.ibm.com" , "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Paolo Bonzini , Nathaniel McCallum , "Dr. David Alan Gilbert" , "Ademar de Souza Reis Jr." References: From: "Laszlo Ersek" Message-ID: <27ee4270-7f88-6939-ffa8-6d52bbe266a2@redhat.com> Date: Wed, 9 Jun 2021 13:00:34 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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 06/09/21 02:58, Xu, Min M wrote: > On 06/09/2021 3:33 AM, Laszlo wrote: >> On 06/08/21 18:01, James Bottomley wrote: >>> On your slide 13 Question: "Open: How will the QEMU find the metadata >>> location?" can't you just use the mechanism for SEV that's already >>> upstream in both QEMU and OVMF? >> >> I think I made the same comment, in different words. (Point (12) at >> > June/msg00143.html>.) >> > So my understanding to this solution is that: > 1) GUID-ed structure chain is started from a fixed GPA in ResetVector. > 2) Append a TDX-specific GUID-ed structure in the chain > 3) Qemu search the GUID-ed chain from the fixed GPA and find the TDX-specific > GUID-ed structure based on TDX-specific GUID. > Is the expected process for QEMU? This is my understanding, yes; James will know more details though. [...] Thanks, Laszlo