![]() | |||||||||||||
Messages in this thread |
On Sunday 22 October 2006 19:39, Anthony Liguori wrote: > I like the idea of a filesystem. In particular, if you exposed the CPU > state as a mmap()'able file, you could read/write from userspace without > any syscall overhead. Right. It's a little tricky though regarding what happens when you write to the register mapping of a running guest, without stopping it first. > There are some clever ways that you could get around need that many > syscalls. For instance, you could have a "paused" file that you could > write a "1" into in order to run the guest (assuming that the memory/CPU > state is setup properly). what for? writing 1, then 0 to that file is two full syscalls. Calling kvm_run and returning from it is just one. You can also just send SIGSTOP/SIGCONT to the task to stop it. > You could then have an "event" file that you could select() for read > on. When "event" became readable, you could read the exit reason, do > whatever is needed, and then write a "1" into "paused" again. It's very handy to stay inside of a single process context for both the hypervisor and the guest, and to simply block in a kvm_run syscall for the time the guest executes. This syscall can then simply return the exit reason as its return value so you don't need another syscall to read it. > Perhaps an ioctl is better for pausing/unpausing but I do think it's > necessary to select() on something to wait for the next exit reason to > occur. I would not mix ioctls with a new file system. ioctl is fine on a character device, but with a new file system, you should be able to express everything as read/write, or one of the new syscalls. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-10-22 19:57 [from the cache] ©2003-2008 | |||||||||||||