From patchwork Tue Apr 26 14:39:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Beulich X-Patchwork-Id: 8939431 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 54609BF29F for ; Tue, 26 Apr 2016 14:41:24 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 87676201BB for ; Tue, 26 Apr 2016 14:41:23 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 636F9201F2 for ; Tue, 26 Apr 2016 14:41:22 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1av497-0005Oj-FW; Tue, 26 Apr 2016 14:39:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1av497-0005ON-22 for xen-devel@lists.xenproject.org; Tue, 26 Apr 2016 14:39:25 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 4F/A7-03293-C9D7F175; Tue, 26 Apr 2016 14:39:24 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRWlGSWpSXmKPExsXS6fjDS3d2rXy 4wf3lGhbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8aEzk7mgrcCFV033RoYP/F2MXJyCAnkScxa uYYdxOYVsJNYt3QHE4gtIWAosW/+KjYQm0VAVeLp1z4WEJtNQF2i7dl21i5GDg4RAQOJc0eTQ MLMAjUSs9rnMYLYwgKhEjf+nGEGKeEVEJT4u0MYosROYvWLb+wTGLlmIWRmIclA2FoSD3/dYo GwtSWWLXzNDFLOLCAtsfwfB0TYSWLe/G2sqEpAbF+JhUfmsCxg5FjFqFGcWlSWWqRraKaXVJS ZnlGSm5iZo2toYKyXm1pcnJiempOYVKyXnJ+7iREYegxAsINx1XbPQ4ySHExKorz38uTDhfiS 8lMqMxKLM+KLSnNSiw8xynBwKEnwmlUD5QSLUtNTK9Iyc4BRAJOW4OBREuF1BUnzFhck5hZnp kOkTjEqSonzXqsCSgiAJDJK8+DaYJF3iVFWSpiXEegQIZ6C1KLczBJU+VeM4hyMSsK8UiDjeT LzSuCmvwJazAS0+PIhWZDFJYkIKakGRkeDyUe/akuEWKwXiFq8Y+pHK4c5HbO/WWybvcnx4oa 7Kv8lu5W3NP9dKvDXM7L+Vdn277f0L8kpT5Kas9bLp0HP7Mvk315vC+dqvQ5acuDj9f9Xn+ze 8nzy/B9cd25H7Dr98lJ4V/7s/TqidwUll+/++tjveOzi94rv8zgsjq6/JZ2W6DpJfZW8EktxR qKhFnNRcSIAInc0nbcCAAA= X-Env-Sender: JBeulich@suse.com X-Msg-Ref: server-14.tower-31.messagelabs.com!1461681561!37028594!1 X-Originating-IP: [137.65.248.74] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9295 invoked from network); 26 Apr 2016 14:39:23 -0000 Received: from prv-mh.provo.novell.com (HELO prv-mh.provo.novell.com) (137.65.248.74) by server-14.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 26 Apr 2016 14:39:23 -0000 Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Tue, 26 Apr 2016 08:39:20 -0600 Message-Id: <571F99BB02000078000E5EC1@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Tue, 26 Apr 2016 08:39:23 -0600 From: "Jan Beulich" To: "xen-devel" Mime-Version: 1.0 Cc: Andrew Cooper , Paul Durrant , Wei Liu Subject: [Xen-devel] [PATCH] x86/vMSI-X: write snoops should ignore hvm_mmio_internal() requests X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Those aren't actual I/O requests (and hence are of no interest here anyway). Since they don't get copied into struct vcpu, looking at that copy reads whatever was left there. Use the state of the request to determine its validity. Signed-off-by: Jan Beulich x86/vMSI-X: write snoops should ignore hvm_mmio_internal() requests Those aren't actual I/O requests (and hence are of no interest here anyway). Since they don't get copied into struct vcpu, looking at that copy reads whatever was left there. Use the state of the request to determine its validity. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vmsi.c +++ b/xen/arch/x86/hvm/vmsi.c @@ -349,6 +349,8 @@ static int msixtbl_range(struct vcpu *v, { const ioreq_t *r = &v->arch.hvm_vcpu.hvm_io.io_req; + if ( r->state != STATE_IOREQ_READY ) + return 0; ASSERT(r->type == IOREQ_TYPE_COPY); if ( r->dir == IOREQ_WRITE && r->size == 4 && !r->data_is_ptr && !(r->data & PCI_MSIX_VECTOR_BITMASK) ) Reviewed-by: Paul Durrant --- a/xen/arch/x86/hvm/vmsi.c +++ b/xen/arch/x86/hvm/vmsi.c @@ -349,6 +349,8 @@ static int msixtbl_range(struct vcpu *v, { const ioreq_t *r = &v->arch.hvm_vcpu.hvm_io.io_req; + if ( r->state != STATE_IOREQ_READY ) + return 0; ASSERT(r->type == IOREQ_TYPE_COPY); if ( r->dir == IOREQ_WRITE && r->size == 4 && !r->data_is_ptr && !(r->data & PCI_MSIX_VECTOR_BITMASK) )