From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c76nU-0005Jp-66 for qemu-devel@nongnu.org; Wed, 16 Nov 2016 15:27:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c76nR-0004Bj-2s for qemu-devel@nongnu.org; Wed, 16 Nov 2016 15:27:08 -0500 Date: Wed, 16 Nov 2016 22:27:02 +0200 From: "Michael S. Tsirkin" Message-ID: <20161116222356-mutt-send-email-mst@kernel.org> 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> <20161116150943-mutt-send-email-mst@kernel.org> <29692970-0020-87d9-0d98-7ba10342ea64@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29692970-0020-87d9-0d98-7ba10342ea64@redhat.com> 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: Paolo Bonzini , qemu-stable@nongnu.org, qemu devel list , Michael Roth On Wed, Nov 16, 2016 at 07:03:27PM +0100, Laszlo Ersek wrote: > On 11/16/16 15:05, Paolo Bonzini wrote: > > > > > > On 16/11/2016 14:18, Michael S. Tsirkin wrote: > >>> - 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. > >> > >> If we keep collecting these magic values, should architect it > >> and do a host/guest bitmap like virtio does? > > > > The value written in 0xB3 can certainly be a feature bitmap. For now we > > would have for example > > > > bit 0 if set, writing 0x10-0xFF to 0xB2 results in a broadcast SMI > > bit 1-7 zero > > Doable, but: > - doesn't address how OVMF learns about the broadcast SMI availability, > - the command value OVMF currently writes is 0. > > How about this: > - etc/smi/features is the LE uint64_t bitmap proposed earlier, bit#0 > stands for broadcast SMI availability > - 0xB2 is the command value (independent of 0xB3) > - 0XB3 is a guest feature bitmap (valid for the next request). SeaBIOS > reserves bit#0 already (uses values 0 and 1), so we can use the > remaining 7 bits for requesting features. Bit#1 (value 2) could be the > broadcast SMI. > > This does resemble a kind of feature negotiation, except the host cannot > signal back an error (unsupported combination of features), like > virtio-1.0 can. We can make QEMU abort in that case, or ignore the flags. > > Thanks > Laszlo I think that if you are going to do it, do it like 1.0: - same bitmap for host and guest. how about a writeable fw cfg file? - use 0XB3 bit for FEATURES_OK -- MST