原创 當前時間節點的LiteOS評述 2018.9

   從設計就是爲了低速芯片,ARM-M0/3/7等等~~~~ 1.也就沒有虛擬、物理內存的區別, 2.也就沒有內核態等區別 3.於是開發的業務代碼其實是寫到了LiteOS的一部分 本質上是一個大程序。。。   但是,LiteOS

原创 EL2異常捕獲設置-HCR_EL2

前言 之前寫了一點關於異常的東西,比較淺顯的勾勒了一下異常的全貌,就像一幅20萬像素的地球全景照,20萬像素也就是能畫出藍白相間的圓;畫成這個樣子當然不會是我這種對吹牛都要持證上崗的人的作風。再寫一篇或許更繁複但只求僅能部分指明要害的文

原创 我認爲微內核的意義(4)-分析微內核效率

 我在沒做過實際測試的情況下論述微內核效率的問題似乎有所不妥,我提出效率的問題也是有機制上的依據的,因爲我能在兩個問題上提出優化的空間。這兩個問題都是基於目前架構最優秀的zircon微內核(我認爲),或是形式化驗證過得sel4微內核。 1

原创 fuchsia虛擬化進程評估 2018.10

 fuchsia是一個基於微內核zircon的富操作系統   ————————————————fuchsia的VMM————————————————   1.fuchsia內建的模擬器Machina庫 基於zircon,提供虛擬外設,集

原创 seL4微內核操作系統初期總結 2018.10

 [email protected]衷心感謝您的拜讀,希望我的分析對您有所幫助;另外,若您發現本文分析錯誤,或seL4版本更新特性變化,您可以發郵件告訴我,以便我能及時更新。考慮到關於信息量較多,在閱讀過程中難免出現語義難明的詞彙,對於前文出現

原创 Hypervisor這個層次對TLB的使用與EL0/1比有限制嗎

我在利用虛擬化這篇文章中出現了一個錯誤,這是一個不起眼,但是細思恐極,再細思安心的錯誤,我有這樣一句話: 對於在EL2中,這條尤其重要,很多cortex都會有IPA-PA相對於VA-PA的縮水,所以EL2中的代碼要怎麼做也是需要思考的問

原创 DMA的經典解讀

Today all computers are architectured the same way: a central processor and a number of peripherals. In order to exchan

原创 linux 圖形棧的演進

1. 最開始,就是一段代碼直接訪問圖形卡:XFree8 server;root運行XFree86 server,使之從用戶態訪問圖形卡,不需要內核支持2D加速,非常容易在各操作系統間移植,不需要內核組件,就像這樣: 圖片發自簡書App

原创 在噩夢中驚醒,Hypervisor這個層次對TLB的使用與EL0/1比有限制嗎

我在利用虛擬化這篇文章中出現了一個錯誤,這是一個不起眼,但是細思恐極,再細思安心的錯誤,我有這樣一句話: 對於在EL2中,這條尤其重要,很多cortex都會有IPA-PA相對於VA-PA的縮水,所以EL2中的代碼要怎麼做也是需要思考的問

原创 GICv3-4宏觀視圖

按照主題來講,首先是GIC本身這個大主題的拆解。 從功能器件來看 GICv3-4已經開始對虛擬化提供大量支撐,從物理硬件上,按照功能器件可以拆解成:Distributor、ITS、Redistributor、CPU interface的集

原创 iptables的背後

每次修改iptables爲子設備做轉發上網都要瞎搜索很久,iptables太踏馬的複雜了,這次搜索完我一定要寫點東西記住哪條規則讓子設備上了網。 背景: 一臺獨設備A,只連接B設備; 一臺能上網設備B,有網卡與A連接; B設備B1網卡與A

原创 原子操作、MESI和內存屏障引起我對鎖理解的智障

前言: 先向已經貢獻大量公開文檔的前輩們致敬,不管是中文的、英文的;再鄙視一下ARM文檔中關於DMB之類的文字,赤裸裸的鄙視,我截一段大家感受下:“The DMB instruction ensures that all affected

原创 DRM的GEM

GEM(Graphics Execution Manager)主要完成:內存申請釋放、指令執行、執行命令時的光圈管理(what?!)。緩存對象的申請主要與linux提供的shmem層相關。設備相關操作如指令執行、pinning、buffe

原创 重用page->mapping

翻譯自LWN.NET 因爲要在struct page這一小段內存中填入最大量的信息,linux kernel中的結構體page是最複雜的結構體之一。struct page中每一個區域都重度過載,開發者們都傾向於:若能避免,絕不對struc

原创 三代DRI的變化

DRI1 首先要說,DRI1已經不在考慮使用了,這裏說一下它的原理: DRI1由於當時圖形卡內存大小,只有一個屏幕front buffer+back buffer由所有DRI clients和X server使用,front buffer