Memory Map Semantics

[npmccallum]

https://github.com/microsoft/igvm/blob/main/igvm_defs/src/lib.rs#L1160-L1217

Can you help me understand the motivations behind defining a custom memory map for IGVM?

I've tried to divine the reasons for this. Compared to e820, you've just added 3 flags (purpose, vtl2 and hidden) and compared to EFI_MEMORY_DESCRIPTOR you've removed a bunch of flags and added 2 flags (vtl2 and hidden). Both vtl2 and hidden are also listed as unstable.

Is there a reason not to just use/extend e820 or EFI_MEMORY_DESCRIPTOR?

[chris-oo]

Namely, that we have memory types that we didn't want to extend EFI to know about, because memory types for a paravisor (see VTL2_PROTECTABLE/hidden) in VTL2 don't seem like the domain of normal firmware. But for a IGVM image launching a normal firmware guest, I would expect that firmware to either complain/deny those types since the VM's configuration is probably not what you expect. Does that make sense?

[npmccallum]

What is the difference between hidden and reserved?

[chris-oo]

RESERVED in this case maps to EFI's concept of RESERVED, so memory that is hardware reserved but present in the EFI memmap (I believe persistent memory uses this). HIDDEN is a hint to the paravisor that this memory you should hide from VTL0, and not describe in the memory map. There's a few things that coconut-svsm uses for that, but I can't remember offhand.

[npmccallum]

AFAICS, coconut-svsm sets its own memory to hidden before passing the table forward to VMPL1. But the RESERVED flag is perfectly adequate for that case. So this memory map feels to me like a Hyper-V/OpenHCL implementation detail leaking into the interface. Instead, a simple vendor reserved flag on the EFI map would suffice.

[chris-oo]

Let me ask Jon again, but IIRC we did not add this for Hyper-V and OpenHCL. Because generally, the paravisor is able to completely control the memory map offered to the guest.

[chris-oo]

The usecase was that when you have an SVSM, not a paravisor, there are cases where the memory ranges used by the SVSM itself must be discovered because of some dynamic feature / memory cost. In this case, OVMF will always query the memory range from the host, not from the SVSM, so the SVSM has no way of hiding what ranges shouldn't be exposed to the guest without VMM cooperation.

Thus that flow is that the VMM to determine how much memory the SVSM should used based off of the configuration of the VM & SVSM, communicate that with the SVSM so it knows what ranges to use, and also not require changes to OVMF so that the memory map it sees doesn't have the SVSM ranges described in it. This is because there was little bandwith to make the change for OVMF to consume the memory map from the SVSM or have the SVSM inject it some other way.

So yes, it's kind of a VMM/usecase leak. I agree that it's a bit weird and not ideal, and we should probably leave it under "unstable" and see if we can unwind this.

Note that in a paravisor model, you expect the paravisor to control all information given to guest firmware, so any kind of memory hiding from the host VMM isn't required as the paravisor itself gets to decide what it will expose.

[npmccallum]

I looked in the SVSM code and, from what I could tell, the only actual operation for this is to mark Coconut's own memory region as hidden. But, AFAICS, these could also just be marked as reserved. Coconut doesn't need hidden to know its own memory regions (it can keep track of those itself). And if this is about communicating from Coconut to OVMF some shared memory, there's other ways we can do that without a custom memory map format.

Maybe Jörg Rödel (@joergroedel) or Jon Lange (@msft-jlange) knows?

[msft-jlange]

Coconut doesn't need hidden to know its own memory regions (it can keep track of those itself).

That's not entirely true. COCONUT-SVSM supports a feature where the host can dynamically choose the size of the SVSM memory region based on the runtime requirements that the host expects. This means that COCONUT-SVSM needs a dynamic discovery mechanism to determine what memory is allocated for its exclusive use. The HIDDEN flag is the one that indicates that the memory is there but will be hidden from guest enumeration. Without this flag, COCONUT-SVSM has no way of knowing whether any memory was granted based on runtime configuration.

[npmccallum]

Jon Lange (@msft-jlange) This doesn't seem like a host/VMM concern. It seems like a guest/tenant concern. The guest should know how much its SVSM should need.

[msft-jlange]

@msft-jlange This doesn't seem like a host/VMM concern. It seems like a guest/tenant concern. The guest should know how much its SVSM should need.

It should, but it doesn't. There is no code in OVMF that knows how to integrate the SVSM into memory map enumeration. Yet there remains a requirement that the SVSM be able to dynamically acquire extra memory. Until OVMF knows how to enumerate SVSM memory, this is the unfortunate workaround.