From: Peter Maydell <peter.maydell@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>,
Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>,
Marcel Apfelbaum <marcel@redhat.com>,
Drew Jones <drjones@redhat.com>,
Christoffer Dall <cdall@linaro.org>,
Gema Gomez-Solano <gema.gomez-solano@linaro.org>,
Marc Zygnier <marc.zyngier@arm.com>
Subject: Re: [Qemu-devel] Qemu and 32 PCIe devices
Date: Wed, 9 Aug 2017 12:11:11 +0100 [thread overview]
Message-ID: <CAFEAcA_7hhP-w3HzFSwdABgK00sgJfbC0nSJQfU9m3BjRKcc1Q@mail.gmail.com> (raw)
In-Reply-To: <c03faf70-9bad-aea7-00ed-8825e8770d03@redhat.com>
On 9 August 2017 at 11:56, Laszlo Ersek <lersek@redhat.com> wrote:
> Now that I look at the "info mtree" monitor output of a random VM, I see
> the following "address-space"s:
> - memory
> - I/O
> - cpu-memory
> - bunch of nameless ones, with top level regions called
> "bus master container"
> - several named "virtio-pci-cfg-as"
> - KVM-SMRAM
>
> I (sort of) understand MemoryRegions and aliases, but:
> - I don't know why "memory" and "cpu-memory" exist separately, for example,
"memory" is the "system address space", ie the default overall
view of memory where most devices appear and which gets
used by DMA'ing devices that don't have a proper model of
what their view of the world should be.
"cpu-memory" is specifically the view of the world that
the CPU has. Per-CPU memory mapped devices and devices
that are visible to the CPU but not to random DMA'ing
things can appear here (and not in the 'memory' address space).
Generally "cpu-memory" will be created effectively as
"memory" plus some other stuff.
Some CPU architectures have more than one address space
per CPU -- notably ARM TrustZone-supporting CPUs
have "cpu-memory" for the NonSecure view and "cpu-secure-memory"
for the Secure view.
The overall aim here is to better model the real world,
where different memory transaction masters can sit on
different buses or in different places in the bus fabric,
and thus have access to different things. Anything that
is a bus master should ideally have its own AddressSpace,
because for QEMU an AddressSpace is the endpoint that
you use to initiate memory transactions. MemoryRegions
on the other hand are what you use for building up the
hierarchy of devices sitting on buses and so on, so
when you're setting up the simulation you pass a device
which is a bus master a MemoryRegion defining "this is
the world you can see", and the device creates an
AddressSpace from it in order to be able to interact
with it.
(We have address_space_init_shareable() to reduce the
proliferation of theoretically distinct but in
practice identical AddressSpaces.)
Similarly, I'm not familiar with the PCI code, but
conceptually each PCI device is a bus master and wants
an AddressSpace to do transactions into.
thanks
-- PMM
next prev parent reply other threads:[~2017-08-09 11:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-08 10:39 [Qemu-devel] Qemu and 32 PCIe devices Marcin Juszkiewicz
2017-08-08 15:51 ` Laszlo Ersek
2017-08-09 1:06 ` Laszlo Ersek
2017-08-09 7:26 ` Paolo Bonzini
2017-08-09 10:00 ` Laszlo Ersek
2017-08-09 10:16 ` Paolo Bonzini
2017-08-09 10:56 ` Laszlo Ersek
2017-08-09 11:11 ` Peter Maydell [this message]
2017-08-09 11:15 ` Paolo Bonzini
2017-08-09 17:16 ` Michael S. Tsirkin
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=CAFEAcA_7hhP-w3HzFSwdABgK00sgJfbC0nSJQfU9m3BjRKcc1Q@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=cdall@linaro.org \
--cc=drjones@redhat.com \
--cc=gema.gomez-solano@linaro.org \
--cc=lersek@redhat.com \
--cc=marc.zyngier@arm.com \
--cc=marcel@redhat.com \
--cc=marcin.juszkiewicz@linaro.org \
--cc=pbonzini@redhat.com \
--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).