From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id DC9A02A07 for ; Mon, 10 Aug 2015 03:21:03 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 09 Aug 2015 18:21:03 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,641,1432623600"; d="scan'208";a="538850256" Received: from kmsmsx153.gar.corp.intel.com ([172.21.73.88]) by FMSMGA003.fm.intel.com with ESMTP; 09 Aug 2015 18:21:01 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.110.15) by KMSMSX153.gar.corp.intel.com (172.21.73.88) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 10 Aug 2015 09:20:59 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.126]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.45]) with mapi id 14.03.0224.002; Mon, 10 Aug 2015 09:20:58 +0800 From: "Ouyang, Changchun" To: Jan Kiszka , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] vchost: Notify application of ownership change Thread-Index: AQHQ0TV2jPqGkzIBnE6JWkov2utqcp4BPY5g///k+oCAA05UUA== Date: Mon, 10 Aug 2015 01:20:58 +0000 Message-ID: References: <55C4E8E1.9090406@siemens.com> <55C5A50F.8090600@siemens.com> In-Reply-To: <55C5A50F.8090600@siemens.com> 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] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] vchost: Notify application of ownership change X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 01:21:04 -0000 > -----Original Message----- > From: Jan Kiszka [mailto:jan.kiszka@siemens.com] > Sent: Saturday, August 8, 2015 2:43 PM > To: Ouyang, Changchun; dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH] vchost: Notify application of ownership > change >=20 > On 2015-08-08 02:25, Ouyang, Changchun wrote: > > > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jan Kiszka > >> Sent: Saturday, August 8, 2015 1:21 AM > >> To: dev@dpdk.org > >> Subject: [dpdk-dev] [PATCH] vchost: Notify application of ownership > >> change > > > > Vchost should be vhost in the title >=20 > Oops. Unless I need to resend for some other reason, I guess the commit c= an > fix this up. >=20 > > > >> > >> On VHOST_*_RESET_OWNER, we reinitialize the device but without > >> telling the application. That will cause crashes when it continues to > >> invoke vhost services on the device. Fix it by calling the > >> destruction hook if the device is still in use. > > What's your qemu version? >=20 > git head, see my other reply for details. >=20 > > Any validation work on this patch? >=20 > What do you mean with this? Test cases? Or steps to reproduce? For the > latter, just fire up a recent qemu, let the guest enable the virtio devic= e, then > reboot or simply terminate qemu. Here, I mean test case,=20 Need make sure the change works on both qemu 2.4(with the reset commit in q= emu) and qemu2.2/2.3(without the commit in qemu). >=20 > >> > >> Signed-off-by: Jan Kiszka > >> --- > >> > >> This is the surprisingly simple answer to my questions in > >> http://thread.gmane.org/gmane.comp.networking.dpdk.devel/22661. > >> > >> lib/librte_vhost/virtio-net.c | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/lib/librte_vhost/virtio-net.c > >> b/lib/librte_vhost/virtio-net.c index > >> b520ec5..3c5b5b2 100644 > >> --- a/lib/librte_vhost/virtio-net.c > >> +++ b/lib/librte_vhost/virtio-net.c > >> @@ -402,6 +402,9 @@ reset_owner(struct vhost_device_ctx ctx) > >> > >> ll_dev =3D get_config_ll_entry(ctx); > >> > >> + if ((ll_dev->dev.flags & VIRTIO_DEV_RUNNING)) > >> + notify_ops->destroy_device(&ll_dev->dev); > >> + > > > > I am not sure whether destroy_device here will affect the second time > init_device(below) and new_device(after the reset) or not. > > Need validation. >=20 > Cannot follow, what do you mean with "second time"? If the callback could > invoke something that causes cleanup_device to be called as well? > That's at least not the case with vhost-switch, but I'm far from being fa= miliar > with the API to asses if that is possible in general. RESET is often followed by a second time virtio device creation.=20 If you have chance to run testpmd with virtio PMD on guest, that would be t= hat case: Call RESET, and then create virtio device again to make it work for packets= rx/tx=20 >=20 > Jan >=20 > > > >> cleanup_device(&ll_dev->dev); > >> init_device(&ll_dev->dev); > >> > >> -- > >> 2.1.4 >=20 >=20 > -- > Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate > Competence Center Embedded Linux