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.web10.23465.1675259557033035282 for ; Wed, 01 Feb 2023 05:52:37 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=bkEwlKzZ; 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 1B0FBB82188 for ; Wed, 1 Feb 2023 13:52:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14346C43443 for ; Wed, 1 Feb 2023 13:52:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675259554; bh=MMBQp8ACBZ0hXTaYrgzMtz33xEhYzfv85vG3NUh8MbA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=bkEwlKzZePwYg96ApBnMNeR4wLLLWQ7fbG/IYNR250E15FXgTNfJFWcKKH7gf5XpK DKhWzPSU+Rg18ROCZpt4OPE5Wqoxg1d1i3mgsx3qUV4DsPmZB0fAzl7ijRXpILZiyl 4k3FNiJvNm/sqDfFwJaUqXkVq8wyTprri0AK6xJUM+j6o4PmCJ7QnBjC4+SI5jHY7z 8eU1bV64n9WDyqruShDuSJ9IPSH2Oxb09X86UA3UO6s1BCXO/lKwa5M0rS/4tx9g5I PGGOGQrbm0N8S8yNDN3Q19DyIc/ktX22nzgFDX0WguWCLdEJsg9oF8TeZhN5//PEQz VSDtKW62g4AwA== Received: by mail-lf1-f52.google.com with SMTP id w11so29299856lfu.11 for ; Wed, 01 Feb 2023 05:52:33 -0800 (PST) X-Gm-Message-State: AO0yUKWWn5+mmEjBEkFha+pRou9qJbr7pUXrUJG3qcSHeoMcExOQjwKP H02TC5Ae+93SD1PB7bCeAonjyszjjh1h3IiMWmE= X-Google-Smtp-Source: AK7set85lOVCVUqEqNqdWC9EiZW3ljwwJgmhnHzRcqKJbtBHo+KonHgKzVuFT/YEnRqBXAWn3We2cuAmeEH7nzYG2Fo= X-Received: by 2002:ac2:4ed9:0:b0:4cb:4526:3f09 with SMTP id p25-20020ac24ed9000000b004cb45263f09mr452382lfr.105.1675259552082; Wed, 01 Feb 2023 05:52:32 -0800 (PST) MIME-Version: 1.0 References: <20230131190837.354950-1-dionnaglaze@google.com> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 1 Feb 2023 14:52:20 +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 Tue, 31 Jan 2023 at 20:18, Dionna Amalie Glaze wrote: > > > > > efi: mem94: [Conventional| | |CC| | | | | | | | | | | ] > > range=[0x0000000100000000-0x000000023fffffff] (5120MB) > > > > This does not have the cache capabilities one would expect for system > > memory, UC|WC|WT|WB. > > > > After this change, the same entry becomes > > > > efi: mem94: [Conventional| | |CC| | | | | | | |WB|WT|WC|UC] > > range=[0x0000000100000000-0x000000023fffffff] (5120MB) > > > > This has all the expected attributes. > > > > 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. The important thing for this conversion is that - the type changes to ConventionalMemory - EFI_MEMORY_WB gets set (along with the other ones set in the capability), as otherwise, Linux will disregard this memory and not use it at all. The EFI_MEMORY_CPU_CRYPTO flag is currently only referenced by Linux in code that prints the memory map for diagnostic purposes, and not used anywhere else.