All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>,
	Markus Armbruster <armbru@redhat.com>
Cc: gaosong <gaosong@loongson.cn>, Bibo Mao <maobibo@loongson.cn>,
	QEMU devel <qemu-devel@nongnu.org>,
	Eduardo Habkost <eduardo@habkost.net>
Subject: Re: [PATCH] target/loongarch: Add full type support for query-cpu-model-expansion
Date: Thu, 13 Feb 2025 17:25:08 +0100	[thread overview]
Message-ID: <c1f5c4d2-d131-452f-b414-169bb6685f07@redhat.com> (raw)
In-Reply-To: <20250213171705.6dde38cf@imammedo.users.ipa.redhat.com>

On 13.02.25 17:17, Igor Mammedov wrote:
> On Thu, 13 Feb 2025 12:48:30 +0100
> Markus Armbruster <armbru@redhat.com> wrote:
> 
>> gaosong <gaosong@loongson.cn> writes:
>>
>>> Cc: Markus
>>>
>>> hi, Markus
>>>
>>> What is the difference between CPU_MODEL_EXPANSION_TYPE_STATIC and
>>> CPU_MODEL_EXPANSION_TYPE_FULL?
> 
> the only difference is that 'static' expansion will not report properties
> not mentioned in hard-codded CPU model definition see: builtin_x86_defs
> 
> while 'full' will iterate over/report all rw properties of CPU object
> created from provided model name.
> 
>> I don't know :)
>>
>> Here's the documentation:
>>
>>      ##
>>      # @CpuModelExpansionType:
>>      #
>>      # An enumeration of CPU model expansion types.
>>      #
>>      # @static: Expand to a static CPU model, a combination of a static
>>      #     base model name and property delta changes.  As the static base
>>      #     model will never change, the expanded CPU model will be the
>>      #     same, independent of QEMU version, machine type, machine
>>      #     options, and accelerator options.  Therefore, the resulting
>>      #     model can be used by tooling without having to specify a
>>      #     compatibility machine - e.g. when displaying the "host" model.
>>      #     The @static CPU models are migration-safe.
> 
> Looking at related x86 code above description sounds like a fiction.

On s390x, which added that interface, that is how it's work.

It resolves to "-base" models that are fixed for all eternity.

x86-64 probably didn't adhere to the description because they were not 
interested in adding stable base models.

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2025-02-13 16:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-13  9:16 [PATCH] target/loongarch: Add full type support for query-cpu-model-expansion Bibo Mao
2025-02-13  9:40 ` bibo mao
2025-02-13 16:52   ` Igor Mammedov
2025-02-14  1:57     ` bibo mao
2025-02-13 10:07 ` gaosong
2025-02-13 11:48   ` Markus Armbruster
2025-02-13 16:17     ` Igor Mammedov
2025-02-13 16:25       ` David Hildenbrand [this message]
2025-02-14 12:29         ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c1f5c4d2-d131-452f-b414-169bb6685f07@redhat.com \
    --to=david@redhat.com \
    --cc=armbru@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=gaosong@loongson.cn \
    --cc=imammedo@redhat.com \
    --cc=maobibo@loongson.cn \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.