From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:56205)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZHnt5-0005ya-TV
	for qemu-devel@nongnu.org; Wed, 22 Jul 2015 02:52:20 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZHnt2-0005lg-NV
	for qemu-devel@nongnu.org; Wed, 22 Jul 2015 02:52:19 -0400
Received: from mailout3.w1.samsung.com ([210.118.77.13]:52642)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <p.fedin@samsung.com>) id 1ZHnt2-0005kF-J7
	for qemu-devel@nongnu.org; Wed, 22 Jul 2015 02:52:16 -0400
Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244])
	by mailout3.w1.samsung.com
	(Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5
	2014)) with ESMTP id <0NRV00JLGN2Z2G00@mailout3.w1.samsung.com> for
	qemu-devel@nongnu.org; Wed, 22 Jul 2015 07:52:11 +0100 (BST)
From: Pavel Fedin <p.fedin@samsung.com>
References: <00ee01d0c2c9$c308c010$491a4030$@samsung.com>
	<CAFEAcA_6so5w8We_2hgCZYJhrf63p51O=my2H7wb+f0VnWEMmA@mail.gmail.com>
	<55ACDA41.2080201@suse.de>
In-reply-to: <55ACDA41.2080201@suse.de>
Date: Wed, 22 Jul 2015 09:52:09 +0300
Message-id: <03d501d0c44a$eefe6da0$ccfb48e0$@samsung.com>
MIME-version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: quoted-printable
Content-language: ru
Subject: Re: [Qemu-devel] [RFC] Virt machine memory map
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: 'Alexander Graf' <agraf@suse.de>, 'Peter Maydell' <peter.maydell@linaro.org>
Cc: 'QEMU Developers' <qemu-devel@nongnu.org>

 Hello!

> > I think the theory we discussed at the time of putting in the PCIe
> > device was that if we wanted this we'd add support for the other
> > PCIe memory window (which would then live at somewhere above 4GB).
> > Alex, can you remember what the idea was?
>=20
> Yes, pretty much. It would give us an upper bound to the amount of RAM
> that we're able to support, but at least we would be able to support =
big
> MMIO regions like for ivshmem.

 But i currently think that specification of "Generic PCI host" assumes =
only a single MMIO region + single PIO region + single ECAM. And we =
cannot have two MMIO regions without changing its specification, which =
can be problematic. Am i wrong about this ?

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia