On Fri, Sep 13, 2019 at 10:14:15AM -0500, Steve Wahl wrote: > On Thu, Sep 12, 2019 at 01:19:17PM +0300, Kirill A. Shutemov wrote: > > On Wed, Sep 11, 2019 at 03:08:35PM -0500, Steve Wahl wrote: > > > Thank you for your time looking into this with me! > > > > With all this explanation the original patch looks sane to me. > > > > But I would like to see more information from this thread in the commit > > message and some comments in the code on why it's crucial not to map more > > than needed. > > I am working on this. > > > I think we also need to make it clear that this is workaround for a broken > > hardware: speculative execution must not trigger a halt. > > I think the word broken is a bit loaded here. According to the UEFI > spec (version 2.8, page 167), "Regions that are backed by the physical > hardware, but are not supposed to be accessed by the OS, must be > returned as EfiReservedMemoryType." Our interpretation is that > includes speculative accesses.
+Dave. I don't think it is. Speculative access is done by hardware, not OS. BTW, isn't it a BIOS issue? I believe it should have a way to hide a range of physical address space from OS or force a caching mode on to exclude it from speculative execution. Like setup MTRRs or something. > I'd lean more toward "tightening of adherence to the spec required by > some particular hardware." Does that work for you? Not really, no. I still believe it's issue of the platform, not OS. -- Kirill A. Shutemov
