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
