| 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
| ||
|
Message-ID: <ec81670539674beea58c9a6c4104b26b@intel.com>
Date: Wed, 5 Aug 2020 19:02:35 +0000
From: "Dey, Megha" <megha.dey@...el.com>
To: 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>,
"rafael@...nel.org" <rafael@...nel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"hpa@...or.com" <hpa@...or.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>,
"jgg@...lanox.com" <jgg@...lanox.com>,
"rafael@...nel.org" <rafael@...nel.org>,
"Hansen, Dave" <dave.hansen@...el.com>,
"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 RFC v2 03/18] irq/dev-msi: Create IR-DEV-MSI irq domain
Hi Thomas,
> -----Original Message-----
> From: Thomas Gleixner <tglx@...utronix.de>
> Sent: Wednesday, July 22, 2020 1:45 PM
> To: Jiang, Dave <dave.jiang@...el.com>; vkoul@...nel.org; Dey, Megha
> <megha.dey@...el.com>; maz@...nel.org; bhelgaas@...gle.com;
> rafael@...nel.org; gregkh@...uxfoundation.org; hpa@...or.com;
> alex.williamson@...hat.com; Pan, Jacob jun <jacob.jun.pan@...el.com>; Raj,
> Ashok <ashok.raj@...el.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; eric.auger@...hat.com; parav@...lanox.com;
> jgg@...lanox.com; rafael@...nel.org; Hansen, Dave
> <dave.hansen@...el.com>; netanelg@...lanox.com; shahafs@...lanox.com;
> yan.y.zhao@...ux.intel.com; pbonzini@...hat.com; Ortiz, Samuel
> <samuel.ortiz@...el.com>; Hossain, Mona <mona.hossain@...el.com>
> Cc: dmaengine@...r.kernel.org; linux-kernel@...r.kernel.org;
> x86@...nel.org; linux-pci@...r.kernel.org; kvm@...r.kernel.org
> Subject: Re: [PATCH RFC v2 03/18] irq/dev-msi: Create IR-DEV-MSI irq domain
>
> Dave Jiang <dave.jiang@...el.com> writes:
> > From: Megha Dey <megha.dey@...el.com>
> >
> > When DEV_MSI is enabled, the dev_msi_default_domain is updated to the
> > base DEV-MSI irq domain. If interrupt remapping is enabled, we create
>
> s/we//
ok
>
> > a new IR-DEV-MSI irq domain and update the dev_msi_default domain to
> > the same.
> >
> > For X86, introduce a new irq_alloc_type which will be used by the
> > interrupt remapping driver.
> >
> > Reviewed-by: Dan Williams <dan.j.williams@...el.com>
> > Signed-off-by: Megha Dey <megha.dey@...el.com>
> > Signed-off-by: Dave Jiang <dave.jiang@...el.com>
> > ---
> > arch/x86/include/asm/hw_irq.h | 1 +
> > arch/x86/kernel/apic/msi.c | 12 ++++++
> > drivers/base/dev-msi.c | 66 +++++++++++++++++++++++++++++++----
> > drivers/iommu/intel/irq_remapping.c | 11 +++++-
> > include/linux/intel-iommu.h | 1 +
> > include/linux/irqdomain.h | 11 ++++++
> > include/linux/msi.h | 3 ++
>
> Why is this mixing generic code, x86 core code and intel specific driver code?
> This is new functionality so:
>
> 1) Provide the infrastructure
> 2) Add support to architecture specific parts
> 3) Enable it
Ok, I will try to adhere to the layering next time around..
>
> > +
> > +#ifdef CONFIG_DEV_MSI
> > +int dev_msi_prepare(struct irq_domain *domain, struct device *dev,
> > + int nvec, msi_alloc_info_t *arg) {
> > + memset(arg, 0, sizeof(*arg));
> > +
> > + arg->type = X86_IRQ_ALLOC_TYPE_DEV_MSI;
> > +
> > + return 0;
> > +}
> > +#endif
>
> What is this? Tons of new lines for taking up more space and not a single
> comment.
Hmm, I will add a comment..
>
> > -static int dev_msi_prepare(struct irq_domain *domain, struct device
> > *dev,
> > +int __weak dev_msi_prepare(struct irq_domain *domain, struct device
> > +*dev,
> > int nvec, msi_alloc_info_t *arg) {
> > memset(arg, 0, sizeof(*arg));
>
> Oh well. So every architecure which needs to override this and I assume all
> which are eventually going to support it need to do the memset() in their
> override.
>
> memset(arg,,,);
> arch_dev_msi_prepare();
>
>
Per you suggestion, I have introduced arch_dev_msi_prepare which returns 0 by default unless
overridden by arch code in the next patch set.
> > - dev_msi_default_domain = msi_create_irq_domain(fn,
> &dev_msi_domain_info, parent);
> > + /*
> > + * This initcall may come after remap code is initialized. Ensure that
> > + * dev_msi_default domain is updated correctly.
>
> What? No, this is a disgusting hack. Get your ordering straight, that's not rocket
> science.
>
Hmm yeah, actually I realized we don't really need to have 2 new IRQ domains for dev-msi
(with and without interrupt remapping enabled). Hence all this will go away in the next round
of patches.
> > +#ifdef CONFIG_IRQ_REMAP
>
> IRQ_REMAP is x86 specific. Is this file x86 only or intended to be for general use?
> If it's x86 only, then this should be clearly documented. If not, then these
> x86'isms have no place here.
True, I will take care of this in the next patch set.
>
> > +struct irq_domain *create_remap_dev_msi_irq_domain(struct irq_domain
> *parent,
> > + const char *name)
>
> So we have msi_create_irq_domain() and this is about dev_msi, right? So can
> you please stick with a consistent naming scheme?
sure
>
> > +{
> > + struct fwnode_handle *fn;
> > + struct irq_domain *domain;
> > +
> > + fn = irq_domain_alloc_named_fwnode(name);
> > + if (!fn)
> > + return NULL;
> > +
> > + domain = msi_create_irq_domain(fn, &dev_msi_ir_domain_info,
> parent);
> > + if (!domain) {
> > + pr_warn("failed to initialize irqdomain for IR-DEV-MSI.\n");
> > + return ERR_PTR(-ENXIO);
> > + }
> > +
> > + irq_domain_update_bus_token(domain,
> DOMAIN_BUS_PLATFORM_MSI);
> > +
> > + if (!dev_msi_default_domain)
> > + dev_msi_default_domain = domain;
>
> Can this be called several times? If so, then this lacks a comment. If not, then
> this condition is useless.
Hmm this will go way in the next patch set, thank you for your input!
>
> Thanks,
>
> tglx
Powered by blists - more mailing lists