RE: [vMCE design RFC] Xen vMCE design

[Liu, Jinsong]

Jan Beulich wrote:
>>>> On 22.06.12 at 15:46, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> Jan Beulich wrote:
>>> One other concern that occurred to me after long having sent
>>> the original response: Your proposal aims at a fixed,
>>> unmodifiable vMCE interface. How is that going to be forward
>>> compatible? I.e. consider you had made that proposal before
>>> the SRAO/SRAR changes went in - would the same interface (with
>>> the same set of capability bits set/clear) still be suitable?
>> 
>> Yes, since it's pure s/w emulated interface. At the case when SRAO
>> or SRAR not supported by h/w platform, it's still OK, since under
>> such case hypervisor don't need deliver SRAO or SRAR to guest at
>> all. The emulated vMCE interface just tell the guest that it runs at
>> a virtual platform with those well-defined capabilities.
> 
> I probably didn't express well enough what I want you to check:
> Consider you had done the current re-design work without
> SRAO/SRAR in mind (e.g. a couple of years ago). Would the
> end result have been the same? Namely, would the bits you
> nominate to be set/clear in MCG_CAP be the same?
> 
>>> 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.
> 
> Jan

Sorry for misunderstanding your meaning in my last email, please ignore it. 
I agree that MCG_CAP should be save/restore when migration, considering in the future some CAP bit may be added.

Thanks,
Jinsong--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/