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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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?

>>> 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.

>>> 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.

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