From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sheng Yang Subject: Re: [PATCH 05/10] KVM: Merge MSI handling to kvm_set_irq Date: Thu, 8 Jan 2009 17:24:02 +0800 Message-ID: <200901081724.03585.sheng@linux.intel.com> References: <1231324966-22286-1-git-send-email-sheng@linux.intel.com> <1231324966-22286-6-git-send-email-sheng@linux.intel.com> <20090107213932.GA16762@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from mga09.intel.com ([134.134.136.24]:64730 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751068AbZAHJYI convert rfc822-to-8bit (ORCPT ); Thu, 8 Jan 2009 04:24:08 -0500 In-Reply-To: <20090107213932.GA16762@amt.cnet> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Thursday 08 January 2009 05:39:32 Marcelo Tosatti wrote: > On Wed, Jan 07, 2009 at 06:42:41PM +0800, Sheng Yang wrote: > > Using kvm_set_irq to handle all interrupt injection. > > > > Signed-off-by: Sheng Yang > > --- > > include/linux/kvm_host.h | 2 +- > > virt/kvm/irq_comm.c | 79 > > +++++++++++++++++++++++++++++++++++++++++++-- virt/kvm/kvm_main.c = |=20 > > 79 +++------------------------------------------- 3 files changed,= 81 > > insertions(+), 79 deletions(-) > > > > +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, > > This code seems to ignore the RH bit (MSI_ADDR_REDIRECTION_SHIFT): > > 4.Destination mode (DM) =E2=80=94 This bit indicates whether the Dest= ination > 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 fie= ld > 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? Um... Partly... For RH bits is almost always 1... OK, I would add anoth= er=20 patch for this bit later. --=20 regards Yang, Sheng