From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:43718)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QbIPj-0000s5-V0
	for qemu-devel@nongnu.org; Mon, 27 Jun 2011 16:28:12 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QbIPi-0000LA-IC
	for qemu-devel@nongnu.org; Mon, 27 Jun 2011 16:28:11 -0400
Received: from mail-pz0-f45.google.com ([209.85.210.45]:59242)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QbIPi-0000L4-5O
	for qemu-devel@nongnu.org; Mon, 27 Jun 2011 16:28:10 -0400
Received: by pzk30 with SMTP id 30so3465361pzk.4
	for <qemu-devel@nongnu.org>; Mon, 27 Jun 2011 13:28:09 -0700 (PDT)
Message-ID: <4E08E7D5.4000207@codemonkey.ws>
Date: Mon, 27 Jun 2011 15:28:05 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
References: <1309180927-19003-1-git-send-email-avi@redhat.com>	<4E089DFF.3090401@redhat.com>
	<20110627155216.GA5614@redhat.com>	<4E08A79D.7010606@redhat.com>
	<20110627155920.GB5614@redhat.com>
In-Reply-To: <20110627155920.GB5614@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC v2 00/20] 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: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org

On 06/27/2011 10:59 AM, Michael S. Tsirkin wrote:
> On Mon, Jun 27, 2011 at 06:54:05PM +0300, Avi Kivity wrote:
>> On 06/27/2011 06:52 PM, Michael S. Tsirkin wrote:
>>> - bridges might also enable subtractive decoding
>>>    (required for isa behind the bridge)
>>
>> What does that mean?
>
> subtractive decoding is
> a method of address decoding in which a device accepts all
> accesses not positively decoded by another agent.

Subtractive decoding is very slow in real hardware so generally any well 
known devices are positively decoded (like anything on the Super I/O 
chip).  Unless we're dealing with very odd ISA devices, we probably 
don't need to worry about subtractive decoding.

The real key point is, each level may dispatch in subtly different ways. 
  You can get 95% of the way there with a generic memory API.  I think 
it's the 95% that actually matters but just realize that we can't model 
hardware exactly without true hierarchical dispatch.

Regards,

Anthony Liguori