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(a)seabios.org)
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.