точки входа ядра в ARM - PullRequest
Новая
       29

точки входа ядра в ARM

0 голосов
/ 17 мая 2018

Я читал исходный код ядра ARM для лучшего понимания и наткнулся на что-то интересное.

Внутри arch/arm/kernel/entry-armv.S есть макрос с именем vector_stub, который генерирует небольшой фрагмент сборкизатем таблица переходов для различных режимов ARM.Например, есть вызов vector_stub irq, IRQ_MODE, 4, который заставляет макрос расширяться до тела с меткой vector_irq;и то же самое происходит для vector_dabt, vector_pabt, vector_und и vector_fiq.

Внутри каждой из этих таблиц переходов vector_ * имеется ровно 1 DWORD с адресом меткис суффиксом _usr.

Я хочу подтвердить, что мое понимание верно, см. ниже.

  1. Означает ли это, что метки с суффиксом _usrвыполняется, только если прерывание возникает, когда поток ядра, выполняющийся на этом процессоре, находится в контексте пользовательского пространства?Например, irq_usr выполняется, если прерывание происходит, когда поток ядра находится в контексте пользовательского пространства, dabt_usr выполняется, если прерывание происходит, когда поток ядра находится в контексте пользовательского пространства, и т. Д.
  2. Если[1] верно, тогда какие потоки ядра отвечают за обработку, скажем, irqs, с другим суффиксом, таким как irq_svc.Я предполагаю, что это обработчик для запроса прерывания, который происходит в режиме SVC.Если да, то какой поток ядра это обрабатывает?Поток ядра, который в данный момент находится в режиме SVC, в зависимости от того, какой процессор получает прерывание?
  3. Если [2] имеет значение true, то в какой момент поток ядра завершает обработку второго прерывания и возвращается к тому месту, где он был прерван(также в режиме SVC)?Это ret_from_intr?

1 Ответ

0 голосов
/ 17 мая 2018

Внутри каждой из этих таблиц переходов vector_ * имеется ровно 1 DWORD с адресом метки с суффиксом _usr.

Это правильно. Таблица индексируется текущим режимом. Например, irq имеет только три записи; irq_usr, irq_svc и irq_invalid. Irq должны быть отключены во время прерывания данных, FIQ и других режимов. Linux будет всегда переходить в режим SVC после этого краткого кода «векторной заглушки». Это достигается с помощью 

@
@ Prepare for SVC32 mode.  IRQs remain disabled.
@
mrs r0, cpsr
eor r0, r0, #(\mode ^ SVC_MODE | PSR_ISETSTATE)
msr spsr_cxsf, r0

@@@ ... other unrelated code

movs    pc, lr          @ branch to handler in SVC mode

Именно поэтому irq_invalid используется для всех других режимов. Исключения не должны возникать, когда выполняется этот код-заглушка.

Означает ли это, что метки с суффиксом _usr выполняются, только если прерывание возникает, когда поток ядра, выполняющийся на этом ЦП, находится в контексте пользовательского пространства? Например, irq_usr выполняется, если прерывание происходит, когда поток ядра находится в контексте пользовательского пространства, dabt_usr выполняется, если прерывание происходит, когда поток ядра находится в контексте пользовательского пространства, и т. Д.

Да, spsr - это режим прерывания, и таблица индексируется этими битами режима.

Если 1 имеет значение true, то какие потоки ядра отвечают за обработку, скажем, irqs, с другим суффиксом, таким как irq_svc. Я предполагаю, что это обработчик для запроса прерывания, который происходит в режиме SVC. Если да, то какой поток ядра это обрабатывает? Поток ядра, в данный момент находящийся в режиме SVC, в зависимости от того, какой процессор получает прерывание?

Я думаю, у вас есть недоразумение. Для процессов пользовательского пространства существует «поток ядра». irq_usr отвечает за хранение регистров пользовательского режима, так как может произойти перепланирование. Контекст для irq_svc отличается, так как стек ядра использовался, и это тот же код, который будет использовать код IRQ. Что происходит, когда пользовательская задача вызывает read()? Он использует системный вызов и код выполняется в контексте ядра. Каждый процесс имеет как пользовательский, так и стек svc / kernel (и информацию о потоке). Поток ядра - это процесс без стека пространства пользователя.

Если 2 имеет значение true, то в какой момент поток ядра завершает обработку второго прерывания и возвращается к тому месту, где он был прерван (также в режиме SVC)? Это ret_from_intr?

Обычно Linux возвращается к потоку ядра, который был прерван, чтобы завершить свою работу. Тем не менее, есть опция конфигурации для упреждения потоков / контекстов SVC. Если прерывание привело к событию перепланирования, то может произойти переключение процесса / контекста, если CONFIG_PREEMPT активен. См. svc_preempt для этого кода.

Смотри также:

...