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

[Avi Kivity <avi@redhat.com>]

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.

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