From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c74af-0006mr-Mf for qemu-devel@nongnu.org; Wed, 16 Nov 2016 13:05:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c74ae-0003bO-Ff for qemu-devel@nongnu.org; Wed, 16 Nov 2016 13:05:45 -0500 Date: Wed, 16 Nov 2016 13:04:00 -0500 (EST) From: Paolo Bonzini Message-ID: <771517296.13175228.1479319440822.JavaMail.zimbra@redhat.com> In-Reply-To: <8f3f29f5-ddb3-5864-84e9-90af5aa72100@redhat.com> References: <20161115015049.2735-1-lersek@redhat.com> <41b3f7ed-0d4c-c879-6bf2-f0325937a0fb@redhat.com> <4f179a45-d10c-82f8-c57b-b7b503674a97@redhat.com> <20161115174436-mutt-send-email-mst@kernel.org> <5a5fce10-9513-c349-a7b0-0931de271322@redhat.com> <1055353985.13082457.1479300462972.JavaMail.zimbra@redhat.com> <8f3f29f5-ddb3-5864-84e9-90af5aa72100@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] hw/isa/lpc_ich9: inject SMI on all VCPUs if APM_STS == 'Q' List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: "Michael S. Tsirkin" , qemu devel list , Michael Roth , qemu-stable@nongnu.org > I guess that's what the next paragraph is about: > > > - we could have another magic 0xB2 value, which is implemented directly > > in QEMU and sets 0xB3 to a magic value. Then OVMF can invoke it > > after SMBASE relocation and SMM IPL (so as not to crash on old QEMUs) > > to detect the new feature. It can fail to start if using traditional > > AP and the new feature is not there. > > Please explain in more detail. If I write to 0xB2 (by invoking the > Trigger() method or somehow else), then on old QEMU's that will raise a > sync / unicast SMI. The SMI handler in edk2 will run, but no request > parameters will have been set up by OVMF, so the SMI handler will do... > no clue what. It should hopefully do nothing. A spurious SMI (such as the one caused by the write to 0xB2) should not crash OVMF. SMBASE relocation uses IPIs, so my hope was to use the SmmCpuFeaturesSmmRelocationComplete hook. > My preference is fw_cfg ATM. It provides a prove, flexible and > extensible interface (it's easy to add new files for future features). > If we expect more knobs in the area, I can modify my proposal to use > "etc/smi/broadcast", so we can add "etc/smi/XXXX" later. Did you know there are 16 entries only for fw_cfg files? :) And we're using already 20 in the worst case: genroms/linuxboot.bin genroms/kvmvapic.bin NVDIMM_DSM_MEM_FILE "etc/smbios/smbios-tables" "etc/smbios/smbios-anchor" "etc/acpi/tables" "etc/table-loader" ACPI_BUILD_TPMLOG_FILE ACPI_BUILD_RSDP_FILE "etc/e820" "etc/msr_feature_control" "etc/reserved-memory-end" "etc/pvpanic-port" "etc/boot-menu-wait" "bootsplash.jpg" "etc/boot-fail-wait" "etc/igd-opregion" "etc/igd-bdsm-size" "etc/extra-pci-roots" "bootorder" Therefore, so close to the release I'm a bit worried about doing changes to fw_cfg or adding more fw_cfg files. Though we just got rid of one file for the number of CPUs, so I guess we might not care. > Do you have any specific arguments against fw_cfg? As I suggested in my > previous email, with fw_cfg I can implement the change in OVMF such that > the default behavior wouldn't change -- the default delivery would > remain relaxed, and the broadcast wouldn't be requested, unless the > fw_cfg file told OVMF otherwise. > > > By the way, in case OVMF needs to use SmmSwDispatch in the future, I > > would make QEMU use broadcast behavior for all values in the 0x10-0xff > > range, or something like that. > > Are we talking control/command (0xB2) or scratch/data (0xB3) register > values? My patches currently use the scratch/data register to provide > the hint to QEMU; that register is less likely to interfere with > anything the SMM core in edk2 does. Sorry I confused the two registers. 0xb3 is more or less unused as far as I can see indeed. Paolo