On Fri, 4 Sept 2026 at 11:15, Philippe Mathieu-Daudé <[email protected]> wrote: > > On 4/9/26 09:57, Bin Meng wrote: > > Hi Philippe, > > > > On Fri, Sep 4, 2026 at 12:56 AM Philippe Mathieu-Daudé > > <[email protected]> wrote: > >> > >> On 3/9/26 13:24, Bin Meng wrote: > >>> Add the base topology for the Phytium Pi board built around the > >>> E2000Q SoC, with two FTC310 and two FTC664 CPUs, RAM, GICv3/ITS, > >>> and PL011 UARTs. > >>> > >>> Describe the CPUs as three non-uniform clusters matching the vendor > >>> Linux device tree. Preserve the board CPU slot order so firmware > >>> MPIDR 0x200 maps to QEMU CPU index 2. > >>> > >>> Signed-off-by: Bin Meng <[email protected]> > >>> --- > >>> > >>> hw/arm/Kconfig | 8 + > >>> hw/arm/meson.build | 1 + > >>> hw/arm/phytium_e2000.c | 406 +++++++++++++++++++++++++++++++++++++++++ > >>> 3 files changed, 415 insertions(+) > >>> create mode 100644 hw/arm/phytium_e2000.c > > > >>> +static void phytium_pi_init(MachineState *ms) > >>> +{ > >>> + PhytiumE2000State *s = PHYTIUM_PI(ms); > >>> + int i; > >>> + > >>> + if (kvm_enabled()) { > >>> + error_report("phytium-pi: KVM is not supported"); > >> > >> Why is it relevant? > > > > This is because the machine relies on heterogeneous named > > FTC310/FTC664 TCG CPU models and Arm KVM generally requires the host > > CPU model. KVM is rejected explicitly instead of failing later during > > vCPU initialization. > > Hmm OK. Cc'ing Pierrick to add to our list of things to think about for > heterogenous emulation. I'd rather have this handled in a generic way, > not per-machine. Hopefully TypeInfo::is_available will be sufficient > to not expose the machine if KVM is not available. No need to think > about that now.
Explicitly checking for KVM is something we do already in the sbsa-ref board. But I think you should only need to do that if your board type accepts arbitrary CPU types rather than hardwiring the CPU type. -- PMM
