[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 1/6] machine: Convert the valid cpu types to

From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH v5 1/6] machine: Convert the valid cpu types to use cpu_model
Date: Thu, 23 Jan 2020 19:48:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

On 6/20/19 4:43 PM, Eduardo Habkost wrote:
On Thu, Jun 20, 2019 at 11:02:39AM +0200, Igor Mammedov wrote:
On Tue, 18 Jun 2019 10:55:16 -0300
Eduardo Habkost <address@hidden> wrote:

On Tue, Jun 18, 2019 at 01:34:10PM +0200, Igor Mammedov wrote:
On Mon, 17 Jun 2019 13:27:00 -0300
Eduardo Habkost <address@hidden> wrote:
On Mon, Jun 17, 2019 at 05:33:43PM +0200, Igor Mammedov wrote:
On Mon, 17 Jun 2019 17:15:21 +0200
Philippe Mathieu-Daudé <address@hidden> wrote:
Yes. Eduardo and you should write some lines to explain this, and then
we will follow :)
Unfortunately I don't recall details anymore. One could check out all
implementations of class_by_name callbacks to find out current state.

See this message for a summary of existing class_by_name quirks:

   Date: Wed, 08 May 2019 10:34:44 +0200
   Message-ID: <address@hidden>
   Subject: Re: [Qemu-devel] [PATCH 0/7] Delete 16 *_cpu_class_by_name() 

I'm unsure about Igor's suggestion to get rid of CPU model names
and use only QOM type names in external interfaces.  In either
case, we can still simplify the rules rules and reduce the amount
of arch-specific code.
as far as we have cpu_class_by_name, we have to watch over that
new patches/targets won't add some custom handling/fallbac/whatnot.

We can get rid of CPUClass::cpu_class_by_name() without changing
the external interfaces provided by QEMU.
if you mean QMP, than it is possible to keep model there where
it already exists. Based on experiment [1](x86) I did, it's local to
affected target and doesn't pollute other code.

I mean both command line and QMP.

I don't have a strong opinion about using only QOM types at -cpu,
yet.  But first we need to get rid of the arch-specific CPU model
name exceptions enumerated at the URL above (which would be very
One way to get rid of them is to deprecate them in favor of strict
match (no fallback/substitutions/aliases) to typename and when we
drop it make switch type based naming only.

This is true, but is it desirable?  Aren't we just moving
complexity elsewhere?  Management software would still need to
translate CPU models from existing VM configurations to QOM type

1) I've just took a quick look at how much of duplicated/confusing
code we could get rid off if we drop cpu_class_by_name/*_cpu_list.
It amounts to >800LOC of trivial removal (not counting ppc/s390
that depend on model naming heavily and in need of some non
trivial refactoring)

Removing the code might be trivial.  Coordinating with the
maintainers of all architectures to confirm this is really
something everybody wants is the difficult part.

If you really want to do it, please make sure all the
architecture maintainers (and libvirt developers) are involved in
the discussion.

From the previous link (summary of existing class_by_name quirks):

  "Deprecating unwanted stuff now is likely to make a
   later cleanup so much easier."

This was 8 months ago :/

IIUC we need to restart this topic addressing the libvirt community first, then see with the QEMU one?

On contrary -device works just with type names for all devices,
applying the same to -cpu which is basically translator
    model->type[,-global type.foo,...]
would be consistent with -device and less confusing for everyone
(not counting significant code reduction).
It would certainly simplify contributing new targets as contributor
won't have to care about cpu model naming and do something about it.

This option wasn't considered before because we didn't have deprecation
back then, but now it opens possibility to simplify qemu and consolidate
naming. (we probably would be able to fold '-cpu help' into '-device help'
as well).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]