About cachetype on ARMv7

About cachetype on ARMv7

[Kukjin Kim]

Hi all,

I have a query about cachetype on ARMv7.

Following is from arch/arm/kernel/setup.c

static void __init cacheid_init(void)
{
	unsigned int cachetype = read_cpuid_cachetype();
	unsigned int arch = cpu_architecture();

	if (arch >= CPU_ARCH_ARMv6) {
		if ((cachetype & (7 << 29)) == 4 << 29) {
			/* ARMv7 register format */
			cacheid = CACHEID_VIPT_NONALIASING;

(snip)

	printk("CPU: %s data cache, %s instruction cache\n",
		cache_is_vivt() ? "VIVT" :
		cache_is_vipt_aliasing() ? "VIPT aliasing" :
		cache_is_vipt_nonaliasing() ? "VIPT nonaliasing" :
"unknown",
		cache_is_vivt() ? "VIVT" :
		icache_is_vivt_asid_tagged() ? "VIVT ASID tagged" :
		cache_is_vipt_aliasing() ? "VIPT aliasing" :
		cache_is_vipt_nonaliasing() ? "VIPT nonaliasing" :
"unknown");
}

The cachetype access cp15 CTR register through read_cpuid_cachetype(). And
if ARMv7, then its [31:29] value is 100(b).

[31:29] = 100(b) on ARMv7
[31:29] = 000(b) on ARMv6

So, if ARMv7, then cacheid is mapped VIPT cache and non-aliasing,
CACHEID_VIPT_NONALIASING.

But actually, didn't check L1Ip which has policy of instruction cache, and
policy of data cache from other register at that time. Nevertheless, if
ARMv7, printed like following and used.
'CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache'

If every ARMv7 SoCs have VIPT non-aliasing d-cache and i-cache, then no
problem. But actually, Samsung S5PV310(cortex-A9) has PIPT d-cache and VIPT
non-aliasing i-cache. I think PIPT does not mean VIPT non-aliasing even
though their functionality is similar.
Isn't there any functionality difference?
And..in this case, isn't there any problems?
...

How do you think about this?

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

About cachetype on ARMv7

[Russell King - ARM Linux]

On Mon, Jul 05, 2010 at 08:21:56PM +0900, Kukjin Kim wrote:
> If every ARMv7 SoCs have VIPT non-aliasing d-cache and i-cache, then no
> problem. But actually, Samsung S5PV310(cortex-A9) has PIPT d-cache and VIPT
> non-aliasing i-cache. I think PIPT does not mean VIPT non-aliasing even
> though their functionality is similar.

There is no visible difference between a non-aliasing VIPT cache and a
PIPT cache.  Address bit allocation for a 32-byte cache line VIPT
non-aliasing cache with 4K page size:

[0:1] = byte offset into word
[4:2] = word offset
[N-1:5] = virtual index
[31:N] = physical tag

where N <= PAGE_SHIFT, otherwise it would be an aliasing VIPT cache.

For a PIPT non-aliasing cache:

[0:1] = byte offset into word
[4:2] = word offset
[M-1:5] = physical index
[31:M] = physical tag

where M doesn't matter as it can never alias with itself.

The requirements for N is such the CPU visible conditions which qualify a
cache as being VIPT non-aliasing also satisfy PIPT - and a non-aliasing
VIPT cache has the same properties as a PIPT cache.

About cachetype on ARMv7

[Kukjin Kim]

Russell King wrote:
> 
> On Mon, Jul 05, 2010 at 08:21:56PM +0900, Kukjin Kim wrote:
> > If every ARMv7 SoCs have VIPT non-aliasing d-cache and i-cache, then no
> > problem. But actually, Samsung S5PV310(cortex-A9) has PIPT d-cache and
VIPT
> > non-aliasing i-cache. I think PIPT does not mean VIPT non-aliasing even
> > though their functionality is similar.
> 
> There is no visible difference between a non-aliasing VIPT cache and a
> PIPT cache.  Address bit allocation for a 32-byte cache line VIPT
> non-aliasing cache with 4K page size:
> 
> [0:1] = byte offset into word
> [4:2] = word offset
> [N-1:5] = virtual index
> [31:N] = physical tag
> 
> where N <= PAGE_SHIFT, otherwise it would be an aliasing VIPT cache.
> 
> For a PIPT non-aliasing cache:
> 
> [0:1] = byte offset into word
> [4:2] = word offset
> [M-1:5] = physical index
> [31:M] = physical tag
> 
> where M doesn't matter as it can never alias with itself.
> 
> The requirements for N is such the CPU visible conditions which qualify a
> cache as being VIPT non-aliasing also satisfy PIPT - and a non-aliasing
> VIPT cache has the same properties as a PIPT cache.

Thanks for your reply :-)

You mean PIPT is the same as VIPT non-aliasing.
Hmm..there is no need to show exactly cachetype in the kernel boot message?

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

About cachetype on ARMv7

[Russell King - ARM Linux]

On Wed, Jul 07, 2010 at 09:20:57AM +0900, Kukjin Kim wrote:
> > The requirements for N is such the CPU visible conditions which qualify a
> > cache as being VIPT non-aliasing also satisfy PIPT - and a non-aliasing
> > VIPT cache has the same properties as a PIPT cache.
> 
> Thanks for your reply :-)
> 
> You mean PIPT is the same as VIPT non-aliasing.

No, because that's not the case - they are different at the hardware
level.  At the software level, they can be treated the same though.

> Hmm..there is no need to show exactly cachetype in the kernel boot message?

The boot message shows how the kernel drives the cache, not what the
actual cache is - which is far more informative about what the kernel
is doing.

We can find out what the hardware is by looking in specification docs;
we don't need the kernel to tell us that.

About cachetype on ARMv7

[Kukjin Kim]

Russell King wrote:
> 
> On Wed, Jul 07, 2010 at 09:20:57AM +0900, Kukjin Kim wrote:
> > > The requirements for N is such the CPU visible conditions which
qualify a
> > > cache as being VIPT non-aliasing also satisfy PIPT - and a
non-aliasing
> > > VIPT cache has the same properties as a PIPT cache.
> >
> > Thanks for your reply :-)
> >
> > You mean PIPT is the same as VIPT non-aliasing.
> 
> No, because that's not the case - they are different at the hardware
> level.  At the software level, they can be treated the same though.
> 
Yes, you're right. I meant from a functionality point of view in the Linux
kernel.

> > Hmm..there is no need to show exactly cachetype in the kernel boot
message?
> 
> The boot message shows how the kernel drives the cache, not what the
> actual cache is - which is far more informative about what the kernel
> is doing.
> 
I see.

> We can find out what the hardware is by looking in specification docs;
> we don't need the kernel to tell us that.

I agree with you in principle.
But I think, it would be helpful to someone if it could be shown more exact
feature in the kernel boot message especially in this case, it differs with
actual hardware information.

Thanks.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.

About cachetype on ARMv7

[Russell King - ARM Linux]

On Thu, Jul 08, 2010 at 09:52:23AM +0900, Kukjin Kim wrote:
> I agree with you in principle.
> But I think, it would be helpful to someone if it could be shown more exact
> feature in the kernel boot message especially in this case, it differs with
> actual hardware information.

I disagree.  What's interesting is how the kernel drives the cache,
not what the cache actually is - what you want to know is "the docs
say that it's a X cache, is the kernel driving it correctly" not
"can the kernel decode the cache type register and tell me what the
documentation says the cache is".

The former is what the kernel tells you today.  The latter is useless
to working out if the kernel is doing the right thing, and is just a
proof that you can decode register values to strings.

About cachetype on ARMv7

[Kukjin Kim]

Russell King wrote:
> 
> On Thu, Jul 08, 2010 at 09:52:23AM +0900, Kukjin Kim wrote:
> > I agree with you in principle.
> > But I think, it would be helpful to someone if it could be shown more
exact
> > feature in the kernel boot message especially in this case, it differs
with
> > actual hardware information.
> 
> I disagree.  What's interesting is how the kernel drives the cache,
> not what the cache actually is - what you want to know is "the docs
> say that it's a X cache, is the kernel driving it correctly" not
> "can the kernel decode the cache type register and tell me what the
> documentation says the cache is".
> 
Ok..I see. :-) so as I said, agree with your opinion.

> The former is what the kernel tells you today.  The latter is useless
> to working out if the kernel is doing the right thing, and is just a
> proof that you can decode register values to strings.

Anyway, thanks for your kindly description.

Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.