Messages in this thread | | | Date | Thu, 28 Jun 2012 15:00:56 +0100 | From | "Jan Beulich" <> | Subject | RE: [xen vMCE RFC V0.2] xen vMCE design |
| |
>>> On 28.06.12 at 15:38, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: > Jan Beulich wrote: >>>>> On 28.06.12 at 11:40, "Liu, Jinsong" <jinsong.liu@intel.com> wrote: >>> 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? >> >> Weeks ago, really. See >> http://lists.xen.org/archives/html/xen-devel/2012-06/msg01619.html >> and follow-ups - we'd really only consider getting the save/restore >> interface into forward compatible shape as acceptable. >> >>> 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? >> >> Unfortunately it's likely going to be even less. However, if split >> that way, chances are things could go into e.g. 4.2.1. >> >> Jan > > So let's look at current vMCE status first: > 1). functionally it work abnormally for guest (but tolerated by some guest > like linux/solaris); > 2). before xen 4.1 it blocks migration when migrate from big bank to small > bank platform;
Before 4.2 you mean (in 4.1 we only have this as a backport in SLE11).
> We may try some middle steps, minimal adjusting for xen 4.2 release (to > avoid futher compatible issue at xen 4.2.1, 4.3, ...): > 1). we don't handle vMCE function bugs, only make sure migration works OK;
That's the minimal goal.
> 2). update vMCE interface to a middle clean status: > * remove MCG_CTL (otherwise we have to add this useless MSR at new > vMCE); > * stick all 1's to MCi_CTL (avoid semantic difference); > * for MCG_CAP, clear MCG_CTL_P, limit to 2 banks (otherwise dirty code > have to be added at new vMCE);
Whether that's acceptable would need to be seen when code is ready.
Jan
| |