Re: [Qemu-devel] [RFC] Memory API

[Avi Kivity <avi@redhat.com>]

On 05/18/2011 07:42 PM, Jan Kiszka wrote:
> >
> >  You cannot do this properly with a single dispatch table because the
> >  behavior depends on where in the hierarchy the I/O is being handled.
>
> Ah, now I remember why I did not follow that path: Not invasiveness, but
> performance concerns. I assume TLB refills have their share in TCG
> performance, and adding another lookup layer, probably for every target,
> will be measurable. I was wondering if that is worth the, granted,
> cleaner design.

We can have a per-cpu hash table and flattened slots list, though that 
seems wasteful.  I agree that a tree walk is too expensive for a tlb miss.

We'll start however with the existing phys_desc, so no performance 
concerns, and no per-cpu APIC address either (btw it is broken in kvm as 
well, and hard to fix - we don't want per-cpu page tables).

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