On Mon, 13 Nov 2023, Mark Cave-Ayland wrote:
On 07/11/2023 10:43, Kevin Wolf wrote:
Am 06.11.2023 um 17:13 hat BALATON Zoltan geschrieben:
On Mon, 6 Nov 2023, Kevin Wolf wrote:
Am 25.10.2023 um 00:40 hat Mark Cave-Ayland geschrieben:
Allow the VIA IDE controller to switch between both legacy and native
modes by
calling pci_ide_update_mode() to reconfigure the device whenever
PCI_CLASS_PROG
is updated.
This patch moves the initial setting of PCI_CLASS_PROG from
via_ide_realize() to
via_ide_reset(), and removes the direct setting of PCI_INTERRUPT_PIN
during PCI
bus reset since this is now managed by pci_ide_update_mode(). This
ensures that
the device configuration is always consistent with respect to the
currently
selected mode.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Tested-by: BALATON Zoltan <bala...@eik.bme.hu>
Tested-by: Bernhard Beschow <shen...@gmail.com>
As I already noted in patch 1, the interrupt handling seems to be wrong
here, it continues to use the ISA IRQ in via_ide_set_irq() even after
switching to native mode.
That's a peculiarity of this via-ide device. It always uses 14/15 legacy
interrupts even in native mode and guests expect that so using native
interrupts would break pegasos2 guests. This was discussed and tested
extensively before.
This definitely needs a comment to explain the situation then because
this is in violation of the spec. If real hardware behaves like this,
it's what we should do, of course, but it's certainly unexpected and we
should explicitly document it to avoid breaking it later when someone
touches the code who doesn't know about this peculiarity.
It's a little bit more complicated than this: in native mode it is possible
to route the IRQs for each individual channel to a small select number of
IRQs by configuring special registers on the VIA.
That's documented for VT82c686B but VT8231 doc says other values are
reserved and only IRQ 14/15 is valid. So even if it worked nothing uses it
and we don't have to be concerned about it and just using these hard coded
14/15 is enough. It probably does not worth trying to emulate chip
functions that no guest uses, especially when we're not sure how the real
chip works as we can't test on real machine.
Regards,
BALATON Zoltan
The complication here is that it isn't immediately obvious how the QEMU PCI
routing code can do this - I did post about this at
https://lists.gnu.org/archive/html/qemu-devel/2023-10/msg10552.html asking
the best way to resolve this, but haven't had any replies yet.
Fortunately it seems that all the guests tested so far stick with the IRQ
14/15 defaults which is why this happens to work, so short-term this is a
lower priority when looking at consolidating the switching logic.
ATB,
Mark.
