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
signature.asc
Description: OpenPGP digital signature
