> > [snip] > > > > So i think David's NACK was mostly for the patchset having some hackish > cosmetics. > > He didn't like 'do_flr' which made sense as the patchset did not do FLR. > It made a bus-reset > for more than one device (if those devices were assigned to pciback). >
When I first wrote this, FLR was not yet implemented in the kernel so I was actually adding FLR support; thus the name do_flr. So that is just cargo from years ago :) > > > > > On the upside one can conclude that this patchset is now pretty well > tested over the years ;) > > > > Since David has left, perhaps Jurgen/Boris/Konrad could express their > views (again) ? > > (CC'ed them as well) > > I've asked Govinda (CC-ed) to refresh the patchset against the lastest > kernel and > repost it and see where it goes. > > > > > > As noted in the original LKML threads, vfio has similar relevant pci > > > device reset retry logic. (Thanks to Rich Persaud for this pointer:) > > > http://elixir.free-electrons.com/linux/v4.14-rc1/source/ > drivers/vfio/pci/vfio_pci.c#L1353 > > > > > > libvirt also performs similar reset logic, using a direct low level > > > interface to config space (Thanks to Marek for this pointer, libvirt > > > is used by Qubes:) > > > https://github.com/libvirt/libvirt/blob/master/src/util/virpci.c#L929 > > > I thinks this indicates that it would be possible to extend libxl to > > > do something similar, but that seems less satisfactory compared to > > > performing the work in a kernel-provided implementation. > > > > > > Is there a way forward to providing this functionality within Xen > > > software or Linux> Christopher > > > -- > > > > > > openxt.org > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > https://lists.xen.org/xen-devel > -- Ross Philipson
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
