Linux PCI subsystem discussion ()

Tom Lyon | 1 Nov 2010 22:22

Picon

Re: [PATCH 0/5] Fixes, non-PCI-2.3 support, EOI enhancements

I've applied all your patches. Thanks!

On Saturday, October 30, 2010 09:58:55 am Alex Williamson wrote:
> Hi Tom,
> 
> I've updated some patches I've been working on to v5 and wanted to
> see what you think.  I also found a couple minor bugs, fixed in this
> series.
> 
> The main idea is that since the VFIO interface defines that the INTx
> interrupt is disabled when it fires, we should provide an interface
> to re-enable it.  We currently have to do a read-modify-write to PCI
> config space, requring two ioctls.  I introduce an ioctl to do this
> for us.  An important aspect of this is that now we can support
> non-PCI-2.3 devices since re-enabling the interrupt is abstracted
> (with the same caveat as current KVM device assignment, that they
> must get an exclusive interrupt).  The real trick though is that we
> can then also create an irqfd-like mechanism to trigger re-enabling
> interrupts from and eventfd.  This allows qemu to do all the setup
> for connecting interrupts from VFIO into KVM and EOIs from KVM to
> VFIO, then lets userspace get completely out of the way.
> 
> Hope you like it.  Thanks,
> 
> Alex
> ---
> 
> Alex Williamson (5):
>       vfio: Add a new ioctl to support EOI via eventfd
>       vfio: Add support for non-PCI 2.3 compliant devices

(Continue reading)

Uwe Kleine-König | 2 Nov 2010 11:41

Picon

Re: should struct device.dma_mask still be a pointer?

Hello,

I'm picking up this old thread because I'm currently faced again with
this problem ... and I'm really annoyed about it.

On Thu, Jul 01, 2010 at 10:35:58AM +0900, FUJITA Tomonori wrote:
> > IMHO it's strange that struct device.dma_mask is a pointer instead of a
> > plain u64.  The reason this was done back then is described in
> > 8ab1bc19e974fdebe76c065fe444979c84ba2f74[1]:
> > 
> > 	Attached is a patch which moves dma_mask into struct device and cleans up the
> > 	scsi mid-layer to use it (instead of using struct pci_dev).  The advantage to
> > 	doing this is probably most apparent on non-pci bus architectures where
> > 	currently you have to construct a fake pci_dev just so you can get the bounce
> > 	buffers to work correctly.
> > 
> > 	The patch tries to perturb the minimum amount of code, so dma_mask in struct
> > 	device is simply a pointer to the one in pci_dev.  However, it will make it
> > 	easy for me now to add generic device to MCA without having to go the fake pci
> > 	route.
> 
> Yeah, that's a strange design. As the commit log said, it's due to the
> historical reason. We invented the pci dma model first then moved to
> the generic dma model.
> 
> 
> > As I work on such a non-pci bus architecture it's still ugly that this
> > is a pointer because I have to allocate extra memory for that.
> 
> The popular trick to avoid allocating the extra memory for that is:

(Continue reading)

FUJITA Tomonori | 2 Nov 2010 14:03

Picon

Re: should struct device.dma_mask still be a pointer?

On Tue, 2 Nov 2010 11:41:04 +0100
Uwe Kleine-König <u.kleine-koenig <at> pengutronix.de> wrote:

> > > As I work on such a non-pci bus architecture it's still ugly that this
> > > is a pointer because I have to allocate extra memory for that.
> > 
> > The popular trick to avoid allocating the extra memory for that is:
> > 
> > device.dma_mask = &device.coherent_dma_mask;
> Does this work in general?  Or are there any corner cases that make this
> trick fail?

It doesn't work if the coherent dma mask of a device is not same as
the dma mask of the device.

> > > Is there a reason not to get rid of struct pci_dev.dma_mask and use
> > > struct pci_dev.dev.dma_mask instead?  (Well apart from the needed
> > > effort of course.)
> > > 
> > > If not, the following would be needed:
> > > 
> > > 	- remove struct pci.dma_mask
> > > 	- make struct device.dma_mask an u64 (instead of u64*)
> > > 	- substitue var.dma_mask by var.dev.dma_mask for all
> > > 	  struct pci_dev var
> > > 	- substitue var.dma_mask by &(var.dma_mask) for all
> > > 	  struct device var
> > > 
> > > and note that there are statically initialized struct device (and maybe
> > > struct pci_dev?) that need fixing, too.  (e.g.

(Continue reading)

Uwe Kleine-König | 2 Nov 2010 14:45

Picon

Re: should struct device.dma_mask still be a pointer?

Hello,

On Tue, Nov 02, 2010 at 10:03:32PM +0900, FUJITA Tomonori wrote:
> On Tue, 2 Nov 2010 11:41:04 +0100
> Uwe Kleine-König <u.kleine-koenig <at> pengutronix.de> wrote:
> 
> > > > As I work on such a non-pci bus architecture it's still ugly that this
> > > > is a pointer because I have to allocate extra memory for that.
> > > 
> > > The popular trick to avoid allocating the extra memory for that is:
> > > 
> > > device.dma_mask = &device.coherent_dma_mask;
> > Does this work in general?  Or are there any corner cases that make this
> > trick fail?
> 
> It doesn't work if the coherent dma mask of a device is not same as
> the dma mask of the device.
> 
> 
> > > > Is there a reason not to get rid of struct pci_dev.dma_mask and use
> > > > struct pci_dev.dev.dma_mask instead?  (Well apart from the needed
> > > > effort of course.)
> > > > 
> > > > If not, the following would be needed:
> > > > 
> > > > 	- remove struct pci.dma_mask
> > > > 	- make struct device.dma_mask an u64 (instead of u64*)
> > > > 	- substitue var.dma_mask by var.dev.dma_mask for all
> > > > 	  struct pci_dev var
> > > > 	- substitue var.dma_mask by &(var.dma_mask) for all

(Continue reading)

FUJITA Tomonori | 2 Nov 2010 15:43

Picon

Re: should struct device.dma_mask still be a pointer?

On Tue, 2 Nov 2010 14:45:11 +0100
Uwe Kleine-König <u.kleine-koenig <at> pengutronix.de> wrote:

> Hello,
> 
> On Tue, Nov 02, 2010 at 10:03:32PM +0900, FUJITA Tomonori wrote:
> > On Tue, 2 Nov 2010 11:41:04 +0100
> > Uwe Kleine-König <u.kleine-koenig <at> pengutronix.de> wrote:
> > 
> > > > > As I work on such a non-pci bus architecture it's still ugly that this
> > > > > is a pointer because I have to allocate extra memory for that.
> > > > 
> > > > The popular trick to avoid allocating the extra memory for that is:
> > > > 
> > > > device.dma_mask = &device.coherent_dma_mask;
> > > Does this work in general?  Or are there any corner cases that make this
> > > trick fail?
> > 
> > It doesn't work if the coherent dma mask of a device is not same as
> > the dma mask of the device.
> > 
> > 
> > > > > Is there a reason not to get rid of struct pci_dev.dma_mask and use
> > > > > struct pci_dev.dev.dma_mask instead?  (Well apart from the needed
> > > > > effort of course.)
> > > > > 
> > > > > If not, the following would be needed:
> > > > > 
> > > > > 	- remove struct pci.dma_mask
> > > > > 	- make struct device.dma_mask an u64 (instead of u64*)

(Continue reading)

Michael S. Tsirkin | 2 Nov 2010 20:11

Picon

Re: [PATCH] vfio: Extended capability fixes

On Mon, Nov 01, 2010 at 11:08:35PM -0600, Alex Williamson wrote:
> - Virtual channel position gets truncated as a u8
>  - Print the ecap that's unknown, not the last cap we saw
>  - Print actual config offset, which provides enough info to make
>    some sense of the error.
> 
> Signed-off-by: Alex Williamson <alex.williamson <at> redhat.com>
> ---
> 
>  drivers/vfio/vfio_pci_config.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_pci_config.c b/drivers/vfio/vfio_pci_config.c
> index 8af995d..8304316 100644
> --- a/drivers/vfio/vfio_pci_config.c
> +++ b/drivers/vfio/vfio_pci_config.c
>  <at>  <at>  -410,7 +410,7  <at>  <at>  static int vfio_msi_cap_len(struct vfio_dev *vdev, u8 pos)
>   * Determine extended capability length for VC (2 & 9) and
>   * MFVC capabilities
>   */
> -static int vfio_vc_cap_len(struct vfio_dev *vdev, u8 pos)
> +static int vfio_vc_cap_len(struct vfio_dev *vdev, u16 pos)
>  {
>  	struct pci_dev *pdev = vdev->pdev;
>  	u32 dw;
>  <at>  <at>  -580,7 +580,7  <at>  <at>  int vfio_build_config_map(struct vfio_dev *vdev)
>  				printk(KERN_WARNING
>  					"%s: pci config conflict at %x, "
>  					"caps %x %x\n",
> -					__func__, i, map[pos+i], cap);

(Continue reading)

Tom Lyon | 2 Nov 2010 23:18

Picon

Re: [PATCH] vfio: Extended capability fixes

Applied. Thanks!

On Monday, November 01, 2010 10:08:35 pm Alex Williamson wrote:
> - Virtual channel position gets truncated as a u8
>  - Print the ecap that's unknown, not the last cap we saw
>  - Print actual config offset, which provides enough info to make
>    some sense of the error.
> 
> Signed-off-by: Alex Williamson <alex.williamson <at> redhat.com>
> ---
> 
>  drivers/vfio/vfio_pci_config.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_pci_config.c
> b/drivers/vfio/vfio_pci_config.c index 8af995d..8304316 100644
> --- a/drivers/vfio/vfio_pci_config.c
> +++ b/drivers/vfio/vfio_pci_config.c
>  <at>  <at>  -410,7 +410,7  <at>  <at>  static int vfio_msi_cap_len(struct vfio_dev *vdev, u8
> pos) * Determine extended capability length for VC (2 & 9) and
>   * MFVC capabilities
>   */
> -static int vfio_vc_cap_len(struct vfio_dev *vdev, u8 pos)
> +static int vfio_vc_cap_len(struct vfio_dev *vdev, u16 pos)
>  {
>  	struct pci_dev *pdev = vdev->pdev;
>  	u32 dw;
>  <at>  <at>  -580,7 +580,7  <at>  <at>  int vfio_build_config_map(struct vfio_dev *vdev)
>  				printk(KERN_WARNING
>  					"%s: pci config conflict at %x, "

(Continue reading)

Tom Lyon | 2 Nov 2010 23:19

Picon

Re: [PATCH] vfio: Extended capability fixes

On Tuesday, November 02, 2010 12:11:08 pm Michael S. Tsirkin wrote:
> On Mon, Nov 01, 2010 at 11:08:35PM -0600, Alex Williamson wrote:
> > - Virtual channel position gets truncated as a u8
> > 
> >  - Print the ecap that's unknown, not the last cap we saw
> >  - Print actual config offset, which provides enough info to make
> >  
> >    some sense of the error.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson <at> redhat.com>
> > ---
> > 
> >  drivers/vfio/vfio_pci_config.c |    8 ++++----
> >  1 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/vfio/vfio_pci_config.c
> > b/drivers/vfio/vfio_pci_config.c index 8af995d..8304316 100644
> > --- a/drivers/vfio/vfio_pci_config.c
> > +++ b/drivers/vfio/vfio_pci_config.c
> >  <at>  <at>  -410,7 +410,7  <at>  <at>  static int vfio_msi_cap_len(struct vfio_dev *vdev, u8
> > pos)
> > 
> >   * Determine extended capability length for VC (2 & 9) and
> >   * MFVC capabilities
> >   */
> > 
> > -static int vfio_vc_cap_len(struct vfio_dev *vdev, u8 pos)
> > +static int vfio_vc_cap_len(struct vfio_dev *vdev, u16 pos)
> > 
> >  {

(Continue reading)

Bjorn Helgaas | 3 Nov 2010 03:28

Picon

Re: [PATCH] x86/PCI: coalesce overlapping host bridge windows

On Fri, Sep 24, 2010 at 10:07:49AM -0700, Jesse Barnes wrote:
> On Wed, 22 Sep 2010 11:09:19 -0600
> Bjorn Helgaas <bjorn.helgaas <at> hp.com> wrote:
> 
> > 
> > Some BIOSes provide PCI host bridge windows that overlap, e.g.,
> > 
> >     pci_root PNP0A03:00: host bridge window [mem 0xb0000000-0xffffffff]
> >     pci_root PNP0A03:00: host bridge window [mem 0xafffffff-0xdfffffff]
> >     pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xffffffff]
> > 
> > If we simply insert these as children of iomem_resource, the second window
> > fails because it conflicts with the first, and the third is inserted as a
> > child of the first, i.e.,
> > 
> >     b0000000-ffffffff PCI Bus 0000:00
> >       f0000000-ffffffff PCI Bus 0000:00
> > 
> > When we claim PCI device resources, this can cause collisions like this
> > if we put them in the first window:
> > 
> >     pci 0000:00:01.0: address space collision: [mem 0xff300000-0xff4fffff] conflicts with PCI Bus
0000:00 [mem 0xf0000000-0xffffffff]
> > 
> > Host bridge windows are top-level resources by definition, so it doesn't
> > make sense to make the third window a child of the first.  This patch
> > coalesces any host bridge windows that overlap.  For the example above,
> > the result is this single window:
> > 
> >     pci_root PNP0A03:00: host bridge window [mem 0xafffffff-0xffffffff]

(Continue reading)

Michael Ellerman | 3 Nov 2010 13:45

Picon

Re: [PATCH net-next-2.6 1/2] be2net: Adding an option to use INTx instead of MSI-X

On Sat, 2010-10-30 at 17:21 -0600, Matthew Wilcox wrote:
> On Tue, Oct 26, 2010 at 05:52:08PM +1100, Michael Ellerman wrote:
> > That horse has really really bolted, it's gawn.
> > 
> > I count 26 drivers with "disable MSI/X" parameters. Some even have more
> > than one.
> 
> That's 26 patches someone needs to write, then.  You can put my Acked-by
> on all of them.

Bah, come on it's hardly the most horrendous sin committed by driver
writers. And removing them risks breaking someone's system, even if they
are clueless, should RTFM etc.

> > I agree it's a mess for users, but it's probably preferable to a
> > non-working driver.
> 
> What more drivers need is an automatic detection of a non-working
> interrupt situation, great big warning messages, and fallback to an
> alternate interrupt mechanism.  Doing it for one driver, then generalising
> as much of it into the core as possible would be nice.

More detection would be good.

I don't see much potential for generalising it though. Looking at e1000e
and tg3 there is really not much in common except the very basic idea.

cheers

(Continue reading)

Group

gmane.linux.kernel.pci.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

Articles in period: 98

November 2010

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

[PATCH] lspci: Fully decode ASPM support from Link Capabilities (17 May 2013)
enabling aspm on ati radeon (17 May 2013)
[PATCH -v2 0/7] Add hostbridge resource release to support root bus ho (17 May 2013)
[PATCHv10 0/9] PCIe support for the Armada 370 and Armada XP SoCs (16 May 2013)
[RFC PATCH v2, part3 00/11] Introduce PCI bus lock and state machine (16 May 2013)
[PATCHv9 0/9] PCIe support for the Armada 370 and Armada XP SoCs (15 May 2013)
[OPW kernel] dma_set_coherent_mask (15 May 2013)
[PATCH] pci: Avoid reentrant calls to work_on_cpu (15 May 2013)
[PATCH] pci: Avoid reentrant calls to work_on_cpu (15 May 2013)
[RFC PATCH v2, part 2 01/18] PCI: introduce hotplug-safe PCI bus itera (14 May 2013)
Seeking advice: Restoring MSI-X after device reset (14 May 2013)
[PATCH 0/2] fix the pci device malfunction if a wrong bus address is a (14 May 2013)
[PATCH v1 1/2] ACPI, PCI: remove unused global list acpi_pci_roots in (14 May 2013)
[PATCH v2] PCI: Reset PCIe devices to stop ongoing DMA (14 May 2013)
[PATCH v2, part 1 0/9] Prepare for introducing PCI bus lock interfaces (13 May 2013)
[PATCH v3 -tip x86/apic 0/2] PCI/MSI: Allocate as many multiple-MSIs a (13 May 2013)
3.8.2: stale pci device info for a previously inserted express card (10 May 2013)
[PATCH] PCI/ACPI: Check acpi_resource_to_address64() return value (9 May 2013)
[GIT PULL] PCI updates for v3.10 (9 May 2013)
Masked MSIs expectations (9 May 2013)
[PATCH] aerdrv: Move cper_print_pcie() out of interrupt context (8 May 2013)

Archives

193	May 2013
484	April 2013
467	March 2013
327	February 2013
486	January 2013
200	December 2012
197	November 2012
337	October 2012
397	September 2012
346	August 2012
317	July 2012
382	June 2012
358	May 2012
383	April 2012
303	March 2012
254	February 2012
266	January 2012
114	December 2011
270	November 2011
272	October 2011
237	September 2011
194	August 2011
115	July 2011
186	June 2011
206	May 2011
147	April 2011
119	March 2011
70	February 2011
95	January 2011
84	December 2010
97	November 2010
166	October 2010
112	September 2010
91	August 2010
122	July 2010
250	June 2010
169	May 2010
329	April 2010
242	March 2010
240	February 2010
396	January 2010
264	December 2009
340	November 2009
238	October 2009
336	September 2009
292	August 2009
227	July 2009
544	June 2009
261	May 2009
314	April 2009
458	March 2009
462	February 2009
441	January 2009
345	December 2008
464	November 2008
605	October 2008
383	September 2008
239	August 2008
354	July 2008
111	June 2008
1	January 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template