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