public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Wright <chrisw@sous-sol.org>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org, avi@redhat.com
Subject: Re: [PATCH corrected RFC] uio: add generic driver for PCI 2.3 devices
Date: Thu, 9 Jul 2009 19:19:45 -0700	[thread overview]
Message-ID: <20090710021945.GE30379@sequoia.sous-sol.org> (raw)
In-Reply-To: <20090709114834.GB26479@redhat.com>

* Michael S. Tsirkin (mst@redhat.com) wrote:
> +struct generic_dev {

I know I commented on this one on an earlier, private version, and naming
is not my strength... maybe "struct uio_generic_pci_dev" or "struct
uio_generic_pci"?

> +	struct uio_info info;
> +	struct pci_dev *pdev;
> +	spinlock_t lock; /* guards command register accesses */
> +};
> +
> +/* Read/modify/write command register to disable interrupts.
> + * Note: we could cache the value and optimize the read if there was a way to
> + * get notified of user changes to command register through sysfs.
> + * */

For the irqcontrol case, I don't think RMW is a problem (coming from
userspace it's already a slower path).

For the irqhandler case, you can grab the full dword to get Command+Status
(since you needed status anyway, and config reads are dword).

> +static void irqtoggle(struct generic_dev *dev, int irq_on)
> +{
> +	struct pci_dev *pdev = dev->pdev;
> +	unsigned long flags;
> +	u16 orig, new;
> +
> +	spin_lock_irqsave(&dev->lock, flags);
> +	pci_block_user_cfg_access(pdev);
> +	pci_read_config_word(pdev, PCI_COMMAND, &orig);
> +	new = irq_on ? orig & ~PCI_COMMAND_INTX_DISABLE :
> +		orig | PCI_COMMAND_INTX_DISABLE;
> +	if (new != orig)
> +		pci_write_config_word(dev->pdev, PCI_COMMAND, new);
> +	pci_unblock_user_cfg_access(dev);
> +	spin_unlock_irqrestore(&dev->lock, flags);
> +}
> +
> +/* irqcontrol is use by userspace to enable/disable interrupts. */
> +static int irqcontrol(struct uio_info *info, s32 irq_on)
> +{
> +	struct generic_dev *dev = container_of(info, struct generic_dev, info);
> +	irqtoggle(dev, irq_on);
> +	return 0;
> +}
> +
> +static irqreturn_t irqhandler(int irq, struct uio_info *info)
> +{
> +	struct generic_dev *dev = container_of(info, struct generic_dev, info);
> +	irqreturn_t ret = IRQ_NONE;
> +	u16 status;
> +
> +	/* Check interrupt status register to see whether our device
> +	 * triggered the interrupt. */
> +	pci_read_config_word(dev->pdev, PCI_STATUS, &status);
> +	if (!(status & PCI_STATUS_INTERRUPT))
> +		goto done;
> +
> +	/* We triggered the interrupt, disable it. */
> +	irqtoggle(dev, 0);
> +	/* UIO core will signal the user process. */
> +	ret = IRQ_HANDLED;
> +done:
> +	return ret;
> +}
> +
> +/* Verify that the device supports Interrupt Disable bit in command register,
> + * per PCI 2.3, by flipping this bit and reading it back: this bit was readonly
> + * in PCI 2.2. */

Wonder if this should also restrict from things like bridges?

> +static int __devinit verify_pci_2_3(struct pci_dev *pdev)
> +{
> +	u16 orig, new;
> +	int err = 0;
> +
> +	pci_block_user_cfg_access(pdev);
> +	pci_read_config_word(pdev, PCI_COMMAND, &orig);
> +	pci_write_config_word(pdev, PCI_COMMAND,
> +			      orig ^ PCI_COMMAND_INTX_DISABLE);
> +	pci_read_config_word(pdev, PCI_COMMAND, &new);
> +	/* There's no way to protect against
> +	 * hardware bugs or detect them reliably, but as long as we know
> +	 * what the value should be, let's go ahead and check it. */
> +	if ((new ^ orig) & ~PCI_COMMAND_INTX_DISABLE) {
> +		err = -EBUSY;
> +		dev_err(&pdev->dev, "Command changed from 0x%x to 0x%x: "
> +			"driver or HW bug?\n", orig, new);
> +		goto err;
> +	}
> +	if (!((new ^ orig) & PCI_COMMAND_INTX_DISABLE)) {
> +		dev_warn(&pdev->dev, "Device does not support "
> +			 "disabling interrupts: unable to bind.\n");
> +		err = -ENODEV;
> +		goto err;
> +	}
> +	/* Now restore the original value. */
> +	pci_write_config_word(pdev, PCI_COMMAND, orig);
> +err:
> +	pci_unblock_user_cfg_access(pdev);
> +	return err;
> +}
> +
> +static int __devinit probe(struct pci_dev *pdev,
> +			   const struct pci_device_id *id)
> +{
> +	struct generic_dev *dev;
> +	int err;
> +
> +	err = pci_enable_device(pdev);
> +	if (err) {
> +		dev_err(&pdev->dev, "%s: pci_enable_device failed: %d\n",
> +			 __func__, err);
> +		return err;
> +	}
> +
> +	err = verify_pci_2_3(pdev);
> +	if (err)
> +		goto err_verify;
> +
> +	err = pci_request_regions(pdev, "uio_pci_generic");
> +	if (err) {
> +		dev_err(&pdev->dev, "%s: pci_request_regions failed: %d\n",
> +			 __func__, err);
> +		goto err_verify;
> +	}
> +
> +	dev = kzalloc(sizeof(struct generic_dev), GFP_KERNEL);
> +	if (!dev) {
> +		err = -ENOMEM;
> +		goto err_alloc;
> +	}
> +
> +	dev->info.name = "uio_pci_generic";
> +	dev->info.version = "0.01";
> +	dev->info.irq = pdev->irq;

May need to verify pdev->irq in verify too?

> +	dev->info.irq_flags = IRQF_SHARED;
> +	dev->info.handler = irqhandler;
> +	dev->info.irqcontrol = irqcontrol;
> +	dev->pdev = pdev;
> +	spin_lock_init(&dev->lock);
> +
> +	pci_reset_function(pdev);

I think this could be a bit much, since it will fall back to secondary
bus reset.

thanks,
-chris

  parent reply	other threads:[~2009-07-10  2:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-09 11:48 [PATCH corrected RFC] uio: add generic driver for PCI 2.3 devices Michael S. Tsirkin
2009-07-09 14:54 ` Anthony Liguori
2009-07-09 18:12   ` Michael S. Tsirkin
2009-07-09 20:14     ` Anthony Liguori
2009-07-09 20:21       ` Michael S. Tsirkin
2009-07-10  2:22   ` Chris Wright
2009-07-12  6:17     ` Avi Kivity
2009-07-10  2:19 ` Chris Wright [this message]
2009-07-10 13:56   ` Michael S. Tsirkin
  -- strict thread matches above, loose matches on Subject: below --
2009-07-09 18:13 Michael S. Tsirkin

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=20090710021945.GE30379@sequoia.sous-sol.org \
    --to=chrisw@sous-sol.org \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.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