Re: [Qemu-devel] [PATCH] mark nic as trusted

[Jamie Lokier]

Anthony Liguori wrote:
> You cannot get around having a kernel module to support something like 
> vmchannel so that's always going to be a requirement.  A completely 
> userspace approach ala the VMware backdoor hackery is just too hideous.

Eh?  I thought the point of vmchannel is to use the guest network
stack, so guest processes - including user ones - can potentially
speak over it to the host via a marked, designated channel.

If you need a kernel module, i.e. you're doing special kernely things,
there's no need for the vmchannel device to be a normal NIC device, no
need for it to interfere with the guest networking (e.g. conflicting
IPv4 subnets), and it can use virtio, I agree in that case.

Now that it's clear I'm imagining guest userspace admin processes and
you're imagining a kernel module on the guest, the rest of this
exchange makes sense :-)

> >In some circles, a major purpose of virtualisation is to run old OS
> >versions, either copied from machines where the hardware is aging to
> >keep a working system still working, or for compatibility testing.
> 
> When dealing with older OSes, there really no limit in terms of what we 
> can do.  For instance, there's no reason that the backported version of 
> the virtio-net driver cannot expose a chardev interface if the distro 
> doesn't have the appropriate configuration.

Realistically, the set of (older) OSes where you'd like to run simple
guest-host communicating apps for VM management, especially simple
monitoring apps (load avg, memory use, number of processes), is much
larger than those older OSes which virtio-net can be loaded onto.

E.g. Linux and Windows apps to do that could run on very old/obscure
versions and diverse distributions, if statically linked.

Sometimes there'll be no backport of kernel drivers, and if there is
one, that doesn't mean you can load it into an existing guest image or
even compile it for that exact guest kernel.

I think it's quite reasonable to want to run simple monitoring apps on
such guests.

> But we also have to think about how to support newer platforms and newer 
> kernels and this will often mean that we have to make intrusive changes 
> so that the integration makes everyone happy.  This does not mean that 
> we cannot support older platforms though, we just have to do it a little 
> differently on the older platforms.

Sure, but don't make it _deliberately_ hard to support
older/obscure/can't-compile-a-kernel-module guests by designing
something that's obviously going to require a totally different
mechanism on those other guests.  It would make it unnecessarily hard
to integrate diverse guests with management apps from different
authors if they do adopt the vmchannel mechanism.

-- Jamie