Tuesday, August 5, 2014, 3:49:30 PM, you wrote: > On Tue, Aug 05, 2014 at 11:44:33AM +0200, Sander Eikelenboom wrote: >> >> Tuesday, August 5, 2014, 11:31:08 AM, you wrote: >> >> > On 05/08/14 09:44, Sander Eikelenboom wrote: >> >> >> >> Monday, August 4, 2014, 8:43:18 PM, you wrote: >> >> >> >>> On Fri, Aug 01, 2014 at 04:30:05PM +0100, David Vrabel wrote: >> >>>> On 14/07/14 17:18, Konrad Rzeszutek Wilk wrote: >> >>>>> Greg: goto GHK >> >>>>> >> >>>>> This is v5 version of patches to fix some issues in Xen PCIback. >> >>>> >> >>>> Applied to devel/for-linus-3.17. >> >> >> >>> Thank you. >> >>>> >> >>>> I dropped the stable Cc for #2 pending a final decision on whether it >> >>>> really is a stable candidate. >> >> >> >>> OK. >> >>>> >> >>>> David >> >> >> >> Hi Konrad / David, >> >> >> >> This series still lacks a resolution on the sysfs /do_flr /reset, >> >> as a result the pci devices are not reset after shutdown of a guest. >> >> (no more pciback 0000:xx:xx.x: restoring config space at offset xxx) >> >> >> >> So this series now introduces a regression to 3.16, which causes devices >> >> to malfunction >> >> after a guest reboot or after assigning the devices to another guest. >> >> > I don't follow what you're saying. The lack of a device reset for PCI >> > devices with no FLR method isn't a regression as this has never worked. >> > Can you explain in more detail what the regression is and which patch >> > caused it? >> >> I haven't bisected it to a specific patch in this series, >> but this patch series (when pulled on top of 3.16) cause the following: >> >> - Do a system start and HVM guest start >> - HVM guest with pci passthrough, devices work fine >> - shutdown the HVM guest >> - "pciback 0000:xx:xx.x: restoring config space at offset xxx" messages do >> not >> appear anymore when shutting down the HVM guest (as they do with vanilla >> 3.16) >> - Starting the HVM guest again with the same devices passed through. >> - Devices malfunction (for example a USB host controller will fail a simple >> "lsusb" >> - And this all works fine on vanilla 3.16.
> Hm, the only patch that makes code changes is > 63fc5ec97cc54257d1c4ee49ed2131f754a5ff9b > "xen/pciback: Don't deadlock when unbinding." > but it does not change any of that code path. Only figures out whether > to take a lock or not. > I will try it out on my box and see if I can reproduce it. > And just to be 100% sure - you are using vanilla Xen? No changes on top > of it? BTW could it have anything to do with the do_flr patch that went into Xen: (http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ab78724fc5628318b172b4344f7280621a151e1b) And isn't into linux yet .. and somehow the old code not having a problem with that but the new (after the patch series with the linux do_flr patch) has ? > Thanks! >> >> >> Apart from that .. i can't resist to remind the other issue with removing >> >> pci >> >> devices passed through to HVM guests related to the signaling via >> >> xenstore, >> >> described in: >> >> >> >> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01875.html >> >> > I don't remember seeing you posting a patch...? > I was going to, but I think we need to figure out the 'do_flr' mechanism > first. >> >> > David >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
