On Wed, 2023-02-08 at 20:23 +0100, Markus Armbruster wrote:
> Nina Schoetterl-Glausch <nsg@xxxxxxxxxxxxx> writes:
>
> > On Wed, 2023-02-01 at 14:20 +0100, Pierre Morel wrote:
> > > When the guest asks to change the polarity this change
> > > is forwarded to the admin using QAPI.
> > > The admin is supposed to take according decisions concerning
> > > CPU provisioning.
> > >
> > > Signed-off-by: Pierre Morel <pmorel@xxxxxxxxxxxxx>
> > > ---
> > > qapi/machine-target.json | 30 ++++++++++++++++++++++++++++++
> > > hw/s390x/cpu-topology.c | 2 ++
> > > 2 files changed, 32 insertions(+)
> > >
> > > diff --git a/qapi/machine-target.json b/qapi/machine-target.json
> > > index 58df0f5061..5883c3b020 100644
> > > --- a/qapi/machine-target.json
> > > +++ b/qapi/machine-target.json
> > > @@ -371,3 +371,33 @@
> > > },
> > > 'if': { 'all': [ 'TARGET_S390X', 'CONFIG_KVM' ] }
> > > }
> > > +
> > > +##
> > > +# @CPU_POLARITY_CHANGE:
> > > +#
> > > +# Emitted when the guest asks to change the polarity.
> > > +#
> > > +# @polarity: polarity specified by the guest
> > > +#
> > > +# The guest can tell the host (via the PTF instruction) whether the
> > > +# CPUs should be provisioned using horizontal or vertical polarity.
> > > +#
> > > +# On horizontal polarity the host is expected to provision all vCPUs
> > > +# equally.
> > > +# On vertical polarity the host can provision each vCPU differently.
> > > +# The guest will get information on the details of the provisioning
> > > +# the next time it uses the STSI(15) instruction.
> > > +#
> > > +# Since: 8.0
> > > +#
> > > +# Example:
> > > +#
> > > +# <- { "event": "CPU_POLARITY_CHANGE",
> > > +# "data": { "polarity": 0 },
> > > +# "timestamp": { "seconds": 1401385907, "microseconds": 422329 } }
> > > +#
> > > +##
> > > +{ 'event': 'CPU_POLARITY_CHANGE',
> > > + 'data': { 'polarity': 'int' },
> > > + 'if': { 'all': [ 'TARGET_S390X', 'CONFIG_KVM'] }
> >
> > I wonder if you should depend on CONFIG_KVM or not. If tcg gets topology
> > support it will use the same event and right now it would just never be emitted.
> > On the other hand it's more conservative this way.
>
> TCG vs. KVM should be as transparent as we can make it.
>
> If only KVM can get into the state where the event is emitted, say
> because the state is only possible with features only KVM supports, then
> making the event conditional on KVM makes sense. Of course, when
> another accelerator acquires these features, we need to emit the event
> there as well, which will involve adjusting the condition.
That's the case here, KVM supports the feature, TCG doesn't, although there is no
reason it couldn't in the future.
>
> > I also wonder if you should add 'feature' : [ 'unstable' ].
> > On the upside, it would mark the event as unstable, but I don't know what the
> > consequences are exactly.
>
> docs/devel/qapi-code-gen.rst:
>
> Special features
> ~~~~~~~~~~~~~~~~
>
> Feature "deprecated" marks a command, event, enum value, or struct
> member as deprecated. It is not supported elsewhere so far.
> Interfaces so marked may be withdrawn in future releases in accordance
> with QEMU's deprecation policy.
>
> Feature "unstable" marks a command, event, enum value, or struct
> member as unstable. It is not supported elsewhere so far. Interfaces
> so marked may be withdrawn or changed incompatibly in future releases.
Yeah, I saw that, but wasn't aware of -compat, thanks.
>
> See also -compat parameters unstable-input, unstable-output, both
> intended for "testing the future".
>
> > Also I guess one can remove qemu events without breaking backwards compatibility,
> > since they just won't be emitted? Unless I guess you specify that a event must
> > occur under certain situations and the client waits on it?
>
> Events are part of the interface just like command returns are. Not
> emitting an event in a situation where it was emitted before can easily
> break things. Only when the situation is no longer possible, the event
> can be removed safely.
@Pierre, seems it would be a good idea to mark all changes to qmp unstable, not just
set-cpu-topology, can just remove it later after all.
>
> Questions?
>
> [...]
>
