From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>,
David Gibson <david@gibson.dropbear.id.au>
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 [thread overview]
Message-ID: <4E9DD88D.2090004@web.de> (raw)
In-Reply-To: <4E9DB892.5060602@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2011-10-18 19:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-30 10:31 [Qemu-devel] [PATCH 1/2] Move graphic-related coalesced MMIO flushes to affected device models Jan Kiszka
2011-10-15 21:35 ` Blue Swirl
2011-10-18 14:00 ` Avi Kivity
2011-10-18 14:05 ` Jan Kiszka
2011-10-18 14:08 ` Avi Kivity
2011-10-18 14:10 ` Jan Kiszka
2011-10-18 14:30 ` Avi Kivity
2011-10-18 16:40 ` Avi Kivity
2011-10-18 16:49 ` Jan Kiszka
2011-10-18 17:34 ` Avi Kivity
2011-10-18 19:50 ` Jan Kiszka [this message]
2011-10-19 9:04 ` Avi Kivity
2011-10-19 11:18 ` Jan Kiszka
2011-10-18 18:06 ` Alon Levy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E9DD88D.2090004@web.de \
--to=jan.kiszka@web.de \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.