On 09/26/2011 04:21 PM, Avi Kivity wrote:
On 09/25/2011 08:22 PM, Jan Kiszka wrote:
On 2011-09-25 16:07, Avi Kivity wrote:
On 09/23/2011 12:31 PM, Lai Jiangshan wrote:
Moreover: wrong indention.
You know that this won't work for qemu-kvm with in-kernel irqchip? You may want to provide a patch for that tree, emulating the unavailable LINT1 injection via testing the APIC configration and then raising an NMI as before if it is accepted.
It works in my box but the NMI is not injected through the in-kernel irqchip, I will implement it as you suggested.
Somewhat hacky; isn't it better to test LINT1 in the kernel (and redefine the KVM_NMI ioctl as "toggle LINT1")?
KVM_NMI is required for user space IRQ chip as well.
We could define KVM_NMI as edging the core NMI input if !irqchip_in_kernel, and toggling LINT1 otherwise. Hardly nice though.
The current KVM_NMI with irqchip_in_kernel is not meaningful, since it doesn't obey the rules of any NMI source.
Introducing some KVM_SET_LINT1 is an option though. But emulating it for the NMI button on older kernels sounds worthwhile nevertheless.
Perhaps this is the best option to avoid confusion.
(add cc: seabios@seabios.org)
Hi, All,
When I was implementing KVM_SET_LINT1, I found many places of the qemu-kvm code need to be changed, and it became nasty.
And as Avi said KVM_NMI with irqchip_in_kernel is not meaningful, so KVM_NMI is not used anymore when KVM_SET_LINT1 & irqchip_in_kernel, it is dead.
Now, we redefine KVM_NMI with more proper meaning, when irqchip_in_kernel, it is kernel/kvm's responsibility to simulate the NMI-injection and set LINT1. When !irqchip_in_kernel, it is userspace's responsibility.
It results more real simulation and results simpler code, and it don't need to add new ioctl interface, and it can make use of existing KVM_NMI.
Thanks, Lai