qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Wed, 18 May 2011 20:05:23 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]