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. -- 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
