Re: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state

[Avi Kivity <avi@redhat.com>]

On 11/17/2009 04:12 PM, Jan Kiszka wrote:
>>
>>> The alternative would be a complex get&lock/put&unlock + a queue for
>>> async events during the lock + an option to ignore what was queued when
>>> doing a true reset. Back to square #1: we would still need the proposed
>>> high-level interface to communicate the difference between replay and
>>> drop queue.
>>>    
>>>       
>> There's no need for get+lock / put+unlock; a normal get/put with the
>>     
> You need to track when to queue and when to apply directly. Call it lock
> or call it something else.
>   

You always queue.  When starting vcpu_run() or reading state to
userspace you flush the queue.

The hardware equivalent is posting APIC messages, and the core executing
them.

>> addition that get flushes the queue suffices.  To make sure queued
>> events don't affect set you need to stop the entire VM before setting
>> state, but you need to do that anyway for non-rmw writes.
>>
>>     
> Well, sounds good, but it will be a non-trivial change in the interface
> semantics. At bare minimum, we would need a new mp_state interface. If
> we would count mp_state to our new event structure (hmm...), then we
> could confine the semantical changes to that new IOCTL pair. But how to
> deal with existing KVM kernels with their mp_state interface? It's a bit
> like the vcpu state thing: we are already down a specific road, and it's
> hard to turn around.
>   

I think we're not on the same page here.  As I see it, no interface
change is needed at all.

It's true that existing kernels don't handle this properly, which is why
I said I'm willing to treat it as a bug (and thus the -stable treatment
etc.).  I admit it's a stretch since this is not going to be trivial
(though I think less complex that you believe).

Putting mp_state into the events structure is reasonable regardless of
this issue (and doable since we haven't pushed it to 2.6.33 yet).  But I
want to understand why you think it's needed.

-- 
error compiling committee.c: too many arguments to function