From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH 1/9] Don't separate registrations with IO_MEM_ROM set Date: Fri, 12 Sep 2008 15:47:37 -0300 Message-ID: <20080912184737.GB3734@poweredge.glommer> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, jes@sgi.com, avi@qumranet.com, aliguori@us.ibm.com To: Jan Kiszka Return-path: Received: from mx2.redhat.com ([66.187.237.31]:33334 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753448AbYILSwX (ORCPT ); Fri, 12 Sep 2008 14:52:23 -0400 Content-Disposition: inline In-Reply-To: <48CA983D.6060101@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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? And > >> 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 sometimes > >> misused to change the protection or the origin of some memory region. > >> 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 not 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 be > 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. > > Jan > > -- > Siemens AG, Corporate Technology, CT SE 2 > Corporate Competence Center Embedded Linux