qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philippe.mathieu.daude@gmail.com>
To: Damien Hedde <damien.hedde@greensocs.com>,
	qemu-devel@nongnu.org, mark.burton@greensocs.com,
	edgari@xilinx.com
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Alistair Francis" <alistair.francis@wdc.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Eric Blake" <eblake@redhat.com>
Subject: Re: [PATCH v4 12/14] add sysbus-mmio-map qapi command
Date: Thu, 3 Mar 2022 15:59:06 +0100	[thread overview]
Message-ID: <a507b986-c8fb-3deb-5531-54fcbb35039e@gmail.com> (raw)
In-Reply-To: <20220223090706.4888-13-damien.hedde@greensocs.com>

On 23/2/22 10:07, Damien Hedde wrote:
> This command allows to map an mmio region of sysbus device onto
> the system memory. Its behavior mimics the sysbus_mmio_map()
> function apart from the automatic unmap (the C function unmaps
> the region if it is already mapped).
> For the qapi function we consider it is an error to try to map
> an already mapped function. If unmapping is required, it is
> probably better to add a sysbus-mmip-unmap command.

"sysbus-mmio-unmap" typo I presume.

> This command is still experimental (hence the 'unstable' feature),
> as it is related to the sysbus device creation through qapi commands.
> 
> This command is required to be able to dynamically build a machine
> from scratch as there is no qapi-way of doing a memory mapping.
> 
> Signed-off-by: Damien Hedde <damien.hedde@greensocs.com>
> ---
> Cc: Alistair Francis <alistair.francis@wdc.com>
> 
> v4:
>   + integrate priority parameter
>   + use 'unstable' feature flag instead of 'x-' prefix
>   + bump version to 7.0
>   + dropped Alistair's reviewed-by as a consequence
> ---
>   qapi/qdev.json   | 31 ++++++++++++++++++++++++++++++
>   hw/core/sysbus.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
>   2 files changed, 80 insertions(+)
> 
> diff --git a/qapi/qdev.json b/qapi/qdev.json
> index 2e2de41499..4830e87a90 100644
> --- a/qapi/qdev.json
> +++ b/qapi/qdev.json
> @@ -160,3 +160,34 @@
>   ##
>   { 'event': 'DEVICE_UNPLUG_GUEST_ERROR',
>     'data': { '*device': 'str', 'path': 'str' } }
> +
> +##
> +# @sysbus-mmio-map:
> +#
> +# Map a sysbus device mmio onto the main system bus.
> +#
> +# @device: the device's QOM path
> +#
> +# @mmio: The mmio number to be mapped (defaults to 0).
> +#
> +# @addr: The base address for the mapping.
> +#
> +# @priority: The priority of the mapping (defaults to 0).
> +#
> +# Features:
> +# @unstable: Command is meant to map sysbus devices
> +#            while in preconfig mode.
> +#
> +# Since: 7.0
> +#
> +# Returns: Nothing on success
> +#
> +##
> +
> +{ 'command': 'sysbus-mmio-map',
> +  'data': { 'device': 'str',
> +            '*mmio': 'uint8',
> +            'addr': 'uint64',
> +            '*priority': 'int32' },

I wonder if not providing the explicit parent container now could
be problematic later, and if we shouldn't start with a QOM MR path
(default to 'system_memory'). Anyway, sysbus are currently
restricted to system_memory so as you described, this mimics well
sysbus_mmio_map().

> +  'features': ['unstable'],
> +  'allow-preconfig' : true }
> diff --git a/hw/core/sysbus.c b/hw/core/sysbus.c
> index 05c1da3d31..df1f1f43a5 100644
> --- a/hw/core/sysbus.c
> +++ b/hw/core/sysbus.c
> @@ -23,6 +23,7 @@
>   #include "hw/sysbus.h"
>   #include "monitor/monitor.h"
>   #include "exec/address-spaces.h"
> +#include "qapi/qapi-commands-qdev.h"
>   
>   static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
>   static char *sysbus_get_fw_dev_path(DeviceState *dev);
> @@ -154,6 +155,54 @@ static void sysbus_mmio_map_common(SysBusDevice *dev, int n, hwaddr addr,
>       }
>   }
>   
> +void qmp_sysbus_mmio_map(const char *device,
> +                         bool has_mmio, uint8_t mmio,
> +                         uint64_t addr,
> +                         bool has_priority, int32_t priority,
> +                         Error **errp)
> +{
> +    Object *obj = object_resolve_path_type(device, TYPE_SYS_BUS_DEVICE, NULL);
> +    SysBusDevice *dev;
> +
> +    if (phase_get() != PHASE_MACHINE_INITIALIZED) {
> +        error_setg(errp, "The command is permitted only when "
> +                         "the machine is in initialized phase");

"command only permitted during the " #PHASE_MACHINE_INITIALIZED "phase"?

> +        return;
> +    }
> +
> +    if (obj == NULL) {
> +        error_setg(errp, "Device '%s' not found", device);
> +        return;
> +    }
> +    dev = SYS_BUS_DEVICE(obj);
> +
> +    if (!has_mmio) {
> +        mmio = 0;
> +    }
> +    if (!has_priority) {
> +        priority = 0;
> +    }
> +
> +    if (mmio >= dev->num_mmio) {
> +        error_setg(errp, "MMIO index '%u' does not exist in '%s'",
> +                   mmio, device);
> +        return;
> +    }
> +
> +    if (dev->mmio[mmio].addr != (hwaddr)-1) {
> +        error_setg(errp, "MMIO index '%u' is already mapped", mmio);
> +        return;
> +    }
> +
> +    if (!memory_region_try_add_subregion(get_system_memory(), addr,
> +                                         dev->mmio[mmio].memory, priority,
> +                                         errp)) {
> +        return;
> +    }
> +
> +    dev->mmio[mmio].addr = addr;
> +}

Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>


  reply	other threads:[~2022-03-03 15:01 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23  9:06 [PATCH v4 00/14] Initial support for machine creation via QMP Damien Hedde
2022-02-23  9:06 ` [PATCH v4 01/14] machine: add phase_get() and document phase_check()/advance() Damien Hedde
2022-03-03 15:01   ` Philippe Mathieu-Daudé
2022-02-23  9:06 ` [PATCH v4 02/14] machine&vl: introduce phase_until() to handle phase transitions Damien Hedde
2022-03-18 13:29   ` Damien Hedde
2022-02-23  9:06 ` [PATCH v4 03/14] vl: support machine-initialized target in phase_until() Damien Hedde
2022-03-03 15:03   ` Philippe Mathieu-Daudé
2022-02-23  9:06 ` [PATCH v4 04/14] qapi/device_add: compute is_hotplug flag Damien Hedde
2022-03-03 15:04   ` Philippe Mathieu-Daudé
2022-02-23  9:06 ` [PATCH v4 05/14] qapi/device_add: handle the rom_order_override when cold-plugging Damien Hedde
2022-05-24 20:08   ` Jim Shu
2022-02-23  9:06 ` [PATCH v4 06/14] qapi/device_add: Allow execution in machine initialized phase Damien Hedde
2022-02-23  9:06 ` [PATCH v4 07/14] none-machine: add the NoneMachineState structure Damien Hedde
2022-03-03 14:36   ` Philippe Mathieu-Daudé
2022-05-24 20:09   ` Jim Shu
2022-02-23  9:07 ` [PATCH v4 08/14] none-machine: add 'ram-addr' property Damien Hedde
2022-03-03 14:41   ` Philippe Mathieu-Daudé
2022-03-03 16:19     ` Damien Hedde
2022-05-24 20:09       ` Jim Shu
2022-02-23  9:07 ` [PATCH v4 09/14] none-machine: allow cold plugging sysbus devices Damien Hedde
2022-03-03 14:44   ` Philippe Mathieu-Daudé
2022-05-24 20:09     ` Jim Shu
2022-02-23  9:07 ` [PATCH v4 10/14] none-machine: allow several cpus Damien Hedde
2022-02-23  9:07 ` [PATCH v4 11/14] softmmu/memory: add memory_region_try_add_subregion function Damien Hedde
2022-02-23  9:12   ` Damien Hedde
2022-03-03 13:32     ` Philippe Mathieu-Daudé
2022-03-04 10:53       ` Damien Hedde
2022-05-24 20:09         ` Jim Shu
2022-02-23  9:07 ` [PATCH v4 12/14] add sysbus-mmio-map qapi command Damien Hedde
2022-03-03 14:59   ` Philippe Mathieu-Daudé [this message]
2022-03-04 10:42     ` Damien Hedde
2022-05-24 20:09   ` Jim Shu
2022-02-23  9:07 ` [PATCH v4 13/14] hw/mem/system-memory: add a memory sysbus device Damien Hedde
2022-02-23  9:44   ` Igor Mammedov
2022-02-23 10:19     ` Damien Hedde
2022-02-24  9:55       ` Igor Mammedov
2022-02-24 11:43         ` Damien Hedde
2022-02-25 11:38           ` Igor Mammedov
2022-02-25 15:31             ` Damien Hedde
2022-03-03 15:16               ` Philippe Mathieu-Daudé
2022-05-24 20:10   ` Jim Shu
2022-02-23  9:07 ` [PATCH v4 14/14] hw: set user_creatable on opentitan/sifive_e devices Damien Hedde
2022-03-04 12:58   ` Philippe Mathieu-Daudé
2022-05-24 20:10     ` Jim Shu
2022-03-03 10:58 ` [PATCH v4 00/14] Initial support for machine creation via QMP Damien Hedde
2022-05-24 19:54   ` Jim Shu

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=a507b986-c8fb-3deb-5531-54fcbb35039e@gmail.com \
    --to=philippe.mathieu.daude@gmail.com \
    --cc=alistair.francis@wdc.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=damien.hedde@greensocs.com \
    --cc=eblake@redhat.com \
    --cc=edgari@xilinx.com \
    --cc=eduardo@habkost.net \
    --cc=mark.burton@greensocs.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).