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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
