Re: [Xen-devel] Xen4.2 S3 regression?

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.09.12 at 17:45, Ben Guthro <ben@xxxxxxxxxx> wrote:
> On Tue, Sep 25, 2012 at 11:10 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>> >>> On 25.09.12 at 16:22, Ben Guthro <ben@xxxxxxxxxx> wrote:
>> > I went back to an old patch that had, since it was in this same function
>> > that you made reference to:
>> > http://markmail.org/message/qpnmiqzt5bngeejk 
>> >
>> > I noticed that I was not seeing the "Breaking vcpu affinity" printk - so
>> > I tried to get that
>> >
>> > The change proposed in that thread seems to work around this pinning
>> > problem.
>> > However, I'm not sure that it is the "right thing" to be doing.
>>
>> As said back then, the original change looks a little suspicious,
>> and hence reverting it is certainly to be considered.
> 
> Which is one of the reasons I brought it up again.

So could you then do what I suggested back then - make a copy
of the two involved CPU masks (*online and *vc->cpu_affinity)
plus vc->domain->cpupool, vc->processor, and vc->vcpu_id into
on-stack variables (ensuring they don't get eliminated by the
compiler, e.g. by adding a read access anywhere after the
triggering ASSERT())?

Then the source change (i.e. the data layout) available, either
together with the xen-syms, or put them into a structure
together with some magic ID to identify where in the stack dump
the interesting bits are.

Jan


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