* Re: [PATCH 01/14] sysbus: Remove sysbus_mmio_unmap
[not found] ` <20220623095825.2038562-2-pdel@fb.com>
@ 2022-06-23 12:09 ` Peter Maydell
2022-06-23 15:09 ` Cédric Le Goater
1 sibling, 0 replies; 8+ messages in thread
From: Peter Maydell @ 2022-06-23 12:09 UTC (permalink / raw)
To: Peter Delevoryas
Cc: clg, andrew, joel, pbonzini, berrange, eduardo, marcel.apfelbaum,
richard.henderson, f4bug, ani, qemu-devel, qemu-arm, kvm
On Thu, 23 Jun 2022 at 11:59, Peter Delevoryas <pdel@fb.com> wrote:
>
> Cedric removed usage of this function in a previous commit.
>
> Fixes: 981b1c6266c6 ("spapr/xive: rework the mapping the KVM memory regions")
> Signed-off-by: Peter Delevoryas <pdel@fb.com>
We only added this function for the XIVE in the first place
so I guess it makes sense to remove it now it's unused.
(People doing complicated stuff that needs to unmap MRs
should probably not be using sysbus_mmio_map()/unmap()
anyway...)
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
-- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 06/14] aspeed: Add system-memory QOM link to SoC
[not found] ` <20220623095825.2038562-7-pdel@fb.com>
@ 2022-06-23 12:30 ` Peter Maydell
2022-06-23 18:30 ` Peter Delevoryas
0 siblings, 1 reply; 8+ messages in thread
From: Peter Maydell @ 2022-06-23 12:30 UTC (permalink / raw)
To: Peter Delevoryas
Cc: clg, andrew, joel, pbonzini, berrange, eduardo, marcel.apfelbaum,
richard.henderson, f4bug, ani, qemu-devel, qemu-arm, kvm
On Thu, 23 Jun 2022 at 12:31, Peter Delevoryas <pdel@fb.com> wrote:
>
> Right now it's just defined as the regular global system memory. If we
> migrate all the SoC code to use this property instead of directly calling
> get_system_memory(), then we can restrict the memory container for the SoC,
> which will be useful for multi-SoC machines.
>
> Signed-off-by: Peter Delevoryas <pdel@fb.com>
> static Property aspeed_soc_properties[] = {
> + DEFINE_PROP_LINK("system-memory", AspeedSoCState, system_memory,
> + TYPE_MEMORY_REGION, MemoryRegion *),
To the extent that we have a convention, we tend to call this
property on an SoC or CPU "memory", I think. (Better suggestions
welcome...)
-- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 11/14] aspeed: Switch to create_unimplemented_device_in
[not found] ` <20220623095825.2038562-12-pdel@fb.com>
@ 2022-06-23 12:56 ` Peter Maydell
2022-06-23 18:32 ` Peter Delevoryas
0 siblings, 1 reply; 8+ messages in thread
From: Peter Maydell @ 2022-06-23 12:56 UTC (permalink / raw)
To: Peter Delevoryas
Cc: clg, andrew, joel, pbonzini, berrange, eduardo, marcel.apfelbaum,
richard.henderson, f4bug, ani, qemu-devel, qemu-arm, kvm
On Thu, 23 Jun 2022 at 13:04, Peter Delevoryas <pdel@fb.com> wrote:
>
> Signed-off-by: Peter Delevoryas <pdel@fb.com>
> ---
> hw/arm/aspeed_ast10x0.c | 10 ++++------
> hw/arm/aspeed_ast2600.c | 19 ++++++++++---------
> hw/arm/aspeed_soc.c | 9 +++++----
> 3 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/hw/arm/aspeed_ast10x0.c b/hw/arm/aspeed_ast10x0.c
> index d259d30fc0..4e6688cc68 100644
> --- a/hw/arm/aspeed_ast10x0.c
> +++ b/hw/arm/aspeed_ast10x0.c
> @@ -158,12 +158,10 @@ static void aspeed_soc_ast1030_realize(DeviceState *dev_soc, Error **errp)
> }
>
> /* General I/O memory space to catch all unimplemented device */
> - create_unimplemented_device("aspeed.sbc",
> - sc->memmap[ASPEED_DEV_SBC],
> - 0x40000);
> - create_unimplemented_device("aspeed.io",
> - sc->memmap[ASPEED_DEV_IOMEM],
> - ASPEED_SOC_IOMEM_SIZE);
> + create_unimplemented_device_in("aspeed.sbc", sc->memmap[ASPEED_DEV_SBC],
> + 0x40000, s->system_memory);
> + create_unimplemented_device_in("aspeed.io", sc->memmap[ASPEED_DEV_IOMEM],
> + ASPEED_SOC_IOMEM_SIZE, s->system_memory);
This is SoC code, so it should probably be handling its unimplemented
devices by creating and mapping TYPE_UNIMPLEMENTED_DEVICE child
objects directly, the same way it handles all its other child devices.
thanks
-- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 01/14] sysbus: Remove sysbus_mmio_unmap
[not found] ` <20220623095825.2038562-2-pdel@fb.com>
2022-06-23 12:09 ` [PATCH 01/14] sysbus: Remove sysbus_mmio_unmap Peter Maydell
@ 2022-06-23 15:09 ` Cédric Le Goater
1 sibling, 0 replies; 8+ messages in thread
From: Cédric Le Goater @ 2022-06-23 15:09 UTC (permalink / raw)
To: Peter Delevoryas
Cc: peter.maydell, andrew, joel, pbonzini, berrange, eduardo,
i.mitsyanko@gmail.com.mst, marcel.apfelbaum, richard.henderson,
f4bug, ani, qemu-devel, qemu-arm, kvm
On 6/23/22 11:58, Peter Delevoryas wrote:
> Cedric removed usage of this function in a previous commit.
>
> Fixes: 981b1c6266c6 ("spapr/xive: rework the mapping the KVM memory regions")
> Signed-off-by: Peter Delevoryas <pdel@fb.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Thanks,
C.
> ---
> hw/core/sysbus.c | 10 ----------
> include/hw/sysbus.h | 1 -
> 2 files changed, 11 deletions(-)
>
> diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
> index 05c1da3d31..637e18f247 100644
> --- a/hw/core/sysbus.c
> +++ b/hw/core/sysbus.c
> @@ -154,16 +154,6 @@ static void sysbus_mmio_map_common(SysBusDevice *dev, int n, hwaddr addr,
> }
> }
>
> -void sysbus_mmio_unmap(SysBusDevice *dev, int n)
> -{
> - assert(n >= 0 && n < dev->num_mmio);
> -
> - if (dev->mmio[n].addr != (hwaddr)-1) {
> - memory_region_del_subregion(get_system_memory(), dev->mmio[n].memory);
> - dev->mmio[n].addr = (hwaddr)-1;
> - }
> -}
> -
> void sysbus_mmio_map(SysBusDevice *dev, int n, hwaddr addr)
> {
> sysbus_mmio_map_common(dev, n, addr, false, 0);
> diff --git a/include/hw/sysbus.h b/include/hw/sysbus.h
> index 3564b7b6a2..153ef20695 100644
> --- a/include/hw/sysbus.h
> +++ b/include/hw/sysbus.h
> @@ -82,7 +82,6 @@ qemu_irq sysbus_get_connected_irq(SysBusDevice *dev, int n);
> void sysbus_mmio_map(SysBusDevice *dev, int n, hwaddr addr);
> void sysbus_mmio_map_overlap(SysBusDevice *dev, int n, hwaddr addr,
> int priority);
> -void sysbus_mmio_unmap(SysBusDevice *dev, int n);
> void sysbus_add_io(SysBusDevice *dev, hwaddr addr,
> MemoryRegion *mem);
> MemoryRegion *sysbus_address_space(SysBusDevice *dev);
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 06/14] aspeed: Add system-memory QOM link to SoC
2022-06-23 12:30 ` [PATCH 06/14] aspeed: Add system-memory QOM link to SoC Peter Maydell
@ 2022-06-23 18:30 ` Peter Delevoryas
0 siblings, 0 replies; 8+ messages in thread
From: Peter Delevoryas @ 2022-06-23 18:30 UTC (permalink / raw)
Cc: Peter Delevoryas, Cédric Le Goater, Andrew Jeffery,
Joel Stanley, pbonzini, berrange, eduardo, marcel.apfelbaum,
richard.henderson, Philippe Mathieu-Daudé,
ani, Cameron Esfahani via, qemu-arm, kvm, Peter Maydell
> On Jun 23, 2022, at 5:30 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 23 Jun 2022 at 12:31, Peter Delevoryas <pdel@fb.com> wrote:
>>
>> Right now it's just defined as the regular global system memory. If we
>> migrate all the SoC code to use this property instead of directly calling
>> get_system_memory(), then we can restrict the memory container for the SoC,
>> which will be useful for multi-SoC machines.
>>
>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>
>> static Property aspeed_soc_properties[] = {
>> + DEFINE_PROP_LINK("system-memory", AspeedSoCState, system_memory,
>> + TYPE_MEMORY_REGION, MemoryRegion *),
>
> To the extent that we have a convention, we tend to call this
> property on an SoC or CPU "memory", I think. (Better suggestions
> welcome...)
Oh oops, yes, in hindsight that is very obvious. I’ll change
this from “system-memory” to “memory”.
>
> -- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 06/14] aspeed: Add system-memory QOM link to SoC
@ 2022-06-23 18:30 ` Peter Delevoryas
0 siblings, 0 replies; 8+ messages in thread
From: Peter Delevoryas @ 2022-06-23 18:30 UTC (permalink / raw)
Cc: Peter Delevoryas, Cédric Le Goater, Andrew Jeffery,
Joel Stanley, pbonzini, berrange, eduardo, marcel.apfelbaum,
richard.henderson, Philippe Mathieu-Daudé,
ani, Cameron Esfahani via, qemu-arm, kvm, Peter Maydell
> On Jun 23, 2022, at 5:30 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 23 Jun 2022 at 12:31, Peter Delevoryas <pdel@fb.com> wrote:
>>
>> Right now it's just defined as the regular global system memory. If we
>> migrate all the SoC code to use this property instead of directly calling
>> get_system_memory(), then we can restrict the memory container for the SoC,
>> which will be useful for multi-SoC machines.
>>
>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>
>> static Property aspeed_soc_properties[] = {
>> + DEFINE_PROP_LINK("system-memory", AspeedSoCState, system_memory,
>> + TYPE_MEMORY_REGION, MemoryRegion *),
>
> To the extent that we have a convention, we tend to call this
> property on an SoC or CPU "memory", I think. (Better suggestions
> welcome...)
Oh oops, yes, in hindsight that is very obvious. I’ll change
this from “system-memory” to “memory”.
>
> -- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 11/14] aspeed: Switch to create_unimplemented_device_in
2022-06-23 12:56 ` [PATCH 11/14] aspeed: Switch to create_unimplemented_device_in Peter Maydell
@ 2022-06-23 18:32 ` Peter Delevoryas
0 siblings, 0 replies; 8+ messages in thread
From: Peter Delevoryas @ 2022-06-23 18:32 UTC (permalink / raw)
Cc: Peter Delevoryas, Cédric Le Goater, Andrew Jeffery,
Joel Stanley, pbonzini, berrange, eduardo, marcel.apfelbaum,
richard.henderson, Philippe Mathieu-Daudé,
ani, Cameron Esfahani via, qemu-arm, kvm, Peter Maydell
> On Jun 23, 2022, at 5:56 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 23 Jun 2022 at 13:04, Peter Delevoryas <pdel@fb.com> wrote:
>>
>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>> ---
>> hw/arm/aspeed_ast10x0.c | 10 ++++------
>> hw/arm/aspeed_ast2600.c | 19 ++++++++++---------
>> hw/arm/aspeed_soc.c | 9 +++++----
>> 3 files changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/hw/arm/aspeed_ast10x0.c b/hw/arm/aspeed_ast10x0.c
>> index d259d30fc0..4e6688cc68 100644
>> --- a/hw/arm/aspeed_ast10x0.c
>> +++ b/hw/arm/aspeed_ast10x0.c
>> @@ -158,12 +158,10 @@ static void aspeed_soc_ast1030_realize(DeviceState *dev_soc, Error **errp)
>> }
>>
>> /* General I/O memory space to catch all unimplemented device */
>> - create_unimplemented_device("aspeed.sbc",
>> - sc->memmap[ASPEED_DEV_SBC],
>> - 0x40000);
>> - create_unimplemented_device("aspeed.io",
>> - sc->memmap[ASPEED_DEV_IOMEM],
>> - ASPEED_SOC_IOMEM_SIZE);
>> + create_unimplemented_device_in("aspeed.sbc", sc->memmap[ASPEED_DEV_SBC],
>> + 0x40000, s->system_memory);
>> + create_unimplemented_device_in("aspeed.io", sc->memmap[ASPEED_DEV_IOMEM],
>> + ASPEED_SOC_IOMEM_SIZE, s->system_memory);
>
> This is SoC code, so it should probably be handling its unimplemented
> devices by creating and mapping TYPE_UNIMPLEMENTED_DEVICE child
> objects directly, the same way it handles all its other child devices.
Ah, right. I’ll include a patch to create the device as a regular
child object, and after that it will probably make more sense to
remove “create_unimplemented_device_in” too and just do that
memory mapping directly. Especially since I’m going to remove
the “sysbus_mmio_map_overlap_in” function too.
>
> thanks
> -- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 11/14] aspeed: Switch to create_unimplemented_device_in
@ 2022-06-23 18:32 ` Peter Delevoryas
0 siblings, 0 replies; 8+ messages in thread
From: Peter Delevoryas @ 2022-06-23 18:32 UTC (permalink / raw)
Cc: Peter Delevoryas, Cédric Le Goater, Andrew Jeffery,
Joel Stanley, pbonzini, berrange, eduardo, marcel.apfelbaum,
richard.henderson, Philippe Mathieu-Daudé,
ani, Cameron Esfahani via, qemu-arm, kvm, Peter Maydell
> On Jun 23, 2022, at 5:56 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 23 Jun 2022 at 13:04, Peter Delevoryas <pdel@fb.com> wrote:
>>
>> Signed-off-by: Peter Delevoryas <pdel@fb.com>
>> ---
>> hw/arm/aspeed_ast10x0.c | 10 ++++------
>> hw/arm/aspeed_ast2600.c | 19 ++++++++++---------
>> hw/arm/aspeed_soc.c | 9 +++++----
>> 3 files changed, 19 insertions(+), 19 deletions(-)
>>
>> diff --git a/hw/arm/aspeed_ast10x0.c b/hw/arm/aspeed_ast10x0.c
>> index d259d30fc0..4e6688cc68 100644
>> --- a/hw/arm/aspeed_ast10x0.c
>> +++ b/hw/arm/aspeed_ast10x0.c
>> @@ -158,12 +158,10 @@ static void aspeed_soc_ast1030_realize(DeviceState *dev_soc, Error **errp)
>> }
>>
>> /* General I/O memory space to catch all unimplemented device */
>> - create_unimplemented_device("aspeed.sbc",
>> - sc->memmap[ASPEED_DEV_SBC],
>> - 0x40000);
>> - create_unimplemented_device("aspeed.io",
>> - sc->memmap[ASPEED_DEV_IOMEM],
>> - ASPEED_SOC_IOMEM_SIZE);
>> + create_unimplemented_device_in("aspeed.sbc", sc->memmap[ASPEED_DEV_SBC],
>> + 0x40000, s->system_memory);
>> + create_unimplemented_device_in("aspeed.io", sc->memmap[ASPEED_DEV_IOMEM],
>> + ASPEED_SOC_IOMEM_SIZE, s->system_memory);
>
> This is SoC code, so it should probably be handling its unimplemented
> devices by creating and mapping TYPE_UNIMPLEMENTED_DEVICE child
> objects directly, the same way it handles all its other child devices.
Ah, right. I’ll include a patch to create the device as a regular
child object, and after that it will probably make more sense to
remove “create_unimplemented_device_in” too and just do that
memory mapping directly. Especially since I’m going to remove
the “sysbus_mmio_map_overlap_in” function too.
>
> thanks
> -- PMM
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-06-23 19:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20220623095825.2038562-1-pdel@fb.com>
[not found] ` <20220623095825.2038562-7-pdel@fb.com>
2022-06-23 12:30 ` [PATCH 06/14] aspeed: Add system-memory QOM link to SoC Peter Maydell
2022-06-23 18:30 ` Peter Delevoryas
2022-06-23 18:30 ` Peter Delevoryas
[not found] ` <20220623095825.2038562-12-pdel@fb.com>
2022-06-23 12:56 ` [PATCH 11/14] aspeed: Switch to create_unimplemented_device_in Peter Maydell
2022-06-23 18:32 ` Peter Delevoryas
2022-06-23 18:32 ` Peter Delevoryas
[not found] ` <20220623095825.2038562-2-pdel@fb.com>
2022-06-23 12:09 ` [PATCH 01/14] sysbus: Remove sysbus_mmio_unmap Peter Maydell
2022-06-23 15:09 ` Cédric Le Goater
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.