linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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
> 

  reply	other threads:[~2013-09-27 15:14 UTC|newest]

Thread overview: 50+ 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:03 ` [RFC PATCH 01/11] kvm: powerpc: book3s hv: Fix vcore leak Aneesh Kumar K.V
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: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:03 ` [RFC PATCH 04/11] kvm: powerpc: book3s: Add a new config variable CONFIG_KVM_BOOK3S_HV Aneesh Kumar K.V
2013-09-27 11:43   ` Alexander Graf
2013-09-27 12:45     ` 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 12:04   ` Alexander Graf
2013-09-27 12:52     ` 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 12:18   ` Alexander Graf
2013-09-27 13:03     ` Aneesh Kumar K.V
2013-09-30 10:09       ` Alexander Graf
2013-09-30 12:56         ` Aneesh Kumar K.V
2013-09-30 14:51           ` Alexander Graf
2013-09-30 16:20             ` Aneesh Kumar K.V
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 12:22   ` Alexander Graf
2013-09-27 13:06     ` Aneesh Kumar K.V
2013-09-30 10:02       ` Alexander Graf
2013-09-30 12:57         ` Aneesh Kumar K.V
2013-09-30 14:51           ` Alexander Graf
2013-09-30 15:53             ` Aneesh Kumar K.V
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 12:25   ` Alexander Graf
2013-09-27 13:08     ` Aneesh Kumar K.V
2013-09-30 10:04       ` Alexander Graf
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 12:31   ` Alexander Graf
2013-09-27 13:13     ` Aneesh Kumar K.V
2013-09-27 15:14       ` Paolo Bonzini [this message]
2013-09-28 15:36         ` Aneesh Kumar K.V
2013-09-29  8:58           ` Gleb Natapov
2013-09-29 15:05             ` Aneesh Kumar K.V
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:03 ` [RFC PATCH 11/11] kvm: powerpc: book3s: Fix module ownership 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-30 10:16   ` Alexander Graf
2013-09-30 13:09     ` Aneesh Kumar K.V
2013-09-30 14:54       ` Alexander Graf
2013-10-01 11:26         ` Aneesh Kumar K.V
2013-10-01 11:36           ` Alexander Graf
2013-10-01 11:41             ` Paolo Bonzini
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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).