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. Even the compatibility story about vhost-user isn't great, I would like to see something solid before we allow that. 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 :|
