On 12/18/2017 6:26 AM, Christoph Hellwig wrote:
On Fri, Dec 15, 2017 at 12:18:02PM -0600, Bjorn Helgaas wrote:
I think Christoph volunteered to do some restructuring, but I don't
know his timeframe. If you can, I would probably wait for that
because there's so much overlap here.
I'll have
On 12/18/2017 6:26 AM, Christoph Hellwig wrote:
On Fri, Dec 15, 2017 at 12:18:02PM -0600, Bjorn Helgaas wrote:
I think Christoph volunteered to do some restructuring, but I don't
know his timeframe. If you can, I would probably wait for that
because there's so much overlap here.
I'll have
Thanks Bjorn for your response. Please see below for my comments.
So, we should consider one of these options.
- set PCI_DEV_FLAGS_NO_FLR_RESET if it is not supported.
- pcie_flr() should return if it is not supported
If we modify pcie_flr() to return error codes, then we need to modify
all
Thanks Bjorn for your response. Please see below for my comments.
So, we should consider one of these options.
- set PCI_DEV_FLAGS_NO_FLR_RESET if it is not supported.
- pcie_flr() should return if it is not supported
If we modify pcie_flr() to return error codes, then we need to modify
all
Jan,
One quick update on pcie_flr() specific implementation. Please see below.
+static int pcistub_device_reset(struct pci_dev *dev)
+{
+ struct xen_pcibk_dev_data *dev_data;
+ bool slot = false, bus = false;
+ struct pcistub_args arg = {};
+
+ if (!dev)
+
Jan,
One quick update on pcie_flr() specific implementation. Please see below.
+static int pcistub_device_reset(struct pci_dev *dev)
+{
+ struct xen_pcibk_dev_data *dev_data;
+ bool slot = false, bus = false;
+ struct pcistub_args arg = {};
+
+ if (!dev)
+
Thanks Bjorn and Christophfor your response. Please see below for my
comments.
On 12/13/2017 3:24 PM, Bjorn Helgaas wrote:
[+cc Christoph]
On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote:
-static bool pcie_has_flr(struct pci_dev *dev)
+bool pcie_has_flr(struct pci_dev *dev
Thanks Bjorn and Christophfor your response. Please see below for my
comments.
On 12/13/2017 3:24 PM, Bjorn Helgaas wrote:
[+cc Christoph]
On Wed, Dec 13, 2017 at 02:46:57PM -0600, Govinda Tatti wrote:
-static bool pcie_has_flr(struct pci_dev *dev)
+bool pcie_has_flr(struct pci_dev *dev
-static bool pcie_has_flr(struct pci_dev *dev)
+bool pcie_has_flr(struct pci_dev *dev)
{
u32 cap;
@@ -3882,6 +3882,7 @@ static bool pcie_has_flr(struct pci_dev *dev)
pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, );
return cap & PCI_EXP_DEVCAP_FLR;
}
-static bool pcie_has_flr(struct pci_dev *dev)
+bool pcie_has_flr(struct pci_dev *dev)
{
u32 cap;
@@ -3882,6 +3882,7 @@ static bool pcie_has_flr(struct pci_dev *dev)
pcie_capability_read_dword(dev, PCI_EXP_DEVCAP, );
return cap & PCI_EXP_DEVCAP_FLR;
}
On 12/12/2017 9:01 AM, Jan Beulich wrote:
On 12.12.17 at 15:48, wrote:
Thanks Jan for your review comments. Please see below for my comments.
First of all - can you please do something about your reply style?
HTML mail should be avoided. You'll see that the (plain
On 12/12/2017 9:01 AM, Jan Beulich wrote:
On 12.12.17 at 15:48, wrote:
Thanks Jan for your review comments. Please see below for my comments.
First of all - can you please do something about your reply style?
HTML mail should be avoided. You'll see that the (plain text) reply
as a result is
Thanks Jan for your review comments. Please see below for my comments.
On 12/8/2017 3:34 AM, Jan Beulich wrote:
On 07.12.17 at 23:21, wrote:
Due to the complexity with the PCI lock we cannot do the reset when a
device is bound ('echo $BDF > bind') or when unbound
Thanks Jan for your review comments. Please see below for my comments.
On 12/8/2017 3:34 AM, Jan Beulich wrote:
On 07.12.17 at 23:21, wrote:
Due to the complexity with the PCI lock we cannot do the reset when a
device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind')
as the
Thanks Bjorn for your review comments. Please see below for my comments.
On 12/8/2017 2:24 PM, Bjorn Helgaas wrote:
On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote:
This patch exports pcie_has_flr() and it is being used by Xen pciback
driver to reset (flr/slot/bus) PCI devices
Thanks Bjorn for your review comments. Please see below for my comments.
On 12/8/2017 2:24 PM, Bjorn Helgaas wrote:
On Thu, Dec 07, 2017 at 05:21:44PM -0500, Govinda Tatti wrote:
This patch exports pcie_has_flr() and it is being used by Xen pciback
driver to reset (flr/slot/bus) PCI devices
This patch exports pcie_has_flr() and it is being used by Xen pciback
driver to reset (flr/slot/bus) PCI devices based on 'reset' SysFS
attribute.
Signed-off-by: Govinda Tatti <govinda.ta...@oracle.com>
---
v3: -New
drivers/pci/pci.c | 3 ++-
include/linux/pci.h | 1 +
2 files chan
ned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti <govinda.ta...@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>
---
v1: - Firs
This patch exports pcie_has_flr() and it is being used by Xen pciback
driver to reset (flr/slot/bus) PCI devices based on 'reset' SysFS
attribute.
Signed-off-by: Govinda Tatti
---
v3: -New
drivers/pci/pci.c | 3 ++-
include/linux/pci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion
ned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Boris Ostrovsky
---
v1: - First posting
v2: - struct pcistub_args: Changed docunt field as unsigned int
- pcistub_reset_dev:
This patch contains Xen pciback driver changes to support PCI reset
(flr/slot/bus) based on SysFS 'reset' attribute. The following Xen
libxl patch depends on these kernel patches.
- Xen/libxl: Perform PCI reset using 'reset' SysFS attribute
Govinda Tatti (2):
Drivers/PCI: Export pcie_has_flr
This patch contains Xen pciback driver changes to support PCI reset
(flr/slot/bus) based on SysFS 'reset' attribute. The following Xen
libxl patch depends on these kernel patches.
- Xen/libxl: Perform PCI reset using 'reset' SysFS attribute
Govinda Tatti (2):
Drivers/PCI: Export pcie_has_flr
Jan,
Do you have any further comments on the current version of this patch?.
Otherwise, I will work on the review comments and publish next version
of this patch later this week. Please let me know. Thanks.
Cheers
GOVINDA
On 12/1/2017 10:16 AM, Govinda Tatti wrote:
On 11/30/2017 8:46 AM
Jan,
Do you have any further comments on the current version of this patch?.
Otherwise, I will work on the review comments and publish next version
of this patch later this week. Please let me know. Thanks.
Cheers
GOVINDA
On 12/1/2017 10:16 AM, Govinda Tatti wrote:
On 11/30/2017 8:46 AM
On 11/30/2017 8:46 AM, Jan Beulich wrote:
On 30.11.17 at 15:15, wrote:
On 11/30/2017 2:27 AM, Jan Beulich wrote:
On 29.11.17 at 18:38, wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The
On 11/30/2017 8:46 AM, Jan Beulich wrote:
On 30.11.17 at 15:15, wrote:
On 11/30/2017 2:27 AM, Jan Beulich wrote:
On 29.11.17 at 18:38, wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function
On 11/30/2017 2:27 AM, Jan Beulich wrote:
On 29.11.17 at 18:38, wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed
On 11/30/2017 2:27 AM, Jan Beulich wrote:
On 29.11.17 at 18:38, wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed irrespective of type of
On 11/30/2017 2:29 AM, Jan Beulich wrote:
On 29.11.17 at 20:44, wrote:
So, we will use the following sequence to reset the requested
device/function.
- FLR (as first option)
- BUS/SLOT reset (as fall-back option) if FLR is not supported or any
issue with FLR
It
On 11/30/2017 2:29 AM, Jan Beulich wrote:
On 29.11.17 at 20:44, wrote:
So, we will use the following sequence to reset the requested
device/function.
- FLR (as first option)
- BUS/SLOT reset (as fall-back option) if FLR is not supported or any
issue with FLR
It looks to me as if the slot
On 11/29/2017 12:05 PM, Pasi Kärkkäinen wrote:
On Wed, Nov 29, 2017 at 11:25:09AM -0600, Govinda Tatti wrote:
Furthermore, contrary to what you claim in
your reply to Pasi, I can't see where you try an actual FLR first -
you go straight to pci_probe_reset_{slot,bus}(). If you actually
tried
On 11/29/2017 12:05 PM, Pasi Kärkkäinen wrote:
On Wed, Nov 29, 2017 at 11:25:09AM -0600, Govinda Tatti wrote:
Furthermore, contrary to what you claim in
your reply to Pasi, I can't see where you try an actual FLR first -
you go straight to pci_probe_reset_{slot,bus}(). If you actually
tried
Thanks Konrad for your response. Please see below for my comments.
Well, that's more a question to Konrad as the maintainer.
Personally I'd prefer just "reset", as "pci" is redundant and "bus"
Can't do 'reset'.
Why?
B/c I forgot that this attribute is not per device, but on the module
Thanks Konrad for your response. Please see below for my comments.
Well, that's more a question to Konrad as the maintainer.
Personally I'd prefer just "reset", as "pci" is redundant and "bus"
Can't do 'reset'.
Why?
B/c I forgot that this attribute is not per device, but on the module
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed irrespective of type of reset being used.
I don't follow: The scope of other devices/functions
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed irrespective of type of reset being used.
I don't follow: The scope of other devices/functions
Furthermore, contrary to what you claim in
your reply to Pasi, I can't see where you try an actual FLR first -
you go straight to pci_probe_reset_{slot,bus}(). If you actually
tried FLR first, only falling back to the other methods as "emulation",
I could certainly agree with the file name
Furthermore, contrary to what you claim in
your reply to Pasi, I can't see where you try an actual FLR first -
you go straight to pci_probe_reset_{slot,bus}(). If you actually
tried FLR first, only falling back to the other methods as "emulation",
I could certainly agree with the file name
Jan,
Please see below for my comments.
On 11/9/2017 2:49 AM, Jan Beulich wrote:
On 09.11.17 at 00:06, wrote:
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -244,6 +244,91 @@ struct pci_dev *pcistub_get_pci_dev(struct
Jan,
Please see below for my comments.
On 11/9/2017 2:49 AM, Jan Beulich wrote:
On 09.11.17 at 00:06, wrote:
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -244,6 +244,91 @@ struct pci_dev *pcistub_get_pci_dev(struct
xen_pcibk_device *pdev,
Jan,
Sorry for the late response. Please see below for my comments.
On 11/9/2017 2:28 AM, Jan Beulich wrote:
On 08.11.17 at 16:44, wrote:
On 11/7/2017 8:40 AM, Jan Beulich wrote:
On 06.11.17 at 18:48, wrote:
---
Jan,
Sorry for the late response. Please see below for my comments.
On 11/9/2017 2:28 AM, Jan Beulich wrote:
On 08.11.17 at 16:44, wrote:
On 11/7/2017 8:40 AM, Jan Beulich wrote:
On 06.11.17 at 18:48, wrote:
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++
Thanks Pasi for your response. Please see below for my comments.
On 11/8/2017 11:38 AM, Pasi Kärkkäinen wrote:
Hi,
On Wed, Nov 08, 2017 at 09:44:48AM -0600, Govinda Tatti wrote:
Thanks Jan for your review comments. Please see below for my comments.
On 11/7/2017 8:40 AM, Jan Beulich wrote
Thanks Pasi for your response. Please see below for my comments.
On 11/8/2017 11:38 AM, Pasi Kärkkäinen wrote:
Hi,
On Wed, Nov 08, 2017 at 09:44:48AM -0600, Govinda Tatti wrote:
Thanks Jan for your review comments. Please see below for my comments.
On 11/7/2017 8:40 AM, Jan Beulich wrote
ck) prior to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti <govinda.ta...@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Reviewe
ck) prior to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Boris Ostrovsky
---
Documentation/ABI/testing/sysfs-drive
Thanks Jan for your review comments. Please see below for my comments.
On 11/7/2017 8:40 AM, Jan Beulich wrote:
On 06.11.17 at 18:48, wrote:
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@
Thanks Jan for your review comments. Please see below for my comments.
On 11/7/2017 8:40 AM, Jan Beulich wrote:
On 06.11.17 at 18:48, wrote:
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@ Description:
On 11/8/2017 9:09 AM, Juergen Gross wrote:
On 08/11/17 16:00, Govinda Tatti wrote:
Thanks Roger for your review comments. Please see below for my comments.
On 11/7/2017 5:21 AM, Roger Pau Monné wrote:
On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:
+out:
+ if (!err
On 11/8/2017 9:09 AM, Juergen Gross wrote:
On 08/11/17 16:00, Govinda Tatti wrote:
Thanks Roger for your review comments. Please see below for my comments.
On 11/7/2017 5:21 AM, Roger Pau Monné wrote:
On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:
+out:
+ if (!err
Thanks Roger for your review comments. Please see below for my comments.
On 11/7/2017 5:21 AM, Roger Pau Monné wrote:
On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:
The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism
Thanks Roger for your review comments. Please see below for my comments.
On 11/7/2017 5:21 AM, Roger Pau Monné wrote:
On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:
The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism
ck) prior to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti <govinda.ta...@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
Reviewe
ck) prior to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.
Signed-off-by: Govinda Tatti
Signed-off-by: Konrad Rzeszutek Wilk
Reviewed-by: Boris Ostrovsky
---
Documentation/ABI/testing/sysfs-drive
54 matches
Mail list logo