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:
On 06.11.17 at 18:48, <govinda.ta...@oracle.com> wrote:
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@ Description:
#echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
will allow the guest to read and write to the configuration
register 0x0E.
+
+What: /sys/bus/pci/drivers/pciback/do_flr
+Date: Nov 2017
+KernelVersion: 4.15
+Contact: xen-de...@lists.xenproject.org
+Description:
+ An option to perform a slot or bus reset when a PCI device
+ is owned by Xen PCI backend. Writing a string of DDDD:BB:DD.F
+ will cause the pciback driver to perform a slot or bus reset
+ if the device supports it. It also checks to make sure that
+ all of the devices under the bridge are owned by Xen PCI
+ backend.
Why do you name this "do_flr" when you don't even try FLR, but
go to slot or then bus reset right away.
Yes, I agree but xen toolstack has already been modified to consume"do_flr"
attribute. Hence, we are using the
function that matches with sysfs attribute.
Hmm.. I remember some discussion from ages ago related to this.
Back then it was suggested to "emulate" the flr capability (by doing slot or
bus reset) for devices which don't have *native* flr available? So is this patch perhaps
related to that?
I don't think so but either Konrad or someone can comment on it.
If the PCI device in question has native flr capability, then native flr is
used, right ?
Yes.
I guess I should read the full patch..
Please check it and let us know your comments.
Cheers
GOVINDA
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel