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

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)

Permalink | Reply | 4 comments |
headers
Chris Wright | 1 Oct 2009 03:17

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
Permalink | Reply | 3 comments |
headers
Thierry Reding | 2 Oct 2009 16:51
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
Permalink | Reply | 4 comments |
headers
Greg KH | 2 Oct 2009 17:03
Gravatar

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
Permalink | Reply | 3 comments |
headers
Thierry Reding | 2 Oct 2009 18:37
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)

Permalink | Reply | 2 comments |
headers
Greg KH | 2 Oct 2009 18:52
Gravatar

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)

Permalink | Reply | 0 comments |
headers
Rolf Eike Beer | 2 Oct 2009 20:16
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)

Permalink | Reply | 0 comments |
headers
Kenji Kaneshige | 5 Oct 2009 02:56
Favicon

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)

Permalink | Reply | 0 comments |
headers
Kenji Kaneshige | 5 Oct 2009 10:39
Favicon

[PATCH 0/6] pciehp driver fixes

Hi,

Here are some pciehp driver fixes.

 - [PATCH 1/6] pciehp: disable DLL state changed event notification
 - [PATCH 2/6] pciehp: remove wrong workaround for bad DLLP
 - [PATCH 3/6] pciehp: create files only for existing capabilities
 - [PATCH 4/6] pciehp: return error on read/write failure
 - [PATCH 5/6] pciehp: fix typo in pciehp_probe
 - [PATCH 6/6] pciehp: prevent unnecessary power off

Please see the header of each patches about details.

Thanks,
Kenji Kaneshige
Permalink | Reply | 7 comments |
headers
Kenji Kaneshige | 5 Oct 2009 10:40
Favicon

[PATCH 1/6] pciehp: disable DLL state changed event notification

Current pciehp doesn't handle Data Link Layer State Changed Event
notification. So it needs to be disabled at initialization time,
otherwise other event notifications are not generated.

Signed-off-by: Kenji Kaneshige <kaneshige.kenji <at> jp.fujitsu.com>

---
 drivers/pci/hotplug/pciehp_hpc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: 20090928/drivers/pci/hotplug/pciehp_hpc.c
===================================================================
--- 20090928.orig/drivers/pci/hotplug/pciehp_hpc.c
+++ 20090928/drivers/pci/hotplug/pciehp_hpc.c
 <at>  <at>  -866,7 +866,8  <at>  <at>  static void pcie_disable_notification(st
 	u16 mask;
 	mask = (PCI_EXP_SLTCTL_PDCE | PCI_EXP_SLTCTL_ABPE |
 		PCI_EXP_SLTCTL_MRLSCE | PCI_EXP_SLTCTL_PFDE |
-		PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_CCIE);
+		PCI_EXP_SLTCTL_HPIE | PCI_EXP_SLTCTL_CCIE |
+		PCI_EXP_SLTCTL_DLLSCE);
 	if (pcie_write_cmd(ctrl, 0, mask))
 		ctrl_warn(ctrl, "Cannot disable software notification\n");
 }
Permalink | Reply | 1 comment |

Gmane