Alignment & Padding (English)

In order to prevent alignment exception, compiler will pad some empty data into memory to let it fit the alignment restriction.
Here is an example in C:

If we declare a structure like this:

struct align{
   char a;
   int b;
   short int c;
};

We will consider that it will use 7 bytes. However, because it has to prevent alignment exception,compiler will add some padding to let it fit 32-bit (i.e. 4 bytes). It may consider like this:

struct align{
   char a;
   char padding_0[3]; // add by compiler, programmer cannot use   
 
   int b;
   short int c;
   char padding_1[2]; // add by compiler, programmer cannot use   
};

Its memory allocation will look like this:
(放圖)

It is obvious to see that padding will waste lots of memory space. As a result, in order to save memory space, sometimes compiler also provide some pragma to let programmer to add in their code, and compiler can use these pragma to let compiler reallocate the memory allocation of this structure.

Here is an example:

#pragma pack(push)
#pragma pack(4)
        struct align
        {
                char a; //1 byte
                int b;  //4 bytes
                short int c;  //2bytes
        };
#pragma pack(pop)

It will let compiler to reallocate its memory allocation and use memory more efficiently.

This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Taiwan License.

Ref: http://en.wikipedia.org/wiki/Data_structure_alignment

About me

Junior System Software Programmer

M.S. in CS
B.S. in EE

In EECS area

Major research interest: Virtualization, Kernel
Minor research interest: Computer Architecture, Compiler, Other system software
More minor research interest: Digital Signal Process
Just for fun: Probability, Electromagnetism

Familiar develop environment:
Processor: ARM, x86, TI-C64xx;
OS: Linux, Mac OS X;
Compiler: GCC, Clang-LLVM

Preferred Software License: BSD License
Preferred Kernel: XNU ( Darwin Kernel )
Preferred Compiler: LLVM


於EECS領域研究興趣：
主要研究作業系統核心、虛擬化技術。對於計算機架構與其他系統軟體亦有相當的研究興趣。因過去大學時的經驗，對DSP、機率、電磁相關領域的知識，亦會作為業外新知來吸收。

熟悉的開發平台與環境：
在處理器架構上，主要對ARM有相對較高的熟悉，對x86、TI-C64xx系列亦有些微了解。在作業系統環境上，主要開發對象為Linux，主要使用環境為Mac OS X與Ubuntu。在編譯器環境上，傳統上使用GCC，最近亦對LLVM有興趣接觸與使用。

C語言：函式的Coding-style

傳統上，我們學C語言的時候，大多使用的寫法方式大多如下：

int main(int argc,char **argv)
{
 ... 
}

會直接把傳進函數的參數的type與名稱打在函式名稱右邊的小括弧中。

也因此，有些人的Coding-style，會傾向把函式的左括弧和函式名稱放在同一行，就例如這樣：

int main(int argc,char **argv) {
 ... 
}

這樣的寫法並不違背C語言的語法，拿去編譯器編譯也當然會過，說實在的如果只是寫給自己看、或是工作的環境並沒有特別指定Coding-style的話，只要自己習慣並沒有什麼不好。

然而，如果開發OpenSource相關專案的人，或多或少都會和開源社群交流，也會去trace甚至更改Source code，在這樣的狀況下，規範一個固定的Coding-style實屬必要。以Linux社群為例，就有著一份 "Documentation/CodingStyle and Beyond" (http://kernel.org/doc/ols/2002/ols2002-pages-250-259.pdf) 來約束大家的Coding-style，以便其他完全素昧平生的開發者，也能輕易的(?)看懂你寫的原始碼。

在"Documentation/CodingStyle"這篇文章當中，對函式寫法的標準是：

int foo(int x)
{
 ... 
}

一開始我在看到這段的時候，覺得只是一個換行符號的差別，僅是社群內自行約束的習慣而已，並不以為意。

然而，後來因緣際會看到一些特殊的函式寫法例子之後，就覺得將左括弧換行是有其必要性，我們來看一個例子：

int main(argc,argv)
    int argc;
    char **argv;
{
 ... 
}

上面的程式碼是在GNU Bash當中，實作printenv指令時，main function的寫法。從上面我們可以看到，他在函式名稱旁邊的小括弧當中，其傳遞進函式的參數，僅將其名字列出，並不指定type，而是換行之後才將其宣告寫入，最後再換行打入左大括號。

初次看到此種寫法之時，會以為這個寫法是有問題的，但將此種寫法拿去編譯器編譯，並不會出現問題，此種寫法是早期C語言的寫法，而在此寫法中，函式變數旁的小括弧和負責包住函式本體的大括弧中間，確實有可能出現其他內容，甚至有換行之必要，故在此寫法下，會希望負責包住函式本體的左大括弧，和括住傳入函式參數的小括弧中間有需要換行，而此習慣便延續到現在Linux kernel的Coding-style當中。

This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Taiwan License.

Introduction to Xen-ARM (1) : Brief introduction to Xen-ARM

We has studied on virtualization for years. And we want to share some interesting information on virtualization nowadays. And we also want to have communicate with others who are also interesting in virtualization. The following article is a summary from the Xen-ARM's website and related public documents.




Section 1: Brief introduction to Xen-ARM

Xen-ARM is a hypervisor which is based on ARM architecture. It means that you can run different operating system at the same time when you are using hypervisor. In the category of hypervisor, Xen-ARM is categorized as Type-1 hypervisor[1] . Besides, it's necessary to patch guest OS when you want to use it running on Xen-ARM.
i.e. Xen-ARM is using para-virtualization.

Xen-ARM is based on Xen[2] which is a hypervisor running on x86-platform. Most of  developers of Xen-ARM are come from Samsung instead of XenSource which is main maintainer of Xen.

In the early stage of developing time of Xen-ARM, they had only supported FreeScale develop board. However, Xen-ARM has support several develop boards, such as XScale PXA310, Versatile, Realview-PB, Cortex-A9, etc. Meanwhile, Xen-ARM also supports Goldfish which is a QEMU emulator patched for Android. Otherwise, in software part, Xen-ARM had only supported for Linux 2.6.11 as guest OS in the early stage of developing time of Xen-ARM. But, Xen-ARM has supported for Linux 2.6.11, 2.6.18, 2.6.21, 2.6.24, 2.6.27 as guest OS nowadays.

虛擬化技術淺論：(1) What is virtualization?

虛擬化技術(Virtualization)於近年雲端運算(Cloud computing)逐漸熱門之後，漸漸廣為討論。實作雲端運算的基礎架構的方式很多，並非得利用虛擬化技術不可，而虛擬化技術除了在雲端運算的應用外，也有著許多其他的應用層面。

本系列文章是整理作者對虛擬化技術的所見所聞，希望讓讀者能夠了解虛擬化技術的前世今生，並以一個更廣泛的角度來看虛擬化技術。當然如果敘述中有缺漏或理解錯誤的部份，也歡迎諸位指教。

What is "virtualization"?

要談虛擬化技術(Virtualization)，或是要談虛擬機器(Virtual Machine)是什麼之前，我們可以先來探討「虛擬」這個字眼在電腦科學領域到底有什麼含義？

在電腦科學領域當中，有著許多帶有"Virtual"字眼的技術，舉凡「虛擬記憶體」(virtual memory)、「Java虛擬機」(Java Virtual Machine)、「虛擬私人網路」(Virtual Private Network)。這些看似無關的技術之間，都有著共同的"virtual"字眼。他們雖然在電腦科學當中分屬不同子領域，但是都蘊含著「把本來不是......的東西，透過軟體來讓他們變成都是......」，例如VPN，他把本來在實體網路上並不是在同一個網域當中的電腦，透過軟體的方式讓他們看似待在同一個網域。又或像JVM，本來在不同種CPU、OS運行的可執行檔都要事先編成對應的Native code才能執行，例如要在Windows for x86、Linux for x86、Linux for ARM需要分別編成三種不同的可執行檔才能運行，但是透過JVM，我們能夠只要編成一樣的Bytecode，在執行的時候再透過JVM去轉成Native code即可，透過JVM我們把本來不是同一種的Runtime（處理器、OS不同），讓他看似變成同樣的Runtime。

Why should we "virtualize" something?

那為何我們會需要虛擬化技術呢？本來既有的硬體配置不好嗎？為什麼沒事要用軟體去把實體不存在的環境用軟體模擬出來呢？

通常我們會使用虛擬化技術主要著眼於下列幾點的好處：

• 資源分享：
  以RAID為例，我們可以把兩顆實體500GB的硬碟透過RAID讓使用者看成1TB去存取，那假設本來每顆硬碟都只剩下30GB的容量，亦即兩顆共剩60GB的容量，但是使用者想放一個50GB的檔案卻無法放入，透過RAID把儲存空間虛擬化，使用者就可以把50GB的檔案放入，而讓後端的虛擬化技術去處理檔案區塊放置的問題，這就達到了資源分享的效果。
• 安全性考量：
  以JVM為例，我們可以把網路上下載來不確定安不安全的程式放在JVM裡面跑，由於JVM提供了一整套的Runtime environment，在裡面跑的程式不會直接和OS與硬體溝通，這也增加了一層防護，若在JVM裡面跑的程式Crash或是想去越權探知OS當中的訊息，這些越權行為都會被JVM擋住。
• 彈性：
  以JVM為例，用Java寫程式的程式設計師，不需要為了Windows for x86、Linux for x86、Linux for ARM分別編出三套不同的執行檔再分送出去，只需要編出一組Bytecode，就能在各種執行環境下執行。在程式開發的階段，也不需要去思考這隻程式是在什麼OS、什麼處理器下運行，為高階語言程式開發者增加了許多彈性。
• ...

虛擬化技術的分類


目前談虛擬化技術通常大多指涉系統虛擬化（System virtualization），意即像VMware、Parallels、Xen、KVM等System VM，然而系統虛擬化並非虛擬化技術的全部，通常我們談虛擬化技術多分為下列三種：

• Process virtualization：
  是以讓一個Process能夠跨平台運行為目標的虛擬化技術。例如Java Virtual Machine、Apple Rosetta（Apple設計能讓原本運行在PowerPC處理器上的可執行檔能夠無痛運行在x86的處理器上的Process VM）
• Device virtualization：
  是針對周邊裝置來進行虛擬化，用軟體來模擬周邊裝置，或是將實體上為多台的周邊裝置透過軟體讓使用者看起來只有一台等等。例如：RAID、VPN
• System virtualization：
  是以讓一個Operating System能夠運行在別的OS上，或是能夠讓一台實體機器同時運行多個OS為目標。例如：VMware、Parallels、Xen、KVM等

我們接下來將會以System virtualization為繼續討論的主題。

To be continue...


本文同步發佈在http://nthusslab.blogspot.com/

This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Taiwan License.

Xen-ARM簡介

（一）簡介 

Xen-ARM是一種在ARM架構上實作的Hypervisor，能在一台機器上同時運行多個作業系統。在Hypervisor的分類當中，屬於Type1的Hypervisor[1] ，而在Hypervisor上運行的Guest OS是需要被Patch過的，在系統虛擬化技術分類上屬於Para-virtualizaiton（半虛擬化）。

Xen-ARM是基於Xen [2] （一款在x86平台上開發的Hypervisor）。不同於Xen是由XenSource公司所主導，Xen-ARM的開發者是以Samsung為主體，而近幾年來有關Xen-ARM的Paper多由Samsung所發表。

談到Xen-ARM與Xen社群的關係，自兩者官網的關係來看，Xen-ARM的官網是被當成Xen官網上的一個分頁，而在XenWiki當中，也有一頁是寫有關Xen-ARM的內容，顯見Xen社群是知道有Xen-ARM的存在，並且是近乎把Xen-ARM當做Xen一部分的方式放置在Xen的官網。然而，Xen-ARM迄今仍未被整合進Xen的主線當中，依據Xen-ARM官網上的說法，他們希望能於2012年進入Xen的主線。

在早期Xen-ARM開發時，只支援FreeScale的開發板，而至今Xen-ARM已經支援Xscale PXA310, Versatile, Realview-PB, Cortex-A9等SoC平台的硬體架構，也支援Goldfish（QEMU emulator patched for Android）。在Guest OS的部份，早期僅支援2.6.11的版本，時至今日，Xen-ARM官方目前已支援Linux v2.6.11, v2.6.18, v2.6.21, v2.6.24, v2.6.27的版本。

（二）Xen-ARM歷史發展

於2007年的Xen秋季高峰會上，三星提出他們成功把Xen移植到ARM處理器架構之下，三星把此計畫稱之為Xen-ARM。在2007年當時，三星團隊在ARM9（ARMv5）的FreeScale開發板上實作Xen-ARM，當時他們是以Xen-3.0.2為基礎移植至FreeScale上，在Hypervisor上運行的Guest OS則是Linux 2.6.11。

然而，雖然2007年當時三星就有到Xen Summit Autumn發表Xen-ARM當時開發的成果，但真正開放原始碼的時間則是到2008上半年才有開放。於08年所釋出的第一版Xen-ARM，僅支援FreeScale的硬體平台，其所支援的Guest OS也僅為miniOS。

也因為沒有釋出Patch過能在Guest mode運行的Linux實有不便，因此於同年（2008年）的下半年，三星又釋出了第二版的Xen-ARM，在這個版本當中，即有提供Para-virtualized Linux 2.6.24來做為Guest OS，同時也釋出了Xen tool。

於2009年下半年，Xen-ARM推出第三版，當中最主要的更新是支援ARM11MPCore（ARMv6）的平台。最新的版本則是2010年推出的版本，此版本已經支援Cortex-A9（ARMv7）的硬體平台，Guest OS也已經有支援Linux v2.6.11, v2.6.18, v2.6.21, v2.6.24, v2.6.27的版本。

（三）Xen-ARM的架構[3]

Xen-ARM的架構與Xen相仿，是在硬體上直接架一層Hypervisor來實際管控所有硬體資源，然後Guest OS再架上Guest OS。當Guest OS在執行Non-sensitive instructions時，由於此種指令不會更動到關鍵的硬體資源，故即讓其native-run。然而當執行到sensitive instruction時，由於此種指令會更動到系統的關鍵資源，而我們不希望Guest OS有權直接存取硬體資源，故此時我們會讓sensitive instruction強制trap進Hypervisor，交由Hypervisor來處理，而此種行為我們會稱為Guest OS發一個hyper-call進hypervisor，如同在OS中我們會稱user-space程式會發system-call進kernel一樣。


1. CPU virtualization

在Xen-ARM當中將CPU的指令分為三種：Xen-ARM mode、virtual kernel mode與virtual user mode，分別給hypervisor、kernel-space of guest OS、user-space of guest OS使用，而對應實際ARM的instruction mode分別為supervisor mode、user mode與user mode。我們可以看到virtual kernel mode和virtual user mode皆是使用user mode，即non-privilege mode，故實際上virtual kernel mode和virtual user mode的差別只是邏輯上的分別而已。


2. Memory virtualization

我們知道在Memory virtualization當中，我們需要於Hypervisor中建立一套機制，能讓Guest OS能夠管理自己的Memory，但又不會直接接觸到實際的記憶體配置。在Xen-ARM當中也利用一樣的技術，在Xen-ARM當中去將實體記憶體切割成數塊，分別定址給各個VM，還有一部分的記憶體會被分配給Hypervisor本身


3. I/O virtualization

在Xen-ARM的架構上，他會把Guest OS切成兩種，一種是負責其他VM和Hypervisor溝通的VM，我們稱其為Dom0或VM0，另一種VM則是無法直接對Hypervisor溝通的VM，我們稱呼其為DomU（在一個Hypervisor上只有兩個VM運行時，我們也多直接成其為Dom1或VM1）。當VM1發出一個I/O request時，他會透過他自己的I/O裝置驅動程式打入Xen-ARM之中，但Xen-ARM只幫忙傳遞訊息給VM0，由VM0當中的Back-end driver去負責模擬虛擬的I/O裝置給VM1使用，而真正接觸到實際硬體的則是交由VM0當中的Native driver去負責。


本文同步發佈在http://nthusslab.blogspot.com/

This work is licensed under a Creative Commons Attribution-NonCommercial 3.0 Taiwan License.