From: "Michael S. Tsirkin" <mst@redhat.com>
To: Pavel Fedin <p.fedin@samsung.com>
Cc: 'Igor Mammedov' <imammedo@redhat.com>,
'Alexander Graf' <agraf@suse.de>,
pbonzini@redhat.com, 'QEMU Developers' <qemu-devel@nongnu.org>,
'Peter Maydell' <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region
Date: Mon, 27 Jul 2015 18:18:30 +0300 [thread overview]
Message-ID: <20150727181408-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <003401d0c879$937041b0$ba50c510$@samsung.com>
On Mon, Jul 27, 2015 at 05:36:07PM +0300, Pavel Fedin wrote:
> Hello!
>
> > > + /* High MMIO space */
> > > + mmio_alias = g_new0(MemoryRegion, 1);
> > > + memory_region_init_alias(mmio_alias, OBJECT(dev), "pcie-mmio-high",
> > > + mmio_reg, base_mmio_high, size_mmio_high);
> > > + memory_region_add_subregion(get_system_memory(), base_mmio_high, mmio_alias);
> > Is there any specific reason to have 2 separate regions vs using 1 like in
> > pc_pci_as_mapping_init()
> > using region priority instead of splitting.
>
> Unfortunately i'm not familiar very well with qemu memory internals. I saw PC code and i know that
> it adds PCI region of the size of the whole memory, then adds other things as overlapped regions.
> But wouldn't it be some resource waste in this case? I understand that in PC absolutely all "unused"
> addresses fall through to PCI, so that any device can plug in there. On ARM this is different, PCI
> controller is not a core of the system, it's just one of devices instead. And on our case a huge
> part of PCI region between VIRT_PCIE_MMIO and VIRT_PCIE_MMIO_HIGH would never be used. Does it worth
> that ?
>
> Kind regards,
> Pavel Fedin
> Expert Engineer
> Samsung Electronics Research center Russia
It's more a question of figuring out what does real hardware do.
It's true, PIIX has this "everything that isn't memory is PCI"
assumption. We do this for Q35 but I'm not even sure it's the
right thing to do there.
If as you say real ARM hardware doesn't work like this, then QEMU
shouldn't do this for ARM.
--
MST
next prev parent reply other threads:[~2015-07-27 15:18 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 11:09 [Qemu-devel] [PATCH v3] hw/arm/virt: Add high MMIO PCI region Pavel Fedin
2015-07-27 13:26 ` Igor Mammedov
2015-07-27 14:36 ` Pavel Fedin
2015-07-27 15:18 ` Michael S. Tsirkin [this message]
2015-07-27 15:51 ` Peter Maydell
2015-07-29 8:58 ` Pavel Fedin
2015-07-29 9:03 ` Peter Maydell
2015-07-29 9:45 ` Pavel Fedin
2015-07-29 9:56 ` Peter Maydell
2015-07-29 11:16 ` Pavel Fedin
2015-07-29 11:45 ` Peter Maydell
2015-07-29 14:01 ` Pavel Fedin
2015-08-03 7:03 ` Pavel Fedin
2015-08-03 7:56 ` Peter Maydell
2015-08-03 8:09 ` Pavel Fedin
2015-08-03 9:48 ` Peter Maydell
2015-08-03 10:20 ` Pavel Fedin
2015-08-03 20:17 ` Alexander Graf
2015-07-29 9:32 ` Igor Mammedov
2015-07-29 10:03 ` Pavel Fedin
2015-07-29 10:21 ` Peter Maydell
2015-07-29 12:05 ` Igor Mammedov
2015-07-29 12:13 ` Pavel Fedin
2015-07-29 12:35 ` Peter Maydell
2015-07-29 9:10 ` Igor Mammedov
2015-07-29 9:48 ` Pavel Fedin
2015-07-29 11:59 ` Igor Mammedov
2015-07-29 12:02 ` Pavel Fedin
2015-07-29 13:24 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150727181408-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=agraf@suse.de \
--cc=imammedo@redhat.com \
--cc=p.fedin@samsung.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).