linux-kernel - RE: [PATCH v3 02/18] iommu/vt-d: Add DEV-MSI support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <c53ae7b0d2304bd9b49f305d4e0e9645@intel.com>
Date:   Tue, 20 Oct 2020 21:42:37 +0000
From:   "Dey, Megha" <megha.dey@...el.com>
To:     David Woodhouse <dwmw2@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Jiang, Dave" <dave.jiang@...el.com>,
        "vkoul@...nel.org" <vkoul@...nel.org>,
        "maz@...nel.org" <maz@...nel.org>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "alex.williamson@...hat.com" <alex.williamson@...hat.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        "Raj, Ashok" <ashok.raj@...el.com>,
        "jgg@...lanox.com" <jgg@...lanox.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>, "Lu, Baolu" <baolu.lu@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        "Kumar, Sanjay K" <sanjay.k.kumar@...el.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "Lin, Jing" <jing.lin@...el.com>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "kwankhede@...dia.com" <kwankhede@...dia.com>,
        "eric.auger@...hat.com" <eric.auger@...hat.com>,
        "parav@...lanox.com" <parav@...lanox.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "netanelg@...lanox.com" <netanelg@...lanox.com>,
        "shahafs@...lanox.com" <shahafs@...lanox.com>,
        "yan.y.zhao@...ux.intel.com" <yan.y.zhao@...ux.intel.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "Ortiz, Samuel" <samuel.ortiz@...el.com>,
        "Hossain, Mona" <mona.hossain@...el.com>
CC:     "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: RE: [PATCH v3 02/18] iommu/vt-d: Add DEV-MSI support



Hi David,
 
> On Wed, 2020-09-30 at 20:32 +0200, Thomas Gleixner wrote:
> > On Tue, Sep 15 2020 at 16:27, Dave Jiang wrote:
> > > @@ -1303,9 +1303,10 @@ static void
> intel_irq_remapping_prepare_irte(struct intel_ir_data *data,
> > >  	case X86_IRQ_ALLOC_TYPE_HPET:
> > >  	case X86_IRQ_ALLOC_TYPE_PCI_MSI:
> > >  	case X86_IRQ_ALLOC_TYPE_PCI_MSIX:
> > > +	case X86_IRQ_ALLOC_TYPE_DEV_MSI:
> > >  		if (info->type == X86_IRQ_ALLOC_TYPE_HPET)
> > >  			set_hpet_sid(irte, info->devid);
> > > -		else
> > > +		else if (info->type != X86_IRQ_ALLOC_TYPE_DEV_MSI)
> > >  			set_msi_sid(irte,
> > >  			msi_desc_to_pci_dev(info->desc));
> >
> > Gah. this starts to become unreadable.
> >
> > diff --git a/drivers/iommu/intel/irq_remapping.c
> b/drivers/iommu/intel/irq_remapping.c
> > index 8f4ce72570ce..0c1ea8ceec31 100644
> > --- a/drivers/iommu/intel/irq_remapping.c
> > +++ b/drivers/iommu/intel/irq_remapping.c
> > @@ -1271,6 +1271,16 @@ static struct irq_chip intel_ir_chip = {
> >  	.irq_set_vcpu_affinity	= intel_ir_set_vcpu_affinity,
> >  };
> >
> > +static void irte_prepare_msg(struct msi_msg *msg, int index, int subhandle)
> > +{
> > +	msg->address_hi = MSI_ADDR_BASE_HI;
> > +	msg->data = sub_handle;
> > +	msg->address_lo = MSI_ADDR_BASE_LO | MSI_ADDR_IR_EXT_INT |
> > +			  MSI_ADDR_IR_SHV |
> > +			  MSI_ADDR_IR_INDEX1(index) |
> > +			  MSI_ADDR_IR_INDEX2(index);
> > +}
> > +
> >  static void intel_irq_remapping_prepare_irte(struct intel_ir_data *data,
> >  					     struct irq_cfg *irq_cfg,
> >  					     struct irq_alloc_info *info,
> > @@ -1312,19 +1322,18 @@ static void
> intel_irq_remapping_prepare_irte(struct intel_ir_data *data,
> >  		break;
> >
> >  	case X86_IRQ_ALLOC_TYPE_HPET:
> > +		set_hpet_sid(irte, info->hpet_id);
> > +		irte_prepare_msg(msg, index, sub_handle);
> > +		break;
> > +
> >  	case X86_IRQ_ALLOC_TYPE_MSI:
> >  	case X86_IRQ_ALLOC_TYPE_MSIX:
> > -		if (info->type == X86_IRQ_ALLOC_TYPE_HPET)
> > -			set_hpet_sid(irte, info->hpet_id);
> > -		else
> > -			set_msi_sid(irte, info->msi_dev);
> > -
> > -		msg->address_hi = MSI_ADDR_BASE_HI;
> > -		msg->data = sub_handle;
> > -		msg->address_lo = MSI_ADDR_BASE_LO |
> MSI_ADDR_IR_EXT_INT |
> > -				  MSI_ADDR_IR_SHV |
> > -				  MSI_ADDR_IR_INDEX1(index) |
> > -				  MSI_ADDR_IR_INDEX2(index);
> > +		set_msi_sid(irte, info->msi_dev);
> > +		irte_prepare_msg(msg, index, sub_handle);
> > +		break;
> > +
> > +	case X86_IRQ_ALLOC_TYPE_DEV_MSI:
> > +		irte_prepare_msg(msg, index, sub_handle);
> >  		break;
> >
> >  	default:
> >
> > Hmm?
> 
> It'd get a bit nicer if you *always* did the irte_prepare_msg() part to
> generate the MSI message. Let the IOAPIC driver swizzle that into the
> IOAPIC RTE for itself. You have no business composing an IOAPIC RTE
> here.
> 
> Then your switch statement is *only* for setting the SID in the IRTE
> appropriately.

I don’t think I fully understand what needs to be done, but if we move the IOAPIC RTE configure into the IOAPIC driver, wouldn't that mean that the IOAPIC driver should be aware of interrupt remapping?

Right now IOAPIC case here configures an RTE entry, and the MSI related cases configure the msi message(through the irte_prepare_msg()). So unless irte_prepare_msg somehow even configures IOAPIC message, we cannot always do irte_prepare_msg right? 

It would be great if you could provide some insight here 😊 

Thanks,
Megha