Fabrice Bellard wrote:
> Some questions:
>
> - QEMU already maintains modified page status for VGA memory (and 
> kqemu for example fully supports that), so I don't see why KVM needs a 
> new method.

KQEMU passes the dirty bitmap directly to the kernel.  KVM does 
aggressive shadow page table caching though so maintaining the bitmap 
requires removing write protection from the shadow page table entries 
explicitly whenever you want to reset it.  This is not something you 
would want to do every time you go back and forth between 
userspace/kernelspace.

KVM also doesn't pass the phys_map to the kernel like KQEMU does.  
Instead, it divides memory into a set of slots.  slots are contiguous 
areas of RAM memory.  An IO access that does fall into a slot is treated 
as MMIO and is then sent to userspace.  We then use the phys_map in 
userspace to dispatch the MMIO operation.

There are only a handful of slots and they happen to be arranged in 
order of most frequent access (I believe) such that you can very quickly 
determine whether memory is MMIO or not.

> - Why is kvm_cpu_register_physical_memory() needed ? kqemu can work 
> without it because there is a remapping between physical memory and 
> RAM address. I suggest to add that feature in KVM or to modify 
> cpu_register_physical_memory() to hide it.

The only reason the second call exists is to simplify the backwards 
compatibility code.  I will fix it properly though because I do agree 
with you that it shouldn't be necessary.

> - If KVM implements its own CPU loop, why are there patches in 
> libqemu.a (CPU core) ?

Good question!  I looked through the code and some of it was just dead 
code from before we had our own main loop.  The rest is as follows:

In exec.c, we need to bump the size of the phys_map to support larger 
memory (since we use it to dispatch MMIO).  We also need to ensure that 
cpu_interrupt calls into KVM code.  There are also hooks for debugging 
support.  We've added more flags to cpu.h that we use when synchronizing 
KVM register state to CPUState.  We also added some additional state to 
CPUState that we need to use.

Other than that, I've removed everything else.

Regards,

Anthony Liguori

> Regards,
>
> Fabrice.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to