From: Peter Maydell <peter.maydell@linaro.org>
To: QEMU Developers <qemu-devel@nongnu.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] unique (or otherwise) RAM block names
Date: Mon, 4 Jun 2018 13:20:29 +0100 [thread overview]
Message-ID: <CAFEAcA8AFApznN92TvtSrDYDzOrvd3DyQvVEbbrvxzGY5UiCmw@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA8Khsu3HTPbsJW-gBvbzrzJkb=z3tpmELwGyw3rQObJFA@mail.gmail.com>
On 1 June 2018 at 18:34, Peter Maydell <peter.maydell@linaro.org> wrote:
> In particular, this means that if you create what you expect to
> be a local-to-this-device RAM memory region in a SysBusDevice,
> then (because SysBus doesn't implement get_dev_path), there is
> no per-device qualification added to the region name, and so the
> code silently creates a globally-namespaced RAM region.
> Trying to create multiple instances of the device therefore fails.
I did an audit of everywhere that creates a RAM region with an
owner (either by calling vmstate_register_ram() with a non-NULL
owner, or by calling memory_region_init_{ram,rom,rom_device} with
a non-NULL owner:
hw/display/g364fb.c: vmstate_register_ram(&s->mem_vram, dev);
TYPE_G364 (sysbus)
hw/display/vga.c: vmstate_register_ram(&s->vram, global_vmstate ?
NULL : DEVICE(obj));
NULL dev, or passed by caller of vga_common_init()
TYPE_ISA_CIRRUS_VGA (ISA) (but OK as it passes global_vmstate = true)
TYPE_PCI_CIRRUS_VGA (PCI)
TYPE_PCI_QXL (PCI)
TYPE_PCI_VGA (PCI)
TYPE_VIRTIO_VGA (PCI)
TYPE_VMWARE_SVGA (PCI)
hw/mem/pc-dimm.c: vmstate_register_ram(vmstate_mr, dev);
TYPE_PC_DIMM (?)
hw/misc/ivshmem.c: vmstate_register_ram(s->ivshmem_bar2, DEVICE(s));
TYPE_IVSHMEM_COMMON (PCI)
hw/display/qxl.c: memory_region_init_ram(&qxl->rom_bar,
OBJECT(qxl), "qxl.vrom",
hw/display/qxl.c: memory_region_init_ram(&qxl->vram_bar,
OBJECT(qxl), "qxl.vram",
hw/display/qxl.c: memory_region_init_ram(&qxl->vga.vram,
OBJECT(dev), "qxl.vgavram",
TYPE_PCI_QXL (PCI)
hw/pci/pci.c: memory_region_init_rom(&pdev->rom, OBJECT(pdev),
name, size, &error_fatal);
-- PCIDevice
hw/arm/aspeed_soc.c: memory_region_init_ram(&s->sram, OBJECT(dev),
"aspeed.sram",
TYPE_ASPEED_SOC (sysbus)
hw/arm/integratorcp.c: memory_region_init_ram(&s->flash, OBJECT(d),
"integrator.flash", 0x100000,
TYPE_INTEGRATOR_CM (sysbus)
hw/display/bochs-display.c: memory_region_init_ram(&s->vram, obj,
"bochs-display-vram", s->vgamem,
TYPE_BOCHS_DISPLAY (PCI)
hw/display/sm501.c: memory_region_init_ram(&s->local_mem_region,
OBJECT(dev), "sm501.local",
TYPE_SYSBUS_SM501 (sysbus)
TYPE_PCI_SM501 (PCI)
hw/tpm/tpm_crb.c: memory_region_init_ram(&s->cmdmem, OBJECT(s),
TYPE_TPM_CRB (TYPE_DEVICE)
hw/xen/xen_pt_load_rom.c: memory_region_init_ram(&dev->rom, owner,
name, st.st_size, &error_abort);
PCI device
hw/arm/aspeed.c: memory_region_init_rom(boot_rom, OBJECT(bmc),
"aspeed.boot_rom",
-- this is bogus because BMC isn't really an object; it happens
that its first member is an AspeedSoCState; TYPE_ASPEED_SOC is a
TYPE_DEVICE
memory_region_init_rom_device()
hw/block/pflash_cfi01.c: memory_region_init_rom_device(
TYPE_CFI_PFLASH01 (sysbus)
hw/block/pflash_cfi02.c:
memory_region_init_rom_device(&pfl->orig_mem, OBJECT(pfl), pfl->be ?
TYPE_CFI_PFLASH02 (sysbus)
PCI implements get_dev_path. The other uses of RAM regions with
owners but unexpectedly non-local names thus are:
TYPE_G364 (sysbus)
TYPE_PC_DIMM (?)
TYPE_ASPEED_SOC (sysbus)
TYPE_INTEGRATOR_CM (sysbus)
TYPE_SYSBUS_SM501 (sysbus)
TYPE_TPM_CRB (TYPE_DEVICE)
TYPE_CFI_PFLASH01 (sysbus)
TYPE_CFI_PFLASH02 (sysbus)
thanks
-- PMM
next prev parent reply other threads:[~2018-06-04 12:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-01 17:34 [Qemu-devel] unique (or otherwise) RAM block names Peter Maydell
2018-06-01 17:42 ` Dr. David Alan Gilbert
2018-06-04 12:20 ` Peter Maydell [this message]
2018-06-04 12:48 ` Laszlo Ersek
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=CAFEAcA8AFApznN92TvtSrDYDzOrvd3DyQvVEbbrvxzGY5UiCmw@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=dgilbert@redhat.com \
--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).