From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5bEh-00015n-Ne for qemu-devel@nongnu.org; Wed, 25 May 2016 12:00:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b5bEd-0000kL-FT for qemu-devel@nongnu.org; Wed, 25 May 2016 12:00:43 -0400 Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]:38293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b5bEc-0000jx-C4 for qemu-devel@nongnu.org; Wed, 25 May 2016 12:00:39 -0400 Received: by mail-wm0-x236.google.com with SMTP id n129so68670513wmn.1 for ; Wed, 25 May 2016 09:00:38 -0700 (PDT) References: <1459870344-16773-1-git-send-email-alex.bennee@linaro.org> <1459870344-16773-4-git-send-email-alex.bennee@linaro.org> <570C0276.8040501@gmail.com> <5745C940.4040306@gmail.com> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <5745C940.4040306@gmail.com> Date: Wed, 25 May 2016 17:01:14 +0100 Message-ID: <87vb22cek5.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC v2 03/11] docs: new design document multi-thread-tcg.txt (DRAFTING) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sergey Fedorov Cc: mttcg@listserver.greensocs.com, fred.konrad@greensocs.com, a.rigo@virtualopensystems.com, cota@braap.org, qemu-devel@nongnu.org, mark.burton@greensocs.com, pbonzini@redhat.com, jan.kiszka@siemens.com, rth@twiddle.net, peter.maydell@linaro.org, claudio.fontana@huawei.com Sergey Fedorov writes: > On 11/04/16 23:00, Sergey Fedorov wrote: >> On 05/04/16 18:32, Alex Bennée wrote: >> >> (snip) >>> + >>> +Memory maps and TLBs >>> +-------------------- >>> + >>> +The memory handling code is fairly critical to the speed of memory >>> +access in the emulated system. >>> + >> It would be nice to put some intro sentence for the following bullets :) >> >>> + - Memory regions (dividing up access to PIO, MMIO and RAM) >>> + - Dirty page tracking (for code gen, migration and display) >>> + - Virtual TLB (for translating guest address->real address) > > There's also a global page table - called 'l1_map' - which is used for: > * keeping a list of TBs generated from a given physical guest page for > further code invalidation on page writes > * holding a bitmap to track which regions of a given physical guest page > actually contain code for optimized code invalidation on page writes > (used only in system mode emulation) > * holding page flags, e.g. protection bits (used only in user mode > emulation) > > The page table seems to be protected by 'mmap_lock' in user mode > emulation but by 'tb_lock' in system mode emulation. It may turn to be > possible to read it safely even with no lock held. I've started adding words to that effect to the document. > > Kind regards, > Sergey > >>> + >>> +There is a both a fast path walked by the generated code and a slow >>> +path when resolution is required. When the TLB tables are updated we >>> +need to ensure they are done in a safe way by bringing all executing >>> +threads to a halt before making the modifications. >> Again, I think we could benefit if we could possibly manage to avoid >> bringing vCPU threads to halt. >> >> Nothing about memory regions and dirty page tracking? >> >>> + >>> +DESIGN REQUIREMENTS: >>> + >>> + - TLB Flush All/Page >>> + - can be across-CPUs >>> + - will need all other CPUs brought to a halt >> s/will/may/ ? >> >>> + - TLB Update (update a CPUTLBEntry, via tlb_set_page_with_attrs) >>> + - This is a per-CPU table - by definition can't race >>> + - updated by it's own thread when the slow-path is forced >> (snip) > > Kind regards, > Sergey -- Alex Bennée