> Sure :). So the problem is that when emulating the G3 Beige machine in > QEMU (default ppc32 target) we also add a PCI VGA adapter. Apparently, > on x86 that PCI VGA adapter can map the special VGA regions to > somewhere, namely 0xa0000. With the memory api overhaul, this also > slipped into the PPC world where mapping 0xa0000 with VGA adapters is > a pretty bad idea, as it's occupied by RAM. > > Now the discussion was on which level that mapping would happen and > which devices go through which buses which then would filter certain > ranges from being mapped. Basically, which way does a memory request > from the CPU go on a G3 Beige machine until it arrives the VGA > adapter? > > I hope that concludes the actual question. Avi, if I explained this > wrong, please correct me.
Ok so there's several things here. First, the mapping from CPU addresses to PCI addresses. This depends on the host bridge chip. The MPC106, used in the Beige G3, itself supports different type of mappings. >From memory, the way it's configured in a G3 is to have a 1:1 mapping of 80000000 CPU to 80000000 PCI. That means that with this basic mapping, you cannot generate memory accesses to low PCI addresses such as 0xa0000. I don't remember (but it's possible) if it has another region which maps some other (high address) part of the address space down to 0 PCI. Typically that would be a smaller region which specifically allow access to the "ISA hole" that way. There is code in pci_process_bridge_OF_ranges() that will detect such an ISA hole, and while it cannot add it to the normal resource management, it is remembered, so we -could- use it from the VGA code if we wanted to (we don't today). The problem is that most bridges used on Macs, typically the Apple ones simply don't provide such a hole. In fact, most bridges used by IBM aren't configured for that either. Now back to your VGA adapter. The legacy VGA stuff does something called "hard decoding", which means it decodes those legacy addresses, usually without a BAR, but using a fixed address decoding. This is old ISA crap emulated on top of PCI, exist only thanks to a "hack" in the PCI spec, in order to be backward compatible with DOS and shit like that. Ideally, you should provide a BAR to allow remapping that stuff elsewhere and a setting to enable/disable the hard-decoding. That way, on power, the firmware could just whack that setting and turn your VGA device into something that behaves properly like a normal PCI device. Macs or pSeries never really used the legacy crap. We always had drivers that configured the cards into "native" mode, which means no hard decoding (some old cards still hard decoded some IO ports but that went away on anything modern), and just using proper MMIO register and linear framebuffer from the driver. That does mean we never used text mode though. It would be possible to still allow text mode by having a BAR in the emulated card that can be used to move the VGA legacy crap around tho if we really wanted to. BTW. I haven't looked at the code, but I've been told that for some of the splice stuff or other higher level additions, you have implemented special IO ports in the card. This is totally ass backward. IOs are old bad junk and must die. MMIO is semi-acceptable, commands in virtio would be better (and perform better), but not IO ports, please ..... Cheers, Ben.
