[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |