On 23.10.23 19:08, Catalin Marinas wrote:
On Mon, Oct 23, 2023 at 01:55:12PM +0200, David Hildenbrand wrote:
On 23.10.23 12:50, Catalin Marinas wrote:
On Mon, Oct 23, 2023 at 04:16:56PM +0900, Hyesoo Yu wrote:
Does tag storage itself supports tagging? Will the following version be unusable
if the hardware does not support it? The document of google said that
"If this memory is itself mapped as Tagged Normal (which should not happen!)
then tag updates on it either raise a fault or do nothing, but never change the
contents of any other page."
(https://github.com/google/sanitizers/blob/master/mte-dynamic-carveout/spec.md)
The support of H/W is very welcome because it is good to make the patches simpler.
But if H/W doesn't support it, Can't the new solution be used?
AFAIK on the current interconnects this is supported but the offsets
will need to be configured by firmware in such a way that a tag access
to the tag carve-out range still points to physical RAM, otherwise, as
per Google's doc, you can get some unexpected behaviour.
[...]
I followed what you are saying, but I didn't quite read the following
clearly stated in your calculations: Using this model, how much memory would
you be able to reuse, and how much not?
I suspect you would *not* be able to reuse "1/(32*32)" [second carve-out]
but be able to reuse "1/32 - 1/(32*32)" [first carve-out] or am I completely
off?
That's correct. In theory, from the hardware perspective, we could even
go recursively to the third/fourth etc. carveout until the last one is a
single page but I'd rather not complicate things further.
Further, (just thinking about it) I assume you've taken care of the
condition that memory cannot self-host it's own tag memory. So that cannot
happen in the model proposed here, right?
I don't fully understand what you mean. The tags for the first data
range (0 .. ram_size * 31/32) are stored in the first tag carveout.
That's where we'll need CMA. For the tag carveout, when hosting data
pages as tagged, the tags go in the second carveout which is fully
reserved (still TBD but possibly the firmware won't even tell the kernel
about it).
You got my cryptic question right: you make sure that the tag for the
first carveout go to the second carveout.
Sounds very good, thanks.
--
Cheers,
David / dhildenb