search for: nmy

Currently, Xen does not support injecting an NMI to HVM guest OS. Adding this feature is necessary for those softwares which depend on NMI to function correctly, such as KDB and oprofile. The attached patch allows NMI to be injected to guest OS in NMIP capable platforms. It also enables to queue an NMI and then inject it as soon as possible. Signed-off-by: Haitao Shan

The self_nmi() code cause''s an NMI to be triggered by sending an APIC message to the local processor. However, NMIs are blocked by the VMEXIT, until the next iret or VMENTER. Volume 3 Chapter 27 Section 1 of the Intel SDM states: An NMI causes subsequent NMIs to be blocked, but only after the VM exit completes. As a result, as soon as the VMENTER happens, an immediate VMEXIT happens

Hello, I have the same error, server is auto rebooted during every boot with kernel XEN, HS20 with Debian Wheezy and XEN hang on and AMM managment show same errors described in previous mails. With Debian wheezy wit non-xen kernel boots correcte, it seems that problems is with xen kernel Same Server HS20 with Debian Lenny+ XEN 3.2 or Debian Squeeze+XEN 4.0 working perfect Upgraded to Debian

Hi Andy, On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: > 1. Use IST for #VC and deal with all the mess that entails. With the removal of IST shifting I wonder what you would suggest on how to best implement an NMI-safe IST handler with nesting support. My current plan is to implement an IST handler which switches itself off the IST stack as soon as possible, freeing it for

I have an Intel e1000e NIC which I put into passthrough for an HVM domain under Xen 4.2. All the corresponding hardware protections are enabled on my system (DMA + Interrupt remapping), however, once in a while I get a SERR NMI in dom0 (NMI - PCI sys error (SERR) in xl dmesg). I am wondering about its exact reason. I am thinking in the following way: [+] Under Intel VT-x, interrupts are

I have just starting auditing the NMI path and found that the oprofile code calls into a fair amount of common code. So far, down the first leg of the call graph, I have found several ASSERT()s, a BUG() and many {rd,wr}msr()s. Given that these are common code, and sensible in their places, removing them for the sake of being on the NMI path seems silly. As an alternative, I suggest that we make

On Tue, Jun 23, 2020 at 04:59:14PM +0200, Joerg Roedel wrote: > On Tue, Jun 23, 2020 at 04:53:44PM +0200, Peter Zijlstra wrote: > > +noinstr void idtentry_validate_ist(struct pt_regs *regs) > > +{ > > + if ((regs->sp & ~(EXCEPTION_STKSZ-1)) == > > + (_RET_IP_ & ~(EXCEPTION_STKSZ-1))) > > + die("IST stack recursion", regs, 0); > > +}

I have just noticed this message in my kernel logs, reporting the possibility of an error with my memory. This would go a long way towards explaining the problems i''ve been having. This particular error is occuring when i''m not running xen so is obviously not something brought on by xen itself. The strange thing is that the NMI error is always followed by the TLAN: eth0: Adaptor

xen/arch/x86/crash.c | 116 ++++++++++++++++++++++++++++++++++----- xen/arch/x86/machine_kexec.c | 19 ++++++ xen/arch/x86/x86_64/entry.S | 34 +++++++++++ xen/include/asm-x86/desc.h | 45 +++++++++++++++ xen/include/asm-x86/processor.h | 4 + 5 files changed, 203 insertions(+), 15 deletions(-) Experimentally, certain crash kernels will triple fault very early

From: Joerg Roedel <jroedel at suse.de> Keep NMI state in SEV-ES code so the kernel can re-enable NMIs for the vCPU when it reaches IRET. Signed-off-by: Joerg Roedel <jroedel at suse.de> --- arch/x86/entry/entry_64.S | 48 +++++++++++++++++++++++++++++++++ arch/x86/include/asm/sev-es.h | 27 +++++++++++++++++++ arch/x86/include/uapi/asm/svm.h | 1 + arch/x86/kernel/nmi.c

When attempting to merge 3 data frames, one of which has fewer columns than the others, rbind.data.frame correctly refuses to perform the bind. However, the error message given is a bit obscure due to a logical bug in the match.names() internal function to rbind.data.frame. Illustration: ## Three data frames with same column variable names: > foo <- data.frame(v1 = c('a',

From: Joerg Roedel <jroedel at suse.de> When an NMI hits in the #VC handler entry code before it switched to another stack, any subsequent #VC exception in the NMI code-path will overwrite the interrupted #VC handlers stack. Make sure this doesn't happen by explicitly adjusting the #VC IST entry in the NMI handler for the time in can cause #VC exceptions. Signed-off-by: Joerg Roedel

A number of users have spotted a terminal problem with the 'debug' package under R2.4.0, along the lines of > mtrace(x) > x() Error in attr(value, "row.names") <- rlabs : row names must be 'character' or 'integer', not 'double' This arose from a bug in 'rbind.data.frame' in R2.4.0 itself. The bug is fixed in R2.4.0 patched, so the

Hi all! Lately, Glauber and I have been working on getting both paravirt_ops and lguest running on the x86_64. I already pushed the x86_64 patches and as promised, I'm pushing now the lguest64 patches. This patches are greatly influenced by Rusty Russell, and we tried to stay somewhat consistent with his work on the i386. But there are some major differences that we had to over come.

Hi all! Lately, Glauber and I have been working on getting both paravirt_ops and lguest running on the x86_64. I already pushed the x86_64 patches and as promised, I'm pushing now the lguest64 patches. This patches are greatly influenced by Rusty Russell, and we tried to stay somewhat consistent with his work on the i386. But there are some major differences that we had to over come.

From: Joerg Roedel <jroedel at suse.de> When running under SEV-ES the kernel has to tell the hypervisor when to open the NMI window again after an NMI was injected. This is done with an NMI-complete message to the hypervisor. Add code to the kernels NMI handler to send this message right at the beginning of do_nmi(). This always allows nesting NMIs. Signed-off-by: Joerg Roedel <jroedel

I have read thru what other users have tried in this list when they have experienced seemingly similar issues to what I have, without success. I suspect there might be an issue regarding both the X100P and TDM04b cards being used in an Intel SE7525GP2 motherboard, as I had to even wait for a BIOS update from Intel in order to utilize my 3ware 9500 SATA raid controller on it (3ware Kb -->

On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > Oh gawd; so instead of improving the whole NMI situation, AMD went and > made it worse still ?!? Well, depends on how you want to see it. Under SEV-ES an IRET will not re-open the NMI window, but the guest has to tell the hypervisor explicitly when it is ready to receive new NMIs via the NMI_COMPLETE message. NMIs stay

On Tue, Feb 11, 2020 at 03:50:08PM +0100, Peter Zijlstra wrote: > Oh gawd; so instead of improving the whole NMI situation, AMD went and > made it worse still ?!? Well, depends on how you want to see it. Under SEV-ES an IRET will not re-open the NMI window, but the guest has to tell the hypervisor explicitly when it is ready to receive new NMIs via the NMI_COMPLETE message. NMIs stay

Hi Peter, On Tue, Jun 23, 2020 at 12:45:59PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 11:45:19AM +0200, Joerg Roedel wrote: > > Or maybe you have a better idea how to implement this, so I'd like to > > hear your opinion first before I spend too many days implementing > > something. > > OK, excuse my ignorance, but I'm not seeing how that IST