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.
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.
