From sacadmin Mon Jan 2 16:21:32 2006 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k030LWIQ021770; Mon, 2 Jan 2006 16:21:32 -0800 (PST) Received: (from alanc@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id k030LVuq021762; Mon, 2 Jan 2006 16:21:31 -0800 (PST) Date: Mon, 2 Jan 2006 16:21:31 -0800 (PST) From: Alan Coopersmith Message-Id: <200601030021.k030LVuq021762@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: Cindy.Sabenorio@Sun.Com, John.M.Martin@Sun.Com Subject: gfx_private update for locking user memory [PSARC/2006/001 Timeout: 01/09/2006] Status: RO Content-Length: 3510 Subject: PSARC FastTrack [01/09/2006]: gfx_private update for locking user memory I am sponsoring this case for John Martin of the Solaris x86 platform group. It requests a Patch release binding and times out Monday, January 9. -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI This information is Copyright 2006 Sun Microsystems, Inc. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: gfx_private update for locking user memory 1.2. Name of Document Author/Supplier: Author: John Martin 1.3 Date of This Document: 02 January, 2006 4. Technical Description Update of gfx_private misc module to add functions to lock user memory mappings. ================================================================= This project updates the graphics private misc module defined by PSARC 2005/475. These additions reflect capabilities available to drivers under Windows and Linux and must be provided for Solaris in order to be performance competitive for OpenGL immediate mode rendering. It adds functions to lock user memory mappings which includes the base pages and the page tables. The functions to lock the base pages for user mappings clone the interface and implementation of mlock()/munlock(). The functions will be called out of the vendor's "black box" code when handling an ioctl in user context. The existing mlock()/munlock() interface is insufficient for use by vendor drivers since: 1. It requires PRIV_PROC_LOCK_MEMORY permission. We don't want to grant this to all OpenGL user space programs. 2. The Linux/FreeBSD architecture being leveraged for drivers calls OS specific functions for locking user mapping out of the vendor "black box" code. The second change is an update to the gfxp_ddi_segmap_setup() defined by PSARC 2005/475. For Linux/FreeBSD, locked mappings do not have their page tables "stolen" by the kernel, at least where action is required by the driver's mmap() vector to restore the page tables an a fault. The user space mappings need to include HAT_LOAD_LOCK to prevent the page tables from being reused. user memory lock function details: ---------------------------------- int gfxp_mlock_user_memory(void *address, uint32_t length); int gfxp_munlock_user_memory(void *address, uint32_t length); These functions are only callable in user context. The pages defined by the user space mapping from address to address+length are locked. gfxp_ddi_segmap_setup() implementation detail: ---------------------------------------------- HAT_LOAD_LOCK is added to the dev_a.hat_flags field. Interface Tables ================ Imported Interfaces: -------------------- gfxp_mlock_user_memory() and gfxp_munlock_user_memory(): valid_usr_range(); as_ctl( MC_LOCK | MC_UNLOCK); set_errno(); gfxp_ddi_segmap_setup() HAT_LOAD_LOCK in structure field dev_a.hat_flags Exported Interfaces: -------------------- gfxp_mlock_user_memory(); Project private gfxp_munlock_user_memory(); Project private 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation (Desktop C-Team) 6.5. ARC review type: FastTrack 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X 6.5. ARC review type: FastTrack From sacadmin Tue Jan 3 08:05:11 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k03G5BIQ011263; Tue, 3 Jan 2006 08:05:11 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k03G5BLn009548; Tue, 3 Jan 2006 08:05:11 -0800 (PST) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k03G573F019849; Tue, 3 Jan 2006 09:05:07 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ISI00401XQNDI00@mail-amer.sun.com> (original mail from John.M.Martin@Sun.COM); Tue, 03 Jan 2006 09:05:07 -0700 (MST) Received: from [129.148.19.26] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ISI00CH6Y0ISSQ0@mail-amer.sun.com>; Tue, 03 Jan 2006 09:05:07 -0700 (MST) Date: Tue, 03 Jan 2006 11:05:02 -0500 From: John Martin Subject: Re: gfx_private update for locking user memory [PSARC/2006/001 Timeout: 01/09/2006] In-reply-to: <200601030021.k030LVuq021762@sac.sfbay.sun.com> Sender: John.M.Martin@Sun.COM To: Alan Coopersmith Cc: PSARC@sac.sfbay.sun.com, Cindy.Sabenorio@Sun.COM Message-id: <43BAA0AE.2030200@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_nDGq6YohsBK+AloTAiTcMQ)" X-Accept-Language: en-us, en References: <200601030021.k030LVuq021762@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051206 Status: RO Content-Length: 3889 This is a multi-part message in MIME format. --Boundary_(ID_nDGq6YohsBK+AloTAiTcMQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Alan Coopersmith wrote: > > user memory lock function details: > ---------------------------------- > > int gfxp_mlock_user_memory(void *address, uint32_t length); > int gfxp_munlock_user_memory(void *address, uint32_t length); > The above calling arguments are from the first draft. The final draft has: int gfxp_mlock_user_memory(caddr_t address, size_t length); int gfxp_munlock_user_memory(caddr_t address, size_t length); The final draft is attached. --Boundary_(ID_nDGq6YohsBK+AloTAiTcMQ) Content-type: text/plain; name=gfxp_fasttrack_umemlock.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=gfxp_fasttrack_umemlock.txt Template Version: @(#)sac_nextcase 1.55 08/11/04 SMI This information is Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. 1. Introduction 1.1. Project/Component Working Name: gfx_private update for locking user memory 1.2. Name of Document Author/Supplier: Author: John Martin 1.3 Date of This Document: 18 December, 2005 4. Technical Description Update of gfx_private misc module to add functions to lock user memory mappings. ================================================================= This project updates the graphics private misc module defined by PSARC 2005/475. These additions reflect capabilities available to drivers under Windows and Linux and must be provided for Solaris in order to be performance competitive for OpenGL immediate mode rendering. It adds functions to lock user memory mappings which includes the base pages and the page tables. The functions to lock the base pages for user mappings clone the interface and implementation of mlock()/munlock(). The functions will be called out of the vendor's "black box" code when handling an ioctl in user context. The existing mlock()/munlock() interface is insufficient for use by vendor drivers since: 1. It requires PRIV_PROC_LOCK_MEMORY permission. We don't want to grant this to all OpenGL user space programs. 2. The Linux/FreeBSD architecture being leveraged for drivers calls OS specific functions for locking user mapping out of the vendor "black box" code. The second change is an update to the gfxp_ddi_segmap_setup() defined by PSARC 2005/475. For Linux/FreeBSD, locked mappings do not have their page tables "stolen" by the kernel, at least where action is required by the driver's mmap() vector to restore the page tables an a fault. The user space mappings need to include HAT_LOAD_LOCK to prevent the page tables from being reused. user memory lock function details: ---------------------------------- int gfxp_mlock_user_memory(caddr_t address, size_t length); int gfxp_munlock_user_memory(caddr_t address, size_t length); These functions are only callable in user context. The pages defined by the user space mapping from address to address+length are locked. gfxp_ddi_segmap_setup() implementation detail: ---------------------------------------------- HAT_LOAD_LOCK is added to the dev_a.hat_flags field. Interface Tables ================ Imported Interfaces: -------------------- gfxp_mlock_user_memory() and gfxp_munlock_user_memory(): valid_usr_range(); as_ctl( MC_LOCK | MC_UNLOCK); set_errno(); gfxp_ddi_segmap_setup() HAT_LOAD_LOCK in structure field dev_a.hat_flags Exported Interfaces: -------------------- gfxp_mlock_user_memory(); Partner private gfxp_munlock_user_memory(); Partner private 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation (Desktop C-Team) 6.5. ARC review type: FastTrack --Boundary_(ID_nDGq6YohsBK+AloTAiTcMQ)-- From sacadmin Tue Jan 3 09:21:53 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k03HLqIQ014858; Tue, 3 Jan 2006 09:21:53 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k03HLnoR003766; Tue, 3 Jan 2006 17:21:49 GMT Received: from 129.156.173.199 (estale [129.156.173.199]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k03HLnn8016441; Tue, 3 Jan 2006 17:21:49 GMT Subject: Re: gfx_private update for locking user memory [PSARC/2006/001 Timeout: 01/09/2006] From: Darren J Moffat To: Alan Coopersmith Cc: PSARC@sac.sfbay.sun.com, Cindy.Sabenorio@Sun.COM, John.M.Martin@Sun.COM In-Reply-To: <200601030021.k030LVuq021762@sac.sfbay.sun.com> References: <200601030021.k030LVuq021762@sac.sfbay.sun.com> Content-Type: text/plain Organization: Sun Microsystems, Inc. Message-Id: <1136308908.456493.6.camel@estale> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.330 Date: Tue, 03 Jan 2006 17:21:48 +0000 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 301 Can you explain how this relates to PSARC/2005/053 and PSARC/2004/580. > 1. It requires PRIV_PROC_LOCK_MEMORY permission. We don't want > to grant this to all OpenGL user space programs. Which is one of the things that PSARC/2004/580 used as its justification as well. -- Darren J Moffat From sacadmin Wed Jan 4 10:09:19 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k04I9JIQ027374; Wed, 4 Jan 2006 10:09:19 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k04I9JLn012891; Wed, 4 Jan 2006 10:09:19 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k04I9Iuf005559; Wed, 4 Jan 2006 11:09:19 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ISK00801YDJ6W00@mail-amer.sun.com> (original mail from John.M.Martin@Sun.COM); Wed, 04 Jan 2006 11:09:18 -0700 (MST) Received: from [129.148.19.26] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ISK00BEGYFHJN36@mail-amer.sun.com>; Wed, 04 Jan 2006 11:09:18 -0700 (MST) Date: Wed, 04 Jan 2006 13:08:07 -0500 From: John Martin Subject: Re: gfx_private update for locking user memory [PSARC/2006/001 Timeout: 01/09/2006] In-reply-to: <1136308908.456493.6.camel@estale> Sender: John.M.Martin@Sun.COM To: Darren J Moffat Cc: Alan Coopersmith , PSARC@sac.sfbay.sun.com, cindy.sabenorio@Sun.COM Message-id: <43BC0F07.80706@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200601030021.k030LVuq021762@sac.sfbay.sun.com> <1136308908.456493.6.camel@estale> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 1181 Darren J Moffat wrote: >Can you explain how this relates to PSARC/2005/053 and PSARC/2004/580. > > >> 1. It requires PRIV_PROC_LOCK_MEMORY permission. We don't want >> to grant this to all OpenGL user space programs. >> > >Which is one of the things that PSARC/2004/580 used as its justification >as well. > > There isn't a direct relation to 2005/053. If the implemenation allows locking by UVAs, I could use these functions inside of the requested gfxp routines, but that would an implementation detail. 2004/580 appears to allow locking by adding the PRIV_PROC_LOCK_MEMORY priviledge, but it isn't clear how to grant that priviledge for all OpenGL applications that can be run on the system. All three major graphics vendors do essentially the same thing. Linux/FreeBSD did not allow the user space client library to lock down selected pages without root permission (mlock/madvise), so they architected their drivers to handle this as a private ioctl. The driver is responsible for executing the OS specific calls which lock/unlock the user space mappings. As long we are leveraging the Linux/FreeBSD code for Solaris, we need to provide the equivalent OS hooks. From sacadmin Wed Jan 4 10:30:11 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k04IUBIQ028717; Wed, 4 Jan 2006 10:30:11 -0800 (PST) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k04IUATe008844; Wed, 4 Jan 2006 10:30:10 -0800 (PST) Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k04IU73F025832; Wed, 4 Jan 2006 11:30:07 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0ISK00I01Y5LNS00@mail-amer.sun.com> (original mail from John.M.Martin@Sun.COM); Wed, 04 Jan 2006 11:30:07 -0700 (MST) Received: from [129.148.19.26] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0ISK00LWOZE5QA40@mail-amer.sun.com>; Wed, 04 Jan 2006 11:30:06 -0700 (MST) Date: Wed, 04 Jan 2006 13:28:55 -0500 From: John Martin Subject: Re: gfx_private update for locking user memory [PSARC/2006/001 Timeout: 01/09/2006] In-reply-to: <43BC0F07.80706@sun.com> Sender: John.M.Martin@Sun.COM To: Darren J Moffat Cc: Alan Coopersmith , PSARC@sac.sfbay.sun.com, Cindy.Sabenorio@Sun.COM Message-id: <43BC13E7.4060607@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200601030021.k030LVuq021762@sac.sfbay.sun.com> <1136308908.456493.6.camel@estale> <43BC0F07.80706@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 1509 John Martin wrote: > Darren J Moffat wrote: > >> Can you explain how this relates to PSARC/2005/053 and PSARC/2004/580. >> >> >>> 1. It requires PRIV_PROC_LOCK_MEMORY permission. We don't want >>> to grant this to all OpenGL user space programs. >>> >> >> Which is one of the things that PSARC/2004/580 used as its justification >> as well. >> >> > There isn't a direct relation to 2005/053. If the implemenation > allows locking by UVAs, I could use these functions inside of > the requested gfxp routines, but that would an implementation detail. > 2004/580 appears to allow locking by adding the PRIV_PROC_LOCK_MEMORY > priviledge, but it isn't clear how to grant that priviledge for > all OpenGL applications that can be run on the system. > > All three major graphics vendors do essentially the same thing. > Linux/FreeBSD did not allow the user space client library to > lock down selected pages without root permission (mlock/madvise), > so they architected their drivers to handle this as a private ioctl. > The driver is responsible for executing the OS specific calls > which lock/unlock the user space mappings. As long we are leveraging > the Linux/FreeBSD code for Solaris, we need to provide the equivalent > OS hooks. Hit send, too soon. The functionality for making certain the PTEs are not reused is not covered by either of the previous PSARC cases. None of the drivers are architected to handle subsequent mmap() driver callbacks when a fault is produced on a stolen PTE. From sacadmin Tue Jan 10 20:39:53 2006 Received: from phys-d3-ha21sca-2 (phys-d3-ha21sca-2.SFBay.Sun.COM [129.145.155.165]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k0B4dqIQ013152 for ; Tue, 10 Jan 2006 20:39:52 -0800 (PST) Received: from conversion-daemon.ha21sca-mail1.sfbay.sun.com by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0ISW00201VIFJ5@ha21sca-mail1.sfbay.sun.com> (original mail from alan.coopersmith@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 10 Jan 2006 20:40:33 -0800 (PST) Received: from [192.168.0.101] (vpn-129-150-24-146.SFBay.Sun.COM [129.150.24.146]) by ha21sca-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0ISW00JGWVNKVF@ha21sca-mail1.sfbay.sun.com>; Tue, 10 Jan 2006 20:40:33 -0800 (PST) Date: Tue, 10 Jan 2006 20:39:42 -0800 From: Alan Coopersmith Subject: Re: gfx_private update for locking user memory [PSARC/2006/001 Timeout: 01/09/2006] In-reply-to: <200601030021.k030LVuq021762@sac.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: Cindy.Sabenorio@Sun.COM, John.M.Martin@Sun.COM Message-id: <43C48C0E.4010305@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050722) References: <200601030021.k030LVuq021762@sac.sfbay.sun.com> Status: RO Content-Length: 486 Alan Coopersmith wrote: > Subject: PSARC FastTrack [01/09/2006]: gfx_private update for locking user memory > > I am sponsoring this case for John Martin of the Solaris x86 platform group. > It requests a Patch release binding and times out Monday, January 9. Since all questions were answered and no further discussion has occured, I'm marking this "closed approved." -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering