On 12/16/11 05:41, Alexey Korolev wrote: >>> I wonder if there any particular reason to separate prefetchable a >>> non-prefetchable memory regions in pciinit? Extra two more regions would >>> make code more complex. >> Oh yes, there is. Which reminds me that the whole thing isn't that easy >> unfortunaly ... >> >> The reason are pci bridges. They have two memory regions, one for >> prefetchable and one for non-prefetchable memory. All devices behind a >> pci bridge must have the bars within the bridges memory regions, thats >> why they are grouped together. >> >> This also implies that a 32bit and a 64bit bar (of the same type) behind >> a pci bridge must be mapped next to each other, so moving up 64bit bars >> unconditionally isn't going to fly. Devices behind bridges need some >> extra care, only when all bars are 64bit capable they can actually be >> mapped above 4G. > The qemu actually does not simulate PCI bridges at all. So good question > shall we bother about this?
Yes. There is work in progress to add pci-express and a more modern chipset emulation to qemu. I think for now it is fine if we simply map everything behind a bridge below 4G and hash out the details (i.e. whenever we can move the bridge memory window above 4G or not) later. > I did some preliminary tests: 64bit BARs > are working quite well for linux 2.6.18 - 3.0 and windows 2008. Nice. > Also I've found important detail that according to PCI architecture > specification, the bridges can describe 64bit ranges for prefetchable > type of memory only. So it's very unlikely that devices exporting 64bit > non-prefetchable BARs. I guess we just need to add one extra type. Agree. > Even if there are two separate prefetchable memory regions (32 bit and > 64bit), it won't be a problem as there is no bridge on the 440FX inside > the virtual machine. Yes, devices attached to the root bus don't have to care about bridge windows. cheers, Gerd
