Anthony Liguori wrote: > It's a statement of correctness really. Devices should never deal with > target_phys_addr_t's.
Shouldn't they? On real hardware, 64-bit PCI devices switch to being 32-bit PCI when plugged into a 32-bit motherboard slot. > The question is, should a pci_addr_t or a sysbus_addr_t be 64 bit or > should it be 32-bit on 32-bit platforms. Depends what you want to emulate. It's not an accurate emulation if all the old PCI devices provide 64-bit BARs; that could conceivably bite some old OS, which expects NE2000-PCI to be a 32-bit device, for example. And it's not a repeatable emulation if switching beteen 32-bit and 64-bit hosts means the guest sees a change in the PCI devices. It should be possible to change hosts with qemu willy nilly with zero change seen be the guest. So perhaps the width of pci_addr_t should be a per-device property, not a host property? > Honestly, I am extremely sceptical that there would be any > measurable performance difference. You may be right, but surely the way to find out is to have a way to build either, and then compare them. Not have it dictated by the build system. 64-bit ops on 32-bit hosts, especially x86 due to register pressure, are noticably more expensive than 32-bit ops. The question is whether they are sparse enough among all the other logic that it doesn't matter. With a bit of make cleverness it should be quite easy to support a mix of build-once files and build-few-times files according to the minimal compile time variations those files depend on - and express those dependencies is a simple, one-liner way. GNU Make is good for that sort of thing. - Jamie
