Igor Kovalenko wrote:
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.
Right, I think I understand now. So the obvious question to ask now is how is PCI configuration space mapped on Sparc64? I can see that on x86 it's mapped to an I/O port at 0xCF8 but I can't seem to find how this is implemented on Sparc64. Anyone have any idea?
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.
Well the Milax ISO does, because it tries to set an alarm to draw the twirly baton on screen. So if we can find a way of setting an alarm() for x ms then we can make use of it.
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.
Okay; are you working on this at the moment? I've tried searching for sparc64 pci memory and qemu but don't seem to have found any hits. Can you point me towards the relevant patches?
ATB,
Mark.