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.web09.36119.1623073948925862930 for ; Mon, 07 Jun 2021 06:52:29 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=PrlDPxxP; 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=1623073948; 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=cRwvIK3N/qpGL6SCWLr6sW0tsCqZhBlLwdecrYqsIgY=; b=PrlDPxxPAnWWUspcCC8RAQRoF1htCSQYj/8wRDq8vjgZOyyuP12wVwgYELOewn9jXPMhJI nEPFQsM+wEfXJyMP/3dwevh8r1qGYwS6x0DKvpD+8jxzXj9a73lB8aVt10y499bb9CmJSM pJLmGxMjFN+xfm4ZYB1YpS+T2tgsVTo= 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-218-WrpdifijMvy5T9bslqgdOw-1; Mon, 07 Jun 2021 09:52:27 -0400 X-MC-Unique: WrpdifijMvy5T9bslqgdOw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C81E48042C9; Mon, 7 Jun 2021 13:52:24 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-114-75.ams2.redhat.com [10.36.114.75]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BAF52102AE7E; Mon, 7 Jun 2021 13:52:17 +0000 (UTC) Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF To: "Xu, Min M" , Michael Brown , "devel@edk2.groups.io" , "Yao, Jiewen" , "rfc@edk2.groups.io" Cc: "jejb@linux.ibm.com" , 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: Date: Mon, 7 Jun 2021 15:52:16 +0200 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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/06/21 14:49, Xu, Min M wrote: > On June 6, 2021 7:30 PM, Michael Brown Wrote: >> On 06/06/2021 03:03, Min Xu wrote: >>>> (11) "Page table should support both 4-level and 5-level page table" >>>> >>>> As a general development strategy, I would suggest building TDX >>>> support in small, well-isolated layers. 5-level paging is not enabled >>>> (has never been tested, to my knowledge) with OVMF on QEMU/KVM, >>>> regardless of confidential computing, for starters. If 5-level paging >>>> is a strict requirement for TDX, then it arguably needs to be >>>> implemented independently of TDX, at first. So that the common edk2 >>>> architecture be at least testable on QEMU/KVM with 5-level paging >>>> enabled. >>>> >>> Yes, 5-level paging is a strict requirement for TDX. I would wait for >>> the conclusion of the *one binary*. >> >> The "one binary" decision isn't relevant here, is it? It would make more >> sense to implement 5-level paging within the base EDK2 architecture. This >> would allow that feature to be tested in isolation from TDX (and >> consequently tested more widely), and would reduce the distance between >> standard builds and TDX builds. >> > > In our first version of TDVF, a static 5-level page table is used. It is simple and > straight forward. But for *one binary* solution, we have to consider the compatibility > with the current 4-level page table. That's why I said "I would wait for the conclusion > of the *one binary*" > > Thanks for the suggestion. We will discuss the it internally first. My primary concern with the 5-level paging is not that the core infrastructure is absent from edk2 -- it is present alright. (Over time, numerous issues have been found and fixed in it, but that's kind of expected, with such a big feature.) I understand it has been in use successfully on a number of physical platforms. My problem is that, AFAICT, the 5-level paging infrastructure of edk2 has never been *tested* on QEMU/KVM, as a part of OVMF. I have absolutely no idea what to expect. The "one binary" decision is a little bit relevant: - If 5-level paging blows up on QEMU/KVM, as a part of OVMF, then restricting the breakage (possibly a regression even?) to the new TDX platform is good. - On the other hand, both 5-level paging and TDX are complex in their own rights; developing feature sets in small isolated waves is always best. There are going to be "bug hunts" in the TDX platform of course; finding an *orthogonal* 5-level paging bug (anywhere in the virt stack, for that matter) is not the greatest outcome for a supposed TDX bug hunt. - I figure users might want 5-level paging for OVMF at some point anyway, even without TDX. The last two points (especially the middle point of the three) kind of outweigh(s) the first point for me. Thanks Laszlo