On Thu, 31 Oct 2024 at 12:24, Kashyap Chamarthy <kcham...@redhat.com> wrote: > > On Mon, Oct 28, 2024 at 05:29:11PM +0100, Cornelia Huck wrote: > > On Mon, Oct 28 2024, Daniel P. Berrangé <berra...@redhat.com> 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?
Ideally, disabling features would work with any '-cpu' option (including our existing TCG CPUs). (The main reason for 'max' is as an option that works whether you're using TCG or KVM.) -- PMM
