On Tue, Dec 16, 2014 at 12:40:26PM +0000, Daniel P. Berrange wrote:
> On Tue, Dec 16, 2014 at 01:33:15PM +0100, Guido Günther wrote:
> > The intel-microcode 3.20140913.1 update disables TSX-NI (transactional
> > memory instructions). When a server running libvirt is rebooted with
> > this update, libvirt no longer considers the machine to have a Haswell
> > CPU:
> >
> > # virsh capabilities | grep -A1 '<arch>x86_64'
> > <arch>x86_64</arch>
> > <model>SandyBridge</model>
> >
> > Since Intel disables the feature on their CPUs we shouldn't check for it
> > as well to keep VMs using Haswell working.
> >
> > This was debugged and reported by Chris Boot at
> >
http://bugs.debian.org/773189
> > ---
> > src/cpu/cpu_map.xml | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml
> > index bd9b056..f41dbce 100644
> > --- a/src/cpu/cpu_map.xml
> > +++ b/src/cpu/cpu_map.xml
> > @@ -507,7 +507,6 @@
> > <feature name='movbe'/>
> > <feature name='fsgsbase'/>
> > <feature name='bmi1'/>
> > - <feature name='hle'/>
> > <feature name='avx2'/>
> > <feature name='smep'/>
> > <feature name='bmi2'/>
>
> NACK. We can not change existing models in cpu_map.xml because that
> results in a guest ABI change.
But Intel changed the ABI as well by removing hle so what would we do
to move forward? Introduce another model? This would still break
systems with the microcode update.
Simply do nothing. There is no requirement that guest CPU model names
match the host CPU you are running on. A guest CPU model name is simply
a synonym for a collection of features. If libvirt reports 'SandyBridge'
for the host CPU model, when it is in fact 'Hasmere' that's not a serious
problem, because the key fact is that the feature bits are correctly
detected regardless of what name is reported.
Regards,
Daniel
--
|: