Tom Lendacky

> For `cbitpos` the guest's value must be equal to the host's value (in current SEV generations); currently QEMU enforces this. > > For `reduced-phys-bits`, I think this is not...

> @larrydewey Responding after being ping'ed on Slack. Sorry for the delay, KVM Forum + waiting for more replies to my email. FWIW, I have only received one reply to...

> @tlendacky Thank you for your response. I think you seem to imply that a guest can use PTE / TLB bits that are marked reserved in the host. I...

On 9/20/22 08:37, Christophe de Dinechin wrote: > Responding after being ping'ed on Slack. FWIW, I have only received one reply to my email asking about this to the relevant...

Section 8.17.2 provides some further detail. The input GPA must be page aligned (CMDBUF_SNP_LAUNCH_UPDATE structure, byte offset 0x10, bits 11:0 must be zero) and the second from the last paragraph...

Sorry, I confused the SPA and the GPA in the first part of that last response. The spec should probably be updated to clarify that the GPA will be page...

> Value of `g_pat` is taken from [this line](https://gitlab.com/qemu-project/qemu/-/blob/master/target/i386/cpu.c#L5944) in the QEMU initialization. It also appears in kvm's code as `MSR_IA32_CR_PAT_DEFAULT`. This is the PAT MSR reset value as documented...

Hi Claudio, when I try to build your pull request I'm encountering the following error: ``` Compiling linux_svsm v0.1.0 (/root/kernels/linux-svsm-claudio-build-x86_64) error[E0432]: unresolved imports `crate::bindings::EVP_CIPHER_CTX_ctrl`, `crate::bindings::EVP_CIPHER_CTX_free`, `crate::bindings::EVP_CIPHER_CTX_new`, `crate::bindings::EVP_CIPHER_CTX_set_key_length`, `crate::bindings::EVP_DecryptFinal_ex`, `crate::bindings::EVP_DecryptInit_ex`, `crate::bindings::EVP_DecryptUpdate`,...

> i was assuming with the svsm stack, it's actually svsm that gets attested, but it looks like its still the entire firmware. > even tho svsm has higher privilege...

> > And the SVSM BSP is measured at VMPL0 in KVM during LAUNCH_FINISH processing. > > yes, but the guest is running at VMPL1, so it can't request a...