Re: [PATCH 02/33] hw/arm: Add basic Phytium Pi machine

["Daniel P. Berrangé" <berrange@redhat.com>]

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é <berrange@redhat.com> 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é <berrange@redhat.com> 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 :|