From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH 05/10] KVM: Merge MSI handling to kvm_set_irq Date: Wed, 7 Jan 2009 19:39:32 -0200 Message-ID: <20090107213932.GA16762@amt.cnet> References: <1231324966-22286-1-git-send-email-sheng@linux.intel.com> <1231324966-22286-6-git-send-email-sheng@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , kvm@vger.kernel.org To: Sheng Yang Return-path: Received: from mx2.redhat.com ([66.187.237.31]:60016 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751853AbZAGVjs (ORCPT ); Wed, 7 Jan 2009 16:39:48 -0500 Content-Disposition: inline In-Reply-To: <1231324966-22286-6-git-send-email-sheng@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 07, 2009 at 06:42:41PM +0800, Sheng Yang wrote: > Using kvm_set_irq to handle all interrupt injection. >=20 > Signed-off-by: Sheng Yang > --- > include/linux/kvm_host.h | 2 +- > virt/kvm/irq_comm.c | 79 ++++++++++++++++++++++++++++++++++++= +++++++-- > virt/kvm/kvm_main.c | 79 +++---------------------------------= ---------- > 3 files changed, 81 insertions(+), 79 deletions(-) >=20 > +static void gsi_dispatch(struct kvm *kvm, u32 gsi) > +{ > + int vcpu_id; > + struct kvm_vcpu *vcpu; > + struct kvm_ioapic *ioapic =3D ioapic_irqchip(kvm); > + struct kvm_gsi_route_entry *gsi_entry; > + int dest_id, vector, dest_mode, trig_mode, delivery_mode; > + u32 deliver_bitmask; > + > + BUG_ON(!ioapic); > + > + gsi_entry =3D kvm_find_gsi_route_entry(kvm, gsi); > + if (!gsi_entry) { > + printk(KERN_WARNING "kvm: fail to find correlated gsi entry\n"); > + return; > + } > + > +#ifdef CONFIG_X86 > + if (gsi_entry->type & KVM_GSI_ROUTE_MSI) { > + dest_id =3D (gsi_entry->msi.address_lo & MSI_ADDR_DEST_ID_MASK) > + >> MSI_ADDR_DEST_ID_SHIFT; > + vector =3D (gsi_entry->msi.data & MSI_DATA_VECTOR_MASK) > + >> MSI_DATA_VECTOR_SHIFT; > + dest_mode =3D test_bit(MSI_ADDR_DEST_MODE_SHIFT, > + (unsigned long *)&gsi_entry->msi.address_lo); > + trig_mode =3D test_bit(MSI_DATA_TRIGGER_SHIFT, > + (unsigned long *)&gsi_entry->msi.data); > + delivery_mode =3D test_bit(MSI_DATA_DELIVERY_MODE_SHIFT, > + (unsigned long *)&gsi_entry->msi.data); > + deliver_bitmask =3D kvm_ioapic_get_delivery_bitmask(ioapic, > + dest_id, dest_mode); > + /* IOAPIC delivery mode value is the same as MSI here */ > + switch (delivery_mode) { Sheng,=20 This code seems to ignore the RH bit (MSI_ADDR_REDIRECTION_SHIFT): 4.Destination mode (DM) =E2=80=94 This bit indicates whether the Destin= ation ID field should be interpreted as logical or physical APIC ID for delivery of the lowest priority interrupt. If RH is 1 and DM is 0, the Destination ID field is in physical destination mode and only the processor in the system that has the matching APIC ID is considered for delivery of that interrupt (this means no re-direction). If RH is 1 and DM is 1, the Destination ID Field is interpreted as in logical destination mode and the redirection is limited to only those processors that are part of the logical group of processors based on the processor=E2=80=99s logical APIC ID and the Destination ID field in the message. The logical group of processors consists of those identified by matching the 8-bit Destination ID with the logical destination identified by the Destination Format Register and the Logical Destination Register in each local APIC. Is that intentional?