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

Thomas Huth thuth at redhat.com
Wed Sep 9 17:17:28 AEST 2015


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? Which command line parameters?

 Thomas



More information about the SLOF mailing list