From: Bandan Das <bsd@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm <kvm@vger.kernel.org>
Subject: Re: x86: Don't report guest userspace emulation error to userspace, why ?
Date: Thu, 10 Dec 2015 12:58:31 -0500 [thread overview]
Message-ID: <jpg7fkm89tk.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <56694209.5050800@redhat.com> (Paolo Bonzini's message of "Thu, 10 Dec 2015 10:12:41 +0100")
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
next prev parent reply other threads:[~2015-12-10 17:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jpg7fkm89tk.fsf@linux.bootlegged.copy \
--to=bsd@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.