On 11/26/14 20:28, Jordan Justen wrote: > On 2014-11-13 17:34:59, Chen, Fan wrote: >> On Thu, 2014-11-13 at 10:42 -0800, Jordan Justen wrote: >>> On 2014-11-06 17:23:01, Fan, Jeff wrote: >>>> Chen, >>>> >>>> Thanks your contribution. I will check-in your patch if there is no >>>> further comments from other guys. >>>> >>>> Reviewed-by: Jeff Fan <jeff....@intel.com> >>> >>> Chen, >>> >>> I committed your series (r16345-r16371) for Jeff (to preserve the >>> separate patches). >>> >>> Thanks for all your work on this! >>> >>> Let me know if you are interested in working on some follow up MP >>> tasks. (I have 2 ideas. :) >> Of course, I hope to help improve the MP. > > Another idea I had (besides the AP sleep task) is to synchronize the > APs MTRRs with the BSP. > > I think this should be fairly simple. Probably in a 'Ready to Boot' or > 'Exit Boot Services' callback, the BSP could read the MTRRs, and then > send the APs off on a task to set their MTRRs using the buffer where > then BSP read its MTRRs. > > I think MtrrLib should make this fairly easy. > > If you boot Linux SMP today the dmesg output will note the issue: > [ 0.051370] mtrr: your CPUs had inconsistent fixed MTRR settings > [ 0.051371] mtrr: your CPUs had inconsistent variable MTRR settings > [ 0.051371] mtrr: your CPUs had inconsistent MTRRdefType settings > [ 0.051372] mtrr: probably your BIOS does not setup all CPUs. > [ 0.051373] mtrr: corrected configuration.
I think such MTRR setup should be done early (as soon as all APs are booted), and, it is a delicate dance between the individual processors. See 11.11.8 MTRR Considerations in MP Systems in the Intel SDM. (A few years ago I fixed a *nasty* bug in the RHEL-5 Xen hypervisor where the spinlock primitive couldn't maintain a waiter count higher than 127 (it was a signed char, basically). As soon as there were more than 127 contenders, the rendezvous/barrier described as step 3 in the above section: 3. Wait for all processors to reach this point. was busted, and processors entered and exited the critical region in an uncontrolled manner. The results weren't nice; we had hangs and weird performance degradations. It's RHBZ#713123 -- sorry, the BZ is not public.) This is arguably more important on physical hardware than on qemu/KVM, but as I gather UefiCpuPkg is mainly used on physical hardware. Laszlo ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
