Arquitetura de comunicação do Guest com o Hypervisor

O funcionamento de um Guest envolve a execução de diversas rotinas, por exemplo, escrita e leitura em disco, rede… Tudo isso com diversos Guests rodando no mesmo Host, então vejamos, o GuestA não pode pausar para esperar a finalização de uma rotina do GuestB, tudo tem que funcionar em conjunto. Para executar essas rotinas existem duas formas muito utilizadas, a arquitetura do paralelismo e a arquiterura de eventos.

Paralelismo (Parallel) - divide as rotinas em threads que serão executadas simultaneamente.
Eventos (Event-driven) - cria um laço de repetição de eventos, que recebem repetidamente informação para processar e disparam uma função de resposta de acordo com o evento. Por exemplo o hypervisor Xen é inteiramente orientado a eventos, não requer threads ou processos para o seu funcionamento.

As arquiteturas de paralelismo e eventos são paradigmas que podem ser empregados para outros tipos de aplicações, porém é de extrema importância o entendimento das duas, pois o hypervisor que você estiver utilizando pode trabalhar com uma das duas ou ambas. 

Não vou aprofundar muito nas arquiteturas, pois existe uma documentação bem completa de ambas no Wikipedia:
http://en.wikipedia.org/wiki/Parallel_computing
http://en.wikipedia.org/wiki/Event-driven_programming

Estruturas dos diretórios e arquivos do Xen Source Code - Part I

Nesse e em mais alguns posts vou mostrar a estrutura de arquivos e diretórios do código fonte do Xen, O texto é basicamente um tradução do XenWiki (aqui), porém como nem todos dominam o inglês e acredito que algumas observações são pertinentes, vamos lá !

Download e extração do código fonte

1 - Para fazer o download do código fonte acesse aqui.

2 - Após efeutar o download execute os comandos abaixo.

[wr41th@arkham Applications]$ ls xen-4.0.1.tar.gz 
xen-4.0.1.tar.gz

[wr41th@arkham Applications]$ tar -xvzf xen-4.0.1.tar.gz

[wr41th@arkham Applications]$ cd xen-4.0.1

Nesse comando vamos listar todo o conteúdo do diretório raiz do Xen, justamente o diretório que vamos falar nesse primeiro post.

[wr41th@arkham xen-4.0.1]$ ls -la
total 400
drwxr-xr-x  23 wr41th  staff     782 Aug 25 07:22 .
drwxr-xr-x  11 wr41th  staff     374 Jan 16 22:25 ..
-rwxr-xr-x   1 wr41th  staff      17 Aug 25 07:22 .bk-to-hg
-rwxr-xr-x   1 wr41th  staff      17 Aug 25 07:22 .hg-to-bk
-rw-r--r--   1 wr41th  staff      94 Aug 25 07:22 .hg_archival.txt
-rw-r--r--   1 wr41th  staff    8515 Aug 25 07:22 .hgignore
-rw-r--r--   1 wr41th  staff    3424 Aug 25 07:22 .hgsigs
-rw-r--r--   1 wr41th  staff    2893 Aug 25 07:22 .hgtags
-rw-r--r--   1 wr41th  staff  110128 Aug 25 07:22 .rootkeys
-rw-r--r--   1 wr41th  staff   19379 Aug 25 07:22 COPYING
-rw-r--r--   1 wr41th  staff    6961 Aug 25 07:22 Config.mk
-rw-r--r--   1 wr41th  staff    6927 Aug 25 07:22 Config.mk.orig
-rw-r--r--   1 wr41th  staff    8197 Aug 25 07:22 Makefile
-rw-r--r--   1 wr41th  staff    6957 Aug 25 07:22 README
drwxr-xr-x  24 wr41th  staff     816 Aug 25 07:22 buildconfigs
drwxr-xr-x  12 wr41th  staff     408 Aug 25 07:22 config
drwxr-xr-x  16 wr41th  staff     544 Aug 25 07:22 docs
drwxr-xr-x   3 wr41th  staff     102 Aug 25 07:22 extras
-rwxr-xr-x   1 wr41th  staff    1270 Aug 25 07:22 install.sh
drwxr-xr-x  17 wr41th  staff     578 Aug 25 07:22 stubdom
drwxr-xr-x  43 wr41th  staff    1462 Aug 25 07:22 tools
drwxr-xr-x   3 wr41th  staff     102 Aug 25 07:22 unmodified_drivers
drwxr-xr-x  12 wr41th  staff     408 Aug 25 07:22 xen

Diretórios do raíz (../xen-4.0.1/)

• buildconfig
• config - Flags para compilar o Xen em diferentes sistemas operacionais
• docs - Documentação do xen no formato LaTEK e man pages
• extras - Código para um mini-OS DomU <-- Realmente muito interessante esse código e futuramente merece um post.
• sutbdom - IOEMU Stub DomU, PV-GRUB Stub DomU, e exemplos de código para criação e novos Stub DomUs.

Stub é um pedaço de código usado para substituir algumas outras funcionalidades de programação. Um stub pode simular o comportamento de um código existente (como um procedimento em uma máquina remota) ou ser um substituto temporário para o código ainda a ser desenvolvido. Eles são portanto mais úteis em portabilidade, computação distribuída bem como no desenvolvimento e teste de software em geral. Porque usar Stub Domains no Xen? A resposta está aqui.

• tools - ferramentas de suporte do Xen hypervisor
• unmodified_drivers - Linux 2.6 drivers

Arquivos do diretório raiz

• .bk-to-hg - Mercurial Repository Files
• .hg_archival.txt - Mercurial Repository Files
• .hgignore - Mercurial Repository Files
• .hgtags - Mercurial Repository Files
• .hg-to-bk - Mercurial Repository Files
• .rootkeys - Mercurial Repository Files

Mercurial é uma ferramenta multi-plataforma de controle de versão distribuído para desenvolvedores de software (parecido com GiT, svn, etc). O sistema é implementado principalmente em Python, porém o utilitário binário diff foi escrito em C. E os arquivos acima são justamente para fazer conexão com esse software.

• Config.mk - Documentação do Makefile
• Copying - Aqruivo de licença, no caso do Xen é GNU
• install.sh - Shell script para instalação do Xen
• Makefile - Makefile principal do Xen
• README - Overview do Xen

No próximo post vou escrever sobre o conteúdo dos diretórios Config e do Docs.

Overview do Xenbus

O XenBus é o responsável por prover uma maneira de organizar, enumerar e conectar os dispositivos virtuais disponíveis para um determinado domínio/guest.

Estrutura para definir um dispositivo XenBus

../include/xen/xenbus.h

struct xenbus_device {
 const char *devicetype;
 const char *nodename;
 const char *otherend;
 int otherend_id;
 struct xenbus_watch otherend_watch
 struct device dev;
 enum xenbus_state state;
 struct completion down;
};

A estrutura xenbus_device para criação de um disposto é muito parecida da estrutura para criação de qualquer dispositivo no Linux.

Uma parte fundamental da estrutura xenbus_device é o xenbus_state, que é definido em io/xenbus.h. Existem sete estados que podem ser definidos:

- XenbusStateUnknown: representa o estado inicial do dispositivo no barramento, antes de estar conectado.

- XenbusStateInitiallising: é o estado que fica enquanto o back end está em processo de inicialização.

- XenbusStateInitWait: nesse estado o driver já inicializou, porém precisa de mais informações para que possa ser conectado.

- XenbusStateIniialised: indica que o back end está pronto para conexão.

- XenbusStateConnected: é o estado normal do barramento. Para maior parte do tempo em que o guest está rodando, o barramento irá estar nesse estado indicando que o front e back ends estão se comunicando normalmente.

- XenbusStateClosing: indica que o dispositivo não está mais disponível. O front e back estão parcialmente conectados, isto é o back end não está executando mais nenhum comando recebido do front end.

- XenbusStateClosed: é o estate final, o back end e o front end estão totalmente desconectados.

Existem duas excepções que não utilizam o XenBus são o console e o XenStore.

Arquitetura Xen PV Drivers

Segue um desenho que fiz sobre a arquitetura de PV drivers no Xen. (quando tiver tempo vou explicar cada parte)

Bit field em estruturas C

O C oferece uma forma especial para declarar o tamanho(em bits) dos membros em uma estrutura, conhecido como bit field, é um inteiro com o número de bits especificado. O bit field é declarado com um structure member do tipo int, signet int, unsigned int, ou bool. Você declara o bit file após o nome do membro seguido por ":" e o número de bits que irá ocupar.

O bit field funciona bem para controle, conforme o exemplo abaixo:

#include <stdio.h>
int main(){
    /* Criar a estrutura */
    struct connectionStatus {
        unsigned int  TCP_UDP:1;
        unsigned int  PORT:32;
        unsigned int  OK:1;
    };
    /* Variavies que vão receber os valores */
    struct connectionStatus firstConnection;
    struct connectionStatus secondConnection;
    /* Definir status da primeira Conexão */
    firstConnection.TCP_UDP = 1;
    firstConnection.PORT = 80;
    firstConnection.OK = 1;
    /* Definir status da segunda Conexão */
    secondConnection.TCP_UDP = 0;
    secondConnection.PORT = 5556;
    secondConnection.OK = 0;
    /* Imprimir valores da primeira conexão */
    if (firstConnection.TCP_UDP == 1) { 
        printf("Primeira Conexão...................\n");
        printf("Conexão TCP\n");
        printf("Porta: %d\n", firstConnection.PORT);
        if (firstConnection.OK == 1) {
            printf("Status: Conexão estabelecida !\n"); 
        } else {
            printf("Status: Erro para conectar !\n");   
        }
    }
    /* Imprimir valores da segunda conexão */
    if (secondConnection.TCP_UDP == 0) {
        printf("\nSegunda Conexão...................\n");
        printf("Conexão TCP\n");
        printf("Porta: %d\n", secondConnection.PORT);
        if (secondConnection.OK == 1) {
            printf("Status: Conexão Estabelecida !\n");
        } else {
            printf("Status: Erro para conectar !\n");
        }
    }
};

No exemplo criamos uma estrutura que mostra o status das fictícias conexões, e o bit field foi utilizado para esse fim. Então imagine um cenário onde temos centenas ou milhares de conexões simultâneas e você declarou um int de 32 bits (tamanho padrão desse tipo em um sistema 32bits) para a variável TCP_UDP, você terá um consumo 31 vezes maior de memória por conexão do que se tivesse declarado 1 bit apenas.

Técnicas de Virtualização

Emulador (Emulator): A máquina virtual simula um hardware completo, permitindo que um sistema operacional (Guest) não modificado, seja executado em uma arquitetura totalmente diferente. Ex: QEMU, Virtual PC…

Virtualização completa (Full Virtualization, FV ou HVM): A máquina virtual provê o ambiente necessário para que um sistema operacional (Guest) não modificado (e construído para a mesma arquitetura) possa ser executado. Ex: Xen, QEMU, Virtual PC, VMware, CP/CMS...

Paravirtualização (Para Virtualization ou PV): A máquina virtual ao invés de simular o hardware, provê uma API que apenas pode ser utilizada por sistemas operacionais (Guests) “modificados” para esta finalidade, o que trás ganhos de performance similares ao dos sistemas nativos. Ex: Xen, VMware, KVM…

Existem algumas técnicas para trazer a performance do paravirtualizado para a virtualização completa (full virtualization/HVM), conhecida como PV-on-HVM ou PV-on-FV. Os guests podem utilizar um driver paravirtual especial que ultrapassa a emulação para IO de disco e rede.

Xcode Tool?

A Apple fornece gratuitamente a ferramenta Xcode para desenvolvimento na plataforma Mac OS X, nas linguagens Objective-C e C. O Xcode pode ser utilizado com outras linguagens, porém o forte da ferramenta é trabalhar com o framework Cocoa (API da Apple).

O Xcode pode ser comparado(de forma grosseira) com o Eclipse, pois sua interface é simples, porém completa, permitindo agilidade no desenvolvimento de aplicações para Mac OS X, tanto no ambiente gráfico quanto no shell.


Tela Inicial do Xcode:

Área de trabalho do Xcode, com o código de um "Hello World":

Existem duas maneiras de adquirir a ferramenta, através do site da Apple ou no DVD do Mac OS X.