On 22/11/2018 15:20, Roger Pau Monné wrote: > On Thu, Nov 22, 2018 at 02:03:55PM +0000, Julien Grall wrote: >> Hi Jan, >> >> On 11/22/18 1:36 PM, Jan Beulich wrote: >>>>>> On 22.11.18 at 14:31, <andrew.coop...@citrix.com> wrote: >>>> I think Julien's point is that without explicitly barriers, CPU0's >>>> update to system_state may not be visible on CPU1, even though the >>>> mappings have been shot down. >>>> >>>> Therefore, from the processors point of view, it did everything >>>> correctly, and hit a real pagefault. >>> Boot time updates of system_state should be of no interest here, >>> as at that time the APs are all idling. >> That's probably true today. But this code looks rather fragile as you don't >> know how this is going to be used in the future. >> >> If you decide to gate init code with system_state, then you need a barrier >> to ensure the code is future proof. > Wouldn't it be enough to declare system_state as volatile?
No. volatility (or lack thereof) is a compiler level construct. ARM has weaker cache coherency than x86, so a write which has completed on one CPU0 in the past may legitimately not be visible on CPU1 yet. If you need guarantees about the visibility of updated, you must use appropriate barriers. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
