Re: [Xen-devel] Question re live migrate on Xen 4.2 re different cpu capabilities

[Konrad Rzeszutek Wilk <konrad@xxxxxxxxxx>]

On Fri, Feb 8, 2013 at 8:36 AM, Olaf Hering <olaf@xxxxxxxxx> wrote:
> On Thu, Feb 07, Alex Bligh wrote:
>
>>
>>
>> --On 7 February 2013 16:19:29 +0000 Jan Beulich <JBeulich@xxxxxxxx> 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.


I recall seeing that libvirt had some of this figured out. It would
know which CPUID flags each CPU family had - and you could actually
set ('I am a Westmere CPU') or it would use the lowest common CPU
family support for all the guest.

Granted that means you need to know _which_ of the machines has the
lowest common CPU family first. Or you set the guest to say 'Core' .

Anyhow, perhaps looking at libvirt and implementing something similar
in 'xl' would be beneficial for these issues?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel