From patchwork Tue Mar 15 18:34:35 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Markus Armbruster X-Patchwork-Id: 8591591 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id BB1519F44D for ; Tue, 15 Mar 2016 18:43:17 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 25FBE20272 for ; Tue, 15 Mar 2016 18:43:17 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6A6A02026C for ; Tue, 15 Mar 2016 18:43:16 +0000 (UTC) Received: from localhost ([::1]:50666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aftw3-00065K-Sg for patchwork-qemu-devel@patchwork.kernel.org; Tue, 15 Mar 2016 14:43:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afto9-0006fr-Pv for qemu-devel@nongnu.org; Tue, 15 Mar 2016 14:35:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afto8-0001qT-4Q for qemu-devel@nongnu.org; Tue, 15 Mar 2016 14:35:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afto7-0001q1-V2 for qemu-devel@nongnu.org; Tue, 15 Mar 2016 14:35:04 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 8472D165453; Tue, 15 Mar 2016 18:35:03 +0000 (UTC) Received: from blackfin.pond.sub.org (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2FIZ17Z009986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Mar 2016 14:35:02 -0400 Received: by blackfin.pond.sub.org (Postfix, from userid 1000) id F06CF3004FBC; Tue, 15 Mar 2016 19:34:56 +0100 (CET) From: Markus Armbruster To: qemu-devel@nongnu.org Date: Tue, 15 Mar 2016 19:34:35 +0100 Message-Id: <1458066895-20632-21-git-send-email-armbru@redhat.com> In-Reply-To: <1458066895-20632-1-git-send-email-armbru@redhat.com> References: <1458066895-20632-1-git-send-email-armbru@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 15 Mar 2016 18:35:03 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: claudio.fontana@huawei.com, cam@cs.ualberta.ca, mlureau@redhat.com, david.marchand@6wind.com, pbonzini@redhat.com Subject: [Qemu-devel] [PATCH v3 20/40] ivshmem: Leave INTx alone when using MSI-X X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, 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 The ivshmem device can either use MSI-X or legacy INTx for interrupts. With MSI-X enabled, peer interrupt events trigger an MSI as they should. But software can still raise INTx via interrupt status and mask register in BAR 0. This is explicitly prohibited by PCI Local Bus Specification Revision 3.0, section 6.8.3.3: While enabled for MSI or MSI-X operation, a function is prohibited from using its INTx# pin (if implemented) to request service (MSI, MSI-X, and INTx# are mutually exclusive). Fix the device model to leave INTx alone when using MSI-X. Document that we claim to use INTx in config space even when we don't. Unlike other devices, ivshmem does *not* use INTx when configured for MSI-X and MSI-X isn't enabled by software. Signed-off-by: Markus Armbruster Reviewed-by: Marc-André Lureau Reviewed-by: Paolo Bonzini --- hw/misc/ivshmem.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c index abcb1c1..65e3a76 100644 --- a/hw/misc/ivshmem.c +++ b/hw/misc/ivshmem.c @@ -126,6 +126,11 @@ static void ivshmem_update_irq(IVShmemState *s) PCIDevice *d = PCI_DEVICE(s); uint32_t isr = s->intrstatus & s->intrmask; + /* No INTx with msi=on, whether the guest enabled MSI-X or not */ + if (ivshmem_has_feature(s, IVSHMEM_MSI)) { + return; + } + /* don't print ISR resets */ if (isr) { IVSHMEM_DPRINTF("Set IRQ to %d (%04x %04x)\n", @@ -873,6 +878,10 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error **errp) pci_conf = dev->config; pci_conf[PCI_COMMAND] = PCI_COMMAND_IO | PCI_COMMAND_MEMORY; + /* + * Note: we don't use INTx with IVSHMEM_MSI at all, so this is a + * bald-faced lie then. But it's a backwards compatible lie. + */ pci_config_set_interrupt_pin(pci_conf, 1); memory_region_init_io(&s->ivshmem_mmio, OBJECT(s), &ivshmem_mmio_ops, s,