Xen project Mailing List

[XenARM] Doubts on VIPT cache

To: "xen-arm@xxxxxxxxxxxxx" <xen-arm@xxxxxxxxxxxxx>

From: akshay st <akshayts@xxxxxxxxxxx>

Date: Sat, 16 Nov 2013 22:14:11 +0800 (SGT)

Delivery-date: Sat, 16 Nov 2013 14:14:27 +0000

Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=QMORLfrcGL7U2HFjlqnhp4Vyc7Qg7aGMuoYglwKLBHUEFTYVMWrChQ0C6WzdtoxDuLg0hFJt0MV22UBnklWcOAZ1z1IFfN38vl2PmpuUpsu0baGs2djVl3jOAsFrNkcPpT3e89v5NOTNY3igxZnvKou6dB1PCn3YNTptTc3OIfo=;

List-id: List for Xen ARM developers and users <xen-arm.lists.xen.org>

Hi,
Earlier i was trying to port XEN on ARMv5 which uses VIVT , for which there were some cache aliasing issues,
However we now have VIPT caches. I see in the Linux they do some color alignment to avoid aliasing issues.
We have 4 way set associative 32Kb cache, 32 bytes cache line.
As i understand there will be 32kb/32 = 1024 lines, so there will be sets=1024 lines/4 way = 256 sets?

I see that bits 13:12 will be used to avoid cache alisasing issues in VIPT. what i understand is if mutliple virtual address maps to same physical address then we aliasing issue, however if we make sure cache line index for multiple virtual address points to same index then there wont be aliaasing issues. Now how are bits 13:12 help in avoiding cache aliasing issues?

Cache look up address bits ->
Bits 0 to 4 -> linesize, Bits 5 to 13(8 bits) NSET, 14 to 31 -> PHysical TAG to compare. Now even if we make 13:12 same for multiple different virtual address mapping same physical adderss, it can differ in 5:11 which selects different set hence aliasing issue should be there? I guess i am missing something in my understanding.

Warm Regards,
Akshay

_______________________________________________ Xen-arm mailing list Xen-arm@xxxxxxxxxxxxx http://lists.xen.org/cgi-bin/mailman/listinfo/xen-arm