linux-kernel - Re: [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset with 'reset' SysFS attribute

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <5A2FFD690200007800196DFB@prv-mh.provo.novell.com>
Date:   Tue, 12 Dec 2017 08:01:45 -0700
From:   "Jan Beulich" <JBeulich@...e.com>
To:     "Govinda Tatti" <Govinda.Tatti@...cle.COM>
Cc:     <roger.pau@...rix.com>, <bhelgaas@...gle.com>,
        <xen-devel@...ts.xenproject.org>, <boris.ostrovsky@...cle.COM>,
        <konrad.wilk@...cle.COM>, "Juergen Gross" <jgross@...e.com>,
        <linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>
Subject: Re: [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus
 reset with 'reset' SysFS attribute

>>> On 12.12.17 at 15:48, <Govinda.Tatti@...cle.COM> 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 rather hard to follow, too.

> --- a/Documentation/ABI/testing/sysfs-driver-pciback
> +++ b/Documentation/ABI/testing/sysfs-driver-pciback
> @@ -11,3 +11,18 @@ 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/reset
> +Date:           Dec 2017
> +KernelVersion:  4.15
> +Contact:        xen-devel@...ts.xenproject.org 
> +Description:
> +                An option to perform a flr/slot/bus reset when a PCI device
> + is owned by Xen PCI backend. Writing a string of DDDD:BB:DD.F  
> SSSS:BB:DD.F (or else the D-s are ambiguous, the more that "domain"
> in Xen code is ambiguous anyway - I continue to be mislead by struct
> pcistub_device_id's domain field)  Thanks for catching this issue. I will 
> fix it.
> 
> 
> Also I assume the SSSS part is optional (default zero), which
> probably can and should be expressed in some way.  SSSS can be 0 or 
> non-zero, subject to system configuration.

The question isn't system configuration, but whether the field can
be omitted on input, with zero being assumed in such a case. That's
a common shorthand, considering that the vast majority of x86
(and maybe other) systems aren't using segments other than zero.

Jan