David Hildenbrand <da...@redhat.com> writes: > On 13.02.25 17:17, Igor Mammedov wrote: >> On Thu, 13 Feb 2025 12:48:30 +0100 >> Markus Armbruster <arm...@redhat.com> wrote: >> >>> gaosong <gaos...@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.
Looks like we made a mess. Having the same command work differently on different targets is less than ideal. I'm sure there were reasons both for the initial s390x design, and for x86-64 deviating from it later. I'm not qualified to debate this. Regardless, actual behavior should match documented behavior. If actual behavior depends on the target, then documentation needs to explain that in sufficient detail. Could we get this fixed, please?
