On Mon, 07 Nov 2011 11:26:53 +0200, Avi Kivity <avi@xxxxxxxxxx> wrote: > One thing to beware of is memory hotplug. If the memory map is static, > then a fork() once everything is set up (with MAP_SHARED) alllows all > processes to access guest memory. However, if memory hotplug is > supported (or planned to be supported), then you can't do that, as > seccomp doesn't allow you to run mmap() in confined processes. > > This means they have to use RPC to the main process in order to access > memory, which is going to slow them down significantly. That would be very silly. As virtio devices are simple, you just ask the device process to save its state, then you kill it and start a new one. For initial implementation, you service each request in a loop so there's no state at all. A pipe is all you need. > > Since I'll be basing it on the KVM tool, which doesn't really emulate > > that many legacy devices, I'll focus first on the virtio family for the > > sake of simplicity (and covering 90% of the options). > > Since virtio is so performance sensitive, my feeling is that it is > better to audit it, and rely on sandboxing for the non performance > sensitive parts of the device model. Of course for a POC it's fine to > start with it. A separate thread per device (or even per virtqueue, as lguest does) will help parallelism. My very brief experiments with lguest showed that it made some things better, some things worse... Cheers, Rusty. -- 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
