qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Qemu and 32 PCIe devices


From: Peter Maydell
Subject: Re: [Qemu-devel] Qemu and 32 PCIe devices
Date: Wed, 9 Aug 2017 12:11:11 +0100

On 9 August 2017 at 11:56, Laszlo Ersek <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]