[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Patch v1 01/29] qmp: details about CPU definitions in
From: |
David Hildenbrand |
Subject: |
Re: [Qemu-devel] [Patch v1 01/29] qmp: details about CPU definitions in query-cpu-definitions |
Date: |
Tue, 2 Aug 2016 16:53:24 +0200 |
> On Tue, Aug 02, 2016 at 04:27:55PM +0200, David Hildenbrand wrote:
> [...]
> > > > >
> > > > > I believe in this case we don't need to make it optional: just
> > > > > make the field always present and set it to "false" by default.
> > > >
> > > > That is true for x86, do you know about the other architectures (arm,
> > > > ppc)?
> > > > I'd like to avoid returning false information here for other
> > > > architectures.
> > >
> > > As being "static" is not a fact about the existing code, but just
> > > a guarantee about what the developers are going to do in the
> > > future, static=false just means that the developers didn't make
> > > any promises yet (so I don't think it would ever be false
> > > information).
> > >
> > > In other words, I believe we can safely assume a CPU model is not
> > > guaranteed to be static unless the maintainers decided to
> > > explicitly document it as static (and change the data returned by
> > > query-cpu-definitions).
> > >
> > > (I am assuming that changing it from "false" to "true" in a new
> > > QEMU version won't be a problem for anybody.)
> > >
> >
> > Hmm, if "static" means, the model will never be changed, but it was changed
> > in
> > the past, this sounds somewhat strange. I would rather say then "information
> > is not available" == no guarantee.
>
> If the CPU model really changed in the past, I think it must be
> always set to "false".
>
> But if it never changed in the past and we never made an explicit
> decision about future guarantees, we can set it to "false" today,
> and change it to "true" later (after we made a decision).
>
> >
> > But if nobody else sees a problem with that, I can just set it to
> > stable=false
> > on all other architectures.
>
> I think it's OK, as long we set it to "true" only if it never
> changed in the past.
>
That indeed is okay. So I'll change that for arm,ppc and x86 (static=false for
all returned definitions).
David
- [Qemu-devel] [Patch v1 00/29] s390x CPU models: exposing features, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 02/29] s390x/cpumodel: "host" and "qemu" as CPU subclasses, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 05/29] s390x/cpumodel: generate CPU feature lists for CPU models, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 01/29] qmp: details about CPU definitions in query-cpu-definitions, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 16/29] s390x/sclp: propagate the ibc val(lowest and unblocked ibc), David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 17/29] s390x/sclp: propagate the mha via sclp, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 15/29] s390x/sclp: indicate sclp features, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 03/29] s390x/cpumodel: expose CPU class properties, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 07/29] s390x/cpumodel: introduce CPU feature group definitions, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 14/29] s390x/sclp: introduce sclp feature blocks, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 12/29] s390x/cpumodel: check and apply the CPU model, David Hildenbrand, 2016/08/02
- [Qemu-devel] [Patch v1 18/29] s390x/sclp: propagate hmfai, David Hildenbrand, 2016/08/02