RE: [Xen-devel] [PATCH] "lock cmpxch8b" and split locks

Nakajima, Jun
Fri, 07 Oct 2005 19:21:26 -0000

Keir Fraser wrote:
> Nice try, but the first sentence of your quote applies only to
> ordinary (non-LOCKed) memory accesses. Section 7.1.2.2 states that
> "The integrity of a bus lock is not affected by the alignment of the
> memory field. The LOCK semantics are followed for as many bus cycles
> as necessary to update the entire operand."
>
> I''m sure you get away with this in practise. 64-bit quantities are
the
> only simple type that does not get naturally aligned in x86 C ABI.
> cmpxchg8b is a pretty rare instruction and most users would be very
> careful to ensure correct alignment in the cases it is used. Luckily
> it was easy for us to make the necessary changes too.

But we don''t want to see unexpected #AC in ring0. Can check the bit 4
(Split-Lock Disable) and 8 (Suppress Lock Enable) of IA32_MISC_ENABLE
MSR (0x1a0)? You may have set the bit 4. You want to set the bit 8, not
bit 4.


>
>   -- Keir
>
> On 6 Oct 2005, at 22:00, Puthiyaparambil, Aravindh wrote:
>
>> I spoke to our hardware engineers about this. They pointed me at
>> Section
>> 7.1.1 of Volume 3 of the Intel Software Developers Manual.
>>
>> "Accesses to cacheable memory that are split across bus widths,
cache
>> lines, and page boundaries are not guaranteed to be atomic by the
>> Pentium 4, Intel Xeon, P6 family, Pentium, and Intel486 processors.
>> The Pentium 4, Intel Xeon, and P6 family processors provide bus
>> control signals that permit external memory subsystems to make split
>> accesses atomic; however, on aligned data accesses will seriously
>> impact the performance of the processor and should be avoided."
>>
>> I hope this gives you a better picture of the situation.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel



Jun
---
Intel Open Source Technology Center