On Tue, Dec 18, 2018 at 10:35:05PM +0400, Marc-André Lureau wrote: > Hi > > On Tue, Dec 11, 2018 at 10:56 PM Michael S. Tsirkin <m...@redhat.com> wrote: > > > > On Tue, Dec 11, 2018 at 09:29:44AM +0000, Daniel P. Berrangé wrote: > > > On Tue, Dec 11, 2018 at 08:42:41AM +0100, Hoffmann, Gerd wrote: > > > > Hi, > > > > > > > > > Right. The main issue is that we need to make sure only > > > > > in-tree devices are supported. > > > > > > > > Well, that is under debate right now, see: > > > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg04912.html > > > > > > I've previously been against the idea of external plugins for QEMU, > > > however, that was when the plugin was something that would be dlopen'd > > > by QEMU. That would cause our internal ABI to be exposed to 3rd parties > > > which is highly undesirable, even if they were open source to comply > > > with the license needs. > > > > > > When the plugin is a completely isolated process communicating with a > > > well defined protocol, it is not placing a significant burden on the > > > QEMU developers' ongoing maintainence, nor has problems with license > > > compliance. The main problem would come from debugging the combined > > > system as the external process is essentially a black box from QEMU's > > > POV. Downstream OS vendors are free to place restrictions on which > > > backend processes they'd be willing to support with QEMU, and upstream > > > is under no obligation to debug stuff beyond the QEMU boundary. > > > > > > We have already accepted that tradeoff with networking by supporting > > > vhost-user and have externals impls like DPDK, so I don't see a > > > compelling reason to try to restrict it for other vhost-user backends. > > > > OK seems to be more or less a rough concensus then. > > > > I wonder what's the approach wrt migration though. > > The series doesn't take care of migration. > > > > > Even the compatibility story about vhost-user isn't > > great, I would like to see something solid before > > we allow that. > > To allow migration? vhost-user has partial support for migration > (dirty memory tracking), and there is also "[PATCH v2 for-4.0 0/7] > vhost-user-blk: Add support for backend reconnecting" - allowing the > backend to store some state, if I understand correctly, which could be > leveraged I guess... > > But I don't think we should block this series because migration isn't > tackled here. > > thanks > > > .
How about blocking migration for now then? We need someone to work on a solution for cross version/device compatibility, vhost net/blk without that is bad enough but at least we have a feature bits, for random devices it would be very very bad. > > > > Are we happy to just block live migration? > > For sure that's already the case with VFIO. > > > > > > > > > vhost-user by design > > > > > is for out of tree users. It needn't be hard, > > > > > maybe it's enough to just make qemu launch these processes > > > > > as opposed to connecting to them on command line. > > > > > > > > Not sure this is a good idea, with security being one of the motivating > > > > factors to move device emulation to other processes. When libvirt > > > > launches the processes it can place them in separate sandboxes ... > > > > > > Yep, libvirt already turns on seccomp policies which forbid QEMU from > > > forking/execing anything, and we have no desire to go backwards here. > > > Any external processes have to be launched by libvirt ahead of time. > > > > > > > > > Regards, > > > Daniel > > > -- > > > |: https://berrange.com -o- > > > https://www.flickr.com/photos/dberrange :| > > > |: https://libvirt.org -o- > > > https://fstop138.berrange.com :| > > > |: https://entangle-photo.org -o- > > > https://www.instagram.com/dberrange :| > > > > > -- > Marc-André Lureau
