From: George Dunlap <george.dunlap@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: vMCE vs migration
Date: Thu, 26 Jan 2012 16:54:56 +0000 [thread overview]
Message-ID: <1327596896.24345.66.camel@elijah> (raw)
In-Reply-To: <4F1E9F45020000780006EA5E@nat28.tlf.novell.com>
On Tue, 2012-01-24 at 11:08 +0000, Jan Beulich wrote:
> >>> On 24.01.12 at 11:29, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > On Mon, Jan 23, 2012 at 11:08 AM, Jan Beulich <JBeulich@suse.com> 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? :-)
-George
next prev parent reply other threads:[~2012-01-26 16:54 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-23 11:08 vMCE vs migration Jan Beulich
2012-01-24 10:29 ` George Dunlap
2012-01-24 11:08 ` Jan Beulich
2012-01-26 16:54 ` George Dunlap [this message]
2012-01-30 7:52 ` Jan Beulich
2012-01-30 13:47 ` Jan Beulich
2012-01-31 11:27 ` George Dunlap
2012-01-31 11:28 ` George Dunlap
2012-01-31 13:17 ` Jan Beulich
2012-01-31 14:34 ` George Dunlap
2012-02-03 7:18 ` Liu, Jinsong
2012-02-03 8:08 ` Jan Beulich
2012-02-03 12:34 ` Liu, Jinsong
2012-02-03 14:04 ` Jan Beulich
2012-02-04 12:35 ` George Dunlap
2012-02-09 18:02 ` Olaf Hering
2012-02-10 10:03 ` Jan Beulich
2012-02-10 16:53 ` Olaf Hering
2012-02-10 17:00 ` Jan Beulich
2012-02-10 17:05 ` Olaf Hering
2012-02-13 8:30 ` Olaf Hering
2012-02-13 10:43 ` Jan Beulich
2012-02-10 21:28 ` Olaf Hering
2012-02-13 9:30 ` Jan Beulich
2012-02-13 10:36 ` Jan Beulich
2012-02-13 14:20 ` Olaf Hering
2012-02-14 14:31 ` Jan Beulich
2012-02-14 15:21 ` Olaf Hering
2012-02-14 14:43 ` Jan Beulich
2012-02-14 17:17 ` Olaf Hering
-- strict thread matches above, loose matches on Subject: below --
2012-02-13 9:35 Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1327596896.24345.66.camel@elijah \
--to=george.dunlap@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.