lkml.org 
[lkml]   [2007]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [kvm-devel] [PATCH 0/15] KVM userspace interface updates
Heiko Carstens wrote:
>> Right. I agree it's more natural to associate a vcpu with a task
>> instead of a vcpu being an independent entry. We'd still need a
>> handle for it, and in Linux that's an fd (pid doesn't cut it as it's
>> racy, and probably slower too as it has to go through a global structure).
>>
>
> If you go for: only one VM per thread group and only one vcpu per thread
> you don't need any identifier.
>

That's the idea, but if I want to send an inter-processor-interrupt to
another cpu, I need to be able to identify it. The pid [tid] is
natural, but racy if the thread can die.

> All relevant information or a pointer to it would be saved in the
> thread_info structure.
> That would give you two system calls to add/remove cpus which implicitely
> create a VM if none is present. This add_vcpu syscall would also map
> a memory range to user space which would be used to communicate between
> user/kernel space to avoid frequent copy_to/from_user just like your
> latest patches for KVM_RUN do.
>
> We implemented a prototype on s390 based on a system call interface
> and which does have full smp support.

[...]

> The interesting part with this is that you don't need any locking
> for a kvm_run system call, simply because only the thread itself can
> create/remove the vcpu:
>

Yes! The vcpu is an implied parameter (current->vcpu).

> Of course all this is rather simplified, but should give a good idea
> why I think that a syscall based interface should be the way to go.
>

I agree with all of the above, and in addition, integration to the
scheduler will allow us to reduce vcpu migration rate, and maybe do
things like gang scheduling.

But that doesn't mean it can be done now: we really need to see how it
works out with smp and with an additional arch, and then we can
stabilize it. Meanwhile I'd like a stable ABI so distros can start
shipping kvm without worrying about upgrade headaches.

So the plan is:
- get the /dev/kvm ABI into 2.6.22
- implement smp
- add another arch
- move to a syscall based interface in parallel; userspace should work
with both
- deprecate the old ABI and external modules.

--
error compiling committee.c: too many arguments to function

-
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: 2007-03-19 17:07    [W:0.049 / U:0.056 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site