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.web08.6878.1614066353083703966 for ; Mon, 22 Feb 2021 23:45:53 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=S+vM4Xuq; spf=pass (domain: redhat.com, ip: 63.128.21.124, mailfrom: pbonzini@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614066352; 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=N0i8Ltb4i1YsQMGSOgLH+v85AXpLEM4deXbZbFx+H/Y=; b=S+vM4Xuqhekol4ZV3cb6Fm8aybqS6RM8NvBr3z7H1e/0958KyliKcrM+FPpuO27wP45BOY jYxBGZpTLs7YAVMUbacrFvJoXn2bSKpvNgAs7wy9WM0jhqVHqRxrFjNXAiA0df+uWZMGqj FG7hjkD9raUB307ScH4Ge7JCy8AdclE= Received: from mail-ej1-f69.google.com (mail-ej1-f69.google.com [209.85.218.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-336-I3beiVfWP5-y6_5r37IgdQ-1; Tue, 23 Feb 2021 02:45:38 -0500 X-MC-Unique: I3beiVfWP5-y6_5r37IgdQ-1 Received: by mail-ej1-f69.google.com with SMTP id v10so1220162ejh.15 for ; Mon, 22 Feb 2021 23:45:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N0i8Ltb4i1YsQMGSOgLH+v85AXpLEM4deXbZbFx+H/Y=; b=RrNi6DeQMQ8ddi51sx2hazGcv+MOds+GBoq6pN7KPcnkKzDTdXYLJEqApsAlVF/Put O7+UgBXdSL7uvqM6k86zcUxSmgUcj1yQkIOt3wvX41J5ss2kx0MH4aFJG038YPV9PvxM RRdOSqSxgJp6KhjCbp09kFhFa4VCSBx+MO912TbzJuUox4OB70RZ9a7Bdcz7wv/u+ZhB iMaE7Pq3noWYcZrFPGJtmNNIRil/ijWmF59ZO2ueAyLug8/IJUA3AJgzShUlnqta+6GD UmXYLtpkLtPe0VqmWEBFF5MolY/70NDfDmTMB8N941OiHA7twh0PnRhUjxEgo2uGf8I9 D3HQ== X-Gm-Message-State: AOAM532wQ8zw8l9FK7DdBtGxvgCrhluwv/aPHyjn1LOql/5WYmUUJdxc dzWXTWbYe2TVp45iz0LkdXqk0T3bTGvJPmmSYbmdWGG1f0s1I1ugw6oPLfWHJsYIKQWzhyKwiji bA98zGL2T4tbQsw== X-Received: by 2002:a17:907:970f:: with SMTP id jg15mr24723120ejc.440.1614066337593; Mon, 22 Feb 2021 23:45:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJzKfMsEkw1UewHe4Bgq17xacgCzltEnA84SVOFxdTFPVtDxI/6OjasdWEVWMPNs7NeAvJdWPw== X-Received: by 2002:a17:907:970f:: with SMTP id jg15mr24723104ejc.440.1614066337389; Mon, 22 Feb 2021 23:45:37 -0800 (PST) Return-Path: Received: from ?IPv6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.gmail.com with ESMTPSA id n17sm5516551eds.96.2021.02.22.23.45.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Feb 2021 23:45:36 -0800 (PST) Subject: Re: [edk2-devel] [PATCH v8 07/10] OvmfPkg/SmmCpuFeaturesLib: call CPU hot-eject handler To: Laszlo Ersek , devel@edk2.groups.io, ankur.a.arora@oracle.com Cc: imammedo@redhat.com, boris.ostrovsky@oracle.com, Jordan Justen , Ard Biesheuvel , Aaron Young References: <20210222071928.1401820-1-ankur.a.arora@oracle.com> <20210222071928.1401820-8-ankur.a.arora@oracle.com> From: "Paolo Bonzini" Message-ID: <746e09c5-8623-d1fe-5871-0960abf09579@redhat.com> Date: Tue, 23 Feb 2021 08:45:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=pbonzini@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 22/02/21 15:53, Laszlo Ersek wrote: >> + >> + if (mCpuHotEjectData != NULL) { >> + CPU_HOT_EJECT_HANDLER Handler; >> + >> + Handler = mCpuHotEjectData->Handler; > This patch looks otherwise OK to me, but: > > In patch v8 08/10, we have a ReleaseMemoryFence(). (For now, it is only > expressed as a MemoryFence() call; we'll make that more precise later.) > > (1) I think that should be paired with an AcquireMemoryFence() call, > just before loading "mCpuHotEjectData->Handler" above -- for now, also > expressed as a MemoryFence() call only. In Linux terms, there is a control dependency here. However, it should at least be a separate statement to load mCpuHotEjectData (which from my EDK2 reminiscences should be a global) into a local variable. So EjectData = mCPUHotEjectData; // Optional AcquireMemoryFence here if (EjectData != NULL) { CPU_HOT_EJECT_HANDLER Handler; Handler = EjectData->Handler; if (Handler != NULL) { Handler (CpuIndex); } } Thanks, Paolo