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
| ||
|
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/
Powered by blists - more mailing lists