From patchwork Mon Jan 12 13:35:04 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Li, Liang Z" X-Patchwork-Id: 427754 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [IPv6:2001:4830:134:3::11]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id C05B81401AC for ; Tue, 13 Jan 2015 00:38:00 +1100 (AEDT) Received: from localhost ([::1]:34362 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAfBs-0005uX-Vd for incoming@patchwork.ozlabs.org; Mon, 12 Jan 2015 08:37:56 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48154) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAfBZ-0005d5-MC for qemu-devel@nongnu.org; Mon, 12 Jan 2015 08:37:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAfBW-00027m-Et for qemu-devel@nongnu.org; Mon, 12 Jan 2015 08:37:37 -0500 Received: from mga09.intel.com ([134.134.136.24]:61577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAfBW-00027D-8r for qemu-devel@nongnu.org; Mon, 12 Jan 2015 08:37:34 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 12 Jan 2015 05:34:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,744,1413270000"; d="scan'208";a="649816119" Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88]) by fmsmga001.fm.intel.com with ESMTP; 12 Jan 2015 05:37:29 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 12 Jan 2015 21:35:06 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.216]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.240]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 21:35:05 +0800 From: "Li, Liang Z" To: "Tian, Kevin" , Stefano Stabellini Thread-Topic: [Xen-devel] [PATCH] xen-pt: Fix PCI devices re-attach failed Thread-Index: AdAgJkXMhzPWC6YkS9mgiucmrIsFCgN8pw4AAADpNIAAE0fOUA== Date: Mon, 12 Jan 2015 13:35:04 +0000 Message-ID: References: <1419411417-23354-1-git-send-email-liang.z.li@intel.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 134.134.136.24 Cc: "xen-devel@lists.xensource.com" , "mst@redhat.com" , "mtosatti@redhat.com" , "qemu-devel@nongnu.org" , "aliguori@amazon.com" , "pbonzini@redhat.com" , "Zhang, Yang Z" , "Hu, Robert" , "rth@twiddle.net" Subject: Re: [Qemu-devel] [Xen-devel] [PATCH] xen-pt: Fix PCI devices re-attach failed X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org > > > Use the 'xl pci-attach $DomU $BDF' command to attach more than one > > > PCI devices to the guest, then detach the devices with 'xl > > > pci-detach $DomU $BDF', after that, re-attach these PCI devices > > > again, an error message will be reported like following: > > > > > > libxl: error: libxl_qmp.c:287:qmp_handle_error_response: receive an > > > error message from QMP server: Duplicate ID 'pci-pt-03_10.1' > > > for device. > > > > > > The count of calling xen_pt_region_add and xen_pt_region_del are not > > > the same will cause the XenPCIPassthroughState and it's related > > > QemuOpts object not be released properly. > > > > Thanks for the patch! > > > > From this description, I don't quite understand why the > > memory_region_ref and memory_region_unref calls are wrong. What do > > you mean by "The count of calling xen_pt_region_add and > > xen_pt_region_del are not the same"? I means for some memory regions , only the xen_pt_region_add callback function was called while the xen_pt_region_del was not called. > > On unplug xen_pt_region_del does not get called? > > Or the memory region argument is not exactly the same as the one > > initially passed to xen_pt_region_add? > > > > agree. Liang, could you elaborate how the patch is associated with above > explanation? :-) I have verified the following patch can work too: By further debugging, I found when using 'address_space_memory', 'xen_pt_region_del' won't be called when the memory region's name is not ' xen-pci-pt-*', when using ' s->dev.bus_master_as ', there is no such issue. I think use the device related address space here is more reasonable, but I am not sure. Could you give some suggestion? Liang diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index c1bf357..f2893b2 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -736,7 +736,7 @@ static int xen_pt_initfn(PCIDevice *d) } out: - memory_listener_register(&s->memory_listener, &address_space_memory); + memory_listener_register(&s->memory_listener, + &s->dev.bus_master_as); memory_listener_register(&s->io_listener, &address_space_io); XEN_PT_LOG(d, "Real physical device %02x:%02x.%d registered successfully!\n",