From: Peter Maydell <peter.maydell@linaro.org>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Aleksandar Rikalo <aleksandar.rikalo@syrmia.com>,
Qemu-block <qemu-block@nongnu.org>,
Huacai Chen <chenhuacai@kernel.org>,
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
QEMU Developers <qemu-devel@nongnu.org>,
Artyom Tarasenko <atar4qemu@gmail.com>,
Cleber Rosa <crosa@redhat.com>, John Snow <jsnow@redhat.com>,
Aurelien Jarno <aurelien@aurel32.net>,
Wainer dos Santos Moschetta <wainersm@redhat.com>
Subject: Re: [RFC PATCH 3/5] hw/pci-host/bonito: Remap PCI "lo" regions when PCIMAP reg is modified
Date: Fri, 1 Jan 2021 23:19:43 +0000 [thread overview]
Message-ID: <CAFEAcA_Hi+4BAPL+0BhDgbsXtzDQjiCs0SAs44mKgUbcSE+XCg@mail.gmail.com> (raw)
In-Reply-To: <20210101231215.1870611-4-f4bug@amsat.org>
On Fri, 1 Jan 2021 at 23:12, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> Per the datasheet (Chapter 5.7.1. "PCI address regions"),
> the PCIMAP register:
>
> Map the 64Mbyte regions marked "PCI_Lo" in the CPU's memory map,
> each of which can be assigned to any 64 Mbyte-aligned region of
> PCI memory. The address appearing on the PCI bus consists of the
> low 26 bits of the CPU physical address, with the high 6 bits
> coming from the appropriate base6 field. Each of the three regions
> is an independent window onto PCI memory, and can be positioned on
> any 64Mbyte boundary in PCI space.
>
> Remap the 3 regions on reset and when PCIMAP is updated.
>
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> hw/pci-host/bonito.c | 49 ++++++++++++++++++++++++++++++++------------
> 1 file changed, 36 insertions(+), 13 deletions(-)
>
> diff --git a/hw/pci-host/bonito.c b/hw/pci-host/bonito.c
> index a99eced0657..c58eeaf504c 100644
> --- a/hw/pci-host/bonito.c
> +++ b/hw/pci-host/bonito.c
> @@ -137,6 +137,10 @@ FIELD(BONGENCFG, PCIQUEUE, 12, 1)
>
> /* 4. PCI address map control */
> #define BONITO_PCIMAP (0x10 >> 2) /* 0x110 */
> +FIELD(PCIMAP, LO0, 0, 6)
> +FIELD(PCIMAP, LO1, 6, 6)
> +FIELD(PCIMAP, LO2, 12, 6)
> +FIELD(PCIMAP, 2G, 18, 1)
> #define BONITO_PCIMEMBASECFG (0x14 >> 2) /* 0x114 */
> #define BONITO_PCIMAP_CFG (0x18 >> 2) /* 0x118 */
>
> @@ -237,6 +241,7 @@ struct BonitoState {
> qemu_irq *pic;
> PCIBonitoState *pci_dev;
> MemoryRegion pci_mem;
> + MemoryRegion pcimem_lo_alias[3];
> };
>
> #define TYPE_BONITO_PCI_HOST_BRIDGE "Bonito-pcihost"
> @@ -245,6 +250,31 @@ OBJECT_DECLARE_SIMPLE_TYPE(BonitoState, BONITO_PCI_HOST_BRIDGE)
> #define TYPE_PCI_BONITO "Bonito"
> OBJECT_DECLARE_SIMPLE_TYPE(PCIBonitoState, PCI_BONITO)
>
> +static void bonito_remap(PCIBonitoState *s)
> +{
> + static const char *const region_name[3] = {
> + "pci.lomem0", "pci.lomem1", "pci.lomem2"
> + };
> + BonitoState *bs = BONITO_PCI_HOST_BRIDGE(s->pcihost);
> +
> + for (size_t i = 0; i < 3; i++) {
> + uint32_t offset = extract32(s->regs[BONITO_PCIMAP], 6 * i, 6) << 26;
> +
> + if (memory_region_is_mapped(&bs->pcimem_lo_alias[i])) {
> + memory_region_del_subregion(get_system_memory(),
> + &bs->pcimem_lo_alias[i]);
> + object_unparent(OBJECT(&bs->pcimem_lo_alias[i]));
> + }
> +
> + memory_region_init_alias(&bs->pcimem_lo_alias[i], OBJECT(s),
> + region_name[i], &bs->pci_mem,
> + offset, 64 * MiB);
> + memory_region_add_subregion(get_system_memory(),
> + BONITO_PCILO_BASE + i * 64 * MiB,
> + &bs->pcimem_lo_alias[i]);
> + }
Rather than delete-and-reinit-and-add, it's probably better to
just create the subregions once at device startup, and then use
memory_region_set_enabled() and memory_region_set_address()
to manipulate whether the subregion is visible and what address
in the system memory it is mapped at.
thanks
-- PMM
next prev parent reply other threads:[~2021-01-01 23:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-01 23:12 [RFC PATCH 0/5] hw/mips: Fix Fuloong2E to boot Linux guest again Philippe Mathieu-Daudé
2021-01-01 23:12 ` [RFC PATCH 1/5] ide: Make room for flags in PCIIDEState and add one for legacy mode Philippe Mathieu-Daudé
2021-01-01 23:12 ` [RFC PATCH 2/5] via-ide: Fix fuloong2e support Philippe Mathieu-Daudé
2021-01-03 15:14 ` Mark Cave-Ayland
2021-01-03 18:31 ` BALATON Zoltan via
2021-01-01 23:12 ` [RFC PATCH 3/5] hw/pci-host/bonito: Remap PCI "lo" regions when PCIMAP reg is modified Philippe Mathieu-Daudé
2021-01-01 23:19 ` Peter Maydell [this message]
2021-01-02 10:44 ` Philippe Mathieu-Daudé
2021-01-02 10:56 ` Philippe Mathieu-Daudé
2021-01-02 11:22 ` BALATON Zoltan via
2021-01-02 13:10 ` Peter Maydell
2021-01-02 14:12 ` BALATON Zoltan via
2021-01-01 23:12 ` [RFC PATCH 4/5] tests/acceptance: Test boot_linux_console for fuloong2e Philippe Mathieu-Daudé
2021-01-01 23:12 ` [RFC PATCH 5/5] tests/integration: Test Fuloong2E IDE drive, run userspace commands Philippe Mathieu-Daudé
2021-01-06 12:49 ` Willian Rampazzo
2021-01-01 23:56 ` [RFC PATCH 0/5] hw/mips: Fix Fuloong2E to boot Linux guest again BALATON Zoltan via
2021-01-03 14:27 ` Mark Cave-Ayland
2021-01-03 16:04 ` BALATON Zoltan via
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_Hi+4BAPL+0BhDgbsXtzDQjiCs0SAs44mKgUbcSE+XCg@mail.gmail.com \
--to=peter.maydell@linaro.org \
--cc=aleksandar.rikalo@syrmia.com \
--cc=atar4qemu@gmail.com \
--cc=aurelien@aurel32.net \
--cc=chenhuacai@kernel.org \
--cc=crosa@redhat.com \
--cc=f4bug@amsat.org \
--cc=jsnow@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wainersm@redhat.com \
/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).