On Thursday 04 August 2016 14:56:01 Paolo Bonzini wrote: > On 04/08/2016 13:18, Mihai Donțu wrote: > > The model we're aiming is: on a KVM host, out of the N running VM-s, one > > has special privileges allowing it to manipulate the memory and vCPU > > state of the others. We call that special VM an SVA (Security Virtual > > Appliance) and it uses a channel (much like the one found on Xen - > > evtchn) and a set of specific VMCALL-s to: > > > > * receive notifications from the host when a new VM is > > created/destroyed > > * manipulate the EPT of a specific VM > > * manipulate the vCPU state of a specific VM (GPRs) > > * manipulate the memory of a specific VM (insert code) > > No special VMs and hypercalls, please. Xen is a microkernel at its > core, KVM is not. Just run a process on the host. I personally have no problem with that approach, but I was thinking at RHEV which uses the ESXi model: the "host OS" is pretty much locked down and only runs the bare minimum, relying on "service VM-s" to implement 3rd party features (not that I know of any for RHEV, yet). > I'm not very convinced of manipulating the EPT page tables directly. > There must be some higher-level abstraction. For example, KVM has > recently grown a new in-kernel interface to track dirty pages, and if > anything you should export that one as ioctls, and make QEMU use the ioctls. I merely gave EPT as an example of the type of low level access we'd need. Obviously something generic would be much better, as we're also looking at ARM. > > Obviously we've tried the userspace / qemu approach since it would have > > made development _much_ easier, but it's simply not "performant" enough. > > That reminds me of kdbus. Without having even stated what the > requirements are, "it's slow" is dogma rather than fact. Even more so > if the client is proprietary and hidden behind a black-box "appliance". I apologise, I might have given the impression that we jumped into the "it's too slow" wagon too fast. We're looking at both approaches actually, I'm merely the only one looking into VirtIO. However, I don't have any numbers yet. :-( > vhost-user is performant enough for line-speed packet processing. It's > obviously not the same thing as VM memory introspection, but it's a > logical suggestion. I'll have a look at that again, thanks for the hint! Here is a small presentation of what we're trying to achieve for KVM: https://events.linuxfoundation.org/sites/events/files/slides/Zero-Footprint%20Guest%20Memory%20Introspection%20from%20Xen%20_%20draft11.pdf When I'm talking about speed, I might be a bit biased as I've been involved in the performance improvements only on the Xen side and we tried pretty hard to keep some code paths as simple as possible. -- Mihai DONȚU -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
