Avi Kivity wrote: > On 11/17/2009 03:05 PM, Jan Kiszka wrote: >> >>> Problem is, the inject channels are implied (APIC messages in smp >>> guests). Documentation is good, but if we can avoid it that's better. >>> >>> Note the only way to rmw vcpu events during smp is pausing the guest, >>> because of this race. >>> >> That's what qemu does on reset and load. >> > > These aren't rmw. Not logically, but ATM technically. > >> 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. > 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. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
