Re: [Qemu-devel] [PATCH 1/2] Move graphic-related coalesced MMIO flushes to affected device models

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-10-19 11:04, Avi Kivity wrote:
> 
> On 10/18/2011 09:50 PM, Jan Kiszka wrote:
>> On 2011-10-18 19:34, Avi Kivity wrote:
>>> On 10/18/2011 06:49 PM, Jan Kiszka wrote:
>>>> On 2011-10-18 18:40, Avi Kivity wrote:
>>>>> On 10/18/2011 04:30 PM, Avi Kivity wrote:
>>>>>> This takes a while to reproduce, let me talk to gdb for a bit.
>>>>>>
>>>>>
>>>>> a vcpu exit causes kvm_flush_coalesced_mmio_buffer() to run, which does
>>>>> a bitblt, which is cirrus_do_copy(), which goes to vga_hw_update, which
>>>>
>>>> Why does it have to do vga_hw_update? Why can't it set some flag for the
>>>> next requested screen update or so? Just thinking, haven't looked at the
>>>> code yet.
>>>
>>> Maybe it's a remnant from the days where it asked the host hardware to
>>> do the blt.
> 
>> If it's no longer needed - drop it? Already for other reasons like
>> efficiency.
> 
> I think it actually is needed - it calls qemu_console_copy() to do the
> copy.  Which incidentally means the the coalesced flush, had it worked,
> would be a bug: it would bring pending mmio writes in front of a
> currently executing bitblt.  I don't think we can regard my hack as a
> fix for that.  Maybe we need to revert the original patch.  Or make sure
> the flush only happens from the display thread.

I hope we can avoid the old scheme as it hurts when trying to make
progress /wrt scalability. Will have a look if we can avoid the
recursion in some reasonable way at device level here.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux