From nobody Mon Apr 29 05:47:46 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1517005617135314.433796459944; Fri, 26 Jan 2018 14:26:57 -0800 (PST) Received: from localhost ([::1]:58691 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efCSQ-0004u0-OE for importer@patchew.org; Fri, 26 Jan 2018 17:26:50 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56280) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1efCRQ-0004QB-6n for qemu-devel@nongnu.org; Fri, 26 Jan 2018 17:25:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1efCRM-0008P1-SU for qemu-devel@nongnu.org; Fri, 26 Jan 2018 17:25:48 -0500 Received: from 9.mo69.mail-out.ovh.net ([46.105.56.78]:51122) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1efCRM-0008KH-Ig for qemu-devel@nongnu.org; Fri, 26 Jan 2018 17:25:44 -0500 Received: from player699.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id 5776B5529B for ; Fri, 26 Jan 2018 23:25:35 +0100 (CET) Received: from bahia.lan (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player699.ha.ovh.net (Postfix) with ESMTPA id BC24B24007E; Fri, 26 Jan 2018 23:25:30 +0100 (CET) From: Greg Kurz To: qemu-devel@nongnu.org Date: Fri, 26 Jan 2018 23:25:24 +0100 Message-ID: <151700552398.7196.2573848773899364520.stgit@bahia.lan> User-Agent: StGit/0.17.1-46-g6855-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Ovh-Tracer-Id: 12312278433602705909 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtvddrvddvgddtudculddtuddrgedtuddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 46.105.56.78 Subject: [Qemu-devel] [PATCH] spapr_pci: fix MSI/MSIX selection X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Alexey Kardashevskiy , qemu-ppc@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 In various place we don't correctly check if the device supports MSI or MSI-X. This can cause devices to be advertised with MSI support, even if they only support MSI-X (like virtio-pci-* devices for example): ethernet@0 { ibm,req#msi =3D <0x1>; <--- wrong! . ibm,loc-code =3D "qemu_virtio-net-pci:0000:00:00.0"; . ibm,req#msi-x =3D <0x3>; }; Worse, this can also cause the "ibm,change-msi" RTAS call to corrupt the PCI status and cause migration to fail: qemu-system-ppc64: get_pci_config_device: Bad config data: i=3D0x6 read: 0 device: 10 cmask: 10 wmask: 0 w1cmask:0 ^^ PCI_STATUS_CAP_LIST bit which is assumed to be constant This patch changes spapr_populate_pci_child_dt() to properly check for MSI support using msi_present(): this ensures that PCIDevice::msi_cap was set by msi_init() and that msi_nr_vectors_allocated() will look at the right place in the config space. Checking PCIDevice::msix_entries_nr is enough for MSI-X but let's add a call to msix_present() there as well for consistency. It also changes rtas_ibm_change_msi() to select the appropriate MSI type in Function 1 instead of always selecting plain MSI. This new behaviour is compliant with LoPAPR 1.1, as described in "Table 71. ibm,change-msi Argument Call Buffer": Function 1: If Number Outputs is equal to 3, request to set to a new number of MSIs (including set to 0). If the =E2=80=9Cibm,change-msix-capable=E2=80=9D property exists= and Number Outputs is equal to 4, request is to set to a new number of MSI or MSI-X (platform choice) interrupts (including set to 0). Since MSI is the the platform default (LoPAPR 6.2.3 MSI Option), let's check for MSI support first. And finally, it checks the input parameters are valid, as described in LoPAPR 1.1 "R1=E2=80=937.3.10.5.1=E2=80=933": For the MSI option: The platform must return a Status of -3 (Parameter error) from ibm,change-msi, with no change in interrupt assignments if the PCI configuration address does not support MSI and Function 3 was requested (that is, the =E2=80=9Cibm,req#msi=E2=80=9D property must exist= for the PCI configuration address in order to use Function 3), or does not support MSI-X and Function 4 is requested (that is, the =E2=80=9Cibm,req#msi-x=E2= =80=9D property must exist for the PCI configuration address in order to use Function 4), or if neither MSIs nor MSI-Xs are supported and Function 1 is requested. This ensures that the ret_intr_type variable contains a valid MSI type for this device, and that spapr_msi_setmsg() won't corrupt the PCI status. Signed-off-by: Greg Kurz Reviewed-by: Alexey Kardashevskiy --- hw/ppc/spapr_pci.c | 61 ++++++++++++++++++++++++++++++++++++------------= ---- 1 file changed, 42 insertions(+), 19 deletions(-) diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c index 37f18b3d3235..39a14980d397 100644 --- a/hw/ppc/spapr_pci.c +++ b/hw/ppc/spapr_pci.c @@ -280,13 +280,42 @@ static void rtas_ibm_change_msi(PowerPCCPU *cpu, sPAP= RMachineState *spapr, int *config_addr_key; Error *err =3D NULL; =20 + /* Fins sPAPRPHBState */ + phb =3D spapr_pci_find_phb(spapr, buid); + if (phb) { + pdev =3D spapr_pci_find_dev(spapr, buid, config_addr); + } + if (!phb || !pdev) { + rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR); + return; + } + switch (func) { - case RTAS_CHANGE_MSI_FN: case RTAS_CHANGE_FN: - ret_intr_type =3D RTAS_TYPE_MSI; + if (msi_present(pdev)) { + ret_intr_type =3D RTAS_TYPE_MSI; + } else if (msix_present(pdev)) { + ret_intr_type =3D RTAS_TYPE_MSIX; + } else { + rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR); + return; + } + break; + case RTAS_CHANGE_MSI_FN: + if (msi_present(pdev)) { + ret_intr_type =3D RTAS_TYPE_MSI; + } else { + rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR); + return; + } break; case RTAS_CHANGE_MSIX_FN: - ret_intr_type =3D RTAS_TYPE_MSIX; + if (msix_present(pdev)) { + ret_intr_type =3D RTAS_TYPE_MSIX; + } else { + rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR); + return; + } break; default: error_report("rtas_ibm_change_msi(%u) is not implemented", func); @@ -294,16 +323,6 @@ static void rtas_ibm_change_msi(PowerPCCPU *cpu, sPAPR= MachineState *spapr, return; } =20 - /* Fins sPAPRPHBState */ - phb =3D spapr_pci_find_phb(spapr, buid); - if (phb) { - pdev =3D spapr_pci_find_dev(spapr, buid, config_addr); - } - if (!phb || !pdev) { - rtas_st(rets, 0, RTAS_OUT_PARAM_ERROR); - return; - } - msi =3D (spapr_pci_msi *) g_hash_table_lookup(phb->msi, &config_addr); =20 /* Releasing MSIs */ @@ -1286,13 +1305,17 @@ static void spapr_populate_pci_child_dt(PCIDevice *= dev, void *fdt, int offset, _FDT(fdt_setprop_cell(fdt, offset, "#size-cells", RESOURCE_CELLS_SIZE)); =20 - max_msi =3D msi_nr_vectors_allocated(dev); - if (max_msi) { - _FDT(fdt_setprop_cell(fdt, offset, "ibm,req#msi", max_msi)); + if (msi_present(dev)) { + max_msi =3D msi_nr_vectors_allocated(dev); + if (max_msi) { + _FDT(fdt_setprop_cell(fdt, offset, "ibm,req#msi", max_msi)); + } } - max_msix =3D dev->msix_entries_nr; - if (max_msix) { - _FDT(fdt_setprop_cell(fdt, offset, "ibm,req#msi-x", max_msix)); + if (msix_present(dev)) { + max_msix =3D dev->msix_entries_nr; + if (max_msix) { + _FDT(fdt_setprop_cell(fdt, offset, "ibm,req#msi-x", max_msix)); + } } =20 populate_resource_props(dev, &rp);