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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]

Avi Kivity wrote:
> 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.

Well, the current API comes with millions of ways to shoot yourself into
the foot. I don't think we can avoid them all.

> 
>>> 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...)
> 

We may start documenting such dependency in kvm/api.txt. On the other
hand, if you have a get/set interface vs. an inject channel, I think
it's obvious that one can overwrite the other.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]