Hi,
this series tries to address a drop of commandline options by qemu in regard to
osxsave [1] and ospke [2].
This was already discussed in [3] late last year but got forgotten afterwards.
The Ubuntu bug is at [4] and an older Fedora bug is at [5].

TL;DR:
- osxsave/ospke features were never really configurable
- KVM never returned the bits on GET_SUPPORTED_CPUID
- very rare to be seen in the wild
- avoid issues with newer qemu and old/odd XMLs to be sure

Details:

I checked various use cases from virt-install to openstack and some in between.
The only cases I found that would define osxsave/ospke is virt-install pior
to version 2.0 and even there only when used with --cpu=host-model or
--cpu=host-copy.
If you ever really enabled the feature you'd have got:
  error: the CPU is incompatible with host CPU:
  Host CPU does not provide required features: ospke

The problem lies in domain XMLs that explicitly disable it. That would be
    <feature policy='disable' name='osxsave'/>
But due to almost (or actually none) no host exposing this the following
also triggers:
    <feature policy='optional' name='ospke'/>

This will make libvirt add it to the qemu commandline like:
  -cpu ...,osxsave=off,ospke=off

And that will crash when qemu starts with:
  error: internal error: process exited while connecting to monitor:
  2019-04-25T12:12:01.698646Z qemu-system-x86_64: can't apply global
  core2duo-x86_64-cpu.osxsave=off: Property '.osxsave' not found

There are much more long term discussions about demoting and dropping qemu
features and I'd like to avoid those discussions being mixed.
The reason to drop it more or less without notice was that it never did
anything to begin with. Due to that our solution might in a similar fashion
be more trivial - just stop defining those two features to qemu commandline.

[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7
[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc
[3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg561877.html
[4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195
[5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848

Christian Ehrhardt (2):
  qemu: do not define known no-op features
  qemuxml2argvtest: add test for remove cpu features

 src/qemu/qemu_command.c                       | 23 +++++++++++++++
 .../qemuxml2argvdata/cpu-host-model-cmt.args  |  2 +-
 .../cpu-no-removed-features.args              | 29 +++++++++++++++++++
 .../cpu-no-removed-features.xml               | 23 +++++++++++++++
 tests/qemuxml2argvdata/cpu-tsc-frequency.args |  4 +--
 tests/qemuxml2argvtest.c                      |  1 +
 6 files changed, 79 insertions(+), 3 deletions(-)
 create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.args
 create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.xml

-- 
2.17.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, Apr 25, 2019 at 2:50 PM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> Hi,
> this series tries to address a drop of commandline options by qemu in regard to
> osxsave [1] and ospke [2].
> This was already discussed in [3] late last year but got forgotten afterwards.
> The Ubuntu bug is at [4] and an older Fedora bug is at [5].
>
> TL;DR:
> - osxsave/ospke features were never really configurable
> - KVM never returned the bits on GET_SUPPORTED_CPUID
> - very rare to be seen in the wild
> - avoid issues with newer qemu and old/odd XMLs to be sure

Hi,
I know we are in a freeze, but we if one has time to review that would
be great to be ready when 5.4 opens.
But since 8 days passed I thought I could ping here to be seen (again).

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 4/25/19 9:50 AM, Christian Ehrhardt wrote:
> Hi,
> this series tries to address a drop of commandline options by qemu in regard to
> osxsave [1] and ospke [2].
> This was already discussed in [3] late last year but got forgotten afterwards.
> The Ubuntu bug is at [4] and an older Fedora bug is at [5].
>
> TL;DR:
> - osxsave/ospke features were never really configurable
> - KVM never returned the bits on GET_SUPPORTED_CPUID
> - very rare to be seen in the wild
> - avoid issues with newer qemu and old/odd XMLs to be sure
>
> Details:
>
> I checked various use cases from virt-install to openstack and some in between.
> The only cases I found that would define osxsave/ospke is virt-install pior
> to version 2.0 and even there only when used with --cpu=host-model or
> --cpu=host-copy.
> If you ever really enabled the feature you'd have got:
>    error: the CPU is incompatible with host CPU:
>    Host CPU does not provide required features: ospke
>
> The problem lies in domain XMLs that explicitly disable it. That would be
>      <feature policy='disable' name='osxsave'/>
> But due to almost (or actually none) no host exposing this the following
> also triggers:
>      <feature policy='optional' name='ospke'/>

So,  it happened that this notebook (ThinkPad T480) has the feature you're
handling in this patch series:


[danielhb@rekt libvirt]$ sudo ./run tools/virsh capabilities
[sudo] password for danielhb:
<capabilities>

   <host>
     <uuid>985fc2cc-23a6-11b2-a85c-a1357d626e56</uuid>
     <cpu>
       <arch>x86_64</arch>
       <model>Skylake-Client-IBRS</model>
       <vendor>Intel</vendor>
       <microcode version='150'/>
       <topology sockets='1' cores='4' threads='2'/>
(...)
       <feature name='pdcm'/>
       <feature name='osxsave'/>

(...)


With your approach, what happens is that a feature that is declared to be
effective in the capabilities is, in fact, ignored. It is an upgrade of 
what would
happen without it, of course.

But I am wondering here, fully aware that you mentioned that you wanted this
discussion to be avoided, that we should simply exterminate both osxsave and
ospke from Libvirt capabilities. I mean, what's the point of even 
reporting them
if they will end up being ignored? You have both QEMU commits [1] and [2]
mentioning that these flags were never configurable in the first place, 
so it's not
like we need to keep them for backward compatibility either.

Note that this does not discard this patch series - I think we'll need a 
solution
like this to deal with older VMs that define these features in their XMLs.


Thanks,


DHB


>
> This will make libvirt add it to the qemu commandline like:
>    -cpu ...,osxsave=off,ospke=off
>
> And that will crash when qemu starts with:
>    error: internal error: process exited while connecting to monitor:
>    2019-04-25T12:12:01.698646Z qemu-system-x86_64: can't apply global
>    core2duo-x86_64-cpu.osxsave=off: Property '.osxsave' not found
>
> There are much more long term discussions about demoting and dropping qemu
> features and I'd like to avoid those discussions being mixed.
> The reason to drop it more or less without notice was that it never did
> anything to begin with. Due to that our solution might in a similar fashion
> be more trivial - just stop defining those two features to qemu commandline.
>
> [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7
> [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc
> [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg561877.html
> [4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195
> [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848
>
> Christian Ehrhardt (2):
>    qemu: do not define known no-op features
>    qemuxml2argvtest: add test for remove cpu features
>
>   src/qemu/qemu_command.c                       | 23 +++++++++++++++
>   .../qemuxml2argvdata/cpu-host-model-cmt.args  |  2 +-
>   .../cpu-no-removed-features.args              | 29 +++++++++++++++++++
>   .../cpu-no-removed-features.xml               | 23 +++++++++++++++
>   tests/qemuxml2argvdata/cpu-tsc-frequency.args |  4 +--
>   tests/qemuxml2argvtest.c                      |  1 +
>   6 files changed, 79 insertions(+), 3 deletions(-)
>   create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.args
>   create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.xml
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Tue, May 7, 2019 at 11:03 PM Daniel Henrique Barboza
<danielhb413@gmail.com> wrote:
>
>
>
> On 4/25/19 9:50 AM, Christian Ehrhardt wrote:
> > Hi,
> > this series tries to address a drop of commandline options by qemu in regard to
> > osxsave [1] and ospke [2].
> > This was already discussed in [3] late last year but got forgotten afterwards.
> > The Ubuntu bug is at [4] and an older Fedora bug is at [5].
> >
> > TL;DR:
> > - osxsave/ospke features were never really configurable
> > - KVM never returned the bits on GET_SUPPORTED_CPUID
> > - very rare to be seen in the wild
> > - avoid issues with newer qemu and old/odd XMLs to be sure
> >
> > Details:
> >
> > I checked various use cases from virt-install to openstack and some in between.
> > The only cases I found that would define osxsave/ospke is virt-install pior
> > to version 2.0 and even there only when used with --cpu=host-model or
> > --cpu=host-copy.
> > If you ever really enabled the feature you'd have got:
> >    error: the CPU is incompatible with host CPU:
> >    Host CPU does not provide required features: ospke
> >
> > The problem lies in domain XMLs that explicitly disable it. That would be
> >      <feature policy='disable' name='osxsave'/>
> > But due to almost (or actually none) no host exposing this the following
> > also triggers:
> >      <feature policy='optional' name='ospke'/>
>
> So,  it happened that this notebook (ThinkPad T480) has the feature you're
> handling in this patch series:

Mine as well actually, but obviously only on the host capabilities.

[...]

>
> With your approach, what happens is that a feature that is declared to be
> effective in the capabilities is, in fact, ignored. It is an upgrade of
> what would happen without it, of course.

Some bikeshedding on "declared to be effective in the capabilities"
needed to bring me up to date on this.
See below...

> But I am wondering here, fully aware that you mentioned that you wanted this
> discussion to be avoided,

Sorry my comment was misleading then - I'm absolutely fine having that
part of the discussion in this context.
I only wanted to avoid the discussion about removing features that
"actually did something" which naturally is a way more complex topic.

> that we should simply exterminate both osxsave and
> ospke from Libvirt capabilities. I mean, what's the point of even
> reporting them
> if they will end up being ignored? You have both QEMU commits [1] and [2]
> mentioning that these flags were never configurable in the first place,
> so it's not
> like we need to keep them for backward compatibility either.

Maybe it is my current lack of understanding how "exterminating both"
would be exactly done and I see potential issues where there are none.
I wonder would that just be dropping the mappings in
src/cpu_map/x86_features.xml?
If not then I'd appreciate a hint where exactly you'd suggest we would
do the mentioned further extermination of ospke/osxsave.

I was afraid of side effects or when no more being detected.
And even more so it seems the definition of "capabilities" is not
clear enough to me (I never thought too much about it so far):
- "The capabilities of the hypervisor" (man page)
- "The host CPU architecture and features." (web page)

For the former definition yes, we might want to drop such non passable
features then.

But for the latter definition it feels right to continue reporting
that the host has it.
It is valid to report that the host has the feature - even thou it
can't pass it to a guest.
After all it is in the host and not the guest (hypervisor dependent)
section of capabilities right?

Also we might (later) use the mapping for other things down the road
where being an tunable feature (or not) is not important either.
Or users compare hosts with same hardware but different libvirt
versions and wonder why they lost a cpu feature.

>
> Note that this does not discard this patch series - I think we'll need a
> solution
> like this to deal with older VMs that define these features in their XMLs.
>
>
> Thanks,
>
>
> DHB
>
>
> >
> > This will make libvirt add it to the qemu commandline like:
> >    -cpu ...,osxsave=off,ospke=off
> >
> > And that will crash when qemu starts with:
> >    error: internal error: process exited while connecting to monitor:
> >    2019-04-25T12:12:01.698646Z qemu-system-x86_64: can't apply global
> >    core2duo-x86_64-cpu.osxsave=off: Property '.osxsave' not found
> >
> > There are much more long term discussions about demoting and dropping qemu
> > features and I'd like to avoid those discussions being mixed.
> > The reason to drop it more or less without notice was that it never did
> > anything to begin with. Due to that our solution might in a similar fashion
> > be more trivial - just stop defining those two features to qemu commandline.
> >
> > [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7
> > [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc
> > [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg561877.html
> > [4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195
> > [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848
> >
> > Christian Ehrhardt (2):
> >    qemu: do not define known no-op features
> >    qemuxml2argvtest: add test for remove cpu features
> >
> >   src/qemu/qemu_command.c                       | 23 +++++++++++++++
> >   .../qemuxml2argvdata/cpu-host-model-cmt.args  |  2 +-
> >   .../cpu-no-removed-features.args              | 29 +++++++++++++++++++
> >   .../cpu-no-removed-features.xml               | 23 +++++++++++++++
> >   tests/qemuxml2argvdata/cpu-tsc-frequency.args |  4 +--
> >   tests/qemuxml2argvtest.c                      |  1 +
> >   6 files changed, 79 insertions(+), 3 deletions(-)
> >   create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.args
> >   create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.xml
> >
>


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 5/9/19 6:31 AM, Christian Ehrhardt wrote:
> On Tue, May 7, 2019 at 11:03 PM Daniel Henrique Barboza
> <danielhb413@gmail.com> wrote:
>>
>>
>> On 4/25/19 9:50 AM, Christian Ehrhardt wrote:
>>> Hi,
>>> this series tries to address a drop of commandline options by qemu in regard to
>>> osxsave [1] and ospke [2].
>>> This was already discussed in [3] late last year but got forgotten afterwards.
>>> The Ubuntu bug is at [4] and an older Fedora bug is at [5].
>>>
>>> TL;DR:
>>> - osxsave/ospke features were never really configurable
>>> - KVM never returned the bits on GET_SUPPORTED_CPUID
>>> - very rare to be seen in the wild
>>> - avoid issues with newer qemu and old/odd XMLs to be sure
>>>
>>> Details:
>>>
>>> I checked various use cases from virt-install to openstack and some in between.
>>> The only cases I found that would define osxsave/ospke is virt-install pior
>>> to version 2.0 and even there only when used with --cpu=host-model or
>>> --cpu=host-copy.
>>> If you ever really enabled the feature you'd have got:
>>>     error: the CPU is incompatible with host CPU:
>>>     Host CPU does not provide required features: ospke
>>>
>>> The problem lies in domain XMLs that explicitly disable it. That would be
>>>       <feature policy='disable' name='osxsave'/>
>>> But due to almost (or actually none) no host exposing this the following
>>> also triggers:
>>>       <feature policy='optional' name='ospke'/>
>> So,  it happened that this notebook (ThinkPad T480) has the feature you're
>> handling in this patch series:
> Mine as well actually, but obviously only on the host capabilities.
>
> [...]

And that changes everything I said in my previous email ... not only
I messed up checking for <host> instead of <guest> capabilities, but
also I could've checked "domcapabilities". In the docs:


"While the Driver Capabilities provides the host capabilities (...),
the Domain Capabilities provides the hypervisor specific capabilities
for Management Applications to query and make decisions regarding
what to utilize."

Thus, it doesn't matter if osxsave is being reported in the host 
capabilities.
What matters if whether osxsave is declared in the domcapabilities (or the
<guest> element in capabilities) - which would mean that guests can utilize
it.

I apologize for this confusion.


>> With your approach, what happens is that a feature that is declared to be
>> effective in the capabilities is, in fact, ignored. It is an upgrade of
>> what would happen without it, of course.
> Some bikeshedding on "declared to be effective in the capabilities"
> needed to bring me up to date on this.
> See below...
>
>> But I am wondering here, fully aware that you mentioned that you wanted this
>> discussion to be avoided,
> Sorry my comment was misleading then - I'm absolutely fine having that
> part of the discussion in this context.
> I only wanted to avoid the discussion about removing features that
> "actually did something" which naturally is a way more complex topic.
>
>> that we should simply exterminate both osxsave and
>> ospke from Libvirt capabilities. I mean, what's the point of even
>> reporting them
>> if they will end up being ignored? You have both QEMU commits [1] and [2]
>> mentioning that these flags were never configurable in the first place,
>> so it's not
>> like we need to keep them for backward compatibility either.
> Maybe it is my current lack of understanding how "exterminating both"
> would be exactly done and I see potential issues where there are none.
> I wonder would that just be dropping the mappings in
> src/cpu_map/x86_features.xml?
> If not then I'd appreciate a hint where exactly you'd suggest we would
> do the mentioned further extermination of ospke/osxsave.
>
> I was afraid of side effects or when no more being detected.
> And even more so it seems the definition of "capabilities" is not
> clear enough to me (I never thought too much about it so far):
> - "The capabilities of the hypervisor" (man page)
> - "The host CPU architecture and features." (web page)
>
> For the former definition yes, we might want to drop such non passable
> features then.
>
> But for the latter definition it feels right to continue reporting
> that the host has it.
> It is valid to report that the host has the feature - even thou it
> can't pass it to a guest.
> After all it is in the host and not the guest (hypervisor dependent)
> section of capabilities right?

Yes, I agree.




>
> Also we might (later) use the mapping for other things down the road
> where being an tunable feature (or not) is not important either.
> Or users compare hosts with same hardware but different libvirt
> versions and wonder why they lost a cpu feature.
>
>> Note that this does not discard this patch series - I think we'll need a
>> solution
>> like this to deal with older VMs that define these features in their XMLs.
>>
>>
>> Thanks,
>>
>>
>> DHB
>>
>>
>>> This will make libvirt add it to the qemu commandline like:
>>>     -cpu ...,osxsave=off,ospke=off
>>>
>>> And that will crash when qemu starts with:
>>>     error: internal error: process exited while connecting to monitor:
>>>     2019-04-25T12:12:01.698646Z qemu-system-x86_64: can't apply global
>>>     core2duo-x86_64-cpu.osxsave=off: Property '.osxsave' not found
>>>
>>> There are much more long term discussions about demoting and dropping qemu
>>> features and I'd like to avoid those discussions being mixed.
>>> The reason to drop it more or less without notice was that it never did
>>> anything to begin with. Due to that our solution might in a similar fashion
>>> be more trivial - just stop defining those two features to qemu commandline.
>>>
>>> [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7
>>> [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc
>>> [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg561877.html
>>> [4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195
>>> [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848
>>>
>>> Christian Ehrhardt (2):
>>>     qemu: do not define known no-op features
>>>     qemuxml2argvtest: add test for remove cpu features
>>>
>>>    src/qemu/qemu_command.c                       | 23 +++++++++++++++
>>>    .../qemuxml2argvdata/cpu-host-model-cmt.args  |  2 +-
>>>    .../cpu-no-removed-features.args              | 29 +++++++++++++++++++
>>>    .../cpu-no-removed-features.xml               | 23 +++++++++++++++
>>>    tests/qemuxml2argvdata/cpu-tsc-frequency.args |  4 +--
>>>    tests/qemuxml2argvtest.c                      |  1 +
>>>    6 files changed, 79 insertions(+), 3 deletions(-)
>>>    create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.args
>>>    create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.xml
>>>
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

This is a VM with 'osxsave' capability declared, when there is no
'osxsave' guest support, using this series on top of current master:


$ sudo ./run tools/virsh start ub1810-osxsave
error: Failed to start domain ub1810-osxsave
error: internal error: process exited while connecting to monitor: 
2019-05-09T17:10:41.077568Z qemu-system-x86_64: can't apply global 
Skylake-Client-IBRS-x86_64-cpu.osxsave=off: Property '.osxsave' not found


Applying this series makes the VM boot up, as intended.

I believe there is room for discussion whether the VM should boot
up or fail to boot with a "feature not found" error like the case below,
in a sense of "you can't disable a feature that does not exist":

<feature policy='disable' name='not_a_cap'/>

$ sudo ./run tools/virsh start ub1810-unknown-cap
error: Failed to start domain ub1810-unknown-cap
error: unsupported configuration: unknown CPU feature: not_a_cap

But the alternative presented in this series does the trick and it's
less annoying for existing VMs.


For all the patch series:


Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>



On 4/25/19 9:50 AM, Christian Ehrhardt wrote:
> Hi,
> this series tries to address a drop of commandline options by qemu in regard to
> osxsave [1] and ospke [2].
> This was already discussed in [3] late last year but got forgotten afterwards.
> The Ubuntu bug is at [4] and an older Fedora bug is at [5].
>
> TL;DR:
> - osxsave/ospke features were never really configurable
> - KVM never returned the bits on GET_SUPPORTED_CPUID
> - very rare to be seen in the wild
> - avoid issues with newer qemu and old/odd XMLs to be sure
>
> Details:
>
> I checked various use cases from virt-install to openstack and some in between.
> The only cases I found that would define osxsave/ospke is virt-install pior
> to version 2.0 and even there only when used with --cpu=host-model or
> --cpu=host-copy.
> If you ever really enabled the feature you'd have got:
>    error: the CPU is incompatible with host CPU:
>    Host CPU does not provide required features: ospke
>
> The problem lies in domain XMLs that explicitly disable it. That would be
>      <feature policy='disable' name='osxsave'/>
> But due to almost (or actually none) no host exposing this the following
> also triggers:
>      <feature policy='optional' name='ospke'/>
>
> This will make libvirt add it to the qemu commandline like:
>    -cpu ...,osxsave=off,ospke=off
>
> And that will crash when qemu starts with:
>    error: internal error: process exited while connecting to monitor:
>    2019-04-25T12:12:01.698646Z qemu-system-x86_64: can't apply global
>    core2duo-x86_64-cpu.osxsave=off: Property '.osxsave' not found
>
> There are much more long term discussions about demoting and dropping qemu
> features and I'd like to avoid those discussions being mixed.
> The reason to drop it more or less without notice was that it never did
> anything to begin with. Due to that our solution might in a similar fashion
> be more trivial - just stop defining those two features to qemu commandline.
>
> [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7
> [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc
> [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg561877.html
> [4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195
> [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848
>
> Christian Ehrhardt (2):
>    qemu: do not define known no-op features
>    qemuxml2argvtest: add test for remove cpu features
>
>   src/qemu/qemu_command.c                       | 23 +++++++++++++++
>   .../qemuxml2argvdata/cpu-host-model-cmt.args  |  2 +-
>   .../cpu-no-removed-features.args              | 29 +++++++++++++++++++
>   .../cpu-no-removed-features.xml               | 23 +++++++++++++++
>   tests/qemuxml2argvdata/cpu-tsc-frequency.args |  4 +--
>   tests/qemuxml2argvtest.c                      |  1 +
>   6 files changed, 79 insertions(+), 3 deletions(-)
>   create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.args
>   create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.xml
>

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, May 9, 2019 at 7:43 PM Daniel Henrique Barboza
<danielhb413@gmail.com> wrote:
>
> This is a VM with 'osxsave' capability declared, when there is no
> 'osxsave' guest support, using this series on top of current master:
>
>
> $ sudo ./run tools/virsh start ub1810-osxsave
> error: Failed to start domain ub1810-osxsave
> error: internal error: process exited while connecting to monitor: 2019-05-09T17:10:41.077568Z qemu-system-x86_64: can't apply global Skylake-Client-IBRS-x86_64-cpu.osxsave=off: Property '.osxsave' not found
>
>
> Applying this series makes the VM boot up, as intended.
>
> I believe there is room for discussion whether the VM should boot
> up or fail to boot with a "feature not found" error like the case below,
> in a sense of "you can't disable a feature that does not exist":
>
> <feature policy='disable' name='not_a_cap'/>
>
> $ sudo ./run tools/virsh start ub1810-unknown-cap
> error: Failed to start domain ub1810-unknown-cap
> error: unsupported configuration: unknown CPU feature: not_a_cap
>
> But the alternative presented in this series does the trick and it's
> less annoying for existing VMs.
>
>
> For all the patch series:
>
>
> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>

Thank you so much Daniel!

Anyone else to chime in?
Otherwise, having review and a test not done by me, I feel complete
and would I'd like to push this later this week.

>
> On 4/25/19 9:50 AM, Christian Ehrhardt wrote:
>
> Hi,
> this series tries to address a drop of commandline options by qemu in regard to
> osxsave [1] and ospke [2].
> This was already discussed in [3] late last year but got forgotten afterwards.
> The Ubuntu bug is at [4] and an older Fedora bug is at [5].
>
> TL;DR:
> - osxsave/ospke features were never really configurable
> - KVM never returned the bits on GET_SUPPORTED_CPUID
> - very rare to be seen in the wild
> - avoid issues with newer qemu and old/odd XMLs to be sure
>
> Details:
>
> I checked various use cases from virt-install to openstack and some in between.
> The only cases I found that would define osxsave/ospke is virt-install pior
> to version 2.0 and even there only when used with --cpu=host-model or
> --cpu=host-copy.
> If you ever really enabled the feature you'd have got:
>   error: the CPU is incompatible with host CPU:
>   Host CPU does not provide required features: ospke
>
> The problem lies in domain XMLs that explicitly disable it. That would be
>     <feature policy='disable' name='osxsave'/>
> But due to almost (or actually none) no host exposing this the following
> also triggers:
>     <feature policy='optional' name='ospke'/>
>
> This will make libvirt add it to the qemu commandline like:
>   -cpu ...,osxsave=off,ospke=off
>
> And that will crash when qemu starts with:
>   error: internal error: process exited while connecting to monitor:
>   2019-04-25T12:12:01.698646Z qemu-system-x86_64: can't apply global
>   core2duo-x86_64-cpu.osxsave=off: Property '.osxsave' not found
>
> There are much more long term discussions about demoting and dropping qemu
> features and I'd like to avoid those discussions being mixed.
> The reason to drop it more or less without notice was that it never did
> anything to begin with. Due to that our solution might in a similar fashion
> be more trivial - just stop defining those two features to qemu commandline.
>
> [1]: https://git.qemu.org/?p=qemu.git;a=commit;h=f1a23522b03a569f13aad49294bb4c4b1a9500c7
> [2]: https://git.qemu.org/?p=qemu.git;a=commit;h=9ccb9784b57804f5c74434ad6ccb66650a015ffc
> [3]: https://www.mail-archive.com/qemu-devel@nongnu.org/msg561877.html
> [4]: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1825195
> [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1644848
>
> Christian Ehrhardt (2):
>   qemu: do not define known no-op features
>   qemuxml2argvtest: add test for remove cpu features
>
>  src/qemu/qemu_command.c                       | 23 +++++++++++++++
>  .../qemuxml2argvdata/cpu-host-model-cmt.args  |  2 +-
>  .../cpu-no-removed-features.args              | 29 +++++++++++++++++++
>  .../cpu-no-removed-features.xml               | 23 +++++++++++++++
>  tests/qemuxml2argvdata/cpu-tsc-frequency.args |  4 +--
>  tests/qemuxml2argvtest.c                      |  1 +
>  6 files changed, 79 insertions(+), 3 deletions(-)
>  create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.args
>  create mode 100644 tests/qemuxml2argvdata/cpu-no-removed-features.xml
>
>


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Mon, May 13, 2019 at 12:23 PM Christian Ehrhardt
<christian.ehrhardt@canonical.com> wrote:
>
> On Thu, May 9, 2019 at 7:43 PM Daniel Henrique Barboza
> <danielhb413@gmail.com> wrote:
> >
> > This is a VM with 'osxsave' capability declared, when there is no
> > 'osxsave' guest support, using this series on top of current master:
> >
> >
> > $ sudo ./run tools/virsh start ub1810-osxsave
> > error: Failed to start domain ub1810-osxsave
> > error: internal error: process exited while connecting to monitor: 2019-05-09T17:10:41.077568Z qemu-system-x86_64: can't apply global Skylake-Client-IBRS-x86_64-cpu.osxsave=off: Property '.osxsave' not found
> >
> >
> > Applying this series makes the VM boot up, as intended.
> >
> > I believe there is room for discussion whether the VM should boot
> > up or fail to boot with a "feature not found" error like the case below,
> > in a sense of "you can't disable a feature that does not exist":
> >
> > <feature policy='disable' name='not_a_cap'/>
> >
> > $ sudo ./run tools/virsh start ub1810-unknown-cap
> > error: Failed to start domain ub1810-unknown-cap
> > error: unsupported configuration: unknown CPU feature: not_a_cap
> >
> > But the alternative presented in this series does the trick and it's
> > less annoying for existing VMs.
> >
> >
> > For all the patch series:
> >
> >
> > Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> > Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com>
>
> Thank you so much Daniel!
>
> Anyone else to chime in?

Nothing else came up, I have rebased, rebuilt and retested to be sure
and then pushed to master.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list