From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH] target-i386: Do not set MCG_SER_P by default
Date: Mon, 23 Nov 2015 11:22:37 -0200
Message-ID: <20151123132237.GM23717@thinpad.lan.raisama.net>
References: <1448060471-14128-1-git-send-email-bp@alien8.de>
 <564FA8A7.3000500@suse.de>
 <20151121010925.GB3994@pd.tnic>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>,
	KVM <kvm@vger.kernel.org>, Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Huang Ying <ying.huang@intel.com>
To: Borislav Petkov <bp@alien8.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:42609 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751510AbbKWNWk (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 23 Nov 2015 08:22:40 -0500
Content-Disposition: inline
In-Reply-To: <20151121010925.GB3994@pd.tnic>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Sat, Nov 21, 2015 at 02:09:25AM +0100, Borislav Petkov wrote:
> On Sat, Nov 21, 2015 at 12:11:35AM +0100, Andreas F=E4rber wrote:
> > Hi,
> >=20
> > CC'ing qemu-devel.
>=20
> Ah, thanks.
>=20
> > Am 21.11.2015 um 00:01 schrieb Borislav Petkov:
> > > From: Borislav Petkov <bp@suse.de>
> > >=20
> > > Software Error Recovery, i.e. SER, is purely an Intel feature and=
 it
> > > shouldn't be set by default. Enable it only on Intel.

What happens when SER is enabled on an AMD CPU? If it really
should't be enabled, why is KVM returning it on
KVM_X86_GET_MCE_CAP_SUPPORTED?

> >=20
> > Is this new in 2.5? Otherwise we would probably need compatibility =
code
> > in pc*.[ch] for incoming live migration from older versions.
>=20
> It looks it is really old, AFAIK from 2010:
>=20
> c0532a76b407 ("MCE: Relay UCR MCE to guest")
>=20
> You'd need to be more verbose about pc*.[ch]. An example perhaps...?

If you change something that's guest-visible and not part of the
migration stream, you need to keep the old behavior on older
machine-types (e.g. pc-i440fx-2.4), or the CPU will change under
the guest's feet when migrating to another host.

=46or examples, see the recent commits to include/hw/i386/pc.h.
They are all about keeping compatibility when CPUID bits are
changed:

33b5e8c0 target-i386: Disable rdtscp on Opteron_G* CPU models
6aa91e4a target-i386: Remove POPCNT from qemu64 and qemu32 CPU models
71195672 target-i386: Remove ABM from qemu64 CPU model
0909ad24 target-i386: Remove SSE4a from qemu64 CPU model

In the case of this code, it looks like it's already broken
because the resulting mcg_cap depends on host kernel capabilities
(the ones reported by kvm_get_mce_cap_supported()), and the data
initialized by target-i386/cpu.c:mce_init() is silently
overwritten by kvm_arch_init_vcpu(). So we would need to fix that
before implementing a proper compatibility mechanism for
mcg_cap.

--=20
Eduardo