From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.groups.io with SMTP id smtpd.web11.52899.1612275368016273381 for ; Tue, 02 Feb 2021 06:16:08 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Eb43dx5o; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612275367; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=D4kgiuIBEW6Zmp9KmA5qx5R6FRETvY/8qEpLk/IVOZQ=; b=Eb43dx5oYhC6MFJP7UdNKuOLHkYWnXEP+/y86tlMnApwS0/Cb2Z7CqQoulVXP4IIwoGqOM hH2KI1AwrXSuUbVwVUYRrD6RdV31O00bZS+nxOc4XUzHGhDIOF17r07cu0PU+V9vnkYiZA RNxgRPAYq3u2L/pCYmd6CGRYeEAujKI= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-490-TwTrYBpSPe25zuiXnioAMA-1; Tue, 02 Feb 2021 09:16:03 -0500 X-MC-Unique: TwTrYBpSPe25zuiXnioAMA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E83EC1022843; Tue, 2 Feb 2021 14:15:44 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-241.ams2.redhat.com [10.36.115.241]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5E8783491A; Tue, 2 Feb 2021 14:15:42 +0000 (UTC) Subject: Re: [PATCH v6 7/9] OvmfPkg/CpuHotplugSmm: add CpuEject() From: "Laszlo Ersek" To: Ankur Arora , devel@edk2.groups.io Cc: imammedo@redhat.com, boris.ostrovsky@oracle.com, Jordan Justen , Ard Biesheuvel , Aaron Young References: <20210129005950.467638-1-ankur.a.arora@oracle.com> <20210129005950.467638-8-ankur.a.arora@oracle.com> <14068eb6-dc43-c244-5985-709d685fc750@oracle.com> Message-ID: Date: Tue, 2 Feb 2021 15:15:41 +0100 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 02/02/21 15:00, Laszlo Ersek wrote: > ... I guess that volatile-qualifying both CPU_HOT_EJECT_DATA, and the > array pointed-to by CPU_HOT_EJECT_DATA.ApicIdMap, should suffice. In > combination with the sync-up point that you quoted. This seems to match > existing practice in PiSmmCpuDxeSmm -- there are no concurrent accesses, > so atomicity is not a concern, and serializing the instruction streams > coarsely, with the sync-up, in combination with volatile accesses, > should presumably guarantee visibility (on x86 anyway). To summarize, this is what I would ask for: - make CPU_HOT_EJECT_DATA volatile - make (*CPU_HOT_EJECT_DATA.ApicIdMap) volatile - after storing something to CPU_HOT_EJECT_DATA or CPU_HOT_EJECT_DATA.ApicIdMap on the BSP, execute a MemoryFence() - before fetching something from CPU_HOT_EJECT_DATA or CPU_HOT_EJECT_DATA.ApicIdMap on an AP, execute a MemoryFence() Except: MemoryFence() isn't a *memory fence* in fact. See "MdePkg/Library/BaseLib/X64/GccInline.c". It's just a compiler barrier, which may not add anything beyond what we'd already have from "volatile". Case in point: PiSmmCpuDxeSmm performs heavy multi-processing, but does not contain a single invocation of MemoryFence(). It uses volatile objects, and a handful of InterlockedCompareExchangeXx() calls, for implementing semaphores. (NB: there is no 8-bit variant of InterlockedCompareExchange(), as "volatile UINT8" is considered atomic in itself, and a suitable basis for a sempahore too.) And given the synchronization from those semaphores, PiSmmCpuDpxeSmm trusts that updates to the *other* volatile objects are both atomic and visible. I'm pretty sure this only works because x86 is in-order. There are instruction stream barriers in place, and compiler barriers too, but no actual memory barriers. Now the question is whether we have managed to *sufficiently* imitate these patterns from PiSmmCpuDxeSmm, in this patch set. Making stuff volatile, and relying on the existent sync-up point, might suffice. Thanks Laszlo