arm mmu

Это зависит от типа кэша, если он виртуально адресуемый, то будут проблемы. В ARMv5 (например процессоры ARM920, ARM926) кэш виртуально адресуемый. В поздних версиях кэш вроде бы стал физически адресуемым. Так что зависит от модели процессора.

>если он виртуально адресуемый, то будут проблемы.

Да, у меня armv5, у которых кэш расположен между процессорным ядром и mmu поэтому работает с виртуальными адресами, в v6 он уже между mmu и внешней физической памятью - работает с физическими адресами, я понимаю что проблемы и у того и у другого будут хотя бы на уровне tlb (поток то один, tlb не инвалидируется) но приведет ли это к фатальным ошибкам или сработает дополнительная логика которая всего лишь замедлит работу ?

>я понимаю что проблемы и у того и у другого будут хотя бы на уровне tlb

(поток то один, tlb не инвалидируется)

Да, tlb не инвалидируется, но вроде бы тут никаких проблем не будет: в tlb могут лежать несколько мэппингов разных виртуальных страниц на одну физическую и все должно работать. Проблемы будут с виртуально адресуемым кэшем данных: может возникнуть ситуация, что в кэше будут присутствовать несколько копий одной и той же физической области памяти и независимо изменяться. В случае физически адресуемого кэша данных такой сценарий исключен. Но есть возможность сделать некэшируемое отображение, тогда и с виртуально адресуемым кэшем все должно работать правильно (поскольку он не будет использоваться).

Была такая мысль, но я пробовал ставить общую политику кэша writethrogh, которая как мне кажется должна была исключить эту ситуацию, но код не работает - валится при первом же переключении регистра ttb (создании нового потока), но прекрасно работает с отключенными кэшами... осложняется тем что я дорабатываю этот код и не полностью могу на данном этапе понять что откуда берется.

Только я имею ввиду ситуацию когда в кэше две копии - одна изменяется а втоая содержит старые значения и при сливе кэшей значение в физической памяти непредсказуемо.

>Была такая мысль, но я пробовал ставить общую политику кэша writethrogh, которая как мне кажется должна была исключить эту ситуацию

Вроде бы в общем случае write-through здесь не помогает. Если в кэше присутствуют несколько копий одной и той же области памяти, то при write-through записанное значение всего лишь сразу попадает в память. При этом остальные копии в кэше не изменяются и хранят старое значение. Если кто-то воспользуется этими копиями он получит старое неправильное значение.

>Только я имею ввиду ситуацию когда в кэше две копии - одна изменяется а втоая содержит старые значения и при сливе кэшей значение в физической памяти непредсказуемо.

Да, write-through от такого спасает, но от того, что я написал выше --- нет.

Появилось несколько мыслей - надо пробовать, в первую очередь попробую при политике writethough кэши вообще не сливать никогда а просто инвалидировать. Спасибо что развеял мой миф который я придумал себе для writethough :)

а почему просто не указать в таблице, что кэеширование выключено, для всех адрессов кроме одного?

Очевидно потому что нужно знать что это уже не первая ссылка на физический адрес. Для мультизадачной ос это несколько проблематично - тем более когда не ты ее начинал делать :) и она не портирована на данную архитектуру, когда даже таблицы вообще неправильно созданы автором, когда работа с кэшами просто не учитывалась.

Когда после бессонных ночей исправлений она вообще заработала на реальном процессоре :)

Тут бы еще не вляпяться в необходимость программной поддержки
цветных страниц.
В ARMv7 заявлено что дополнительная логика чипа отслеживает
дублирование в кэше, но вот ранее не гарантируется.