linux-kernel - Re: [Xen-devel] [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] [day] [month] [year] [list]

Message-ID: <CAFLBxZaqvqNZK0CutdVO2KMZ7CfnwS5Mp99WTwyKp_hkToKrYg@mail.gmail.com>
Date:	Tue, 26 Jun 2012 12:05:25 +0100
From:	George Dunlap <George.Dunlap@...citrix.com>
To:	"Luck, Tony" <tony.luck@...el.com>
Cc:	Jan Beulich <JBeulich@...e.com>,
	"Liu, Jinsong" <jinsong.liu@...el.com>,
	"Jiang, Yunhong" <yunhong.jiang@...el.com>,
	Keir Fraser <keir@....org>, "Raj, Ashok" <ashok.raj@...el.com>,
	"Li, Susie" <susie.li@...el.com>,
	"Shan, Haitao" <haitao.shan@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Dugger, Donald D" <donald.d.dugger@...el.com>,
	"Auld, Will" <will.auld@...el.com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	"Nakajima, Jun" <jun.nakajima@...el.com>,
	"Zhang, Xiantao" <xiantao.zhang@...el.com>
Subject: Re: [Xen-devel] [vMCE design RFC] Xen vMCE design

On Fri, Jun 22, 2012 at 4:21 PM, Luck, Tony <tony.luck@...el.com> wrote:
>>>> 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.

Typically if you have a heterogeneous pool (i.e., different processors
with different CPUID bits) you typically have to calculate the minimum
subset of features available on all processors and only expose those
to the guest.  It wouldn't be too hard to extend that to vMCEs if we
had to.  Alternately, as Jan says, we could just fake things out when
we need to.

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