Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset
 with 'do_flr' SysFS attribute
To:     =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= <pasik@iki.fi>
Cc:     Jan Beulich <JBeulich@suse.com>,
        Konrad Wilk <konrad.wilk@oracle.com>,
        Juergen Gross <jgross@suse.com>,
        xen-devel@lists.xenproject.org,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        linux-kernel@vger.kernel.org
References: <20171106174842.20276-1-Govinda.Tatti@Oracle.COM>
 <5A01D3F3020000780018CE86@prv-mh.provo.novell.com>
 <8940b38d-715c-9fcb-cc74-46574d416703@oracle.com>
 <5A041FB9020000780018D6E8@prv-mh.provo.novell.com>
 <af25e0d8-ca55-7eb4-649e-5297b0e09299@oracle.com>
 <5A1EE1D50200007800193318@prv-mh.provo.novell.com>
 <fb6d3c3b-2fba-1903-d3b1-bf7aeefd7ee8@oracle.com>
 <20171129180529.GQ20756@reaktio.net>
From:   Govinda Tatti <govinda.tatti@oracle.com>
Organization: Oracle Corporation
Message-ID: <6a28becf-8142-9fcb-71a8-583ea69001ee@oracle.com>
Date:   Wed, 29 Nov 2017 13:51:06 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20171129180529.GQ20756@reaktio.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


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 FLR first, only falling back to the other methods as "emulation",
>>>>> I could certainly agree with the file name chosen.
>>>> Currently, multiple resets are being invoked (independently) in the context
>>>> of "xl attach/detach/shutdown/reboot".
>>>>
>>>> - pci_reset_function_locked (invoked by pcistub_put_pci_dev())
>>>>     This function tries various PCI reset methods including FLR.
>>>> - pcistub_reset_dev (called by toolsstack based on "do_flr" attribute)
>>> While related in a certain way, I can't really see how this addresses
>>> the comment.
>> pcistub_reset_dev() just tries slot or bus reset but not FLR since it is
>> being
>> checked and executed by pci_reset_function_locked() if supported. May be we
>> can
>> add FLR reset code to pcistub_reset_dev() and try FLR first before fall-back
>> to
>> slot/bus reset.
>>
> Hmm.. is the suitable reset method something that can be figured out automatically?
>
> I mean if FLR is tried first, but it isn't supported by the device, is it OK to go ahead and do a slot/bus reset automatically?
Yes, we are moving in the same direction.

> What if there are other devices in the same bus, wouldn't automatic bus reset be a bad thing?
We will perform BUS or SLOT reset only if all device/functions behind 
the bus/slot are owned by pcistub.
Otherwise, we will skipthis reset.

> Or should the reset-method be configured by the user for the VM / PCI device ?
>
> Just thinking out loud here..
>

Cheers
GOVINDA

From 1585430974095385005@xxx Wed Nov 29 19:46:40 +0000 2017
X-GM-THRID: 1583346318922306893
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread