Il 03/09/2013 15:56, Marcelo Tosatti ha scritto:
>>> The point of REQ_MCLOCK_INPROGRESS request is to guarantee that the
>>> following is not possible:
>>>
>>> - 2 vcpus in guest mode with per-vcpu kvmclock areas with
>>> different {system_timestamp, tsc_offset} values.
>>
>> Understood.
>>
>>> To achieve that:
>>>
>>> - Kick all vcpus out of guest mode (via a request bit that can't be
>>> cleared).
>>> - Update the {system_timestamp, tsc_offset} values.
>>> - Clear the request bit.
>>
>> After make_all_cpus_request, all VCPUs will be out of guest mode, and
>> the request bit will not be cleared until pvclock_gtod_sync_lock is
>> released.
>
> It seems more obfuscated to rely on an implicit pvclock_gtod_sync_lock
> blocking than an explicit request bit that can't be cleared, but perhaps
> thats personal opinion.
Yes, this gets dangerously close to personal opinion territory. :)
> OTOH, you can also argue that the request bit abuses the vcpu->requests
> request mechanism, because there is not a request in fact (it only
> blocks guest entry).
The busy-wait is a bit ugly, but otherwise it's fine.
> If you have reasons to update, and you are sure its safe, feel
> free to modify it.
No reason yet apart from removing a few lines of code, but thanks for
discussing this. If you want to do the seqlock change for
pvclock_gtod_sync_lock, I'll be glad to review the patch.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
