Re: [Xen-devel] [PATCH] Xen/MCE: adjust for future new vMCE model

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 05.07.12 at 18:42, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
> Jan Beulich wrote:
>>>>> On 05.07.12 at 17:56, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>>> Jan Beulich wrote:
>>>>>>> On 05.07.12 at 14:46, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>>>>> wrote: 
>>>>> No, what I meant is not coding price. I mean the price that have
>>>>> to add dirty and useless change to the new vMCE is high. Just
>>>>> curious why we cannot simply get rid of c/s 24887? after all it
>>>>> only benefit SLES11 sp2.
>>>> 
>>>> This is what save MCG_CAP, and that this is necessary we agreed
>>>> on iirc. So why would you want to drop that code all of the sudden?
>>> 
>>> The original idea we buy in save/restore MCG_CAP is for the sake of
>>> future capability bits exentsion of MCG_CAP. I didn't image keep a
>>> useless bit in new vMCE.
>> 
>> Which bit is useless?
> 
> I mean, MCG_CTL_P bit (and the MCG_CTL reg) are useless for new vMCE.
> 
> But according to your opinion (if I didn't misunderstand), we have to enable 
> MCG_CTL_P bit and keep MCG_CTL reg in the future.

No - we need to tolerate MCG_CTL_P coming in set from a migration.
There's no reason I can see why MCG_CTL needs to be retained, all
that's needed is that guest accesses don't fault (returning all 1s is,
if I got your earlier mails right, to be tolerated by guests).

> Per my understanding, you just backport c/s 24887 to sp2, so sp0->sp1 and 
> sp1->sp2 migration still block.

Yes, but sp2->sp2 migration now works even when the destination
host has fewer banks. An sp1->sp2 migration would still underly
the restriction on the number of banks, but one could now do a
sp1->sp2->sp2 migration to achieve the effect of migrating to a
less capable host.

>>> If so, the only thing we need do in this middle-work patch is to
>>> remove mci_ctl bank array and stick all 1's to MCi_CTL;
>> 
>> And removing MCG_CTL at the same time is the logical consequence.
> 
> I again confuse here. You don't mind I disable MCG_CTL_P bit and remove 
> MCG_CTL reg in this middle-work patch? so which point you against my former 
> patch?
> 1. remove MCG_CTL;
> 2. stick all 1's to MCi_CTL;
> 3. set MCG_CTL_P=0 and 2 banks at MCG_CAP;

None of these. What I do mind is you disallowing incoming
migration with MCG_CTL_P set and/or bank count != 2.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel