search for: instrumentation_begin

...in()/end(). > > > + * Otherwise the #VC handler could be raised recursivly. > > > + */ > > > + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { > > > + vc_handle_trap_db(regs); > > > + return; > > > + } > > > + > > > instrumentation_begin(); > > > > Wait what?! That makes no sense what so ever. > > Then my understanding of intrumentation_begin/end() is wrong, I thought > that the kernel will forbid setting breakpoints before > instrumentation_begin(), which is necessary here because a break-point > in th...

...in()/end(). > > > + * Otherwise the #VC handler could be raised recursivly. > > > + */ > > > + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { > > > + vc_handle_trap_db(regs); > > > + return; > > > + } > > > + > > > instrumentation_begin(); > > > > Wait what?! That makes no sense what so ever. > > Then my understanding of intrumentation_begin/end() is wrong, I thought > that the kernel will forbid setting breakpoints before > instrumentation_begin(), which is necessary here because a break-point > in th...

...t; + * #DB is special and needs to be handled outside of the intrumentation_begin()/end(). > + * Otherwise the #VC handler could be raised recursivly. > + */ > + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { > + vc_handle_trap_db(regs); > + return; > + } > + > instrumentation_begin(); Wait what?! That makes no sense what so ever.

...t; + * #DB is special and needs to be handled outside of the intrumentation_begin()/end(). > + * Otherwise the #VC handler could be raised recursivly. > + */ > + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { > + vc_handle_trap_db(regs); > + return; > + } > + > instrumentation_begin(); Wait what?! That makes no sense what so ever.

On Wed, Jul 15, 2020 at 11:51:36AM +0200, Peter Zijlstra wrote: > On Wed, Jul 15, 2020 at 11:13:37AM +0200, Joerg Roedel wrote: > > Then my understanding of intrumentation_begin/end() is wrong, I thought > > that the kernel will forbid setting breakpoints before > > instrumentation_begin(), which is necessary here because a break-point > > in the #VC handler might cause recursive #VC-exceptions when #DB is > > intercepted. > > Maybe you can elaborate on why this makes no sense? > > Kernel avoids breakpoints in any noinstr text, irrespective of > instrume...

...Jul 15, 2020 at 11:51:36AM +0200, Peter Zijlstra wrote: > > On Wed, Jul 15, 2020 at 11:13:37AM +0200, Joerg Roedel wrote: > > > Then my understanding of intrumentation_begin/end() is wrong, I thought > > > that the kernel will forbid setting breakpoints before > > > instrumentation_begin(), which is necessary here because a break-point > > > in the #VC handler might cause recursive #VC-exceptions when #DB is > > > intercepted. > > > Maybe you can elaborate on why this makes no sense? > > > > Kernel avoids breakpoints in any noinstr text, irre...

From: Joerg Roedel <jroedel at suse.de> Handle #VC exceptions caused by #DB exceptions in the guest. Those must be handled outside of instrumentation_begin()/end() so that the handler will not be raised recursivly. Handle them by calling the kernels debug exception handler. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/kernel/sev-es.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/arch/x86/kernel/sev-e...

...andled outside of the intrumentation_begin()/end(). > > + * Otherwise the #VC handler could be raised recursivly. > > + */ > > + if (error_code == SVM_EXIT_EXCP_BASE + X86_TRAP_DB) { > > + vc_handle_trap_db(regs); > > + return; > > + } > > + > > instrumentation_begin(); > > Wait what?! That makes no sense what so ever. Then my understanding of intrumentation_begin/end() is wrong, I thought that the kernel will forbid setting breakpoints before instrumentation_begin(), which is necessary here because a break-point in the #VC handler might cause recursive...

From: Joerg Roedel <jroedel at suse.de> Handle #VC exceptions caused by #DB exceptions in the guest. Those must be handled outside of instrumentation_begin()/end() so that the handler will not be raised recursivly. Handle them by calling the kernels debug exception handler. Signed-off-by: Joerg Roedel <jroedel at suse.de> Link: https://lore.kernel.org/r/20200724160336.5435-64-joro at 8bytes.org --- arch/x86/kernel/sev-es.c | 17 ++++++++++++++...

From: Joerg Roedel <jroedel at suse.de> Hi, here is the fourth version of the SEV-ES Guest Support patches. I addressed the review comments sent to me for the previous version and rebased the code v5.8-rc5. The biggest change in this version is the IST handling code for the #VC handler. I adapted the entry code for the #VC handler to the big pile of entry code changes merged into

From: Joerg Roedel <jroedel at suse.de> Hi, here is the fourth version of the SEV-ES Guest Support patches. I addressed the review comments sent to me for the previous version and rebased the code v5.8-rc5. The biggest change in this version is the IST handling code for the #VC handler. I adapted the entry code for the #VC handler to the big pile of entry code changes merged into

From: Joerg Roedel <jroedel at suse.de> Hi, here is the new version of the SEV-ES client enabling patch-set. It is based on the latest tip/master branch and contains the necessary changes. In particular those ar: - Enabling CR4.FSGSBASE early on supported processors so that early #VC exceptions on APs can be handled. - Add another patch (patch 1) to fix a KVM frame-size build

From: Joerg Roedel <jroedel at suse.de> Hi, here is a rebased version of the latest SEV-ES patches. They are now based on latest tip/master instead of upstream Linux and include the necessary changes. Changes to v4 are in particular: - Moved early IDT setup code to idt.c, because the idt_descr and the idt_table are now static - This required to make stack protector work early (or

From: Joerg Roedel <jroedel at suse.de> Hi, here is a new version of the SEV-ES Guest Support patches for x86. The previous versions can be found as a linked list starting here: https://lore.kernel.org/lkml/20200824085511.7553-1-joro at 8bytes.org/ I updated the patch-set based on ther review comments I got and the discussions around it. Another important change is that the early IDT

From: Joerg Roedel <jroedel at suse.de> Hi, here is a new version of the SEV-ES Guest Support patches for x86. The previous versions can be found as a linked list starting here: https://lore.kernel.org/lkml/20200824085511.7553-1-joro at 8bytes.org/ I updated the patch-set based on ther review comments I got and the discussions around it. Another important change is that the early IDT