Hi,
I haven't really had a chance to review it. Initial thoughts were
- on patch 1, I'm not sure how that will impact stack usage which
is quite tight when running in 16bit mode;
Stack usage doesn't grow much I think. struct pci_dev becomes larger, but I doubt you can find those on the stack. Some local variables move from u32 to u64. But doesn't run this code in 32bit anyway?
patch 5 - seems incomplete if it doesn't handle bridges properly. I didn't fully understand patch 5, but that's likely just due to lack of time to look at it.
Yea, 64bit window detection isn't there, couldn't test that because qemu didn't support it, but mst posted a patch for that yesterday.
BTW, what's the use case for 64bit PCI today?
Hmm at the moment I've almost complete testing of another implementation of 64bit BAR support. It's implemeted in a very different way. Just need a day or so to form patches and write a description.
Oh, ok. I had the impression the effort is stalled due to complete silence for a bunch of weeks. /me looks forward to look at your patches.
Who needs this today. At the moment qemu 1.0 does not work with 64bit BARs properly.
latest master works fine.
If 64bit BAR support is implemented we will be able to go ahead with network monitoring card in qemu. So we need this feature. In addition big memory ranges (i.e. 64bit BARs) are very desirable for qemu ivshmem driver (virtual pci device for inter-vm shared memory). And I'm pretty sure there will be other use cases.
Yea, this is pretty much about moving large memory bars out of the PCI address space window below 4G. ivshmem is a obvious candidate. I have patches for QXL too.
cheers, Gerd