From: Olaf Hering <olaf@aepfle.de>
To: Alex Bligh <alex@alex.org.uk>
Cc: Ian Campbell <Ian.Campbell@citrix.com>,
Jan Beulich <JBeulich@suse.com>,
Xen Devel <xen-devel@lists.xen.org>
Subject: Re: Question re live migrate on Xen 4.2 re different cpu capabilities
Date: Fri, 8 Feb 2013 14:36:30 +0100 [thread overview]
Message-ID: <20130208133630.GA5304@aepfle.de> (raw)
In-Reply-To: <83398C3BBF16693DB6E1E2CA@nimrod.local>
On Thu, Feb 07, Alex Bligh wrote:
>
>
> --On 7 February 2013 16:19:29 +0000 Jan Beulich <JBeulich@suse.com> wrote:
>
> >You're heading in a slightly wrong direction here: You don't really
> >care what features Xen know about or supports. What you do care
> >about is what features your DomU-s get to see. And that's where
> >the masking comes into play (and why this can be done on a per
> >guest basis as well as at the host level).
>
> I want my domUs to see a no more than a fixed set of CPU flags
> (obviously if those CPU flags aren't present, I don't want to
> lie that they are). I have no visibility of what hardware my
> software may be installed on in the future. EG if Intel introduces
> a megawidget CPU flag and Xen adds support for it, I want to be
> guaranteed this is masked out as it will break live migrate
> between megawidget and non-megawidget compatible machines.
I'm not sure what the question is, in a recent bug I had to disable
popcnt because one of the hosts did not have it. So I came up with this
config entry, which disables popcnt and sse4* bits:
cpuid=[ '1:ecx=xxxxxxxx0xx00xxxxxxxxxxxxxxxxxxx' ]
I think you have to read through the CPUID entry and set a few "required" bits
and a few "common across your hardware zoo" bits to 1 and set everything else
to 0 to handle the upcoming megawidget bit:
http://en.wikipedia.org/wiki/CPUID
If you use xend, you may need this patch to handle cpuid properly:
Only add cpuid and cpuid_check to sexpr once
When converting a XendConfig object to sexpr, cpuid and cpuid_check
were being emitted twice in the resulting sexpr. The first conversion
writes incorrect sexpr, causing parsing of the sexpr to fail when xend
is restarted and domain sexpr files in /var/lib/xend/domains/<dom-uuid>
are read and parsed.
This patch skips the first conversion, and uses only the custom
cpuid{_check} conversion methods called later. It is not pretty, but
is the least invasive fix in this complex code.
Index: xen-4.2.0-testing/tools/python/xen/xend/XendConfig.py
===================================================================
--- xen-4.2.0-testing.orig/tools/python/xen/xend/XendConfig.py
+++ xen-4.2.0-testing/tools/python/xen/xend/XendConfig.py
@@ -1126,6 +1126,10 @@ class XendConfig(dict):
else:
for name, typ in XENAPI_CFG_TYPES.items():
if name in self and self[name] not in (None, []):
+ # Skip cpuid and cpuid_check. Custom conversion
+ # methods for these are called below.
+ if name in ("cpuid", "cpuid_check"):
+ continue
if typ == dict:
s = self[name].items()
elif typ == list:
Olaf
next prev parent reply other threads:[~2013-02-08 13:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-07 9:08 Question re live migrate on Xen 4.2 re different cpu capabilities Alex Bligh
2013-02-07 9:19 ` Olaf Hering
2013-02-07 9:47 ` Ian Campbell
2013-02-07 10:59 ` Alex Bligh
2013-02-07 15:11 ` Olaf Hering
2013-02-07 15:59 ` Alex Bligh
2013-02-07 16:16 ` Ian Campbell
2013-02-07 16:59 ` Alex Bligh
2013-02-07 16:19 ` Jan Beulich
2013-02-07 16:59 ` Alex Bligh
2013-02-08 13:36 ` Olaf Hering [this message]
2013-02-08 20:04 ` Konrad Rzeszutek Wilk
2013-02-11 16:18 ` Olaf Hering
-- strict thread matches above, loose matches on Subject: below --
2013-02-07 9:07 Alex Bligh
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=20130208133630.GA5304@aepfle.de \
--to=olaf@aepfle.de \
--cc=Ian.Campbell@citrix.com \
--cc=JBeulich@suse.com \
--cc=alex@alex.org.uk \
--cc=xen-devel@lists.xen.org \
/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.