On 09/02/11 17:31, Paolo Bonzini wrote:
On 09/02/2011 05:18 PM, Gerd Hoffmann wrote:
Can you just use a bottom half to defer this work to the I/O thread?
Bottom half scheduling has to be signal safe which means it will also be
thread safe.
Not that straight forward as I would have to pass ar
On 09/02/2011 10:31 AM, Paolo Bonzini wrote:
On 09/02/2011 05:18 PM, Gerd Hoffmann wrote:
Can you just use a bottom half to defer this work to the I/O thread?
Bottom half scheduling has to be signal safe which means it will also be
thread safe.
Not that straight forward as I would have to pa
On 09/02/2011 05:18 PM, Gerd Hoffmann wrote:
Can you just use a bottom half to defer this work to the I/O thread?
Bottom half scheduling has to be signal safe which means it will also be
thread safe.
Not that straight forward as I would have to pass arguments to the
bottom half.
Can you add
On 09/02/2011 10:18 AM, Gerd Hoffmann wrote:
Hi,
A patch like the attached (warning: untested) should do as quick&dirty
fix for stable. But IMO we really should fix spice instead.
I agree. I'm not sure I like the idea of still calling QEMU code without
holding the mutex (even the QObject code
Hi,
A patch like the attached (warning: untested) should do as quick&dirty
fix for stable. But IMO we really should fix spice instead.
I agree. I'm not sure I like the idea of still calling QEMU code without
holding the mutex (even the QObject code).
I though just creating the objects isn'
On 09/02/2011 08:39 AM, Gerd Hoffmann wrote:
Hi,
After some investigation, I found out that the problem is that different
SPICE threads are calling monitor functions (such as
monitor_protocol_event()) in parallel which causes concurrent access
to the monitor's internal buffer outbuf[].
[ addi
On Fri, 02 Sep 2011 15:39:03 +0200
Gerd Hoffmann wrote:
>Hi,
>
> >> After some investigation, I found out that the problem is that different
> >> SPICE threads are calling monitor functions (such as
> >> monitor_protocol_event()) in parallel which causes concurrent access
> >> to the monitor
On 09/02/2011 08:39 AM, Gerd Hoffmann wrote:
Hi,
After some investigation, I found out that the problem is that different
SPICE threads are calling monitor functions (such as
monitor_protocol_event()) in parallel which causes concurrent access
to the monitor's internal buffer outbuf[].
[ addi
Hi,
After some investigation, I found out that the problem is that different
SPICE threads are calling monitor functions (such as
monitor_protocol_event()) in parallel which causes concurrent access
to the monitor's internal buffer outbuf[].
[ adding spice-list to Cc, see qemu-devel for the
On 2011-09-02 11:41, Daniel P. Berrange wrote:
> On Thu, Sep 01, 2011 at 08:34:35PM -0500, Anthony Liguori wrote:
>> On 09/01/2011 02:35 PM, Luiz Capitulino wrote:
>>> Sometimes, when having lots of VMs running on a RHEV host and the user
>>> attempts to close a SPICE window, libvirt will get corru
On Thu, Sep 01, 2011 at 08:34:35PM -0500, Anthony Liguori wrote:
> On 09/01/2011 02:35 PM, Luiz Capitulino wrote:
> >Sometimes, when having lots of VMs running on a RHEV host and the user
> >attempts to close a SPICE window, libvirt will get corrupted json from
> >QEMU.
> >
> >After some investigat
On 09/01/2011 02:35 PM, Luiz Capitulino wrote:
Sometimes, when having lots of VMs running on a RHEV host and the user
attempts to close a SPICE window, libvirt will get corrupted json from
QEMU.
After some investigation, I found out that the problem is that different
SPICE threads are calling mo
On 2011-09-01 21:35, Luiz Capitulino wrote:
> Sometimes, when having lots of VMs running on a RHEV host and the user
> attempts to close a SPICE window, libvirt will get corrupted json from
> QEMU.
>
> After some investigation, I found out that the problem is that different
> SPICE threads are cal
On Thu, Sep 01, 2011 at 04:35:45PM -0300, Luiz Capitulino wrote:
> Sometimes, when having lots of VMs running on a RHEV host and the user
> attempts to close a SPICE window, libvirt will get corrupted json from
> QEMU.
>
> After some investigation, I found out that the problem is that different
>
Sometimes, when having lots of VMs running on a RHEV host and the user
attempts to close a SPICE window, libvirt will get corrupted json from
QEMU.
After some investigation, I found out that the problem is that different
SPICE threads are calling monitor functions (such as
monitor_protocol_event()
15 matches
Mail list logo
