[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 05.07.12 at 09:02, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Thu, 2012-07-05 at 07:44 +0100, Ian Campbell wrote:
>> On Thu, 2012-07-05 at 07:39 +0100, Jan Beulich wrote:
>> > >>> On 05.07.12 at 05:03, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> > > Jan Beulich wrote:
>> > >> Also I seem to recall that there was going to be a need to
>> > >> save/restore MCi_CTL2, but there's nothing being done in that
>> > >> direction.
>> > > 
>> > > Yes, but that would be done at new vMCE.
>> > > Current vMCE didn't enable MCG_CMCI_P, and MCi_CTL2 are not used, so we 
>> > > don't save/restore MCi_CTL2 at this version.
>> > 
>> > But _that_ is the major save/restore related issue to be
>> > addressed, at least if backward migration (4.2 -> 4.1) is also
>> > to be working reasonably. If such compatibility is entirely
>> > unneeded, then I agree that it likely doesn't need any
>> > consideration at this point.
>> We don't generally worry about N->N-1 migration, just N->N+1.
> If there's nothing to save in 4.2 (and therefore to restore in 4.3) what
> is it we are giving a freeze exception to again?
> If there's no save/restore can you even migrate a guest with vMCE
> enabled at all?

We're currently saving MCG_CAP, with the bank count in it
reflecting the host bank count, and with other bits in there also
matching the host's. That's what we'd like to simplify, _but_ as
said we're already shipping the current interface, so backward
compatibility will be needed anyway.

The main issue really was with MCi_CTL, which if not saved by
4.2 wouldn't be restorable in 4.3. Now that we decided that they
will get fixed values anyway, simply enforcing these fixed values
(to not surprise the guest) would seem sufficient for 4.2. MCi_CTL2
are different in that afaiu setting them to 0 for a guest with no
saved values (i.e. 4.2, where their presence isn't being advertised,
since CMCI doesn't get surfaced) would be correct.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.