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=-2.2 required=3.0 tests=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 380A7C3A5A0 for ; Mon, 19 Aug 2019 18:53:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 17EA1214DA for ; Mon, 19 Aug 2019 18:53:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728259AbfHSSwl (ORCPT ); Mon, 19 Aug 2019 14:52:41 -0400 Received: from mga01.intel.com ([192.55.52.88]:29061 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728214AbfHSSwl (ORCPT ); Mon, 19 Aug 2019 14:52:41 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Aug 2019 11:52:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,405,1559545200"; d="scan'208";a="172210414" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.41]) by orsmga008.jf.intel.com with ESMTP; 19 Aug 2019 11:52:40 -0700 Date: Mon, 19 Aug 2019 11:52:40 -0700 From: Sean Christopherson To: Adalbert =?utf-8?B?TGF6xINy?= Cc: kvm@vger.kernel.org, linux-mm@kvack.org, virtualization@lists.linux-foundation.org, Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Konrad Rzeszutek Wilk , Tamas K Lengyel , Mathieu Tarral , Samuel =?iso-8859-1?Q?Laur=E9n?= , Patrick Colp , Jan Kiszka , Stefan Hajnoczi , Weijiang Yang , Zhang@vger.kernel.org, Yu C , Mihai =?utf-8?B?RG9uyJt1?= Subject: Re: [RFC PATCH v6 55/92] kvm: introspection: add KVMI_CONTROL_MSR and KVMI_EVENT_MSR Message-ID: <20190819185240.GC1916@linux.intel.com> References: <20190809160047.8319-1-alazar@bitdefender.com> <20190809160047.8319-56-alazar@bitdefender.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190809160047.8319-56-alazar@bitdefender.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Fri, Aug 09, 2019 at 07:00:10PM +0300, Adalbert Lazăr wrote: > +int kvmi_arch_cmd_control_msr(struct kvm_vcpu *vcpu, > + const struct kvmi_control_msr *req) > +{ > + int err; > + > + if (req->padding1 || req->padding2) > + return -KVM_EINVAL; > + > + err = msr_control(vcpu, req->msr, req->enable); > + > + if (!err && req->enable) This needs a comment explaining that it intentionally calls into arch code only for the enable case so as to avoid having to deal with tracking whether or not it's safe to disable interception. At first (and second) glance it look like KVM is silently ignoring the @enable=false case. > + kvm_arch_msr_intercept(vcpu, req->msr, req->enable); Renaming to kvm_arch_enable_msr_intercept() would also help communicate that KVMI can't be used to disable msr interception. The function can always be renamed if someone takes on the task of enhancing the arch code to handling disabling interception. > + > + return err; > +}