On 05/08/2014 16:44, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu if one CPU is
modified by another CPU or the main thread (e.g.
On 20/08/14 01:22, Wanpeng Li wrote:
On Tue, Aug 19, 2014 at 04:04:03PM +0200, Christian Borntraeger wrote:
On 18/08/14 07:02, Wanpeng Li wrote:
Hi Christian,
On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
On 07/08/14 15:40, Paolo Bonzini wrote:
Il 07/08/2014 11:59, Christian Borntraeger ha scritto:
Paolo,
are you willing to apply to kvm/queue?
I asked a question, but anyway... not until the end of the merge window
and my small vacation. :)
Paolo
Absolutely, was on vacation myself :-)
On 07/08/14 15:39, Paolo Bonzini wrote:
Il 05/08/2014 16:44, Christian Borntraeger ha scritto:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu if one CPU is
modified by
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be hiding a bug in
QEMU.
On s390 we call KVM_S390_INITIAL_RESET from several reset functions, e.g.
during
CPU creation. This is the first hickup and the pid now points to the main
On 19/08/14 11:27, Paolo Bonzini wrote:
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be hiding a bug in
QEMU.
On s390 we call KVM_S390_INITIAL_RESET from several reset functions, e.g.
during
CPU creation. This is the first
Il 19/08/2014 11:47, Christian Borntraeger ha scritto:
On 19/08/14 11:27, Paolo Bonzini wrote:
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be
hiding a bug in QEMU.
On s390 we call KVM_S390_INITIAL_RESET from several reset
On 19/08/14 11:53, Paolo Bonzini wrote:
Il 19/08/2014 11:47, Christian Borntraeger ha scritto:
On 19/08/14 11:27, Paolo Bonzini wrote:
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be
hiding a bug in QEMU.
On s390 we call
Il 19/08/2014 11:59, Christian Borntraeger ha scritto:
Its only for the interrupts that are cpu local (like pending IPIs).
In addition, we would do that only for the reset case (with an
interface that can be used for migration). Right now
KVM_S390_INITIAL_RESET takes the vcpu_mutex, so this
On 19/08/14 12:03, Paolo Bonzini wrote:
Il 19/08/2014 11:59, Christian Borntraeger ha scritto:
Its only for the interrupts that are cpu local (like pending IPIs).
In addition, we would do that only for the reset case (with an
interface that can be used for migration). Right now
Il 19/08/2014 12:09, Christian Borntraeger ha scritto:
I'm not sure, this does seem like a workaround for another
limitation after all... Gleb?
Yes. We want to get rid of KVM_S390_INITIAL_RESET in QEMU. This comes
from a time, when we had another userspace prototype for KVM on s390
(kuli).
On 19/08/14 12:31, Paolo Bonzini wrote:
Il 19/08/2014 12:09, Christian Borntraeger ha scritto:
I'm not sure, this does seem like a workaround for another
limitation after all... Gleb?
Yes. We want to get rid of KVM_S390_INITIAL_RESET in QEMU. This comes
from a time, when we had another
Il 19/08/2014 12:48, Christian Borntraeger ha scritto:
But I understand your concern of touching generic KVM code only if
really necessary. Let me know if I should send a minimal pid==0
version. (I would prefer the full version, of course).
Yes, please do.
Paolo
--
To unsubscribe from this
Il 19/08/2014 10:38, Christian Borntraeger ha scritto:
The patch may be okay, but I'm worried that it might be hiding a bug in
QEMU.
On s390 we call KVM_S390_INITIAL_RESET from several reset functions, e.g.
during
CPU creation. This is the first hickup and the pid now points to the
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any reasons
why kvm_cpu_synchronize_post_reset() doesn't do the same (e.g. called from
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
reasons
why kvm_cpu_synchronize_post_reset() doesn't do the same (e.g. called from
On 18/08/14 07:02, Wanpeng Li wrote:
Hi Christian,
On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu
On 19/08/14 14:14, David Hildenbrand wrote:
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
reasons
why kvm_cpu_synchronize_post_reset()
On 19/08/14 14:14, David Hildenbrand wrote:
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls
in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
reasons
why
On 19/08/14 16:23, David Hildenbrand wrote:
On 19/08/14 14:14, David Hildenbrand wrote:
Il 19/08/2014 13:28, David Hildenbrand ha scritto:
Looking at the code, kvm_cpu_synchronize_state() seems to do these ioctls
in
the vcpu thread (e.g. comming from cpu_synchronize_all_states()), any
Hmm. We want to not only reduce, we want them be zero.
In addition to a reworked MP_STATE patch set, we might be able to change
the code to call KVM_S390_INITIAL_RESET only from the cpu thread itself.
If that simplifies things, we could avoid doing KVM_S390_INITIAL_RESET on
CPU
On Tue, Aug 19, 2014 at 04:04:03PM +0200, Christian Borntraeger wrote:
On 18/08/14 07:02, Wanpeng Li wrote:
Hi Christian,
On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for
Hi Christian,
On Tue, Aug 05, 2014 at 04:44:14PM +0200, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu if one CPU is
modified by another CPU or
On 08/05/2014 08:14 PM, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu if one CPU is
modified by another CPU or the main thread (e.g.
On 07/08/14 10:21, Raghavendra K T wrote:
On 08/05/2014 08:14 PM, Christian Borntraeger wrote:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu if one CPU is
modified by
Il 05/08/2014 16:44, Christian Borntraeger ha scritto:
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu if one CPU is
modified by another CPU or the main thread (e.g.
Il 07/08/2014 11:59, Christian Borntraeger ha scritto:
Paolo,
are you willing to apply to kvm/queue?
I asked a question, but anyway... not until the end of the merge window
and my small vacation. :)
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
We currently track the pid of the task that runs the VCPU in
vcpu_load. Since we call vcpu_load for all kind of ioctls on a
CPU, this causes hickups due to synchronize_rcu if one CPU is
modified by another CPU or the main thread (e.g. initialization,
reset). We track the pid only for the purpose
28 matches
Mail list logo
