[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fb6d3c3b-2fba-1903-d3b1-bf7aeefd7ee8@oracle.com>
Date: Wed, 29 Nov 2017 11:25:09 -0600
From: Govinda Tatti <govinda.tatti@...cle.com>
To: Jan Beulich <JBeulich@...e.com>,
Konrad Wilk <konrad.wilk@...cle.com>
Cc: Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
linux-kernel@...r.kernel.org
Subject: Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset
with 'do_flr' SysFS attribute
>>> 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.
Cheers
GOVINDA
Powered by blists - more mailing lists