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,
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:
---
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
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: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/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
Any comments on this patch?. Thanks.
On 12/7/2017 4:26 PM, Govinda Tatti wrote:
The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism.
- It starts with the device being bound to us, for which we do a function
reset (done via SysFS
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
Are you saying do_flr doesn't exist at all in any version of Linux,
and as such the line you're removing is currently pointless?
Yes, that's correct. In other-words, it will not break any existing code
or functionality.
Except for people, like me, running unofficial patches to linux. It
should
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 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
-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;
}
This patch contains Xen/libxl specific changes to support PCI reset
(flr/slot/bus) in Xen pciback driver based on SysFS 'reset' attribute.
It depends on the following kernel patch.
- Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS
attribute
Govinda Tatti (1):
Xen/libxl
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 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>
---
v1: -New
tools/libxl/libxl_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_pci.c b/tools/li
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
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
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
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
22 matches
Mail list logo