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.web12.745.1630648618842139188 for ; Thu, 02 Sep 2021 22:56:59 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FPTO7II6; 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=1630648617; 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=cN51AETrkIkMi9Fwb3ULQQ81DmML1JaGutWnmCGAJP0=; b=FPTO7II6v86gAGi+0Ewc1Y6qmJ+97dgbElGcKCv18/j5feB7pBS7Rw100ltvotpdkE0Bkz Z/TB+zvN4yiwoM8CuKi00qtTsrtgZaYTxai/yBDaq25+gZZlqfoJ4+sA+kZaSJaYe9fMx7 U+DVYqgPrNzjRZNqq6JAMNBhhanYb64= 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-354-va8Z-vwDMNiU0JIYelczJA-1; Fri, 03 Sep 2021 01:56:54 -0400 X-MC-Unique: va8Z-vwDMNiU0JIYelczJA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 04AFB107ACCD; Fri, 3 Sep 2021 05:56:53 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9ED1860BF1; Fri, 3 Sep 2021 05:56:51 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A8A1818000A3; Fri, 3 Sep 2021 07:56:49 +0200 (CEST) Date: Fri, 3 Sep 2021 07:56:49 +0200 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "Gao, Jiaqi" , "devel@edk2.groups.io" , "Wang, Jian J" , "Wu, Hao A" , "Bi, Dandan" , "gaoliming@byosoft.com.cn" , "Ni, Ray" , "Kinney, Michael D" , "Zimmer, Vincent" , "Justen, Jordan L" , "Xu, Min M" Subject: Re: [edk2-devel] [RFC] Design review for Lazy Page Accept in TDVF Message-ID: <20210903055649.jsjh4giqphpggktp@sirius.home.kraxel.org> References: <20210831061037.7imk7cip2wh6q3vm@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 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 Fri, Sep 03, 2021 at 12:31:57AM +0000, Yao, Jiewen wrote: > Hi > It is good idea to have a protocol to abstract TDX and SEV. > > I think we need clearly document what service can be used in EFI_ACCEPT_MEMORY. > For example, can we use memory allocation service, GCD service, or MP service? Likewise the expected behavior. For example whenever the protocol driver or the memory core should update the GCD maps. > Couple of dependency issue: > If EFI_ACCEPT_MEMORY cannot use MP service, then there might be performance concern. > If it uses MP service, then we need ensure MP service is installed earlier and before memory accept request. > I think we need a way to ensure there is enough memory *before* the protocol is installed, right? Yes. Same for booting the OS, the kernel must have enough memory so it can boot up to the point where the driver handling the lazy page accept loads. We should also define how we hand over memory range state from one stage to the other (see also my reply to the sev-snp series posted yesterday) so ovmf knows which ranges are accepted/validated already. take care, Gerd