Avi Kivity wrote:
> Jan Kiszka wrote:
>> 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?
>>   
> 
> This is from the first days of qemu-kvm, some of this is due to Intel
> real mode issues (can't start at 0xffff ffff ffff fff0), and some I
> never got around to.  It's possible that it requires proper slot
> destruction.  Even if that's the case, we cam simply return here, as the
> code shows.

But we can also get past this point as upstream demonstrates (minus
protection changes).

Jan