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

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

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

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