From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: x86: Don't report guest userspace emulation error to userspace, why ? Date: Thu, 10 Dec 2015 10:12:41 +0100 Message-ID: <56694209.5050800@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit To: Bandan Das , kvm Return-path: Received: from mail-qg0-f49.google.com ([209.85.192.49]:35750 "EHLO mail-qg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752484AbbLJJMp (ORCPT ); Thu, 10 Dec 2015 04:12:45 -0500 Received: by qgec40 with SMTP id c40so129727343qge.2 for ; Thu, 10 Dec 2015 01:12:44 -0800 (PST) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: 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