> On Nov 3, 2015, at 11:42 AM, Jordan Justen <[email protected]> wrote: > > On 2015-11-03 05:45:52, Paolo Bonzini wrote: >> >> >> On 03/11/2015 14:25, Laszlo Ersek wrote: >>> - Agreement between Paolo, Jordan and Mike about implementing >>> broadcast SMIs. I am willing to code up whatever design is >>> agreed upon. Can everyone involved please prioritize this >>> discussion a little? > > Obviously we'll have to follow what QEMU decides, so I'm not sure how > much we can actually influence this. > > Aside from the desire to better emulate chipset/platform designs of > the actual hardware, I do have a related question. >
The SMI IPI is sent from a processor in SMM, so like all other hardware resources used in SMM the SMM handler needs to restore any state it changes on exit. The old PCI 0xCF8/0xCFC IO ports are the old school example of this need to restore state to be transparent to the OS. Funny old school story but this kind of issue cropped up with the IPMI in the 1990's as the hardware interface was an indexed IO registers, and the communications was a message (multiple bytes of data). It was not always possible to home the IPMI state machine and some times the SMM handler would bork the OS IPMI driver state. The final resolution was adding a 2nd set of registers dedicated to SMM so the IPMI device could probably track state in all cases. > If we use the local apic to initiate IPIs to other processors, what > impact might that have on the state of the local apic if the OS is > also trying to use it? For example, what if the OS is in the middle of > trying to send an IPI? > > I think real platforms get to nicely avoid this by having the chipset > assert SMI to the hardware pins of all processors in the system. It > looks like our code has a provision for having one processor send the > others into SMM, but I wonder under which scenarios this is used, and > how they deal with the local apic state in that case. > I've seen the SMI IPI in code, but I think it is mostly used to deal with the case that the processor is sitting in an INIT and the broadcast SMI was ignored. Thanks, Andrew Fish >> Actually, I was *de*prioritizing it because things _more or less_ work >> without it, especially if the timeout is temporarily reduced. We >> probably agree that timeouts are evil in a virt setting, but even >> without this issue you can commit the ~70 patches that bring us to 99% >> of the way. >> >> Once the slate is clean and everybody is focused on the few remaining >> problems, we can tackle them---including broadcast SMIs. >> >> In fact, the rest of your email lists some more pressing problems than >> broadcast SMIs, which I'm quoting below to further remind other readers. :) > > Since it involves multiple projects, could it take longer to > coordinate a change? > > -Jordan > >> >> Paolo >> >>> - Solving the MP-related ExitBootServices() handler bug in CpuDxe. >>> Patches have been on the list for almost a week. While I've been >>> breaking my back testing and reviewing patches for others (not >>> just on edk2-devel, mind you), nobody has batted an eye about >>> that series. >>> >>> [edk2] [PATCH v2 0/4] UefiCpuPkg/CpuDxe: Fix ExitBootServices() >>> callback in the presence of SMIs >>> http://thread.gmane.org/gmane.comp.bios.edk2.devel/3518 >>> >>> Please review it, so that I can include it at the front of my >>> upcoming v4 SMM series. >>> >>> - Thirty (30) patches from the SMM series still need reviews. Once >>> all of the above is covered, I'll update the OvmfPkg/README >>> patch about the status, and post version 4. I wouldn't mind if >>> we could commit the series still in 2015, but I'm getting less >>> and less hopeful. > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
