Re: [Xen-devel] [xen vMCE RFC V0.2] xen vMCE design

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

Jan Beulich wrote:
>>>> On 28.06.12 at 10:54, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:
>> Jan Beulich wrote:
>>> The 2-bank approach also needs to be brought in line with the
>>> current host derived value in MCG_CAP, especially if the code to
>>> implement this new model doesn't make it into 4.2 (which would
>>> generally save a larger value).
>> 
>> Let me repeat in my word to avoid misunderstanding about your
>> concern: 
>> Your concern rooted from the history patch (c/s 24887, as attached)
>> which used to solve vMCE migration issue caused from bank number. I
>> guess the patch was not in xen4.1.x but would be in xen 4.2 release
>> recently (right? and when will xen 4.2 release?)
> 
> 4.2 is in feature freeze right now, preparing for the release.
> 
>> Per my understanding, you want us to make sure our new vMCE model
>> compatible w/ olde vMCE. For example if our patch in xen 4.3
>> release, you want to make sure a guest migrate from xen 4.2 to 4.3
>> would not broken. Is this your concern?
> 
> Yes. If we can't get the save/restore records adjusted in time
> for 4.2, compatibility with 4.2 would be a requirement. If we
> manage to get the necessary adjustments done in time, and if
> they're not too intrusive (i.e. would be acceptable at this late
> stage of the development cycle), then the concern could be
> dropped from an upstream perspective due to the lack of
> support in 4.1 (and hence no backward compatibility issues).
> BUT this isn't as simple from a product usage point of view: As
> the save/restore code currently in -unstable was coded up to
> address a problem observed by SLE11 SP2 users, we already
> backported those patches. So compatibility will be a requirement
> in any case.
> 
> Jan

A basic point of new vMCE is, it get rid of old vMCE, start setting up a new 
model from the very beginning. From coding point of view, backward 
compatibility issue would be dirty and troublesome.

The point is, old vMCE interface is host-based while new vMCE is pure s/w 
defined, hence troubles come from the interface heterogeneous (if need keep 
compatibility). The basic assumption of live migration from A to B is, A and B 
basically at same page, so it could be migrated by setting the smallest common 
feature/capability set (via cpuid, command line, etc.). However, old vMCE and 
new vMCE are quite different and cannot controlled effectively. For example, 
old vMCE has MCG_CTL but new vMCE doesn't, and new vMCE has CMCI support (and 
MCi_CTL2) but old vMCE doesn't. I even doubt the feasibility of keeping 
compatibility w/ old vMCE. An example is, it's hard to migrate between Intel 
cpu and AMD cpu.

So I would like to push new vMCE as quickly as possible. What's the timeline of 
vMCE developing that xen 4.2 could accept? I wonder if we could make major 
components of vMCE done before xen 4.2 timeline, and leave the surrounding 
features and the corner cases done later?

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