linux-kernel - RE: [vMCE design RFC] Xen vMCE design

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3908561D78D1C84285E8C5FCA982C28F19323340@ORSMSX104.amr.corp.intel.com>
Date:	Fri, 22 Jun 2012 15:21:53 +0000
From:	"Luck, Tony" <tony.luck@...el.com>
To:	Jan Beulich <JBeulich@...e.com>,
	"Liu, Jinsong" <jinsong.liu@...el.com>
CC:	"Raj, Ashok" <ashok.raj@...el.com>,
	"Dugger, Donald D" <donald.d.dugger@...el.com>,
	"Shan, Haitao" <haitao.shan@...el.com>,
	"Nakajima, Jun" <jun.nakajima@...el.com>,
	"Li, Susie" <susie.li@...el.com>,
	"Auld, Will" <will.auld@...el.com>,
	"Zhang, Xiantao" <xiantao.zhang@...el.com>,
	"Jiang, Yunhong" <yunhong.jiang@...el.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Keir Fraser <keir@....org>
Subject: RE: [vMCE design RFC] Xen vMCE design

>>> I think that we minimally need to retain the MCG_CAP register
>>> as being of potentially variable content (and hence needing
>>> saving/restoring on migration). To support this in a forward
>>> compatible manner, we may have to have a way to tell the
>>> hypervisor e.g. via command line option which extra MSRs
>>> have to be treated read-as-zero/writes-ignored upon guest
>>> accesses.
>> 
>> Seems unnecessary, reason as above.
>
> So going forward you see no possibility of additions to the
> interface that might warrant allowing more bits to be set in
> MCG_CAP than you define to be set here? That really looks
> unrealistic to me.

More bits can be added to MCG_CAP - but this becomes a hard
problem for migration because most OS guests only look at
MCG_CAP at boot time (linux certainly does) ... so if you migrate
and change MCG_CAP to match the new host, the guest will have
no idea that things changed.

MCG_SER_P bit is easy to deal with:
1) You already know about it
2) You can safely set it when the guest is running on a host that
does not support software error recover ... the guest will just
think that SRAO and SRAR events are possible, but they will never
actually occur. Setting it does make sure that the guest will be
ready should you migrate to a system that really does support it.

Future bits would have to be dealt with on a case by case basis.
The same general model would apply ... set the bit everywhere ...
but you might need some Xen changes to virtualize any new resources
and capabilities that were described by the new bit. Side question:
when a guest is migrated from one machine to another, does the version
of Xen running on source and target have to be the same? This tactic
will not work if you migrate a guest running on Xen version 99 that
does have the code to virtualize some new capability to a machine
running Xen version 98 that doesn't.

-Tony
--
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/