Keir Fraser wrote:

>>
>> My only argument in favor of using the lock would be for completeness 
>> of the emulation. You are
>> absolutely right in that for Linux there seems to be no need to hold 
>> the lock. My concern is that
>> other OSs  may treat this differently. And if we don't have sources, 
>> it may be somewhat difficult
>> to  figure out that the atomicity (or lack of it) was the cause of a 
>> problem.
>>
>> If, however, there is a strong feeling that we don't need the lock, I 
>> am happy to drop it.
>> I guess you are mostly unhappy about adding a new field to 
>> hvm_domain, not about performance
>> impact?
>
>
> Yes, also my second argument was that there is *no way* for two VCPUs 
> to conflict on a local APIC access, since LAPIC accesses are always to 
> the VCPU's own LAPIC. So there is no potential concurrency that needs 
> to be serialised, regardless of the guest OS.


OK, that's fair. Here is updated patch with lock removed.

I don't think I then understand why Linux is using atomic accesses to
local APICs. It's interesting though that 64-bit code doesn't do it ---
they use vanilla apic_write().

-boris