Re: [Qemu-devel] Re: [PATCH 1/6] Make config space accessor host bus trapable

[Benjamin Herrenschmidt]

On Tue, 2010-01-05 at 00:08 +0100, Alexander Graf wrote:
> 
> IIRC qemu's mmio functions just pass the register value the guest had
> at that moment to the mmio function.

That means that qemu HW emulation needs, for each device, to add a layer
of byteswap depending on whether the CPU is LE or BE which sucks :-)

> While that is pretty simple, it means that we behave different from
> real hardware. Real hardware has 2 components:
> 
> 1) CPU
> 2) Device
> 
> The CPU sends an MMIO request in local byte order to the device. The
> device also has a native endianness - either BE or LE.
> So what the byte swap here does is simply converting from wrong LE
> (what Linux thought the device needs) to a proper variable.

Not quite. The CPU sends an MMIO request to a PCI host bridge. For
devices (and I'm not talking about the host bridge registers themselves,
those are on the CPU bus and could be wired in any fancy way), but for
PCI devices behind that bridge, you expect things to be wired in such a
way that the BE CPU MSB is wired to the PCI LSB.

IE. If a piece of C code writes 0xaabbccdd to a PCI device 32-bit
register using a native aligned access from the CPU of the form
*(unsigned int *)addr, the device should see 0xaabbccdd with a LE CPU
and 0xddccbbaa with a BE CPU :-) Really ! This is why writel() in linux
will byteswap on BE CPUs.

Ideally, QEMU should do the same swapping for all accesses over PCI in
order to avoid to CPU conditional byteswap tricks in the device
emulation proper.

Now, regarding the host bridge own registers, as I said above, if they
are legacy IO cf8/cfc (which is the case of most CHRPs for example) they
will be LE just the same way as above. Some SoCs like FSL do try to be
smart and get them BE though. But yeah, that is all specific to a given
host bridge.

> I'm not sure what the correct solution to this is. I'm inclined to
> suggest that mmio callbacks should get called with tswap'ed values.
> But then again the code as is works in quite a lot of cases and I
> don't want to spend months getting it back to where it is just because
> of a cosmetic change.

Well, I'd say that MMIO callbacks should continue being native for
anything on the CPU bus, -but- when crossing a bridge, they may need to
get some swapping done depending on what that bridge does. For example,
I would expect a powerpc/amba bridge to do a similar swapping as above
for a powerpc/pci bridge.

Cheers,
Ben.

> Alex