On Mon, Dec 15, 2014 at 06:56:19PM +0100, intrigeri wrote:
> hi,
> 
> Chris Boot wrote (15 Dec 2014 12:39:52 GMT) :
> > 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:
> 
> > dietrich ~ # virsh capabilities | grep -A1 '<arch>x86_64'
> >       <arch>x86_64</arch>
> >       <model>SandyBridge</model>
> 
> > This causes a problem as any VMs that require a Haswell CPU, which would
> > have worked previously, now fail to start altogether. Commenting out the
> > two cpuinfo flags relevant to TSX-NI from /usr/share/libvirt/cpu_map.xml
> > fixes this for me:
> 
> FWIW, I've been suffering from the symptoms of that issue for a few
> weeks. I guessed it was caused by that microcode update, but had no
> time to report it. *If* that's a regression since Wheezy, I think
> it would qualify as RC, since VMs that started just fine previously
> now fail to come up at boot. The workaround (in the package) is tiny,
> and makes sense to me: if Intel themselves now consider that Haswell
> CPUs have no TSX-NI, then libvirt's view of what's a Haswell CPU
> should be updated.
> 
> OTOH, the user-side workaround (copy host CPU model) is easy enough
> too, although a bit painful to discover initially for many users
> I guess.
> 
> Shall we ask the release team if they would happily unblock this
> change for Jessie?

I think we should. I've submitted it upstream to get some feadback and
make this a safe change and thanks to both of you!
Cheers,
 -- Guido


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to