On Thu, 23 Feb 2023, Bernhard Beschow wrote:
> On Thu, Feb 23, 2023 at 1:34 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>>>> I don't get your approach.
>>>>>
>>>>> I hope that I could help you get a better understanding. The linked
>>>>> .pdf is good and comprehensive reading material.
>>>>
>>>> I'm not sure the via-ide confirms to that doc but it's also not any
>>>> more a problem with via-ide now. That was discussed to death back then
>>>> and "fixed" to work for the cases we want it to work with. We probably
>>>> never agreed on how this really works but at least what we ended up
>>>> with works with guests that run on real hardware. I'm OK with also
>>>> making these cases work that we want now such as network and sound card
>>>> under AmigaOS and sound under MorphOS (as long as you don't use USB) on
>>>> pegasos2. This series does that so unless it breaks something that
>>>> worked before I condider this moving forward and we can always improve
>>>> adn fix it later. I'm not saying I'm not interested in your
>>>> improvements just that let's that not hold this back now as we can fix
>>>> and improve it later but otherwise users will have to wait until
>>>> September to be able to use it. I know a few who want this and getting
>>>> this out as it is would allow more people to test it and report
>>>> problems so unless there are clearly wrong parts I'm OK with less than
>>>> perfect but working solution as long as it's not too messy.
>>>
>>> Patch 1 really seems like duplicating PCI code that already exists in
>>> QEMU. This is not needed and we should avoid that.
>>>
>>> Moreover, usage of the IRQ line register (0x3c) for interrupt routing
>>> should be switched to using the 0x55-0x57 regs to be PCI compliant.
>>
>> That would not work because then guests were not able to separately
>> configure IRQs for PCI interrupt lines and internal functions which is
>> what the datasheet says should be possible. The internal functions' IRQs
>> are not affeceted by 0x55-0x57 but routed by different registers.
>
> How do you know?
The datasheet says so. It says that 0x55-0x57 are controlling what ISA
interrupts the PIRQA-D pins should raise while internal functions are
documented to have 0x3c register to select what ISA IRQ they use. It's not
said internal functions would use PCI interrupts that are separate and
connected to the PIRQ pins.
> I think
>> your series only work because pegasos2 firmware progeams everything to
>> IRQ9 but if a guest decided to change that and route e.g. USB somewhere
>> else then it would break. My series models that a bit better but may still
>> break if a guest routes a function to an IRQ also controlled by some ISA
>> device (like serial or ps2 keyboard) which are currently done within
>> QEMU's ISA model so I can't easily channel those IRQs through the
>> via-isa.for proper routing but it's unliikely guests would want to do that
>> so in practice my series should work. We may duplicate PCI IRQ routing
>> here but this chip does that and more so we need to implement it as it
>> handles more than the 4 PCI interrupts so that implementation is not
>> enough to handle all sources this chip has. This isn't a complex piece of
>> code though so having a similar implementation is not a problem IMO.
>>
>>> Thanks to your great work to make via-ac97 work we can confirm that both
>>> IRQ routing implementations basically work for now. Let's work out a
>>> solution that relies on existing code, sticks to the standard and
>>> hopefully works for i386 and MIPS, too.
>>
>> I'm still not convinced your implementation is correct
>
>
> It seems that Mark (cc'd), I, the commenter in
> https://community.osr.com/discussion/30399/read-only-pci-interrupt-line-register
> and the PCI specification agree that the 0x3c regs aren't supposed to be
> interpreted by hardware.
You could still all be wrong if the PCI spec does not apply to the
internal functions of the VIA chip which is just an assumption you made
but the docs and experience never proved that so I don't believe that's a
valid assumption. According to the datasheet internal functions'
interrupts are routed independently from PCI interrupts which is what I've
tried to model.
> I've provided a working example with no functional
> downsides to the 0x3c approach. I've provided the PCI-IDE reading material
> that Mark suggested for reading in
> b38987d5-5530-ecd9-2fd2-3a57e1a611dd@ilande.co.uk/" rel="noreferrer" target="_blank">https://lore.kernel.org/qemu-devel/b38987d5-5530-ecd9-2fd2-3a57e1a611dd@ilande.co.uk/
> . I'm running out of ideas now on how to proceed.
Please submit an alternative series that we can test and if it works with
the guests that I want to run like mine we can take that instead even if I
believe your way is wrong. I don't care about who's right as long as it
works. But make sure it gets in for 8.0 as I do care that it should work
in the next release.
Please submit further iterations when audio changes are needed.
Best regards,
Bernhard
Regards,
BALATON Zoltan