From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:36668)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1QMkBe-0004qW-Ie
	for qemu-devel@nongnu.org; Wed, 18 May 2011 13:05:31 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1QMkBc-0006FZ-Lc
	for qemu-devel@nongnu.org; Wed, 18 May 2011 13:05:30 -0400
Received: from mx1.redhat.com ([209.132.183.28]:20333)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <avi@redhat.com>) id 1QMkBc-0006FF-EV
	for qemu-devel@nongnu.org; Wed, 18 May 2011 13:05:28 -0400
Message-ID: <4DD3FC53.4080301@redhat.com>
Date: Wed, 18 May 2011 20:05:23 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
References: <4DD3C5B9.1080908@redhat.com>	<4DD3D236.90708@siemens.com>	<4DD3D95E.2060105@redhat.com>	<4DD3E1B3.3020405@siemens.com>
	<4DD3E47F.9060104@redhat.com>	<4DD3F4D5.7020807@codemonkey.ws>
	<4DD3F6E4.2020606@siemens.com>
In-Reply-To: <4DD3F6E4.2020606@siemens.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] Memory API
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel <qemu-devel@nongnu.org>

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