qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH 1/2] Move graphic-related coalesced MMIO flushes to affected device models
Date: Tue, 18 Oct 2011 21:50:37 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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.

> 
>> Do you think that only cirrus is affected by this pattern?
> 
> It's also possible for hotunplug:
> 
> - hotunplug
> - unregister coalesced regions
> - flush mmios
> - call back into same device

Which device triggers hotunplug via a coalesced mmio region?

Anyway, if we want to avoid other surprises like that, better make
kvm_flush_coalesced_mmio_buffer reentrance-safe. If we think that this
remains an odd scenario, issue a warning to the console that some device
may require fixing.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]