RE: Emulating Solaris 10 on SPARC64 sun4u

[BALATON Zoltan]

On Wed, 19 Feb 2020, BALATON Zoltan wrote:
> On Wed, 19 Feb 2020, BALATON Zoltan wrote:
> > faster or doing something differently? Does someone know what interrupts 
> > are generated on real hardware in DMA mode so we can compare that to what 
> > we see with QEMU?
>
> The document Programming Interface for Bus Master IDE Controller, Revision 
> 1.0 (5/16/94) has some info on this. AFAIU it says that after DMA operation 
> is completed an IRQ should be raised. On page 5, section 3.1. Data 
> Synchronization it says:
>
> "Another way to view this requirement is that the first read to the 
> controller Status register in response to the IDE device interrupt must 
> return with the Interrupt bit set and with the guarantee that all buffered 
> data has been written to memory."
>
> Not sure if this is relevant but how is it handled in QEMU? Is the right 
> interrupt bit set after DMA transfer is done? If so is it the one that's 
> checked by the OS driver?

I think I now understand the problem with via-ide at least and the 
following is true for that case. I'm not sure about the CMD646 but it may 
be similar as these seem to be similar designs or maybe even related 
somehow. The problem in my case stems from that the device has two modes 
documented: legacy where it uses standard ISA ioports and INT14 and 15 for 
the two channels and native mode in which it uses PCI BARs for io address 
and an IRQ configurable via PCI_INTERRUPT_LINE (config reg 9). It seems 
the IRQ in native mode is still not a PCI INT line but an ISA IRQ, however 
it can be selected by config reg and it's a single interrupt instead of 
two for separate channels (Linux prints these during boot so that's a good 
way to check which mode it thinks it's using). That's so far is complex 
enough to not be easy to emulate in QEMU as we can set up legacy ISA ports 
with ide_init_ioport() but there's no way then to switch it off so via-ide 
either implemented legacy or native mode but can't correctly switch 
between those. This may not be a problem most of the time for Linux at 
least which tries to check which mode the controller is in and use that so 
it would work with whatever is there as long as the regs match what's 
emulated so we can just emulate one mode and still work.

But all of the above is further complicated by that on some (most?) boards 
there's also a "non 100% native mode" in which the io addresses are taken 
from the PCI BARs but still using hardcoded INT14 and 15, ignoring the 
setting in PCI_INTERRUPT_LINE. So guest drivers may assume this without 
checking regs and not care about what's set in PCI_INTERRUPT_LINE just 
expect interrupts on INT14 and 15. If the emulation raises PCI INT or some 
other isa interrupt it won't work, even if config regs correctly describe 
the difference following the docs but guest drivers don't care about the 
chip spec only the implementation on the board they meant to run on. 
Unfortunately different guests use different heuristics and workarounds 
(even Linux does so on different archs) so it's not easy to make an 
emulation that works with all. The pegasos2 firmware for example sets 
via-ide in native mode and assigns interrupt 9 but on real hardware this 
reg seems to be hardcoded to 14 and Linux uses this to detect if it needs 
to use the half-native mode but sets the mode reg to legacy to note this 
despite then using PCI BARs (so we can't hardcode mode reg to always 
native without breaking this but have to force int reg and emulate half 
native mode to work with other guests). Linux would also work with 100% 
native mode with IRQ9 but Amiga like OSes don't seem to care and just use 
hardcoded half-native mode regardless of config regs and expect interrupt 
on IRQ14 and 15. I could make a patch to work with all these on pegasos2 
but the via-ide is also used on a mips board where the corresponding Linux 
version also applies its own (different) workarounds corresponding to the 
quirks of that board and ends up either trying to use legacy mode (which 
is not emulated as io is only on PCI BARs) or trying to use 100% native 
mode which does not work with half-native interrupts. I think I'll need to 
add a special property to the device to set it to half-native for pegasos2 
and leave it 100% native for mips, otherwise there may not be a 
combination which works with all these firmwares and guests on both 
machines. (We still can avoid having to implement native mode as well but 
I can imagine if some PC guests were involved we may need that too but on 
these ppc and mips boards and also in your case I think native and 
half-native modes should be enough as that's all guests use.)

The CMD646 case might be similar and that's also used on a hppa board so 
you may need to check with that too if you make changes. To check this 
theory you might try forcing ide interrupts to be IRQ14 and 15 via 
something like:

qemu_set_irq(isa_get_irq(NULL, (channel ? 15 : 14)), level);

instead of using PCI interrupt or configured ISA interrupt in native mode 
and see if Solaris likes it better. If so then go on a quest to find a 
combination that works with at least Linux on both the sparc and hppa 
boards and Solaris (if that's not enough you can also try NeXTSTEP :-) ). 
So I think after all the common ide and bmdma code is probably OK and we 
have problems in individual controller emulations which is made difficult 
because of different hardware quirks and assumptions of guest sofware.

Regards,
BALATON Zoltan