[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 6/7] xen/evtch: use smp barriers for user event ring
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
- Date: Mon, 8 Feb 2021 10:45:07 +0000
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KTAhKbc8ItfP/8f/ZVtVH7mdz7uVY/mhTn0Uoxu7XQ4=; b=aQSUZ3Jba6eFbxJFXSpUsp0Cljtcb4YTA7+qWnlpTG80CmOJwda335H3OcqHDVkRGF2URlpH6Ho0xwiWHdDLwAa1FHeFTD4N4xMymrGCpLpWj/eJw0/Xp6DeSSmYOlEZLGrK65jOX+Uh/2KfLpRM0nm/PxZt5cYD0w069nkGTEF1VAqcjUQHMTGcDSKAozusyxCK78rd0U2/lAxAYaVWr9QXnWaYGYdwGmTG3upadjt2d2e8dgaeZKhtS20rkwvWVCjeI8bZwqr7cl/OAq338AFquhdJAGEVvQYQ66+2EVlijhEXad4fW5tety1pMgiw5uuuixWHf3i1zpM0mldHEw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZitFKSKKOhP1dbIzVOi/kUfoIOhPjzI8OS24C5WkEv/JZI4dCHtHJBzl+yQmpUb0FrRSZF5LbbF5V1yv+v1i82/YIerPTl+8wb5hz9RFtorKjtIZiTpBjkkiNwqo1M1CtOseUR3S+I1aouIasZ12UapvPQacFNeigdO95bGmHlUb/rQeGnveXgQds2IQc9ckWS3zughSB6dINEKcP4MZxJpd3Qv569PBQBVIcsvPQmeBuI3oh/3iXsge9iEsWU42VkYOyweiaSUAKlbtqxmFBTCgHi+ou0qLt0n5fYq3H67bQ8slbLweb9A2CD/bTJWAddMjNmnnJKC2v1eu7Jb0vA==
- Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
- Cc: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 08 Feb 2021 10:45:20 +0000
- Ironport-sdr: dLXmBGtmA5SK9mLVGnfJ5CwbCEpIfdJepfI+K//9UEPkFe/WYAMwhCpW1kbX2JY7Mgiiy6zT/t MgP9ZnPhZ7jNe0QmV5gPCxIBaJ9/DFDdk0mw7sk10PXeBxsh6jMYtYP7F5qIR+sHYauwMfMe+o xK51HjPdrlP7T1HZ12+9FFSNVFaGy+sNgH1xpYbupRWq/OOJmlmUS65rN7sLTIsLAd7zHHXVDS hntvuBe2/4c59edQA6Aid2ZNvb0WwKVW4yyo8mVOeHHIaS/WfGLi3cyfdnUfXdeZoBIoUGJg3M GMg=
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 08/02/2021 10:36, Jan Beulich wrote:
> On 08.02.2021 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@xxxxxxxxxx>
>>>>> Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
>>>> 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.
> Hmm, I may not know enough of Arm's memory model - are you saying
> Arm CPUs aren't even self-coherent, i.e. later operations (e.g.
> the consuming of ring contents) won't observe earlier ones (the
> updating of ring contents) when only a single physical CPU is
> involved in all of this? (I did mention the hypervisor level
> context switch simply because that's the only way multiple CPUs
> can get involved.)
In this case, no - see my later reply. I'd mistaken the two ends of
this ring. As they're both inside the same guest, its fine.
For cases such as the xenstore/console ring, the semantics required
really are SMP, even if the guest is built UP. These cases really will
break when smp_rmb() etc degrade to just a compiler barrier on
architectures with weaker semantics than x86.
~Andrew
|
