Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:
> On 09/12/2015 23:18, Bandan Das wrote:
>> 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 ?
>
> Not what userspace always wants, but what the guest kernel always wants.
Thanks Paolo, this one I agree.
> 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.
> 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 majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
