linux-kernel - Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers

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: <4C05E752.6000403@redhat.com>
Date:	Wed, 02 Jun 2010 08:08:34 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Tom Lyon <pugs@...n-about.com>
CC:	Alex Williamson <alex.williamson@...hat.com>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	chrisw@...s-sol.org, joro@...tes.org, hjk@...utronix.de,
	gregkh@...e.de, aafabbri@...co.com, scofeldm@...co.com
Subject: Re: [PATCH] VFIO driver: Non-privileged user level PCI drivers

On 06/02/2010 07:59 AM, Tom Lyon wrote:
>
> This is just what I was thinking.  But rather than a get/set, just use two fds.
>
> 	ioctl(vfio_fd1, VFIO_SET_DOMAIN, vfio_fd2);
>
> This may fail if there are really 2 different IOMMUs, so user code must be
> prepared for failure,  In addition, this is strictlyupwards compatible with
> what is there now, so maybe we can add it later.
>
>    

What happens if one of the fds is later closed?

I don't like this conceptually.  There is a 1:n relationship between the 
memory map and the devices.  Ignoring it will cause the API to have 
warts.  It's more straightforward to have an object to represent the 
memory mapping (and talk to the iommus), and have devices bind to this 
object.


-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

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