From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 939B7C433DB for ; Thu, 31 Dec 2020 15:36:01 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 F1A6C20798 for ; Thu, 31 Dec 2020 15:36:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F1A6C20798 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:46802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kuzzb-0000qZ-RW for qemu-devel@archiver.kernel.org; Thu, 31 Dec 2020 10:35:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kuzyh-0000Kk-0B for qemu-devel@nongnu.org; Thu, 31 Dec 2020 10:35:03 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:41113) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kuzyf-0003Sc-6i for qemu-devel@nongnu.org; Thu, 31 Dec 2020 10:35:02 -0500 Received: by mail-ed1-x535.google.com with SMTP id i24so18447288edj.8 for ; Thu, 31 Dec 2020 07:35:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LAtqigyxIB6iW0jmwf26+YtqPJRrnmOekDv4rBie1aM=; b=Cb+NkrT9KjQzOcfL3FOxEHrbV5i7q7LyEk6RU+AaH1OW9D4On6jVlWzx1RIaI2X3X4 o2GLyVruAbSMh+mOyF3+kZQiAB7AAvGZJeZzu39B0+c9wx2vxqbSx3Muz15WdWV25aly C0o9yy+qnj72J47mFwmBgjxeX3GukXTXE2YdF2YVZQtCLjaFl6gGUioAtsMQa34Y5mM4 ScR2ZokAn61bYtVSo8RvduhCVAh6JGEyqJ942NtxkFCIF9qp99ccvS5JREOsH4m+62xf 5LRBlBz8Tj5AffYBVZz10YEg8Ys+/WtNyfkIJSJxSu5iu7tVKK4krr9yiXOiZYparyUH KWdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LAtqigyxIB6iW0jmwf26+YtqPJRrnmOekDv4rBie1aM=; b=R1vb9E8l0rh/4iEMQLKwjUX/T+ADOQeWILpsM9SiQpUoU4N6BfZ+XrYjgfDkukcTTa N0sfKH2S4BrW2lLzzWVwp8FFaWb6uphLiR0tJcjy/tN1azt+zT+CJEVDosM9T08dt1sM s3tI1bE4Oc3d67fWbR2XbugjXAWSgL3AATCF0Cw9aE5PZ0TRRQmZiomJ5krEtLNme/al yZIdkFCOUFzN0y662J8wl7My44t6QUJEUR2yQqw0ps3Z1fD4CIE1BZXk9Gus/mnH0Dvm VYfnu7Vu8vxQcaUXsxxfdW+KUYTWE3DBY4/TYjRiovJKAGrOSr0ETkVYgaXZftzBHuqQ AQXA== X-Gm-Message-State: AOAM530apcVq5EnK/taNlpOWiNz5APCM2StrNjJZI1Glmq0Gv+8dZRp0 G3F/0qYFu/e8GoaIeX5WFHUpvg3xwaghT4DVUOIzQg== X-Google-Smtp-Source: ABdhPJy/NR77pq4c+B62CoaPwGWAznB7frehgQvU7gjvpXeUviQkSedR853DY1mL1+slejSf0KNPVP+nBBTbGnLo83c= X-Received: by 2002:a05:6402:366:: with SMTP id s6mr54951366edw.44.1609428899388; Thu, 31 Dec 2020 07:34:59 -0800 (PST) MIME-Version: 1.0 References: <3f0f8fc6-6148-a76e-1088-b7882b0bbcaf@roeck-us.net> <5ef852ee-8a53-df9d-82f4-33a68c05f53a@ilande.co.uk> <5849da05-a063-cd56-7709-c4760c8aa71f@roeck-us.net> In-Reply-To: From: Peter Maydell Date: Thu, 31 Dec 2020 15:34:48 +0000 Message-ID: Subject: Re: Problems with irq mapping in qemu v5.2 To: BALATON Zoltan Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::535; envelope-from=peter.maydell@linaro.org; helo=mail-ed1-x535.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Mark Cave-Ayland , QEMU Developers , Guenter Roeck , "Michael S. Tsirkin" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, 25 Dec 2020 at 23:45, BALATON Zoltan via wrote: > For the Bamboo board we have 4 interrupts connected to the PCI bus in the > board but also have a comment in ppc4xx_pci.c near the above function > saying: > > /* On Bamboo, all pins from each slot are tied to a single board IRQ. This > * may need further refactoring for other boards. */ > static int ppc4xx_pci_map_irq(PCIDevice *pci_dev, int irq_num) > { > int slot = pci_dev->devfn >> 3; > > trace_ppc4xx_pci_map_irq(pci_dev->devfn, irq_num, slot); > > return slot - 1; > } > > Now I'm not sure what that comment means: It definitely doesn't match the code, anyway... > 1. All PCI INTA from all slots go to one irq, PCI INTB to another and so on > > or > > 2. All PCI interrupts (INTA-D) from first slot are connected to one irq on > the board, then those from next slot are to another irq and so on I looked at the datasheet for the PPC440EP SoC itself, and it has only a single PCIINT pin, so all boards using this CPU must end up only asserting one interrupt line into the interrupt controller (presumably via an on-board OR gate?) > The slot - 1 mapping seems to correspond more to 2. but that also means we > can only have 4 slots. You can have more than 4 slots -- one common approach is to stripe the 4 interrupts across slots, so that if you have 4 interrupts 0, 1, 2, 3 then in slot 0 they are wired INTA=0, INTB=1, INTC=2, INTD=3, and in slot 1 they are INTA=1, INTB=2, INTC=3, INTD=0, and in slot 2 they are INTA=2, INTB=3, INTC=4, INTD=1, and so on. This just helps to spread the interrupt usage out and minimise sharing of interrupts between devices, because most PCI cards only ever use INTA (though they are permitted to use all 4 if they have a need for it, I think.) This kind of striping is just implemented by how you connect the pins on the PCI slots. (This striping is what function pci_swizzle_map_irq_fn() implements.) In QEMU's PCI implementation, it's OK for the mapping function to reuse IRQ numbers -- PCI IRQ line changes go via pci_change_irq_level(), which first calls the controller-specific map_irq function, and then in pci_bus_change_irq_level() keeps a count of how many different devices have asserted the (mapped) IRQ, so it calls the controller's set_irq method with effectively the logical-OR of all the input levels. (I was wrong about this in another email I just wrote -- I'll go back and correct that in a moment.) > I did not find a picture of the real board so don't > know how many slots that has or how they are connected. I think we need > more info on the real hardware to tell what's the correct mapping here. Yeah, I couldn't find any documentation for the board itself either :-( Incidentally, if guest software like Linux has been written and tested on QEMU and not on the real hardware, then bugs in the mapping of IRQs can be painful to try to fix, because if the kernel was written with the equal-but-opposite bug it will then not run on a bugfixed QEMU. We had a bit of a mess with the QEMU versatilepb PCI controller that way. thanks -- PMM