Kay, Allen M | 1 Oct 01:33 2009
Picon

RE: [PATCH ACS v3 1/1]

>
> I did not generateany errors to see if AER is working, did you?
>

No, I believe AER RC interrupts are turned off by default.  I can try to turn it on to see if I see anything.

> This means adding direct translated P2P support, no?

Yes, I believe PCIe switches will need to be enhanced to differentiate between transactions with
translated addresses and un-translated addresses to support P2P.

>
> And what does the device cache when the IOMMU is in PT mode?  I'm mainly voicing concern
> about the non-IOV case (i.e. common case) that this impacts by enabling as a default.
>

I don't think device caches translation when VT-d is in PT mode.

On the other hand, can we say VT-d PT mode is mainly for KVM virtualization use case?  If so, is it reasonable to
say performance of host P2P in this mode is not of highest priority?

If not, another option is to have a kernel boot parameter to configure an kernel boot instance to be either
host kernel optimized or virtualization optimized.  I don't know whether this is a reasonable or not ...

-----Original Message-----
From: linux-pci-owner <at> vger.kernel.org [mailto:linux-pci-owner <at> vger.kernel.org] On Behalf Of
Chris Wright
Sent: Tuesday, September 29, 2009 11:47 AM
To: Kay, Allen M
Cc: Chris Wright; linux-kernel <at> vger.kernel.org; linux-pci <at> vger.kernel.org;
(Continue reading)

Chris Wright | 1 Oct 03:17 2009

Re: [PATCH ACS v3 1/1]

* Kay, Allen M (allen.m.kay <at> intel.com) wrote:
> On the other hand, can we say VT-d PT mode is mainly for KVM
> virtualization use case?  If so, is it reasonable to say performance of
> host P2P in this mode is not of highest priority?

Guess it depends on the workload.  Would be helpful to identify a use
case that is p2p heavy (and then the impact of enabling ACS).

> If not, another option is to have a kernel boot parameter to
> configure an kernel boot instance to be either host kernel optimized or
> virtualization optimized.  I don't know whether this is a reasonable or
> not ...

I was thinking that ACS could be enabled if an IOMMU is enabled.  Not a
perfect fit, but seems reasonably close.

thanks,
-chris
Thierry Reding | 2 Oct 16:51 2009
Picon

unregistered PCI vendor and device IDs

Hi,

I'm currently working on a platform that comes with an FPGA connected to the
CPU via a PCIe interface The FPGA will eventually integrate several IP cores,
some of them being open (OpenCores). I would like to mainline any drivers for
those cores, but that raises the problem of the vendor ID. Is there any
procedure for providing Linux drivers supporting devices which do not have a
registered vendor and/or device ID?

Would it be acceptable to make vendor and device IDs configurable via
Kconfig?

Cheers,
Thierry
Greg KH | 2 Oct 17:03 2009

Re: unregistered PCI vendor and device IDs

On Fri, Oct 02, 2009 at 04:51:21PM +0200, Thierry Reding wrote:
> Hi,
> 
> I'm currently working on a platform that comes with an FPGA connected to the
> CPU via a PCIe interface The FPGA will eventually integrate several IP cores,
> some of them being open (OpenCores). I would like to mainline any drivers for
> those cores, but that raises the problem of the vendor ID. Is there any
> procedure for providing Linux drivers supporting devices which do not have a
> registered vendor and/or device ID?

Why do you not have a registered vendor device id?  You aren't "allowed"
to create a PCI device without one from what I can tell.

> Would it be acceptable to make vendor and device IDs configurable via
> Kconfig?

You can dynamically add vendor/device ids to drivers from userspace
today, no need to build it in through Kconfig selections.

thanks,

greg k-h
Thierry Reding | 2 Oct 18:37 2009
Picon

Re: unregistered PCI vendor and device IDs

* Greg KH wrote:
> On Fri, Oct 02, 2009 at 04:51:21PM +0200, Thierry Reding wrote:
> > Hi,
> > 
> > I'm currently working on a platform that comes with an FPGA connected to the
> > CPU via a PCIe interface The FPGA will eventually integrate several IP cores,
> > some of them being open (OpenCores). I would like to mainline any drivers for
> > those cores, but that raises the problem of the vendor ID. Is there any
> > procedure for providing Linux drivers supporting devices which do not have a
> > registered vendor and/or device ID?
> 
> Why do you not have a registered vendor device id?  You aren't "allowed"
> to create a PCI device without one from what I can tell.

Because my employer has never had a need for one before. The devices will be
embedded and from what I hear it seems common practice to just assign vendor
and device IDs at random in embedded devices. The reason being that the
hardware is always known and there won't be any ID clashes.

In this particular case it would also not be correct to specify our vendor ID
(assuming we actually had one) since some of the IP cores were not developed
in-house and are in fact open.

> > Would it be acceptable to make vendor and device IDs configurable via
> > Kconfig?
> 
> You can dynamically add vendor/device ids to drivers from userspace
> today, no need to build it in through Kconfig selections.

Great, that would be a good alternative then. Would it be acceptable to
(Continue reading)

Greg KH | 2 Oct 18:52 2009

Re: unregistered PCI vendor and device IDs

On Fri, Oct 02, 2009 at 06:37:12PM +0200, Thierry Reding wrote:
> * Greg KH wrote:
> > On Fri, Oct 02, 2009 at 04:51:21PM +0200, Thierry Reding wrote:
> > > Hi,
> > > 
> > > I'm currently working on a platform that comes with an FPGA connected to the
> > > CPU via a PCIe interface The FPGA will eventually integrate several IP cores,
> > > some of them being open (OpenCores). I would like to mainline any drivers for
> > > those cores, but that raises the problem of the vendor ID. Is there any
> > > procedure for providing Linux drivers supporting devices which do not have a
> > > registered vendor and/or device ID?
> > 
> > Why do you not have a registered vendor device id?  You aren't "allowed"
> > to create a PCI device without one from what I can tell.
> 
> Because my employer has never had a need for one before. The devices will be
> embedded and from what I hear it seems common practice to just assign vendor
> and device IDs at random in embedded devices. The reason being that the
> hardware is always known and there won't be any ID clashes.

Heh, I can't wait for the PCI-SIG to find out about that :)

> > > Would it be acceptable to make vendor and device IDs configurable via
> > > Kconfig?
> > 
> > You can dynamically add vendor/device ids to drivers from userspace
> > today, no need to build it in through Kconfig selections.
> 
> Great, that would be a good alternative then. Would it be acceptable to
> mainline the drivers without a predefined vendor/device ID pair and add
(Continue reading)

Rolf Eike Beer | 2 Oct 20:16 2009
Picon

Re: unregistered PCI vendor and device IDs

Thierry Reding wrote:
> * Greg KH wrote:
> > On Fri, Oct 02, 2009 at 04:51:21PM +0200, Thierry Reding wrote:
> > > Hi,
> > >
> > > I'm currently working on a platform that comes with an FPGA connected
> > > to the CPU via a PCIe interface The FPGA will eventually integrate
> > > several IP cores, some of them being open (OpenCores). I would like to
> > > mainline any drivers for those cores, but that raises the problem of
> > > the vendor ID. Is there any procedure for providing Linux drivers
> > > supporting devices which do not have a registered vendor and/or device
> > > ID?
> >
> > Why do you not have a registered vendor device id?  You aren't "allowed"
> > to create a PCI device without one from what I can tell.
> 
> Because my employer has never had a need for one before. The devices will
>  be embedded and from what I hear it seems common practice to just assign
>  vendor and device IDs at random in embedded devices. The reason being that
>  the hardware is always known and there won't be any ID clashes.
> 
> In this particular case it would also not be correct to specify our vendor
>  ID (assuming we actually had one) since some of the IP cores were not
>  developed in-house and are in fact open.

You could ask your FPGA vendor if they will give you one of their device ids. 
Our company got our first device ids for our PCIe boards that way before we 
applied for our own id at PCI SIG.

Greetings,
(Continue reading)

Stephen Boyd | 3 Oct 06:15 2009
Picon

[PATCH] pci/dmar: add __init annotation to dmar_ir_support()

dmar_ir_support() references dmar_tbl which is annotated with
__initdata. The only caller of dmar_ir_support() is
intr_remapping_supported() also annotated with __init.

WARNING: drivers/pci/built-in.o(.text+0xa110): Section mismatch in
reference from the function dmar_ir_support() to the variable
.init.data:dmar_tbl
The function dmar_ir_support() references
the variable __initdata dmar_tbl.
This is often because dmar_ir_support lacks a __initdata
annotation or the annotation of dmar_tbl is wrong.

Signed-off-by: Stephen Boyd <bebarino <at> gmail.com>
---
 drivers/pci/dmar.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/pci/dmar.c b/drivers/pci/dmar.c
index 14bbaa1..fbca5e7 100644
--- a/drivers/pci/dmar.c
+++ b/drivers/pci/dmar.c
 <at>  <at>  -1327,7 +1327,7  <at>  <at>  int dmar_reenable_qi(struct intel_iommu *iommu)
 /*
  * Check interrupt remapping support in DMAR table description.
  */
-int dmar_ir_support(void)
+int __init dmar_ir_support(void)
 {
 	struct acpi_table_dmar *dmar;
 	dmar = (struct acpi_table_dmar *)dmar_tbl;
(Continue reading)

Rafael J. Wysocki | 5 Oct 00:48 2009
Picon

[Resend][PATCH] PCI PM: Read device power state from register after updating it

From: Rafael J. Wysocki <rjw <at> sisk.pl>

After attempting to change the power state of a PCI device
pci_raw_set_power_state() doesn't check if the value it wrote into
the device's PCI_PM_CTRL register has been stored in there, but
unconditionally modifies the device's current_state field to reflect
the change.  This may cause problems to happen if the power state of
the device hasn't been changed in fact, because it will make the PCI
PM core make a wrong assumption.

To prevent such situations from happening modify
pci_raw_set_power_state() so that it reads the device's PCI_PM_CTRL
register after writing into it and uses the value read from the
register to update the device's current_state field.  Also make it
print a message saying that the device refused to change its power
state as requested (returning an error code in such cases would cause
suspend regressions to appear on some systems, where device drivers'
suspend routines return error codes if pci_set_power_state() fails).

Signed-off-by: Rafael J. Wysocki <rjw <at> sisk.pl>
---
 drivers/pci/pci.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
 <at>  <at>  -513,7 +513,11  <at>  <at>  static int pci_raw_set_power_state(struc
 	else if (state == PCI_D2 || dev->current_state == PCI_D2)
(Continue reading)

Kenji Kaneshige | 5 Oct 02:56 2009

Re: [PATCH] PCIe hotplug: decline to manage slots under HP PCIe host bridge

Bjorn Helgaas wrote:
> This patch prevents the use of PCIe native hotplug on slots below certain
> HP PCIe host bridges.
> 
> A silicon defect in these host bridges causes a machine check after
> powering on certain devices.  The ACPI hotplug methods contain workarounds
> for the defect, so ACPI hotplug works correctly.
> 
> The pciehp driver requests permission to use PCI Express native hotplug by
> using _OSC; I think the firmware should have refused that request.  Since
> firmware grants the request, we have to work around it by hand.
> 
> See HP internal defect RS1899.  MCA observed with a QLogic ISP2432 4Gb HBA
> (firmware 4.00.70) in slot 5 of an HP rx3600 (system firmware 04.11) with
> a PCIe backplane.  Slot 5 is directly connected to the PCIe host bridge.
> The MCA does not occur with the QLogic HBA in slot 3, which has an IDT
> switch between the host bridge and the HBA.
> 
> Signed-off-by: Bjorn Helgaas <bjorn.helgaas <at> hp.com>
> ---
>  drivers/pci/hotplug/acpi_pcihp.c |   22 +++++++++++++++++++++-
>  1 files changed, 21 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/pci/hotplug/acpi_pcihp.c b/drivers/pci/hotplug/acpi_pcihp.c
> index a73028e..24e6687 100644
> --- a/drivers/pci/hotplug/acpi_pcihp.c
> +++ b/drivers/pci/hotplug/acpi_pcihp.c
>  <at>  <at>  -324,6 +324,26  <at>  <at>  int pci_get_hp_params(struct pci_dev *dev, struct hotplug_params *hpp)
>  }
>  EXPORT_SYMBOL_GPL(pci_get_hp_params);
(Continue reading)


Gmane