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

[Benjamin Herrenschmidt]

On Sun, 2010-01-03 at 21:27 +0100, Alexander Graf wrote:

> I think if unin_pci is the only user, it'd be better to do it hacky
> inside unin_pci.c. But if there's a chance there's another user, it'd
> be better to make it generic.
> 
> Since this is the first time I ever stumbled across type 0 and type 1
> PCI config space addresses, I simply don't know if there are any. Blue
> Swirls comment indicated that there are. Ben also sounded as if it's
> rather common to not use the x86 format. On the other hand, it looks
> like nobody in qemu needed it so far - and we're implementing ARM,
> MIPS and all other sorts of platforms.
> 
> So if anyone with knowledge in PCI could shed some light here, please
> do so.

My feeling is that what you're better off doing is to have the qemu core
take an abstract struct to identify a device config space location, that
consists of separate fields for:

 - The PCI domain (which is what host bridge it hangs off since bus
numbers are not unique between domains)

 - The bus number

 - The device number (aka slot ID)

 - The function number

Now, you can then provide a "helper" that translate the standard x86
type 0 and type 1 cf8/cfc accesses into the above for most bridges to
use, and uninorth or other non-x86 that use different scheme can do
their own decoding.

The reason you want the above is to be more future proof, ie, you'll
probably want to deal with PCIe extended function numbers for example,
or implement different methods of MMCONFIG etc... and it's better to
disconnect the low level decoding of the config space access from the
internal representation in qemu.

Cheers,
Ben.