On Sat, May 3, 2014 at 4:51 PM, Andy Lutomirski <[email protected]> wrote: > On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin <[email protected]> wrote: >> On 05/03/2014 04:24 AM, Steven Rostedt wrote: >>> On Fri, 02 May 2014 21:03:10 -0700 >>> "H. Peter Anvin" <[email protected]> wrote: >>> >>>> >>>> I'd really like to see a workload which would genuinely benefit before >>>> adding more complexity. Now... if we can determine that it doesn't harm >>>> anything and would solve the NMI nesting problem cleaner than the >>>> current solution, that would justify things, too... >>>> >>> >>> As I stated before. It doesn't solve the NMI nesting problem. It only >>> handles page faults. We would have to implement this for breakpoint >>> return paths too. Is that a plan as well? >>> >> >> I would assume we would do it for *ALL* the IRETs. There are only three >> IRETs in the kernel last I checked... > > I think we should carefully avoid doing it for returns from NMI, though :) > > If you want a realistic benchmark that will speed up, packet > forwarding might be a good place to look.
Hmm. I think my patch will blow up with EFI mixed mode if any EFI functions are called with interrupts enabled. It may also blow up with when suspending or doing other BIOS things like that. It should probably check the actual value of CS as opposed to just the CPL. I'm not sure what's happening with the alternate GDT in the EFI stuff. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
