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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
