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

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

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

Avi Kivity wrote:
> On 11/17/2009 11:16 AM, Jan Kiszka wrote:
>>
>>> That's because qemu has no need for this.  But kvm is more than just
>>> serving qemu, we try to be more general.  That said, I can't really see
>>> anyone wanting to arbitrarily inject an exception.
>>>      
>> Well, the current API comes with millions of ways to shoot yourself into
>> the foot. I don't think we can avoid them all.
>>    
> 
> It would be nice to make the API saner.  Do you know of more holes?
> 
>>> The current interface is subtly dangerous, you can't run set(get()) as
>>> you would expect.
>>>
>>> (well you can't with the lapic or the tsc msr either...)
>>>
>>>      
>> We may start documenting such dependency in kvm/api.txt. On the other
>> hand, if you have a get/set interface vs. an inject channel, I think
>> it's obvious that one can overwrite the other.
>>    
> 
> 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.

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.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]