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.9928.1607586846642456396 for ; Wed, 09 Dec 2020 23:54:07 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=RZuf82XJ; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1607586845; 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=UpSEx/LEp6dQ+3qMCsaknAlPeQ/TL4yzZpjOOPH+i/k=; b=RZuf82XJh7nyLQw1aNWY0jesk4at+NOcKVJC94Woxdkdjg5F2F0Ah1uvtaYtrWIqXanVoI flNz6wpg3DSx6XLq3LmSHMDUQ8LRt8tmpn0gPvWCjkL3USCAMgFQNFKrD1+OVjDEcGCLXj a6nSaqfhZIiAS3q23LR52X31wkKw6JU= 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-399-1FHY_JKYNBWp82i5GL1UtQ-1; Thu, 10 Dec 2020 02:54:02 -0500 X-MC-Unique: 1FHY_JKYNBWp82i5GL1UtQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AFBA7104FB63; Thu, 10 Dec 2020 07:53:59 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-52.ams2.redhat.com [10.36.113.52]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4BFF2620D7; Thu, 10 Dec 2020 07:53:56 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v3 0/3] SEV Page Encryption Bitmap support for OVMF. To: devel@edk2.groups.io, thomas.lendacky@amd.com, ashish.kalra@amd.com Cc: dovmurik@linux.vnet.ibm.com, brijesh.singh@amd.com, tobin@ibm.com, Jon.Grimm@amd.com, jejb@linux.ibm.com, frankeh@us.ibm.com, dgilbert@redhat.com, jordan.l.justen@intel.com, ard.biesheuvel@arm.com References: <6f1ebc14-879d-53fd-74f9-0085d869f090@redhat.com> <20201204081009.GA767@ashkalra_ubuntu_server> From: "Laszlo Ersek" Message-ID: Date: Thu, 10 Dec 2020 08:53:55 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 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 12/08/20 15:57, Lendacky, Thomas wrote: > On 12/7/20 8:44 PM, Laszlo Ersek wrote: >> On 12/04/20 09:10, Ashish Kalra wrote: >>> On Fri, Dec 04, 2020 at 04:50:05AM +0100, Laszlo Ersek wrote: >>>> On 12/04/20 01:03, Ashish Kalra wrote: >>>>> From: Ashish Kalra >>>>> >>>>> By default all the SEV guest memory regions are considered encrypted, >>>>> if a guest changes the encryption attribute of the page (e.g mark a >>>>> page as decrypted) then notify hypervisor. Hypervisor will need to >>>>> track the unencrypted pages. The information will be used during >>>>> guest live migration, guest page migration and guest debugging. >>>>> >>>>> The patch-set also adds a new SEV and SEV-ES hypercall abstraction >>>>> library to support SEV Page encryption/decryption status hypercalls >>>>> for SEV and SEV-ES guests. >>>>> >>>>> BaseMemEncryptSevLib invokes hypercalls via this new hypercall library. >>>>> >>>>> A branch containing these patches is available here: >>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fashkalra%2Fedk2%2Ftree%2Fsev_page_encryption_bitmap_v3&data=04%7C01%7Cthomas.lendacky%40amd.com%7Caa286d7e06864008110008d89b233ebc%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637429922982193672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EjrGD2LNlji8ualk8KClh%2BhqJa5Fm0UzlmPc4%2FQvb2g%3D&reserved=0 >>>>> >>>>> Changes since v2: >>>>> - GHCB_BASE setup during reset-vector as decrypted is marked explicitly >>>>> in the hypervisor page encryption bitmap after setting the >>>>> PcdSevEsIsEnabled PCD. >>>>> >>>>> Changes since v1: >>>>> - Mark GHCB_BASE setup during reset-vector as decrypted explicitly in >>>>> the hypervisor page encryption bitmap. >>>>> - Resending the series with correct shallow threading. >>>>> >>>>> Ashish Kalra (2): >>>>> OvmfPkg/MemEncryptHypercallLib: add library to support SEV hypercalls. >>>>> OvmfPkg/PlatformPei: Mark SEC GHCB page in the page encrpytion bitmap. >>>>> >>>>> Brijesh Singh (1): >>>>> OvmfPkg/BaseMemEncryptLib: Support to issue unencrypted hypercall >>>>> >>>>> .../Include/Library/MemEncryptHypercallLib.h | 37 ++++++ >>>>> .../BaseMemEncryptSevLib.inf | 1 + >>>>> .../BaseMemEncryptSevLib/X64/VirtualMemory.c | 18 +++ >>>>> .../MemEncryptHypercallLib.c | 105 ++++++++++++++++++ >>>>> .../MemEncryptHypercallLib.inf | 39 +++++++ >>>>> .../X64/AsmHelperStub.nasm | 39 +++++++ >>>>> OvmfPkg/OvmfPkgX64.dsc | 1 + >>>>> OvmfPkg/PlatformPei/AmdSev.c | 10 ++ >>>>> 8 files changed, 250 insertions(+) >>>>> create mode 100644 OvmfPkg/Include/Library/MemEncryptHypercallLib.h >>>>> create mode 100644 OvmfPkg/Library/MemEncryptHypercallLib/MemEncryptHypercallLib.c >>>>> create mode 100644 OvmfPkg/Library/MemEncryptHypercallLib/MemEncryptHypercallLib.inf >>>>> create mode 100644 OvmfPkg/Library/MemEncryptHypercallLib/X64/AsmHelperStub.nasm >>>>> >>>> >>>> I'll need some time to get to this series. >>>> >>>> I'm fairly certain though, from a quick skim, that this series breaks >>>> all DSC files under OvmfPkg except X64. Please fix that. >>>> >>>> >>> >>> Ok thanks Laszlo, i will fix this. >> >> Thanks. >> >> I can see a new comment for the series from Dov Murik, and I think >> that's awesome. I'd welcome if there were lively exchanges around OVMF >> patch sets. I'm selfish of course: I'd like to delegate reviews. >> >> So, on this patch set, I notice it does not add the new >> (MemEncryptHypercallLib-related) files to Maintainers.txt, namely >> section "OvmfPkg: SEV-related modules". >> >> Please include such a patch in v4 -- if Tom and Brijesh agree, I'd like >> to put the new lib explicitly under their reviewership. > > Yes, no issues with that. Thank you guys! Laszlo > >> >> Also, I plan to review this series (v4, at this point) only for >> formalities. I'd like to receive an R-b from Tom or Brijesh [*], and >> another from Dov or a colleague at IBM, for this series; those together >> should suffice for merging the library. >> >> [*] Brijesh seems to be the original author of patch#2, so maybe Tom is >> a better-poised reviewer for this. > > Will do. I know a new version is coming as well as discussion about the > hypercall in general, so lets see where that goes. > > Thanks, > Tom > >> >> Thanks >> Laszlo >> > > > > >