[Bug dynamic-link/27201] New: Consider disabling x86-64-v2 support check

[Bug dynamic-link/27201] New: Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

            Bug ID: 27201
           Summary: Consider disabling x86-64-v2 support check
           Product: glibc
           Version: 2.33
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
  Target Milestone: ---
             Build: x86_64-*-linux-gnu
             Flags: security-

This is related to this upstream commit:



>From the mailing list:

commit ecce11aa0752735c4fd730da6e7c9e0b98e12fb8
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Oct 9 06:06:56 2020 -0700

    x86: Support GNU_PROPERTY_X86_ISA_1_V[234] marker [BZ #26717]

Specifically this check:

+      if ((l->l_x86_isa_1_needed & cpu_features->isa_1)
+         != l->l_x86_isa_1_needed)
+       {
+         if (program)
+           _dl_fatal_printf ("%s: CPU ISA level is lower than required\n",
+                             *l->l_name != '\0' ? l->l_name : program);
+         else
+           _dl_signal_error (0, l->l_name, "dlopen",
+                             N_("CPU ISA level is lower than required"));
+       }
+    }


> It turns out that libvirt defaults to the qemu64 model.  It masks most
> of the feature bits required by x86-64-v2.  Libvirt developers have
> previously told me that nothing should be using the qemu64 model, but
> it's still the default for API stability reasons (in the same way SSL 3
> and DES used to be the default in crypto libraries, under the assumption
> that if you negotiatied a particular protocol and set of algorithms in
> 1998, you'd still want the exact same choice fifteen years later).
>
> But of course, despite no one should be using the qemu64 model, they
> still do.  Here's an example:
>
>   Guest: fix to always use host-passthrough CPU for all arches
>   <https://github.com/clalancette/oz/pull/283>
>
> One pecularity about x86-64-v2 is that under KVM virtualization, the new
> structions added over the baseline do not actually trap (assuming the
> host supports them).  So we could paper over this integration issue by
> doing the check for x86-64-v3 and later only.  (Although it might not
> work there—I looked at printing a nice error message for the same
> situation when we transitioned to z13, but it it turned to be quite
> difficult.)
>
> Downstream, this would likely buy us about three years, in which we
> could fix qemu64-type problems.  But maybe we should tackle this now.
>
> I also hope to have a conversation about the libvirt developers
> regarding defaults, but I'm still trying to figure out the appropriate
> forum.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
If CPUID is unreliable in this case, can we detect it and use a different
approach to check CPU features for x86-64-vN? Can we use AT_HWCAP2 here?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
I tested KVM on Fedora 33/Westmere.  /proc/cpuinfo looks OK:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 44
model name      : Westmere E56xx/L56xx/X56xx (IBRS update)
stepping        : 1
microcode       : 0x1
cpu MHz         : 3333.292
cache size      : 16384 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush mmx fxsr sse sse2 syscall nx pdpe1gb rdtscp lm constant_tsc
re
p_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 cx16 pcid
sse
4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes hypervisor lahf_lm cpuid_fault
p
ti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid tsc_adjust arat
um
ip arch_capabilities

tst-isa-level-1.c works fine:

Breakpoint 1, do_test () at ../sysdeps/x86/tst-isa-level-1.c:63
63        const struct cpu_features *cpu_features
(gdb) next
65        unsigned int isa_level = get_isa_level (cpu_features);
(gdb) 
81        do_test_1 ("tst-isa-level-mod-1-baseline.so", false);
(gdb) 
87        do_test_1 ("tst-isa-level-mod-1-v4.so", true);
(gdb) 
93        do_test_1 ("tst-isa-level-mod-1-v3.so", true);
(gdb) 
96        if (has_isa_v2)
(gdb) 
78            return EXIT_SUCCESS;
(gdb)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

--- Comment #3 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to H.J. Lu from comment #2)
> model name	: Westmere E56xx/L56xx/X56xx (IBRS update)

This is not the qemu64 device model.

To be clear here, everything is consistent on the QEMU side, and CPUID is
working as expected.

But before the level check was added, it was possible to run x86-64-v2 binaries
in a qemu64 guest if the host supported x86-64-v2 because CPUID masking does
not cause the instructions to trap. With the level check, the last part
obviously does not change, but we refuse to run anything at all nevertheless.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Florian Weimer from comment #3)
> (In reply to H.J. Lu from comment #2)
> > model name	: Westmere E56xx/L56xx/X56xx (IBRS update)
> 
> This is not the qemu64 device model.

I use virt-manager to manage VM. I didn't change the default.  How do I
enable the qemu64 device model?

> To be clear here, everything is consistent on the QEMU side, and CPUID is
> working as expected.
> 
> But before the level check was added, it was possible to run x86-64-v2
> binaries in a qemu64 guest if the host supported x86-64-v2 because CPUID
> masking does not cause the instructions to trap. With the level check, the
> last part obviously does not change, but we refuse to run anything at all
> nevertheless.

How can I produce it on Fedora 33/Westmere?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #4)
> (In reply to Florian Weimer from comment #3)
> > (In reply to H.J. Lu from comment #2)
> > > model name	: Westmere E56xx/L56xx/X56xx (IBRS update)
> > 
> > This is not the qemu64 device model.
> 
> I use virt-manager to manage VM. I didn't change the default.  How do I
> enable the qemu64 device model?
> 

virt-manager defaults to "Copy host CPU configuration".  On
Westmere, when I selected the qemu64 device model, I couldn't
even power on the VM since my host CPU isn't compatible with
qemu64 due to the missing SVM feature.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to H.J. Lu from comment #5)
> 
> virt-manager defaults to "Copy host CPU configuration".  On
> Westmere, when I selected the qemu64 device model, I couldn't
> even power on the VM since my host CPU isn't compatible with
> qemu64 due to the missing SVM feature.

Since Intel CPUs don't have SVM and the qemu64 device model requires
SVM, how can libvirt default to the qemu64 model?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #7 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to H.J. Lu from comment #5)
> (In reply to H.J. Lu from comment #4)
> > (In reply to Florian Weimer from comment #3)
> > > (In reply to H.J. Lu from comment #2)
> > > > model name	: Westmere E56xx/L56xx/X56xx (IBRS update)
> > > 
> > > This is not the qemu64 device model.
> > 
> > I use virt-manager to manage VM. I didn't change the default.  How do I
> > enable the qemu64 device model?
> > 
> 
> virt-manager defaults to "Copy host CPU configuration".  On
> Westmere, when I selected the qemu64 device model, I couldn't
> even power on the VM since my host CPU isn't compatible with
> qemu64 due to the missing SVM feature.

It works for me (on a CPU without SVM). I encountered a virt-manager UI issue
which would not allow me to change the CPU model.

It's possible to use virsh, its edit comment, and remove the XML elements
related to the CPU model, cpu and features. Once you do that, libvirt will tell
QEMU to switch to the qemu64 model, and it shows up as such in virt-manager as
well.

Note that the Fedora 32 graphical boot does not work because llvmpipe generates
VEX instructions (for XMM registers though). That's an unrelated issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Florian Weimer from comment #7)
> 
> It works for me (on a CPU without SVM). I encountered a virt-manager UI
> issue which would not allow me to change the CPU model.
> 
> It's possible to use virsh, its edit comment, and remove the XML elements
> related to the CPU model, cpu and features. Once you do that, libvirt will
> tell QEMU to switch to the qemu64 model, and it shows up as such in
> virt-manager as well.

Given that virt-manager works fine by default and I don't know how to enable
the qemu64 model under virt-manager, I can't tell how serious this issue is.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
I don't think qemu64 works well on Intel CPU:

https://github.com/vagrant-libvirt/vagrant-libvirt/issues/667
https://forums.unraid.net/topic/90086-emulated-qemu64-cpu-not-working/

I highly doubt that qemu64 is the default.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to H.J. Lu from comment #8)
> Given that virt-manager works fine by default and I don't know how to enable
> the qemu64 model under virt-manager, I can't tell how serious this issue is.

libvirt isn't just used via virt-manager.  Generating your own XML is
explicitly supported as an important use case, but it leads to issues like this
one:

   Guest: fix to always use host-passthrough CPU for all arches
   <https://github.com/clalancette/oz/pull/283>

I can see this behavior on a Fedora 33 host with a Fedora 32 guest if I use the
“edit” command under “virsh” and remove the <cpu> and <features>.  It is
important to use “virsh” to make the change, and not edit the files on disk.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #11 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Florian Weimer from comment #10)
> (In reply to H.J. Lu from comment #8)
> > Given that virt-manager works fine by default and I don't know how to enable
> > the qemu64 model under virt-manager, I can't tell how serious this issue is.
> 
> libvirt isn't just used via virt-manager.  Generating your own XML is
> explicitly supported as an important use case, but it leads to issues like
> this one:
> 
>    Guest: fix to always use host-passthrough CPU for all arches
>    <https://github.com/clalancette/oz/pull/283>
> 
> I can see this behavior on a Fedora 33 host with a Fedora 32 guest if I use
> the “edit” command under “virsh” and remove the <cpu> and <features>.  It is
> important to use “virsh” to make the change, and not edit the files on disk.

Please show me the command-line how to do it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.redhat.com
                   |                            |/show_bug.cgi?id=1598162
             Status|NEW                         |WAITING

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
This is related to

https://bugzilla.redhat.com/show_bug.cgi?id=1598162

I believe there is no issue here unless I can reproduce it myself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[berrange at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

Daniel Berrange <berrange at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |berrange at redhat dot com

--- Comment #13 from Daniel Berrange <berrange at redhat dot com> ---
(In reply to H.J. Lu from comment #6)
> (In reply to H.J. Lu from comment #5)
> > 
> > virt-manager defaults to "Copy host CPU configuration".  On
> > Westmere, when I selected the qemu64 device model, I couldn't
> > even power on the VM since my host CPU isn't compatible with
> > qemu64 due to the missing SVM feature.
> 
> Since Intel CPUs don't have SVM and the qemu64 device model requires
> SVM, how can libvirt default to the qemu64 model?

There's some subtle behavioural things going on here as there's two different
ways qemu64 can get used.

In the libvirt XML config, if *no* <cpu> element is present at all, then QEMU's
built-in default "qemu64" model is used.   When it does this, it operates in a
relaxed mode where any features in qemu64 that don't exist in the host and
dropped from the CPU exposed to the guest. IIRC, there is a message in
/var/log/libvirt/qemu/$GUEST.log for each feature that is dropped in this way.
In this mode you can use qemu64 on an Intel host and "svm" will be dropped. I
don't believe you can configure this way in virt-manager, as it tries hard to
ensure you always have an explicit CPU specified to follow best practice. If
you want to test it use 'virsh edit $GUEST' to manually delete the <cpu>

Conversely if you specify a <cpu mode='custom''><model>qemu64</model></cpu>,
then it will operate in strict mode, where QEMU will refuse to start the guest
if the host lacks features. In this mode you can NOT use qemu64 on a Intel host
because 'svm' doesn't exist.

Yes, this is confusing, but we have to maintain the historical behaviour for
upgrade / live migration compatibility.

Well maintained applications will *always* specify a <cpu> in libvirt and pick
a sane modern model.  If live migration is not required, then using simple
host-passthrough is simplest. If live migration is required, then a named model
that matches your host CPU generation is best (Westmere, IvyBridge, Nehalm,
Broadwell, etc).  This is described

https://qemu.readthedocs.io/en/latest/system/target-i386.html#recommendations-for-kvm-cpu-model-configuration-on-x86-hosts

All widely used libvirt apps that are actively maintained by their upstream,
should be doing the thing thing in this area. oVirt, OpenStack, virt-manager,
virt-install, GNOME Boxes, Cockpit all do the right thing. Unfortunately the
'oz' program that Florian mentions is barely maintained and not following
recommendations, thus hitting the problem due to its reliance on the builtin
defualt.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> ---
I need to see the issue on Fedora 33 myself to find a solution.  So far
I can't set qemu64 on Fedora 33.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[berrange at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #15 from Daniel Berrange <berrange at redhat dot com> ---
(In reply to H.J. Lu from comment #14)
> I need to see the issue on Fedora 33 myself to find a solution.  So far
> I can't set qemu64 on Fedora 33.

Try to just use 'virsh edit $GUESTNAME' (as root) and remove the <cpu>
...</cpu> element entirely, and that'll cause QEMU to use the built-in default.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Daniel Berrange from comment #15)
> (In reply to H.J. Lu from comment #14)
> > I need to see the issue on Fedora 33 myself to find a solution.  So far
> > I can't set qemu64 on Fedora 33.
> 
> Try to just use 'virsh edit $GUESTNAME' (as root) and remove the <cpu>
> ...</cpu> element entirely, and that'll cause QEMU to use the built-in
> default.

I am using virt-manager.  How does virsh work with virt-manager?

[hjl@gnu-skl-1 ~]$ virsh list
 Id   Name   State
--------------------

[hjl@gnu-skl-1 ~]$

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #17 from Florian Weimer <fweimer at redhat dot com> ---
For me, virt-manager defaults to use the system's libvirt instance, so I have
to use this to actually see the VM:

$ sudo sudo virsh list --all

Furthermore, the list command only shows running VMs, so you need the --all
argument.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #18 from H.J. Lu <hjl.tools at gmail dot com> ---
I managed to do it. I got

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 6
model name      : QEMU Virtual CPU version 2.5+
stepping        : 3
microcode       : 0x1
cpu MHz         : 3407.984
cache size      : 16384 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl xtopology cpuid
tsc_known_freq pni cx16 x2apic hypervisor lahf_lm cpuid_fault pti
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds
swapgs itlb_multihit
bogomips        : 6815.96
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

on Skylake.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
I need to add

export LIBVIRT_DEFAULT_URI=qemu:///system

to ~/.zshenv.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #20 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to H.J. Lu from comment #18)
> flags		: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pse36
> clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl xtopology cpuid
> tsc_known_freq pni cx16 x2apic hypervisor lahf_lm cpuid_fault pti
> bugs		: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs

Those look like as expected. Now install glibc from here:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1669316

It has the x86-64-v2 check and won't boot.

This earlier build requires x86-64-v2 as well (due to its build flags), but
will run because the x86-64-v2 instructions do not trap:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1666794

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |hjl.tools at gmail dot com
   Target Milestone|---                         |2.33

--- Comment #21 from H.J. Lu <hjl.tools at gmail dot com> ---
I am working on it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[hjl.tools at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #22 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 13142
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13142&action=edit
A patch

Add a configure option, --enable-qemu-isa-level=LEVEL, to specify the
minimum ISA level for QEMU.  Does it look reasonable?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[berrange at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #23 from Daniel Berrange <berrange at redhat dot com> ---
Matching on this "QEMU Virtual CPU" model name exposed to the guest is not a
good idea. This only matches the qemu32/qemu64 models, which are just two out
of many QEMU CPU models. In addition any model QEMU exposes can be tailored by
the user to disable arbitrary features that were otherwise built-in. eg $QEMU
-cpu Westmere,aes=off,sse4.1=off.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #24 from Florian Weimer <fweimer at redhat dot com> ---
I think only x86-64-v2 is special that the hypervisor and kernel cannot disable
support if the CPU implements it.  x86-64-v3 needs OSXSAVE, so the hack will
not work for it because the kernel does not provide it for the qemu64 model.

What I'm looking for right now is a way to get a working x86-64-v2 machine
model out of libvirt, without teaching libvirt clients about Intel vs AMD CPU
differences, or the precise definition of x86-64-v2. Maybe we should just
recommend the use of host-passthrough for all local use cases (i.e. not
involving live migration).  Supporting live migration will be more difficult.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[berrange at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #25 from Daniel Berrange <berrange at redhat dot com> ---
One thing that occurred to me is that QEMU could explore the idea of using of
its CPU model versioning to define a new version 'qemu64-v2' that includes a
more useful modern baseline of feature bits.

There is also a QEMU concept called machine types, which encode a particular
machine ABI. Machine types are versioned too, so when you provision a VM, it is
set use the newest machine type version available at that point in time and
never changes thereafter.  Machine types can associate with CPU versions, to
express what version 'qemu64' will expand to. 

IOW, it ought to be possible to make future machine types from QEMU to
reference the qemu64-v2 CPU model instead of the qemu64-v1 model. One that is
done existing deployed VMs will still be using qem64-v1, but newly deployed VMs
would pick up qemu64-v2. If we can achieve this, it should not involve any
changes to mgmt apps.

The devil is in the detail, but I think it is worth exploring as an option.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

--- Comment #26 from Florian Weimer <fweimer at redhat dot com> ---
Should we move this discussion to a different forum?

As I said, any glibc hack we put it in will likely not work for x86-64-v3, so
I'm not sure if it is worthwhile to have it just for x86-64-v2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug dynamic-link/27201] Consider disabling x86-64-v2 support check

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27201

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #27 from Florian Weimer <fweimer at redhat dot com> ---
I think this idea is not helpful because it does not seem to apply to TCG. It
won't leak the host capabilities in the way KVM does, so the diagnostic is
actually required there.

-- 
You are receiving this mail because:
You are on the CC list for the bug.