From: Paolo Bonzini <pbonzini@redhat.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Alexander Graf <agraf@suse.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
"<kvm@vger.kernel.org> list" <kvm@vger.kernel.org>,
Gleb Natapov <gleb@redhat.com>
Subject: Re: [RFC PATCH 09/11] kvm: simplify processor compat check
Date: Fri, 27 Sep 2013 15:14:37 +0000 [thread overview]
Message-ID: <5245A0DD.9070205@redhat.com> (raw)
In-Reply-To: <87r4ca9zmi.fsf@linux.vnet.ibm.com>
Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
> Alexander Graf <agraf@suse.de> writes:
>
>> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>>
>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> Missing patch description.
>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>
>> I fail to see how this really simplifies things, but at the end of the
>> day it's Gleb's and Paolo's call.
>
> will do. It avoid calling
>
> for_each_online_cpu(cpu) {
> smp_call_function_single()
>
> on multiple architecture.
I agree with Alex.
The current code is not specially awesome; having
kvm_arch_check_processor_compat take an int* disguised as a void* is a
bit ugly indeed.
However, the API makes sense and tells you that it is being passed as a
callback (to smp_call_function_single in this case).
You are making the API more complicated to use on the arch layer
(because arch maintainers now have to think "do I need to check this on
all online CPUs?") and making the "leaf" POWER code less legible because
it still has the weird void()(void *) calling convention.
If anything, you could change kvm_arch_check_processor_compat to return
an int and accept no argument, and introduce a wrapper that kvm_init
passes to smp_call_function_single.
Paolo
> We also want to make the smp call function a callback of opaque. Hence
> this should be made arch specific.
>
> int kvm_arch_check_processor_compat(void *opaque)
> {
> int r,cpu;
> struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
> for_each_online_cpu(cpu) {
> smp_call_function_single(cpu,
> kvm_ops->check_processor_compat,
> &r, 1);
> if (r < 0)
> break;
> }
> return r;
> }
>
> against
>
> - for_each_online_cpu(cpu) {
> - smp_call_function_single(cpu,
> - kvm_arch_check_processor_compat,
> - &r, 1);
> - if (r < 0)
> - goto out_free_1;
> - }
> +
> + r = kvm_arch_check_processor_compat(opaque);
> + if (r < 0)
> + goto out_free_1;
>
>
>
>>
>> Which brings me to the next issue: You forgot to CC kvm@vger on your
>> patch set. Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't
>> have to. Every kvm patch that you want review on or that should get
>> applied needs to be sent to kvm@vger. If you want to tag it as PPC
>> specific patch, do so by CC'ing kvm-ppc@vger.
>
> Will do in the next update
>
> -aneesh
>
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Gleb Natapov <gleb@redhat.com>,
"<kvm@vger.kernel.org> list" <kvm@vger.kernel.org>,
Alexander Graf <agraf@suse.de>,
kvm-ppc@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 09/11] kvm: simplify processor compat check
Date: Fri, 27 Sep 2013 17:14:37 +0200 [thread overview]
Message-ID: <5245A0DD.9070205@redhat.com> (raw)
In-Reply-To: <87r4ca9zmi.fsf@linux.vnet.ibm.com>
Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
> Alexander Graf <agraf@suse.de> writes:
>
>> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>>
>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> Missing patch description.
>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>
>> I fail to see how this really simplifies things, but at the end of the
>> day it's Gleb's and Paolo's call.
>
> will do. It avoid calling
>
> for_each_online_cpu(cpu) {
> smp_call_function_single()
>
> on multiple architecture.
I agree with Alex.
The current code is not specially awesome; having
kvm_arch_check_processor_compat take an int* disguised as a void* is a
bit ugly indeed.
However, the API makes sense and tells you that it is being passed as a
callback (to smp_call_function_single in this case).
You are making the API more complicated to use on the arch layer
(because arch maintainers now have to think "do I need to check this on
all online CPUs?") and making the "leaf" POWER code less legible because
it still has the weird void()(void *) calling convention.
If anything, you could change kvm_arch_check_processor_compat to return
an int and accept no argument, and introduce a wrapper that kvm_init
passes to smp_call_function_single.
Paolo
> We also want to make the smp call function a callback of opaque. Hence
> this should be made arch specific.
>
> int kvm_arch_check_processor_compat(void *opaque)
> {
> int r,cpu;
> struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
> for_each_online_cpu(cpu) {
> smp_call_function_single(cpu,
> kvm_ops->check_processor_compat,
> &r, 1);
> if (r < 0)
> break;
> }
> return r;
> }
>
> against
>
> - for_each_online_cpu(cpu) {
> - smp_call_function_single(cpu,
> - kvm_arch_check_processor_compat,
> - &r, 1);
> - if (r < 0)
> - goto out_free_1;
> - }
> +
> + r = kvm_arch_check_processor_compat(opaque);
> + if (r < 0)
> + goto out_free_1;
>
>
>
>>
>> Which brings me to the next issue: You forgot to CC kvm@vger on your
>> patch set. Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't
>> have to. Every kvm patch that you want review on or that should get
>> applied needs to be sent to kvm@vger. If you want to tag it as PPC
>> specific patch, do so by CC'ing kvm-ppc@vger.
>
> Will do in the next update
>
> -aneesh
>
WARNING: multiple messages have this Message-ID (diff)
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: Alexander Graf <agraf@suse.de>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
"<kvm@vger.kernel.org> list" <kvm@vger.kernel.org>,
Gleb Natapov <gleb@redhat.com>
Subject: Re: [RFC PATCH 09/11] kvm: simplify processor compat check
Date: Fri, 27 Sep 2013 17:14:37 +0200 [thread overview]
Message-ID: <5245A0DD.9070205@redhat.com> (raw)
In-Reply-To: <87r4ca9zmi.fsf@linux.vnet.ibm.com>
Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
> Alexander Graf <agraf@suse.de> writes:
>
>> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>>
>>> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>>
>> Missing patch description.
>>
>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>>
>> I fail to see how this really simplifies things, but at the end of the
>> day it's Gleb's and Paolo's call.
>
> will do. It avoid calling
>
> for_each_online_cpu(cpu) {
> smp_call_function_single()
>
> on multiple architecture.
I agree with Alex.
The current code is not specially awesome; having
kvm_arch_check_processor_compat take an int* disguised as a void* is a
bit ugly indeed.
However, the API makes sense and tells you that it is being passed as a
callback (to smp_call_function_single in this case).
You are making the API more complicated to use on the arch layer
(because arch maintainers now have to think "do I need to check this on
all online CPUs?") and making the "leaf" POWER code less legible because
it still has the weird void()(void *) calling convention.
If anything, you could change kvm_arch_check_processor_compat to return
an int and accept no argument, and introduce a wrapper that kvm_init
passes to smp_call_function_single.
Paolo
> We also want to make the smp call function a callback of opaque. Hence
> this should be made arch specific.
>
> int kvm_arch_check_processor_compat(void *opaque)
> {
> int r,cpu;
> struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
> for_each_online_cpu(cpu) {
> smp_call_function_single(cpu,
> kvm_ops->check_processor_compat,
> &r, 1);
> if (r < 0)
> break;
> }
> return r;
> }
>
> against
>
> - for_each_online_cpu(cpu) {
> - smp_call_function_single(cpu,
> - kvm_arch_check_processor_compat,
> - &r, 1);
> - if (r < 0)
> - goto out_free_1;
> - }
> +
> + r = kvm_arch_check_processor_compat(opaque);
> + if (r < 0)
> + goto out_free_1;
>
>
>
>>
>> Which brings me to the next issue: You forgot to CC kvm@vger on your
>> patch set. Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't
>> have to. Every kvm patch that you want review on or that should get
>> applied needs to be sent to kvm@vger. If you want to tag it as PPC
>> specific patch, do so by CC'ing kvm-ppc@vger.
>
> Will do in the next update
>
> -aneesh
>
next prev parent reply other threads:[~2013-09-27 15:14 UTC|newest]
Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-27 10:03 [RFC PATCH 00/11 Allow PR and HV KVM to coexist in one kernel Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 10:03 ` [RFC PATCH 01/11] kvm: powerpc: book3s hv: Fix vcore leak Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 11:39 ` Alexander Graf
2013-09-27 11:39 ` Alexander Graf
2013-09-27 10:03 ` [RFC PATCH 02/11] kvm: powerpc: book3s: remove kvmppc_handler_highmem label Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 10:03 ` [RFC PATCH 03/11] kvm: powerpc: book3s: move book3s_64_vio_hv.c into the main kernel binary Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 10:03 ` [RFC PATCH 04/11] kvm: powerpc: book3s: Add a new config variable CONFIG_KVM_BOOK3S_HV Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 11:43 ` Alexander Graf
2013-09-27 11:43 ` Alexander Graf
2013-09-27 12:45 ` Aneesh Kumar K.V
2013-09-27 12:57 ` Aneesh Kumar K.V
2013-09-27 10:03 ` [RFC PATCH 05/11] kvm: powerpc: book3s: Add kvmppc_ops callback for HV and PR specific operations Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 12:04 ` [RFC PATCH 05/11] kvm: powerpc: book3s: Add kvmppc_ops callback for HV and PR specific operation Alexander Graf
2013-09-27 12:04 ` [RFC PATCH 05/11] kvm: powerpc: book3s: Add kvmppc_ops callback for HV and PR specific operations Alexander Graf
2013-09-27 12:52 ` Aneesh Kumar K.V
2013-09-27 12:52 ` [RFC PATCH 05/11] kvm: powerpc: book3s: Add kvmppc_ops callback for HV and PR specific operation Aneesh Kumar K.V
2013-09-27 10:03 ` [RFC PATCH 06/11] kvm: powerpc: book3s: Add is_hv_enabled to kvmppc_ops Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 12:18 ` Alexander Graf
2013-09-27 12:18 ` Alexander Graf
2013-09-27 13:03 ` Aneesh Kumar K.V
2013-09-27 13:15 ` Aneesh Kumar K.V
2013-09-30 10:09 ` Alexander Graf
2013-09-30 10:09 ` Alexander Graf
2013-09-30 12:56 ` Aneesh Kumar K.V
2013-09-30 12:56 ` Aneesh Kumar K.V
2013-09-30 14:51 ` Alexander Graf
2013-09-30 14:51 ` Alexander Graf
2013-09-30 16:20 ` Aneesh Kumar K.V
2013-09-30 16:32 ` Aneesh Kumar K.V
2013-09-30 16:36 ` Alexander Graf
2013-09-30 16:36 ` Alexander Graf
2013-09-27 10:03 ` [RFC PATCH 07/11] kvm: powerpc: book3s: pr: move PR related tracepoints to a separate header Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 12:22 ` Alexander Graf
2013-09-27 12:22 ` Alexander Graf
2013-09-27 13:06 ` Aneesh Kumar K.V
2013-09-27 13:18 ` Aneesh Kumar K.V
2013-09-30 10:02 ` Alexander Graf
2013-09-30 10:02 ` Alexander Graf
2013-09-30 12:57 ` Aneesh Kumar K.V
2013-09-30 12:57 ` Aneesh Kumar K.V
2013-09-30 14:51 ` Alexander Graf
2013-09-30 14:51 ` Alexander Graf
2013-09-30 15:53 ` Aneesh Kumar K.V
2013-09-30 15:53 ` Aneesh Kumar K.V
2013-09-30 15:55 ` Alexander Graf
2013-09-30 15:55 ` Alexander Graf
2013-09-27 10:03 ` [RFC PATCH 08/11] kvm: powerpc: book3s: Support building HV and PR KVM as module Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 12:25 ` Alexander Graf
2013-09-27 12:25 ` Alexander Graf
2013-09-27 13:08 ` Aneesh Kumar K.V
2013-09-27 13:20 ` Aneesh Kumar K.V
2013-09-30 10:04 ` Alexander Graf
2013-09-30 10:04 ` Alexander Graf
2013-09-30 12:57 ` Aneesh Kumar K.V
2013-09-30 12:57 ` Aneesh Kumar K.V
2013-09-27 10:03 ` [RFC PATCH 09/11] kvm: simplify processor compat check Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 12:31 ` Alexander Graf
2013-09-27 12:31 ` Alexander Graf
2013-09-27 12:31 ` Alexander Graf
2013-09-27 13:13 ` Aneesh Kumar K.V
2013-09-27 13:25 ` Aneesh Kumar K.V
2013-09-27 13:13 ` Aneesh Kumar K.V
2013-09-27 15:14 ` Paolo Bonzini [this message]
2013-09-27 15:14 ` Paolo Bonzini
2013-09-27 15:14 ` Paolo Bonzini
2013-09-28 15:36 ` Aneesh Kumar K.V
2013-09-28 15:48 ` Aneesh Kumar K.V
2013-09-28 15:36 ` Aneesh Kumar K.V
2013-09-29 8:58 ` Gleb Natapov
2013-09-29 8:58 ` Gleb Natapov
2013-09-29 8:58 ` Gleb Natapov
2013-09-29 15:05 ` Aneesh Kumar K.V
2013-09-29 15:17 ` Aneesh Kumar K.V
2013-09-29 15:05 ` Aneesh Kumar K.V
2013-09-29 15:11 ` Gleb Natapov
2013-09-29 15:11 ` Gleb Natapov
2013-09-29 15:11 ` Gleb Natapov
2013-09-27 10:03 ` [RFC PATCH 10/11] kvm: powerpc: book3s: Allow the HV and PR selection per virtual machine Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 10:03 ` [RFC PATCH 11/11] kvm: powerpc: book3s: Fix module ownership Aneesh Kumar K.V
2013-09-27 10:15 ` Aneesh Kumar K.V
2013-09-27 10:52 ` [RFC PATCH 00/11 Allow PR and HV KVM to coexist in one kernel Aneesh Kumar K.V
2013-09-27 10:52 ` Aneesh Kumar K.V
2013-09-30 10:16 ` Alexander Graf
2013-09-30 10:16 ` Alexander Graf
2013-09-30 10:16 ` Alexander Graf
2013-09-30 13:09 ` Aneesh Kumar K.V
2013-09-30 13:21 ` Aneesh Kumar K.V
2013-09-30 13:09 ` Aneesh Kumar K.V
2013-09-30 14:54 ` Alexander Graf
2013-09-30 14:54 ` Alexander Graf
2013-09-30 14:54 ` Alexander Graf
2013-10-01 11:26 ` Aneesh Kumar K.V
2013-10-01 11:38 ` Aneesh Kumar K.V
2013-10-01 11:26 ` Aneesh Kumar K.V
2013-10-01 11:36 ` Alexander Graf
2013-10-01 11:36 ` Alexander Graf
2013-10-01 11:36 ` Alexander Graf
2013-10-01 11:41 ` Paolo Bonzini
2013-10-01 11:41 ` Paolo Bonzini
2013-10-01 11:41 ` Paolo Bonzini
2013-10-01 11:43 ` Alexander Graf
2013-10-01 11:43 ` Alexander Graf
2013-10-01 11:43 ` Alexander Graf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5245A0DD.9070205@redhat.com \
--to=pbonzini@redhat.com \
--cc=agraf@suse.de \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=gleb@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.