From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SioAJ-0007EI-MM for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:51:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SioAH-00066b-OW for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:51:51 -0400 Received: from mout.web.de ([212.227.15.4]:60346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SioAH-00066V-Eh for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:51:49 -0400 Message-ID: <4FE72980.5030807@web.de> Date: Sun, 24 Jun 2012 16:51:44 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4FE4F56D.1020201@web.de> <4FE4F7F5.7030400@web.de> <20120623002259.GA13440@amt.cnet> <20120623090646.GA21908@amt.cnet> <4FE5AC75.1020504@web.de> <4FE71F71.7030908@web.de> <4FE7259F.4030100@redhat.com> <4FE726CF.5090906@web.de> <4FE72838.9070301@redhat.com> In-Reply-To: <4FE72838.9070301@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01F837FA38CF3337BA0C1EFF" Subject: Re: [Qemu-devel] [PATCH] kvm: First step to push iothread lock out of inner run loop List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Liu Ping Fan , kvm , qemu-devel , Marcelo Tosatti , Alexander Graf , liu ping fan , Anthony Liguori This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01F837FA38CF3337BA0C1EFF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-24 16:46, Avi Kivity wrote: > On 06/24/2012 05:40 PM, Jan Kiszka wrote: >> On 2012-06-24 16:35, Avi Kivity wrote: >>> On 06/24/2012 05:08 PM, Jan Kiszka wrote: >>>> As a first step, I will post a series later that gets rid of >>>> kvm_flush_coalesced_mmio_buffer in the common vmexit path. >>> >>> If you defer this, I can think of two places that need to flush: >>> - anything that accesses those memory areas (such as DMA to the >>> framebuffer, or updating the display) >> >> - anything that accesses related areas (in case of VGA: PIO accesses t= o >> the control ports). I'm providing memory_region_set_flush_coalesced th= at >> allows to flush on non-coalesced region accesses as well. Some PIO >> accesses unfortunately still need open-coded >> qemu_flush_coalesced_mmio_buffer as they do not use memory regions yet= =2E >=20 > Framebuffer access will bypass the MemoryRegionOps callbacks, did you > intend to hook those? Are there really cases where the framebuffer is accessible both via MMIO and RAM-like mappings at the same time? If so, the current flushing on vmexit would help either as the direct mappings would not trigger exits. Or what do you mean? >=20 > I'm not sure the problem is general enough to merit a check in our > generic mmio dispatch code (granted, now it has a check in the vcpu exi= t > path which is much worse). The current situation is indeed much worse. Jan --------------enig01F837FA38CF3337BA0C1EFF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/nKYAACgkQitSsb3rl5xRYxACggbvXvIZEOqkTsWtFN/DJiTSH TRsAoNoMdap+Ox5BanVV341G3q61GicL =PsXO -----END PGP SIGNATURE----- --------------enig01F837FA38CF3337BA0C1EFF--