linux-kernel - Re: [PATCH 1/7] KVM: userspace interface

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]

Message-ID: <4537C8B3.5050501@us.ibm.com>
Date:	Thu, 19 Oct 2006 13:49:23 -0500
From:	Anthony Liguori <aliguori@...ibm.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	John Stoffel <john@...ffel.org>, Avi Kivity <avi@...ranet.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/7] KVM: userspace interface

Alan Cox wrote:
> Ar Iau, 2006-10-19 am 10:30 -0400, ysgrifennodd John Stoffel:
>   
>> Avi> This patch defines a bunch of ioctl()s on /dev/kvm.  The ioctl()s
>> Avi> allow adding memory to a virtual machine, adding a virtual cpu to
>> Avi> a virtual machine (at most one at this time), transferring
>> Avi> control to the virtual cpu, and querying about guest pages
>> Avi> changed by the virtual machine.
>>
>> Yuck.  ioclts are deprecated, you should be using /sysfs instead for
>> stuff like this, or configfs.  
>>     
>
> Bzzt Wrong answer, please try again 8)
>
> The kernel summit discussions were very much that ioctl has its place,
> and that the sysfs extremists were wrong. sysfs has its place (views
> ranging from that being /dev/null upwards) but sysfs is useless for many
> kinds of interface including those with read/write or other
> synchronization properties, those that trigger actions and those that
> are tied to the file handle you are working with. An executing VM
> interface via sysfs is a ludicrous concept.
>
> Making sure the ioctl sizes are the same in 32/64bit and aligned the
> same way is the more important issue.
>   

ioctls are probably wrong here though.  Ideally, you would want to be 
able to support an SMP guest.  This means you need to have two virtual 
processors executing in kernel space.  If you use ioctls, it forces you 
to have two separate threads in userspace.  This would be hard for 
something like QEMU which is currently single threaded (and not at all 
thread safe).

If you used a read/write interface, you could poll for any number of 
processors and handle IO emulation in a single userspace thread (which 
seems closer to how hardware really works anyway).

Regards,

Anthony Liguori

> Alan
>
> -
> 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/
>
>   

-
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/