> On Jan 31, 2020, at 3:33 PM, Wei Liu <[email protected]> wrote: > > On Fri, Jan 17, 2020 at 02:13:04PM -0500, Rich Persaud wrote: >> On Aug 26, 2019, at 17:08, Pasi Kärkkäinen <[email protected]> wrote: >>> Hi, >>> >>>> On Mon, Oct 08, 2018 at 10:32:45AM -0400, Boris Ostrovsky wrote: >>>>> On 10/3/18 11:51 AM, Pasi Kärkkäinen wrote: >>>>> On Wed, Sep 19, 2018 at 11:05:26AM +0200, Roger Pau Monné wrote: >>>>>> On Tue, Sep 18, 2018 at 02:09:53PM -0400, Boris Ostrovsky wrote: >>>>>>> On 9/18/18 5:32 AM, George Dunlap wrote: >>>>>>>>> On Sep 18, 2018, at 8:15 AM, Pasi Kärkkäinen <[email protected]> wrote: >>>>>>>>> Hi, >>>>>>>>> On Mon, Sep 17, 2018 at 02:06:02PM -0400, Boris Ostrovsky wrote: >>>>>>>>>> What about the toolstack changes? Have they been accepted? I vaguely >>>>>>>>>> recall there was a discussion about those changes but don't remember >>>>>>>>>> how >>>>>>>>>> it ended. >>>>>>>>> I don't think toolstack/libxl patch has been applied yet either. >>>>>>>>> "[PATCH V1 0/1] Xen/Tools: PCI reset using 'reset' SysFS attribute": >>>>>>>>> https://lists.xen.org/archives/html/xen-devel/2017-12/msg00664.html >>>>>>>>> "[PATCH V1 1/1] Xen/libxl: Perform PCI reset using 'reset' SysFS >>>>>>>>> attribute": >>>>>>>>> https://lists.xen.org/archives/html/xen-devel/2017-12/msg00663.html >>>>>>> Will this patch work for *BSD? Roger? >>>>>> At least FreeBSD don't support pci-passthrough, so none of this works >>>>>> ATM. There's no sysfs on BSD, so much of what's in libxl_pci.c will >>>>>> have to be moved to libxl_linux.c when BSD support is added. >>>>> Ok. That sounds like it's OK for the initial pci 'reset' implementation >>>>> in xl/libxl to be linux-only.. >>>> >>>> Are these two patches still needed? ISTR they were written originally >>>> to deal with guest trying to use device that was previously assigned to >>>> another guest. But pcistub_put_pci_dev() calls >>>> __pci_reset_function_locked() which first tries FLR, and it looks like >>>> it was added relatively recently. >>> >>> Replying to an old thread.. I only now realized I forgot to reply to this >>> message earlier. >>> >>> afaik these patches are still needed. Håkon (CC'd) wrote to me in private >>> that >>> he gets a (dom0) Linux kernel crash if he doesn't have these patches >>> applied. >>> >>> >>> Here are the links to both the linux kernel and libxl patches: >>> >>> >>> "[Xen-devel] [PATCH V3 0/2] Xen/PCIback: PCI reset using 'reset' SysFS >>> attribute": >>> https://lists.xen.org/archives/html/xen-devel/2017-12/msg00659.html >>> >>> [Note that PATCH V3 1/2 "Drivers/PCI: Export pcie_has_flr() interface" is >>> already applied in upstream linux kernel, so it's not needed anymore] >>> >>> "[Xen-devel] [PATCH V3 2/2] Xen/PCIback: Implement PCI flr/slot/bus reset >>> with 'reset' SysFS attribute": >>> https://lists.xen.org/archives/html/xen-devel/2017-12/msg00661.html >>> >>> >>> "[Xen-devel] [PATCH V1 0/1] Xen/Tools: PCI reset using 'reset' SysFS >>> attribute": >>> https://lists.xen.org/archives/html/xen-devel/2017-12/msg00664.html >>> >>> "[Xen-devel] [PATCH V1 1/1] Xen/libxl: Perform PCI reset using 'reset' >>> SysFS attribute": >>> https://lists.xen.org/archives/html/xen-devel/2017-12/msg00663.html >> >> [dropping Linux mailing lists] >> >> What is required to get the Xen patches merged? Rebasing against Xen >> master? OpenXT has been carrying a similar patch for many years and >> we would like to move to an upstream implementation. Xen users of PCI >> passthrough would benefit from more reliable device reset. > > Rebase and resend? > > Skimming that thread I think the major concern was backward > compatibility. That seemed to have been addressed. > > Unfortunately I don't have the time to dig into Linux to see if the > claim there is true or not. > > It would be helpful to write a concise paragraph to say why backward > compatibility is not required.
Just going through my old “make sure something happens with this” mails. Did anything ever happen with this? Who has the ball here / who is this stuck on? -George
