On Fri, Sep 04, 2026 at 01:24:35PM +0200, Philippe Mathieu-Daudé wrote: > On 4/9/26 12:47, Peter Maydell wrote: > > On Fri, 4 Sept 2026 at 11:36, Daniel P. Berrangé <[email protected]> > > wrote: > > > > > > On Fri, Sep 04, 2026 at 11:28:35AM +0100, Peter Maydell wrote: > > > > On Fri, 4 Sept 2026 at 11:25, Daniel P. Berrangé <[email protected]> > > > > wrote: > > > > > We need to use QAPI MachineInfo / MachineClass to report to mgmt apps > > > > > whether a machine is capable of using hardware acceleration or not in > > > > > response to "query-machines". > > > > > > > > > > Currently if a target supports HW accel, then apps assume that all > > > > > machines in that target can use acceleration. This was a convenient > > > > > short cut assumption, but this new machine suggests we can no make > > > > > do with that assumption, and need to explicitly report it per-machine. > > > > > > > > That assumption has never been true for Arm; this new machine > > > > type is no different to any of our existing boards in that regard. > > > > Support for KVM etc is only present for the 'virt' machine type and > > > > one or two others. Most of the rest don't work with KVM because they > > > > create a specific CPU type (not 'host' or 'max') and that won't work > > > > with KVM, or (as with sbsa-ref) because they want EL3 support and > > > > KVM doesn't provide that. > > > > > > Oh, then the problem is already way worse than I realized which > > > really makes we think we should consider exposing whether > > > machines can use HW acceleration or not. > > > > It also depends on the options to the machine, so for instance > > this should always work with any of the hw accelerators: > > qemu-system-aarch64 -M virt -cpu host > > but this wants nested virt, so only works with a hw accel > > that supports that and a host kernel that has the KVM side support: > > qemu-system-aarch64 -M virt,virtualization=on -cpu host > > and this wants EL3, which won't work in any hw accelerator > > qemu-system-aarch64 -M virt,secure=on -cpu host > > > > Similarly the interrupt controller choice matters, so this: > > qemu-system-aarch64 -M virt,gic-version=2 -cpu host > > may or may not work depending on whether the host CPU has the > > GICv2 back-compat support; and this: > > qemu-system-aarch64 -M virt,gic-version=x-5 -cpu host > > is currently TCG-only. (But also it's experimental so you kind > > of know you're off-piste here ;-)) > > > > If you try the things that won't work with -enable-kvm then they > > should wind up causing QEMU to exit with a hopefully more or less > > informative error message, but I don't think we have any mechanism > > for introspection of the form "if I try this particular set of > > QEMU options is it going to work?" short of actually trying. > > I recall some discussion with Markus / Paolo when brainstorming > declarative dynamic machines, we'd need another MachinePhase > iterating on all selected types to instantiate and check whether > they can be instantiated, and returning impossible config error; > way before a property is evaluated on an instance at Realize time.
Mmm, yes, that is getting into quite alot of work for probably not enough benefit. > Here IMO accelerators should report whether a CPU model class > requested is accelerable or not (then later we can double check > with features updated on the model instances). > The machine deciding is a shortcut, not scalable and hard to maintain. Yeah, I think you're right - the machine does look like a facade around the CPU for accelerator runnability. So it probably better fits the QMP commands for querying CPU runnability. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
