From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f9CkE-00054C-At for qemu-devel@nongnu.org; Thu, 19 Apr 2018 12:49:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f9CkA-0000RX-BW for qemu-devel@nongnu.org; Thu, 19 Apr 2018 12:49:14 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:53442 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f9CkA-0000Qe-6d for qemu-devel@nongnu.org; Thu, 19 Apr 2018 12:49:10 -0400 Date: Thu, 19 Apr 2018 19:48:55 +0300 From: "Michael S. Tsirkin" Message-ID: <20180419194500-mutt-send-email-mst@kernel.org> References: <20180412151232.17506-1-tiwei.bie@intel.com> <20180412151232.17506-7-tiwei.bie@intel.com> <20180418192154-mutt-send-email-mst@kernel.org> <20180419111439.i6gfhnept6wy7uzp@debian> <20180419180912-mutt-send-email-mst@kernel.org> <174b5e48-dfde-cb5f-e664-39d43a20a629@redhat.com> <20180419185630-mutt-send-email-mst@kernel.org> <380b6838-7249-fec1-8ebb-1b899830a9a0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <380b6838-7249-fec1-8ebb-1b899830a9a0@redhat.com> Subject: Re: [Qemu-devel] [virtio-dev] RE: [PATCH v3 6/6] vhost-user: support registering external host notifiers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Liang, Cunming" , "Bie, Tiwei" , "jasowang@redhat.com" , "alex.williamson@redhat.com" , "stefanha@redhat.com" , "qemu-devel@nongnu.org" , "virtio-dev@lists.oasis-open.org" , "Daly, Dan" , "Tan, Jianfeng" , "Wang, Zhihong" , "Wang, Xiao W" On Thu, Apr 19, 2018 at 06:07:07PM +0200, Paolo Bonzini wrote: > On 19/04/2018 17:59, Michael S. Tsirkin wrote: > > On Thu, Apr 19, 2018 at 05:51:51PM +0200, Paolo Bonzini wrote: > >> On 19/04/2018 17:19, Michael S. Tsirkin wrote: > >>>> - if we make it 1 when weak barriers are needed, the device also needs > >>>> to nack feature negotiation (not allow setting the FEATURES_OK) if the > >>>> bit is not set by the driver. > >>>> However, that is not enough. Live > >>>> migration assumes that it is okay to migrate a virtual machine from a > >>>> source that doesn't support a feature to a destination that supports it. > >>>> In this case, it would assume that it is okay to migrate from software > >>>> virtio to hardware virtio. This is wrong because the destination would > >>>> use weak barriers > >>> > >>> You can't migrate between systems with different sets of device features > >>> right now. > >> > >> Yes, you can, exactly because some features are defined not by the > >> machine type but rather by the host kernel. See virtio_net_get_features > >> in QEMU's hw/virtio/virtio-net.c, and virtio_set_features_nocheck in > >> QEMU's hw/virtio/virtio.c. > > > > Oh you are right. Well we can just special-case that one :) > > Anything wrong with bumping the PCI revision? > > Paolo Nothing except in virtio 1 bumping the revision does not prevent loading the old driver. -- MST