Re: [Qemu-devel] [PATCH 1/2] seabios: Add Local APIC NMI Structure to ACPI MADT

2011-10-31 Thread Kenji Kaneshige 

(2011/10/28 21:48), Jun Koi wrote:

2011/10/28 Kenji Kaneshigekaneshige.ke...@jp.fujitsu.com:

Avi, Jan,

Could you comment on these patches?

Inject-NMI doesn't work on Windows guest without these patches.


sorry but i am really curious here: why Windows still works well even
if it desnt see the inject-NMI?
or there are still invisible side-effects that we are not awere of???


Without this patch, LVT LINT1 is not configured by Windows guest because
seabios MADT has no ACPI NMI structure which is used by Windows to setup
LVT. So NMI interrupt would not be sent to CPUs when NMI signal happens
on LINT1. But qemu/kvm inject-nmi feature had a bug that it sent NMI to
CPUs without emulating LAPIC LVT. As a result, NMI interrupt is sent to
all the CPUs even though LVT LINT1 is not configured. This is why
inject-nmi behaves as if it works well on Windows guest.

Regards,
Kenji Kaneshige

Re: [Qemu-devel] [PATCH 1/2] seabios: Add Local APIC NMI Structure to ACPI MADT

2011-10-28 Thread Kenji Kaneshige 
Avi, Jan,

Could you comment on these patches?

Inject-NMI doesn't work on Windows guest without these patches. Windows seems
to setup LVT based on ACPI NMI structure information which is missing in current
seabios. LVT LINT1 are never unmasked by Windows guest without the patches.

Those patches were already reviewed by seabios people, but need ack from 
qemu/kvm
side.

Regards,
Kenji Kaneshige



(2011/10/10 15:06), Lai Jiangshan wrote:
 From: Kenji Kaneshigekaneshige.ke...@jp.fujitsu.com
 
 ACPI NMI Structure describes LINT pin (LINT0 or LINT1) information to
 which NMI is connected, and it is needed by OS to initialize local APIC.
 
 Signed-off-by: Kenji Kaneshigekaneshige.ke...@jp.fujitsu.com
 Reviewed-by: Lai Jiangshanla...@cn.fujitsu.com
 ---
   src/acpi.c |   22 --
   1 file changed, 20 insertions(+), 2 deletions(-)
 
 Index: seabios/src/acpi.c
 ===
 --- seabios.orig/src/acpi.c
 +++ seabios/src/acpi.c
 @@ -134,6 +134,14 @@ struct madt_intsrcovr {
   u16 flags;
   } PACKED;
 
 +struct madt_local_nmi {
 +ACPI_SUB_HEADER_DEF
 +u8  processor_id;   /* ACPI processor id */
 +u16 flags;  /* MPS INTI flags */
 +u8  lint;   /* Local APIC LINT# */
 +} PACKED;
 +
 +
   /*
* ACPI 2.0 Generic Address Space definition.
*/
 @@ -288,7 +296,9 @@ build_madt(void)
   int madt_size = (sizeof(struct multiple_apic_table)
+ sizeof(struct madt_processor_apic) * MaxCountCPUs
+ sizeof(struct madt_io_apic)
 - + sizeof(struct madt_intsrcovr) * 16);
 + + sizeof(struct madt_intsrcovr) * 16
 + + sizeof(struct madt_local_nmi));
 +
   struct multiple_apic_table *madt = malloc_high(madt_size);
   if (!madt) {
   warn_noalloc();
 @@ -340,7 +350,15 @@ build_madt(void)
   intsrcovr++;
   }
 
 -build_header((void*)madt, APIC_SIGNATURE, (void*)intsrcovr - 
 (void*)madt, 1);
 +struct madt_local_nmi *local_nmi = (void*)intsrcovr;
 +local_nmi-type = APIC_LOCAL_NMI;
 +local_nmi-length   = sizeof(*local_nmi);
 +local_nmi-processor_id = 0xff; /* all processors */
 +local_nmi-flags= 0;
 +local_nmi-lint = 1; /* LINT1 */
 +local_nmi++;
 +
 +build_header((void*)madt, APIC_SIGNATURE, (void*)local_nmi - 
 (void*)madt, 1);
   return madt;
   }
 
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [PATCH] kernel/kvm: fix improper nmi emulation

2011-10-12 Thread Kenji Kaneshige 
(2011/10/10 19:26), Avi Kivity wrote:
 On 10/10/2011 08:06 AM, Lai Jiangshan wrote:
 From: Kenji Kaneshigekaneshige.ke...@jp.fujitsu.com

 Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
 button event happens. This doesn't properly emulate real hardware on
 which NMI button event triggers LINT1. Because of this, NMI is sent to
 the processor even when LINT1 is maskied in LVT. For example, this
 causes the problem that kdump initiated by NMI sometimes doesn't work
 on KVM, because kdump assumes NMI is masked on CPUs other than CPU0.

 With this patch, KVM_NMI ioctl is handled as follows.

 - When in-kernel irqchip is enabled, KVM_NMI ioctl is handled as a
 request of triggering LINT1 on the processor. LINT1 is emulated in
 in-kernel irqchip.

 - When in-kernel irqchip is disabled, KVM_NMI ioctl is handled as a
 request of injecting NMI to the processor. This assumes LINT1 is
 already emulated in userland.
 
 Please add a KVM_NMI section to Documentation/virtual/kvm/api.txt.
 

 -static int kvm_vcpu_ioctl_nmi(struct kvm_vcpu *vcpu)
 -{
 - kvm_inject_nmi(vcpu);
 -
 - return 0;
 -}
 -
 static int vcpu_ioctl_tpr_access_reporting(struct kvm_vcpu *vcpu,
 struct kvm_tpr_access_ctl *tac)
 {
 @@ -3038,9 +3031,10 @@ long kvm_arch_vcpu_ioctl(struct file *fi
 break;
 }
 case KVM_NMI: {
 - r = kvm_vcpu_ioctl_nmi(vcpu);
 - if (r)
 - goto out;
 + if (irqchip_in_kernel(vcpu-kvm))
 + kvm_apic_lint1_deliver(vcpu);
 + else
 + kvm_inject_nmi(vcpu);
 r = 0;
 break;
 }
 
 Why did you drop kvm_vcpu_ioctl_nmi()?
 
 Please add (and document) a KVM_CAP flag that lets userspace know the new 
 behaviour is supported.
 

Sorry for the delayed responding.

I don't understand why new KVM_CAP flag is needed.

I think the old behavior was clearly a bug, and new behavior is not a new
capability. Furthermore, the kvm patch and the qemu patch in this patchset
can be applied independently. If only the kvm patch is applied, NMI bug in
kernel irq is fixed and qemu NMI behavior is not changed. If the only the
qemu patch is applied, qemu NMI bug is fixed and the NMI behavior in kernel
irq is not changed.

Regards,
Kenji Kaneshige

Re: [Qemu-devel] [PATCH 1/1 V2] kernel/kvm: fix improper nmi emulation

2011-10-12 Thread Kenji Kaneshige 
(2011/10/12 2:00), Lai Jiangshan wrote:
 From: Kenji Kaneshigekaneshige.ke...@jp.fujitsu.com
 
 Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
 button event happens. This doesn't properly emulate real hardware on
 which NMI button event triggers LINT1. Because of this, NMI is sent to
 the processor even when LINT1 is maskied in LVT. For example, this
 causes the problem that kdump initiated by NMI sometimes doesn't work
 on KVM, because kdump assumes NMI is masked on CPUs other than CPU0.
 
 With this patch, KVM_NMI ioctl is handled as follows.
 
 - When in-kernel irqchip is enabled, KVM_NMI ioctl is handled as a
request of triggering LINT1 on the processor. LINT1 is emulated in
in-kernel irqchip.
 
 - When in-kernel irqchip is disabled, KVM_NMI ioctl is handled as a
request of injecting NMI to the processor. This assumes LINT1 is
already emulated in userland.
 
 (laijs) Changed from v1:
 Add KVM_NMI API document
 Add KVM_CAP_USER_NMI
 
 Signed-off-by: Kenji Kaneshigekaneshige.ke...@jp.fujitsu.com
 Tested-by: Lai Jiangshanla...@cn.fujitsu.com
 ---
   Documentation/virtual/kvm/api.txt |   20 
   arch/x86/kvm/irq.h|1 +
   arch/x86/kvm/lapic.c  |7 +++
   arch/x86/kvm/x86.c|   12 
   include/linux/kvm.h   |3 +++
   5 files changed, 43 insertions(+), 0 deletions(-)
 
 diff --git a/Documentation/virtual/kvm/api.txt 
 b/Documentation/virtual/kvm/api.txt
 index b0e4b9c..5c24cc3 100644
 --- a/Documentation/virtual/kvm/api.txt
 +++ b/Documentation/virtual/kvm/api.txt
 @@ -1430,6 +1430,26 @@ is supported; 2 if the processor requires all virtual 
 machines to have
   an RMA, or 1 if the processor can use an RMA but doesn't require it,
   because it supports the Virtual RMA (VRMA) facility.
 
 +4.64 KVM_NMI
 +
 +Capability: KVM_CAP_USER_NMI
 +Architectures: x86
 +Type: vcpu ioctl
 +Parameters: none
 +Returns: 0 on success, -1 on error
 +
 +This ioctl injects NMI to the vcpu.
 +
 +If with capability KVM_CAP_LAPIC_NMI, KVM_NMI ioctl is handled as follows:
 +
 + - When in-kernel irqchip is enabled, KVM_NMI ioctl is handled as a
 +   request of triggering LINT1 on the processor. LINT1 is emulated in
 +   in-kernel lapic irqchip.
 +
 + - When in-kernel irqchip is disabled, KVM_NMI ioctl is handled as a
 +   request of injecting NMI to the processor. This assumes LINT1 is
 +   already emulated in userland lapic.
 +
   5. The kvm_run structure
 
   Application code obtains a pointer to the kvm_run structure by
 diff --git a/arch/x86/kvm/irq.h b/arch/x86/kvm/irq.h
 index 53e2d08..0c96315 100644
 --- a/arch/x86/kvm/irq.h
 +++ b/arch/x86/kvm/irq.h
 @@ -95,6 +95,7 @@ void kvm_pic_reset(struct kvm_kpic_state *s);
   void kvm_inject_pending_timer_irqs(struct kvm_vcpu *vcpu);
   void kvm_inject_apic_timer_irqs(struct kvm_vcpu *vcpu);
   void kvm_apic_nmi_wd_deliver(struct kvm_vcpu *vcpu);
 +void kvm_apic_lint1_deliver(struct kvm_vcpu *vcpu);
   void __kvm_migrate_apic_timer(struct kvm_vcpu *vcpu);
   void __kvm_migrate_pit_timer(struct kvm_vcpu *vcpu);
   void __kvm_migrate_timers(struct kvm_vcpu *vcpu);
 diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
 index 57dcbd4..87fe36a 100644
 --- a/arch/x86/kvm/lapic.c
 +++ b/arch/x86/kvm/lapic.c
 @@ -1039,6 +1039,13 @@ void kvm_apic_nmi_wd_deliver(struct kvm_vcpu *vcpu)
   kvm_apic_local_deliver(apic, APIC_LVT0);
   }
 
 +void kvm_apic_lint1_deliver(struct kvm_vcpu *vcpu)
 +{
 + struct kvm_lapic *apic = vcpu-arch.apic;
 +
 + kvm_apic_local_deliver(apic, APIC_LVT1);
 +}
 +
   static struct kvm_timer_ops lapic_timer_ops = {
   .is_periodic = lapic_is_periodic,
   };
 diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
 index 84a28ea..6862ef7 100644
 --- a/arch/x86/kvm/x86.c
 +++ b/arch/x86/kvm/x86.c
 @@ -2729,12 +2729,24 @@ static int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu 
 *vcpu,
   return 0;
   }
 
 +#ifdef KVM_CAP_LAPIC_NMI
 +static int kvm_vcpu_ioctl_nmi(struct kvm_vcpu *vcpu)
 +{
 + if (irqchip_in_kernel(vcpu-kvm))
 + kvm_apic_lint1_deliver(vcpu);
 + else
 + kvm_inject_nmi(vcpu);
 +
 + return 0;
 +}
 +#else
   static int kvm_vcpu_ioctl_nmi(struct kvm_vcpu *vcpu)
   {
   kvm_inject_nmi(vcpu);
 
   return 0;
   }
 +#endif

I don't think we need to keep old kvm_vcpu_ioctl_nmi() behavior because
it's clearly a bug.

Regards,
Kenji Kaneshige