>>> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> 17.03.06 11:19:21 >>>
>
>On 13 Mar 2006, at 16:40, Jan Beulich wrote:
>
>> The compiler isn't required to order the two stores
>> ptep_get_and_clear_full() in any particular way, and we saw cases
>> where the upper 32 bits get stored before the lower ones, which causes
>> the access to fail (page-fault propagated out of
>> Xen).
>
>Isn't this patch needed for native also? Even though this fastpath is
>(I think) only called from exit_mmap(), processors may still be running
>on those pagetables at that point (e.g., due to lazy switching).
I thought about that, too, but wasn't sure.
>So what if:
>
>1. Compiler causes high to be cleared before low.
>2. This causes an invalid PTE (e.g., pointing into an uncacheable I/O
>region)
>3. A processor speculatively loads the PTE into its TLB
>4. A processor speculatively fetches a cacheline from the bogus area
>5. You get a bug like the old AMD GART hang, where the CPU writes back
>the cache line at an inopportune moment, when it should never have been
>cached in the first place.
It, at least as per the spec, cannot write this cache line back, as everything
up to here was speculative, and hence no change to the cache line may have
occurred. But the caching inconsistencies would still be a problem and could,
if I recall right, lead to processor hangs.
If such a speculative access is considered theoretically possible, then yes, I'd
think the same change is needed for native.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home