base, mem-cache: Rewrite TaggedEntry code

The only difference between the TaggedEntry and the newly defined
CacheEntry is the presence of the secure flag in the first case.  The
need to tag a cache entry according to the security bit required the
overloading of the matching methods in the TaggedEntry class to take
security into account (See matchTag [1]), and the persistance after
PR #745 of the AssociativeSet class which is basically identical
to its AssociativeCache superclass, only it overrides its virtual
method to match the tag according to the secure bit as well.

The introduction of the KeyType parameter in the previous commit
will smoothe the differences and help unifying the interface.

Rather than overloading and overriding to account for a different
signature, we embody the difference in the KeyType class. A
CacheEntry will match with KeyType = Addr,
whereas a TaggedEntry will use the following lookup type proposed in this
patch:

struct KeyType {
    Addr address;
    bool secure;
}

This patch is partly reverting the changes in #745 which were
reimplementing TaggedEntry on top of the CacheEntry. Instead
we keep them separate as the plan is to allow different
entry types with templatization rather than polymorphism.

As a final note, I believe a separate commit will have to
change the naming of our entries; the CacheEntry should
probably be renamed into TaggedEntry and the current TaggedEntry
into something that reflect the presence of the security bit
alongside the traditional address tag

[1]: https://github.com/gem5/gem5/blob/stable/\
    src/mem/cache/tags/tagged_entry.hh#L81

Change-Id: Ifc104c8d0c1d64509f612d87b80d442e0764f7ca
Signed-off-by: Giacomo Travaglini <giacomo.travaglini@arm.com>
This commit is contained in:
Giacomo Travaglini
2024-08-08 14:19:31 +01:00
parent 1c57195d7f
commit ee9814499d
38 changed files with 385 additions and 270 deletions

View File

@@ -1,5 +1,5 @@
/*
* Copyright (c) 2010-2019 ARM Limited
* Copyright (c) 2010-2019, 2024 ARM Limited
* All rights reserved.
*
* The license below extends only to copyright in the software and shall
@@ -172,7 +172,7 @@ Cache::access(PacketPtr pkt, CacheBlk *&blk, Cycles &lat,
DPRINTF(Cache, "%s for %s\n", __func__, pkt->print());
// flush and invalidate any existing block
CacheBlk *old_blk(tags->findBlock(pkt->getAddr(), pkt->isSecure()));
CacheBlk *old_blk(tags->findBlock({pkt->getAddr(), pkt->isSecure()}));
if (old_blk && old_blk->isValid()) {
BaseCache::evictBlock(old_blk, writebacks);
}
@@ -1268,7 +1268,7 @@ Cache::recvTimingSnoopReq(PacketPtr pkt)
}
bool is_secure = pkt->isSecure();
CacheBlk *blk = tags->findBlock(pkt->getAddr(), is_secure);
CacheBlk *blk = tags->findBlock({pkt->getAddr(), is_secure});
Addr blk_addr = pkt->getBlockAddr(blkSize);
MSHR *mshr = mshrQueue.findMatch(blk_addr, is_secure);
@@ -1383,7 +1383,7 @@ Cache::recvAtomicSnoop(PacketPtr pkt)
return 0;
}
CacheBlk *blk = tags->findBlock(pkt->getAddr(), pkt->isSecure());
CacheBlk *blk = tags->findBlock({pkt->getAddr(), pkt->isSecure()});
uint32_t snoop_delay = handleSnoop(pkt, blk, false, false, false);
return snoop_delay + lookupLatency * clockPeriod();
}
@@ -1429,7 +1429,7 @@ Cache::sendMSHRQueuePacket(MSHR* mshr)
// we should never have hardware prefetches to allocated
// blocks
assert(!tags->findBlock(mshr->blkAddr, mshr->isSecure));
assert(!tags->findBlock({mshr->blkAddr, mshr->isSecure}));
// We need to check the caches above us to verify that
// they don't have a copy of this block in the dirty state