Xen project Mailing List

Re: [Xen-devel] pci-passthrough loses msi-x interrupts ability after domain destroy

[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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

Ross Philipson

_______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel