Re: KVM developers conference call

[Philippe Mathieu-Daudé]

Cc'ing the list...

On Tue, 29 Nov 2022 at 14:02, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> Hi Juan,
>
> On 28/11/22 14:42, juan.quintela@gmail.com wrote:
>
> > KVM developers conference call
> > Tuesday 2022-11-29 ⋅ 15:00 – 16:00 (Central European Time - Madrid)
>
> > I think that Richard and Mark wanted to talk in tomorrow call (I forgot
> > the topic, sorry).
>
> We want to discuss around QEMU system emulation: single binary and
> heterogeneous vCPUs.
>
> Mark wanted to discuss dynamic machines and external devices. He can not
> make it today but we'd like to reserve the next slot for "External Devices".
>
> Today we'll cover multiple TCG frontends and possibly Problems of
> dynamic machines.
>
> I added the agenda on
> https://etherpad.opendev.org/p/qemu-emulation-bof%402022-11-29:
>
> --
>
> A) Single-binary multi-tcg frontends
>
> We'd like a single build of QEMU using several different TCG frontends.
>
> symbol collision -> dynamic libraries and force hidden visibility to all
> the symbols (static with prefix hack would be an OK stepping stone)
>
> Alessandro Di Federico and Anton Johansson almost have a PoC loading
> frontends as shared libraries (only user-mode so far).
> Updates: https://pad.rev.ng/i0N4yVkcQEWw24tqWsj6rA
>
> Use of current_cpu from generic code (Alex Bennée working on removing it)
>
> target specific macros (notes in https://pad.rev.ng/s/8cjdhsvtH)
>
> TARGET_LONG_BITS
> TARGET_PAGE_BITS_MIN / TARGET_PAGE_BITS
> TARGET_PHYS_ADDR_SPACE_BITS / TARGET_VIRT_ADDR_SPACE_BITS
> NB_MMU_MODES
>
> TARGET_BIG_ENDIAN
> Philippe Mathieu-Daudé working on removing this macro from hw/ devices,
> and from tcg backends using MemOp
>
>   B/ Dynamic Machine Models
>
> Instead of having static machines created using qom/qdev API in code,
> we'd like to create a dynamic machine at runtime.
> Basics:
>      - instanciate object, set properties, realize
>      - wire IRQs
>      - map memory regions
>
> GreenSocs proposed to use scripts to generate QMP commands in the
> pre-config machine state.
>
> Is the SysBus API limited? If so should we convert SysBusDevices do
> plain QDevs?
> Time to deprecate non-QOM/QDev devices? Keep them in legacy
> qemu-system-ARCH?
> Machine Reset issue: MachineState is QOM but not QDev (DeviceState)
> Is CPU reset() still different from any device reset()? If so, why? Can
> we unify?
> Peter Maydell started converting some devices from legacy reset to
> 3-phase reset
> Markus Armbruster mentioned the QAPI error path is not designed to
> handle qmp-device-add failures at runtime
>
> Previous work:
> Generalize the sysbus device machine allowance
> https://lore.kernel.org/qemu-devel/20220331115312.30018-1-damien.hedde@greensocs.com/
> This series transforms the TYPE_SYSBUS_DEVICE allowed list that exists
> in machine class model into a TYPE_DEVICE allowed list.
> qmp-send program to send raw qmp commands
> This script takes an input file containing raw qmp commands
> (concatenated json dicts) and send all commands one by one to a qmp
> server. When one command fails, it exits
> https://lore.kernel.org/qemu-devel/20220316095455.6473-1-damien.hedde@greensocs.com/
> Sysbus device generic QAPI plug support
> https://lore.kernel.org/qemu-devel/20220524134809.40732-1-damien.hedde@greensocs.com/
> QAPI support for device cold-plug
> https://lore.kernel.org/qemu-devel/20220519153402.41540-1-damien.hedde@greensocs.com/
> qemu-system-any: system emulation aiming to target any architecture
> https://lore.kernel.org/qemu-devel/20220215002658.60678-2-f4bug@amsat.org/
>
> C/ External devices (Mark Burton, 2022-12-13)
>
> User case: How to use a SMMUv3 implemented in SystemC?
>
> The "Multi-process QEMU" provides the RemoteMachineState/RemoteIommuElem
> interfaces which relies on a PCIBus. Currently related to vfio-user.
> Could it be useful if extended?
>
> We want to keep the memory management in QEMU. Can we directly expose
> the MemoryAPI? Can we avoid external device to take the IOLock?
>
> Mark Burton: What we should do is use async_safe_run_on_cpu to ensure
> the QEMU is quiescent before calling this interface. However that will
> require some rework. Not least because we will (typically) have a number
> of operations to perform, and they should (ideally) all be performed
> ‘atomically’. One option here MAY be to create a ‘transaction’ and then
> ‘execute’ that using async_safe….
>
> --
>
> Regards,
>
> Phil.