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

["Liu, Jinsong" <jinsong.liu@xxxxxxxxx>]

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.

> 
>>>> Jan, I'm not challenge why you backport to SLES11 sp2. If there is
>>>> anything wrong, I agree it's my fault. Currently what I concern is
>>>> if we can do an outright cleanup at xen4.2 so that future vMCE
>>>> could be simple and clean.
>>> 
>>> But we can't tell our customers that migration from, say, SP2 to
>>> SP3 won't be possible.
>> 
>> Somehow I agree, though not 100%, say, how can you tell customers
>> that migrate from sp1 to sp2 (and former) would block? AFAICT it
>> only benefit a little earlier to sp2 (in our solution it delay to
>> sp3). 
> 
> I'm afraid I don't understand what you try to tell me here.

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

> 
>>>> If so, why we need this middle-work patch? It could just keep
>>>> current status at xen 4.2, then start 'dirty' new vMCE implement at
>>>> xen4.3 --> and the 'dirty' inherit from c/s 24887 which from code
>>>> point of view would be totally removed at new vMCE.
>>> 
>>> No, what we now want is to complete said c/s. While at that time
>>> I thought we would need to save MCi_CTL, with the new concept
>>> we won't need to. Instead, we need to enforce it to be all ones
>>> universally. 
>>> 
>>> The only compatibility thing is the need to deal with higher bank
>>> counts perceived to be available by guests, and the possibly
>>> previously seen set MCG_CTL_P bit.
>>> 
>>> And yes, if this created a lot of ugly and otherwise unnecessary
>>> code, I'd agree not to care for this compatibility. But as I don't
>>> expect this to be the case, I thought I'd still ask for it (since if
>>> we don't do it in -unstable, we'll have to carry a private patch
>>> in SLE to do so, and presumably for much longer than the 4.3
>>> development period).
>> 
>> 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;

> 
> If we're in agreement that with this we can adjust things in 4.3
> without breaking 4.2->4.3 migration, then why don't we just do
> that?
> 
> Jan


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