On Mon, Oct 28, 2024 at 05:29:11PM +0100, Cornelia Huck wrote:
> On Mon, Oct 28 2024, Daniel P. Berrangé <[email protected]> wrote:
[...]
> >> We could consolidate that to the current "host" model, once we figure
> >> out how to handle the currently already existing properties. Models
> >> based on the different architecture extensions would probably be more
> >> useable in the long run; maybe "custom" has a place for testing.
> >
> > If you can set the features against "host", then any testing could
> > be done with "host" surely, making 'custom' pointless ?
>
> We might differentiate between "do some consistency checks" and "allow
> a completely weird wolpertinger"; if we agree that we don't need it,
> then we surely could drop it again.
Yeah, FWIW, I agree that it's best to drop "custom" if all the
meaningful tests can be handled by being able to add/remove CPU flags
from `-cpu host`.
Related: I don't see any mention of `-cpu max` here. Is it not
relevant? It is currently defined as: "enables all features supported
by the accelerator in the current host". Does it make sense for `max`
to allow disabling features? Or is the idea that, why would you choose
`-cpu max` if you want to disable features? In that case, go with
either:
-cpu host,feat1=off
Or:
-cpu some_future_named_model,$feat1=off
?
--
/kashyap
