Re: [PATCH 1/9] Don't separate registrations with IO_MEM_ROM set

[Jan Kiszka <jan.kiszka@siemens.com>]

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