From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: libxl__device_pci_reset() questions Date: Thu, 19 Feb 2015 15:26:24 +0000 Message-ID: <1424359584.30924.91.camel@citrix.com> References: <54E5FA4E0200007800061AB4@mail.emea.novell.com> <1424356252.30924.66.camel@citrix.com> <92904325.20150219160938@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YOT0T-00089L-V3 for xen-devel@lists.xenproject.org; Thu, 19 Feb 2015 15:27:14 +0000 In-Reply-To: <92904325.20150219160938@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Sander Eikelenboom Cc: Wei Liu , Stefano Stabellini , Ian Jackson , David Vrabel , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, 2015-02-19 at 16:09 +0100, Sander Eikelenboom wrote: > Thursday, February 19, 2015, 3:30:52 PM, you wrote: > > > On Thu, 2015-02-19 at 13:59 +0000, Jan Beulich wrote: > >> All, > >> > >> in the context of someone seeing "The kernel doesn't support reset > >> from sysfs for PCI device", is my understanding correct that the lack > >> of error checking in any caller (perhaps intentional) means that any > >> of the errors logged from this function are really just warnings, i.e. > >> don't prevent the assignment from taking place? > > > It was a long while ago, but I believe that was the intention, yes. > > >> Furthermore I'm puzzled by the function first thing trying to access > >> a "do_flr" file supposedly made available by the pciback driver, yet > >> I can't see either the upstream or the old 2.6.18 driver surfacing > >> such a file. What am I missing here? > > > I'm not sure, on the basis of > > http://lists.xen.org/archives/html/xen-devel/2014-06/msg03105.html and > > http://lists.xen.org/archives/html/xen-devel/2014-07/msg01108.html I've > > added Konrad to the CC. > > You seemed to have missed the actual CC, added now Nope, Konrad's mailman configuration is such that the list copy of the mail ends up with his CC stripped -- that's really a feature of mailman! > and also David who nacked these patches. I didn't know about this. Oh well, I'll let other fight it out as to what the correct approach is. > > The fundamental issue seems to be: > A) Does this even have to be sysfs triggered functionality. The most prominent > reason for this construct with pciback deferring it to the toolstack which in > turn invokes a sysfs to pciback again were issues around locking. > However vfio/virtio also has the bus/slot reset logic and seems to be able to > work around said locking issues. > > B) If it *has* to be done with a sysfs entry, the naming of the sysfs entry > "do_flr" is misleading since it doesn't do an FLR, but hooks up bus/slot > reset. > > That said, i'm running for quite some time now with the mentioned do_flr patches > from Konrad applied, these fix issues with pci devices not being properly reset > when stopping and starting VM's with pci devices passed through. Most > prominently VGA cards (without it they won't work any more after a VM shutdown > and you would have to restart the host (you also see the screen isn't reset to > all black after the VM shuts down.) > > So the functionality is valuable, but it would be nice if the implementation > could be contained within pciback (when a device is being mappend/ unmapped > from a guest) and the sysfs attribute could be dropped (solves the naming issue) > > -- > Sander > > > Ian. > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel