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

Reply via email to