From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: x86: Don't report guest userspace emulation error to userspace, why ? Date: Thu, 10 Dec 2015 12:58:31 -0500 Message-ID: References: <56694209.5050800@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: kvm To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:45846 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753133AbbLJR6c (ORCPT ); Thu, 10 Dec 2015 12:58:32 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 959563D1EB for ; Thu, 10 Dec 2015 17:58:32 +0000 (UTC) In-Reply-To: <56694209.5050800@redhat.com> (Paolo Bonzini's message of "Thu, 10 Dec 2015 10:12:41 +0100") Sender: kvm-owner@vger.kernel.org List-ID: Paolo Bonzini 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