Re: [Qemu-devel] Re: [PATCH 3/3] Add KVM support to QEMU

[Anthony Liguori <anthony@codemonkey.ws>]

Glauber Costa wrote:
> On Tue, Oct 28, 2008 at 7:51 PM, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>>
>> This is part of the reason for this exercise.  I'd rather introduce KVM
>> support first and then look at abstracting things, than vice versa.  A
>> number of the hooks in the current QEMUAccel tree are there for the wrong
>> reason (to support the out-of-tree IO thread, for instance).
>>
>> If you just introduce something with various hooks and say, these are hooks
>> we'll need, it's not possible to really evaluate whether the hooks are
>> needed because nothing in the tree makes use of them.
>>     
>
> We talked extensively on monday about it, and I'm in agreement with it.
>   

Something I was thinking about this morning, and I think the first place 
where we'll definitely need a hook, is how to deal with 
kvm_load_registers().  I think there's overlap between KVM and the IO 
thread here.

There are two reasons (I can think of) that most of the device model 
code can't run in conjunction with TCG.  The first is that TCG may 
modify CPUState in a non-atomic way.  The device model may need to 
access CPUState although there are very few places that it does.  The 
other reason is accessing guest memory.  TCG does not preserve atomicity 
when a guest accesses device memory.  There are probably only a few 
places in the device model (like virtio) that depend on atomicity.

If we implemented an API that implemented a lock/unlock for CPUState and 
for portions of memory, then I think this could be used both as a hook 
for kvm_load_registers and as a way to introduce an IO thread with TCG.

The CPUState lock/unlock is pretty straight forward.  For the memory 
implementation to be efficient, I think you would have to acquire the 
lock when TCG brings a physical address into the TLB (preferrably, at a 
page granularity), or whenever someone tries to access memory (via 
cpu_physical_memory_rw).  I think in the vast majority of the cases, 
there wouldn't be any contention and both could TCG could run along side 
the IO thread.

Another place "hook" is updating a slot's dirty bitmap.  Right now, with 
my patchset we don't have live migration or the VGA RAM optimization.  
There's nothing about the VGA RAM optimization that wouldn't work for 
QEMU.  I'm not sure that it really is an optimization in the context of 
TCG, but I certainly don't think it's any worse.  The only thing you 
really need is to query the KVM dirty bitmap when it comes time to 
enable start over querying the VGA dirty bits.

The same is needed for live migration, so I think what we really need is 
to change the memory dirty bit tracking API to have a concept of refresh 
that we can use to hook for KVM.

FWIW, I included a TODO in my patch if people are interesting in 
tackling any of these things.

Regards,

Anthony Liguori

Regards,

Anthony Liguori

>> Regards,
>>
>> Anthony Liguori
>>
>>     
>>> surprised,
>>>  Gerd
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>       
>>
>>
>>     
>
>
>
>