[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute





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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.