On 8/10/2026 8:56 AM, Daniel P. Berrangé wrote: > On Thu, Aug 06, 2026 at 01:21:13PM -0700, Pierrick Bouvier wrote: >> On 8/6/2026 9:52 AM, Daniel P. Berrangé wrote: >>> >>> What machines you could see when doing "qemu-system --machine help" >>> would depend on which/how many "--target NAME" args you enable. >>> >>> qemu-system -target x86_64 -machine help >>> -> x86_64 machines >>> (equiv of qemu-system-x86_64) >>> >>> qemu-system -target aarch64 >>> -> aarch64 machines >>> (equiv of qemu-system-aarch64) >>> >>> qemu-system -target x86_64,aarch64 >>> -> aarch64 machines >>> -> x86_64 machines >>> -> aarch64+x86_64 machines >>> (equiv of qemu-system-aarch64 plus qemu-system-x86_64 plus new >>> heterogenous machines) >>> >>> qemu-system -target x86_64,aarch64,riscv64 >>> -> aarch64 machines >>> -> x86_64 machines >>> -> riscv64 machines >>> -> aarch64+x86_64 machines >>> -> aarch64+riscv64 machines >>> -> riscv64+x86_64 machines >>> -> aarch64+riscv64+x86_64 machines >>> (equiv of qemu-system-aarch64 plus qemu-system-x86_64 >>> plus qemu-system-riscv64 plus new heterogenous machines >>> for any combo of x86_64, aarch64 and riscv64) >>> >> >> This is where we have a gap in our understanding. >> The goal is not to enable multiple targets, not in this way at least. >> >> I give you a simple example about why it's a bad design: >> What is the semantic of such a line? >> $ qemu-system -target x86_64,aarch64,riscv64 -M virt -cpu max >> We now created an ambiguous command line, is virt the virt riscv64 or >> aarch64? How about cpu? > > The ambiguity needs fixing before we can have multiple different > targets in the same binary. I would expect you're going to hit a > failure before QEMU even tries to process that command line, as > QOM class names must be unique and you'll have two separate > classes called 'virt-machine' AFAICT. >
That's why it's interesting to fix this issue, as we add more targets. We met this issue with max cpu between arm and aarch64. There is no "generic solution" and we'll tackle issues one after another, like we did so far. >> Someone with over engineering tendencies will come with the idea: >> "Ok let's prefix machine and cpu with target". >> $ qemu-system -target x86_64,aarch64,riscv64 -M aarch64:virt -cpu >> aarch64:max >> >> And then, someone will say: >> $ qemu-system -target x86_64,aarch64,riscv64 -M aarch64:virt -cpu >> riscv64:max >> And then, we will all go to hell for creating such a thing. > > I wouldn't suggest we need to prefix an arch name for *everything*, > as most type names will not clash. "virt" and "max" are two > exceptions but most machine names and CPU names will be unique > across architectures. > > IOW, just those clashing names need fixing, 'aarch64-virt' > and 'aarch64-max', but not the rest. > So now, should it be the default name for existing binary, or just for single-binary? This approach creates more and more problem. > Saying this is "going to hell" is overly dramatic. It is just > an expected result of fixing a handful of cases where we got > away without having properly unique naming today. > Sorry for not being a native speaker. The meaning I wanted to express is that we would commit a sin, and end up in hell because of that. >> The only sane solution is to restrict to a single -target, and have the >> exact same behavior than current binaries. No change, no breakage. > > I think we're going to need to have changes this area. > > To deal with the transition we'll need to support aliases > like "virt" that resolve to either "aarch64_virt" or "riscv64_virt" > depending on target specific context, or raise an error if it is > ambiguous in a fully heterogenous context. > How about we wait to have a single-binary before solving issues to which we're not exposed yet? We don't even have a prototype upstream, and we're already trying to solve issues we'll have in 6 months. One lesson of our work so far was that trying to fix things before they happen just create more delay and problems. >> For heterogeneous machines, we want to propose a very different >> approach, that requires all QOM types to be registered. Once again, it's >> not the time to present/solve that, but it's why we implemented this >> runtime filtering instead of exposing only some types. > > AFAIK, QEMU won't be able to register all QOM types, as it will have > multiple different classes called 'virt-machine' and will (should) > trigger an assert until they're given unique names. > See the first paragraph in my answer above. > With regards, > Daniel
