Future of target/arm "max" CPU type

Future of target/arm "max" CPU type

[Peter Maydell]

This is something we've discussed before. I don't think I have a very
solid grip on it and I suspect I may be missing some parts of the
"problem description" (i.e. what are we trying to achieve) and perhaps
some implications of the choice. Overall it feels to me like a "no
obviously correct answer, make a tradeoff" question. I've written this
up to try to clarify my thinking and canvass for opinions and for
people to point out what I'm missing.

For a long time now the arm targets have defined a "max" CPU type
whose definition is roughly "all the features that QEMU
implements". This is helpful for:

 - giving us a way to provide newly emulated CPU features to users
   without having to define a specific named CPU type matching some
   hardware that implements the feature (which might not exist at the
   point we add the emulation, or which might also need some other
   features we don't yet support)
 - giving users a way to say "I just want everything"

Mostly this has worked pretty well, I think. (It can cause problems
for some workloads that break when a new feature is added; TF-A
firmware seems particularly prone to this.)

However, it doesn't work so well if the architecture decides to drop a
feature and mandate that newer implementations may not implement
it. Up til now that hasn't been a big deal, as only a few very niche
items (like FEAT_DoubleLock, an old mechanism for quiescing external
debug before a CPU power-down) have ever been removed.

With the Armv9.0 architecture, a big feature gets removed: support for
running in 32-bit mode at anything above userspace (EL1, EL2, EL3) is
not allowed to be implemented.  We've got away so far with ignoring
that requirement, but as new v9.x features are added, they are
designed under the assumption that there is no 32-bit system mode
code. For instance, the GICv5 CPU interface defines only 64-bit system
registers, and our non-compliant "32-bit is actually there"
implementation would give you a 32-bit OS that couldn't handle
interrupts. Other similar (or harder to spot) issues are likely to
also turn up.

So my suggestion is that we should have two new CPU types:

 v8-max : "all the features we implement that are valid
   for the v8.x architecture"
 v9-max : "all the features we implement that are valid
   for the v9.x architecture"

v9-max would not implement AArch32 EL1/2/3; v8-max wouldn't implement
any feature the architecture says is v9-or-later.

For the existing 'max' CPU:
 - on qemu-system-arm this would be a synonym for v8-max
   (since it must be 32-bit)
 - on qemu-aarch64 and qemu-system-aarch64 this would be a synonym
   for v9-max
 - on qemu-arm it can also be v9-max, since v9 doesn't drop 32-bit
   usermode support. (Though we don't currently implement qemu-arm
   max this way, so it might end up being effectively v8-max until
   we get round to implementing support for selecting AArch64 CPUs in
   qemu-arm.)

I don't think it's worth claiming 'max' as deprecated and dropping it:
as an alias it's trivial to support, and there are a lot of workloads
that won't ever notice this change.

It's possible some workloads currently using "max" will need to switch
to 'v8-max", but I think this will be rare: it would have to be
emulation of an EL2 guest which is itself 64-bit but which runs some
inner-guest VM within itself that is 32-bit. The failure mode will be
that the (outer) guest will report that it can't run a 32-bit (inner)
guest (in whatever way that hypervisor reports that kind of error).

So that's my sketch of a proposal -- what do people think? What
have I forgotten about?

thanks
-- PMM

Re: Future of target/arm "max" CPU type

[Pierrick Bouvier]

Hi Peter,

On 5/1/2026 6:26 AM, Peter Maydell wrote:
> This is something we've discussed before. I don't think I have a very
> solid grip on it and I suspect I may be missing some parts of the
> "problem description" (i.e. what are we trying to achieve) and perhaps
> some implications of the choice. Overall it feels to me like a "no
> obviously correct answer, make a tradeoff" question. I've written this
> up to try to clarify my thinking and canvass for opinions and for
> people to point out what I'm missing.
> 
> For a long time now the arm targets have defined a "max" CPU type
> whose definition is roughly "all the features that QEMU
> implements". This is helpful for:
> 
>  - giving us a way to provide newly emulated CPU features to users
>    without having to define a specific named CPU type matching some
>    hardware that implements the feature (which might not exist at the
>    point we add the emulation, or which might also need some other
>    features we don't yet support)
>  - giving users a way to say "I just want everything"
> 
> Mostly this has worked pretty well, I think. (It can cause problems
> for some workloads that break when a new feature is added; TF-A
> firmware seems particularly prone to this.)
> 
> However, it doesn't work so well if the architecture decides to drop a
> feature and mandate that newer implementations may not implement
> it. Up til now that hasn't been a big deal, as only a few very niche
> items (like FEAT_DoubleLock, an old mechanism for quiescing external
> debug before a CPU power-down) have ever been removed.
> 
> With the Armv9.0 architecture, a big feature gets removed: support for
> running in 32-bit mode at anything above userspace (EL1, EL2, EL3) is
> not allowed to be implemented.  We've got away so far with ignoring
> that requirement, but as new v9.x features are added, they are
> designed under the assumption that there is no 32-bit system mode
> code. For instance, the GICv5 CPU interface defines only 64-bit system
> registers, and our non-compliant "32-bit is actually there"
> implementation would give you a 32-bit OS that couldn't handle
> interrupts. Other similar (or harder to spot) issues are likely to
> also turn up.
> 
> So my suggestion is that we should have two new CPU types:
> 
>  v8-max : "all the features we implement that are valid
>    for the v8.x architecture"
>  v9-max : "all the features we implement that are valid
>    for the v9.x architecture"
> 
> v9-max would not implement AArch32 EL1/2/3; v8-max wouldn't implement
> any feature the architecture says is v9-or-later.
> 
> For the existing 'max' CPU:
>  - on qemu-system-arm this would be a synonym for v8-max
>    (since it must be 32-bit)
>  - on qemu-aarch64 and qemu-system-aarch64 this would be a synonym
>    for v9-max
>  - on qemu-arm it can also be v9-max, since v9 doesn't drop 32-bit
>    usermode support. (Though we don't currently implement qemu-arm
>    max this way, so it might end up being effectively v8-max until
>    we get round to implementing support for selecting AArch64 CPUs in
>    qemu-arm.)
>

This seems like a good approach. A side effect is to solve the
duplication we encounter for the single-binary also, by correctly
deduplicating QOM types associated.

The concept of having a "max" alias that maps to a specific type (in
this case, distinct depending on the binary) could be used for other
arch if needed also.

> I don't think it's worth claiming 'max' as deprecated and dropping it:
> as an alias it's trivial to support, and there are a lot of workloads
> that won't ever notice this change.
>

I agree.

> It's possible some workloads currently using "max" will need to switch
> to 'v8-max", but I think this will be rare: it would have to be
> emulation of an EL2 guest which is itself 64-bit but which runs some
> inner-guest VM within itself that is 32-bit. The failure mode will be
> that the (outer) guest will report that it can't run a 32-bit (inner)
> guest (in whatever way that hypervisor reports that kind of error).
>

That's a good solution, and only a small minority of users (the one that
has to really deal with this) will be concerned.

> So that's my sketch of a proposal -- what do people think? What
> have I forgotten about?
> 
> thanks
> -- PMM
> 

Do you have a time frame in mind for this? It's on the path for having
the single-binary, and we can help with it if needed.

It should be a pretty straightforward change, just renaming QOM types,
and adding the "max" selection mechanic.

Regards,
Pierrick

Re: Future of target/arm "max" CPU type

[Philippe Mathieu-Daudé]

On 7/5/26 00:17, Pierrick Bouvier wrote:
> Hi Peter,
> 
> On 5/1/2026 6:26 AM, Peter Maydell wrote:
>> This is something we've discussed before. I don't think I have a very
>> solid grip on it and I suspect I may be missing some parts of the
>> "problem description" (i.e. what are we trying to achieve) and perhaps
>> some implications of the choice. Overall it feels to me like a "no
>> obviously correct answer, make a tradeoff" question. I've written this
>> up to try to clarify my thinking and canvass for opinions and for
>> people to point out what I'm missing.
>>
>> For a long time now the arm targets have defined a "max" CPU type
>> whose definition is roughly "all the features that QEMU
>> implements". This is helpful for:
>>
>>   - giving us a way to provide newly emulated CPU features to users
>>     without having to define a specific named CPU type matching some
>>     hardware that implements the feature (which might not exist at the
>>     point we add the emulation, or which might also need some other
>>     features we don't yet support)
>>   - giving users a way to say "I just want everything"
>>
>> Mostly this has worked pretty well, I think. (It can cause problems
>> for some workloads that break when a new feature is added; TF-A
>> firmware seems particularly prone to this.)
>>
>> However, it doesn't work so well if the architecture decides to drop a
>> feature and mandate that newer implementations may not implement
>> it. Up til now that hasn't been a big deal, as only a few very niche
>> items (like FEAT_DoubleLock, an old mechanism for quiescing external
>> debug before a CPU power-down) have ever been removed.
>>
>> With the Armv9.0 architecture, a big feature gets removed: support for
>> running in 32-bit mode at anything above userspace (EL1, EL2, EL3) is
>> not allowed to be implemented.  We've got away so far with ignoring
>> that requirement, but as new v9.x features are added, they are
>> designed under the assumption that there is no 32-bit system mode
>> code. For instance, the GICv5 CPU interface defines only 64-bit system
>> registers, and our non-compliant "32-bit is actually there"
>> implementation would give you a 32-bit OS that couldn't handle
>> interrupts. Other similar (or harder to spot) issues are likely to
>> also turn up.
>>
>> So my suggestion is that we should have two new CPU types:
>>
>>   v8-max : "all the features we implement that are valid
>>     for the v8.x architecture"
>>   v9-max : "all the features we implement that are valid
>>     for the v9.x architecture"
>>
>> v9-max would not implement AArch32 EL1/2/3; v8-max wouldn't implement
>> any feature the architecture says is v9-or-later.

Certainly clearer than what we currently have.

>> For the existing 'max' CPU:
>>   - on qemu-system-arm this would be a synonym for v8-max
>>     (since it must be 32-bit)
>>   - on qemu-aarch64 and qemu-system-aarch64 this would be a synonym
>>     for v9-max
>>   - on qemu-arm it can also be v9-max, since v9 doesn't drop 32-bit
>>     usermode support. (Though we don't currently implement qemu-arm
>>     max this way, so it might end up being effectively v8-max until
>>     we get round to implementing support for selecting AArch64 CPUs in
>>     qemu-arm.)
>>
> 
> This seems like a good approach. A side effect is to solve the
> duplication we encounter for the single-binary also, by correctly
> deduplicating QOM types associated.
> 
> The concept of having a "max" alias that maps to a specific type (in
> this case, distinct depending on the binary) could be used for other
> arch if needed also.
> 
>> I don't think it's worth claiming 'max' as deprecated and dropping it:
>> as an alias it's trivial to support, and there are a lot of workloads
>> that won't ever notice this change.

We could display a note though.

   "Using 'v9-max' for requested 'max' CPU".

> 
> I agree.
> 
>> It's possible some workloads currently using "max" will need to switch
>> to 'v8-max", but I think this will be rare: it would have to be
>> emulation of an EL2 guest which is itself 64-bit but which runs some
>> inner-guest VM within itself that is 32-bit. The failure mode will be
>> that the (outer) guest will report that it can't run a 32-bit (inner)
>> guest (in whatever way that hypervisor reports that kind of error).
>>
> 
> That's a good solution, and only a small minority of users (the one that
> has to really deal with this) will be concerned.
> 
>> So that's my sketch of a proposal -- what do people think? What
>> have I forgotten about?
>>
>> thanks
>> -- PMM
>>
> 
> Do you have a time frame in mind for this? It's on the path for having
> the single-binary, and we can help with it if needed.
> 
> It should be a pretty straightforward change, just renaming QOM types,
> and adding the "max" selection mechanic.

Per Peter description, it doesn't seem renaming types is a 1:1 change.

 From a reviewer point of view, it would be better to first add the
v8-max and v9-max clearly defined / documented types; then migrate
current 'max' to the appropriate new type for each binary, mentioning
the adjustments done; and finally do the alias replacement.

Re: Future of target/arm "max" CPU type

[Daniel P. Berrangé]

On Thu, May 07, 2026 at 12:17:32PM +0200, Philippe Mathieu-Daudé wrote:
> On 7/5/26 00:17, Pierrick Bouvier wrote:
> > Hi Peter,
> > 
> > On 5/1/2026 6:26 AM, Peter Maydell wrote:
> > > This is something we've discussed before. I don't think I have a very
> > > solid grip on it and I suspect I may be missing some parts of the
> > > "problem description" (i.e. what are we trying to achieve) and perhaps
> > > some implications of the choice. Overall it feels to me like a "no
> > > obviously correct answer, make a tradeoff" question. I've written this
> > > up to try to clarify my thinking and canvass for opinions and for
> > > people to point out what I'm missing.
> > > 
> > > For a long time now the arm targets have defined a "max" CPU type
> > > whose definition is roughly "all the features that QEMU
> > > implements". This is helpful for:
> > > 
> > >   - giving us a way to provide newly emulated CPU features to users
> > >     without having to define a specific named CPU type matching some
> > >     hardware that implements the feature (which might not exist at the
> > >     point we add the emulation, or which might also need some other
> > >     features we don't yet support)
> > >   - giving users a way to say "I just want everything"
> > > 
> > > Mostly this has worked pretty well, I think. (It can cause problems
> > > for some workloads that break when a new feature is added; TF-A
> > > firmware seems particularly prone to this.)
> > > 
> > > However, it doesn't work so well if the architecture decides to drop a
> > > feature and mandate that newer implementations may not implement
> > > it. Up til now that hasn't been a big deal, as only a few very niche
> > > items (like FEAT_DoubleLock, an old mechanism for quiescing external
> > > debug before a CPU power-down) have ever been removed.
> > > 
> > > With the Armv9.0 architecture, a big feature gets removed: support for
> > > running in 32-bit mode at anything above userspace (EL1, EL2, EL3) is
> > > not allowed to be implemented.  We've got away so far with ignoring
> > > that requirement, but as new v9.x features are added, they are
> > > designed under the assumption that there is no 32-bit system mode
> > > code. For instance, the GICv5 CPU interface defines only 64-bit system
> > > registers, and our non-compliant "32-bit is actually there"
> > > implementation would give you a 32-bit OS that couldn't handle
> > > interrupts. Other similar (or harder to spot) issues are likely to
> > > also turn up.
> > > 
> > > So my suggestion is that we should have two new CPU types:
> > > 
> > >   v8-max : "all the features we implement that are valid
> > >     for the v8.x architecture"
> > >   v9-max : "all the features we implement that are valid
> > >     for the v9.x architecture"
> > > 
> > > v9-max would not implement AArch32 EL1/2/3; v8-max wouldn't implement
> > > any feature the architecture says is v9-or-later.
> 
> Certainly clearer than what we currently have.
> 
> > > For the existing 'max' CPU:
> > >   - on qemu-system-arm this would be a synonym for v8-max
> > >     (since it must be 32-bit)
> > >   - on qemu-aarch64 and qemu-system-aarch64 this would be a synonym
> > >     for v9-max
> > >   - on qemu-arm it can also be v9-max, since v9 doesn't drop 32-bit
> > >     usermode support. (Though we don't currently implement qemu-arm
> > >     max this way, so it might end up being effectively v8-max until
> > >     we get round to implementing support for selecting AArch64 CPUs in
> > >     qemu-arm.)
> > > 
> > 
> > This seems like a good approach. A side effect is to solve the
> > duplication we encounter for the single-binary also, by correctly
> > deduplicating QOM types associated.
> > 
> > The concept of having a "max" alias that maps to a specific type (in
> > this case, distinct depending on the binary) could be used for other
> > arch if needed also.
> > 
> > > I don't think it's worth claiming 'max' as deprecated and dropping it:
> > > as an alias it's trivial to support, and there are a lot of workloads
> > > that won't ever notice this change.
> 
> We could display a note though.
> 
>   "Using 'v9-max' for requested 'max' CPU".

Please don't make use of "-cpu max" print warnings.

IMHO "max" should remain a first class citizen across all targets,
because it provides a consistent approach for users.

What Peter describes with resolving "max" to either "v9-max" or
"v8-max" depending on arm vs aarch64  makes sense to me.

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

Re: Future of target/arm "max" CPU type

[Philippe Mathieu-Daudé]

On 7/5/26 12:29, Daniel P. Berrangé wrote:
> On Thu, May 07, 2026 at 12:17:32PM +0200, Philippe Mathieu-Daudé wrote:
>> On 7/5/26 00:17, Pierrick Bouvier wrote:
>>> Hi Peter,
>>>
>>> On 5/1/2026 6:26 AM, Peter Maydell wrote:
>>>> This is something we've discussed before. I don't think I have a very
>>>> solid grip on it and I suspect I may be missing some parts of the
>>>> "problem description" (i.e. what are we trying to achieve) and perhaps
>>>> some implications of the choice. Overall it feels to me like a "no
>>>> obviously correct answer, make a tradeoff" question. I've written this
>>>> up to try to clarify my thinking and canvass for opinions and for
>>>> people to point out what I'm missing.
>>>>
>>>> For a long time now the arm targets have defined a "max" CPU type
>>>> whose definition is roughly "all the features that QEMU
>>>> implements". This is helpful for:
>>>>
>>>>    - giving us a way to provide newly emulated CPU features to users
>>>>      without having to define a specific named CPU type matching some
>>>>      hardware that implements the feature (which might not exist at the
>>>>      point we add the emulation, or which might also need some other
>>>>      features we don't yet support)
>>>>    - giving users a way to say "I just want everything"
>>>>
>>>> Mostly this has worked pretty well, I think. (It can cause problems
>>>> for some workloads that break when a new feature is added; TF-A
>>>> firmware seems particularly prone to this.)
>>>>
>>>> However, it doesn't work so well if the architecture decides to drop a
>>>> feature and mandate that newer implementations may not implement
>>>> it. Up til now that hasn't been a big deal, as only a few very niche
>>>> items (like FEAT_DoubleLock, an old mechanism for quiescing external
>>>> debug before a CPU power-down) have ever been removed.
>>>>
>>>> With the Armv9.0 architecture, a big feature gets removed: support for
>>>> running in 32-bit mode at anything above userspace (EL1, EL2, EL3) is
>>>> not allowed to be implemented.  We've got away so far with ignoring
>>>> that requirement, but as new v9.x features are added, they are
>>>> designed under the assumption that there is no 32-bit system mode
>>>> code. For instance, the GICv5 CPU interface defines only 64-bit system
>>>> registers, and our non-compliant "32-bit is actually there"
>>>> implementation would give you a 32-bit OS that couldn't handle
>>>> interrupts. Other similar (or harder to spot) issues are likely to
>>>> also turn up.
>>>>
>>>> So my suggestion is that we should have two new CPU types:
>>>>
>>>>    v8-max : "all the features we implement that are valid
>>>>      for the v8.x architecture"
>>>>    v9-max : "all the features we implement that are valid
>>>>      for the v9.x architecture"
>>>>
>>>> v9-max would not implement AArch32 EL1/2/3; v8-max wouldn't implement
>>>> any feature the architecture says is v9-or-later.
>>
>> Certainly clearer than what we currently have.
>>
>>>> For the existing 'max' CPU:
>>>>    - on qemu-system-arm this would be a synonym for v8-max
>>>>      (since it must be 32-bit)
>>>>    - on qemu-aarch64 and qemu-system-aarch64 this would be a synonym
>>>>      for v9-max
>>>>    - on qemu-arm it can also be v9-max, since v9 doesn't drop 32-bit
>>>>      usermode support. (Though we don't currently implement qemu-arm
>>>>      max this way, so it might end up being effectively v8-max until
>>>>      we get round to implementing support for selecting AArch64 CPUs in
>>>>      qemu-arm.)
>>>>
>>>
>>> This seems like a good approach. A side effect is to solve the
>>> duplication we encounter for the single-binary also, by correctly
>>> deduplicating QOM types associated.
>>>
>>> The concept of having a "max" alias that maps to a specific type (in
>>> this case, distinct depending on the binary) could be used for other
>>> arch if needed also.
>>>
>>>> I don't think it's worth claiming 'max' as deprecated and dropping it:
>>>> as an alias it's trivial to support, and there are a lot of workloads
>>>> that won't ever notice this change.
>>
>> We could display a note though.
>>
>>    "Using 'v9-max' for requested 'max' CPU".
> 
> Please don't make use of "-cpu max" print warnings.
> 
> IMHO "max" should remain a first class citizen across all targets,
> because it provides a consistent approach for users.
> 
> What Peter describes with resolving "max" to either "v9-max" or
> "v8-max" depending on arm vs aarch64  makes sense to me.

Effectively postponing the problem until ARMv10 gets released
with v10-max diverging from v9-max.

Nevermind, we'll keep handling "max" alias at the machine level.

Regards,

Phil.

Re: Future of target/arm "max" CPU type

[Daniel P. Berrangé]

On Thu, May 07, 2026 at 03:20:27PM +0200, Philippe Mathieu-Daudé wrote:
> On 7/5/26 12:29, Daniel P. Berrangé wrote:
> > On Thu, May 07, 2026 at 12:17:32PM +0200, Philippe Mathieu-Daudé wrote:
> > > On 7/5/26 00:17, Pierrick Bouvier wrote:
> > > > Hi Peter,
> > > > 
> > > > On 5/1/2026 6:26 AM, Peter Maydell wrote:
> > > > > This is something we've discussed before. I don't think I have a very
> > > > > solid grip on it and I suspect I may be missing some parts of the
> > > > > "problem description" (i.e. what are we trying to achieve) and perhaps
> > > > > some implications of the choice. Overall it feels to me like a "no
> > > > > obviously correct answer, make a tradeoff" question. I've written this
> > > > > up to try to clarify my thinking and canvass for opinions and for
> > > > > people to point out what I'm missing.
> > > > > 
> > > > > For a long time now the arm targets have defined a "max" CPU type
> > > > > whose definition is roughly "all the features that QEMU
> > > > > implements". This is helpful for:
> > > > > 
> > > > >    - giving us a way to provide newly emulated CPU features to users
> > > > >      without having to define a specific named CPU type matching some
> > > > >      hardware that implements the feature (which might not exist at the
> > > > >      point we add the emulation, or which might also need some other
> > > > >      features we don't yet support)
> > > > >    - giving users a way to say "I just want everything"
> > > > > 
> > > > > Mostly this has worked pretty well, I think. (It can cause problems
> > > > > for some workloads that break when a new feature is added; TF-A
> > > > > firmware seems particularly prone to this.)
> > > > > 
> > > > > However, it doesn't work so well if the architecture decides to drop a
> > > > > feature and mandate that newer implementations may not implement
> > > > > it. Up til now that hasn't been a big deal, as only a few very niche
> > > > > items (like FEAT_DoubleLock, an old mechanism for quiescing external
> > > > > debug before a CPU power-down) have ever been removed.
> > > > > 
> > > > > With the Armv9.0 architecture, a big feature gets removed: support for
> > > > > running in 32-bit mode at anything above userspace (EL1, EL2, EL3) is
> > > > > not allowed to be implemented.  We've got away so far with ignoring
> > > > > that requirement, but as new v9.x features are added, they are
> > > > > designed under the assumption that there is no 32-bit system mode
> > > > > code. For instance, the GICv5 CPU interface defines only 64-bit system
> > > > > registers, and our non-compliant "32-bit is actually there"
> > > > > implementation would give you a 32-bit OS that couldn't handle
> > > > > interrupts. Other similar (or harder to spot) issues are likely to
> > > > > also turn up.
> > > > > 
> > > > > So my suggestion is that we should have two new CPU types:
> > > > > 
> > > > >    v8-max : "all the features we implement that are valid
> > > > >      for the v8.x architecture"
> > > > >    v9-max : "all the features we implement that are valid
> > > > >      for the v9.x architecture"
> > > > > 
> > > > > v9-max would not implement AArch32 EL1/2/3; v8-max wouldn't implement
> > > > > any feature the architecture says is v9-or-later.
> > > 
> > > Certainly clearer than what we currently have.
> > > 
> > > > > For the existing 'max' CPU:
> > > > >    - on qemu-system-arm this would be a synonym for v8-max
> > > > >      (since it must be 32-bit)
> > > > >    - on qemu-aarch64 and qemu-system-aarch64 this would be a synonym
> > > > >      for v9-max
> > > > >    - on qemu-arm it can also be v9-max, since v9 doesn't drop 32-bit
> > > > >      usermode support. (Though we don't currently implement qemu-arm
> > > > >      max this way, so it might end up being effectively v8-max until
> > > > >      we get round to implementing support for selecting AArch64 CPUs in
> > > > >      qemu-arm.)
> > > > > 
> > > > 
> > > > This seems like a good approach. A side effect is to solve the
> > > > duplication we encounter for the single-binary also, by correctly
> > > > deduplicating QOM types associated.
> > > > 
> > > > The concept of having a "max" alias that maps to a specific type (in
> > > > this case, distinct depending on the binary) could be used for other
> > > > arch if needed also.
> > > > 
> > > > > I don't think it's worth claiming 'max' as deprecated and dropping it:
> > > > > as an alias it's trivial to support, and there are a lot of workloads
> > > > > that won't ever notice this change.
> > > 
> > > We could display a note though.
> > > 
> > >    "Using 'v9-max' for requested 'max' CPU".
> > 
> > Please don't make use of "-cpu max" print warnings.
> > 
> > IMHO "max" should remain a first class citizen across all targets,
> > because it provides a consistent approach for users.
> > 
> > What Peter describes with resolving "max" to either "v9-max" or
> > "v8-max" depending on arm vs aarch64  makes sense to me.
> 
> Effectively postponing the problem until ARMv10 gets released
> with v10-max diverging from v9-max.
> 
> Nevermind, we'll keep handling "max" alias at the machine level.

Tieing to machine type is tricky, however, as v10-max vs v9-max
will have different "runability" depending on what the host OS
is

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