From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752676AbdK2Tvf (ORCPT ); Wed, 29 Nov 2017 14:51:35 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:39522 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751980AbdK2Tve (ORCPT ); Wed, 29 Nov 2017 14:51:34 -0500 Subject: Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute To: =?UTF-8?B?UGFzaSBLw6Rya2vDpGluZW4=?= Cc: Jan Beulich , Konrad Wilk , Juergen Gross , xen-devel@lists.xenproject.org, Boris Ostrovsky , 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> <5A1EE1D50200007800193318@prv-mh.provo.novell.com> <20171129180529.GQ20756@reaktio.net> From: Govinda Tatti 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 X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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