[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 03/11] docs: new design document multi-thread-t
From: |
Sergey Fedorov |
Subject: |
Re: [Qemu-devel] [RFC v2 03/11] docs: new design document multi-thread-tcg.txt (DRAFTING) |
Date: |
Wed, 25 May 2016 18:48:16 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 |
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.
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