From nobody Mon Feb 9 00:55:42 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1617806248; cv=none; d=zohomail.com; s=zohoarc; b=TlPjAvsnyBYBq1Aw9QSXlIyb4dICMWOXctWOcrLwpRSHqJG+omY1Pvlh0yQ465xqdXJ2Yp3rusoh+36e0+OroSsdbSdZ6+vkV+RyVlySG+tma4jqVNzGnrM1TVjejCoOzRZ16DqwdDXsFfmqDFd86+VE/bJqJvwbQl++OFu1JkA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1617806248; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=RVTfOHZt+5GTfUvqHRoOkSW+lbhVxEv08w2Zo444uTE=; b=Q28zcuHtq2XPtF6koV+uWnafzCTN9GZYiqCqSczxnhXtyh5cEcFKEPJe6hVbkMFaRBY0A/tEc+ABO343SPQEbjPlz2PTZFzwgehcfVCLvlBRBe5g6ckFLJeWnDgs/e4y8gV1tHTGzoQFsuvz8bUYOc7ZId3/gSALXRnD/yp/6W4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1617806248958211.9767805848445; Wed, 7 Apr 2021 07:37:28 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.106710.204034 (Exim 4.92) (envelope-from ) id 1lU9Iu-0000ID-QL; Wed, 07 Apr 2021 14:37:12 +0000 Received: by outflank-mailman (output) from mailman id 106710.204034; Wed, 07 Apr 2021 14:37:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lU9Iu-0000I6-NP; Wed, 07 Apr 2021 14:37:12 +0000 Received: by outflank-mailman (input) for mailman id 106710; Wed, 07 Apr 2021 14:37:10 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lU9Is-0000I0-P0 for xen-devel@lists.xenproject.org; Wed, 07 Apr 2021 14:37:10 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id ad8feeeb-105d-4109-9eac-9139ac9511ca; Wed, 07 Apr 2021 14:37:09 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8FC69B02B; Wed, 7 Apr 2021 14:37:08 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: ad8feeeb-105d-4109-9eac-9139ac9511ca X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1617806228; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RVTfOHZt+5GTfUvqHRoOkSW+lbhVxEv08w2Zo444uTE=; b=dxVMt1/MVxgxezDMjlgFkrsbkJzJf8KChJcL8kJJ1zHCy9qoOD2zfpNADajoT/Nr6KBjwo K0ayqSBdIFgYfl9hZ9vTy5u6JM/xcbZj9wo5X0WIqG9Pyr+x7WN8/bP6o7YxOckCBKkQda sP/6d+ZqCyE66qO8kJHMEj3IqxxEmlg= Subject: [PATCH 1/3] xen-pciback: redo VF placement in the virtual topology From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Juergen Gross , Boris Ostrovsky , Konrad Wilk References: Message-ID: <32d6a8d4-c06f-7fe0-1376-4b80fac8c6de@suse.com> Date: Wed, 7 Apr 2021 16:37:08 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) Content-Type: text/plain; charset="utf-8" The commit referenced below was incomplete: It merely affected what would get written to the vdev- xenstore node. The guest would still find the function at the original function number as long as=20 __xen_pcibk_get_pci_dev() wouldn't be in sync. The same goes for AER wrt __xen_pcibk_get_pcifront_dev(). Undo overriding the function to zero and instead make sure that VFs at function zero remain alone in their slot. This has the added benefit of improving overall capacity, considering that there's only a total of 32 slots available right now (PCI segment and bus can both only ever be zero at present). Fixes: 8a5248fe10b1 ("xen PV passthru: assign SR-IOV virtual functions to s= eparate virtual slots") Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org --- Like the original change this has the effect of changing where devices would appear in the guest, when there are multiple of them. I don't see an immediate problem with this, but if there is we may need to reduce the effect of the change. Taking into account, besides the described breakage, how xen-pcifront's pcifront_scan_bus() works, I also wonder what problem it was in the first place that needed fixing. It may therefore also be worth to consider simply reverting the original change. --- a/drivers/xen/xen-pciback/vpci.c +++ b/drivers/xen/xen-pciback/vpci.c @@ -70,7 +70,7 @@ static int __xen_pcibk_add_pci_dev(struc struct pci_dev *dev, int devid, publish_pci_dev_cb publish_cb) { - int err =3D 0, slot, func =3D -1; + int err =3D 0, slot, func =3D PCI_FUNC(dev->devfn); struct pci_dev_entry *t, *dev_entry; struct vpci_dev_data *vpci_dev =3D pdev->pci_dev_data; =20 @@ -95,22 +95,25 @@ static int __xen_pcibk_add_pci_dev(struc =20 /* * Keep multi-function devices together on the virtual PCI bus, except - * virtual functions. + * that we want to keep virtual functions at func 0 on their own. They + * aren't multi-function devices and hence their presence at func 0 + * may cause guests to not scan the other functions. */ - if (!dev->is_virtfn) { + if (!dev->is_virtfn || func) { for (slot =3D 0; slot < PCI_SLOT_MAX; slot++) { if (list_empty(&vpci_dev->dev_list[slot])) continue; =20 t =3D list_entry(list_first(&vpci_dev->dev_list[slot]), struct pci_dev_entry, list); + if (t->dev->is_virtfn && !PCI_FUNC(t->dev->devfn)) + continue; =20 if (match_slot(dev, t->dev)) { dev_info(&dev->dev, "vpci: assign to virtual slot %d func %d\n", - slot, PCI_FUNC(dev->devfn)); + slot, func); list_add_tail(&dev_entry->list, &vpci_dev->dev_list[slot]); - func =3D PCI_FUNC(dev->devfn); goto unlock; } } @@ -123,7 +126,6 @@ static int __xen_pcibk_add_pci_dev(struc slot); list_add_tail(&dev_entry->list, &vpci_dev->dev_list[slot]); - func =3D dev->is_virtfn ? 0 : PCI_FUNC(dev->devfn); goto unlock; } } From nobody Mon Feb 9 00:55:42 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1617806268; cv=none; d=zohomail.com; s=zohoarc; b=T6W9DqXCaMuvbjZROHqFps/xAxA2mx+bRVKxDzh2OazbpacjDYQYngCmYIYZ/n9pj3f3BTiQkOGsiMNbkvA+m5053zbmCEoz7KDfQVAjhLNcwH187yt9ZjTubRQ1OsvmiBhtrb3dMCR6mQkx99TOjDfsf3sPw6Cs7QUXbmN7cvw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1617806268; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=VS4wzz4JN1F6uBq2W5fhu7rrdUSiDdslm/RtnI7Yyw0=; b=bmnbHCvKHnSLi+c1xCl69a1kDX+Esj8BFDmpm/Hy4S5FU5PjERk1NEW3Y53UJrPQAtORKmI6hROmiehsjjb4U0bE9LexEeWu5Ax1okAjJtM4tK2nvh64vGVxGMphz40s5FZlV1r+COaV2f3Zqc6PXufhmVkQLS0Ad++eGRGuhKo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1617806268777666.5347829422144; Wed, 7 Apr 2021 07:37:48 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.106713.204047 (Exim 4.92) (envelope-from ) id 1lU9JG-0000NE-3M; Wed, 07 Apr 2021 14:37:34 +0000 Received: by outflank-mailman (output) from mailman id 106713.204047; Wed, 07 Apr 2021 14:37:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lU9JF-0000N7-Vj; Wed, 07 Apr 2021 14:37:33 +0000 Received: by outflank-mailman (input) for mailman id 106713; Wed, 07 Apr 2021 14:37:33 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lU9JF-0000Mx-D2 for xen-devel@lists.xenproject.org; Wed, 07 Apr 2021 14:37:33 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 9663923e-363a-4c8c-8c8b-6169e901c5ff; Wed, 07 Apr 2021 14:37:32 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 74DBEB034; Wed, 7 Apr 2021 14:37:31 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9663923e-363a-4c8c-8c8b-6169e901c5ff X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1617806251; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VS4wzz4JN1F6uBq2W5fhu7rrdUSiDdslm/RtnI7Yyw0=; b=V+qWN/caw4IVWpZnWxOfPRmNweRh3TWDlswo2itZariZbCfk8clHdAwL66wTavooDRgCfv tLoYX/24ibzLiOg94lE2cc3L9HyZY89UXXs0X4V4ci7zA1goVy2AvSiStjTKTzJEWfN6nm SK8Izn6jcRFuiKggP1VBfL5WPxrgOAE= Subject: [PATCH 2/3] xen-pciback: reconfigure also from backend watch handler From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Juergen Gross , Boris Ostrovsky , Konrad Wilk References: Message-ID: <74955b48-80b1-3436-06b4-d8569260aa65@suse.com> Date: Wed, 7 Apr 2021 16:37:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) Content-Type: text/plain; charset="utf-8" When multiple PCI devices get assigned to a guest right at boot, libxl incrementally populates the backend tree. The writes for the first of the devices trigger the backend watch. In turn xen_pcibk_setup_backend() will set the XenBus state to Initialised, at which point no further reconfigures would happen unless a device got hotplugged. Arrange for reconfigure to also get triggered from the backend watch handler. Signed-off-by: Jan Beulich Cc: stable@vger.kernel.org --- I will admit that this isn't entirely race-free (with the guest actually attaching in parallel), but from the looks of it such a race ought to be benign (not the least thanks to the mutex). Ideally the tool stack wouldn't write num_devs until all devices had their information populated. I tried doing so in libxl, but xen_pcibk_setup_backend() calling xenbus_dev_fatal() when not being able to read that node prohibits such an approach (or else libxl and driver changes would need to go into use in lock-step). I wonder why what is being watched isn't just the num_devs node. Right now the watch triggers quite frequently without anything relevant actually having changed (I suppose in at least some cases in response to writes by the backend itself). --- a/drivers/xen/xen-pciback/xenbus.c +++ b/drivers/xen/xen-pciback/xenbus.c @@ -359,7 +359,8 @@ out: return err; } =20 -static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev) +static int xen_pcibk_reconfigure(struct xen_pcibk_device *pdev, + enum xenbus_state state) { int err =3D 0; int num_devs; @@ -374,8 +375,7 @@ static int xen_pcibk_reconfigure(struct =20 mutex_lock(&pdev->dev_lock); /* Make sure we only reconfigure once */ - if (xenbus_read_driver_state(pdev->xdev->nodename) !=3D - XenbusStateReconfiguring) + if (xenbus_read_driver_state(pdev->xdev->nodename) !=3D state) goto out; =20 err =3D xenbus_scanf(XBT_NIL, pdev->xdev->nodename, "num_devs", "%d", @@ -500,6 +500,9 @@ static int xen_pcibk_reconfigure(struct } } =20 + if (state !=3D XenbusStateReconfiguring) + goto out; + err =3D xenbus_switch_state(pdev->xdev, XenbusStateReconfigured); if (err) { xenbus_dev_fatal(pdev->xdev, err, @@ -525,7 +528,7 @@ static void xen_pcibk_frontend_changed(s break; =20 case XenbusStateReconfiguring: - xen_pcibk_reconfigure(pdev); + xen_pcibk_reconfigure(pdev, XenbusStateReconfiguring); break; =20 case XenbusStateConnected: @@ -664,6 +667,10 @@ static void xen_pcibk_be_watch(struct xe xen_pcibk_setup_backend(pdev); break; =20 + case XenbusStateInitialised: + xen_pcibk_reconfigure(pdev, XenbusStateInitialised); + break; + default: break; } From nobody Mon Feb 9 00:55:42 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=suse.com ARC-Seal: i=1; a=rsa-sha256; t=1617806295; cv=none; d=zohomail.com; s=zohoarc; b=RJTkvRex9rTcZ3XQRtHm0/erUxE9axiLJhPcKIaOaZMngZ/fRd+Z953uCdxrHP8ia/PjG39roevUDzVOjeRpvBq7/i95XYWe/LYEPJ86X2lWztRu3q6OBe1MnFli8BIrUNpDoSmr0K+ZMHCIbYiE7Jn9mP3QWj5p8DKxj0u68fk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1617806295; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=1EjVwkyGSZf0Nk1jVX5DjRxmB+T2lYtGn0JD3AChaEs=; b=g8i1x8D1Xrq1xBYIxdKGXeISdhP/CbdASrnj2ZgiPvt0M4p798+GROARLu1P2kiW7Qcxsca/rRj49X0kiyS8w2alu5STGEagqki6fYDtLMjl4idNNbNUzU0ZZvs6TNsM4+iSGLbWKXs8HwQkVIPZ5cis487Di+ts70y4yOmsHV8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1617806295893310.8497088035788; Wed, 7 Apr 2021 07:38:15 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.106719.204059 (Exim 4.92) (envelope-from ) id 1lU9Ji-0000UD-BW; Wed, 07 Apr 2021 14:38:02 +0000 Received: by outflank-mailman (output) from mailman id 106719.204059; Wed, 07 Apr 2021 14:38:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lU9Ji-0000U6-8L; Wed, 07 Apr 2021 14:38:02 +0000 Received: by outflank-mailman (input) for mailman id 106719; Wed, 07 Apr 2021 14:38:00 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lU9Jg-0000Tu-Mn for xen-devel@lists.xenproject.org; Wed, 07 Apr 2021 14:38:00 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id a519e47d-968b-4c76-a1d6-05e8e9e4c19e; Wed, 07 Apr 2021 14:37:59 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 11C8FAC79; Wed, 7 Apr 2021 14:37:59 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: a519e47d-968b-4c76-a1d6-05e8e9e4c19e X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1617806279; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1EjVwkyGSZf0Nk1jVX5DjRxmB+T2lYtGn0JD3AChaEs=; b=eWXbEVkRVTII+IpZ4PqLt/lsGdso13cCXLuPPtQoDDbG0itha8XZFSQrXc9HcODss9Cumi 8kcSzH8G5p8ZBfpbv05pgquqADjPkp4oKj+QyXHP1nFFs8O85QzSO6hwppxutroC6ziU1s ru3/srlxu16r5gFPrD2sH1/H6L2v044= Subject: [PATCH 3/3] xen-pciback: simplify vpci's find hook From: Jan Beulich To: "xen-devel@lists.xenproject.org" Cc: Juergen Gross , Boris Ostrovsky , Konrad Wilk References: Message-ID: <158273a2-d1b9-3545-b25d-affca867376c@suse.com> Date: Wed, 7 Apr 2021 16:37:58 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @suse.com) Content-Type: text/plain; charset="utf-8" There's no point in comparing SBDF - we can simply compare the struct pci_dev pointers. If they weren't the same for a given device, we'd have bigger problems from having stored a stale pointer. Signed-off-by: Jan Beulich Reviewed-by: Boris Ostrovsky --- a/drivers/xen/xen-pciback/vpci.c +++ b/drivers/xen/xen-pciback/vpci.c @@ -235,7 +235,6 @@ static int __xen_pcibk_get_pcifront_dev( unsigned int *devfn) { struct pci_dev_entry *entry; - struct pci_dev *dev =3D NULL; struct vpci_dev_data *vpci_dev =3D pdev->pci_dev_data; int found =3D 0, slot; =20 @@ -244,11 +243,7 @@ static int __xen_pcibk_get_pcifront_dev( list_for_each_entry(entry, &vpci_dev->dev_list[slot], list) { - dev =3D entry->dev; - if (dev && dev->bus->number =3D=3D pcidev->bus->number - && pci_domain_nr(dev->bus) =3D=3D - pci_domain_nr(pcidev->bus) - && dev->devfn =3D=3D pcidev->devfn) { + if (entry->dev =3D=3D pcidev) { found =3D 1; *domain =3D 0; *bus =3D 0;