From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42335)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1a3Gw9-0008In-L3
	for qemu-devel@nongnu.org; Mon, 30 Nov 2015 00:23:42 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1a3Gw6-0002jx-IK
	for qemu-devel@nongnu.org; Mon, 30 Nov 2015 00:23:41 -0500
Received: from mx1.redhat.com ([209.132.183.28]:53444)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1a3Gw6-0002hp-Cv
	for qemu-devel@nongnu.org; Mon, 30 Nov 2015 00:23:38 -0500
References: <1448553628-5446-1-git-send-email-marcel@redhat.com>
	<56573AF0.2050207@redhat.com> <565AF179.8010302@redhat.com>
From: Laszlo Ersek <lersek@redhat.com>
Message-ID: <565BDD55.1000207@redhat.com>
Date: Mon, 30 Nov 2015 06:23:33 +0100
MIME-Version: 1.0
In-Reply-To: <565AF179.8010302@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH V3 0/3] hw/pcie: Multi-root support for Q35
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: Marcel Apfelbaum <marcel@redhat.com>
Cc: ehabkost@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, armbru@redhat.com, kraxel@redhat.com, laine@redhat.com, pbonzini@redhat.com, imammedo@redhat.com, rth@twiddle.net

On 11/29/15 13:37, Marcel Apfelbaum wrote:
> On 11/26/2015 07:01 PM, Laszlo Ersek wrote:
>> Hello Marcel,
>>
> 
> [...] if you have ACPI table dumps from within an i440fx
>> SeaBIOS Linux guest, both from before and after your QEMU patches, and
>> those dumps are identical, then that's good evidence against
>> regressions. (I tend to do such acpidump-based comparisons when messing
>> with ACPI builder code.)
>>
> 
> Hi,
> 
> OK, there are no functional differences between the SSDT before/after,
> however the optimization made in patch "1/3 hw/acpi: merge pxb adjacent
> memory/IO ranges"
> for pxb-pcies works also for pxb, which is a good thing.
> 
> SSDT before (only PXB differences) :
> -----------------------------------
> 
>  Device (PC0A)
>  {
>    ...
>     Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource Settings
>             {
>                 ...
>                 DWordMemory (ResourceProducer, PosDecode, MinFixed,
> MaxFixed, NonCacheable, ReadWrite,
>                     0x00000000,         // Granularity
>                     0xFE800000,         // Range Minimum
>                     0xFE9FFFFF,         // Range Maximum
>                     0x00000000,         // Translation Offset
>                     0x00200000,         // Length
>                     ,, , AddressRangeMemory, TypeStatic)
>                 DWordMemory (ResourceProducer, PosDecode, MinFixed,
> MaxFixed, NonCacheable, ReadWrite,
>                     0x00000000,         // Granularity
>                     0xFE000000,         // Range Minimum
>                     0xFE7FFFFF,         // Range Maximum
>                     0x00000000,         // Translation Offset
>                     0x00800000,         // Length
>                     ,, , AddressRangeMemory, TypeStatic)
>                 ...
>             })
>  }
> 
> SSDT after:
> ------------
> 
> Device (PC0A)
> {
>   ...
>   Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
>      {
>     ...
>     DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed,
> NonCacheable, ReadWrite,
>                     0x00000000,         // Granularity
>                     0xFE000000,         // Range Minimum
>                     0xFE9FFFFF,         // Range Maximum
>                     0x00000000,         // Translation Offset
>                     0x00A00000,         // Length
>                     ,, , AddressRangeMemory, TypeStatic)
>        ...
>     })
> }
> 
> As it can be seen, the optimization works also for PXB by merging the
> MEM regions.
> 
> Thanks,
> Marcel
> 
> [...]

Looks good and makes sense, thanks.

Laszlo