[SLOF] [PATCH 3/4] fbuffer: Implement MRMOVE as an accelerated primitive

[Thomas Huth]

On 09/09/15 13:37, Nikunj A Dadhania wrote:
> Thomas Huth <thuth at redhat.com> writes:
> 
>> On 09/09/15 13:05, Nikunj A Dadhania wrote:
>>> Thomas Huth <thuth at redhat.com> writes:
>>>
>>>> On 09/09/15 08:45, Nikunj A Dadhania wrote:
>>>>> Thomas Huth <thuth at redhat.com> writes:
>>>>>
>>>>>> On 03/08/15 17:53, Thomas Huth wrote:
>>>>>>> On 03/08/15 12:37, Nikunj A Dadhania wrote:
>>>>>>>> Thomas Huth <thuth at redhat.com> writes:
>>>>>>>>
>>>>>>>>> The character drawing function fb8-draw-character uses "mrmove"
>>>>>>>>> (which moves main memory contents to IO memory) to copy the data
>>>>>>>>> of the character from main memory to the frame buffer. However,
>>>>>>>>> the current implementation of "mrmove"  performs quite badly on
>>>>>>>>> board-qemu since it triggers a hypercall for each memory access
>>>>>>>>> (e.g. for each 8 bytes that are transfered).
>>>>>>>>> But since the KVMPPC_H_LOGICAL_MEMOP hypercall can transfer bigger
>>>>>>>>> regions at once, we can accelerate the character drawing quite a
>>>>>>>>> bit by simply mapping the "mrmove" to the same macro that is
>>>>>>>>> already used for the "rmove". For keeping board-js2x in sync,
>>>>>>>>> this patch also transforms the "mrmove" for js2x into primitives.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Thomas Huth <thuth at redhat.com>
>>>>>>>>
>>>>>>>> I dont have a js2x handy, did you test this on js2x?
>>>>>>>
>>>>>>> No, sorry, unfortunately, I also was not able to test this on js2x yet.
>>>>>>> I still have a YDL PowerStation somewhere in a corner of my flat, but
>>>>>>> it's currently not set up ... will do that one day when I got enough
>>>>>>> spare time again, but that won't happen within the next few weeks (KVM
>>>>>>> forum's ahead!). So if there are problems, I'll fix them up as soon as I
>>>>>>> got the PowerStation running again (and I guess there might be other
>>>>>>> problems, too, since board-js2x hardly got any testing within the last
>>>>>>> months/years, I think).
>>>>>>
>>>>>> FWIW, I've recently dusted off my PowerStation and gave it a try...
>>>>>> the HEAD of the SLOF master branch is unfortunately quite broken on js2x
>>>>>> nowadays (I'll try to send some first fixes later), but I was able to
>>>>>> cherry-pick the fbuffer acceleration patches to an older level of SLOF
>>>>>> from 2012 which was still working nicely.
>>>>>
>>>>> TCG seem to be broken with this new series, git bisect pointed to:
>>>>>
>>>>> 59a135e fbuffer: Implement MRMOVE as an accelerated primitive
>>>>>
>>>>> I havent looked into detail of why its failing though.
>>>>
>>>> It seems to work fine for me here (SLOF master and QEMU master
>>>> branch). Which version of QEMU did you use? 
>>>
>>> QEMU: fc04a73 Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20150908' into staging
>>>
>>> SLOF: 811277a version: update to 20150813
>>>
>>>> Which command line parameters?
>>>
>>>         ./ppc64-softmmu/qemu-system-ppc64 -machine pseries -m 2048  -serial stdio
>>
>> I've just tried the very same versions, with the very same parameters,
>> and it is working nicely here! Very strange...
>>
>>>         VNC server running on `127.0.0.1:5900'
>>> 	SLOF **********************************************************************
>>> 	QEMU Starting
>>> 	 Build Date = Sep  9 2015 16:30:15
>>> 	 FW Version = git-811277ac91f674a9
>>> 	 Press "s" to enter Open Firmware.
>>> 	
>>> 	Cannot open file : fbuffer.fs
>>
>> Sounds like the boot_rom.bin / slof.bin maybe has not been built
>> correctly ... what do you get when you run:
>>
>> strings boot_rom.bin | grep fbuffer.fs
>>
> 
> $ strings boot_rom.bin | grep fbuffer.fs
> include fbuffer.fs
> 0fbuffer.fs

That looks ok, fbuffer.fs is available in the romfs ...

I've did some more tests, and it occurs for me, too, when I use the ATC
compiler instead of my normal cross-compiler from my distro!
But for me, 59a135e is still working fine, it just breaks with
86b2718b467f8ed (Add missing half word access case to _FASTRMOVE and
_FASTMOVE) ! ... not sure why this could cause these strange effects,
though ...

 Thomas