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