On Thu, Feb 23, 2023 at 3:23 PM BALATON Zoltan <bala...@eik.bme.hu> wrote:
> On Thu, 23 Feb 2023, Bernhard Beschow wrote: > > On Thu, Feb 23, 2023 at 1:34 PM BALATON Zoltan <bala...@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 > > > https://lore.kernel.org/qemu-devel/b38987d5-5530-ecd9-2fd2-3a57e1a61...@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. > Here we go: https://lore.kernel.org/qemu-devel/20230223202053.117050-1-shen...@gmail.com/ Please submit further iterations when audio changes are needed. Best regards, Bernhard > > Regards, > BALATON Zoltan >
