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:	Fri, 16 Mar 2007 16:01:45 +0100
From:	Heiko Carstens <heiko.carstens@...ibm.com>
To:	Anthony Liguori <aliguori@...ibm.com>
Cc:	Avi Kivity <avi@...ranet.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

On Fri, Mar 16, 2007 at 09:03:08AM -0500, Anthony Liguori wrote:
> Heiko Carstens wrote:
> >On Sun, Mar 11, 2007 at 03:53:12PM +0200, Avi Kivity wrote:
> >  
> >>This patchset updates the kvm userspace interface to what I hope will
> >>be the long-term stable interface.  Provisions are included for extending
> >>the interface later.  The patches address performance and cleanliness
> >>concerns.
> >>    
> >
> >Searching the mailing list I figured that as soons as the interface seems
> >to be stable, kvm should/would switch to a system call based interface.
> >I assume the userspace interface might still change a lot, especially if
> >kvm is ported to new architectures.
> >But the general question is: do you still plan to switch to a syscall
> >interface?
> >  
> 
> What benefit would a syscall interface have?

First of all: it's faster and doesn't burn a bunch of additional cpu
cycles like sys_ioctl and the large switch statements do.

Another thing is that this patch set already introduces a way to pass a
sigset. Passing a sigset to a device node is sort of strange.

In addition, if we would port kvm to s390, then we would need to
make sure that each virtual cpu only gets executed from the thread
that created it. That is simply because the upper half of our page
tables contain information about the guest page states. This is yet
another thing that would be strange to do via an ioctl based interface.

Of course everthing can be done via an iotcl interface too, but IMHO
that's just the wrong interface.
-
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/