From: "Jan Beulich" <JBeulich@novell.com>
To: "Konrad Rzeszutek Wilk" <konrad.wilk@oracle.com>
Cc: "Ryan Wilson" <hap9@darnok.org>,
"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>,
"Jeremy Fitzhardinge" <jeremy@goop.org>,
"Konrad Rzeszutek Wilk" <konrad@kernel.org>,
<xen-devel@lists.xensource.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 20/23] xen-pcifront: Xen PCI frontend driver.
Date: Wed, 13 Oct 2010 10:36:59 +0100 [thread overview]
Message-ID: <4CB599DB020000780001CC60@vpn.id2.novell.com> (raw)
In-Reply-To: <1286898271-32018-21-git-send-email-konrad.wilk@oracle.com>
>>> On 12.10.10 at 17:44, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -40,6 +40,21 @@ config PCI_STUB
>
> When in doubt, say N.
>
> +config XEN_PCIDEV_FRONTEND
> + tristate "Xen PCI Frontend"
> + depends on PCI && X86 && XEN
> + select HOTPLUG
> + select PCI_XEN
> + default y
> + help
> + The PCI device frontend driver allows the kernel to import
> arbitrary
> + PCI devices from a PCI backend to support PCI driver domains.
> +
> +config XEN_PCIDEV_FE_DEBUG
> + bool
> + depends on PCI_DEBUG
> + default n
A bool without prompt, (pointlessly) defaulting to 'n', and without
getting selected anywhere has no way to get set to 'y'...
> +
> config HT_IRQ
> bool "Interrupts on hypertransport devices"
> default y
> --- /dev/null
> +++ b/drivers/pci/xen-pcifront.c
> @@ -0,0 +1,1157 @@
> +/*
> + * Xen PCI Frontend.
> + *
> + * Author: Ryan Wilson <hap9@epoch.ncsc.mil>
> + */
> +#include <linux/module.h>
> +#include <linux/init.h>
> +#include <linux/mm.h>
> +#include <xen/xenbus.h>
> +#include <xen/events.h>
> +#include <xen/grant_table.h>
> +#include <xen/page.h>
> +#include <linux/spinlock.h>
> +#include <linux/pci.h>
> +#include <linux/msi.h>
> +#include <xen/xenbus.h>
> +#include <xen/interface/io/pciif.h>
> +#include <asm/xen/pci.h>
> +#include <linux/interrupt.h>
> +#include <asm/atomic.h>
> +#include <linux/workqueue.h>
> +#include <linux/bitops.h>
> +#include <linux/time.h>
> +
> +
> +#ifndef __init_refok
> +#define __init_refok
> +#endif
???
> +
> +#define INVALID_GRANT_REF (0)
> +#define INVALID_EVTCHN (-1)
> +
> +
> +struct pci_bus_entry {
> + struct list_head list;
> + struct pci_bus *bus;
> +};
> +
> +#define _PDEVB_op_active (0)
> +#define PDEVB_op_active (1 << (_PDEVB_op_active))
> +
> +struct pcifront_device {
> + struct xenbus_device *xdev;
> + struct list_head root_buses;
> +
> + int evtchn;
> + int gnt_ref;
> +
> + int irq;
> +
> + /* Lock this when doing any operations in sh_info */
> + spinlock_t sh_info_lock;
> + struct xen_pci_sharedinfo *sh_info;
> + struct work_struct op_work;
> + unsigned long flags;
> +
> +};
> +
> +struct pcifront_sd {
> + int domain;
> + struct pcifront_device *pdev;
> +};
> +
> +static inline struct pcifront_device *
> +pcifront_get_pdev(struct pcifront_sd *sd)
> +{
> + return sd->pdev;
> +}
> +
> +static inline void pcifront_init_sd(struct pcifront_sd *sd,
> + unsigned int domain, unsigned int bus,
> + struct pcifront_device *pdev)
> +{
> + sd->domain = domain;
> + sd->pdev = pdev;
> +}
> +
> +static inline void pcifront_setup_root_resources(struct pci_bus *bus,
> + struct pcifront_sd *sd)
> +{
> +}
???
> +
> +
> +DEFINE_SPINLOCK(pcifront_dev_lock);
static?
>...
> +void pcifront_do_aer(struct work_struct *data)
static?
>...
> +irqreturn_t pcifront_handler_aer(int irq, void *dev)
static?
>...
> +int pcifront_connect(struct pcifront_device *pdev)
static?
>...
> +void pcifront_disconnect(struct pcifront_device *pdev)
static?
>...
> +static void free_pdev(struct pcifront_device *pdev)
> +{
> + dev_dbg(&pdev->xdev->dev, "freeing pdev @ 0x%p\n", pdev);
> +
> + pcifront_free_roots(pdev);
> +
> + /*For PCIE_AER error handling job*/
> + flush_scheduled_work();
if (pdev->irq > 0)
> + unbind_from_irqhandler(pdev->irq, pdev);
> +
> + if (pdev->evtchn != INVALID_EVTCHN)
> + xenbus_free_evtchn(pdev->xdev, pdev->evtchn);
> +
> + if (pdev->gnt_ref != INVALID_GRANT_REF)
> + gnttab_end_foreign_access(pdev->gnt_ref, 0 /* r/w page */,
> + (unsigned long)pdev->sh_info);
else
free_page((unsigned long)pdev->sh_info);
> +
> + dev_set_drvdata(&pdev->xdev->dev, NULL);
> +
> + kfree(pdev);
> +}
> +
> +static int pcifront_publish_info(struct pcifront_device *pdev)
> +{
> + int err = 0;
> + struct xenbus_transaction trans;
> +
> + err = xenbus_grant_ring(pdev->xdev, virt_to_mfn(pdev->sh_info));
> + if (err < 0)
> + goto out;
> +
> + pdev->gnt_ref = err;
> +
> + err = xenbus_alloc_evtchn(pdev->xdev, &pdev->evtchn);
> + if (err)
> + goto out;
> +
> + err = bind_evtchn_to_irqhandler(pdev->evtchn, pcifront_handler_aer,
> + 0, "pcifront", pdev);
> + if (err < 0) {
> + xenbus_free_evtchn(pdev->xdev, pdev->evtchn);
You're leaking the grant ref here. I think it's better to not do any
cleanup here, and instead call free_pdev() on error in
pcifront_xenbus_probe() (see below).
> + xenbus_dev_fatal(pdev->xdev, err, "Failed to bind evtchn to "
> + "irqhandler.\n");
> + return err;
> + }
> + pdev->irq = err;
>...
> +static int __devinit pcifront_try_connect(struct pcifront_device *pdev)
> +{
> + int err = -EFAULT;
> + int i, num_roots, len;
> + char str[64];
> + unsigned int domain, bus;
> +
The original code had a per-device lock here and in subsequent
functions. Is this being dropped due to implicit serialization through
only running in the context of the single xenbus thread?
>...
> +static int pcifront_xenbus_probe(struct xenbus_device *xdev,
> + const struct xenbus_device_id *id)
> +{
> + int err = 0;
> + struct pcifront_device *pdev = alloc_pdev(xdev);
> +
> + if (pdev == NULL) {
> + err = -ENOMEM;
> + xenbus_dev_fatal(xdev, err,
> + "Error allocating pcifront_device struct");
> + goto out;
> + }
> +
> + err = pcifront_publish_info(pdev);
if (err)
free_pdev(pdev);
> +
> +out:
> + return err;
> +}
>...
Jan
next prev parent reply other threads:[~2010-10-13 9:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-12 15:44 [PATCH v8] Xen PCI + " Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 01/23] xen: Don't disable the I/O space Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 02/23] xen: define BIOVEC_PHYS_MERGEABLE() Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 03/23] xen: implement pirq type event channels Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 04/23] x86/io_apic: add get_nr_irqs_gsi() Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 05/23] xen: identity map gsi->irqs Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 06/23] xen: dynamically allocate irq & event structures Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 07/23] xen: set pirq name to something useful Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 08/23] xen: statically initialize cpu_evtchn_mask_p Konrad Rzeszutek Wilk
2011-01-24 17:44 ` Paolo Bonzini
2011-01-25 14:02 ` [Xen-devel] " Ian Campbell
2010-10-12 15:44 ` [PATCH 09/23] xen: Find an unbound irq number in reverse order (high to low) Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 10/23] xen: Provide a variant of xen_poll_irq with timeout Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 11/23] xen: fix shared irq device passthrough Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 12/23] x86/PCI: Clean up pci_cache_line_size Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 13/23] x86/PCI: make sure _PAGE_IOMAP it set on pci mappings Konrad Rzeszutek Wilk
2010-10-12 15:54 ` Jesse Barnes
2010-10-12 15:44 ` [PATCH 14/23] x86/PCI: Export pci_walk_bus function Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 15/23] msi: Introduce default_[teardown|setup]_msi_irqs with fallback Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 16/23] x86: Introduce x86_msi_ops Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 17/23] xen/x86/PCI: Add support for the Xen PCI subsystem Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 18/23] xenbus: Xen paravirtualised PCI hotplug support Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 19/23] xenbus: prevent warnings on unhandled enumeration values Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 20/23] xen-pcifront: Xen PCI frontend driver Konrad Rzeszutek Wilk
2010-10-13 9:36 ` Jan Beulich [this message]
2010-10-13 13:53 ` Konrad Rzeszutek Wilk
2010-10-13 16:16 ` Konrad Rzeszutek Wilk
2010-10-14 7:15 ` [Xen-devel] " Jan Beulich
2010-10-14 17:35 ` Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 21/23] xen/pci: Request ACS when Xen-SWIOTLB is activated Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 22/23] MAINTAINERS: Add myself for Xen PCI and Xen SWIOTLB maintainer Konrad Rzeszutek Wilk
2010-10-12 15:44 ` [PATCH 23/23] swiotlb-xen: On x86-32 builts, select SWIOTLB instead of depending on it Konrad Rzeszutek Wilk
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=4CB599DB020000780001CC60@vpn.id2.novell.com \
--to=jbeulich@novell.com \
--cc=hap9@darnok.org \
--cc=jeremy@goop.org \
--cc=konrad.wilk@oracle.com \
--cc=konrad@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stefano.stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.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
all inboxes | Powered by JetHome®