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

Re: Help with Understanding vcpu xstate restore error during vm migration



>> Please do you mind giving me more insight on the logic currently implemented
>> and maybe what is wrong with it? It will be important for me since what I'm
>> doing is research work.
> 
> See 9e6dbbe8bf40^..267122a24c49

What reference is this please? 

> 
>> How do the values evc->size and xfeature_mask relate to the source and target
>> processor xstates (or xstate management)?
> 
> The lower bounds check is for normal reasons, while the upper bounds
> check is a sanity "does this image appear to have more states active
> than the current system".
> 
> The upper bound is bogus, because "what this VM has" has no true
> relationship to "what Xen decided to turn on by default at boot".

I see. My initial question about this was more of understanding how this 
information
is gathered. Is it directly related to the CPUID of the VM or does depend on 
the state
of the VM at the moment of migrating it? 

If it is related to the CPUID, how is it constructed? 

>>> To start with, which version (or versions?) of Xen, and what hardware?
>> Xen version 4.18.3-pre
> 
> As you're not on a specific tag, exact changeset?

I am on the stable-4.18 tag. 

> 
> Not that it likely matters - there shouldn't be anything relevant in
> staging-4.18 since RELEASE-4.18.2 as far as this goes.
> 
> There are backports of 2 of bugfixes, but in a way that should be
> practical change on 4.18.
> 
>> My CPU is : Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
> 
> Ok, so Haswell.
> 
> Let me stare at the CPUID dumps and see if anything stands out.

> 
> ~Andrew

Caleb



 


Rackspace

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