On 7/21/2021 6:08 AM, Tom Lendacky wrote:
On 7/6/21 8:59 AM, Paolo Bonzini wrote:
On 03/07/21 00:04, isaku.yamahata@xxxxxxxxx wrote:
From: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
Add 'guest_state_protected' to mark a VM's state as being protected by
hardware/firmware, e.g. SEV-ES or TDX-SEAM. Use the flag to disallow
ioctls() and/or flows that attempt to access protected state.
Return an error if userspace attempts to get/set register state for a
protected VM, e.g. a non-debug TDX guest. KVM can't provide sane data,
it's userspace's responsibility to avoid attempting to read guest state
when it's known to be inaccessible.
Retrieving vCPU events is the one exception, as the userspace VMM is
allowed to inject NMIs.
Co-developed-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>
Signed-off-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>
Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
Signed-off-by: Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
---
arch/x86/kvm/x86.c | 104 +++++++++++++++++++++++++++++++++++++--------
1 file changed, 86 insertions(+), 18 deletions(-)
Looks good, but it should be checked whether it breaks QEMU for SEV-ES.
Tom, can you help?
Sorry to take so long to get back to you... been really slammed, let me
look into this a bit more. But, some quick thoughts...
Offhand, the SMI isn't a problem since SEV-ES doesn't support SMM.
For kvm_vcpu_ioctl_x86_{get,set}_xsave(), can TDX use what was added for
SEV-ES:
ed02b213098a ("KVM: SVM: Guest FPU state save/restore not needed for SEV-ES guest")
Same for kvm_arch_vcpu_ioctl_{get,set}_fpu().
Tom,
I think what you did in this commit is not so correct. It just silently
ignores the ioctls insteaf of returning an error to userspace to tell
this IOCTL is not invalid to this VM. E.g., for
kvm_arch_vcpu_ioctl_get_fpu(), QEMU just gets it succesful with fpu
being all zeros.
So Paolo, what's your point on this?
The changes to kvm_arch_vcpu_ioctl_{get,set}_sregs() might cause issues,
since there are specific things allowed in __{get,set}_sregs. But I'll
need to dig a bit more on that.
Thanks,
Tom
