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

[Avi Kivity <avi@redhat.com>]

On 11/17/2009 10:14 AM, Jan Kiszka wrote:
>
>
>> state that is updated outside the vcpu thread.  These are particularly
>> bad since we can't exclude them from updates without excluding other
>> state as well.
>>      
> We easily can, using the very same mechanism: No need to overwrite any
> of the kvm_vcpu_events during runtime, only on reset/vmload).
>    

That's because qemu has no need for this.  But kvm is more than just 
serving qemu, we try to be more general.  That said, I can't really see 
anyone wanting to arbitrarily inject an exception.

>> The whole issue is tricky.  I'm inclined to pretend we never meant any
>> vcpu state (outside lapic) to be asynchronous and declare the whole
>> thing a bug.  We could fix it by modeling external changes to state
>> (INIT, SIPI, NMI) as messages queued to the vcpu, to be processed in the
>> vcpu thread.  The queue would be drained before running the vcpu or
>> before reading state from userspace, so the message queue contents can
>> never be observed and never lost.
>>
>> Of course, we can't really implement this as a queue (SIGSTOP vcpu
>> thread ->  overflow), but a word is sufficient.  INIT writes the word,
>> everything else uses compare-and-swap or set_bit to raise events (e.g.
>> SIPI = do { oldq = vcpu->queue; newq = (oldq&  ~SIPI_MASK) | sipi_vector
>> | RUNNING; } while (!cas(&vcpu->queue, oldq, newq)))
>>
>>      
> I do not yet see why we need this complication, why the proposed model
> isn't enough.
>    

The current interface is subtly dangerous, you can't run set(get()) as 
you would expect.

(well you can't with the lapic or the tsc msr either...)

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