From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ruediger Otte Subject: Re: [RFC PATCH] Xen PCI back - do slot and bus reset (v0). Date: Thu, 5 Jun 2014 00:15:04 +0200 Message-ID: <20140605001504.0b12344a@dox64> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Konrad Rzeszutek Wilk , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Hi, this patch actually solves the problem I experienced when trying to passthrough a Radeon 7750 to a windows guest with a custom build of Xen 4.4.0 on Debian Wheezy. While I was always getting dom0 lockups at the first reboot of the guest, I'm now able to do several reboots without sending the host to standby in between. I haven't done extensive testing yet, but gpu passthrough seems to just work now. However I'm now seeing a different issue at dom0 boot when the devices are assigned to xen-pciback (in kernel, no module). After the message "xen_pciback: backend is passthrough" the host hangs for 2-3 seconds, then reboots. Strangely sometimes the host just boots ok, but then again I get three or more failed boots in a row before it finally works. Before I applied your patch I have already followed every hint and tried every available workaround with no success so far, so I would be glad if this code could be further improved. If there's the need I can of course provide debug output and configuration details from my setup. Kind regards, Ruediger Otte > Hey, > > While I was trying to narrow down the state of GPU passthrough > (still not finished) and figuring what needs to be done I realized > that Xen PCIback did not reset my GPU properly (when I crashed the > Windows guest by mistake). It does an FLR reset or Power one - if > the device supports it. But it seems that some of these GPUs > are liars and actually don't do the power part properly. > > One way to fix this is by doing a slot (aka device) and bus reset. > Of course to do that - you need to make sure that all of the > functions of a device are under the ownership of xen-pciback. > Otherwise you might accidently reset your sound card while it is > being used. > > These RFC patches cleanup pci back a bit and also make it possible > for Xen pciback to do the whole gamma of 'reset' for PCI devices: > FLR, power management, AER, slot and bus reset if neccessary. > > Thanks go to Gordan Bobic for educating me on how to "reprogram" > and GFX460 in a Quardro 4000M and also reporting oddities when > a PCI device was reset but it looked like it was not reset. > > > drivers/xen/xen-pciback/pci_stub.c | 142 > +++++++++++++++++++++++++++++++------ > drivers/xen/xen-pciback/xenbus.c | 5 +- 2 files changed, 124 > insertions(+), 23 deletions(-) > > > Konrad Rzeszutek Wilk (5): > xen-pciback: Cleanup up pcistub_put_pci_dev > xen-pciback: First reset, then free. > xen-pciback: Document when we FLR an PCI device. > xen/pciback: Move the FLR code to a function. > xen/pciback: PCI reset slot or bus