On 01/09/11 19:31, Andreas Färber wrote:
If there aren't known issues, then I want to remove the non-I/O thread
code. git history is still there for anyone that wants to test w/o it.
My problem is that at HEAD *none* of the i386,ppc,sparc guests that used
to work about a month ago boot *at
On 09/01/2011 01:31 PM, Andreas Färber wrote:
Am 30.08.2011 um 21:28 schrieb Anthony Liguori:
On 08/30/2011 01:45 PM, Andreas Färber wrote:
Am 30.08.2011 um 00:42 schrieb Jan Kiszka:
What about making --enable-io-thread default as an intermediate step?
That would leave --disable-io-thread
On 09/02/2011 04:31 PM, Anthony Liguori wrote:
For a platform to be supported, it needs to be actively maintained and
fixed. If there aren't enough folks testing/fixing Darwin/ppc64, then
it's not a platform we can reasonable support :-/
I agree unfortunately. I think personally that Darwin
On 09/02/2011 09:42 AM, Paolo Bonzini wrote:
On 09/02/2011 04:31 PM, Anthony Liguori wrote:
For a platform to be supported, it needs to be actively maintained and
fixed. If there aren't enough folks testing/fixing Darwin/ppc64, then
it's not a platform we can reasonable support :-/
I agree
Am 30.08.2011 um 21:28 schrieb Anthony Liguori:
On 08/30/2011 01:45 PM, Andreas Färber wrote:
Am 30.08.2011 um 00:42 schrieb Jan Kiszka:
What about making --enable-io-thread default as an intermediate
step?
That would leave --disable-io-thread as temporary workaround until
all
issues are
Am 30.08.2011 um 00:42 schrieb Jan Kiszka:
On 2011-08-29 23:25, Anthony Liguori wrote:
On 08/29/2011 04:23 PM, Andreas Färber wrote:
Am 29.08.2011 um 22:24 schrieb Anthony Liguori:
On 08/29/2011 03:21 PM, Andreas Färber wrote:
Am 29.08.2011 um 20:03 schrieb Anthony Liguori:
On 08/22/2011
On 08/30/2011 01:45 PM, Andreas Färber wrote:
Am 30.08.2011 um 00:42 schrieb Jan Kiszka:
What about making --enable-io-thread default as an intermediate step?
That would leave --disable-io-thread as temporary workaround until all
issues are fixed. The latter could generate a big fat warning
On 08/22/2011 08:35 AM, Jan Kiszka wrote:
On 2011-08-22 15:24, Anthony Liguori wrote:
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that the
TCG VCPU doesn't have to multiplex itself with the
Am 29.08.2011 um 20:03 schrieb Anthony Liguori:
On 08/22/2011 08:35 AM, Jan Kiszka wrote:
On 2011-08-22 15:24, Anthony Liguori wrote:
Enabling the I/O thread by default seems like an important part of
declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread
means that the
On 08/29/2011 03:21 PM, Andreas Färber wrote:
Am 29.08.2011 um 20:03 schrieb Anthony Liguori:
On 08/22/2011 08:35 AM, Jan Kiszka wrote:
On 2011-08-22 15:24, Anthony Liguori wrote:
Enabling the I/O thread by default seems like an important part of
declaring
1.0. Besides allowing true SMP
Am 29.08.2011 um 22:24 schrieb Anthony Liguori:
On 08/29/2011 03:21 PM, Andreas Färber wrote:
Am 29.08.2011 um 20:03 schrieb Anthony Liguori:
On 08/22/2011 08:35 AM, Jan Kiszka wrote:
On 2011-08-22 15:24, Anthony Liguori wrote:
Enabling the I/O thread by default seems like an important
On 08/29/2011 04:23 PM, Andreas Färber wrote:
Am 29.08.2011 um 22:24 schrieb Anthony Liguori:
On 08/29/2011 03:21 PM, Andreas Färber wrote:
Am 29.08.2011 um 20:03 schrieb Anthony Liguori:
On 08/22/2011 08:35 AM, Jan Kiszka wrote:
On 2011-08-22 15:24, Anthony Liguori wrote:
Enabling the
On 2011-08-29 23:25, Anthony Liguori wrote:
On 08/29/2011 04:23 PM, Andreas Färber wrote:
Am 29.08.2011 um 22:24 schrieb Anthony Liguori:
On 08/29/2011 03:21 PM, Andreas Färber wrote:
Am 29.08.2011 um 20:03 schrieb Anthony Liguori:
On 08/22/2011 08:35 AM, Jan Kiszka wrote:
On 2011-08-22
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that the
TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which
currently requires a (racey) signal based alarm system.
I
On 2011-08-22 15:24, Anthony Liguori wrote:
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that
the
TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines which
currently
On 08/22/2011 08:35 AM, Jan Kiszka wrote:
On 2011-08-22 15:24, Anthony Liguori wrote:
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that the
TCG VCPU doesn't have to multiplex itself with the
On 22 August 2011 14:24, Anthony Liguori aligu...@us.ibm.com wrote:
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that
the
TCG VCPU doesn't have to multiplex itself with the I/O dispatch
On 08/22/2011 03:50 PM, Peter Maydell wrote:
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that
the
TCG VCPU doesn't have to multiplex itself with the I/O dispatch routines
which
On 2011-08-22 16:00, Paolo Bonzini wrote:
On 08/22/2011 03:50 PM, Peter Maydell wrote:
Enabling the I/O thread by default seems like an important part of
declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means
that the
TCG VCPU doesn't have to multiplex itself
On 08/22/2011 08:50 AM, Peter Maydell wrote:
On 22 August 2011 14:24, Anthony Liguorialigu...@us.ibm.com wrote:
Enabling the I/O thread by default seems like an important part of declaring
1.0. Besides allowing true SMP support with KVM, the I/O thread means that the
TCG VCPU doesn't have to
On 22 August 2011 15:00, Paolo Bonzini pbonz...@redhat.com wrote:
On 08/22/2011 03:50 PM, Peter Maydell wrote:
Even with iothread it's still signal based (and still racy) -- the only
way to get a thread currently executing TCG code to stop doing so is to
send it a signal.
It's signal-based,
21 matches
Mail list logo
