From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: vMCE vs migration Date: Tue, 31 Jan 2012 14:34:05 +0000 Message-ID: <1328020445.22639.20.camel@elijah> References: <4F1D4DCD020000780006E593@nat28.tlf.novell.com> <4F1E9F45020000780006EA5E@nat28.tlf.novell.com> <1327596896.24345.66.camel@elijah> <4F26AD7C020000780006FDC1@nat28.tlf.novell.com> <1328009238.27781.87.camel@elijah> <4F27F8020200007800070211@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F27F8020200007800070211@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: George Dunlap , Olaf Hering , "xen-devel@lists.xensource.com" , Ian Campbell List-Id: xen-devel@lists.xenproject.org On Tue, 2012-01-31 at 13:17 +0000, Jan Beulich wrote: > >>> On 31.01.12 at 12:27, George Dunlap wrote: > > On Mon, 2012-01-30 at 13:47 +0000, Jan Beulich wrote: > >> >>> On 26.01.12 at 17:54, George Dunlap wrote: > >> > On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote: > >> >> >>> On 24.01.12 at 11:29, George Dunlap wrote: > >> >> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich wrote: > >> >> >> x86's vMCE implementation lets a guest know of as many MCE reporting > >> >> >> banks as there are in the host. While a PV guest could be expected to > >> >> >> deal with this number changing (particularly decreasing) during migration > >> >> >> (not currently handled anywhere afaict), for HVM guests this is certainly > >> >> >> wrong. > >> >> >> > >> >> >> At least to me it isn't, however, clear how to properly handle this. The > >> >> >> easiest would appear to be to save and restore the number of banks > >> >> >> the guest was made believe it can access, making vmce_{rd,wr}msr() > >> >> >> silently tolerate accesses between the host and guest values. > >> >> > > >> >> > We ran into this in the XS 6.0 release as well. I think that the > >> >> > ideal thing to do would be to have a parameter that can be set at > >> >> > boot, to say how many vMCE banks a guest has, defaulting to the number > >> >> > of MCE banks on the host. This parameter would be preserved across > >> >> > migration. Ideally, a pool-aware toolstack like xapi would then set > >> >> > this value to be the value of the host in the pool with the largest > >> >> > number of banks, allowing a guest to access all the banks on any host > >> >> > to which it migrates. > >> >> > > >> >> > What do you think? > >> >> > >> >> That sounds like the way to go. > >> > > >> > So should we put this on IanC's to-do-be-done list? Are you going to > >> > put it on your to-do list? :-) > >> > >> Below/attached a draft patch (compile tested only), handling save/ > >> restore of the bank count, but not allowing for a config setting to > >> specify its initial value (yet). > > > > Looks pretty good for a first blush. Just one question: Why is the vmce > > count made on a per-vcpu basis, rather than on a per-domain basis, like > > the actual banks are? Is the host MCE stuff per-vcpu? > > The question should probably be the other way around - why is the > vMCE implementation using global (fake) MSRs rather than per-vCPU > ones (as they would be on hardware). If the change here was > implemented as per-domain MSRs, a future move of the vMCE > implementation to a more natural model would be impossible. Also, > for the PV case the save/restore logic is much simpler this way. Ah, that makes sense. Good spot on the impossiblity of changing to per-vcpu later. -George