From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Regression in kernel 3.5 as Dom0 regarding PCI Passthrough?! Date: Wed, 5 Sep 2012 14:54:12 -0400 Message-ID: <20120905185412.GA27077@phenom.dumpdata.com> References: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1B4B44D9196EFF41AE41FDA404FC0A101881CE@SHSMSX101.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Ren, Yongjie" Cc: Konrad Rzeszutek Wilk , Tobias Geiger , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org > > > > And its due to a patch I added in v3.4 > > > > (cd9db80e5257682a7f7ab245a2459648b3c8d268) > > > > - which did not work properly in v3.4, but with v3.5 got it working > > > > (977f857ca566a1e68045fcbb7cfc9c4acb077cf0) which causes v3.5 to > > now > > > > work > > > > anymore. > > > > > > > > Anyhow, for right now jsut revert > > > > cd9db80e5257682a7f7ab245a2459648b3c8d268 > > > > and it should work for you. > > > > > Confirmed, after reverting that commit, VT-d will work fine. > Will you fix this and push it to upstream Linux, Konrad? > > > > Also, our team reported a VT-d bug 2 months ago. > > > http://bugzilla.xen.org/bugzilla/show_bug.cgi?id=1824 > > Can either one of you please test this patch, please: diff --git a/drivers/xen/xen-pciback/pci_stub.c b/drivers/xen/xen-pciback/pci_stub.c index 097e536..425bd0b 100644 --- a/drivers/xen/xen-pciback/pci_stub.c +++ b/drivers/xen/xen-pciback/pci_stub.c @@ -4,6 +4,8 @@ * Ryan Wilson * Chris Bookholt */ +#define DEBUG 1 + #include #include #include @@ -97,13 +99,15 @@ static void pcistub_device_release(struct kref *kref) /* Call the reset function which does not take lock as this * is called from "unbind" which takes a device_lock mutex. */ + dev_dbg(&psdev->dev->dev, "FLR locked..\n"); __pci_reset_function_locked(psdev->dev); if (pci_load_and_free_saved_state(psdev->dev, &dev_data->pci_saved_state)) { dev_dbg(&psdev->dev->dev, "Could not reload PCI state\n"); - } else + } else { + dev_dbg(&psdev->dev->dev, "Reloading PCI state..\n"); pci_restore_state(psdev->dev); - + } /* Disable the device */ xen_pcibk_reset_device(psdev->dev); @@ -353,16 +357,16 @@ static int __devinit pcistub_init_device(struct pci_dev *dev) if (err) goto config_release; - dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n"); - __pci_reset_function_locked(dev); - /* We need the device active to save the state. */ dev_dbg(&dev->dev, "save state of device\n"); pci_save_state(dev); dev_data->pci_saved_state = pci_store_saved_state(dev); if (!dev_data->pci_saved_state) dev_err(&dev->dev, "Could not store PCI conf saved state!\n"); - + else { + dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n"); + __pci_reset_function_locked(dev); + } /* Now disable the device (this also ensures some private device * data is setup before we export) */