[lkml]   [2012]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRE: [xen vMCE RFC V0.2] xen vMCE design
    Jan Beulich wrote:
    >>>> On 28.06.12 at 10:54, "Liu, Jinsong" <> 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?


     \ /
      Last update: 2012-06-28 12:21    [W:0.046 / U:24.492 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site