[Qemu-devel] Re: POLL: Why do you use kqemu?

[Avi Kivity <avi@redhat.com>]

Jan Kiszka wrote:
> 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).
>   

It's actually quite recent:

commit d03f4d2defd76f35f46f5418979f3e6d14a11183
Author: Jan Kiszka <jan.kiszka@web.de>
Date:   Wed Sep 10 21:34:44 2008 +0200

    I440fx: do change ISA mappings under KVM
   
    As long as KVM does not support remapping or protection state changes of
    guest memory, do not fiddle with the ISA mappings that QEMU see,
    confusing both the monitor and the gdbstub.
   
    Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
    Signed-off-by: Avi Kivity <avi@qumranet.com>

So we can change this to if (kvm_enabled() && 
kvm_doesnt_support_remapping_or_protection_state_changes()).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.