Re: [PATCH v2 3/3] hw/ide/via: implement legacy/native mode switching

[BALATON Zoltan]

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-ayland@ilande.co.uk>
> > > > > Tested-by: BALATON Zoltan <balaton@eik.bme.hu>
> > > > > Tested-by: Bernhard Beschow <shentey@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.