linux-kernel - Re: [PATCH 0/7] KVM: Kernel-based Virtual Machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 22 Oct 2006 19:53:58 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Anthony Liguori <aliguori@...ibm.com>
Cc:	Avi Kivity <avi@...ranet.com>, Muli Ben-Yehuda <muli@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 0/7] KVM: Kernel-based Virtual Machine

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/