[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |