SEV-SNP fixes

[tylerfanelli]

This commit automatically enables the SMT bit in a SEV-SNP guest's policy and replaces the deprecated GuestRegionMmap::as_slice() method to get slices of measured regions.

Marking as draft as the as_slice() replacement still requires a few changes.

[tylerfanelli]

@slp It seems I'm correctly replacing the usage of GuestRegionMmap::as_slice() in 4f50bb5, yet when running this I'm met with

Injecting and measuring memory regions. This may take a while.
munmap_chunk(): invalid pointer

Can you take a look and see if anything is being done wrong here?

[tylerfanelli]

@slp I think I've fixed the issue by making a change to vm-memory and taking a slice of the GuestRegionMmap directly (now pointing to a branch of vm-memory that adds this change).

However, I'm met with another vague error when running the VM:

Injecting and measuring memory regions. This may take a while.
Starting TEE/microVM.
[2024-10-25T02:11:11Z ERROR vmm::linux::vstate] Unexpected exit reason on vcpu run: SystemEvent(6, [256])

Have you seen this before?

[jakecorrenti]

@slp I think I've fixed the issue by making a change to vm-memory and taking a slice of the GuestRegionMmap directly (now pointing to a branch of vm-memory that adds this change).

However, I'm met with another vague error when running the VM:

Injecting and measuring memory regions. This may take a while.
Starting TEE/microVM.
[2024-10-25T02:11:11Z ERROR vmm::linux::vstate] Unexpected exit reason on vcpu run: SystemEvent(6, [256])

Have you seen this before?

I don't know much about it specifically but in the match statement where you check the vCPU exit on vcpu.run() this is the default behavior if you don't handle the exit directly.

Not sure if you've seen this before but you can find more details on the error in the KVM API docs

Looks like the 6 indicates KVM_SYSTEM_EVENT_SEV_TERM:

KVM_SYSTEM_EVENT_SEV_TERM -- an AMD SEV guest requested termination. The guest physical address of the guest's GHCB is stored in data[0]

[tylerfanelli]

@jakecorrenti Nice catch. I switched to libkrunfw 4.0.0 and the problem disappears. It seems there's a breaking change between libkrunfw 4.0.0 --> 4.4.2

[tylerfanelli]

@slp libkrunfw-sev v4.0.0 works fine, yet this issue is found on v4.2.0. It seems something broke in that release.

[jakecorrenti]

@tylerfanelli Looks like there was ~8 changes to the SEV patches between v4.0 and v4.2. I wonder if you could add them one by one starting with the rebase from the older kernel and see if any of them suddenly trigger it.

Just shooting ideas out, no idea if they'll help or not :)

[tylerfanelli]

As it turns out, I don't require a change to vm-memory as I originally thought. This PR is ready for review.