All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Shu <jim.shu@sifive.com>
To: Damien Hedde <damien.hedde@greensocs.com>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
	mark.burton@greensocs.com, edgari@xilinx.com,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Alistair Francis" <Alistair.Francis@wdc.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Bin Meng" <bin.meng@windriver.com>,
	"David Hildenbrand" <david@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Peter Xu" <peterx@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Yanan Wang" <wangyanan55@huawei.com>,
	"Igor Mammedov" <imammedo@redhat.com>,
	"Palmer Dabbelt" <palmer@dabbelt.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Ani Sinha" <ani@anisinha.ca>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Eric Blake" <eblake@redhat.com>
Subject: Re: [PATCH v4 00/14] Initial support for machine creation via QMP
Date: Wed, 25 May 2022 03:54:05 +0800	[thread overview]
Message-ID: <CALw707opo56xWwme5h4yNyM=1+RKEQOMTaYYSdGE-5x+4UHK5A@mail.gmail.com> (raw)
In-Reply-To: <94a413c6-9a4c-4068-a9e7-3979df440d9e@greensocs.com>

[-- Attachment #1: Type: text/plain, Size: 7887 bytes --]

Hi all,

Thanks for the work!

I'm from SiFive and we are very interested in this feature.
QMP/QAPI configurable QEMU machine is a useful feature in our use case.
With this feature, we can both model our versatile FPGA-based platforms
more easily and model a new platform without modification of source code.
It is helpful for early software development of SoC prototyping.
We think this feature is also helpful to the QEMU community.

Also, I have tested this patchset (v4) and newer v5 patchset [1] with
Damien's firmware [2] and it works correctly.

p.s. QMP option "-qmp socket,path=./qmpsocket,server" in v5 patchset
instruction may not work?
I use the option "-qmp unix:./qmpsocket,server" instead.

[1] [PATCH v5 0/6] QAPI support for device cold-plug
https://lore.kernel.org/qemu-devel/20220519153402.41540-1-damien.hedde@greensocs.com/

[2] Test firmware for patchset
v5: https://github.com/GreenSocs/qemu-qmp-machines/tree/master/arm-virt
v4:
https://github.com/GreenSocs/qemu-qmp-machines/tree/eba16dab8b587e624d65c5c302aeef424bece3a0

On Thu, Mar 3, 2022 at 7:02 PM Damien Hedde <damien.hedde@greensocs.com>
wrote:

> Ping !
>
> It would be good to have some feedback on 1st and 2nd part.
>
> Thanks,
> Damien
>
> On 2/23/22 10:06, Damien Hedde wrote:
> > Hi,
> >
> > This series adds initial support to build a machine using QMP/QAPI
> > commands. With this series, one can start from the 'none' machine,
> > create cpus, sysbus devices, memory map them and wire interrupts.
> >
> > Sorry for the huge cc list on this cover-letter. Apart from people
> > who attended the kvm call about this topic, I've cc'ed you only
> > according to MAINTAINERS file.
> >
> > The series is divided in 4 parts which are independent of each other,
> > but we need the 4 parts to be able to use this mechanism:
> > + Patches 1 to 6 allow to use the qapi command device_add to cold
> >    plug devices (like CLI -device do)
> > + Patches 7 to 10 modify the 'none' machine which serves as base
> >    machine.
> > + Patches 11 to 13 handle memory mapping and memory creation
> > + Patches 14 allows dynamic cold plug of opentitan/sifive_e machine
> >    to build some example. This last patch is based on a cleanup
> >    series: it probably works without it, but some config errors are
> >    not handled (see based-on below).
> >
> > Only patch 11 is reviewed-by.
> >
> > v4:
> > + cold plugging approach changed in order not to conflict with
> >    startup. I do not add additional command to handle this so that
> >    we can change everything easily.
> > + device_add in cold plug context is also now equivalent to -device
> >    CLI regarding -fw_cfg. I also added patches to modify the 'none'
> >    machine.
> > + reworked most of the none machine part
> > + updated the sybus-mmio-map command patch
> >
> > Note that there are still lot of limitations (for example if you try
> > to create more cpus than the _max_cpus_, tcg will abort()).
> > Basically all tasks done by machine init reading some parameters are
> > really tricky: for example, loading complex firmware. But we have to
> > start by something and all this is not accessible unless the user
> > asked for none machine and -preconfig.
> >
> > I can maintain the code introduced here. I'm not sure what's the
> > process. Is there something else to do than propose a patch to
> > MAINTAINERS ?
> > If there is a global agreement on moving on with these feature, it
> > would be great to have a login on qemu wiki so I can document
> > limitations and the work being done to solve them.
> >
> > A simple test can be done with the following scenario which build
> > a machine subset of the opentitan.
> >
> > $ cat commands.qmp
> > // RAM 0x10000000
> > device_add driver=sysbus-memory id=ram size=0x4000 readonly=false
> > sysbus-mmio-map device=ram addr=268435456
> > // CPUS
> > device_add driver=riscv.hart_array id=cpus
> cpu-type=lowrisc-ibex-riscv-cpu num-harts=1 resetvec=0x8080
> > // ROM 0x00008000
> > device_add driver=sysbus-memory id=rom size=0x4000 readonly=true
> > sysbus-mmio-map device=rom addr=32768
> > // PLIC 0x48000000
> > device_add driver=riscv.sifive.plic id=plic hart-config=M hartid-base=0
> num-sources=180 num-priorities=3 priority-base=0x0 pending-base=0x1000
> enable-base=0x2000 enable-stride=32 context-base=0x200000 context-stride=8
> aperture-size=0x4005000
> > sysbus-mmio-map device=plic addr=1207959552
> > qom-set path=plic property=unnamed-gpio-out[1]
> value=cpus/harts[0]/unnamed-gpio-in[11]
> > // UART 0x40000000
> > device_add driver=ibex-uart id=uart chardev=serial0
> > sysbus-mmio-map device=uart addr=1073741824
> > qom-set path=uart property=sysbus-irq[1] value=plic/unnamed-gpio-in[2]
> > // FIRMWARE
> > device_add driver=loader cpu-num=0 file=/path/to/firmware.elf
> > x-exit-preconfig
> >
> > $ qemu-system-riscv32 -display none -M none -preconfig -serial stdio
> -qmp unix:/tmp/qmp-sock,server
> >
> > In another terminal, you'll need to send the commands with, for example:
> > $ grep -v '^//' commands.qmp | qmp-shell /tmp/qmp-sock -v
> >
> > It is the same as running
> > $ qemu-system-riscv32 -display none -M opentitan -serial stdio -kernel
> path/to/firmware.elf
> >
> > If you need a firmware, you can pick this one
> >
> https://github.com/GreenSocs/qemu-qmp-machines/blob/master/opentitan-echo.elf
> > This firmware is just a small interrupt-based bare-metal program
> > echoing back whatever is sent in the uart.
> >
> > This repo contains also sifive_e machine example.
> >
> > Based-on: <20220218164646.132112-1-damien.hedde@greensocs.com>
> > "RiscV cleanups for user-related life cycles"
> >
> > Thanks for your comments,
> > --
> > Damien
> >
> > Damien Hedde (13):
> >    machine: add phase_get() and document phase_check()/advance()
> >    machine&vl: introduce phase_until() to handle phase transitions
> >    vl: support machine-initialized target in phase_until()
> >    qapi/device_add: compute is_hotplug flag
> >    qapi/device_add: handle the rom_order_override when cold-plugging
> >    none-machine: add the NoneMachineState structure
> >    none-machine: add 'ram-addr' property
> >    none-machine: allow cold plugging sysbus devices
> >    none-machine: allow several cpus
> >    softmmu/memory: add memory_region_try_add_subregion function
> >    add sysbus-mmio-map qapi command
> >    hw/mem/system-memory: add a memory sysbus device
> >    hw: set user_creatable on opentitan/sifive_e devices
> >
> > Mirela Grujic (1):
> >    qapi/device_add: Allow execution in machine initialized phase
> >
> >   qapi/qdev.json                 | 34 +++++++++++-
> >   include/exec/memory.h          | 22 ++++++++
> >   include/hw/mem/sysbus-memory.h | 28 ++++++++++
> >   include/hw/qdev-core.h         | 33 ++++++++++++
> >   hw/char/ibex_uart.c            |  1 +
> >   hw/char/sifive_uart.c          |  1 +
> >   hw/core/null-machine.c         | 68 ++++++++++++++++++++++--
> >   hw/core/qdev.c                 |  5 ++
> >   hw/core/sysbus.c               | 49 ++++++++++++++++++
> >   hw/gpio/sifive_gpio.c          |  1 +
> >   hw/intc/riscv_aclint.c         |  2 +
> >   hw/intc/sifive_plic.c          |  1 +
> >   hw/mem/sysbus-memory.c         | 80 +++++++++++++++++++++++++++++
> >   hw/misc/sifive_e_prci.c        |  8 +++
> >   hw/misc/unimp.c                |  1 +
> >   hw/riscv/riscv_hart.c          |  1 +
> >   hw/timer/ibex_timer.c          |  1 +
> >   monitor/misc.c                 |  2 +-
> >   softmmu/memory.c               | 23 ++++++---
> >   softmmu/qdev-monitor.c         | 20 +++++++-
> >   softmmu/vl.c                   | 94 ++++++++++++++++++++++++++--------
> >   hmp-commands.hx                |  1 +
> >   hw/mem/meson.build             |  2 +
> >   23 files changed, 439 insertions(+), 39 deletions(-)
> >   create mode 100644 include/hw/mem/sysbus-memory.h
> >   create mode 100644 hw/mem/sysbus-memory.c
> >
>
>

[-- Attachment #2: Type: text/html, Size: 10027 bytes --]

      reply	other threads:[~2022-05-24 19:56 UTC|newest]

Thread overview: 48+ 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é
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-02-23  9:07   ` Damien Hedde
2022-03-04 12:58   ` Philippe Mathieu-Daudé
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 [this message]

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='CALw707opo56xWwme5h4yNyM=1+RKEQOMTaYYSdGE-5x+4UHK5A@mail.gmail.com' \
    --to=jim.shu@sifive.com \
    --cc=Alistair.Francis@wdc.com \
    --cc=ani@anisinha.ca \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=bin.meng@windriver.com \
    --cc=damien.hedde@greensocs.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=edgari@xilinx.com \
    --cc=eduardo@habkost.net \
    --cc=f4bug@amsat.org \
    --cc=imammedo@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=mark.burton@greensocs.com \
    --cc=mst@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wangyanan55@huawei.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 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.