From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id BEEFD3B5 for ; Wed, 17 Dec 2014 02:06:24 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 16 Dec 2014 17:06:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="429910555" Received: from pgsmsx104.gar.corp.intel.com ([10.221.44.91]) by FMSMGA003.fm.intel.com with ESMTP; 16 Dec 2014 16:55:16 -0800 Received: from pgsmsx105.gar.corp.intel.com (10.221.44.96) by PGSMSX104.gar.corp.intel.com (10.221.44.91) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Dec 2014 09:06:21 +0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by PGSMSX105.gar.corp.intel.com (10.221.44.96) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 17 Dec 2014 09:06:21 +0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 09:06:20 +0800 From: "Xie, Huawei" To: Tetsuya Mukawa , "dev@dpdk.org" Thread-Topic: [PATCH RFC v2 08/12] lib/librte_vhost: vhost-user support Thread-Index: AQHQGN0rDGierkxgakmerAM+nlIdtZyS231w Date: Wed, 17 Dec 2014 01:06:18 +0000 Message-ID: References: <1418247477-13920-1-git-send-email-huawei.xie@intel.com> <1418247477-13920-9-git-send-email-huawei.xie@intel.com> <548FA172.5030604@igel.co.jp> In-Reply-To: <548FA172.5030604@igel.co.jp> Accept-Language: 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 RFC v2 08/12] lib/librte_vhost: vhost-user support 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: Wed, 17 Dec 2014 01:06:25 -0000 > > +{ > > + struct virtio_net *dev =3D get_device(ctx); > > + > > + /* We have to stop the queue (virtio) if it is running. */ > > + if (dev->flags & VIRTIO_DEV_RUNNING) > > + notify_ops->destroy_device(dev); >=20 > I have an one concern about finalization of vrings. > Can vhost-backend stop accessing RX/TX to the vring before replying to > this message? >=20 > QEMU sends this message when virtio-net device is finalized by > virtio-net driver on the guest. > After finalization, memories used by the vring will be freed by > virtio-net driver, because these memories are allocated by virtio-net > driver. > Because of this, I guess vhost-backend must stop accessing to vring > before replying to this message. >=20 > I am not sure what is a good way to stop accessing. > One idea is adding a condition checking when rte_vhost_dequeue_burst() > and rte_vhost_enqueue_burst() is called. > Anyway we probably need to wait for stopping access before replying. >=20 > Thanks, > Tetsuya >=20 I think we have discussed the similar question. It is actually the same issue whether the virtio APP in guest is crashed, o= r is finalized. The virtio APP will only write to the STATUS register without waiting/synci= ng to vhost backend. After that, not only the guest memory pointed by vring entry but also the v= ring itself isn't usable any more. The memory for vring or pointed by vring entry might be used by other APPs. This will crash guest(rather than the vhost, do you agree?). If you mean this issue, I think we have no solution but one walk around: ke= ep the huge page files of crashed app, and=20 bind virtio to igb_uio and then delete the huge page files. In our implementation, when vhost sends the message, we will call the dest= roy_device provided by the vSwitch to ask the vSwitch to stop processing the vring, but this willn't solve the issue I me= ntion above, because the virtio APP in guest will n't=20 wait us. Could you explain a bit more? Is it the same issue? -huawei