From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14AD1C4727D for ; Tue, 29 Sep 2020 03:53:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DEF1D20BED for ; Tue, 29 Sep 2020 03:53:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727077AbgI2DxB (ORCPT ); Mon, 28 Sep 2020 23:53:01 -0400 Received: from mga17.intel.com ([192.55.52.151]:63648 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726064AbgI2DxB (ORCPT ); Mon, 28 Sep 2020 23:53:01 -0400 IronPort-SDR: PSaEE/V5kVTMc36yVcOWeJpjD34M9z807+uZ24Zso1zXqmppG7Q2ixEgmsccYYVMXTcpMy2Tmf pe4j83Qo97zg== X-IronPort-AV: E=McAfee;i="6000,8403,9758"; a="142130338" X-IronPort-AV: E=Sophos;i="5.77,316,1596524400"; d="scan'208";a="142130338" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2020 20:52:59 -0700 IronPort-SDR: hteUO/I0NkRZCWCqDL3H7Bh47P1tPJPqBYjCk6dgjVJo4jwAQFholEK4c5dCMLnGrHfNswXOR4 bEWpDRx0rI0A== X-IronPort-AV: E=Sophos;i="5.77,316,1596524400"; d="scan'208";a="457102758" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.160]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Sep 2020 20:52:59 -0700 Date: Mon, 28 Sep 2020 20:52:57 -0700 From: Sean Christopherson To: Paolo Bonzini Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Marc Zyngier , James Morse , Julien Thierry , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Huacai Chen , Aleksandar Markovic , linux-mips@vger.kernel.org, Paul Mackerras , kvm-ppc@vger.kernel.org, Christian Borntraeger , Janosch Frank , David Hildenbrand , Cornelia Huck , Claudio Imbrenda Subject: Re: [RFC PATCH 3/3] KVM: x86: Use KVM_BUG/KVM_BUG_ON to handle bugs that are fatal to the VM Message-ID: <20200929035257.GH31514@linux.intel.com> References: <20200923224530.17735-1-sean.j.christopherson@intel.com> <20200923224530.17735-4-sean.j.christopherson@intel.com> <878scze4l5.fsf@vitty.brq.redhat.com> <20200924181134.GB9649@linux.intel.com> <87k0wichht.fsf@vitty.brq.redhat.com> <20200925171233.GC31528@linux.intel.com> <731dd323-8c66-77ff-cf15-4bbdea34bcf9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <731dd323-8c66-77ff-cf15-4bbdea34bcf9@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org On Fri, Sep 25, 2020 at 11:06:10PM +0200, Paolo Bonzini wrote: > On 25/09/20 19:12, Sean Christopherson wrote: > >> Do we actually want to prevent *all* ioctls? E.g. when 'vm bugged' > >> condition is triggered userspace may want to extract some information to > >> assist debugging but even things like KVM_GET_[S]REGS will just return > >> -EIO. I'm not sure it is generally safe to enable *everything* (except > >> for KVM_RUN which should definitely be forbidden) so maybe your approach > >> is preferable. > > > > The answer to this probably depends on the answer to the first question of > > when it's appropriate to use KVM_BUG(). E.g. if we limit usage to fatal or > > dangrous cases, then blocking all ioctls() is probably the right thing do do. > > I think usage should be limited to dangerous cases, basically WARN_ON > level. However I agree with Vitaly that KVM_GET_* should be allowed. Makes sense. On the topic of feedback from Vitaly, while dredging through my mailbox I rediscovered his suggestion of kvm->kvm_internal_bug (or maybe just kvm->internal_bug) instead of kvm->vm_bugged[*]. Like past me, I like the "internal" variants better. [*] https://lkml.kernel.org/r/20190930153358.GD14693@linux.intel.com > The other question is whether to return -EIO or KVM_EXIT_INTERNAL_ERROR. > The latter is more likely to be handled already by userspace. And probably less confusing for unsuspecting users. E.g. -EIO is most likely to be interpreted as "I screwed up", whereas KVM_EXIT_INTERNAL_ERROR will correctly be read as "KVM screwed up".