From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7Rh0-0006OX-BD for qemu-devel@nongnu.org; Thu, 17 Nov 2016 13:45:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7Rgv-0001PQ-Cz for qemu-devel@nongnu.org; Thu, 17 Nov 2016 13:45:50 -0500 References: <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> <20161116222356-mutt-send-email-mst@kernel.org> <32d1f1df-1104-6f28-bc11-70215570ecb5@redhat.com> <20161117194357-mutt-send-email-mst@kernel.org> From: Laszlo Ersek Message-ID: <4d0f2c38-5cb3-563e-6882-41aee212dc1f@redhat.com> Date: Thu, 17 Nov 2016 19:45:40 +0100 MIME-Version: 1.0 In-Reply-To: <20161117194357-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=windows-1252 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: "Michael S. Tsirkin" Cc: Michael Roth , Paolo Bonzini , qemu-stable@nongnu.org, qemu devel list On 11/17/16 18:46, Michael S. Tsirkin wrote: > On Thu, Nov 17, 2016 at 02:16:35PM +0100, Laszlo Ersek wrote: >> On 11/16/16 21:27, Michael S. Tsirkin wrote: >>> 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? >> >> fw_cfg files are not writeable since qemu 2.4 (see commits 023e3148567ac >> and 6cec43e178cde). >> >> How about this alternative, in STS: >> - bit 0: read and written transparently >> - bit 1: on write: >> 0 -- set features in bits 2-7 >> 1 -- query host features into bits 2-7 >> on read: >> - after querying features: >> - reads back as 0 if the interface is supported >> - reads back as 1 if the interface is missing >> - after setting features: >> - reads back as 0 if the feature subset is valid >> - reads back as 1 otherwise >> - bit 2: on write: >> - when setting features: request broadcast SMI >> - when querying features: ignored >> on read: >> - after setting features: zero >> - after querying features: broadcast SMI availability (1 if >> available) >> >> - bit 3-7: future features (I think 5 more features for SMI handling >> should suffice), working similarly to bit 2 >> >> SeaBIOS writes values 0x00 and 0x01, and expects to find the same when >> reading back. Bit pattern 0000_000?b translates to "clear all >> features", which always succeeds and results in behavior identical to >> the current one, hence bits 1-7 read back as zero. >> >> OVMF: >> - write 0x02, read back value: >> - if bit 1 is set, interface is missing >> - otherwise feature bitmap was returned in bits 2-7 >> - select requested features in bits 2-7, set bit 1 to 0, write value, >> read back value >> - if bit 1 is set, the feature subset is invalid >> - okay otherwise >> >> Thanks >> Laszlo > > > It's all fine, or we can make fw cfg writeable again (I posted > a patch for that a while ago), but it's all a bit too much > for this release. > > Let's just defer it, or do you have a better idea? I'm writing patches for the above proposal (including a document under docs/specs/), and I plan to post them soon. They're definitely 2.9 material though -- I don't mind if I have to wait a bit even just to get feedback on those patches :) So, to make it formal for the patch that started this thread: Self-NAK Will post something better / more flexible soon, for 2.9. (Hopefully I'll remember to put "[for-2.9]" in the subject.) Thanks! Laszlo >>> - use 0XB3 bit for FEATURES_OK >>>