All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.