Avi Kivity wrote:
> Jan Kiszka wrote:
>>>>
>>>> Check e.g the diff of hw/vga.c against upstream: All the magic dances
>>>>  there are required as qemu-kvm tracking
>>>> cpu_register_physical_memory and
>>>>  kvm_log_start cannot cope with all the patterns normal qemu code comes
>>>>  up with. Upstream slot management now provides the same features
>>>>  (including migration) like qemu-kvm, it just does not deal with
>>>> legacy,
>>>>  thus it does not have to patch qemu code (rather, we were able to
>>>> remove
>>>>  some already merged hooks - vga_dirty_log_stop).
>>>>       
>>> Still not very restrictive, all this could be encapsulated with for
>>> example macro COMPAT_NO_DMRW which could be removed when we don't care
>>> anymore. Next?
>>>     
>>
>> Really, it's not worth the maintenance pain: Every new device emulation
>> code that wants to be KVM-legacy-compatible would need to be written
>> like that. And unless you are familiar with the slot management
>> internals, the "correct" pattern will not be obvious.
>>   
> 
> Only devices which direct map memory.  Currently VGA and cirrus.
> 

--- /data/qemu/hw/piix_pci.c    2009-06-07 09:42:27.000000000 +0200
+++ hw/piix_pci.c       2009-06-02 13:00:09.000000000 +0200
...
@@ -91,6 +93,10 @@ static void i440fx_update_memory_mapping
     int i, r;
     uint32_t smram, addr;

+    if (kvm_enabled()) {
+        /* FIXME: Support remappings and protection changes. */
+        return;
+    }
     update_pam(d, 0xf0000, 0x100000, (d->config[0x59] >> 4) & 3);
     for(i = 0; i < 12; i++) {
         r = (d->config[(i >> 1) + 0x5a] >> ((i & 1) * 4)) & 3;

IIRC, this is at least partially due to the restricted slot management
in qemu-kvm - or is this obsolete now?

Jan