From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYEn0-00059r-HA for qemu-devel@nongnu.org; Wed, 18 Mar 2015 10:17:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYEmx-00070O-7D for qemu-devel@nongnu.org; Wed, 18 Mar 2015 10:17:42 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52892 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYEmw-00070H-UH for qemu-devel@nongnu.org; Wed, 18 Mar 2015 10:17:39 -0400 Message-ID: <550988C1.1040504@suse.de> Date: Wed, 18 Mar 2015 15:16:33 +0100 From: Alexander Graf MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] GSOC 2015 Project Proposal List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Xin Tong Cc: David Gibson , QEMU Developers , Richard Henderson On 03/18/2015 12:46 PM, Stefan Hajnoczi wrote: > On Mon, Feb 9, 2015 at 12:44 AM, Xin Tong wrote: >> I would like to do GSOC this summer. The project i have in mind is to >> implement a set of facilities to make implementing Hardware >> transactional memory (HTM) easier in QEMU. >> >> HTM has become available in many architecture supported by QEMU, e.g. >> i386, PowerPC, etc. Currently, necessary memory tracking. conflict >> detection and transaction rollbak/commit are not available in QEMU. As >> a result, HTM is supported in a very rudimentary fashion in PowerPC, >> i.e. the transaction begins (tbegin in PowerPC) always trigger a fault >> to the fallback code path. Even though HTM is supported by different >> architectures, the underlying principle are very similar and therefore >> it is beneficial to provide a set of facilities to make implementing >> HTM easier in QEMU. >> >> These facilities should include. >> >> A modified software TLB to make memory address and value tracking simple. >> A performant and memory efficient value/address tracking facility to >> detect read/write conflicts for transactions. >> A performant and memory efficient mechanism to rollback and commit >> memory accesses. >> A mechanism to abort transactions on the current processor as well as >> remote processor. >> >> I will come up with a more detailed proposal as application time draws >> close. Any suggestions are appreciated at the moment. > Hi Xin, > Thanks for proposing this project idea. There haven't been any > responses yet. I have CCed Alexander Graf and David Gibson, who have > worked on the PowerPC target, and Richard Henderson in case he's > interested in transactional memory. > > You need to find a mentor willing to supervise this project idea. > Hopefully bumping this email thread will remind people to consider > your idea. I think this would be a very interesting research project, but I'm wary that the overhead of TLB allocation synchronization with other vcpus ends up pretty expensive for the normal use case of non-transactional operation. I'm also not sure whether GSoC is long enough to actually get to the point where what you're proposing works. How much experience do you have in this field? Alex