From: Gleb Natapov <gleb@redhat.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: "<kvm@vger.kernel.org> list" <kvm@vger.kernel.org>,
Alexander Graf <agraf@suse.de>,
kvm-ppc@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Paolo Bonzini <pbonzini@redhat.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH 09/11] kvm: simplify processor compat check
Date: Sun, 29 Sep 2013 18:11:15 +0300 [thread overview]
Message-ID: <20130929151115.GA4964@redhat.com> (raw)
In-Reply-To: <87siwnbrdf.fsf@linux.vnet.ibm.com>
On Sun, Sep 29, 2013 at 08:35:16PM +0530, Aneesh Kumar K.V wrote:
> Gleb Natapov <gleb@redhat.com> writes:
>
> > On Sat, Sep 28, 2013 at 09:06:47PM +0530, Aneesh Kumar K.V wrote:
> >> Paolo Bonzini <pbonzini@redhat.com> writes:
> >>
> >> > 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).
> >>
> >> But whether to check on all cpus or not is arch dependent right?.
> >> IIUC only x86 and ppc64 need to do that. Also on ppc64 it really
> >> depends on whether HV or PR. We need to check on all cpus only if it is
> >> HV.
> >>
> >> >
> >> > 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.
> >> >
> >>
> >> IIUC what we wanted to check is to find out whether kvm can run on this
> >> system. That is really an arch specific check. So for core kvm the call
> >> should be a simple
> >>
> >> if (kvm_arch_check_process_compat() < 0)
> >> error;
> > We have that already, just return error from kvm_arch_hardware_setup. This
> > is specific processor compatibility check and you are arguing that the
> > processor check should be part of kvm_arch_hardware_setup().
>
>
> What about the success case ?. ie, on arch like arm we do
>
> void kvm_arch_check_processor_compat(void *rtn)
> {
> *(int *)rtn = 0;
> }
>
> for_each_online_cpu(cpu) {
As I said they opted out from doing the check. They may reconsider after
first bad HW will be discovered.
> smp_call_function_single(cpu,
> kvm_arch_check_processor_compat,
> &r, 1);
> if (r < 0)
> goto out_free_1;
> }
>
> There is no need to do that for loop for arm.
It's done once during module initialisation. Why is this a big deal?
--
Gleb.
next prev parent reply other threads:[~2013-09-29 15:11 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
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 [this message]
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=20130929151115.GA4964@redhat.com \
--to=gleb@redhat.com \
--cc=agraf@suse.de \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
/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).