[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SA1PR11MB67342EF55449288F93C3A78EA8819@SA1PR11MB6734.namprd11.prod.outlook.com>
Date: Tue, 21 Mar 2023 00:13:34 +0000
From: "Li, Xin3" <xin3.li@...el.com>
To: Peter Zijlstra <peterz@...radead.org>,
"H. Peter Anvin" <hpa@...or.com>
CC: Lai Jiangshan <jiangshanlai@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>,
"bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
"Christopherson,, Sean" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>
Subject: RE: [PATCH v5 22/34] x86/fred: FRED initialization code
> > The purpose of separate stacks for NMI, #DB and #MC *in the kernel*
> > (remember that user space faults are always taken on stack level 0) is
> > to avoid overflowing the kernel stack. #DB in the kernel would imply
> > the use of a kernel debugger.
>
> Perf (and through it bpf) also has access to #DB. They can set
> breakpoints on kernel instructions/memory just fine provided permission
> etc.
So they are still *kernel* debuggers :)
Powered by blists - more mailing lists