search for: nmi

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. S...

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 exi...

...Upgraded to Debian testing and unstable with same results XEN 4.1 and 4.2. If you need more information, you can ask. How can be solved this bug? Thanks On Fri, Feb 08, 2013 at 03:08:08PM +0100, agya naila wrote: Hello all, Today Xen finally running on IBM blade server machine, try to add nmi=dom0 and find the Base Board Management Controller on bios configuration and disabled the ''reboot system on nmi'' attribute. This step won''t eliminate the nmi problem since I still found NMI error interrupt on my blade server log but xen would ignored and keep running. If...

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 re-use. The flow would be roughly like this upon entering the handler; build_pt_regs(); RSP = pt_regs->sp; if (RSP in VC_IST_s...

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 virtualized, thus all the interrupts coming from my HVM domain should be handled by the corresponding handler in dom0/(hypervisor?) whic...

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 N...

...ist(struct pt_regs *regs) > > +{ > > + if ((regs->sp & ~(EXCEPTION_STKSZ-1)) == > > + (_RET_IP_ & ~(EXCEPTION_STKSZ-1))) > > + die("IST stack recursion", regs, 0); > > +} > > Yes, this is a start, it doesn't cover the case where the NMI stack is > in-between, so I think you need to walk down regs->sp too. That shouldn't be possible with the current code, I think. > The dumpstack code already has some logic for this. Reliability of that depends on the unwinder, I wouldn't want the guess uwinder to OOPS me by acc...

...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 Error = 0x180002, which says to me that either there is something wrong with my network card which is triggering an NMI, or that the NMI triggers an error in that network adapter. The memory itself is ECC memory in a Compaq Proliant 1600, maybe i...

...n/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 after starting if started with NMIs disabled. This was discovered when experimenting with a debug keyhandler which deliberately created a reentrant NMI, causing stack corruption. Because of this discovered bug, and that the future changes to the NMI handling will make the kexec path more fragile, take the time now to bullet-proof...

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/ua...

...39;))) > rbind(foo, bar, fifi) Error in match.names(clabs, names(xi)) : names do not match previous names: v4 > ## Output looks fine. ## Third data frame is missing a column. > gaga <- data.frame(v1 = c('a', 'e'), v2 = c(7, 8)) > rbind(foo, bar, gaga) Error in paste(nmi[nii == 0], collapse = ", ") : object "nii" not found In addition: Warning message: longer object length is not a multiple of shorter object length in: clabs == nmi > This somewhat cryptic error message results because the second portion of the second if() test clause in...

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...

...'debug' library [so you could put this in your '.First' function]: Thanks to all who reported the problem Mark Bravington mark.bravington at csiro.au mvbutils:::assign.to.base( 'rbind.data.frame', function (..., deparse.level = 1) { match.names <- function(clabs, nmi) { if (all(clabs == nmi)) NULL else if (length(nmi) == length(clabs) && all(nii <- match(nmi, clabs, 0))) { m <- pmatch(nmi, clabs, 0) if (any(m == 0)) stop("names do not match previous names"...

...'s also nice about this, is that the host can see all the guest vcpu shared data, but each guest will only have access to their own, and only while running in dpl 0. These vcpu structures holds lots of data, from the hosts current gdt and idt pointer, to the cr3's (both guest and host), an NMI trampoline section, and lots more. Each guest also has a unique lguest_guest_info structure that stores generic data for the guest, but nothing that would be needed for running a specific VCPU. Loading the hypervisor: ---------------------- As opposed to compiling a hypervisor.c blob, we build...

...'s also nice about this, is that the host can see all the guest vcpu shared data, but each guest will only have access to their own, and only while running in dpl 0. These vcpu structures holds lots of data, from the hosts current gdt and idt pointer, to the cr3's (both guest and host), an NMI trampoline section, and lots more. Each guest also has a unique lguest_guest_info structure that stores generic data for the guest, but nothing that would be needed for running a specific VCPU. Loading the hypervisor: ---------------------- As opposed to compiling a hypervisor.c blob, we build...

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 at suse.de> --- arch/x86/i...

...hed, Slackware 10.0 was then installed on it. It currently runs stock kernel 2.6.9, udev 042, and the most recent hotplug from 2004-09-23. 3. Installed a digium-supplied X101P into the machine into a 32bit PCI slot. 4. Downloaded zaptel 1.0.3, compiled against kernel 2.6.9. Upon modprobe wcfxo, NMI's are immediately reported (syslog to follow). The instructions from README.udev were followed and parameters inserted into the rules file for udev. Problem occurs regardless of whether or not hotplug inserts the modules or the are manually inserted by me. Repeated modprobe -r wcfxo; modprob...

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 blocked even when an...

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 blocked even when an...

...e I spend too many days implementing > > something. > > OK, excuse my ignorance, but I'm not seeing how that IST shifting > nonsense would've helped in the first place. > > If I understand correctly the problem is: > > <#VC> > shift IST > <NMI> > ... does stuff > <#VC> # again, safe because the shift > > But what happens if you get the NMI before your IST adjustment? The v3 patchset implements an unconditional shift of the #VC IST entry in the NMI handler, before it can trigger a #VC exception. > Eith...