qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] GSOC 2015 Project Proposal


From: Alexander Graf
Subject: Re: [Qemu-devel] GSOC 2015 Project Proposal
Date: Wed, 18 Mar 2015 15:16:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 03/18/2015 12:46 PM, Stefan Hajnoczi wrote:
On Mon, Feb 9, 2015 at 12:44 AM, Xin Tong <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]