On 09/19/2012 10:57 PM, Blue Swirl wrote: > On Wed, Sep 19, 2012 at 12:54 PM, Avi Kivity <a...@redhat.com> wrote: >> On 09/14/2012 10:51 PM, Blue Swirl wrote: >>>> >>>> exec: >>> >>> These files need cleanup so that TCG code gets into tcg/. Maybe also >>> TB and CPUTLB handling. >> >> Some of that could be done by adding a separate MemoryListener for tcg. > > But the TBs and CPUTLB are based on virtual mappings, it would mean > that MMU maps would have to be modeled using memory API. Is that fast > enough?
No. The memory API is designed to be fast on reads at the expense of being slow on writes, and this will get worse as rcu is added. I meant that the various calls to invalidate tcg-specific caches can use a tcg-specific MemoryListener. > This could have nice cleanup effects though and for example enable > generic 'info vmtree' to discover VA->PA mappings for any target > instead of current MMU table walkers. How? That's in a hardware defined format that's completely invisible to the memory API. -- error compiling committee.c: too many arguments to function
