From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH] kvm: First step to push iothread lock out of inner run loop Date: Sun, 24 Jun 2012 16:51:44 +0200 Message-ID: <4FE72980.5030807@web.de> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01F837FA38CF3337BA0C1EFF" Cc: liu ping fan , Marcelo Tosatti , qemu-devel , Liu Ping Fan , Alexander Graf , Anthony Liguori , kvm To: Avi Kivity Return-path: Received: from mout.web.de ([212.227.15.4]:50597 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751087Ab2FXOvr (ORCPT ); Sun, 24 Jun 2012 10:51:47 -0400 In-Reply-To: <4FE72838.9070301@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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--