From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SioGf-0000VW-NA for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:58:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SioGd-0007H2-UG for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:58:25 -0400 Received: from mout.web.de ([212.227.15.4]:52542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SioGd-0007Gv-KW for qemu-devel@nongnu.org; Sun, 24 Jun 2012 10:58:23 -0400 Message-ID: <4FE72B0C.5060908@web.de> Date: Sun, 24 Jun 2012 16:58:20 +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> <4FE72980.5030807@web.de> <4FE72AA5.5070203@redhat.com> In-Reply-To: <4FE72AA5.5070203@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig54C25FECEDF3981837E4E179" 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) --------------enig54C25FECEDF3981837E4E179 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-06-24 16:56, Avi Kivity wrote: > On 06/24/2012 05:51 PM, Jan Kiszka wrote: >> 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= to >>>> the control ports). I'm providing memory_region_set_flush_coalesced = that >>>> 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 y= et. >>> >>> Framebuffer access will bypass the MemoryRegionOps callbacks, did you= >>> intend to hook those? >> >> Are there really cases where the framebuffer is accessible both via MM= IO >> 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 exit= s. >> Or what do you mean? >=20 > I meant accesses by the display code to put the framebuffer in front of= > the user's eyes. Those just access the memory directly. We could wrap= > them with memory_region_get/put_ram_ptr() (as Xen requires anyway) and > have those issue the flush. That's a non issue, we already have to flush on display updates. See e.g. vga_update_display. Jan --------------enig54C25FECEDF3981837E4E179 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/nKwwACgkQitSsb3rl5xRd5wCffZI7mb9hX+Od2kYmzC8GYhjc z1EAn2pHQuUdv1g0Qg3IesOwSRmRJ8bR =+s0b -----END PGP SIGNATURE----- --------------enig54C25FECEDF3981837E4E179--