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