On Tue, Dec 15, 2009 at 8:30 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Igor Kovalenko wrote:
Right, that's the issue we have at the moment; both qemu and openbios are to be changed.
- Actual memory
- PCI memory space
- PCI IO space
They are each independent address spaces. Zero in any one of them is independent from zero in all the others.
Well, sparc64 is a bit unique.
From what I have seen almost any other openbios platform is either 32bit or has no pci devices, also every other platform has pci configuration mechanism 1 in place.
- sparc64 has no configuration mechanism 1 (which has basically a single
port to implement configuration protocol) but directly maps configuration space. So for sparc64 pci is also quite different from the rest, and a few clients know about that mapped configuration space.
- PCI support is there and useful, but a few places has bar address
mapping hardcoded;
- getting ucells right on 64bit sparc was *real* fun :) It turns out that
linux kernel started to rely more on prom tree data so that required ofmem supporting allocations and range properties; no other openbios platform seem to require implementing ofmem to such extent
Right, so is what you're saying is that at a minimum we'd need to implement 2) with a PCI configuration mechanism in place for this to stand any chance of working? Would the configuration mechanism simply be a set of MMIO addresses?
Bare minimum is to move legacy device registers, pci control registers and pci memory space out of physical ram space. Obvious workaround is to claim out patches of ram space so those cannot be mapped by client, downside is that looking at memory issues is non-trivial with non-uniform mapping. Also physical memory would be at waste.
Second required part is tick timer support. In my local experiments this is only directly visible in linux kernel runs. Others (including helenos and milax) do not really get to using timer yet.
I've never looked at PCI devices in much detail before, however if there is any C coding I can do to help out, please let me know.
Welcome! But to my mind we need to get qemu part right first, in that we need to remap pci address spaces out of low addresses. If you could invent another workaround it would be a good start, we need get these 3 address spaces right one way or another.
Does that mean you've already started working on the Qemu side of this? If so, again let me know if I can help at all. Incidentally if you already have ideas for this, it's probably worth floating any proposals to the qemu-devel list first before doing any coding, just to make sure that they would be happy to accept patches implementing this new functionality.
It was already proposed to allow sparc64 to shift pci memory space by a constant offset (say 0x1fe00000000 as it is on real hardware) so qemu could map device bars into 64bit address space where those belong. Originally that change was quite huge since all pci devices were touched, to support bars mapped above 32bit space. Most of those changes are in qemu code already, so it may be worth doing another patch submission round.