Re: [Qemu-devel] directory hierarchy

[Blue Swirl]

On Thu, Sep 20, 2012 at 11:31 AM, Avi Kivity <address@hidden> wrote:
> On 09/19/2012 10:57 PM, Blue Swirl wrote:
>> On Wed, Sep 19, 2012 at 12:54 PM, Avi Kivity <address@hidden> 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.

Maybe.

>
>> 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.

It's invisible now, but target-specific code could grab the mappings
and feed them to memory API. Memory API would just see the per-CPU
virtual memory as address spaces that map to physical memory address
space.

For RAM backed MMU tables like x86 and Sparc32, writes to page table
memory areas would need to be tracked like SMC. For in-MMU TLBs, this
would not be needed.

Again, if performance would degrade, this would not be worthwhile. I'd
expect VA->PA mappings to change at least at context switch rate +
page fault rate + mmap/exec activity so this could amount to thousands
of changes per second per CPU.

In theory KVM could use memory API as CPU type agnostic way to
exchange this information, I'd expect that KVM exit rate is not nearly
as big and in many cases exchange of mapping information would not be
needed. It would not improve performance there either.

>
> --
> error compiling committee.c: too many arguments to function