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: Laszlo Ersek
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 11:50:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10/22/15 10:40, 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.

We could invent a magic value for APM_STS (not used by SeaBIOS) that
would decide between "all" and "current". It would be an ugly hack, yes,
but this is a virtual platform. :)

Theoretically, the Trigger() function in OVMF can take a value for
APM_STS from the caller -- this is specified even on the protocol level
--, but the only caller, the SMM core, doesn't fill in that optional
parameter (the pointer to the APM_STS value is NULL):

MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c:

    Status = mSmmControl2->Trigger (mSmmControl2, NULL, NULL, FALSE, 0);

So in OVMF's implementation of Trigger(), we could replace

  IoWrite8 (ICH9_APM_STS, DataPort    == NULL ? 0 : *DataPort);

with

  IoWrite8 (ICH9_APM_STS, DataPort    == NULL ? MAGIC : *DataPort);

and then in QEMU the cpu_interrupt() call in question could be wrapped
in a loop for all CPUs. (Or maybe we already have a helper function for
that.)

... With the "relaxed" method configured in OVMF, the above change would
make no difference as long as the BSP executes the firmware -- which is
guaranteed before ExitBootServices() --, but it still makes a difference
if later a runtime service is called by an AP. In that case the AP must
drag in the BSP, and that takes very long (1 second loop). We can
decrease that loop length of course, but how much? 100ms? 10ms?

Anyway, just an idea.

Thanks
Laszlo

> 
> Paolo
> 




reply via email to

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