From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e5MnM-0003m2-I4 for qemu-devel@nongnu.org; Thu, 19 Oct 2017 22:12:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e5MnI-000315-E5 for qemu-devel@nongnu.org; Thu, 19 Oct 2017 22:12:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55250) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e5MnI-0002zu-4U for qemu-devel@nongnu.org; Thu, 19 Oct 2017 22:12:16 -0400 Date: Fri, 20 Oct 2017 05:12:11 +0300 From: "Michael S. Tsirkin" Message-ID: <20171020050456-mutt-send-email-mst@kernel.org> References: <1508390650-19115-1-git-send-email-changpeng.liu@intel.com> <1508390650-19115-2-git-send-email-changpeng.liu@intel.com> <20171019183638-mutt-send-email-mst@kernel.org> <42aa8736-bc23-d66d-27de-dbaf83ea2f99@redhat.com> <20171019204305-mutt-send-email-mst@kernel.org> <20171020032138-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v4 1/4] vhost-user: add new vhost user messages to support virtio config space List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Liu, Changpeng" Cc: Paolo Bonzini , "qemu-devel@nongnu.org" , "stefanha@gmail.com" , "marcandre.lureau@redhat.com" , "felipe@nutanix.com" , "Harris, James R" On Fri, Oct 20, 2017 at 01:55:20AM +0000, Liu, Changpeng wrote: > > > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:mst@redhat.com] > > Sent: Friday, October 20, 2017 8:28 AM > > To: Paolo Bonzini > > Cc: Liu, Changpeng ; qemu-devel@nongnu.org; > > stefanha@gmail.com; marcandre.lureau@redhat.com; felipe@nutanix.com; Harris, > > James R > > Subject: Re: [PATCH v4 1/4] vhost-user: add new vhost user messages to support > > virtio config space > > > > On Thu, Oct 19, 2017 at 11:04:48PM +0200, Paolo Bonzini wrote: > > > On 19/10/2017 19:43, Michael S. Tsirkin wrote: > > > > On Thu, Oct 19, 2017 at 05:43:18PM +0200, Paolo Bonzini wrote: > > > >> On 19/10/2017 17:39, Michael S. Tsirkin wrote: > > > >>>> Add VHOST_USER_GET_CONFIG/VHOST_USER_SET_CONFIG messages > > which can be > > > >>>> used for live migration of vhost user devices, also vhost user devices > > > >>>> can benefit from the messages to get/set virtio config space from/to the > > > >>>> I/O target. For the purpose to support virtio config space change, > > > >>>> VHOST_USER_SET_CONFIG_FD message is added as the event notifier > > > >>>> in case virtio config space change in the I/O target. > > > >>>> > > > >>>> Signed-off-by: Changpeng Liu > > > >>> I don't much like it that config is getting passed through. > > > >>> > > > >>> IMO this makes managing things harder not easier. > > > >>> > > > >>> How about specific messages about specific parts of > > > >>> config space that you want to get from the backend? > > > >> > > > >> In the case of virtio-blk that would be all of it. Do you have a case > > > >> in mind where some part of the configuration space is owned by QEMU? > > > >> > > > >> Paolo > > > > > > > > Yes. seg_max > > > > > > The seg_max limit is established by whoever reads buffers from the vring > > > and passes them down to the lower layer. For vhost-blk that's the > > > device server, not QEMU. > > > > > > Paolo > > > > Good point. How about num_queues though? > num_queues is part of virtio_blk config, vhost-user slave can set it, > and Qemu driver can rewrite it if user want less IO queues. Fundamentally QEMU needs to support this # of queues for this device. So whenever QEMU doesn't always expose config space as-is, need to document the exact semantics. Also, does backend need to know? > > > > Also why is there SET_CONFIG? Does not look like blk uses it. > Only one possible usage when disable write cache to vhost-user slave device. Again need to add documentation what can be written. > > > > And I wonder how do we do it for other devices. > > > > E.g. for net there's a bit in the middle of the > > config field that deals with migration. > Well, I'm okay to make those messages only valid for virtio block device, because it's enough > for virtio block to be started with vhost-user slave target. OK but I'd rather make them at least somewhat generic so we can reuse them down the road. It looks like adding offset/size pair would solve most of the issues. Thoughts? > > > > > > -- > > MST