From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qxfyn-00069Z-H2 for qemu-devel@nongnu.org; Sun, 28 Aug 2011 10:04:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qxfym-0000eF-IC for qemu-devel@nongnu.org; Sun, 28 Aug 2011 10:04:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qxfym-0000e6-A5 for qemu-devel@nongnu.org; Sun, 28 Aug 2011 10:04:52 -0400 Message-ID: <4E5A4AF0.20707@redhat.com> Date: Sun, 28 Aug 2011 17:04:32 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1314040622.6866.268.camel@x201.home> <20110823131441.GN2079@amd.com> <1314119311.2859.59.camel@bling.home> <20110824085213.GB2079@amd.com> <1314198467.2859.192.camel@bling.home> <20110825123146.GD1923@amd.com> <20110826042423.GF2308@yookeroo.fritz.box> <20110826092440.GO1923@amd.com> <4E5A3F18.7050903@redhat.com> <20110828135632.GG8978@8bytes.org> In-Reply-To: <20110828135632.GG8978@8bytes.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Joerg Roedel Cc: Alex Williamson , Alexey Kardashevskiy , "kvm@vger.kernel.org" , Paul Mackerras , "Roedel, Joerg" , qemu-devel , Alexander Graf , chrisw , iommu , "linux-pci@vger.kernel.org" , linuxppc-dev , "benve@cisco.com" On 08/28/2011 04:56 PM, Joerg Roedel wrote: > On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote: > > On 08/26/2011 12:24 PM, Roedel, Joerg wrote: > > >> The biggest problem with this approach is that it has to happen in the > >> context of the given process. Linux can't really modify an mm which > >> which belong to another context in a safe way. > >> > > > > Is use_mm() insufficient? > > Yes, it introduces a set of race conditions when a process that already > has an mm wants to take over another processes mm temporarily (and when > use_mm is modified to actually provide this functionality). It is only > save when used from kernel-thread context. > > One example: > > Process A Process B Process C > . . . > . <-- takes A->mm . > . and assignes as B->mm . > . . --> Wants to take > . . B->mm, but gets > A->mm now Good catch. > > This can't be secured by a lock, because it introduces potential > A->B<-->B->A lock problem when two processes try to take each others mm. > It could probably be solved by a task->real_mm pointer, havn't thought > about this yet... > Or a workqueue - you get a kernel thread context with a bit of boilerplate. -- error compiling committee.c: too many arguments to function