Re: [Xen-devel] [PATCH 1/3] x86/xen: use memory barriers when enabling local irqs

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.08.13 at 16:31, David Vrabel <david.vrabel@xxxxxxxxxx> wrote:
> From: David Vrabel <david.vrabel@xxxxxxxxxx>
> 
> Because vcpu->evtchn_upcall_mask and vcpu->evtchn_upcall_pending are
> be written by Xen as well as the guest, using barrier() (a
> compiler-only barrier) in xen_enable_irq() and xen_restore_fl() is not
> sufficient.
> 
> Use mb() (a full memory barrier) instead.

If this was generic code, I'd agree. But in x86 specific code I don't
see the need.

Jan

> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
> ---
>  arch/x86/xen/irq.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
> index 01a4dc0..1a8d0d4 100644
> --- a/arch/x86/xen/irq.c
> +++ b/arch/x86/xen/irq.c
> @@ -60,7 +60,7 @@ static void xen_restore_fl(unsigned long flags)
>  
>       if (flags == 0) {
>               preempt_check_resched();
> -             barrier(); /* unmask then check (avoid races) */
> +             mb(); /* unmask then check (avoid races) */
>               if (unlikely(vcpu->evtchn_upcall_pending))
>                       xen_force_evtchn_callback();
>       }
> @@ -93,7 +93,7 @@ static void xen_irq_enable(void)
>       /* Doesn't matter if we get preempted here, because any
>          pending event will get dealt with anyway. */
>  
> -     barrier(); /* unmask then check (avoid races) */
> +     mb(); /* unmask then check (avoid races) */
>       if (unlikely(vcpu->evtchn_upcall_pending))
>               xen_force_evtchn_callback();
>  }
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx 
> http://lists.xen.org/xen-devel 




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel