qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] hw/isa/lpc_ich9: inject the SMI on the VCPU tha


From: Jordan Justen
Subject: Re: [Qemu-devel] [PATCH] hw/isa/lpc_ich9: inject the SMI on the VCPU that is writing to APM_CNT
Date: Thu, 22 Oct 2015 21:41:15 -0700
User-agent: alot/0.3.6

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?

> it's not even documented in the chipset docs whether
> 0xb2 sends an SMI to all processors or only the running one.

My knowledge of recent chipsets is getting rusty, but in ICH ~ ICH6
the SMI# pin was wired to every processor. Any chipset based SMI would
cause all processors to enter SMM.

In more recent chipsets, I could speculate that maybe the SMI could be
delivered over a bus instead. But, I still think the chipset SMI's
would go to all processors. I did note from the ICH9 datasheet that
there is still a SMI# pin.

I also saw this under "Interrupt Message Format" of the ICH9
datasheet:

"The ICH9’s I/O APIC can only send interrupts due to interrupts which
 do not include SMI, NMI or INIT. This means that in IA-32/Intel ® 64
 based platforms, Front Side Bus interrupt message format delivery
 modes 010 (SMI/ PMI), 100 (NMI), and 101 (INIT) as indicated in this
 section, must not be used and is not supported. Only the hardware pin
 connection is supported by ICH9."

This leads me to think that the ICH9 system designs continued to wire
the SMI# pin to all processors.

-Jordan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]