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? Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
