x86: Don't report guest userspace emulation error to userspace, why ?
Commit a2b9e6c1a35afcc09:
KVM: x86: Don't report guest userspace emulation error to userspace
Commit fc3a9157d314 ("KVM: X86: Don't report L2 emulation failures to user-space") disabled the reporting of L2 (nested guest) emulation failures to userspace due to race-condition between a vmexit and the instruction emulator. The same rational applies also to userspace applications that are permitted by the guest OS to access MMIO area or perform PIO.
This patch extends the current behavior - of injecting a #UD instead of reporting it to userspace - also for guest userspace code.
I searched the archives but failed in finding anything. Can someone please explain why this is needed ? Or, why not let userspace decide what to do based on the cpl, whether to continue execution or kill the guest ? Is the assumption here that this is what userspace always wants ?
Paolo Bonzini
maintainerQuoted 10 lines · Bandan Das
Commit
a2b9e6c1a35afcc09:KVM: x86: Don't report guest userspace emulation error to userspace
Commit
fc3a9157d314("KVM: X86: Don't report L2 emulation failures to user-space") disabled the reporting of L2 (nested guest) emulation failures to userspace due to race-condition between a vmexit and the instruction emulator. The same rational applies also to userspace applications that are permitted by the guest OS to access MMIO area or perform PIO.
Quoted 7 lines
This patch extends the current behavior - of injecting a #UD instead of reporting it to userspace - also for guest userspace code.
I searched the archives but failed in finding anything. Can someone please explain why this is needed ? Or, why not let userspace decide what to do based on the cpl, whether to continue execution or kill the guest ? Is the assumption here that this is what userspace always wants ?
Not what userspace always wants, but what the guest kernel always wants.
Allowing userspace to stop the guest with an emulation failure is a possible denial of service, similar to L2 stopping L1 with an emulation failure.
Paolo
Quoted 14 lines · Paolo Bonzini
Quoted 13 lines · Bandan Das
Commit
a2b9e6c1a35afcc09:KVM: x86: Don't report guest userspace emulation error to userspace
Commit
fc3a9157d314("KVM: X86: Don't report L2 emulation failures to user-space") disabled the reporting of L2 (nested guest) emulation failures to userspace due to race-condition between a vmexit and the instruction emulator. The same rational applies also to userspace applications that are permitted by the guest OS to access MMIO area or perform PIO.This patch extends the current behavior - of injecting a #UD instead of reporting it to userspace - also for guest userspace code.
Quoted 6 lines
Quoted 4 lines
I searched the archives but failed in finding anything. Can someone please explain why this is needed ? Or, why not let userspace decide what to do based on the cpl, whether to continue execution or kill the guest ? Is the assumption here that this is what userspace always wants ?
Not what userspace always wants, but what the guest kernel always wants.
Thanks Paolo, this one I agree.
Quoted 1 line
Allowing userspace to stop the guest with an emulation failure is a
This one I don't :) Userspace started the guest after all, there are other ways for it to kill the guest if it wanted to.
Quoted 8 lines
possible denial of service, similar to L2 stopping L1 with an emulation failure.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Paolo Bonzini
maintainerQuoted 3 lines · Bandan Das
Quoted 1 line
Quoted 1 line
Allowing userspace to stop the guest with an emulation failure is a
This one I don't :) Userspace started the guest after all, there are other ways for it to kill the guest if it wanted to.
I mean allowing guest userspace to stop the guest.
Paolo
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
possible denial of service, similar to L2 stopping L1 with an emulation failure.
Quoted 6 lines · Paolo Bonzini
Quoted 3 lines · Bandan Das
Quoted 1 line
Quoted 1 line
Allowing userspace to stop the guest with an emulation failure is a
This one I don't :) Userspace started the guest after all, there are other ways for it to kill the guest if it wanted to.
I mean allowing guest userspace to stop the guest.
Sure! Userspace (Qemu) can just reenter the guest when it sees the failure. Doing it in the host kvm seems overkill.
Quoted 4 lines
Paolo
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
possible denial of service, similar to L2 stopping L1 with an emulation failure.
Paolo Bonzini
maintainerQuoted 10 lines
Quoted 6 lines · Paolo Bonzini
Quoted 3 lines · Bandan Das
Quoted 1 line
Quoted 1 line
Allowing userspace to stop the guest with an emulation failure is a
This one I don't :) Userspace started the guest after all, there are other ways for it to kill the guest if it wanted to.
I mean allowing guest userspace to stop the guest.
Sure! Userspace (Qemu) can just reenter the guest when it sees the failure. Doing it in the host kvm seems overkill.
Most userspaces will get it wrong. Doing it once makes sure that you do it right.
Paolo
Quoted 6 lines · Paolo Bonzini
Quoted 6 lines
Quoted 5 lines · Paolo Bonzini
Quoted 3 lines · Bandan Das
Quoted 1 line
Quoted 1 line
Allowing userspace to stop the guest with an emulation failure is a
This one I don't :) Userspace started the guest after all, there are other ways for it to kill the guest if it wanted to.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
I mean allowing guest userspace to stop the guest.
Sure! Userspace (Qemu) can just reenter the guest when it sees the failure. Doing it in the host kvm seems overkill.
Most userspaces will get it wrong. Doing it once makes sure that you do it right.
I don't buy that. As userspace, I prefer getting to know what error the guest I launched hit and decide what to do. Well, atleast whenever I can. This seems to be one such case.
Quoted 1 line
Paolo