From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:35097)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1YfQ2e-0004Ox-5m
	for qemu-devel@nongnu.org; Tue, 07 Apr 2015 05:43:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1YfQ2b-0003Wt-DI
	for qemu-devel@nongnu.org; Tue, 07 Apr 2015 05:43:32 -0400
Received: from mail-ig0-f178.google.com ([209.85.213.178]:37446)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1YfQ2b-0003Wk-8r
	for qemu-devel@nongnu.org; Tue, 07 Apr 2015 05:43:29 -0400
Received: by igblo3 with SMTP id lo3so6760451igb.0
	for <qemu-devel@nongnu.org>; Tue, 07 Apr 2015 02:43:28 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <20150407113100-mutt-send-email-mst@redhat.com>
References: <1428055432-12120-1-git-send-email-zhaoshenglong@huawei.com>
	<1428346052.2973.26.camel@deneb.redhat.com>
	<55234469.9060404@huawei.com>
	<CAFEAcA-52kAaE0oZmb00g_4QMg7G1ddZvf4pzMDytHYL8=JGeA@mail.gmail.com>
	<20150407113100-mutt-send-email-mst@redhat.com>
From: Peter Maydell <peter.maydell@linaro.org>
Date: Tue, 7 Apr 2015 10:43:07 +0100
Message-ID: <CAFEAcA_N58xMMfNiwjadpAm_g2+NhWmOQpUZ-htb9CwuGzpYKw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] [PATCH v4 00/20] Generate ACPI v5.1 tables and
 expose it to guest over fw_cfg on ARM
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: hangaohuai@huawei.com, Igor Mammedov <imammedo@redhat.com>, Alexander Spyridakis <a.spyridakis@virtualopensystems.com>, Shannon Zhao <zhaoshenglong@huawei.com>, Claudio Fontana <claudio.fontana@huawei.com>, QEMU Developers <qemu-devel@nongnu.org>, "Huangpeng (Peter)" <peter.huangpeng@huawei.com>, Hanjun Guo <hanjun.guo@linaro.org>, Mark Salter <msalter@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Laszlo Ersek <lersek@redhat.com>, Christoffer Dall <christoffer.dall@linaro.org>, Shannon Zhao <shannon.zhao@linaro.org>

On 7 April 2015 at 10:32, Michael S. Tsirkin <mst@redhat.com> wrote:
> On Tue, Apr 07, 2015 at 10:19:22AM +0100, Peter Maydell wrote:
>> On 7 April 2015 at 03:43, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> > The dts node is:
>> >                 ranges = <0x1000000 0x0 0x0 0x0 0x3eff0000 0x0 0x10000
>> >                           0x2000000 0x0 0x10000000 0x0 0x10000000 0x0 0x2eff0000>;
>> >                 reg = <0x0 0x3f000000 0x0 0x1000000>;
>> >                 bus-range = <0x0 0xf>;
>> >
>> > The ACPI table entry:
>> >             Method (_CBA, 0, NotSerialized)  // _CBA: Configuration Base Address
>> >             {
>> >                 Return (0x3F000000)
>> >             }
>> >             Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
>> >             {
>> >                 Name (RBUF, ResourceTemplate ()
>> >                 {
>> >                     WordBusNumber (ResourceProducer, MinFixed, MaxFixed, PosDecode,
>> >                         0x0000,             // Granularity
>> >                         0x0000,             // Range Minimum
>> >                         0x000F,             // Range Maximum
>> >                         0x0000,             // Translation Offset
>> >                         0x0010,             // Length
>> >                         ,, )
>> >                     DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, Cacheable, ReadWrite,
>>
>> Is this claiming that the non-cacheable PCI MMIO region is cacheable?
>> If so that isn't right...
>
> I suspect that's fine.
> Some parts of MMIO might be cacheable. This really depends on the
> device

No, this is the PCI "non-cacheable MMIO" window. (We don't have
a cacheable MMIO window on this board). In the DTB we advertise
it as non-cacheable, and we should do the same in ACPI.

-- PMM