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. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux -- 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
