From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 1/9] Don't separate registrations with IO_MEM_ROM set Date: Sat, 13 Sep 2008 08:26:06 +0200 Message-ID: <48CB5CFE.2030907@web.de> References: <1221232250-9653-1-git-send-email-glommer@redhat.com> <1221232250-9653-2-git-send-email-glommer@redhat.com> <48CA8F1C.1040104@siemens.com> <20080912160432.GA3734@poweredge.glommer> <48CA983D.6060101@siemens.com> <20080912184737.GB3734@poweredge.glommer> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE52761B93A7D7140EDE4BD6D" Cc: kvm@vger.kernel.org, jes@sgi.com, avi@qumranet.com, aliguori@us.ibm.com To: Glauber Costa Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:33200 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752391AbYIMG0V (ORCPT ); Sat, 13 Sep 2008 02:26:21 -0400 In-Reply-To: <20080912184737.GB3734@poweredge.glommer> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE52761B93A7D7140EDE4BD6D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Glauber Costa wrote: > On Fri, Sep 12, 2008 at 06:26:37PM +0200, Jan Kiszka wrote: >> Glauber Costa wrote: >>> On Fri, Sep 12, 2008 at 05:47:40PM +0200, Jan Kiszka wrote: >>>> Glauber Costa wrote: >>>>> Actually, all registrations are the same. If IO_MEM_ROM is set, we = only >>>>> need to take care of not passing its value as the phys_offset. >>>> As you are turning things upside down already: :-> >>>> >>>> Any idea how to deal with that "real-only" property of IO_MEM_ROM? A= nd >>>> how to handle memory remappings during runtime (like >>>> i440fx_update_memory_mappings does)? >>>> >>>> I like the hook-approach for kvm_cpu_register_physical_memory a lot.= But >>>> note that - at least so far - cpu_register_physical_memory is someti= mes >>>> misused to change the protection or the origin of some memory region= =2E >>>> That should be taken into account. Or the qemu interface should be >>>> refactored first so that kvm (or qemuaccel) can cleanly hook into >>>> dedicated remapping/protection changing services. >>> Right now, KVM does not seem to bother. >>> The registering of memory does not account for any kind of protection= , and the >>> only flag we have is regarding logging being enabled or disabled (for= that one, >>> I do see the problem you describe, but haven't dig deeply yet). >>> >>> Calling of kvm_cpu_register_physical_what_a_big_name_memory() does no= t exclude >>> the calling of qemu's version. So for what qemu itself is concerned, = the protection >>> changes still happen: only kvm takes no action about it. >> Yes, lacking protection may not harm that much, more problematic can b= e >> the inconsistencies memory remappings leave behind. > Which inconsistencies? Since all memory as viewed as the same by KVM, I= fail to see > how they can become inconsistent. I'm currently not aware of a practical use case where this bites, but if the guest maps some memory from A to B, it may expect to find the content of A under B as well. That is not the case so far as B remains B from KVM's POV. At the same time, all QEMU memory access functions see B as A (that caused trouble for debugging and memory sniffing monitor services). IMHO, this inconsistency is waiting to cause troubles in the future again and should be resolved cleanly when hooking into QEMU's memory management, even if we lived without it until now. Jan --------------enigE52761B93A7D7140EDE4BD6D 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkjLXQoACgkQniDOoMHTA+kcigCeMjTY73fT9R5T9XTvSn2ffNy4 iVwAn2xt+JmDBrlnLlXU9ldMpE0dz3SL =qWUt -----END PGP SIGNATURE----- --------------enigE52761B93A7D7140EDE4BD6D--