Re: [Qemu-devel] [PATCH v2] hw/isa/lpc_ich9: inject SMI on all VCPUs if APM_STS == 'Q'

[Michael S. Tsirkin]

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