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: Mon, 15 Sep 2008 10:15:18 -0300 Message-ID: <20080915131518.GB6066@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> <20080912184737.GB3734@poweredge.glommer> <48CB5CFE.2030907@web.de> <20080915124449.GA5967@poweredge.glommer> <48CE5E31.90400@web.de> 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]:36041 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753396AbYIONRh (ORCPT ); Mon, 15 Sep 2008 09:17:37 -0400 Content-Disposition: inline In-Reply-To: <48CE5E31.90400@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Sep 15, 2008 at 03:08:01PM +0200, Jan Kiszka wrote: > Glauber Costa wrote: > > On Sat, Sep 13, 2008 at 08:26:06AM +0200, Jan Kiszka wrote: > >> 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? 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. > >> 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). > > It looks like KVM aliasing support, that (up to now), seemed completely orthogonal. > > I'm looking at ways to integrate aliasing now, so if you can provide me with some use > > cases of what you described above, (that seem to have happened in your debugging patches), > > it would surely help. > > The use case that currently exists is independent of my series: > rombios32.c remaps the BIOS code at 0x0f0000..0x100000 to RAM and plays > with its access permissions (bios_shadow_init, bios_lock_shadow_ram) via > the i440fx chipset (qemu/hw/piix_pci.c: i440fx_update_memory_mappings). > Due to my workaround [1] the emulation ignores this request for now. > > Before that kvm continued to use the BIOS region after the remapping > while qemu started to look at the RAM. You were able to see this e.g. > via the monitor command 'xp /8xb 0xffff0'. This service and also the > gdbstub (that's how I found it) look at the memory via > cpu_physical_memory_rw, ie. with the help of qemu, while kvm-hosted code > uses kvm's mappings, of course. Awesome Will take a look at it today.