Messages in this thread | | | Date | Wed, 29 Nov 2017 20:05:29 +0200 | From | Pasi Kärkkäinen <> | Subject | Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute |
| |
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? What if there are other devices in the same bus, wouldn't automatic bus reset be a bad thing?
Or should the reset-method be configured by the user for the VM / PCI device ?
Just thinking out loud here..
> Cheers > GOVINDA >
Thanks,
-- Pasi
| |