[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, 2013-02-07 at 15:59 +0000, Alex Bligh wrote:
> Olaf,
> 
> --On 7 February 2013 16:11:26 +0100 Olaf Hering <olaf@xxxxxxxxx> wrote:
> 
> > cpuid= is what the guest sees, so its not so much a feature of Xen
> > itself but what the host cpu provides. I'm not sure if Xen can emulate
> > certain important bits. The wikipedia CPUID entry has a list what each
> > bit means.
> 
> I know what how to find out what the bits mean. But in some sense
> I don't care.
> 
> What I want to do is take a particular set of cpu features (which for the
> sake of argument I will do by booting a kvm domain), and say "mask off
> any additional cpuid flags beyond these", so if a new feature gets
> introduced in the Xen codebase, it won't show in the guest. I think the
> only thing I can do at the moment is check the Xen code for every cpu
> feature Xen knows about, remove those I still want, and mask off the rest.
> What I actually want to do is to say "please don't expose any features
> other than these ones, and only expose these if the host supports them",
> so that if we change versions of Xen to one supporting another feature,
> we won't need to poke around in every domain config.

I think you can do this using what xl.cfg(5) describes as the "xend"
syntax, by setting all the ones you aren't explicitly exposing to 0.

The "libxl syntax" is currently "=host,flag=value,..." which starts from
the host and modifies the flags. I can't offhand thing of a reason why
we wouldn't also want to support a different keyword ("explicit"?) which
means "starting from an empty slate add these". Patches accepted...

Ian.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.