On Mon, Apr 11, 2022 at 07:10:06PM -0700, Atish Patra wrote: > > The RISC-V virt machine has helped RISC-V software eco system to evolve at a > rapid pace even in absense of the real hardware. It is definitely commendable. > However, the number of devices & commandline options keeps growing as a result > of that as well. That adds flexibility but will also become bit difficult > to manage in the future as more extension support will be added. As it is the > most commonly used qemu machine, it needs to support all kinds of device and > interrupts as well. Moreover, virt machine has limitations on the maximum > number of harts it can support because of all the MMIO devices it has to > support. > > The RISC-V IMSIC specification allows to develop machines completely relying > on MSI and don't care about the wired interrupts at all. It just requires > all the devices to be present behind a PCI bus or present themselves as > platform > MSI device. The former is a more common scenario in x86 world where most > of the devices are behind PCI bus. As there is very limited MMIO device > support, it can also scale to very large number of harts. > > That's why, this patch series introduces a minimalistic yet very extensible > forward looking machine called as "RISC-V Mini Computer" or "minic". The > idea is to build PC or server like systems with this machine. The machine can > work with or without virtio framework. The current implementation only > supports RV64. I am not sure if building a RV32 machine would be of interest > for such machines. The only mmio device it requires is clint to emulate > the mtimecmp.
I would ask what you see as the long term future usage for 'virt' vs 'minic' machine types ? Would you expect all existing users of 'virt' to ultimately switch to 'minic', or are there distinct non-overlapping use cases for 'virt' vs 'minic' such that both end up widely used ? Is 'minic' intended to be able to mimic real physical hardware at all, or is it still intended as a purely virtual machine, like a 'virt-ng' ? Essentially 'virt' was positioned as the standard machine to use if you want to run a virtual machine, without any particular match to physical hardware. It feels like 'minic' is creating a second machine type to fill the same purpose, so how do users decide which to use ? > "Naming is hard". I am not too attached with the name "minic". > I just chose least bad one out of the few on my mind :). I am definitely > open to any other name as well. > > The other alternative to provide MSI only option to aia in the > existing virt machine to build MSI only machines. This is certainly doable > and here is the patch that supports that kind of setup. > > https://github.com/atishp04/qemu/tree/virt_imsic_only > > However, it even complicates the virt machine even further with additional > command line option, branches in the code. I believe virt machine will become > very complex if we continue this path. I am interested to learn what everyone > else think. > > It is needless to say that the current version of minic machine > is inspired from virt machine and tries to reuse as much as code possible. > The first patch in this series adds MSI support for serial-pci device so > console can work on such a machine. The 2nd patch moves some common functions > between minic and the virt machine to a helper file. The PATCH3 actually > implements the new minic machine. > > I have not added the fw-cfg/flash support. We probably should add those > but I just wanted to start small and get the feedback first. > This is a work in progress and have few more TODO items before becoming the > new world order :) > > 1. OpenSBI doesn't have PCI support. Thus, no console support for OpenSBI > for now. > 2. The ns16550 driver in OpenSBI also need to support MSI/MSI-X. > 3. Add MSI-X support for serial-pci device. > > This series can boot Linux distros with the minic machine with or without > virtio > devices with out-of-tree Linux kernel patches[1]. Here is an example > commandline > > Without virtio devices (nvme, serial-pci & e1000e): > ===================================================== > /scratch/workspace/qemu/build/qemu-system-riscv64 -cpu rv64 -M minic -m 1G > -smp 4 -nographic -nodefaults \ > -display none -bios > /scratch/workspace/opensbi/build/platform/generic/firmware/fw_dynamic.elf \ > -kernel /scratch/workspace/linux/arch/riscv/boot/Image \ > -chardev stdio,mux=on,signal=off,id=charconsole0 \ > -mon chardev=charconsole0,mode=readline \ > -device pci-serial,msi=true,chardev=charconsole0 \ > -drive > id=disk3,file=/scratch/workspace/rootfs_images//fedora/Fedora-Developer-Rawhide-20211110.n.0-sda.raw,format=raw,if=none,id=drive-system-disk,cache=none,format=raw > \ > -device nvme,serial=deadbeef,drive=disk3 \ > -netdev user,id=usernet,hostfwd=tcp::10000-:22 -device > e1000e,netdev=usernet,bus=pcie.0 \ > -append 'root=/dev/nvme0n1p2 rw loglevel=8 memblock=debug console=ttyS0 > earlycon' -d in_asm -D log.txt -s > > With virtio devices (virtio-scsi-pci, serial-pci & virtio-net-pci) > ================================================================== > /scratch/workspace/qemu/build/qemu-system-riscv64 -cpu rv64 -M minic -m 1G > -smp 4 -nographic -nodefaults \ > -display none -bios > /scratch/workspace/opensbi/build/platform/generic/firmware/fw_dynamic.elf \ > -kernel /scratch/workspace/linux/arch/riscv/boot/Image \ > -chardev stdio,mux=on,signal=off,id=charconsole0 \ > -mon chardev=charconsole0,mode=readline \ > -device pci-serial,msi=true,chardev=charconsole0 \ > -drive > file=/scratch/workspace/rootfs_images//fedora/Fedora-Developer-Rawhide-20211110.n.0-sda.raw,format=raw,if=none,id=drive-system-disk,cache=none > \ > -device virtio-scsi-pci,id=scsi0 -device > scsi-hd,bus=scsi0.0,drive=drive-system-disk,id=system-disk,bootindex=1 \ > -netdev user,id=n1,hostfwd=tcp::10000-:22 -device virtio-net-pci,netdev=n1 \ > -append 'root=/dev/sda2 rw loglevel=8 memblock=debug console=ttyS0 earlycon' > > The objective of this series is to engage the community to solve this problem. > Please suggest if you have another alternatve solution. > > [1] https://github.com/atishp04/linux/tree/msi_only_console > > Atish Patra (3): > serial: Enable MSI capablity and option > hw/riscv: virt: Move common functions to a separate helper file > hw/riscv: Create a new qemu machine for RISC-V > > configs/devices/riscv64-softmmu/default.mak | 1 + > hw/char/serial-pci.c | 36 +- > hw/riscv/Kconfig | 11 + > hw/riscv/machine_helper.c | 417 +++++++++++++++++++ > hw/riscv/meson.build | 2 + > hw/riscv/minic.c | 438 ++++++++++++++++++++ > hw/riscv/virt.c | 403 ++---------------- > include/hw/riscv/machine_helper.h | 87 ++++ > include/hw/riscv/minic.h | 65 +++ > include/hw/riscv/virt.h | 13 - > 10 files changed, 1090 insertions(+), 383 deletions(-) > create mode 100644 hw/riscv/machine_helper.c > create mode 100644 hw/riscv/minic.c > create mode 100644 include/hw/riscv/machine_helper.h > create mode 100644 include/hw/riscv/minic.h > > -- > 2.25.1 > > With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|