Re: [Xen-devel] [PATCH 2/2] x86/vMCE: save/restore MCA capabilities

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

Jan Beulich wrote:
>>>> On 06.03.12 at 12:55, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> Jan Beulich wrote:
>>>>>> On 06.03.12 at 10:28, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>
>>>>>> wrote: 
>>>> Jan Beulich wrote:
>>>>> But we're getting all the farther away from the actual question:
>>>>> Do we need to provide for saving/restoring of any of the _CTL
>>>>> registers? 
>>>>> 
>>>> 
>>>> Per Tony's elaboration about _CTL h/w meaning, I thought they are
>>>> model specific mainly used for debug purpose and os defaultly set
>>>> all 1's to them (if any misunderstanding please point out to me).
>>>> So how about unbind _CTL with host (say, pure software emulated
>>>> msr, not involve h_mcg_ctl/h_mci_ctrl[bank])? If so we don't need
>>>> save/restore _CTL. After all they are model specific, and emulated
>>>> as all 1's to guest seems reasonable.
>>> 
>>> If the guest OS considers a particular CPU model to require an
>>> adjustment to any of these, any such adjustment would be lost over
>>> migration. I'm simply uncertain whether all OSes will tolerate that
>>> (in which case ignoring the writes in the first place would
>>> probably be better). 
>>> 
>> 
>> I'm unsure its risk but if concern OSes tolerance, it would better
>> avoid such inconsistent case. An update approach is, pure s/w
>> emulated _CTL + save/restore, which would get rid of h/w
>> heterogeneity and keep consistent when migrate. 
>> Does it make sense?
> 
> That would be an option, but again only if OSes don't make
> assumptions on the number of banks for certain CPU models.
> 

Afict the only way SDM recommand to get bank number is via mcg_cap, so if OS 
assume bank number via cpu model it would either get same number as that via 
mcg_cap or get wrong number which is OS problem not Xen.

Thanks,
Jinsong


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