The BoF session will be in Lifey A (the big hall) this afternoon. I thought being able to sit around tables while we discuss things would make things a bit easier. We can share note taking on the etherpad:
https://etherpad.opendev.org/p/qemu-emulation-bof%40kvmforum2022 I'll run a HO at: https://meet.google.com/rac-axef-xvv On Wed, 31 Aug 2022 at 16:19, Alex Bennée <alex.ben...@linaro.org> wrote: > Hi, > > Given our slowly growing range of TCG emulations and the evident > interest in keeping up with modern processor architectures is it worth > having an emulation focused BoF at the up-coming KVM Forum? > > Some potential topics for discussion I could think of might include: > > * Progress towards heterogeneous vCPU emulation > > We've been making slow progress in removing assumptions from the > various front-ends about their global nature and adding accel:TCG > abstractions and support for the translator loop. We can already have > CPUs from the same architecture family in a model. What else do we need > to do so we can have those funky ARM+RiscV+Tricore heterogeneous > models? Is it library or something else? > > * External Device Models > > I know this is a contentious topic given the potential for GPL > end-runs. However there are also good arguments for enabling the > testing of open source designs without having forcing the > implementation of a separate C model to test software. For example if > we hypothetically modelled a Pi Pico would it make sense to model the > PIO in C if we could just compile the Verilog for it into a SystemC > model? Would a plethora of closed device models be the inevitable > consequence of such an approach? Would it matter if we just > concentrated on supporting useful open source solutions? > > * Dynamic Machine Models > > While we try and avoid modelling bespoke virtual HW in QEMU > (virt/goldfish not withstanding ;-) there is obviously a desire in the > EDA space to allow such experimentation. Is this something we can > provide so aspiring HW engineers can experiment with system > architectures without having to form QEMU and learn QOM. There have > been suggestions about consuming device trees or maybe translating to > QMP calls and adding support for wiring devices together. Given the > number of forks that exist is this something that could be better > supported upstream without degenerating into messy hacks? > > * A sense of time > > Currently we have the fairly limited support for -icount in QEMU. At > the same time we have no desire to start expanding frontends with > the details cost models required for a more realistic sense of time to > be presented. One suggestion is to expand the TCG plugin interface to > allow for the plugin to control time allowing as much or little logic > to be pushed there as we like and freeing up frontends from ever having > to consider it. > > Are any of these topics of interest? Are there any other emulation > topics people would like to discuss? > > -- > Alex Bennée > -- Alex Bennée KVM/QEMU Hacker for Linaro
