On Thu, 2012-02-16 at 21:28 +0200, Avi Kivity wrote: > On 02/16/2012 03:04 AM, Michael Ellerman wrote: > > > > > > ioctl is good for hardware devices and stuff that you want to enumerate > > > and/or control permissions on. For something like KVM that is really a > > > core kernel service, a syscall makes much more sense. > > > > Yeah maybe. That distinction is at least in part just historical. > > > > The first problem I see with using a syscall is that you don't need one > > syscall for KVM, you need ~90. OK so you wouldn't do that, you'd use a > > multiplexed syscall like epoll_ctl() - or probably several > > (vm/vcpu/etc). > > No. Many of our ioctls are for state save/restore - we reduce that to > two. Many others are due to the with/without irqchip support - we slash > that as well. The device assignment stuff is relegated to vfio. > > I still have to draw up a concrete proposal, but I think we'll end up > with 10-15. That's true, you certainly could reduce it, though by how much I'm not sure. On powerpc I'm working on moving the irq controller emulation into the kernel, and some associated firmware emulation, so that's at least one new ioctl. And there will always be more, whatever scheme you have must be easily extensible - ie. not requiring new syscalls for each new weird platform. > > Secondly you still need a handle/context for those syscalls, and I think > > the most sane thing to use for that is an fd. > > The context is the process (for vm-wide calls) and thread (for vcpu > local calls). Yeah OK I forgot you'd mentioned that. But isn't that change basically orthogonal to how you get into the kernel? ie. we could have the kvm/vcpu pointers in mm_struct/task_struct today? I guess it wouldn't win you much though because you still have the fd and ioctl overhead as well. cheers
Attachment:
signature.asc
Description: This is a digitally signed message part
