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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
