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
