From: Bernhard Beschow <shentey@gmail.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org,
Gerd Hoffmann <kraxel@redhat.com>,
Daniel Henrique Barboza <danielhb413@gmail.com>,
Peter Maydell <peter.maydell@linaro.org>,
philmd@linaro.org, ReneEngel80@emailn.de
Subject: Re: [PATCH v5 3/7] hw/isa/vt82c686: Implement PCI IRQ routing
Date: Wed, 01 Mar 2023 21:08:37 +0000 [thread overview]
Message-ID: <C6D02032-862B-4159-933C-D2B8C2BE00CC@gmail.com> (raw)
In-Reply-To: <794ef01a-730b-46c6-2e79-95c68bc42102@eik.bme.hu>
Am 1. März 2023 11:15:02 UTC schrieb BALATON Zoltan <balaton@eik.bme.hu>:
>On Wed, 1 Mar 2023, Bernhard Beschow wrote:
>> Am 1. März 2023 00:17:09 UTC schrieb BALATON Zoltan <balaton@eik.bme.hu>:
>>> The real VIA south bridges implement a PCI IRQ router which is configured
>>> by the BIOS or the OS. In order to respect these configurations, QEMU
>>> needs to implement it as well. The real chip may allow routing IRQs from
>>> internal functions independently of PCI interrupts but since guests
>>> usually configute it to a single shared interrupt we don't model that
>>> here for simplicity.
>>>
>>> Note: The implementation was taken from piix4_set_irq() in hw/isa/piix4.
>>>
>>> Suggested-by: Bernhard Beschow <shentey@gmail.com>
>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>> ---
>>> hw/isa/vt82c686.c | 38 +++++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 37 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
>>> index 01e0148967..018a119964 100644
>>> --- a/hw/isa/vt82c686.c
>>> +++ b/hw/isa/vt82c686.c
>>> @@ -604,6 +604,42 @@ static void via_isa_request_i8259_irq(void *opaque, int irq, int level)
>>> qemu_set_irq(s->cpu_intr, level);
>>> }
>>>
>>> +static int via_isa_get_pci_irq(const ViaISAState *s, int irq_num)
>>> +{
>>> + switch (irq_num) {
>>> + case 0:
>>> + return s->dev.config[0x55] >> 4;
>>> + case 1:
>>> + return s->dev.config[0x56] & 0xf;
>>> + case 2:
>>> + return s->dev.config[0x56] >> 4;
>>> + case 3:
>>> + return s->dev.config[0x57] >> 4;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +static void via_isa_set_pci_irq(void *opaque, int irq_num, int level)
>>> +{
>>> + ViaISAState *s = opaque;
>>> + PCIBus *bus = pci_get_bus(&s->dev);
>>> + int i, pic_level, pic_irq = via_isa_get_pci_irq(s, irq_num);
>>> +
>>> + if (unlikely(pic_irq == 0 || pic_irq == 2 || pic_irq > 14)) {
>>
>> Where does the "pic_irq > 14" come from? It's not mentioned in the datasheet.
>
>Check at 0x3c register of USB and AC97 functions. For the others it may be valid but unlikely to be used hence we just disallow it. (In my version which also mapped IDE here I've checkrf for each source but there's no way to do that in this version.)
I'm not sure what you mean. The 0x3c regs aren't related to the PCI IRQ routing regs.
Moreover, as I wrote in my other mail, I wonder what the datasheet tries to tell us here at all. The information there partly contradicts itself.
Can you please clarify?
Thanks,
Bernhard
>
>Regards,
>BALATON Zoltan
>
>>> + return;
>>> + }
>>> +
>>> + /* The pic level is the logical OR of all the PCI irqs mapped to it. */
>>> + pic_level = 0;
>>> + for (i = 0; i < PCI_NUM_PINS; i++) {
>>> + if (pic_irq == via_isa_get_pci_irq(s, i)) {
>>> + pic_level |= pci_bus_get_irq_level(bus, i);
>>> + }
>>> + }
>>> + /* Now we change the pic irq level according to the via irq mappings. */
>>> + qemu_set_irq(s->isa_irqs_in[pic_irq], pic_level);
>>> +}
>>> +
>>> static void via_isa_realize(PCIDevice *d, Error **errp)
>>> {
>>> ViaISAState *s = VIA_ISA(d);
>>> @@ -615,9 +651,9 @@ static void via_isa_realize(PCIDevice *d, Error **errp)
>>>
>>> qdev_init_gpio_out(dev, &s->cpu_intr, 1);
>>> isa_irq = qemu_allocate_irqs(via_isa_request_i8259_irq, s, 1);
>>> + qdev_init_gpio_in_named(dev, via_isa_set_pci_irq, "pirq", PCI_NUM_PINS);
>>> isa_bus = isa_bus_new(dev, pci_address_space(d), pci_address_space_io(d),
>>> errp);
>>> -
>>> if (!isa_bus) {
>>> return;
>>> }
>>
>>
next prev parent reply other threads:[~2023-03-01 21:09 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-01 0:17 [PATCH v5 0/7] Pegasos2 fixes and audio output support BALATON Zoltan
2023-03-01 0:17 ` [PATCH v5 1/7] hw/display/sm501: Add debug property to control pixman usage BALATON Zoltan
2023-03-02 21:51 ` BALATON Zoltan
2023-03-01 0:17 ` [PATCH v5 2/7] Revert "hw/isa/vt82c686: Remove intermediate IRQ forwarder" BALATON Zoltan
2023-03-01 0:33 ` BALATON Zoltan
2023-03-01 6:43 ` Bernhard Beschow
2023-03-01 11:17 ` BALATON Zoltan
2023-03-02 10:41 ` Philippe Mathieu-Daudé
2023-03-02 10:44 ` Philippe Mathieu-Daudé
2023-03-02 12:37 ` BALATON Zoltan
2023-03-02 12:46 ` Philippe Mathieu-Daudé
2023-03-01 0:17 ` [PATCH v5 3/7] hw/isa/vt82c686: Implement PCI IRQ routing BALATON Zoltan
2023-03-01 6:38 ` Bernhard Beschow
2023-03-01 11:15 ` BALATON Zoltan
2023-03-01 21:08 ` Bernhard Beschow [this message]
2023-03-01 21:27 ` BALATON Zoltan
2023-03-01 0:17 ` [PATCH v5 4/7] hw/ppc/pegasos2: Fix PCI interrupt routing BALATON Zoltan
2023-03-03 9:17 ` Daniel Henrique Barboza
2023-03-01 0:17 ` [PATCH v5 5/7] hw/isa/vt82c686: Work around missing level sensitive irq in i8259 model BALATON Zoltan
2023-03-01 6:49 ` Bernhard Beschow
2023-03-01 11:27 ` BALATON Zoltan
2023-03-01 11:52 ` David Woodhouse
2023-03-01 13:18 ` BALATON Zoltan
2023-03-01 14:05 ` David Woodhouse
2023-03-01 18:01 ` BALATON Zoltan
2023-03-01 21:53 ` David Woodhouse
2023-03-01 22:47 ` BALATON Zoltan
2023-03-02 8:59 ` David Woodhouse
2023-03-02 9:06 ` [PATCH] hw/intc/i8259: Implement legacy LTIM Edge/Level Bank Select David Woodhouse
2023-03-02 9:58 ` David Woodhouse
2023-03-02 12:35 ` BALATON Zoltan
2023-03-02 21:46 ` [PATCH v5 5/7] hw/isa/vt82c686: Work around missing level sensitive irq in i8259 model BALATON Zoltan
2023-03-01 20:58 ` Bernhard Beschow
2023-03-01 0:17 ` [PATCH v5 6/7] hw/usb/vt82c686-uhci-pci: Use PCI IRQ routing BALATON Zoltan
2023-03-01 0:17 ` [PATCH v5 7/7] hw/audio/via-ac97: Basic implementation of audio playback BALATON Zoltan
2023-03-02 21:59 ` BALATON Zoltan
2023-03-03 6:57 ` Volker Rümelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C6D02032-862B-4159-933C-D2B8C2BE00CC@gmail.com \
--to=shentey@gmail.com \
--cc=ReneEngel80@emailn.de \
--cc=balaton@eik.bme.hu \
--cc=danielhb413@gmail.com \
--cc=kraxel@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).