All of lore.kernel.org
 help / color / mirror / Atom feed
* x86: Don't report guest userspace emulation error to userspace, why ?
@ 2015-12-09 22:18 Bandan Das
  2015-12-10  9:12 ` Paolo Bonzini
  0 siblings, 1 reply; 7+ messages in thread
From: Bandan Das @ 2015-12-09 22:18 UTC (permalink / raw)
  To: kvm


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 ?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: Don't report guest userspace emulation error to userspace, why ?
  2015-12-09 22:18 x86: Don't report guest userspace emulation error to userspace, why ? Bandan Das
@ 2015-12-10  9:12 ` Paolo Bonzini
  2015-12-10 17:58   ` Bandan Das
  0 siblings, 1 reply; 7+ messages in thread
From: Paolo Bonzini @ 2015-12-10  9:12 UTC (permalink / raw)
  To: Bandan Das, kvm



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.

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: Don't report guest userspace emulation error to userspace, why ?
  2015-12-10  9:12 ` Paolo Bonzini
@ 2015-12-10 17:58   ` Bandan Das
  2015-12-10 17:59     ` Paolo Bonzini
  0 siblings, 1 reply; 7+ messages in thread
From: Bandan Das @ 2015-12-10 17:58 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: kvm

Paolo Bonzini <pbonzini@redhat.com> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: Don't report guest userspace emulation error to userspace, why ?
  2015-12-10 17:58   ` Bandan Das
@ 2015-12-10 17:59     ` Paolo Bonzini
  2015-12-10 18:36       ` Bandan Das
  0 siblings, 1 reply; 7+ messages in thread
From: Paolo Bonzini @ 2015-12-10 17:59 UTC (permalink / raw)
  To: Bandan Das; +Cc: kvm



On 10/12/2015 18:58, Bandan Das wrote:
>> > 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

>> > possible denial of service, similar to L2 stopping L1 with an emulation
>> > failure.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: Don't report guest userspace emulation error to userspace, why ?
  2015-12-10 17:59     ` Paolo Bonzini
@ 2015-12-10 18:36       ` Bandan Das
  2015-12-10 20:20         ` Paolo Bonzini
  0 siblings, 1 reply; 7+ messages in thread
From: Bandan Das @ 2015-12-10 18:36 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: kvm

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 10/12/2015 18:58, Bandan Das wrote:
>>> > 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.

> Paolo
>
>>> > possible denial of service, similar to L2 stopping L1 with an emulation
>>> > failure.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: Don't report guest userspace emulation error to userspace, why ?
  2015-12-10 18:36       ` Bandan Das
@ 2015-12-10 20:20         ` Paolo Bonzini
  2015-12-10 20:35           ` Bandan Das
  0 siblings, 1 reply; 7+ messages in thread
From: Paolo Bonzini @ 2015-12-10 20:20 UTC (permalink / raw)
  To: Bandan Das; +Cc: kvm

> Paolo Bonzini <pbonzini@redhat.com> writes:
> > On 10/12/2015 18:58, Bandan Das wrote:
> >>> > 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: x86: Don't report guest userspace emulation error to userspace, why ?
  2015-12-10 20:20         ` Paolo Bonzini
@ 2015-12-10 20:35           ` Bandan Das
  0 siblings, 0 replies; 7+ messages in thread
From: Bandan Das @ 2015-12-10 20:35 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: kvm

Paolo Bonzini <pbonzini@redhat.com> writes:

>> Paolo Bonzini <pbonzini@redhat.com> writes:
>> > On 10/12/2015 18:58, Bandan Das wrote:
>> >>> > 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.

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.

> Paolo

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2015-12-10 20:35 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-09 22:18 x86: Don't report guest userspace emulation error to userspace, why ? Bandan Das
2015-12-10  9:12 ` Paolo Bonzini
2015-12-10 17:58   ` Bandan Das
2015-12-10 17:59     ` Paolo Bonzini
2015-12-10 18:36       ` Bandan Das
2015-12-10 20:20         ` Paolo Bonzini
2015-12-10 20:35           ` Bandan Das

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.