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

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

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

Avi Kivity wrote:
> On 11/17/2009 06:50 PM, Jan Kiszka wrote:
>>
>>> 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.
>>    
> 
> It makes sense from a grouping point of view... maybe.
> 
>> But what would you queue at all? Only mp_state, nmi_pending and
>> sipi_vector?
> 
> INIT, too.

INIT should be handled by queuing up the next mp_state.

BTW, as we do not inject mp_state changes from user space during
runtime, the issue I saw with the current interface is not existing. We
just need to add that queuing feature to asynchronous in-kernel mp_state
changes, and we should be fine.


Let's assume we will have such changes in future kernels: should
qemu-kvm and qemu upstream also bother about older kernels and establish
workarounds? Because then we need to find a cleaner approach than the
current one, and my proposed patch comes into the game again.

Jan


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