Re: [RFC][PATCH] qemu-kvm: Introduce writeback scope for cpu_synchronize_state

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]