Re: [Xen-devel] Need help with fixing the Xen waitqueue feature

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.11.11 at 22:03, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 23/11/2011 19:21, "Keir Fraser" <keir.xen@xxxxxxxxx> wrote:
> 
>> On 23/11/2011 18:31, "Olaf Hering" <olaf@xxxxxxxxx> wrote:
>> 
>>> On Wed, Nov 23, Keir Fraser wrote:
>>> 
>>>> We have quite a big waitqueue problem actually. The current scheme of
>>>> per-cpu stacks doesn't work nicely, as the stack pointer will change if a
>>>> vcpu goes to sleep and then wakes up on a different cpu. This really 
>>>> doesn't
>>>> work nicely with preempted C code, which may implement frame pointers 
>>>> and/or
>>>> arbitrarily take the address of on-stack variables. The result will be
>>>> hideous cross-stack corruptions, as these frame pointers and cached
>>>> addresses of automatic variables will reference the wrong cpu's stack!
>>>> Fixing or detecting this in general is not possible afaics.
>>> 
>>> Yes, I was thinking about that wakeup on different cpu as well.
>>> As a quick fix/hack, perhaps the scheduler could make sure the vcpu
>>> wakes up on the same cpu?
>> 
>> Could save old affinity and then vcpu_set_affinity. That will have to do for
>> now. Actually it should work okay as long as toolstack doesn't mess with
>> affinity meanwhile. I'll sort out a patch for this.
> 
> Attached three patches for you to try. They apply in sequence.
> 00: A fixed version of "domain_crash on stack overflow"
> 01: Reorders prepare_to_wait so that the vcpu will always be on the
> waitqueue on exit (even if it has just been woken).
> 02: Ensures the vcpu wakes up on the same cpu that it slept on.

Didn't we (long ago) settle on not permitting new calls to
domain_crash_synchronous()? Is it really impossible to just
domain_crash() in any of the instances these add?

Jan

> We need all of these. Just need testing to make sure they aren't horribly
> broken. You should be able to test multi-processor host again with these.
> 
>  -- Keir
> 
>>  -- Keir
>> 
>>> Olaf
>> 
>> 




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel