Re: [Qemu-devel] [PATCH] hw/isa/lpc_ich9: inject the SMI on the VCPU that is writing to APM_CNT

[Laszlo Ersek]

On 10/23/15 09:26, Paolo Bonzini wrote:
> 
> 
> On 23/10/2015 06:41, Jordan Justen wrote:
>> On 2015-10-22 12:46:56, Paolo Bonzini wrote:
>>>
>>> On 22/10/2015 20:04, Kevin O'Connor wrote:
>>>> On Thu, Oct 22, 2015 at 10:40:08AM +0200, Paolo Bonzini wrote:
>>>>> On 21/10/2015 20:36, Jordan Justen wrote:
>>>>>> On 2015-10-20 11:14:00, Laszlo Ersek wrote:
>>>>>>> Commit 4d00636e97b7 ("ich9: Add the lpc chip", Nov 14 2012) added the
>>>>>>> ich9_apm_ctrl_changed() ioport write callback function such that it 
>>>>>>> would
>>>>>>> inject the SMI, in response to a write to the APM_CNT register, on the
>>>>>>> first CPU, invariably.
>>>>>>>
>>>>>>> Since this register is used by guest code to trigger an SMI 
>>>>>>> synchronously,
>>>>>>> the interrupt should be injected on the VCPU that is performing the 
>>>>>>> write.
>>>>>>
>>>>>> Why not send an SMI to *all* processors, like the real chipsets do?
>>>>>
>>>>> That's much less scalable, and more important I would have to check that
>>>>> SeaBIOS can handle that correctly.  It probably doesn't, as it doesn't
>>>>> relocate SMBASEs.
>>>>
>>>> SeaBIOS is only expecting its SMI handler to be called once in
>>>> response to a synchronous SMI.  We can change SeaBIOS to fix that.
>>>>
>>>> SeaBIOS does relocate the smbase from 0x30000 to 0xa0000 during its
>>>> init phase (by creating a synchronous SMI on the BSP and then setting
>>>> the smbase register to 0xa0000 in the smi handler).
>>>
>>> Right; however it would also have to relocate the SMBASE on the APs (in
>>> case they were halted with cli;hlt and not INITed).  It's really not
>>> worth the hassle,
>>
>> It's not worth the hassle to relocate the SMBASE of the APs?
>> So, basically, write to 0x30000-0x38000, then send an SMI IPI to the
>> AP and now you have the AP running in SMI and it has extra privileges?
> 
> Extra privileges compared to what?  Legacy BIOS does not really put
> anything privileged in SMRAM, while OVMF does and _hence_ relocates the
> SMBASE of the AP.  It would have been nice to get it right from the
> beginning, but right now it's not worth forcing a lockstep QEMU-SeaBIOS
> update.

So what are we thinking about a magic APM_STS value to trigger an SMI
for all VCPUs? 0x51 ('Q') would be cool. :)

Thanks
Laszlo