Re: [Qemu-devel] [PATCH v1] qemu: command: rework cpu feature argument support

Re: [Qemu-devel] [PATCH v1] qemu: command: rework cpu feature argument support

[Eduardo Habkost]

CCing qemu-devel.

CCing Markus, in case he has any insights about the interface
introspection.

On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote:
> On Mon, Nov 14, 2016 at 18:02:29 -0200, Eduardo Habkost wrote:
> > On Mon, Nov 14, 2016 at 02:26:03PM -0500, Collin L. Walling wrote:
> > > cpu features are passed to the qemu command with feature=on/off
> > > instead of +/-feature.
> > > 
> > > Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
> > 
> > If I'm not mistaken, the "feature=on|off" syntax was added on
> > QEMU 2.0.0. Does current libvirt support older QEMU versions?
> 
> Of course it does. I'd love to switch to feature=on|off, but how can we
> check if QEMU supports it? We can't really start using this syntax
> without it.

Actually, I was wrong, this was added in v2.4.0. "feat=on|off"
needs two things to work (in x86):

* Translation of all "foo=bar" options to QOM property setting.
  This was added in v2.0.0-rc0~162^2
* The actual QOM properties for feature names to be present. They
  were added in v2.4.0-rc0~101^2~1

So you can be sure "feat=on" is supported by checking if the
feature flags are present in device-list-properties output for
the CPU model. But device-list-properties is also messy[1].

Maybe we can use the availability of query-cpu-model-expansion to
check if we can safely use the new "feat=on|off" system? It's
easier than taking all the variables above into account.

---

[1] * device-list-properties support for x86 CPU QOM classes
      will be in QEMU 2.8.
    * device-list-properties on x86 CPU QOM classes returns
      an error on QEMU 2.5-2.7.
    * device-list-properties on x86 CPU classes may crash QEMU in
      QEMU older than 2.5 (see commit 4c315c27).
  But:
    * query-cpu-definitions will probably return the CPU QOM
      typename in QEMU 2.9+ only.


-- 
Eduardo

Re: [Qemu-devel] [libvirt] [PATCH v1] qemu: command: rework cpu feature argument support

[Jiri Denemark]

On Tue, Nov 15, 2016 at 11:44:00 -0200, Eduardo Habkost wrote:
> CCing qemu-devel.
> 
> CCing Markus, in case he has any insights about the interface
> introspection.
> 
> On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote:
> > On Mon, Nov 14, 2016 at 18:02:29 -0200, Eduardo Habkost wrote:
> > > On Mon, Nov 14, 2016 at 02:26:03PM -0500, Collin L. Walling wrote:
> > > > cpu features are passed to the qemu command with feature=on/off
> > > > instead of +/-feature.
> > > > 
> > > > Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
> > > 
> > > If I'm not mistaken, the "feature=on|off" syntax was added on
> > > QEMU 2.0.0. Does current libvirt support older QEMU versions?
> > 
> > Of course it does. I'd love to switch to feature=on|off, but how can we
> > check if QEMU supports it? We can't really start using this syntax
> > without it.
> 
> Actually, I was wrong, this was added in v2.4.0. "feat=on|off"
> needs two things to work (in x86):
> 
> * Translation of all "foo=bar" options to QOM property setting.
>   This was added in v2.0.0-rc0~162^2
> * The actual QOM properties for feature names to be present. They
>   were added in v2.4.0-rc0~101^2~1
> 
> So you can be sure "feat=on" is supported by checking if the
> feature flags are present in device-list-properties output for
> the CPU model. But device-list-properties is also messy[1].
> 
> Maybe we can use the availability of query-cpu-model-expansion to
> check if we can safely use the new "feat=on|off" system? It's
> easier than taking all the variables above into account.

Yeah, this could work since s390 already supports
query-cpu-model-expansion. It would cause feature=on|off not to be used
on x86_64 with QEMU older than 2.9.0, but I guess that's not a big deal,
is it?

Jirka

Re: [Qemu-devel] [libvirt] [PATCH v1] qemu: command: rework cpu feature argument support

[Eduardo Habkost]

On Wed, Nov 16, 2016 at 02:15:02PM +0100, Jiri Denemark wrote:
> On Tue, Nov 15, 2016 at 11:44:00 -0200, Eduardo Habkost wrote:
> > CCing qemu-devel.
> > 
> > CCing Markus, in case he has any insights about the interface
> > introspection.
> > 
> > On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote:
> > > On Mon, Nov 14, 2016 at 18:02:29 -0200, Eduardo Habkost wrote:
> > > > On Mon, Nov 14, 2016 at 02:26:03PM -0500, Collin L. Walling wrote:
> > > > > cpu features are passed to the qemu command with feature=on/off
> > > > > instead of +/-feature.
> > > > > 
> > > > > Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
> > > > 
> > > > If I'm not mistaken, the "feature=on|off" syntax was added on
> > > > QEMU 2.0.0. Does current libvirt support older QEMU versions?
> > > 
> > > Of course it does. I'd love to switch to feature=on|off, but how can we
> > > check if QEMU supports it? We can't really start using this syntax
> > > without it.
> > 
> > Actually, I was wrong, this was added in v2.4.0. "feat=on|off"
> > needs two things to work (in x86):
> > 
> > * Translation of all "foo=bar" options to QOM property setting.
> >   This was added in v2.0.0-rc0~162^2
> > * The actual QOM properties for feature names to be present. They
> >   were added in v2.4.0-rc0~101^2~1
> > 
> > So you can be sure "feat=on" is supported by checking if the
> > feature flags are present in device-list-properties output for
> > the CPU model. But device-list-properties is also messy[1].
> > 
> > Maybe we can use the availability of query-cpu-model-expansion to
> > check if we can safely use the new "feat=on|off" system? It's
> > easier than taking all the variables above into account.
> 
> Yeah, this could work since s390 already supports
> query-cpu-model-expansion. It would cause feature=on|off not to be used
> on x86_64 with QEMU older than 2.9.0, but I guess that's not a big deal,
> is it?

Not a problem, as we have no plans to remove +feat/-feat support
in x86 anymore.

-- 
Eduardo

Re: [Qemu-devel] [libvirt] [PATCH v1] qemu: command: rework cpu feature argument support

[Collin L. Walling]

On 11/16/2016 09:05 AM, Eduardo Habkost wrote:
> On Wed, Nov 16, 2016 at 02:15:02PM +0100, Jiri Denemark wrote:
>> On Tue, Nov 15, 2016 at 11:44:00 -0200, Eduardo Habkost wrote:
>>> CCing qemu-devel.
>>>
>>> CCing Markus, in case he has any insights about the interface
>>> introspection.
>>>
>>> On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote:
>>>> On Mon, Nov 14, 2016 at 18:02:29 -0200, Eduardo Habkost wrote:
>>>>> On Mon, Nov 14, 2016 at 02:26:03PM -0500, Collin L. Walling wrote:
>>>>>> cpu features are passed to the qemu command with feature=on/off
>>>>>> instead of +/-feature.
>>>>>>
>>>>>> Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
>>>>> If I'm not mistaken, the "feature=on|off" syntax was added on
>>>>> QEMU 2.0.0. Does current libvirt support older QEMU versions?
>>>> Of course it does. I'd love to switch to feature=on|off, but how can we
>>>> check if QEMU supports it? We can't really start using this syntax
>>>> without it.
>>> Actually, I was wrong, this was added in v2.4.0. "feat=on|off"
>>> needs two things to work (in x86):
>>>
>>> * Translation of all "foo=bar" options to QOM property setting.
>>>    This was added in v2.0.0-rc0~162^2
>>> * The actual QOM properties for feature names to be present. They
>>>    were added in v2.4.0-rc0~101^2~1
>>>
>>> So you can be sure "feat=on" is supported by checking if the
>>> feature flags are present in device-list-properties output for
>>> the CPU model. But device-list-properties is also messy[1].
>>>
>>> Maybe we can use the availability of query-cpu-model-expansion to
>>> check if we can safely use the new "feat=on|off" system? It's
>>> easier than taking all the variables above into account.
>> Yeah, this could work since s390 already supports
>> query-cpu-model-expansion. It would cause feature=on|off not to be used
>> on x86_64 with QEMU older than 2.9.0, but I guess that's not a big deal,
>> is it?
> Not a problem, as we have no plans to remove +feat/-feat support
> in x86 anymore.
>
Beautiful. Thanks for your responses everyone. :)

Re: [Qemu-devel] [PATCH v1] qemu: command: rework cpu feature argument support

[Markus Armbruster]

Eduardo Habkost <ehabkost@redhat.com> writes:

> CCing qemu-devel.
>
> CCing Markus, in case he has any insights about the interface
> introspection.
>
> On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote:
>> On Mon, Nov 14, 2016 at 18:02:29 -0200, Eduardo Habkost wrote:
>> > On Mon, Nov 14, 2016 at 02:26:03PM -0500, Collin L. Walling wrote:
>> > > cpu features are passed to the qemu command with feature=on/off
>> > > instead of +/-feature.
>> > > 
>> > > Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
>> > 
>> > If I'm not mistaken, the "feature=on|off" syntax was added on
>> > QEMU 2.0.0. Does current libvirt support older QEMU versions?
>> 
>> Of course it does. I'd love to switch to feature=on|off, but how can we
>> check if QEMU supports it? We can't really start using this syntax
>> without it.
>
> Actually, I was wrong, this was added in v2.4.0. "feat=on|off"
> needs two things to work (in x86):
>
> * Translation of all "foo=bar" options to QOM property setting.
>   This was added in v2.0.0-rc0~162^2
> * The actual QOM properties for feature names to be present. They
>   were added in v2.4.0-rc0~101^2~1
>
> So you can be sure "feat=on" is supported by checking if the
> feature flags are present in device-list-properties output for
> the CPU model. But device-list-properties is also messy[1].
>
> Maybe we can use the availability of query-cpu-model-expansion to
> check if we can safely use the new "feat=on|off" system? It's
> easier than taking all the variables above into account.
>
> ---
>
> [1] * device-list-properties support for x86 CPU QOM classes
>       will be in QEMU 2.8.
>     * device-list-properties on x86 CPU QOM classes returns
>       an error on QEMU 2.5-2.7.
>     * device-list-properties on x86 CPU classes may crash QEMU in
>       QEMU older than 2.5 (see commit 4c315c27).
>   But:
>     * query-cpu-definitions will probably return the CPU QOM
>       typename in QEMU 2.9+ only.

In other words:

* feature=on|off works since 2.4, but what's the best way to probe for
  it?

* device-list-properties can act as a witness, but there are two
  problems: you need to map between CPU model and QOM typename to use
  it, and it can fail or even crash before 2.8.

* 2.9 will take provide the information to map between CPU model and QOM
  typename.

I guess the sane choice is to probe for the CPU model - QOM typename
mapping information, and if it's there, assume device-list-properties
and feature=on|off work.  Eduardo, what do you think?

Re: [Qemu-devel] [PATCH v1] qemu: command: rework cpu feature argument support

[Eduardo Habkost]

On Thu, Nov 17, 2016 at 04:04:33PM +0100, Markus Armbruster wrote:
> Eduardo Habkost <ehabkost@redhat.com> writes:
> 
> > CCing qemu-devel.
> >
> > CCing Markus, in case he has any insights about the interface
> > introspection.
> >
> > On Tue, Nov 15, 2016 at 08:42:12AM +0100, Jiri Denemark wrote:
> >> On Mon, Nov 14, 2016 at 18:02:29 -0200, Eduardo Habkost wrote:
> >> > On Mon, Nov 14, 2016 at 02:26:03PM -0500, Collin L. Walling wrote:
> >> > > cpu features are passed to the qemu command with feature=on/off
> >> > > instead of +/-feature.
> >> > > 
> >> > > Signed-off-by: Collin L. Walling <walling@linux.vnet.ibm.com>
> >> > 
> >> > If I'm not mistaken, the "feature=on|off" syntax was added on
> >> > QEMU 2.0.0. Does current libvirt support older QEMU versions?
> >> 
> >> Of course it does. I'd love to switch to feature=on|off, but how can we
> >> check if QEMU supports it? We can't really start using this syntax
> >> without it.
> >
> > Actually, I was wrong, this was added in v2.4.0. "feat=on|off"
> > needs two things to work (in x86):
> >
> > * Translation of all "foo=bar" options to QOM property setting.
> >   This was added in v2.0.0-rc0~162^2
> > * The actual QOM properties for feature names to be present. They
> >   were added in v2.4.0-rc0~101^2~1
> >
> > So you can be sure "feat=on" is supported by checking if the
> > feature flags are present in device-list-properties output for
> > the CPU model. But device-list-properties is also messy[1].
> >
> > Maybe we can use the availability of query-cpu-model-expansion to
> > check if we can safely use the new "feat=on|off" system? It's
> > easier than taking all the variables above into account.
> >
> > ---
> >
> > [1] * device-list-properties support for x86 CPU QOM classes
> >       will be in QEMU 2.8.
> >     * device-list-properties on x86 CPU QOM classes returns
> >       an error on QEMU 2.5-2.7.
> >     * device-list-properties on x86 CPU classes may crash QEMU in
> >       QEMU older than 2.5 (see commit 4c315c27).
> >   But:
> >     * query-cpu-definitions will probably return the CPU QOM
> >       typename in QEMU 2.9+ only.
> 
> In other words:
> 
> * feature=on|off works since 2.4, but what's the best way to probe for
>   it?
> 
> * device-list-properties can act as a witness, but there are two
>   problems: you need to map between CPU model and QOM typename to use
>   it, and it can fail or even crash before 2.8.
> 
> * 2.9 will take provide the information to map between CPU model and QOM
>   typename.
> 
> I guess the sane choice is to probe for the CPU model - QOM typename
> mapping information, and if it's there, assume device-list-properties
> and feature=on|off work.  Eduardo, what do you think?

That would work for x86, but not for s390x on QEMU <= 2.8 (where
only feat=on|off is supported). Using query-cpu-model-expansion
as a witness would work for both s390x and i386, even with
QEMU <= 2.8.

-- 
Eduardo