Análise do processo de comunicação heterogênea entre núcleo A e núcleo M

Agora, mais e mais produtos têm arquitetura heterogênea de núcleo M e núcleo A, que podem não apenas atender aos requisitos em tempo real do núcleo M, mas também atender à ecologia e ao poder de computação do núcleo A. Como a série i.MX8 da NXP, a série RZ/G2L da Renesas e a série AM62x da TI, etc. Embora as marcas e o desempenho desses processadores sejam diferentes, os princípios da comunicação multi-core são basicamente os mesmos, todos baseados em registradores e interrupções para transmitir mensagens e baseados em memória compartilhada para transmitir dados.

Descrição da arquitetura geral do processo de comunicação

 

1. Princípio de implementação da comunicação da camada de hardware

Através da alocação de memória física DDR, a camada de hardware é dividida em duas partes: TXVring Buffer (enviar buffer de anel virtual) e RXVring Buffer (receber buffer de anel virtual); onde o núcleo M envia dados da área TXVring e lê da área RXVring Receber dados, um núcleo vice-versa.

O processador suporta o módulo de função Messaging Unit (MU para abreviar), que se comunica e coordena passando mensagens através do MU e transmite comandos entre o núcleo M e o núcleo A por meio de interrupções de registro e suporta até 4 grupos de MUs para transmitir mensagens bidirecionalmente. Notifique a outra parte sobre o status da transmissão de dados por meio de interrupções, e também pode enviar até 4 bytes de dados e pode ativar a outra parte no modo de baixo consumo de energia, que é um meio importante para garantir tempo real comunicação de núcleo duplo.

Vamos dar uma olhada no processo específico de passar uma mensagem de CoreA para CoreB uma vez:

Registre o modelo de comunicação de entrada e saída

(1) CoreA grava dados;
(2) MU limpa o bit Tx vazio para 0, e o bit Rx cheio é definido como 1; (
3) Gera uma solicitação de interrupção de recebimento e notifica CoreB que o receptor no registro de status de recebimento está cheio e pode ler dados;
(4) CoreB responde à interrupção e lê os dados;
(5) Depois que CoreB lê os dados, MU limpa o bit cheio Rx para 0 e o bit vazio Tx é definido como 1; (
6) O status register gera uma solicitação de envio de interrupção para o CoreA, informando ao CoreB para ler os dados e enviar o registrador nulo.

2. Realização da comunicação RPMsg sob a camada de driver Virtio

O Virtio é um framework geral de virtualização de I/O, uma camada de abstração acima do dispositivo, responsável pelo mecanismo de notificação e processo de controle entre front-end e back-end, e fornece uma implementação de camada para comunicação de dados entre multi-cores heterogêneos. O hipervisor simula uma série de dispositivos de virtualização, como virtio-net, virtio-blk, etc., e disponibiliza esses dispositivos por meio de chamadas de API dentro da máquina virtual. É composto por 4 partes: driver front-end, driver back-end, vring e interface unificada entre comunicação. Comparado com outros métodos de I/O simulados, o virtio reduz a saída e a cópia de dados de máquinas virtuais e pode melhorar muito o desempenho de I/O. Existem diferentes padrões de barramento em computadores, e o virtio usa o barramento pci (claro, ele também pode ser implementado com outros barramentos). Todo dispositivo virtio é um dispositivo pci.

  • Driver front-end Virtio

O driver virtio front-end está localizado no kernel do Linux e é executado na máquina virtual VM. Existem diferentes tipos de drivers para diferentes tipos de dispositivos, incluindo virtio-net, virtio-blk, virtio-pci, etc. Esses drivers interagem com o driver de back-end. Tudo unificado.

  • camada virtio

A camada virtio implementa a interface de fila virtual. Como uma ponte para comunicação front-end e back-end, o número de filas virtuais usadas por diferentes tipos de dispositivos é diferente. Por exemplo, virtio-net usa duas filas virtuais, uma para receber e um para envio; apenas o driver virtio-blk Use uma fila virtual. A fila virtual é realmente implementada como um ponto de conexão entre o sistema operacional convidado e o hipervisor e pode ser implementada de qualquer maneira, desde que o sistema operacional convidado e o programa de back-end virtio sigam certos padrões e os implementem de maneira correspondente.

  • camada de anel virtio

Virtio-ring é uma implementação concreta de uma fila virtual, que implementa um buffer de anel (ring buffer) para salvar informações sobre a execução do driver de front-end e do manipulador de back-end e pode salvar várias solicitações de E/S de o driver front-end de uma só vez e entregá-lo ao driver back-end para processamento em lote e, finalmente, chamar o driver de dispositivo no host para implementar operações físicas de E/S. Dessa forma, o processamento em lote pode ser realizado de acordo com o acordo em vez de cada solicitação de E/S no cliente. Processado uma vez, melhorando assim a eficiência da troca de informações entre o cliente e o hipervisor.

  • Driver back-end Virtio

O driver de back-end do virtio está localizado no qemu e as principais funções do dispositivo de back-end são divididas em duas partes:

  1. Emulação de dispositivos de back-end virtio;
  2. De acordo com o protocolo virtio, a solicitação enviada da máquina virtual é processada.

Na implementação do QEMU, o dispositivo virtio é um dispositivo PCI simulado pelo QEMU para a máquina virtual. Segue a especificação PCI definida pelo PCI-SIG e possui funções como espaço de configuração e configuração de interrupção. O driver de back-end virtio é executado em a máquina host e é usado para implementar o virtio O back-end opera dispositivos de hardware, como o envio de um pacote de dados para a pilha de protocolos do kernel para concluir a operação da máquina virtual nos dados da rede.

O RPMsg message framework é um framework para comunicação de mensagens entre o núcleo de processamento principal e o núcleo de coprocessamento implementado pelo sistema Linux baseado na fila de cache do Virtio. Quando o driver cliente precisar enviar uma mensagem, o RPMsg irá encapsular a mensagem em um Virtio cache e adicioná-lo à fila de cache para Após concluir o envio da mensagem, quando o barramento de mensagens receber a mensagem enviada pelo coprocessador, ela será razoavelmente despachada para o driver cliente para processamento.

Na camada de driver, para o núcleo A, o Linux adota o framework RPMsg + modelo de driver Virtio, e encapsula o RPMsg como um arquivo tty para a camada de aplicação chamar; no núcleo M, o Virtio é transplantado, e uma versão simplificada do é utilizado o RPMsg, pois envolve mutexes e Semaphore, e por fim utilizar o FreeRTOS para completar o encapsulamento do processo, segue abaixo o fluxograma.

Fluxograma de transferência de dados entre o núcleo de processamento principal e o núcleo de coprocessamento

(1) Core0 envia dados para Core1 e empacota os dados na área de lista vinculada Virtioavail por meio da função rpmsg_send; (
2) Encontra o cache livre na memória compartilhada na lista vinculada de disponibilidade e coloca os dados na memória compartilhada;
(3) Notifica o Core1 da chegada de dados por meio de uma interrupção, a memória compartilhada é alterada da área de lista vinculada disponível para a área usada; (4) o Core1
recebe uma interrupção, aciona a função de retorno de chamada do rpmsg, obtém o endereço físico da memória compartilhada onde os dados estão localizados da área usada e conclui a recepção de dados; (5) Notifica através da
interrupção que a recepção de dados do Core0 é concluída e o cache da memória compartilhada é alterado da área usada para a área disponível para o próxima transmissão.

 Informações por meio do trem: rota de aprendizado da tecnologia de código-fonte do kernel do Linux + tutorial em vídeo do código-fonte do kernel

Learning through train: Linux kernel code memory tuning file system process management device driver/network protocol stack

3. Implementação de comunicação dual-core da camada de aplicativo

Na camada de aplicação, as funções open, write e read podem ser usadas para chamar os arquivos do dispositivo em /dev para o núcleo A; as funções rpmsg_lite_remote_init, rpmsg_lite_send e rpmsg_queue_recv podem ser usadas para o núcleo M, e o foco não será elaborado . Do ponto de vista da estrutura geral, a relação é a seguinte:

 

Acho que você gosta

Origin blog.csdn.net/youzhangjing_/article/details/131475972
Recomendado
Clasificación