On 2014-11-26 12:07:53, Laszlo Ersek wrote: > On 11/26/14 20:28, Jordan Justen wrote: > > On 2014-11-13 17:34:59, Chen, Fan wrote: > >> 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),
Seems reasonable. But, MTRRs can be changed after this phase, so they may need to be sync'd later as well. I'm not sure there is a great way to ensure that they are always sync'd, so maybe AP startup plus just before booting the OS would be a good start. > 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. I don't think this is the case. (Well, UefiCpuPkg/CpuDxe, anyway.) It is not nearly feature complete enough for that. I don't think there is any reason that this couldn't be improved over time, but I'm not sure how motivated others are to make this happen. Obviously lack of MP support in the open source stack was a big missing feature, but I expect there are still a lot of other little things missing. -Jordan ------------------------------------------------------------------------------ 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
