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. init
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 th
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_
> >> 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
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_s
> 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_cp
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_
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 synchron
> 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
> cpu_synchr
> 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 no
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
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
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
> (
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
>> KVM_S3
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 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
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 seve
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 i
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
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
>> modi
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
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
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 me
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. i
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
>> modi
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. initializ
27 matches
Mail list logo
