Re: [Xen-devel] [vMCE design RFC] Xen vMCE design

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Fri, Jun 22, 2012 at 4:21 PM, Luck, Tony <tony.luck@xxxxxxxxx> wrote:
>>>> 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.
>
> More bits can be added to MCG_CAP - but this becomes a hard
> problem for migration because most OS guests only look at
> MCG_CAP at boot time (linux certainly does) ... so if you migrate
> and change MCG_CAP to match the new host, the guest will have
> no idea that things changed.

Typically if you have a heterogeneous pool (i.e., different processors
with different CPUID bits) you typically have to calculate the minimum
subset of features available on all processors and only expose those
to the guest.  It wouldn't be too hard to extend that to vMCEs if we
had to.  Alternately, as Jan says, we could just fake things out when
we need to.

 -George

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