On Tue, Jan 05, 2010 at 08:25:30AM +1100, Benjamin Herrenschmidt wrote: > On Mon, 2010-01-04 at 23:12 +0200, Michael S. Tsirkin wrote: > > Well, the main issue if I understand correcttly is that basically the > > same hardware bridge can be connected to host in different ways. Yes, we > > can say "if it's connected differently it's a different device" but this > > is slightly ugly, device should not have to know how it's connected. It > > would be cleaner to have a "connector" device in the middle that swaps > > bytes. Even though yes, what you describe would be less ugly than using > > proprocessor as we do now. > > Well, the thing is... PCI is always little endian. > I'm not 100% familiar > on how emulation of devices works in qemu, but it's possible that the > problem here is simply not how a standard PCI host bridge is connected > to the processor changing but rather whether it's connected to an x86 > host or a ppc host should make the byte order appear different. IE. a > PPC operating system will byteswap accesses. If qemu just passes on > accesses -as-is- instead of doing natural byteswapping then indeed you > will need that added swap there too. >
Yes, but I think how you program your host to pci bridge is platform specific, the standard (mostly) applies to what happens below the bridge. There's no real standard for how PCI host bridge is connected to processor AFAIK, it's by luck we can share code there at all. > I still think though that this should be buried in the accessors for the > host bridge themselves, eventually controlled by a flag set when > instanciating the host bridge in case it can indeed be wired in > different ways. > > Cheers, > Ben. > buried sounds scary, but generally yes, a flag in host bridge code is the idea.