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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0600BC433F5 for ; Tue, 15 Feb 2022 02:11:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233448AbiBOCLl (ORCPT ); Mon, 14 Feb 2022 21:11:41 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:58106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232846AbiBOCLk (ORCPT ); Mon, 14 Feb 2022 21:11:40 -0500 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8B0D19C3A; Mon, 14 Feb 2022 18:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1644891091; x=1676427091; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=+HeZRAeKFxW/cwuCZBqN2uQwwndDLWRt5wIFdHPT7oM=; b=AuaIm1/q2OT+wy9PW+hgjnMIe7bEwjz7GYjQ21mcIsPrGAkCK5iylBVS KpsmX9MNuK/ZWgogrIn+VAWfGzQOo0p1uR6dAyJpNKRLAAomLtVB9xQ6L 7nOgKIE4oTNy6Zv//HGT19Mm0ItMxUaMqwyNaJFzCIMqlYQybNdLEFAs6 epNKKhaE3ToKkSi65rh7XDtRDpICr9dbxyrHwph3AWKhgTTltN731u2ns uWRB1jx3TWhLPoanDEaHwTv58xLc1FRdS0mk62y2z2nR161wyxI72nazz Dym4s/EJztdhyOJDsaslFZYuclyFJXvRX+3j6dEqFwmcCeWa0fgoLtPSP w==; X-IronPort-AV: E=McAfee;i="6200,9189,10258"; a="230867125" X-IronPort-AV: E=Sophos;i="5.88,369,1635231600"; d="scan'208";a="230867125" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 18:11:31 -0800 X-IronPort-AV: E=Sophos;i="5.88,369,1635231600"; d="scan'208";a="703381197" Received: from gao-cwp.sh.intel.com (HELO gao-cwp) ([10.239.159.105]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Feb 2022 18:11:27 -0800 Date: Tue, 15 Feb 2022 10:22:23 +0800 From: Chao Gao To: Sean Christopherson Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Zeng Guang , Maxim Levitsky Subject: Re: [PATCH 02/11] KVM: VMX: Handle APIC-write offset wrangling in VMX code Message-ID: <20220215022221.GA28478@gao-cwp> References: <20220204214205.3306634-1-seanjc@google.com> <20220204214205.3306634-3-seanjc@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220204214205.3306634-3-seanjc@google.com> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org >--- a/arch/x86/kvm/vmx/vmx.c >+++ b/arch/x86/kvm/vmx/vmx.c >@@ -5302,9 +5302,16 @@ static int handle_apic_eoi_induced(struct kvm_vcpu *vcpu) > static int handle_apic_write(struct kvm_vcpu *vcpu) > { > unsigned long exit_qualification = vmx_get_exit_qual(vcpu); >- u32 offset = exit_qualification & 0xfff; > >- /* APIC-write VM exit is trap-like and thus no need to adjust IP */ >+ /* >+ * APIC-write VM-Exit is trap-like, KVM doesn't need to advance RIP and >+ * hardware has done any necessary aliasing, offset adjustments, etc... >+ * for the access. I.e. the correct value has already been written to >+ * the vAPIC page for the correct 16-byte chunk. KVM needs only to >+ * retrieve the register value and emulate the access. >+ */ >+ u32 offset = exit_qualification & 0xff0; Can we take this opportunity to remove offset/exit_qualification? They are used just once. >+ > kvm_apic_write_nodecode(vcpu, offset); > return 1; > } >-- >2.35.0.263.gb82422642f-goog >