On 11/9/2023 12:07 AM, Sean Christopherson wrote:
On Wed, Nov 08, 2023, Xiaoyao Li wrote:
On 11/8/2023 9:09 AM, Sean Christopherson wrote:
Add yet another macro to the VM/vCPU ioctl() framework to detect when an
ioctl() failed because KVM killed/bugged the VM, i.e. when there was
nothing wrong with the ioctl() itself. If KVM kills a VM, e.g. by way of
a failed KVM_BUG_ON(), all subsequent VM and vCPU ioctl()s will fail with
-EIO, which can be quite misleading and ultimately waste user/developer
time.
Use KVM_CHECK_EXTENSION on KVM_CAP_USER_MEMORY to detect if the VM is
dead and/or bug, as KVM doesn't provide a dedicated ioctl(). Using a
heuristic is obviously less than ideal, but practically speaking the logic
is bulletproof barring a KVM change, and any such change would arguably
break userspace, e.g. if KVM returns something other than -EIO.
We hit similar issue when testing TDX VMs. Most failure of SEMCALL is
handled with a KVM_BUG_ON(), which leads to vm dead. Then the following
IOCTL from userspace (QEMU) and gets -EIO.
Can we return a new KVM_EXIT_VM_DEAD on KVM_REQ_VM_DEAD?
Why? Even if KVM_EXIT_VM_DEAD somehow provided enough information to be useful
from an automation perspective, the VM is obviously dead. I don't see how the
VMM can do anything but log the error and tear down the VM. KVM_BUG_ON() comes
with a WARN, which will be far more helpful for a human debugger, e.g. because
all vCPUs would exit with KVM_EXIT_VM_DEAD, it wouldn't even identify which vCPU
initially triggered the issue.
It's not about providing more helpful debugging info, but to provide a
dedicated notification for VMM that "the VM is dead, all the following
command may not response". With it, VMM can get rid of the tricky
detection like this patch.
Using an exit reason is a also bit tricky because it requires a vCPU, whereas a
dead VM blocks anything and everything.
No argue of it. It cannot work for all the case, but at least it can
make some case happier.
and replace -EIO with 0? yes, it's a ABI change.
Definitely a "no" on this one. As has been established by the guest_memfd series,
it's ok to return -1/errno with a valid exit_reason.
But I'm wondering if any userspace relies on -EIO behavior for VM DEAD case.
I doubt userspace relies on -EIO, but userpsace definitely relies on -1/errno being
returned when a fatal error.
what about KVM_EXIT_SHUTDOWN? Or KVM_EXIT_INTERNAL_ERROR?
