Ok, this is another trick I learned working on my project.

I’ve a QEMU arm machine and a simulation outside them. QEMU shares his RAM (in the future I’ll write about this) with the simulator so I want to unlock the simulation (that is waiting for a 1 at the address 0x0FF8000) writing the specified value on that address using an application in user space inside the VM.

Ok I’ve found here a source code that do exactly this operation.

It uses the device /dev/mem. It is a special file that provides access to the physical memory of the computer.

if((fd = open("/dev/mem", O_RDWR | O_SYNC)) == -1) FATAL;

It opens /dev/mem in RW.

map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, target & ~MAP_MASK);

This is the key line of the program. The function mmap maps something in the virtual address space of the process who call them. To map the content of a file, mmap starts to read from the offset parameter (the last one) to the length parameter (the second one). MAP_SIZE is 4096 (the size of a memory page), the offset must be multiple of the page size, so target & ~MAP_MASK calculates what is the nearest multiple for our address.

virt_addr = map_base + (target & MAP_MASK);

Now we can add, to the map_base address returned by mmap, the offset deleted before when calculating the multiple of the page size, now we have a physical address that is mapped in a virtual address, and we can write or read directly from it.

This is the second part of the integration of a SystemC module into Qemu. SystemC is C++ so I’ve had lots of problems trying to link my library (that is a multiprocessor simulator written in SystemC) with Qemu, because this is written in pure C.

The first rule that you have to remember when you want to link a C++ library with a C application is to wrap the functions that you want to export with the construct “extern C” . This tells to the C++ compiler to use the standard C name mangling for a function or a group of functions. You can use it in the following way:

extern "C" void function1(int a);
void function1(int a) { /* my function code */ }

In this example function1 can be used in a C application even if it is C++ code. Note that the object for this file must be created using a C++ compiler.

After you can use function1 in any functions written in C (remember to create and to include an header or to use “extern void function1″ in your C code).

The last important rule is to create the binary linking all different object files using a C++ linker.

In my project I’ve added another C++ file in Qemu with something like the function1 explained before, and I’ve to edit Qemu’s Makefile to compile the new C++ file and create the final executable using C++ linker and not a C one.

Now I can use my C++ code in a C application.

I’m currently working on a university project where I need to merge Qemu and a multi-processor simulator written in SystemC, and I want to share with you all my problems and how I resolved them.

First of all, I need to convert the simulator in a library because of I need to create a multi-threaded application to execute Qemu on a thread and the simulator on another. To do it I modified SystemC sc_main.cpp changing the name of the main function in init_systemc_main and recompiling the library.

After I got a lot of linking problem because there is a circular dependence between the simulator and SystemC. The solution was to edit the Makefile of the simulator adding to the linker’s options the “–start-group” and the “–end-group” parameter.
To do that you need to add to the command line the following string:

-Wl,--start-group systemc.a mylib.a -Wl,--end-group

The -Wl parameter tells to the compiler that the following parameters have to be parsed by the linker. Libraries that are inside the group created by –start-group and –end-group parameters are searched repeatedly until no new undefined references are created. We need to use these parameters because normally a library is searched only once in the order that it is specified on the command line.
After this, the program has been compiled and I could start to work on Qemu, but I’ll talk to you of this when I’ll take some steps forward.

After an entire day of working, now Virtualbricks is able to manager remote virtual machines.

You can configure these machines using a local instance of the software. All the features work on a remote machine except for the interconnections between the bricks. Image disks must be located in the same subdirectory and must have the same name. For example if we want to use a disk disk1.qcow2 and your image directory is /home/noob/VM, another image file called disk1.qcow2 must be in the /root/VM directory.

We are still working on other new features and, most important, we are working to remote networks configuration.

Download source from launchpad and try the software, and please report every bug that you find or additional feature that you want.

Oggi è stato il primo giorno del primo WebForAll Week End.

WebForAll è una associazione senza fini di lucro per la realizzazione di servizi digitali e web per soggetti non profit che si impegnano nel sociale.

Il progetto a cui sono stato assegnato riguardava la realizzazione di un sito web per l’associazione Borgo Alice. La cosa più importante della giornata di oggi è stata vedere quanto impegno, quanto lavoro e quante persone sono dentro queste associazioni, che anche se piccole, lavorano pieni di voglia di aiutare, di farsi sentire e di far capire quanto importante sia la propria causa!

Ecco perché è importante questo progetto e perché ho deciso di contribuire!

Vedrete domani quale sarà il risultato di questa fantastica iniziativa!

Dovendo gestire più di un testbed formato da macchine virtuali di numero, tipologia e topologie diverse, mi sono imbattuto in alcuni problemi. I sistemi che utilizzo sono macchine virtuali KVM e VDE per gestire la rete. Per gestirli ovviamente utilizzo Virtualbricks poiché mi semplifica, e non di poco, la vita.

Il problema

Il problema che voglio affrontare in questo articolo è un problema di semplificazione all’accesso da remoto alle varie macchine virtuali, ovvero: come fare ad accedere, utilizzando SSH, alle varie macchine virtuali utilizzando come nome degli host i nomi delle macchine virtuali che ho impostato su Virtualbricks? E soprattutto questo meccanismo può essere automatizzato, in modo che ogni macchina virtuale, appena viene lanciata, istruisca la macchina host su quale è la combinazione hostname – IP corretta per comunicare con essa?

Il primo passo: l’assegnamento degli indirizzi IP

Data la dinamicità della topologia, impostare indirizzi IP statici è di poca utilità, occorre quindi utilizzare un server DHCP per assegnare gli indirizzi, il che vuol dire che i SO delle macchine virtuali devono essere configurati per prendere l’IP automaticamente via DHCP al boot, e questo è il primo passo.

Secondo passo: il server DHCP

Il secondo passo è l’installazione del server DHCP sulla macchina host. La scelta è caduta su dnsmasq che, tra le altre cose, permette anche di associare uno script che viene lanciato subito dopo la ricezione di una richiesta DHCP al server, il che ci sarà molto utile più avanti. Per quanto riguarda il file di configurazione, esso sarà molto semplice:

interface=tap0
dhcp-range=10.0.0.100,10.0.0.200,255.255.255.0,12h
dhcp-script=/bin/add_hosts.sh

La prima riga specifica su che interfaccia si vuole restare in ascolto, il perché essa sia “tap0″ verrà spiegato più avanti. La seconda è il range di indirizzi IP e la netmask che si vuole utilizzare. Infine viene specificato lo script che deve essere lanciato.

Terzo passo: la topologia

Come indicato dalla figura, la topologia è composta da 5 componenti: tre VM, un VDE Switch e una interfaccia di tap. Quest’ultima in particolare è una interfaccia di rete simulata che funziona come punto di interconnessione tra la rete virtuale e la macchina host. Utilzzandola e assegnandole un indirizzo IP (come se fosse una normale scheda di rete) la macchina host diverrà parte integrante della rete e sarà connessa direttamente alle macchine virtuali. L’interfaccia di tap (e di conseguenza la macchina host nella rete) in questo esempio ha indirizzo 10.0.0.1.

Quarto passo: dove salvare le informazioni su come raggiungere le macchine virtuali?

Le informazioni che devo salvare sono due: hostname e indirizzo IP. Qual’è il posto migliore per salvare questo tipo di informazioni, in modo che siano prioritarie rispetto ai DNS? Ovviamente la risposta è il file /etc/hosts.

Quinto passo: che parametri vengono passati allo script dal server DHCP?

I parametri che il server DHCP invia allo script che è stato configurato per essere eseguito all’arrivo di una richiesta sono 4: il comando (add se è arrivata una richiesta di assegnazione, old se la richiesta per il dato mac address è già stata servita una volta, del per il release), il mac address, l’indirizzo IP assegnato ed l’hostname. Quest’ultimo purtroppo non è sempre inviato da tutti i client DHCP, per questo ho trovato un modo alternativo per recuperare l’hostname nei casi in cui non sia fornito.

Sesto passo: script per il salvataggio delle informazioni

E questa è la parte un po’ più complicata. Ecco a voi lo script che aggiunge automaticamente al file hosts le coppie hostname – indirizzo IP delle varie VM:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110

#!/usr/bin/python
# script created by Francesco Apollonio and released under GNU General Public License version 2
# http://www.ldlabs.org/
# script that add a VM who requests an IP address using the dhcpd to local hosts file
import sys
import subprocess
import string
import time
 
debug_file="/var/log/add_hosts.log"
 
def debug(message):
   message = time.strftime("%d %b %Y %H:%M:%S") + " " + message
   print message
   fd = open(debug_file, "a")
   fd.write(message + "\n")
   fd.close()
 
text=""
for arg in sys.argv:
   text = text +" "+arg
debug(text)   
 
action=sys.argv[1]
ip=sys.argv[3]
mac=sys.argv[2]
hosts="/etc/hosts"
 
# if del action is called exit from this script
if action == "del":
   fd=open(hosts, "r")
   hosts_lines=fd.readlines()
   fd.close()
 
   fd=open(hosts, "w")
   for line in hosts_lines:
      if ip not in line:
         fd.write(line)
 
   debug( "Ok, %s deleted from %s file" % (name, hosts))
   sys.exit(0)      
 
# add address to local hosts file
 
if len(sys.argv) == 5:
   name = sys.argv[4]
   debug("host name from parameters: "+name)
else:
   command = "ps ax | grep /usr/bin/kvm"
   process = subprocess.Popen(command, stdout=subprocess.PIPE, shell=True)
   found = None
   for line in process.stdout.readlines():
      pid=line.split(" ")
      pid = pid[1]
      fd_c = open("/proc/"+pid+"/cmdline", "r")
      lines=fd_c.readlines()
      fd_c.close()
      if len(lines)>0:
         line=lines[0]
         line=string.replace(line, "-", " -")
         line=string.replace(line, "\x00", " ")
      else:
         continue
      if mac in line and "add_host" not in line:
         found = line
         break
   if found is None:
      debug("Ops, no VM with %s found" % mac)
      sys.exit(1)
   parms = found.split(" -")[1:]
   name=False
 
   for par in parms:
      if par.strip().startswith("name"):
         name = par.strip().split(" ")[1]
 
if name is False:
   debug("Ops, VM name not found")
   sys.exit(2)
 
fd=open(hosts, "r")
 
hosts_lines=fd.readlines()
fd.close()
already=False
for line in hosts_lines:
   if name in line:
      already=line
      break
change=False
if already is not False:
   if ip in line:
      debug("Ok, VM already in hosts file")
      sys.exit(0)
   else:
      change=True
 
if change is False:
   fd=open(hosts, "a")
   fd.write(ip + "\t\t" + name +"\n")
else:
   fd=open(hosts, "w")
   for line in hosts_lines:
      if name in line:
         line = ip + "\t\t" + name + "\n"
      fd.write(line)
 
fd.close()
 
debug( "Ok, %s added to %s file" % (name, hosts))

Il funzionamento è abbastanza semplice. In caso di comando “add” o “old” ricevuto dal server DHCP, lo script prima controlla se l’hostname è stato fornito dalla richiesta DHCP,  e in questo caso procede direttamente al salvataggio. Se invece l’hostname non è stato fornito, lo script scansiona la lista dei processi KVM che sono in esecuzione. Poi si procura la command line completa con le quali le macchine virtuali sono state eseguite leggendola dall’apposito file nella cartella /proc (in una prima versione usavo direttamente l’output di ps per ottenere queste informazioni, ma, in determinate circostanze, la command line veniva tagliata, rendendo inutilizzabile lo script, per questo ho optato per recuperare le informazioni da /proc). Una volta ottenuta la command line il gioco è fatto: estraggo il nome della macchina virtuale impostato in Virtualbricks, apro il file hosts controllo che non ci sia già una voce per la macchina virtuale che ha richiesto l’indirizzo; se esiste allora semplicemente aggiorno l’indirizzo IP, se invece non esiste aggiungo una nuova voce.
Per quanto riguarda “del”, invece, apro il file hosts e se vi è l’indirizzo ip specificato, elimino la linea che lo contiene.

Parte sette: conclusioni e sviluppi futuri

Bene l’architettura funziona più che bene (la utilizzo quotidianamente). Questa è ovviamente solo una applicazione per poter creare una “rete di controllo” che permetta una più semplice gestione di un numero variabile di macchine virtuali. Per i prossimi sviluppi restate in ascolto

Ultimamente non scrivo molto per mancanza di tempo, ma questa notizia, visto che mi riguarda da vicino, andava pubblicizzata.

Virtualbricks è ora disponibile nei repository ufficiali di debian sid!

Per chi non lo sapesse Virtualbricks è un software per la gestione di macchine virtuali Qemu/KVM, che permette anche la crezione di topologie complesse composte da più macchine virtuali interconnesse dai componenti VDE, creazione di reti ibride (macchine virtuali e reali nella stessa rete LAN) e distribuite (utilizzando cioè più di una macchina host).

Il sito ufficiale è http://www.virtualbricks.eu/, nel wiki è disponibile un po’ di documentazione (dobbiamo ancora continuare a lavorarci per ampliarla).

Per scaricare l’ultima versione l’indirizzo è http://www.virtualbricks.eu/download.php?latest oppure dalla pagina Launchpad del progetto http://launchpad.net/virtualbrick, a meno che non usiate Debian sid, li ovviamente il comando è:

apt-get install virtualbricks

A presto!

Utilizzando macchine (virtuali e non) remote, mi capita spesso di dover utilizzare VNC per avere accesso al desktop, talvolta serve anche un ambiente grafico. Sono venuto a conoscenza qualche giorno fa di Guacamole, programma che permette di accedere al desktop VNC attraverso un normalissimo browser web che supporti però il tag canvas di HTML5.

Desktop remoto con Guacamole nel browser

Il programma funziona benissimo e velocemente, l’unica cosa un po’ complicata è l’installazione. Per prima cosa occorre installare Tomcat6. Infatti il cuore che permette il tutto è un applicazione in Java che invia al browser le informazioni per poter visualizzare il desktop. Eseguiamo l’installazione:

# apt-get install tomcat6 libvncserver0

Ora che il web server è installato, occorre scaricare il programma da questo link. Dopo aver scompattato l’archivio, quello che ci troviamo davanti sono alcuni file xml (file di configurazione) ed un war (archivio contenente l’applicazione vera e propria). Questa è la procedura d’installazione:

# cp guacamole-users.xml /etc/tomcat6/
# mkdir -p /var/lib/guacamole
# cp guacamole.war /var/lib/guacamole/
# cp guacamole.xml /etc/tomcat6/Catalina/localhost/

I file sono ora installati nel webserver ma occorre configurarli. In particolare in /etc/tomcat6/guacamole-users.xml troviamo la coppia user:password che ci viene chiesta all’apertura dell’applicazione, non si tratta della password di VNC ma di una password propria dell’applicazione. Nel file /etc/tomcat6/Catalina/localhost/guacamole.xml invece sono contenute l’informazioni del server VNC:

<Parameter name="host" value="localhost"/>
<Parameter name="port" value="5901"/>
<Parameter name="password" value="PASSWORD"/>

I parametri che ci interessano sono questi tre elencati sopra, e vanno riempiti con i dati del server VNC. In particolare per calcolare la porta, occorre ottenere il numero desktop virtuale avviato (:1 ad esempio) e sommarlo a 5900. In questo caso quindi il server a cui ci connettiamo è :1. Per avviare un nuovo server VNC ovviamente digitiamo il comando:

$ vncserver
New 'X' desktop is home:1

Se è la prima volta che avviamo un server VNC, ci verrà chiesta la password per l’accesso (non è obbligatorio inserirla), quella che deve essere inclusa nel file guacamole.xml. Ora riavviamo il server web:

# service tomcat6 restart

e colleghiamoci all’applicazione tramite il nostro browser (occhio ad utilizzare uno compatibile con il tag CANVAS di HTML5, chromium/chrome o Firefox 5 vanno benissimo) utilizzando il link:

http://localhost:8080/guacamole/

ci verrà prima richiesto di effettuare l’autenticazione del programma. Se non avete cambiato guacamole-users.xml l’username è ‘guacamole‘ e la password ‘changeme‘, ovviamente è fortemente consigliato cambiarla. Dopo aver inserito anche la password del server VNC (se ovviamente è stata impostata):

Ecco fatto ora accedere al vostro server VNC sarà molto più semplice, infatti impostando ad esempio come porta di Tomcat la 80, potrete accedere al desktop remoto in tranquillità anche in presenza di proxy non troppo permissivi!

Buon lavoro!

Sviluppano spesso siti web di vario genere, mi sono trovato a dover gestire un form html con Ajax. Il problema non è stato tanto per i dati testuali normali, quanto principalmente perchè dovevo trasferire un file via AJAX.

Lo strumento che ho utilizzato è JQuery Form Plugin. Tre parole per descriverlo? Semplice, rapido e funzionante!

Per prima cosa vediamo la pagina HTML (con l’annesso form per l’upload):

<html>
	<head>

		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
		<script type="text/javascript" src="jquery-1.5.1.min.js" ></script>
		<script type="text/javascript" src="jquery.form.js" ></script>
		<script type="text/javascript" src="scripts.js" ></script>
		</script>
		<title>Pagina di prova</title>

	</head>
	<body>

		<form action="file_upload.php" method="post"
			enctype="multipart/form-data" id="upload">

			<label for="file">Filename:</label>
			<input type="file" name="file" id="file" /><br />
			<input type="submit" id="send_file" value="Aggiungi" />

		</form>

	</body>
</html>

Ovviamente, come si può vedere analizzando l’html, occorrono altri due file. Il primo è il file javascript che ci permetterà di gestire l’invio lato client. Il secondo è il file in PHP che ci permette di gestire l’upload dal lato server. Analizziamo il file javascript (script.js):

1
2
3
4
5

$(document).ready(function() {
	$("#upload").ajaxForm(function(resp) {
		alert(resp);
	});
});

Come si può facilmente capire il funzionamento è semplice. Basta associare l’AjaxForm all’id del form html ed il gioco è fatto. Ovviamente nella funzione di risposta si può effettuare qualsiasi operazione, utilizzando la variabile resp che contiene l’output della pagina che si occupa dell’upload lato server. Ecco il codice PHP (file_upload.php):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php
// CONTROLLO DEI PARAMETRI!
$path="PERCORSO_DOVE_SALVARE_IL_FILE/";
if ($_FILES["file"]["error"] > 0) {
	echo "ERROR";
} else {
	if (file_exists($path . $_FILES["file"]["name"])) {
		echo "File already exists.";
	} else {
		move_uploaded_file($_FILES["file"]["tmp_name"], $path .  $_FILES["file"]["name"]);
		echo "OK. File uploaded.";
	}
}
?>

che semplicemente salva il file nella directory specificata e ritorna un messaggio che indica se l’operazione è andata a buon fine. Ricordatevi ovviamente, se utilizzate lo script in PHP per il vostro sito, di eseguire le operazioni di controllo dei parametri in ingresso via POST.

Come potete vedere è veramente una passeggiata, buon lavoro!

Abbiamo visto come caricare sulla scheda un firmware che già abbiamo, ma come possiamo compilarne uno noi?

Layout della board

Il primo passo è ovviamente ottenere il compilatore, chi ha letto il vecchio articolo avrà sicuramente notato, in fondo alla pagina, la presenza del link ad un compilatore ARM, è proprio quello che utilizzeremo per creare il firmware da caricare:

wget http://www.codesourcery.com/sgpp/lite/arm/portal/package8734/public/\
arm-none-eabi/arm-2011.03-42-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
tar jxvf arm-2011.03-42-arm-none-eabi-i686-pc-linux-gnu.tar.bz2

Facciamo attenzione alla directory che utilizziamo per contenere il compilatore, dato che ci servirà per permetterci di raggiungerlo, infatti occorre impostare una variabile del nostro terminale con il percorso esatto. Dal terminale dove successivamente eseguiremo la compilazione digitiamo:

export CROSS_COMPILE=/PERCORSO_VERSO_IL_COMPILATORE/arm-2011.03/bin/arm-none-eabi-

In alternativa possiamo aggiungere la riga all’interno del file ~/.bashrc in modo da non doverlo riscrivere ogni volta.

Ora non ci resta che trovare qualcosa da compilare. Per i miei esperimenti utilizzo il mini-sistema operativo creato da Alessandro Rubini per processori Cortex-M3 che si può scaricare da questo indirizzo. Questo sistema è un buon inizio per inziare a muovere i primi passi con la board (sto inziando anche io con questo), infatti permette di avere un sistema che si avvia e sul quale è possibile effettuare delle aggiunte. Una volta scaricato e scompattato, occorre prima effettuare una modifica al main.c:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#include <stdint.h>
#include "io.h"
 
void main(void)
{
 volatile int i;
 int on = 0;
 
 /*
 * Call the mimmo application. Turn this if to false if you want to
 * run the older code that just flashes leds
 */
 if (0) {
 extern void do_mimmo(void);
 do_mimmo();
 }
 
 /* Older led-toggling application */
 *(volatile uint32_t *)0x50038000 = 0xf; /* port C: all 4 out */
 
 while (1) {
 puts("stuff\n");
 if (++on & 1)
 *(volatile uint32_t *)0x5003003c = 0xf;
 else
 *(volatile uint32_t *)0x5003003c = 0;
 for (i = 0; i < 1000*1000; i++)
 ;
 }
}

In particolare occorre modificare la riga 13, non facendo entrare il programma all’interno dell’if, cambiano quindi l’1 in 0. Dopo aver salvato il file, non ci resta che lanciare il comando

make

dalla cartella estratta per eseguire la compilazione. Come si può leggere dal pdf allegato ai sorgenti, vengono creati due file bin, uno per l’esecuzione da ROM e uno per l’esecuzione da RAM. Dato che per programmare la RAM è necessario usare UART, quello che interessa a noi e che quindi dobbiamo trasferire sulla board è il file m3c.rom.bin:

mdel c:firmware.bin
mcopy m3c.rom.bin c:new.bin

Per chi non capisse cosa sono questi ultimi due comandi, consiglio la lettura del precedente articolo che spiega, tra l’altro, come configurare mtools per permettere il riconoscimento della board. Dopo aver resettato la board (togliere il jumper dai piedini JMP BLD_E e premere il tasto di Reset) il nuovo programma appena compilato e caricato verrà eseguito, facendo lampeggiare 4 led.

La prossima volta vedremo come accedere ai registri di configurazione e accendere dei led a piacere.