Re: [Qemu-devel] [PATCH v3 5/6] vga: Use linear mapping + dirty logging in chain 4 memory access mode

[Benjamin Herrenschmidt]

> 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.