PCI range checking under qemu-system-sparc64

[Mark Cave-Ayland]

On 16/09/15 22:19, Marius Strobl wrote:

>> Hmmm. Thinking back to when I was getting NetBSD/OpenBSD to work under
>> QEMU then first things I would look at are:
>>
>> - Missing UPA/APB diagnostic register implementation from QEMU
>> - Use of an ASI unimplemented/buggy in QEMU
>> - Incorrect interrupt mapping/bug in APB emulation
> 
> Speaking of APB emulation, QEMU apparently cares about adding two
> APBs to the Sabre but there's nothing beneath them, i. e. all PCI
> devices hang off directly from the host-PCI-bridge. This cannot
> be in reality, hardware-wise. The QEMU topology shouldn't pose a
> problem for FreeBSD but I think some x11 part at least one point
> in time had the assumption the if there are APBs (aka Simbas), all
> PCI devices sit underneath them. Anyway, I'm mainly puzzled as to
> why that topology was chosen in QEMU. If there's a problem with
> emulating an entire PCI hierarchy, i. e. devices behind PCI-PCI-
> bridges, why not emulate a Hummingbird and get rid of the APBs
> altogether in the frist place?

This goes back to before my time with OpenBIOS/QEMU but my understanding
is that there was a bug in either the QEMU or OpenBIOS PCI bridge code
that made it impossible to enumerate devices behind the bridge at the
time when the original code was added. There is probably a good chance
that things have changed here, however I'd like to get the basic
emulation working first before making changes to the model (e.g.
creating a virtual hme device). My eventual aim is to be able to run
Solaris in -nographic mode for 64-bit SPARC.

>> Also how does the
>> boot log compare with a complete boot log - often looking at what the
>> next line is on a complete boot log gives a hint as where things are
>> going wrong.
> 
> The next lines should be probe messages of the devices on the
> ATA controller, i. e. something like:
> cd0 at ata3 bus 0 scbus1 target 1 lun 0
> cd0: <TEAC CD-224E 1.7A> Removable CD-ROM SCSI device
> cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes)
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> ada0 at ata3 bus 0 scbus1 target 0 lun 0
> ada0: <ST340016A 3.10> ATA-5 device
> ada0: Serial Number 3HS2QXLQ
> ada0: 66.700MB/s transfers (UDMA4, PIO 8192bytes)
> ada0: 38166MB (78165360 512 byte sectors: 16H 63S/T 16383C)
> ada0: Previously was known as ad0
> 
> And then finally some "Trying to mount root from <...>" line.
> 
> Which suggest that the next thing to investigate is the CMD646
> emulation. Is there a particular reason why QEMU emulates a
> CMD646U rather than a plain CMD646 as found in the real sun4u
> machines of the USIIe/i era?

Mainly because that device is already available in QEMU. From what I've
seen in various driver sources the plain CMD646 is extremely buggy for
DMA and everyone just gives up and disables it ;)

> Alexey, does building the port with CDROM_DMA disabled make
> a difference?
> 
> I've also a gut feeling that interrupts are not working,
> otherwise there should be some timeout message if detection
> of ATA devices fails and finally a panic due to there being
> no source for mounting root (assuming the kernel doesn't
> hang before the enumeration of storage devices).
> Alexey, could you please try to drop into the debugger
> (apparently, ctrl-a b should bring you there with QEMU if
> you have compiled DDB into the kernel) and issue a `show
> intrcnt` (besides a backtrace)?

That's interesting. I've already upstreamed some fixes for CMD646
interrupts in order to get NetBSD/OpenBSD to work. The short version is
that the interrupt acknowledge bits are mirrored between the CMD646
BMDMA and standard registers, and previously QEMU handled them
separately. What was happening was that the interrupt would be cleared
by writing to one register but without the mirror the BMDMA would hang
as its interrupt bit was still asserted.

I have had reports that disk I/O hangs under high load on fast machines
but it's not something I can reproduce here. With some investigation, I
found that the logic in the emulated APB interrupt code isn't quite
right but haven't had a chance to come up with a better solution.

I do have a better (but still wrong) patch for QEMU if anyone is
interested to see if that gets things moving along further.

> Btw., is there a way to netboot with qemu-system-sparc64?
> It would help enormously not to build ISO images for
> testing but apparently at least `boot net:dhcp` isn't
> implemented in QEMU/OpenBIOS.

Unfortunately OpenBIOS doesn't have an IP stack included (yet?). For
testing Linux kernels there are -kernel and -initrd parameters that
simply copy the ELF image into the virtual machine RAM and set the PC to
the entry address on startup. I'm not sure there is an equivalent for
the *BSD ABI though.

>> I also see that the output stops after "IPsec: Initialized Security
>> Association Processing." appears on the console. Maybe the crypto uses
>> paths that aren't well tested in QEMU or we are waiting for entrophy?
> 
> Unlikely; "Initialized" means just that, the SA stuff has
> been set up. Also, given that IP isn't used at that point
> IPsec simply isn't either. Unblocking the random device
> in turn comes later, i. e. at least after storage devices
> have been probed.

ATB,

Mark.