Messages in this thread | | | From | Arnd Bergmann <> | Subject | Re: [kvm-devel] [PATCH][RFC] KVM: prepare user interface for smp guests | Date | Mon, 30 Oct 2006 01:01:10 +0100 |
| |
On Sunday 29 October 2006 14:31, Avi Kivity wrote: > + r = -EEXIST; > + if (vcpu->vmcs) > + goto out_unlock; > + > + r = -ENOMEM; > + filp = get_empty_filp(); > + if (!filp) > + goto out_unlock; > + > + r = get_unused_fd(); > + if (r < 0) > + goto out_free_filp; > + > + fd = r; > > vcpu->host_fx_image = (char*)ALIGN((hva_t)vcpu->fx_buf, > FX_IMAGE_ALIGN); > @@ -1372,10 +1428,25 @@ static int kvm_dev_ioctl_create_vcpu(str > if (r < 0) > goto out_free_vcpus; > > - return 0; > + filp->f_dentry = dget(kvm_filp->f_dentry); > + filp->f_vfsmnt = mntget(kvm_filp->f_vfsmnt); > + filp->f_mode = kvm_filp->f_mode; > + allow_write_access(filp); > + cdev_get(filp->f_dentry->d_inode->i_cdev); > + kvm_get(kvm); > + filp->f_op = fops_get(&kvm_vcpu_ops); > + filp->private_data = vcpu; > + fd_install(fd, filp);
Separating the objects into different file descriptors sounds like a good idea, but reusing an open dentry/inode with a new file and different file operations is a rather unusual way to do it. Your concept of allocating a new context on each open is already weird, but there have been other examples of that before.
I'd suggest going to a syscall-based model with your own file system right away, even if you don't use the spufs approach but something in the middle:
* You do a trivial nonmountable new file system with anonymous objects, similar to eventpollfs, and hand out file descriptors to inodes in it, for both the kvm and the vcpu objects. * You replace the syscall you'd normally use to hand out a new kvm instance with an ioctl on /dev/kvm, and don't allow any other operations on that device.
This would be a much more consistant object model, compared with other generic kernel functionality that is not bound to an actual device. You still have all the flexibility of a loadable module without core kernel changes for the development phase, and can easily switch to real syscalls when merging it into mainline.
I really think that a small number of syscalls is where you should be heading, whether you use a file system or not, but I understand that ioctls are convenient for development.
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/
| |