On 23/12/2011, at 11:58 PM, Alexander Graf wrote: > > On 13.12.2011, at 07:21, Matt Evans wrote: > >> Different architectures will deal with MMIO exits differently. For example, >> KVM_EXIT_IO is x86-specific, and I/O cycles are often synthesised by steering >> into windows in PCI bridges on other architectures. >> >> This patch calls arch-specific kvm_cpu__emulate_io() and kvm_cpu__emulate_mmio() >> from the main runloop's IO and MMIO exit handlers. For x86, these directly >> call kvm__emulate_io() and kvm__emulate_mmio() but other architectures will >> perform some address munging before passing on the call. > > Why do you need address munging? PIO is simply not there and MMIO always goes to the physical address the CPU sees, so I don't see what you want to munge. The way the memory bus is attached to the CPU should certainly not be modeled differently for PPC and x86. PIO not there? PIO is used heavily in kvmtool. So, I made a window in a similar way to how a real PHB has PIO-window-in-MMIO. PCI BARs are currently 32-bit. I don't want to limit the guest RAM to <4G nor puncture holes in it just to make it look like x86... PCI bus addresses == CPU addresses is a bit of an x86ism. So, I just used another PHB window to offset 32bit PCI MMIO up somewhere else. We can then use all 4G of PCI MMIO space without putting that at addr 0 and RAM starting >4G. (And then, exception vectors where?) The PCI/BARs/MMIO code could really support 64bit addresses though that's a bit of an orthogonal bit of work. Why should PPC have an MMIO hole in the middle of RAM? Cheers! Matt -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
