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: <DE8DF0795D48FD4CA783C40EC8292335258568@SHSMSX101.ccr.corp.intel.com>
Date:	Mon, 25 Jun 2012 08:30:17 +0000
From:	"Liu, Jinsong" <jinsong.liu@...el.com>
To:	Jan Beulich <JBeulich@...e.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>,
	"Luck, Tony" <tony.luck@...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

Jan Beulich wrote:
>>>> On 22.06.12 at 15:46, "Liu, Jinsong" <jinsong.liu@...el.com> wrote:
>> Jan Beulich wrote:
>>> One other concern that occurred to me after long having sent
>>> the original response: Your proposal aims at a fixed,
>>> unmodifiable vMCE interface. How is that going to be forward
>>> compatible? I.e. consider you had made that proposal before
>>> the SRAO/SRAR changes went in - would the same interface (with
>>> the same set of capability bits set/clear) still be suitable?
>> 
>> Yes, since it's pure s/w emulated interface. At the case when SRAO
>> or SRAR not supported by h/w platform, it's still OK, since under
>> such case hypervisor don't need deliver SRAO or SRAR to guest at
>> all. The emulated vMCE interface just tell the guest that it runs at
>> a virtual platform with those well-defined capabilities.
> 
> I probably didn't express well enough what I want you to check:
> Consider you had done the current re-design work without
> SRAO/SRAR in mind (e.g. a couple of years ago). Would the
> end result have been the same? Namely, would the bits you
> nominate to be set/clear in MCG_CAP be the same?
> 
>>> 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.
> 
> Jan

Sorry for misunderstanding your meaning in my last email, please ignore it. 
I agree that MCG_CAP should be save/restore when migration, considering in the future some CAP bit may be added.

Thanks,
Jinsong--
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/