From: James Hogan <james.hogan@imgtec.com>
To: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Cc: <linux-mips@linux-mips.org>, David Daney <ddaney.cavm@gmail.com>,
"Ralf Baechle" <ralf@linux-mips.org>, <kvm@vger.kernel.org>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH 07/15] MIPS: Add mips_cpunum() function.
Date: Thu, 22 May 2014 17:15:12 +0100 [thread overview]
Message-ID: <537E2290.900@imgtec.com> (raw)
In-Reply-To: <20140522161342.GI11800@alberich>
On 22/05/14 17:13, Andreas Herrmann wrote:
> On Wed, May 21, 2014 at 12:10:45PM +0100, James Hogan wrote:
>> On 20/05/14 15:47, Andreas Herrmann wrote:
>>> +static inline unsigned int mips_cpunum(void)
>>> +{
>>> + return read_c0_ebase() & 0x3ff; /* Low 10 bits of ebase. */
>>> +}
>>
>> If this is going to go in mips generic code I think it should be clearly
>> defined, especially in the presence of MT, otherwise perhaps it makes
>> sense for it to go in a paravirt specific header?
>
> It's just wrapper to read ebase_cpunum. Currently only used in the
> paravirt-code (to get CPUnum for a guest CPU -- which eventually is
> read from guest cp0 context).
>
> I am not sure whether it needs to be moved to a paravirt specific
> header.
>
>> I.e. does it return the core number of the running VPE (if so it should
>> probably do something like below as in decode_configs() and go in
>> smp.h), or does it simply always return that field in ebase register (in
>> which case it should probably have ebase in the name and a comment to
>> clarify that it doesn't necessarily map directly to core/vpe number).
>
> Under KVM (MIPSVZ) it effectively returns vcpu_id and thus such a
> comment could be added for clarification.
>
> So, should we name it get_ebase_cpunum() but keep it in this header
> (and also replace the 1 or 2 occurrences of "read_c0_ebase() & 0x3ff"
> in the non-paravirt code with it)?
That sounds reasonable to me.
Cheers
James
WARNING: multiple messages have this Message-ID (diff)
From: James Hogan <james.hogan@imgtec.com>
To: Andreas Herrmann <andreas.herrmann@caviumnetworks.com>
Cc: linux-mips@linux-mips.org, David Daney <ddaney.cavm@gmail.com>,
Ralf Baechle <ralf@linux-mips.org>,
kvm@vger.kernel.org, David Daney <david.daney@cavium.com>
Subject: Re: [PATCH 07/15] MIPS: Add mips_cpunum() function.
Date: Thu, 22 May 2014 17:15:12 +0100 [thread overview]
Message-ID: <537E2290.900@imgtec.com> (raw)
Message-ID: <20140522161512.QsqZrWCHLbW7v5mYaflRoPQwrndDejnCxl2bTDEMr6Q@z> (raw)
In-Reply-To: <20140522161342.GI11800@alberich>
On 22/05/14 17:13, Andreas Herrmann wrote:
> On Wed, May 21, 2014 at 12:10:45PM +0100, James Hogan wrote:
>> On 20/05/14 15:47, Andreas Herrmann wrote:
>>> +static inline unsigned int mips_cpunum(void)
>>> +{
>>> + return read_c0_ebase() & 0x3ff; /* Low 10 bits of ebase. */
>>> +}
>>
>> If this is going to go in mips generic code I think it should be clearly
>> defined, especially in the presence of MT, otherwise perhaps it makes
>> sense for it to go in a paravirt specific header?
>
> It's just wrapper to read ebase_cpunum. Currently only used in the
> paravirt-code (to get CPUnum for a guest CPU -- which eventually is
> read from guest cp0 context).
>
> I am not sure whether it needs to be moved to a paravirt specific
> header.
>
>> I.e. does it return the core number of the running VPE (if so it should
>> probably do something like below as in decode_configs() and go in
>> smp.h), or does it simply always return that field in ebase register (in
>> which case it should probably have ebase in the name and a comment to
>> clarify that it doesn't necessarily map directly to core/vpe number).
>
> Under KVM (MIPSVZ) it effectively returns vcpu_id and thus such a
> comment could be added for clarification.
>
> So, should we name it get_ebase_cpunum() but keep it in this header
> (and also replace the 1 or 2 occurrences of "read_c0_ebase() & 0x3ff"
> in the non-paravirt code with it)?
That sounds reasonable to me.
Cheers
James
next prev parent reply other threads:[~2014-05-22 16:17 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-20 14:47 [PATCH 00/15] MIPS: Add mips_paravirt Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 01/15] MIPS: OCTEON: Enable use of FPU Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 02/15] MIPS: Move system level config items from CPU_CAVIUM_OCTEON to CAVIUM_OCTEON_SOC Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 03/15] MIPS: OCTEON: Move CAVIUM_OCTEON_CVMSEG_SIZE to CPU_CAVIUM_OCTEON Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 22:52 ` James Hogan
2014-05-20 23:23 ` David Daney
2014-05-20 23:23 ` David Daney
2014-05-21 6:22 ` Andreas Herrmann
2014-05-21 6:22 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 04/15] MIPS: Don't use RI/XI with 32-bit kernels on 64-bit CPUs Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 05/15] MIPS: Don't build fast TLB refill handler with 32-bit kernels Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-21 9:38 ` James Hogan
2014-05-21 9:38 ` James Hogan
2014-05-21 13:04 ` Ralf Baechle
2014-05-21 13:17 ` Andreas Herrmann
2014-05-21 13:17 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 06/15] MIPS: Add minimal support for OCTEON3 to c-r4k.c Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-21 10:04 ` James Hogan
2014-05-21 10:04 ` James Hogan
2014-05-21 16:10 ` David Daney
2014-05-21 16:10 ` David Daney
2014-05-21 12:40 ` Ralf Baechle
2014-05-21 21:02 ` Andreas Herrmann
2014-05-21 21:02 ` Andreas Herrmann
2014-05-22 7:59 ` Ralf Baechle
2014-05-20 14:47 ` [PATCH 07/15] MIPS: Add mips_cpunum() function Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-21 11:10 ` James Hogan
2014-05-21 11:10 ` James Hogan
2014-05-22 16:13 ` Andreas Herrmann
2014-05-22 16:13 ` Andreas Herrmann
2014-05-22 16:15 ` James Hogan [this message]
2014-05-22 16:15 ` James Hogan
2014-05-20 14:47 ` [PATCH 08/15] MIPS: OCTEON: Add OCTEON3 to __get_cpu_type Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 09/15] MIPS: Add functions for hypervisor call Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-21 0:16 ` James Hogan
2014-05-21 7:30 ` Andreas Herrmann
2014-05-21 7:30 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 10/15] MIPS: Add code for new system 'paravirt' Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-21 13:39 ` James Hogan
2014-05-21 13:39 ` James Hogan
2014-05-21 16:31 ` David Daney
2014-05-21 16:31 ` David Daney
2014-05-21 16:46 ` James Hogan
2014-05-21 16:46 ` James Hogan
2014-05-23 20:31 ` Andreas Herrmann
2014-05-23 20:31 ` Andreas Herrmann
2014-05-22 16:54 ` Andreas Herrmann
2014-05-22 16:54 ` Andreas Herrmann
2014-05-23 20:28 ` Andreas Herrmann
2014-05-23 20:28 ` Andreas Herrmann
2014-05-23 21:47 ` Ralf Baechle
2014-05-20 14:47 ` [PATCH 11/15] MIPS: paravirt: Add pci controller for virtio Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-21 11:42 ` James Hogan
2014-05-21 11:42 ` James Hogan
2014-05-22 20:17 ` Andreas Herrmann
2014-05-22 20:17 ` Andreas Herrmann
2014-05-28 22:10 ` Andreas Herrmann
2014-05-28 22:10 ` Andreas Herrmann
2014-05-21 13:34 ` Ralf Baechle
2014-05-20 14:47 ` [PATCH 12/15] MIPS: Enable build for new system 'paravirt' Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 13/15] MIPS: Add defconfig for mips_paravirt Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 23:14 ` James Hogan
2014-05-21 6:29 ` Andreas Herrmann
2014-05-21 6:29 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 14/15] MIPS: paravirt: Update mips_paravirt_defconfig Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-20 23:17 ` James Hogan
2014-05-21 6:36 ` Andreas Herrmann
2014-05-21 6:36 ` Andreas Herrmann
2014-05-20 14:47 ` [PATCH 15/15] MIPS: paravirt: Provide _machine_halt function to exit VM on shutdown of guest Andreas Herrmann
2014-05-20 14:47 ` Andreas Herrmann
2014-05-21 13:44 ` James Hogan
2014-05-21 13:44 ` James Hogan
2014-05-28 22:04 ` Andreas Herrmann
2014-05-28 22:04 ` Andreas Herrmann
2014-05-28 23:18 ` James Hogan
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=537E2290.900@imgtec.com \
--to=james.hogan@imgtec.com \
--cc=andreas.herrmann@caviumnetworks.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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