dmaengine.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Dave Jiang <dave.jiang@intel.com>,
	vkoul@kernel.org, megha.dey@intel.com, maz@kernel.org,
	bhelgaas@google.com, alex.williamson@redhat.com,
	jacob.jun.pan@intel.com, ashok.raj@intel.com, jgg@mellanox.com,
	yi.l.liu@intel.com, baolu.lu@intel.com, kevin.tian@intel.com,
	sanjay.k.kumar@intel.com, tony.luck@intel.com,
	jing.lin@intel.com, dan.j.williams@intel.com,
	kwankhede@nvidia.com, eric.auger@redhat.com, parav@mellanox.com,
	jgg@mellanox.com, rafael@kernel.org, netanelg@mellanox.com,
	shahafs@mellanox.com, yan.y.zhao@linux.intel.com,
	pbonzini@redhat.com, samuel.ortiz@intel.com,
	mona.hossain@intel.com
Cc: dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, linux-pci@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v3 11/18] dmaengine: idxd: ims setup for the vdcm
Date: Wed, 30 Sep 2020 21:57:22 +0200	[thread overview]
Message-ID: <87mu17ghr1.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <160021253189.67751.12686144284999931703.stgit@djiang5-desk3.ch.intel.com>

On Tue, Sep 15 2020 at 16:28, Dave Jiang wrote:
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index a39392157dc2..115a8f49aab3 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -301,6 +301,7 @@ config INTEL_IDXD_MDEV
>  	depends on INTEL_IDXD
>  	depends on VFIO_MDEV
>  	depends on VFIO_MDEV_DEVICE
> +	depends on IMS_MSI_ARRAY

select?

> int idxd_mdev_host_init(struct idxd_device *idxd)
> {
>	struct device *dev = &idxd->pdev->dev;

> +	ims_info.max_slots = idxd->ims_size;
> +	ims_info.slots = idxd->reg_base + idxd->ims_offset;
> +	dev->msi_domain =
> pci_ims_array_create_msi_irq_domain(idxd->pdev, &ims_info);

1) creating the domain can fail and checking the return code is overrated

2) dev_set_msi_domain() exists for a reason. If we change any of this in
   struct device then we can chase all the open coded mess in drivers
   like this.

Also can you please explain how this is supposed to work?

idxd->pdev is the host PCI device. So why are you overwriting the MSI
domain of the underlying host device? This works by chance because you
allocate the regular MSIX interrupts for the host device _before_
invoking this.

IIRC, I provided you ASCII art to show how all of this is supposed to be
structured...

>  int vidxd_send_interrupt(struct vdcm_idxd *vidxd, int msix_idx)
>  {
>  	int rc = -1;
> @@ -44,15 +46,63 @@ int vidxd_send_interrupt(struct vdcm_idxd *vidxd, int msix_idx)
>  	return rc;
>  }
>  
> +#define IMS_PASID_ENABLE	0x8
>  int vidxd_disable_host_ims_pasid(struct vdcm_idxd *vidxd, int ims_idx)

Yet more unreadable glue. The coding style of this stuff is horrible.

>  {
> -	/* PLACEHOLDER */
> +	struct mdev_device *mdev = vidxd->vdev.mdev;
> +	struct device *dev = mdev_dev(mdev);
> +	unsigned int ims_offset;
> +	struct idxd_device *idxd = vidxd->idxd;
> +	u32 val;
> +
> +	/*
> +	 * Current implementation limits to 1 WQ for the vdev and therefore
> +	 * also only 1 IMS interrupt for that vdev.
> +	 */
> +	if (ims_idx >= VIDXD_MAX_WQS) {
> +		dev_warn(dev, "ims_idx greater than vidxd allowed: %d\n", ims_idx);

This warning text makes no sense whatsoever.

> +		return -EINVAL;
> +	}
> +
> +	ims_offset = idxd->ims_offset + vidxd->ims_index[ims_idx] * 0x10;
> +	val = ioread32(idxd->reg_base + ims_offset + 12);
> +	val &= ~IMS_PASID_ENABLE;
> +	iowrite32(val, idxd->reg_base + ims_offset + 12);

*0x10 + 12 !?!? 

Reusing struct ims_slot from the irq chip driver would not be convoluted
enough, right?

Aside of that this is fiddling in the IMS storage array behind the irq
chips back without any comment here and a big fat comment about the
shared usage of ims_slot::ctrl in the irq chip driver.

This is kernel programming, not the obfuscated C code contest.

> +	/* Setup the PASID filtering */
> +	pasid = idxd_get_mdev_pasid(mdev);
> +
> +	if (pasid >= 0) {
> +		ims_offset = idxd->ims_offset + vidxd->ims_index[ims_idx] * 0x10;
> +		val = ioread32(idxd->reg_base + ims_offset + 12);
> +		val |= IMS_PASID_ENABLE | (pasid << 12) | (val & 0x7);
> +		iowrite32(val, idxd->reg_base + ims_offset + 12);

More magic numbers and more fiddling in the IMS slot.

> +	} else {
> +		dev_warn(dev, "pasid setup failed for ims entry %lld\n", vidxd->ims_index[ims_idx]);
> +		return -ENXIO;
> +	}
> +
>  	return 0;
>  }
>  
> @@ -839,12 +889,43 @@ static void vidxd_wq_disable(struct vdcm_idxd *vidxd, int wq_id_mask)
>  
>  void vidxd_free_ims_entries(struct vdcm_idxd *vidxd)
>  {
> -	/* PLACEHOLDER */
> +	struct irq_domain *irq_domain;
> +	struct mdev_device *mdev = vidxd->vdev.mdev;
> +	struct device *dev = mdev_dev(mdev);
> +	int i;
> +
> +	for (i = 0; i < VIDXD_MAX_MSIX_VECS - 1; i++)
> +		vidxd->ims_index[i] = -1;
> +
> +	irq_domain = vidxd->idxd->pdev->dev.msi_domain;

See above.

> +	msi_domain_free_irqs(irq_domain, dev);

>  int vidxd_setup_ims_entries(struct vdcm_idxd *vidxd)
>  {
> -	/* PLACEHOLDER */
> +	struct irq_domain *irq_domain;
> +	struct idxd_device *idxd = vidxd->idxd;
> +	struct mdev_device *mdev = vidxd->vdev.mdev;
> +	struct device *dev = mdev_dev(mdev);
> +	int vecs = VIDXD_MAX_MSIX_VECS - 1;
> +	struct msi_desc *entry;
> +	struct ims_irq_entry *irq_entry;
> +	int rc, i = 0;
> +
> +	irq_domain = idxd->pdev->dev.msi_domain;

Ditto.

> +	rc = msi_domain_alloc_irqs(irq_domain, dev, vecs);
> +	if (rc < 0)
> +		return rc;
> +
> +	for_each_msi_entry(entry, dev) {
> +		irq_entry = &vidxd->irq_entries[i];
> +		irq_entry->vidxd = vidxd;
> +		irq_entry->int_src = i;

Redundant information because it's the index in the array. What for?

> +		irq_entry->irq = entry->irq;
> +		vidxd->ims_index[i] = entry->device_msi.hwirq;

The point of having two arrays to store related information is?

It's at least orders of magnitudes better than the previous trainwreck,
but oh well...

Thanks,

        tglx

  parent reply	other threads:[~2020-09-30 19:57 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <160021207013.67751.8220471499908137671.stgit@djiang5-desk3.ch.intel.com>
2020-09-15 23:27 ` [PATCH v3 01/18] irqchip: Add IMS (Interrupt Message Storage) driver Dave Jiang
2020-09-30 18:23   ` Thomas Gleixner
2020-10-01 22:59     ` Dey, Megha
2020-09-15 23:27 ` [PATCH v3 02/18] iommu/vt-d: Add DEV-MSI support Dave Jiang
2020-09-30 18:32   ` Thomas Gleixner
2020-10-01 23:26     ` Dey, Megha
2020-10-02 11:13       ` Thomas Gleixner
2020-10-08  7:54     ` David Woodhouse
2020-10-20 21:42       ` Dey, Megha
2020-09-15 23:28 ` [PATCH v3 05/18] dmaengine: idxd: add IMS support in base driver Dave Jiang
2020-09-30 18:47   ` Thomas Gleixner
2020-09-30 18:51     ` Jason Gunthorpe
2020-09-30 21:48       ` Thomas Gleixner
2020-09-30 21:49       ` Raj, Ashok
2020-09-30 21:57         ` Thomas Gleixner
2020-10-01  1:07           ` Raj, Ashok
2020-10-01  8:44             ` Thomas Gleixner
2020-09-30 22:38         ` Jason Gunthorpe
2020-10-01 20:48     ` Dave Jiang
2020-09-15 23:28 ` [PATCH v3 07/18] dmaengine: idxd: add basic mdev registration and helper functions Dave Jiang
2020-09-15 23:28 ` [PATCH v3 10/18] dmaengine: idxd: virtual device commands emulation Dave Jiang
2020-09-15 23:28 ` [PATCH v3 12/18] dmaengine: idxd: add mdev type as a new wq type Dave Jiang
2020-09-15 23:29 ` [PATCH v3 13/18] dmaengine: idxd: add dedicated wq mdev type Dave Jiang
2020-09-15 23:29 ` [PATCH v3 14/18] dmaengine: idxd: add new wq state for mdev Dave Jiang
2020-09-15 23:29 ` [PATCH v3 15/18] dmaengine: idxd: add error notification from host driver to mediated device Dave Jiang
2020-09-15 23:29 ` [PATCH v3 16/18] dmaengine: idxd: add ABI documentation for mediated device support Dave Jiang
2020-09-17 15:06 ` [PATCH v3 00/18] Add VFIO mediated device support and DEV-MSI support for the idxd driver Jason Gunthorpe
2020-09-17 17:15   ` Dave Jiang
2020-09-17 17:27     ` Jason Gunthorpe
2020-09-17 17:30     ` Alex Williamson
2020-09-17 17:37       ` Jason Gunthorpe
     [not found] ` <160021248280.67751.12525558281536923518.stgit@djiang5-desk3.ch.intel.com>
2020-09-30 18:36   ` [PATCH v3 04/18] dmaengine: idxd: add interrupt handle request support Thomas Gleixner
2020-10-01 20:16     ` Dave Jiang
     [not found] ` <160021253189.67751.12686144284999931703.stgit@djiang5-desk3.ch.intel.com>
2020-09-30 19:57   ` Thomas Gleixner [this message]
2020-10-07 21:54     ` [PATCH v3 11/18] dmaengine: idxd: ims setup for the vdcm Dave Jiang
2020-10-08  7:39       ` Thomas Gleixner
2020-10-08 16:51         ` Dave Jiang
2020-10-08 23:17           ` Thomas Gleixner
2020-10-08 23:32             ` Jason Gunthorpe
2020-10-09  0:27               ` Dave Jiang
2020-10-09  1:22               ` Raj, Ashok
2020-10-09 11:57                 ` Jason Gunthorpe
2020-10-09 12:43                   ` Raj, Ashok
2020-10-09 12:49                     ` Jason Gunthorpe
2020-10-09 13:02                       ` Raj, Ashok
2020-10-09 13:12                         ` Jason Gunthorpe
2020-10-09 13:40                           ` Raj, Ashok
2020-10-09 14:44               ` Thomas Gleixner
2020-10-09 14:52                 ` Jason Gunthorpe
2020-10-09 16:02                   ` Thomas Gleixner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mu17ghr1.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@intel.com \
    --cc=bhelgaas@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=eric.auger@redhat.com \
    --cc=jacob.jun.pan@intel.com \
    --cc=jgg@mellanox.com \
    --cc=jing.lin@intel.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwankhede@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=megha.dey@intel.com \
    --cc=mona.hossain@intel.com \
    --cc=netanelg@mellanox.com \
    --cc=parav@mellanox.com \
    --cc=pbonzini@redhat.com \
    --cc=rafael@kernel.org \
    --cc=samuel.ortiz@intel.com \
    --cc=sanjay.k.kumar@intel.com \
    --cc=shahafs@mellanox.com \
    --cc=tony.luck@intel.com \
    --cc=vkoul@kernel.org \
    --cc=x86@kernel.org \
    --cc=yan.y.zhao@linux.intel.com \
    --cc=yi.l.liu@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).