On 15/07/16 09:39, Peter Lieven wrote:
> Am 15.07.2016 um 08:32 schrieb Juergen Gross:
>> Commit 095497ffc66b7f031ff2a17f1e50f5cb105ce588 ("vnc-enc-tight: use
>> thread local storage for palette") introduced a regression with Xen:
>> Since this commit qemu used as a device model is no longer capable
>> to register Xenstore watches (that's the effect visible to a user).
>> Reverting this commit makes qemu behave well again. I have no idea
>> why that commit would have this effect with Xen, may be some memory
>> is clobbered?
>
> I personally have no idea, maybe @Paolo has?
>
> Maybe the corruption happens somewhere else and is just visible
> due to this change.
>
> Do you see sth when you ran qemu/xen in valgrind?
Nothing scaring and no real difference between working and not working
variant.
Meanwhile I've been digging a little bit deeper and found the reason:
libxenstore is setting up a reader thread which is waiting for the
watch to fire. With above commit the stack size of that thread (16kB)
is too small. Setting it to 32kB made qemu work again.
So I'd recommend to have just a thread local palette pointer and
allocate the palette when needed and don't free it after using it but
keep it for reuse. Do you want to write that patch or should I do it?
Juergen
