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

[Nikunj A Dadhania]

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
        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
	Populating /vdevice methods
	Cannot open file : vio-hvterm.fs
	Cannot open file : rtas-nvram.fs
	Cannot open file : vio-veth.fs
	Cannot open file : vio-vscsi.fs
	Cannot open file : pci-phb.fs
	No NVRAM common partition, re-initializing...
	
	E3401: Aborting boot,  No valid NVRAM.
	 No valid NVRAM.
	2 > qemu: terminating on signal 2

After I move back to above mentioned commit, starts working fine.

	./ppc64-softmmu/qemu-system-ppc64 -machine pseries -m 2048  -serial stdio
	VNC server running on `127.0.0.1:5900'
	
	
	SLOF **********************************************************************
	QEMU Starting
	 Build Date = Sep  9 2015 16:34:27
	 FW Version = git-d0732f556d44e3b2
	 Press "s" to enter Open Firmware.
	
	Populating /vdevice methods
	Populating /vdevice/vty at 71000000
	Populating /vdevice/nvram at 71000001
	Populating /vdevice/l-lan at 71000002
	Populating /vdevice/v-scsi at 71000003
	       SCSI: Looking for devices
	          8200000000000000 CD-ROM   : "QEMU     QEMU CD-ROM      2.4."


Regards
Nikunj