Jan Kiszka wrote: > Avi Kivity wrote: >> On 11/17/2009 04:12 PM, Jan Kiszka wrote: >>>>> The alternative would be a complex get&lock/put&unlock + a queue for >>>>> async events during the lock + an option to ignore what was queued when >>>>> doing a true reset. Back to square #1: we would still need the proposed >>>>> high-level interface to communicate the difference between replay and >>>>> drop queue. >>>>> >>>>> >>>> There's no need for get+lock / put+unlock; a normal get/put with the >>>> >>> You need to track when to queue and when to apply directly. Call it lock >>> or call it something else. >>> >> You always queue. When starting vcpu_run() or reading state to >> userspace you flush the queue. > > Now I finally got your idea. > >> The hardware equivalent is posting APIC messages, and the core executing >> them. >> >>>> addition that get flushes the queue suffices. To make sure queued >>>> events don't affect set you need to stop the entire VM before setting >>>> state, but you need to do that anyway for non-rmw writes. >>>> >>>> >>> Well, sounds good, but it will be a non-trivial change in the interface >>> semantics. At bare minimum, we would need a new mp_state interface. If >>> we would count mp_state to our new event structure (hmm...), then we >>> could confine the semantical changes to that new IOCTL pair. But how to >>> deal with existing KVM kernels with their mp_state interface? It's a bit >>> like the vcpu state thing: we are already down a specific road, and it's >>> hard to turn around. >>> >> I think we're not on the same page here. As I see it, no interface >> change is needed at all. >> >> It's true that existing kernels don't handle this properly, which is why >> I said I'm willing to treat it as a bug (and thus the -stable treatment >> etc.). I admit it's a stretch since this is not going to be trivial >> (though I think less complex that you believe). >> >> Putting mp_state into the events structure is reasonable regardless of >> this issue (and doable since we haven't pushed it to 2.6.33 yet). But I >> want to understand why you think it's needed. >> > > That wouldn't be required anymore with the "always queue" policy. Hmm, unless we need mp_state manipulation analogously to KVM_NMI vs. KVM_SET_VCPU_STATE: The former will queue, the latter write, but may be overwritten by anything queued. If you just queue KVM_SET_MP_STATE, you still have a conflict between concurrent manipulations from user space, something we want to resolve automagically. > > But what would you queue at all? Only mp_state, nmi_pending and > sipi_vector? Or also all the relevant PIC and LAPIC states that might be > changed asynchronously? > Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
