All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
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: Wed, 19 Oct 2011 11:04:20 +0200	[thread overview]
Message-ID: <4E9E9294.8020908@redhat.com> (raw)
In-Reply-To: <4E9DD88D.2090004@web.de>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

>
>
> >
> >> 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?

Er, none.

> 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.
>

- -- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOnpKTAAoJEI7yEDeUysxlWjkP/3KubuwPQXYV6Fh8EjLXYSNG
ClxiqOvGIy8lHqdpZON2iuv5RiFcReeUZlFVXhRcjJ28tSb2ZYh8qxb/mRE82U8p
1sPS+kEH8k+lvzF38LjUc9XwWdjLLPiXrm3xWX/3uGvotbMKezS+2WGqc5hN7l8U
bc1pKLXQJ8YTIPq1seMv+ncVUcS3yaYSHMagkwjnQ4MDo8mhyPadfkkyv2BBLMM6
lTI9w5QvZ6JoWAHy/7KEEqyzs06ssfXOc/rSQLcHXn0S4CyVsmuGu3B/grHNqKIp
8OE0gZgDcA00E+YvXdOUGPMJ+XHEn/BCH2vrRf1TAlWq+zRPwXTrY3SZbauuBV/+
x0991xE2fMPF3o03OybwqnbQFrqtPhhYKXu9Dt/mBeITOkcvEVJjnO6ooCeqirmA
GrA26ls0I5+oZxfC3qmwJnO/WmGhZCEBS4YAav/4o+t1Ae2bjj/A23kcW/W+RUW7
5I2WTcbhe/+zqtalJg68F//8PSWmCnF4njxdHR3sRyhkzuDS1Ue99bGi0eugkYrM
71q0r17SnOK8Mo7tPn4FP0eeSEpTnxzS5vScf60IV0p3wIzgTPqeDgs+73v6AzO1
Yu3efGmh2q+UFVgUOhkDiFkPoQeaUSnpNEhpwBDGctGjqMyKpildkZB6DFY/+hle
9+Id+qSPeQNzoO62bfGi
=n5PD
-----END PGP SIGNATURE-----

  reply	other threads:[~2011-10-19  9:04 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
2011-10-19  9:04                   ` Avi Kivity [this message]
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=4E9E9294.8020908@redhat.com \
    --to=avi@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=jan.kiszka@web.de \
    --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.