From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by mx.groups.io with SMTP id smtpd.web11.1818.1676414249962362932 for ; Tue, 14 Feb 2023 14:37:30 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=okbuiEfu; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0F0AEB81F4A for ; Tue, 14 Feb 2023 22:37:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDFB2C4339C for ; Tue, 14 Feb 2023 22:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1676414246; bh=XWkHd8nfxLA4wsfxVZJQNkC7rHUqgwhWyHq4MATKx+k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=okbuiEfuZvPJzIcWvHnxUhWn1UL6/wKkWU/Ptfmb+JCV3JRODgpvy2qHqiyJoJ3Gp hkCkgps7rujZdKk4sY4THq1f1eTiRVkk/Re0Air2jPBV4qZjQ99J14bG2O3fHokXaG s16svxCUv7rZrHJAsL8QYSAgGsTbZ94vd7FVSYt0YDJ+4/bdrlFPVnH1PHhJZO29mA ANbYMV5LnClByi1eZ7mCRHGtMWPvAHB6qeJCuXZBMN2Fk228B+W0M3x4reWpmg6UKq fgy+llLX3vEjlVU9etNyBfIqq1wLSlHNKb+xLCnnkkG6VhpO+d8JNYEII0v4/lvYqh HOgt9Al0sjsSA== Received: by mail-lf1-f49.google.com with SMTP id w11so25385592lfu.11 for ; Tue, 14 Feb 2023 14:37:26 -0800 (PST) X-Gm-Message-State: AO0yUKUX0C/5ObwO152Inyfy8QO/oOfgN/NwYte6sGjBKcsZBggz+Bp4 TUfFMa1sAeLEe4A6pPO/gvFemhhJ6CPOaifpj7M= X-Google-Smtp-Source: AK7set9aeCE8HNsQDgV9OM0UoNVrEZhsqy+TJGnXhV5M377Y1yTLMwjmezwS9ZNgVgf8i4osa0MEa/+rMgP14+Nkx/g= X-Received: by 2002:a19:9103:0:b0:4db:37ff:f5d0 with SMTP id t3-20020a199103000000b004db37fff5d0mr178999lfd.1.1676414244893; Tue, 14 Feb 2023 14:37:24 -0800 (PST) MIME-Version: 1.0 References: <20230131190837.354950-1-dionnaglaze@google.com> In-Reply-To: From: "Ard Biesheuvel" Date: Tue, 14 Feb 2023 23:37:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] OvmfPkg: Fix SevMemoryAcceptance memory attributes To: Dionna Amalie Glaze Cc: devel@edk2.groups.io, Ard Biesheuvel , Erdem Aktas , James Bottomley , Jiewen Yao , Min Xu , Tom Lendacky , Michael Roth Content-Type: text/plain; charset="UTF-8" On Thu, 2 Feb 2023 at 21:42, Dionna Amalie Glaze wrote: > > > > > > > This change is made given a request from Ard. The CC capability is not > > > applied to other system memory ranges that probably should also have > > > that capability, given that it's encrypted and accepted. I haven't > > > considered carefully where EFI_MEMORY_CPU_CRYPTO should be added to > > > conventional memory, given the acceptance happens before DXE > > > initializes. Perhaps > > > CoreConvertResourceDescriptorHobAttributesToCapabilities? This is more > > > of a question to Ard and Thomas. > > > > > > > It's not clear to me whether the CC attribute applies to the host or > > the guest. From the guest PoV, there is really no distinction, whereas > > on the host, I could imagine that only CC capable memory can be used > > for handing out to VMs. > > > > That's a good point. The UEFI spec language is hard to interpret here. > Min or Jiewen, do you have more context on the EFI_MEMORY_CPU_CRYPTO > attribute? > To keep things moving, I've queued this up (as #4040) with the EFI_MEMORY_CPU_CRYPTO flag dropped. I don't think we need to add it here, given that EDK2 nor Linux ever set or test this flag anywhere else, but if this changes, we can add it back.