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? > > - use 0XB3 bit for FEATURES_OK > >
