linux-kernel - Re: [kvm-devel] [PATCH 0/15] KVM userspace interface updates

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:	Mon, 19 Mar 2007 18:02:57 +0200
From:	Avi Kivity <avi@...ranet.com>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
CC:	Avi Kivity <avi@...o.co.il>, Anthony Liguori <aliguori@...ibm.com>,
	kvm-devel@...ts.sourceforge.net, Andrew Morton <akpm@...l.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/