From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Mon, 07 Oct 2019 02:34:58 -0700 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 mx1.redhat.com (Postfix) with ESMTPS id 8FA1281F0F; Mon, 7 Oct 2019 09:34:57 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-11.rdu2.redhat.com [10.10.120.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id ABD01196B2; Mon, 7 Oct 2019 09:34:54 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH wave 1 00/10] support QEMU's "SMRAM at default SMBASE" feature To: devel@edk2.groups.io, imammedo@redhat.com Cc: Ard Biesheuvel , Boris Ostrovsky , Brijesh Singh , Jiewen Yao , Joao M Martins , Jordan Justen , Jun Nakajima , Michael Kinney , Paolo Bonzini , Phillip Goerl , Yingwen Chen References: <20190924113505.27272-1-lersek@redhat.com> <20190927133533.14b75bc1@redhat.com> <15679c12-857f-cdd2-47ae-adbfe21c2d57@redhat.com> <20191004160948.72097f6c@redhat.com> From: "Laszlo Ersek" Message-ID: <6b608959-2e2e-3d45-c366-3ecd0c62d64e@redhat.com> Date: Mon, 7 Oct 2019 11:34:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20191004160948.72097f6c@redhat.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 07 Oct 2019 09:34:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 10/04/19 16:09, Igor Mammedov wrote: > On Tue, 1 Oct 2019 17:31:17 +0200 > "Laszlo Ersek" wrote: >> (It does not matter if another hotplug CPU starts the relocation in SMM >> while the earlier one is left with *only* the RSM instruction in SMM, >> immediately after the swap-back.) > I don't see why it doesn't matter, let me illustrate the case > I'm talking about. Right, I'm sorry -- I completely forgot that the RSM instruction is what makes the newly set SMBASE permanent! [...] > Safest way to deal with it would be: > > 1. wait till all host CPUs are brought into SMM (with hotplug SMI handler = check me in) > > 2. wait till all hotplugged CPUs are put in well know state > (a host cpu should send INIT-SIPI-SIPI with NOP vector to wake up) > > 3. a host CPU will serialize hotplugged CPUs relocation by sending > uincast SMI + INIT-SIPI-SIPI NOP vector to wake up the second time > (with hotplug SMI handler = relocate_me) > > alternatively we could skip step 3 and do following: > > hotplug_SMI_handler() > hp_cpu_check_in_map[apic_id] = 1; > /* wait till another cpu tells me to continue */ > while(hp_cpu_check_in_map[apic_id]) ;; > ... > > host_cpu_hotplug_all_cpus() > wait till all hotpluged CPUs are in hp_cpu_check_in_map; > for(i=0;;) { > if (hp_cpu_check_in_map[i]) { > /* relocate this CPU */ > hp_cpu_check_in_map[i] = 0; > } > > tell QEMU that FW pulled the CPU in; > /* we can add a flag to QEMU's cpu hotplug MMIO interface to FW do it, > so that legitimate GPE handler would tell OS to online only > firmware vetted CPUs */ > } [...] >> How can we discover in the hotplug initial SMI handler at 0x3_0000 that >> the CPU executing the code should have been relocated *earlier*, and the >> OS just didn't obey the ACPI GPE code? I think a platform reset would be >> a proper response, but I don't know how to tell, "this CPU should not be >> here". > > one can ask QEMU about present CPUs (via cpu hotplug interface) > and compare with present CPU state in FW (OS can hide insert > event there but not the presence). > > another way is to keep it pinned in relocation SMI handler > until another CPU tells it to continue with relocation. > > In absence of SMI, such CPU will continue to run wild but do we > really care about it? Thanks. It's clear that, for me, too much hangs in the air right now. I'll have to get my hands dirty and experiment. I need to learn a lot about this area of edk2 as well, and experimenting looks like one way. Let's return to these question once we reach the following state: - ACPI code generated by QEMU raises a broadcast SMI on VCPU hotplug - in OVMF, a cold-plugged CPU executes platform code, in a custom SMI handler - in OVMF, a hot-plugged CPU executes platform code, in the initial (default) SMI handler. Once we get to that point, we can look into further details. I'll answer under your other email too: . Thanks Laszlo