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]

Message-Id: <200610211816.27964.arnd@arndb.de>
Date:	Sat, 21 Oct 2006 18:16:27 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Avi Kivity <avi@...ranet.com>
Cc:	Muli Ben-Yehuda <muli@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] KVM: Kernel-based Virtual Machine

On Thursday 19 October 2006 20:00, Avi Kivity wrote:
> Working code is fairly hairy, since it's emulating a PC.  That'll be on
> sourceforge once they approve my new project.
>
> In general one does
>
>   open("/dev/kvm")
>   ioctl(KVM_SET_MEMORY_REGION) for main memory
>   ioctl(KVM_SET_MEMORY_REGION) for the framebuffer
>   ioctl(KVM_CREATE_VCPU) for the obvious reason
>   if (debugger)
>     ioctl(KVM_DEBUG_GUEST) to singlestep or breakpoint the guest
>   while (1) {
>      ioctl(KVM_RUN)
>      switch (exit reason) {
>          handle mmio, I/O etc. might call
>             ioctl(KVM_INTERRUPT) to queue an external interrupt
>             ioctl(KVM_{GET,SET}_{REGS,SREGS}) to query/modify registers
>             ioctl(KVM_GET_DIRTY_LOG) to see which guest memory pages
> have changed
>      }
>
> I have some simple test code, I'll clean it up and post it.

This looks _a_lot_ like what we're doing for the SPUs in the cell processor,
except that we're using different calls into the kernel. Have you looked
into what we have implemented there? The code is in
arch/powerpc/platforms/cell/spufs. I think it would be a good abstraction
to use for you as well, maybe we could even move to a common infrastructure,
as I have heard from a few other projects that want to do similar things.

The main differences to your interface are:

- A file system is used instead of a character device
- Directories, not open file descriptors represent contexts
- Two new syscalls were introduced (spu_create/spu_run)
- instead of ioctls, files represent different bits of information,
  you can read/write, poll or mmap them.

Your example above could translate to something like:

   int kvm_fd = kvm_create("/kvm/my_vcpu")
   int mem_fd = openat(kvm_fd, "mem", O_RDWR);
   void *mem = mmap(mem_fd, ...); // main memory
   void *fbmem = mmap(mem_fd, ...); // frame buffer memory
   int regs_fd = openat(kvm_fd, "regs", O_RDWR);
   int irq_fd = openat(kvm_fd, "regs", O_WRONLY);

   if (debugger) {
     int fd = openat(fvm_fd, "debug", O_WRONLY);
     write(fd, "1", 1);
     close(fd);
   }
   while (1) {
      int exit_reason = kvm_run(kvm_fd, &kvm_descriptor);
      switch (exit reason) {
          handle mmio, I/O etc. might call
             write(irq_fd, &interrupt_packet, sizeof (interrupt_packet));
             pread(regs_fd, &rax, sizeof rax, KVM_REG_RAX);
   }

	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/