From patchwork Fri Mar 20 19:07:36 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Roger_Pau_Monn=C3=A9?= X-Patchwork-Id: 11450197 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E734F913 for ; Fri, 20 Mar 2020 19:09:17 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C336020767 for ; Fri, 20 Mar 2020 19:09:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=citrix.com header.i=@citrix.com header.b="G0/Xb/ed" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C336020767 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=citrix.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jFN0C-0000Sa-48; Fri, 20 Mar 2020 19:08:16 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jFN0B-0000SQ-C1 for xen-devel@lists.xenproject.org; Fri, 20 Mar 2020 19:08:15 +0000 X-Inumbo-ID: 232a7238-6ade-11ea-b34e-bc764e2007e4 Received: from esa3.hc3370-68.iphmx.com (unknown [216.71.145.155]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 232a7238-6ade-11ea-b34e-bc764e2007e4; Fri, 20 Mar 2020 19:08:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1584731290; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=5szMN6eLyIRQyrcbotjLy/JLjgHXMPVpj2Am1OM3ueQ=; b=G0/Xb/edTW1VzD7JcT9Q0wqWxHTfUdxIqVe0jbr6da0eI5mid4fCG5yf SQziSovKeJmM4Sgkuj1drLEsTe9/NO3VWHLxCpPtfxJU9jIQWtjW9IqVa OMjWXG5gMMU3Yh3Sey/R5qT97fz3JMBH40NtR5feQzmrI7lOE5AG29uH2 I=; Authentication-Results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@citrix.com; spf=Pass smtp.mailfrom=roger.pau@citrix.com; spf=None smtp.helo=postmaster@mail.citrix.com Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender authenticity information available from domain of roger.pau@citrix.com) identity=pra; client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (esa3.hc3370-68.iphmx.com: domain of roger.pau@citrix.com designates 162.221.158.21 as permitted sender) identity=mailfrom; client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="roger.pau@citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:209.167.231.154 ip4:178.63.86.133 ip4:195.66.111.40/30 ip4:85.115.9.32/28 ip4:199.102.83.4 ip4:192.28.146.160 ip4:192.28.146.107 ip4:216.52.6.88 ip4:216.52.6.188 ip4:162.221.158.21 ip4:162.221.156.83 ip4:168.245.78.127 ~all" Received-SPF: None (esa3.hc3370-68.iphmx.com: no sender authenticity information available from domain of postmaster@mail.citrix.com) identity=helo; client-ip=162.221.158.21; receiver=esa3.hc3370-68.iphmx.com; envelope-from="roger.pau@citrix.com"; x-sender="postmaster@mail.citrix.com"; x-conformance=sidf_compatible IronPort-SDR: /CGnllzdDdPIXxzmv+3CDFRPOiZ7Z0mjRf4Q4+o06QkU13pPCiupy/9W5skuIZpcqloihrvxia k1VEBHeMByJ5JqKvCSy6xPvO9FEtMm2t+17aK+6rDlG7MYckBoxbXENS38QYtYflRKx3MBhyM+ PhT86OALuJ7cHzgkTHVvzeMw4h3eKjy6sqw1lvedQoRg4eMuGLMpVGXrCo0odR8ZJBZx+b0HIK CVs4WXcgUSamH4Wu2TbsBvaC2zxULUEoVDDvmzk12WpoYP+LYOe5pvLaDHyBjRTa13ZJfF7ECb jNg= X-SBRS: 2.7 X-MesageID: 14352788 X-Ironport-Server: esa3.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED X-IronPort-AV: E=Sophos;i="5.72,285,1580792400"; d="scan'208";a="14352788" From: Roger Pau Monne To: Date: Fri, 20 Mar 2020 20:07:36 +0100 Message-ID: <20200320190737.42110-3-roger.pau@citrix.com> X-Mailer: git-send-email 2.25.0 In-Reply-To: <20200320190737.42110-1-roger.pau@citrix.com> References: <20200320190737.42110-1-roger.pau@citrix.com> MIME-Version: 1.0 Subject: [Xen-devel] [PATCH 2/3] x86/nvmx: clarify and fix usage of nvmx_update_apicv X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Jun Nakajima , Wei Liu , Andrew Cooper , Jan Beulich , Roger Pau Monne Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The current usage of nvmx_update_apicv is not clear: it is deeply intertwined with the Ack interrupt on exit VMEXIT control. The code in nvmx_update_apicv should update the SVI (in service interrupt) field of the guest interrupt status only when the Ack interrupt on exit is set, as it is used to record that the interrupt being serviced is signaled in a vmcs field, and hence hasn't been injected as on native. It's important to record the current in service interrupt on the guest interrupt status field, or else further interrupts won't respect the priority of the in service one. While clarifying the usage make sure that the SVI is only updated when Ack on exit is set and the nested vmcs interrupt info field is valid. Or else a guest not using the Ack on exit feature would loose interrupts as they would be signaled as being in service on the guest interrupt status field but won't actually be recorded on the interrupt info vmcs field, neither injected in any other way. Signed-off-by: Roger Pau Monné --- xen/arch/x86/hvm/vmx/vvmx.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c index 1b8461ba30..180d01e385 100644 --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -1383,7 +1383,7 @@ static void nvmx_update_apicv(struct vcpu *v) { struct nestedvmx *nvmx = &vcpu_2_nvmx(v); unsigned long reason = get_vvmcs(v, VM_EXIT_REASON); - uint32_t intr_info = nvmx->intr.intr_info; + unsigned long intr_info = get_vvmcs(v, VM_EXIT_INTR_INFO); if ( reason == EXIT_REASON_EXTERNAL_INTERRUPT && nvmx->intr.source == hvm_intsrc_lapic && @@ -1399,6 +1399,15 @@ static void nvmx_update_apicv(struct vcpu *v) ppr = vlapic_set_ppr(vlapic); WARN_ON((ppr & 0xf0) != (vector & 0xf0)); + /* + * SVI must be updated when the interrupt has been signaled using the + * Ack on exit feature, or else the currently in-service interrupt + * won't be respected. + * + * Note that this is specific to the fact that when doing a VMEXIT an + * interrupt might get delivered using the interrupt info vmcs field + * instead of being injected normally. + */ status = vector << VMX_GUEST_INTR_STATUS_SVI_OFFSET; rvi = vlapic_has_pending_irq(v); if ( rvi != -1 )