Message-ID: <7110555170.20140805163357@eikelenboom.it>
Date:	Tue, 5 Aug 2014 16:33:57 +0200
From:	Sander Eikelenboom <linux@...elenboom.it>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CC:	David Vrabel <david.vrabel@...rix.com>, gregkh@...uxfoundation.org,
	<boris.ostrovsky@...cle.com>, <xen-devel@...ts.xenproject.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH v5] Fixes to Xen pciback for 3.17.


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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists