From patchwork Sun Sep 29 21:24:31 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chao Gao X-Patchwork-Id: 11166003 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 52B3D1599 for ; Mon, 30 Sep 2019 05:18: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 32F2120815 for ; Mon, 30 Sep 2019 05:18:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32F2120815 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none 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 1iEo3B-00018d-GA; Mon, 30 Sep 2019 05:16:45 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iEo3A-00018V-H0 for xen-devel@lists.xenproject.org; Mon, 30 Sep 2019 05:16:44 +0000 X-Inumbo-ID: 7c103fba-e341-11e9-97fb-bc764e2007e4 Received: from mga03.intel.com (unknown [134.134.136.65]) by localhost (Halon) with ESMTPS id 7c103fba-e341-11e9-97fb-bc764e2007e4; Mon, 30 Sep 2019 05:16:41 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Sep 2019 22:16:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,565,1559545200"; d="scan'208";a="220535688" Received: from knl-rvp-beta.sh.intel.com ([10.239.48.66]) by fmsmga002.fm.intel.com with ESMTP; 29 Sep 2019 22:16:38 -0700 From: Chao Gao To: xen-devel@lists.xenproject.org, chao.gao@intel.com Date: Mon, 30 Sep 2019 05:24:31 +0800 Message-Id: <1569792271-19856-1-git-send-email-chao.gao@intel.com> X-Mailer: git-send-email 1.8.3.1 Subject: [Xen-devel] [PATCH for Xen 4.13] x86/msi: Don't panic if msix capability is missing 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: Andrew Cooper , Jan Beulich , Wei Liu , =?utf-8?q?Roger_Pau_?= =?utf-8?q?Monn=C3=A9?= MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Current, Xen isn't aware of device reset (initiated by dom0). Xen may access the device while device cannot respond to config requests normally (e.g. after device reset, device may respond to config requests with CRS completions to indicate it needs more time to complete a reset, refer to pci_dev_wait() in linux kernel for more detail). Here, don't assume msix capability is always visible and return -EAGAIN to the caller. Signed-off-by: Chao Gao --- I didn't find a way to trigger the assertion in normal usages. It is found by an internal test: echo 1 to /sys/bus/pci//reset when the device is being used by a guest. Although the test is a little insane, it is better to avoid crashing Xen even for this case. --- xen/arch/x86/msi.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c index 76d4034..e2f3c6c 100644 --- a/xen/arch/x86/msi.c +++ b/xen/arch/x86/msi.c @@ -1265,7 +1265,13 @@ int pci_msi_conf_write_intercept(struct pci_dev *pdev, unsigned int reg, pos = entry ? entry->msi_attrib.pos : pci_find_cap_offset(seg, bus, slot, func, PCI_CAP_ID_MSIX); - ASSERT(pos); + if ( unlikely(!pos) ) + { + printk_once(XENLOG_WARNING + "%04x:%02x:%02x.%u MSI-X capability is missing\n", + seg, bus, slot, func); + return -EAGAIN; + } if ( reg >= pos && reg < msix_pba_offset_reg(pos) + 4 ) {