[OpenBIOS] Faulty Qemu SPARC64 IDE emulation?

[Igor Kovalenko]

On Tue, Dec 15, 2009 at 8:30 PM, Mark Cave-Ayland
<mark.cave-ayland at 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.
>>>>
>>>>> 1) Actual memory
>>>>> 2) PCI memory space
>>>>> 3) 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.

-- 
Kind regards,
Igor V. Kovalenko