Re: [PATCH] OvmfPkg: Fix SevMemoryAcceptance memory attributes

["Ard Biesheuvel" <ardb@kernel.org>]

On Tue, 31 Jan 2023 at 20:18, Dionna Amalie Glaze
<dionnaglaze@google.com> 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.