[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60ca5c18-bbf5-5d3d-1af6-f4692077c44e@suse.com>
Date: Mon, 8 Feb 2021 11:25:36 +0100
From: Jürgen Groß <jgross@...e.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>,
Jan Beulich <jbeulich@...e.com>
Cc: Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Stefano Stabellini <sstabellini@...nel.org>,
linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org
Subject: Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring
On 08.02.21 11:23, Andrew Cooper wrote:
> On 08/02/2021 09:50, Jan Beulich wrote:
>> On 08.02.2021 10:44, Andrew Cooper wrote:
>>> On 06/02/2021 10:49, Juergen Gross wrote:
>>>> The ring buffer for user events is used in the local system only, so
>>>> smp barriers are fine for ensuring consistency.
>>>>
>>>> Reported-by: Andrew Cooper <andrew.cooper3@...rix.com>
>>>> Signed-off-by: Juergen Gross <jgross@...e.com>
>>> These need to be virt_* to not break in UP builds (on non-x86).
>> Initially I though so, too, but isn't the sole vCPU of such a
>> VM getting re-scheduled to a different pCPU in the hypervisor
>> an implied barrier anyway?
>
> Yes, but that isn't relevant to why UP builds break.
>
> smp_*() degrade to compiler barriers in UP builds, and while that's
> mostly fine for x86 read/write, its not fine for ARM barriers.
>
> virt_*() exist specifically to be smp_*() which don't degrade to broken
> in UP builds.
But the barrier is really only necessary to serialize accesses within
the guest against each other. There is no guest outside party involved.
In case you are right this would mean that UP guests are all broken on
Arm.
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3092 bytes)
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists