On Wed, Jul 29, 2020 at 08:40:57PM +0000, Fenghua Yu wrote: > On Wed, Jul 29, 2020 at 10:49:47AM +0200, pet...@infradead.org wrote: > > On Fri, Jul 17, 2020 at 02:35:00PM -0700, Fenghua Yu wrote: > > > > > #DB for bus lock detect fixes all issues in #AC for split lock detect: > > > 1) It's architectural ... just need to look at one CPUID bit to know it > > > exists > > > 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread. > > > So each process or guest can have different behavior. > > > > And it generates a whole new problem due to #DB being an IST, and
> > we very much rely on #DB never recursing, which we carefully crafted by > > disallowing hardare breakpoints on noinstr code and clearing DR7 early. > > > > But now it can... please keep the pieces. > > Can we disable Bus Lock Detection before handle it and re-enable it > after handle it? Will that resolve the recursion issue? Because WRMSR is cheap, right? You have to unconditionally {dis,en}able it on #DB entry/exit. Not only when it's a DR_BUS_LOCK, _always_. Then maybe. I'm too tired to think through the IST mess. IST's suck, they're horrible crap. Suppose we get a #DB, then we get an NMI right before it does WRMSR, so BUS_LOCK is still on, then the NMI does a dodgy LOCK op, we die. So that means, you get to disable it on every NMI-like exception too, but we happen to care about performance for those, you loose. Also, what happens if you have a hardware watchpoint on the instruction that causes DR_BUS_LOCK? Does that work as expected?