linux-kernel - Re: [Qemu-devel] [Patch V2 1/2] x86, mce: Basic support to add LMCE support to QEMU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20151215154255.GI3774@thinpad.lan.raisama.net>
Date:	Tue, 15 Dec 2015 13:42:55 -0200
From:	Eduardo Habkost <ehabkost@...hat.com>
To:	"Raj, Ashok" <ashok.raj@...el.com>
Cc:	Borislav Petkov <bp@...e.de>, kvm@...r.kernel.org,
	Tony Luck <tony.luck@...el.com>,
	Gong Chen <gong.chen@...el.com>,
	Gleb Natapov <gleb@...nel.org>, linux-kernel@...r.kernel.org,
	qemu-devel@...gnu.org, Andi Kleen <andi.kleen@...el.com>,
	Paolo Bonzini <pbonzini@...hat.com>, libvir-list@...hat.com,
	Jiri Denemark <jdenemar@...hat.com>
Subject: Re: [Qemu-devel] [Patch V2 1/2] x86, mce: Basic support to add LMCE
 support to QEMU

On Mon, Dec 14, 2015 at 07:17:27PM -0500, Raj, Ashok wrote:
> On Mon, Dec 14, 2015 at 11:37:16PM +0100, Borislav Petkov wrote:
> > On Mon, Dec 14, 2015 at 02:11:46PM -0500, Raj, Ashok wrote:
> > > This is mostly harmless.. since the MCG_CAP space is shared and has no
> > > conflict between vendors. Also just the CAP being set has no effect.
> > 
> > Of course it does - we check SER_P in machine_check_poll() and when
> > I emulate an AMD guest and inject errors into it, error handling is
> > obviously wrong, see:
> > 
> > https://lkml.kernel.org/r/20151123150355.GE5134@pd.tnic
> > 
> 
> I can see how this hurts.. since the poller isn't doing cpu model specific 
> stuff..?
> 
> in the LMCE case, even if you advertise MCG_LMCE_P in MCG_CAP, the guest kernel 
> wont call intel_init_lmce() only from mce_intel.c.. so the same problem
> won't happen.
> 
> but the issue Eduardo mentioned seems like the following.
> 
> New QEMU_LMCE + New KVM_LMCE + New_GUEST_LMCE - No problem
> 
> but if you were to migrage the Guest_LMCE to a non-LMCE supported KVM host
> we could run into an issue.. 
> 
> is this the compatibility issue that you were looking to fix Eduardo?

If I understood you correctly, yes. Also, note that currently
kvm_arch_init_vcpu() simply warns about missing capabilities,
instead of preventing the VM from running/migrating (as it
should). We need to change that, and figure out a good way to
report "feature FOO can't be enabled in this host" errors to
management software[1]. The main problem is that we don't even
have a QMP console available anymore if machine initialization is
aborted.

CCing libvir-list so they get in the loop.

[1] This is similar to what we need for CPUID checks, but the new
    MCE feature means we need something more generic (that just
    reports QOM property names, probably?)

-- 
Eduardo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/