इस लेख में, हम यह पता लगाएंगे कि हमारे कोर में पेज मेमोरी सपोर्ट कैसे लागू किया जाए। सबसे पहले, हम विभिन्न तरीकों का अध्ययन करेंगे ताकि भौतिक पृष्ठ तालिका के फ्रेम कर्नेल के लिए उपलब्ध हो जाएं, और उनके फायदे और नुकसान पर चर्चा करें। फिर हम एड्रेस ट्रांसलेशन फंक्शन और नया मैपिंग बनाने के फंक्शन को लागू करते हैं।

गिटहब पर प्रकाशित लेखों की यह श्रृंखला। यदि आपके कोई प्रश्न या समस्याएं हैं, तो वहां संबंधित टिकट खोलें। लेख के सभी स्रोत इस सूत्र में हैं ।

पेजिंग के बारे में एक अन्य लेख?
यदि आप इस चक्र का अनुसरण करते हैं, तो आपने जनवरी के अंत में "पृष्ठ मेमोरी: उन्नत स्तर" लेख देखा। लेकिन पुनरावर्ती पृष्ठ तालिकाओं के लिए मेरी आलोचना की गई । इसलिए, मैंने फ़्रेम को एक्सेस करने के लिए एक अलग दृष्टिकोण का उपयोग करते हुए, लेख को फिर से लिखने का फैसला किया।

यहाँ एक नया विकल्प है। लेख अभी भी बताता है कि कैसे पुनरावर्ती पृष्ठ तालिकाएं काम करती हैं, लेकिन हम एक सरल और अधिक शक्तिशाली कार्यान्वयन का उपयोग करते हैं। हम पिछले लेख को नहीं हटाएंगे, लेकिन इसे पुराने के रूप में चिह्नित करेंगे और इसे अपडेट नहीं करेंगे।

मुझे आशा है कि आप नए विकल्प का आनंद लेंगे!

सामग्री

परिचय

पिछले लेख से, हमने पेजिंग मेमोरी के सिद्धांतों और x86_64 पर चार-स्तरीय पृष्ठ तालिकाओं के बारे में सीखा। हमने यह भी पाया कि लोडर पहले से ही हमारे कर्नेल के लिए पृष्ठ तालिका पदानुक्रम सेट करता है, इसलिए कर्नेल वर्चुअल पतों पर चलता है। इससे सुरक्षा बढ़ जाती है क्योंकि स्मृति तक अनधिकृत पहुंच के कारण भौतिक मेमोरी को बेतरतीब ढंग से बदलने के बजाय पृष्ठ दोष हो जाता है।

समाप्त हो गया लेख हमारे कर्नेल से पृष्ठ तालिकाओं तक पहुंचने में सक्षम नहीं है, क्योंकि वे भौतिक मेमोरी में संग्रहीत हैं, और कर्नेल पहले से ही आभासी पतों पर चल रहा है। यहां हम विषय को जारी रखते हैं और कर्नेल से पेज टेबल के फ्रेम तक पहुंचने के लिए विभिन्न विकल्पों का पता लगाते हैं। हम उनमें से प्रत्येक के फायदे और नुकसान पर चर्चा करेंगे, और फिर हमारे कोर के लिए उपयुक्त विकल्प चुनेंगे।

बूट लोडर समर्थन की आवश्यकता है, इसलिए हम इसे पहले कॉन्फ़िगर करेंगे। फिर हम एक फ़ंक्शन को कार्यान्वित करते हैं जो भौतिक पतों में आभासी पतों का अनुवाद करने के लिए पृष्ठ तालिकाओं के पूरे पदानुक्रम के माध्यम से चलता है। अंत में, हम सीखेंगे कि पेज टेबल में नए मैपिंग कैसे बनाएं और नए टेबल बनाने के लिए अप्रयुक्त मेमोरी फ्रेम को कैसे खोजें।

निर्भरता अद्यतन

इस आलेख में आपको bootloader संस्करण 0.4.0 या उच्चतर और x86_64 संस्करण 0.5.2 या उससे अधिक निर्भरता में पंजीकृत करने की आवश्यकता है। आप Cargo.toml में निर्भरता को अपडेट कर सकते हैं:

 [dependencies] bootloader = "0.4.0" x86_64 = "0.5.2"

इन संस्करणों में परिवर्तन के लिए, बूटलोडर लॉग और x86_64 लॉग देखें ।

पृष्ठ तालिकाओं तक पहुंच

कर्नेल से पेज टेबल एक्सेस करना इतना आसान नहीं है जितना यह लग सकता है। समस्या को समझने के लिए, पिछले लेख के चार स्तरीय तालिका पदानुक्रम पर एक और नज़र डालें:

महत्वपूर्ण बात यह है कि प्रत्येक पृष्ठ प्रविष्टि अगली तालिका का भौतिक पता संग्रहीत करती है। यह इन पतों के अनुवाद से बचता है, जो प्रदर्शन को कम करता है और आसानी से अंतहीन छोरों की ओर जाता है।

समस्या यह है कि हम सीधे कर्नेल से भौतिक पतों तक नहीं पहुँच सकते हैं, क्योंकि यह वर्चुअल पतों पर भी काम करता है। उदाहरण के लिए, जब हम एड्रेस 4 KiB , तो हम वर्चुअल एड्रेस 4 KiB तक पहुंचते हैं, न कि उस भौतिक पते पर, जहां 4 वें स्तर के पेजों की तालिका संग्रहीत है। यदि हम 4 KiB के भौतिक पते तक पहुंचना चाहते हैं, तो हमें कुछ आभासी पते का उपयोग करने की आवश्यकता है, जो इसमें अनुवादित है।

इसलिए, पृष्ठ तालिकाओं के फ़्रेमों तक पहुंचने के लिए, आपको इन फ़्रेमों के लिए कुछ वर्चुअल पेजों को मैप करने की आवश्यकता है। इस तरह की तुलना बनाने के लिए विभिन्न तरीके हैं।

पहचान मानचित्रण

एक सरल समाधान सभी पृष्ठ तालिकाओं का समान प्रदर्शन है ।

इस उदाहरण में, हम फ्रेम के समान प्रदर्शन को देखते हैं। पृष्ठ तालिकाओं के भौतिक पते एक ही समय में मान्य आभासी पते हैं, जिससे हम आसानी से सभी स्तरों के पृष्ठ तालिकाओं तक पहुंच सकते हैं, जो रजिस्टर सीआर 3 से शुरू होते हैं।

हालांकि, यह दृष्टिकोण वर्चुअल एड्रेस स्पेस को अव्यवस्थित करता है और मुफ्त मेमोरी के बड़े सन्निहित क्षेत्रों को खोजना मुश्किल बनाता है। मान लीजिए कि हम उपरोक्त आकृति में 1000 KiB वर्चुअल मेमोरी क्षेत्र बनाना चाहते हैं, उदाहरण के लिए, किसी फ़ाइल को मेमोरी में प्रदर्शित करना । हम 28 KiB क्षेत्र से शुरू नहीं कर सकते, क्योंकि यह 1004 KiB पर पहले से ही मौजूद पृष्ठ पर टिकी हुई है। इसलिए, आपको तब तक आगे देखना होगा जब तक कि हम एक उपयुक्त बड़े टुकड़े को न पा लें, उदाहरण के लिए, 1008 KiB साथ। खंडित मेमोरी में उतनी ही विखंडन की समस्या है।

इसके अलावा, नए पृष्ठ तालिकाओं का निर्माण अधिक जटिल है, क्योंकि हमें उन भौतिक फ़्रेमों को खोजने की आवश्यकता है जिनके संबंधित पृष्ठ अभी तक उपयोग नहीं किए गए हैं। उदाहरण के लिए, हमारी फ़ाइल के लिए, हमने 10008 kB वर्चुअल मेमोरी का एक क्षेत्र आरक्षित किया है, जिसका पता 1008 KiB । अब हम 1000 KiB और 2008 KiB बीच भौतिक पते के साथ किसी भी फ्रेम का उपयोग नहीं कर सकते, क्योंकि इसे पहचान के रूप में प्रदर्शित नहीं किया जा सकता है।

फिक्स्ड ऑफसेट नक्शा

वर्चुअल एड्रेस स्पेस को अव्यवस्थित करने से बचने के लिए, आप पृष्ठ तालिकाओं को एक अलग मेमोरी क्षेत्र में प्रदर्शित कर सकते हैं । इसलिए, मैपिंग की पहचान करने के बजाय, हम वर्चुअल एड्रेस स्पेस में एक निश्चित ऑफसेट के साथ फ्रेम को मैप करते हैं। उदाहरण के लिए, ऑफसेट 10 TiB हो सकते हैं:

पृष्ठ तालिकाओं को प्रदर्शित करने के लिए विशुद्ध रूप से वर्चुअल मेमोरी की इस रेंज को आवंटित करके, हम समान डिस्प्ले की समस्याओं से बचते हैं। वर्चुअल एड्रेस स्पेस के इतने बड़े क्षेत्र का संरक्षण केवल तभी संभव है जब वर्चुअल एड्रेस स्पेस भौतिक मेमोरी के आकार से बहुत बड़ा हो। x86_64 यह कोई समस्या नहीं है क्योंकि 48-बिट एड्रेस स्पेस 256 TiB है।

लेकिन इस दृष्टिकोण का नुकसान यह है कि प्रत्येक पृष्ठ तालिका बनाते समय, आपको एक नई मैपिंग बनाने की आवश्यकता होती है। इसके अलावा, यह अन्य पता स्थानों में तालिकाओं तक पहुंच की अनुमति नहीं देता है, जो एक नई प्रक्रिया बनाते समय उपयोगी होगा।

पूर्ण भौतिक स्मृति मानचित्रण

हम सभी भौतिक मेमोरी प्रदर्शित करके इन समस्याओं को हल कर सकते हैं, न कि केवल पेज टेबल फ्रेम:

यह दृष्टिकोण कर्नेल को मनमाने ढंग से भौतिक मेमोरी तक पहुंचने की अनुमति देता है, जिसमें अन्य एड्रेस स्पेस के पेज टेबल फ्रेम भी शामिल हैं। वर्चुअल मेमोरी की एक श्रृंखला पहले की तरह ही आकार में आरक्षित है, लेकिन इसमें केवल कोई बेजोड़ पृष्ठ नहीं हैं।

इस दृष्टिकोण का नुकसान यह है कि भौतिक स्मृति को प्रदर्शित करने के लिए अतिरिक्त पृष्ठ तालिकाओं की आवश्यकता होती है। इन पृष्ठ तालिकाओं को कहीं संग्रहीत किया जाना चाहिए, इसलिए वे कुछ भौतिक मेमोरी का उपयोग करते हैं, जो कि थोड़ी मात्रा में रैम के साथ उपकरणों पर एक समस्या हो सकती है।

हालाँकि, x86_64 पर हम 4 KiB के डिफ़ॉल्ट आकार के बजाय प्रदर्शित करने के लिए विशाल 2 MiB पृष्ठों का उपयोग कर सकते हैं। इस प्रकार, भौतिक मेमोरी के 32 GiB को प्रदर्शित करने के लिए, प्रति पृष्ठ तालिका में केवल 132 KiB की आवश्यकता होती है: केवल एक तृतीय-स्तरीय तालिका और 32 द्वितीय-स्तरीय तालिकाएँ। विशाल पृष्ठों को भी अधिक कुशलता से कैश किया जाता है क्योंकि वे गतिशील अनुवाद बफर (टीएलबी) में कम प्रविष्टियों का उपयोग करते हैं।

अस्थायी प्रदर्शन

बहुत कम भौतिक मेमोरी वाले उपकरणों के लिए, आप केवल उन तक पहुंचने के लिए अस्थायी रूप से पेज टेबल प्रदर्शित कर सकते हैं। अस्थायी तुलना के लिए, केवल प्रथम स्तर की तालिका का एक समान प्रदर्शन आवश्यक है:

इस आंकड़े में, एक स्तर 1 तालिका वर्चुअल एड्रेस स्पेस के पहले 2 MiB का प्रबंधन करती है। यह संभव है क्योंकि CR3 रजिस्टर से पहुंच 4, 3 और 2 के स्तरों में शून्य प्रविष्टियों के माध्यम से है। सूचकांक 8 साथ रिकॉर्ड 32 KiB पर आभासी पृष्ठ को 32 KiB में एक भौतिक फ्रेम में अनुवाद करता है, जिससे स्तर 1 तालिका की पहचान होती है। आकृति में यह एक क्षैतिज तीर द्वारा दिखाया गया है।

आइडेंटली मैप्ड लेवल 1 टेबल पर लिखकर, हमारा कर्नेल 511 टाइम कंपेरिजन (पहचान मैपिंग के लिए जरूरी रिकॉर्ड माइनस 512 मिनट) तक बना सकता है। उपरोक्त उदाहरण में, कर्नेल दो बार तुलना बनाता है:

24 KiB पर एक फ्रेम में एक स्तर 1 तालिका में एक शून्य प्रविष्टि का मानचित्रण। यह डॉटेड तीर द्वारा इंगित पृष्ठ स्तर 2 तालिका के भौतिक फ्रेम में 0 KiB पर आभासी पृष्ठ का एक अस्थायी मानचित्रण बनाता है।
4 KiB में एक फ्रेम के साथ एक स्तर 1 तालिका के 9 वें रिकॉर्ड का मिलान करें। यह डॉटेड एरो द्वारा इंगित पेज लेवल 4 टेबल के भौतिक फ्रेम में 36 KiB पर वर्चुअल पेज का एक अस्थायी मानचित्रण बनाता है।

अब कर्नेल एक स्तर 2 तालिका को उस पृष्ठ पर लिखकर एक्सेस कर सकता है जो 0 KiB पर शुरू होता है और एक स्तर 4 तालिका 33 KiB पर शुरू होने वाले पृष्ठ पर लिखकर।

इस प्रकार, अस्थायी मैपिंग के साथ पृष्ठ तालिका के एक मनमाने ढंग से फ्रेम तक पहुंच के लिए निम्नलिखित क्रियाएं शामिल हैं:

समान रूप से प्रदर्शित स्तर 1 तालिका में एक निःशुल्क प्रविष्टि प्राप्त करें।
इस प्रविष्टि को उस पृष्ठ तालिका के भौतिक फ़्रेम में मैप करें जिसे हम एक्सेस करना चाहते हैं।
प्रवेश के साथ जुड़े आभासी पृष्ठ के माध्यम से इस फ्रेम तक पहुंचें।
अप्रयुक्त करने के लिए वापस रिकॉर्ड सेट, जिससे अस्थायी मानचित्रण को हटाने।

इस दृष्टिकोण के साथ, आभासी पता स्थान साफ रहता है, क्योंकि समान 512 आभासी पृष्ठ लगातार उपयोग किए जाते हैं। नुकसान कुछ बोझिल है, खासकर जब से एक नई तुलना में तालिका के कई स्तरों को बदलने की आवश्यकता हो सकती है, अर्थात, हमें कई बार वर्णित प्रक्रिया को दोहराने की आवश्यकता होती है।

पुनरावर्ती पृष्ठ सारणी

एक और दिलचस्प दृष्टिकोण जिसमें अतिरिक्त पृष्ठ तालिकाओं की आवश्यकता नहीं होती है, वह पुनरावर्ती मिलान है ।

विचार अपने आप में चौथे स्तर की तालिका से कुछ रिकॉर्ड का अनुवाद करना है। इस प्रकार, हम वास्तव में वर्चुअल एड्रेस स्पेस का एक हिस्सा आरक्षित करते हैं और सभी वर्तमान और भविष्य के टेबल फ्रेम को इस स्पेस में मैप करते हैं।

आइए एक उदाहरण देखें कि यह कैसे काम करता है:

लेख की शुरुआत में उदाहरण से एकमात्र अंतर 4 टेबल के स्तर में सूचकांक 511 साथ एक अतिरिक्त रिकॉर्ड है, जिसे भौतिक फ्रेम 4 KiB में मैप किया जाता है, जो इस तालिका में ही स्थित है।

जब सीपीयू इस रिकॉर्ड पर जाता है, तो यह स्तर 3 तालिका को संदर्भित नहीं करता है, लेकिन फिर से स्तर 4 तालिका को संदर्भित करता है। यह एक पुनरावर्ती फ़ंक्शन के समान है जो स्वयं को कॉल करता है। यह महत्वपूर्ण है कि प्रोसेसर मानता है कि स्तर 4 तालिका में प्रत्येक रिकॉर्ड स्तर 3 तालिका के लिए इंगित करता है, इसलिए अब यह स्तर 4 तालिका को स्तर 3 तालिका के रूप में मानता है। यह काम करता है क्योंकि x86_64 में सभी स्तरों के तालिकाओं की संरचना समान होती है।

वास्तविक रूपांतरण शुरू करने से पहले एक या अधिक बार पुनरावर्ती रिकॉर्ड का पालन करके, हम प्रोसेसर के माध्यम से जाने वाले स्तरों की संख्या को प्रभावी ढंग से कम कर सकते हैं। उदाहरण के लिए, यदि हम एक बार पुनरावर्ती रिकॉर्ड का पालन करते हैं, और फिर स्तर 3 तालिका पर जाते हैं, तो प्रोसेसर सोचता है कि स्तर 3 तालिका एक स्तर 2 तालिका है। आगे बढ़ते हुए, वह स्तर 2 तालिका को स्तर 1 तालिका के रूप में मानता है, और स्तर तालिका को मैप किया गया है। भौतिक स्मृति में फ्रेम। इसका मतलब है कि अब हम पेज लेवल 1 टेबल पर पढ़ और लिख सकते हैं क्योंकि प्रोसेसर को लगता है कि यह मैप्ड फ्रेम है। नीचे दिया गया आंकड़ा ऐसे अनुवाद के पाँच चरणों को दर्शाता है:

इसी तरह, हम रूपांतरण को शुरू करने से पहले दो बार पारित होने वाले स्तर को कम करने के लिए एक पुनरावर्ती प्रविष्टि का पालन कर सकते हैं:

आइए इस प्रक्रिया को चरण दर चरण देखें। सबसे पहले, CPU स्तर 4 तालिका में एक पुनरावर्ती प्रविष्टि का अनुसरण करता है और सोचता है कि यह स्तर 3 तालिका तक पहुंच गया है। फिर वह पुनरावर्ती रिकॉर्ड का अनुसरण करता है और सोचता है कि यह स्तर 2 तक पहुंच गया है। लेकिन वास्तव में यह अभी भी 4 के स्तर पर है। तब CPU नए पते पर जाता है। और स्तर 3 तालिका में शामिल हो जाता है, लेकिन यह पहले से ही स्तर 1 तालिका में सोचता है। अंत में, स्तर 2 तालिका में अगले प्रवेश बिंदु पर, प्रोसेसर को लगता है कि उसने भौतिक मेमोरी फ्रेम तक पहुंच बनाई है। यह हमें एक स्तर 2 टेबल पर पढ़ने और लिखने की अनुमति देता है।

स्तर 3 और 4 की तालिकाएँ भी एक्सेस की गई हैं। स्तर 3 की तालिका तक पहुँचने के लिए हम तीन बार एक पुनरावर्ती रिकॉर्ड का पालन करते हैं: प्रोसेसर सोचता है कि यह पहले से ही स्तर 1 की तालिका में है, और अगले चरण में हम स्तर 3 तक पहुँचते हैं, जिसे सीपीयू एक मैप्ड फ़्रेम के रूप में देखता है। स्तर 4 तालिका को स्वयं एक्सेस करने के लिए, हम केवल चार बार पुनरावर्ती रिकॉर्ड का पालन करते हैं जब तक कि प्रोसेसर स्तर 4 तालिका को एक मैप्ड फ़्रेम (नीचे की आकृति में नीला) के रूप में संसाधित करता है।

अवधारणा पहली बार में समझना मुश्किल है, लेकिन व्यवहार में यह बहुत अच्छी तरह से काम करता है।

पता गणना

इसलिए, हम एक या अधिक बार पुनरावर्ती रिकॉर्ड का पालन करके सभी स्तरों की तालिकाओं तक पहुँच सकते हैं। चूंकि चार स्तरों के तालिकाओं में अनुक्रमित को सीधे आभासी पते से प्राप्त किया जाता है, इसलिए इस पद्धति के लिए विशेष आभासी पते बनाए जाने चाहिए। जैसा कि हम याद करते हैं, पेज टेबल इंडेक्स इस पते से निकाले जाते हैं:

मान लीजिए कि हम एक स्तर 1 तालिका का उपयोग करना चाहते हैं जो एक विशिष्ट पृष्ठ प्रदर्शित करता है। जैसा कि हमने ऊपर सीखा है, आपको एक बार पुनरावर्ती रिकॉर्ड से गुजरना होगा, और फिर 4, 3 और 2 के स्तर के सूचकांक के माध्यम से। ऐसा करने के लिए, हम सभी एड्रेस ब्लॉक को एक ब्लॉक में दाईं ओर ले जाते हैं और पुनरावर्ती रिकॉर्ड के इंडेक्स को लेवल 4 के शुरुआती इंडेक्स के स्थान पर सेट करते हैं:

इस पृष्ठ के स्तर 2 तालिका तक पहुँचने के लिए, हम सभी सूचकांक खंडों को दो खंडों को दाईं ओर ले जाते हैं और पुनरावर्ती सूचकांक को दोनों स्रोत खंडों के स्तर पर सेट करते हैं: स्तर 4 और स्तर 3:

स्तर 3 तालिका तक पहुंचने के लिए, हम ऐसा ही करते हैं, हम अभी पहले से ही तीन पते वाले ब्लॉक पर जाते हैं।

अंत में, स्तर 4 तालिका तक पहुंचने के लिए, चार ब्लॉकों को दाईं ओर ले जाएं।

अब आप सभी चार स्तरों के पृष्ठ तालिकाओं के लिए आभासी पतों की गणना कर सकते हैं। हम एक पते की भी गणना कर सकते हैं, जो एक विशिष्ट पृष्ठ तालिका प्रविष्टि को इंगित करता है, इसके सूचकांक को 8 से गुणा करके, पृष्ठ तालिका प्रविष्टि का आकार।

नीचे दी गई तालिका विभिन्न प्रकार के फ़्रेमों तक पहुंचने के लिए पते की संरचना को दर्शाती है:

के लिए वर्चुअल एड्रेस	पता संरचना ( अष्टाधारी )
पेज	`0o_SSSSSS_AAA_BBB_CCC_DDD_EEEE`
स्तर 1 तालिका में प्रवेश	`0o_SSSSSS_RRR_AAA_BBB_CCC_DDDD`
एक स्तर 2 तालिका में प्रवेश	`0o_SSSSSS_RRR_RRR_AAA_BBB_CCCC`
एक स्तर 3 तालिका में प्रवेश	`0o_SSSSSS_RRR_RRR_RRR_AAA_BBBB`
स्तर 4 तालिका में प्रवेश	`0o_SSSSSS_RRR_RRR_RRR_RRR_AAAA`

यहां स्तर 4 सूचकांक है, स्तर 3 है, स्तर 2 है, और DDD प्रदर्शित फ्रेम के लिए स्तर 1 सूचकांक है, EEEE इसकी भरपाई है। RRR पुनरावर्ती रिकॉर्ड का सूचकांक है। एक सूचकांक (तीन अंक) 8 (पेज टेबल प्रविष्टि के आकार) से गुणा करके एक ऑफसेट (चार अंक) में बदल जाता है। इस ऑफसेट के साथ, परिणामी पता सीधे संबंधित तालिका तालिका प्रविष्टि को इंगित करता है।

SSSS हस्ताक्षरित अंक के विस्तार बिट्स हैं, SSSS , वे सभी बिट 47 की प्रतियां हैं। यह x86_64 वास्तुकला में मान्य पते के लिए एक विशेष आवश्यकता है, जिसकी हमने पिछले लेख में चर्चा की थी।

पते ऑक्टल हैं , क्योंकि प्रत्येक ऑक्टल चरित्र तीन बिट्स का प्रतिनिधित्व करता है, जो आपको अलग-अलग स्तरों पर 9-बिट इंडेक्स टेबल को स्पष्ट रूप से अलग करने की अनुमति देता है। यह हेक्साडेसिमल प्रणाली में संभव नहीं है, जहां प्रत्येक चरित्र चार बिट्स का प्रतिनिधित्व करता है।

रस्ट कोड

आप बिट कोड संचालन का उपयोग करके रस्ट कोड में ऐसे पते बना सकते हैं:

 // the virtual address whose corresponding page tables you want to access let addr: usize = […]; let r = 0o777; // recursive index let sign = 0o177777 << 48; // sign extension // retrieve the page table indices of the address that we want to translate let l4_idx = (addr >> 39) & 0o777; // level 4 index let l3_idx = (addr >> 30) & 0o777; // level 3 index let l2_idx = (addr >> 21) & 0o777; // level 2 index let l1_idx = (addr >> 12) & 0o777; // level 1 index let page_offset = addr & 0o7777; // calculate the table addresses let level_4_table_addr = sign | (r << 39) | (r << 30) | (r << 21) | (r << 12); let level_3_table_addr = sign | (r << 39) | (r << 30) | (r << 21) | (l4_idx << 12); let level_2_table_addr = sign | (r << 39) | (r << 30) | (l4_idx << 21) | (l3_idx << 12); let level_1_table_addr = sign | (r << 39) | (l4_idx << 30) | (l3_idx << 21) | (l2_idx << 12);

यह कोड इंडेक्स 0o777 (511) के साथ पिछले स्तर 4 रिकॉर्ड के एक पुनरावर्ती मानचित्रण का पुनरावर्ती मिलान करता है। वर्तमान में ऐसा नहीं है, इसलिए कोड अभी तक काम नहीं करेगा। लोडर को पुनरावर्ती मैपिंग सेट करने का तरीका बताने के लिए नीचे देखें।

मैन्युअल रूप से बिटवाइज़ ऑपरेशन करने के विकल्प के रूप में, आप x86_64 टोकरा के RecursivePageTable प्रकार का उपयोग कर सकते हैं, जो विभिन्न तालिका संचालन के लिए सुरक्षित सार प्रदान करता है। उदाहरण के लिए, नीचे दिए गए कोड से पता चलता है कि आभासी पते को उसके संबंधित भौतिक पते में कैसे परिवर्तित किया जाए:

 // in src/memory.rs use x86_64::structures::paging::{Mapper, Page, PageTable, RecursivePageTable}; use x86_64::{VirtAddr, PhysAddr}; /// Creates a RecursivePageTable instance from the level 4 address. let level_4_table_addr = […]; let level_4_table_ptr = level_4_table_addr as *mut PageTable; let recursive_page_table = unsafe { let level_4_table = &mut *level_4_table_ptr; RecursivePageTable::new(level_4_table).unwrap(); } /// Retrieve the physical address for the given virtual address let addr: u64 = […] let addr = VirtAddr::new(addr); let page: Page = Page::containing_address(addr); // perform the translation let frame = recursive_page_table.translate_page(page); frame.map(|frame| frame.start_address() + u64::from(addr.page_offset()))

फिर से, इस कोड को एक सही पुनरावर्ती मानचित्रण की आवश्यकता है। इस मैपिंग के साथ, अनुपलब्ध level_4_table_addr गणना पहले कोड उदाहरण में की जाती है।

रिकर्सिव मैपिंग एक दिलचस्प विधि है जो यह बताती है कि एकल तालिका के माध्यम से कितना शक्तिशाली मिलान हो सकता है। इसे लागू करना अपेक्षाकृत आसान है और इसके लिए केवल न्यूनतम सेटअप (केवल एक पुनरावर्ती प्रविष्टि) की आवश्यकता होती है, इसलिए यह पहले प्रयोगों के लिए एक अच्छा विकल्प है।

लेकिन इसके कुछ नुकसान भी हैं:

बड़ी मात्रा में वर्चुअल मेमोरी (512 GiB)। यह एक बड़े 48-बिट एड्रेस स्पेस में कोई समस्या नहीं है, लेकिन उप-कैश व्यवहार को जन्म दे सकता है।
यह आसानी से केवल वर्तमान में सक्रिय पता स्थान तक पहुँच देता है। पुनरावर्ती प्रविष्टि को बदलकर अन्य पता स्थानों तक पहुंच संभव है, लेकिन स्विचिंग के लिए अस्थायी मिलान आवश्यक है। हमने पिछले (अप्रचलित) लेख में ऐसा करने का वर्णन किया है।
यह x86 पेज टेबल फॉर्मेट पर बहुत अधिक निर्भर करता है और अन्य आर्किटेक्चर पर काम नहीं कर सकता है।

बूटलोडर समर्थन

ऊपर वर्णित सभी दृष्टिकोणों को पेज टेबल और संबंधित सेटिंग्स में बदलाव की आवश्यकता होती है। उदाहरण के लिए, भौतिक स्मृति को पहचानने के लिए या चतुर्थ-स्तरीय तालिका के रिकॉर्ड को पुन: मैप करने के लिए। समस्या यह है कि हम पेज टेबल तक पहुँच के बिना ये सेटिंग्स नहीं कर सकते।

इसलिए, मुझे बूटलोडर की मदद चाहिए। उसके पास पृष्ठ तालिकाओं तक पहुंच है, इसलिए वह किसी भी डिस्प्ले को बना सकता है जिसकी हमें आवश्यकता है। अपने वर्तमान कार्यान्वयन में, bootloader क्रेट कार्गो कार्यों का उपयोग करके उपरोक्त दोनों दृष्टिकोणों का समर्थन करता है :

map_physical_memory फ़ंक्शन वर्चुअल एड्रेस स्पेस में पूरी भौतिक मेमोरी को कहीं न कहीं मैप करता है। इस प्रकार, कर्नेल सभी भौतिक मेमोरी तक पहुंच प्राप्त करता है और पूर्ण भौतिक मेमोरी के प्रदर्शन के साथ एक दृष्टिकोण लागू कर सकता है।
recursive_page_table फ़ंक्शन का उपयोग करते हुए, लोडर पुनरावर्ती रूप से एक चौथे-स्तरीय पृष्ठ तालिका प्रविष्टि प्रदर्शित करता है। यह कर्नेल को "पुनरावर्ती पृष्ठ तालिकाओं" अनुभाग में वर्णित विधि के अनुसार काम करने की अनुमति देता है।

हमारी कर्नेल के लिए, हम पहला विकल्प चुनते हैं, क्योंकि यह एक सरल, प्लेटफ़ॉर्म-स्वतंत्र और अधिक शक्तिशाली दृष्टिकोण है (यह केवल पृष्ठ तालिकाओं को ही नहीं, बल्कि अन्य फ़्रेमों को भी एक्सेस देता है)। बूटलोडर से समर्थन के लिए, फ़ंक्शन को इसकी निर्भरता में जोड़ें map_physical_memory:

 [dependencies] bootloader = { version = "0.4.0", features = ["map_physical_memory"]}

यदि यह सुविधा सक्षम है, तो बूटलोडर पूरी भौतिक मेमोरी को वर्चुअल पते के कुछ अप्रयुक्त श्रेणी में मैप करता है। कर्नेल के लिए कई वर्चुअल पतों को पास करने के लिए, बूटलोडर बूट सूचना की संरचना से गुजरता है ।

बूट जानकारी

टोकरा कर्नेल को पारित की गई सभी सूचनाओं के साथ BootInfobootloader की संरचना को परिभाषित करता है । संरचना को अभी भी अंतिम रूप दिया जा रहा है, इसलिए भविष्य के संस्करणों के लिए अपग्रेड किए जाने के दौरान कुछ विफलताएं हो सकती हैं जो कि सेवर के साथ असंगत हैं । वर्तमान में, संरचना के दो क्षेत्र हैं: और :memory_mapphysical_memory_offset

फ़ील्ड memory_mapउपलब्ध भौतिक मेमोरी का अवलोकन प्रदान करता है। यह कर्नेल को बताता है कि सिस्टम पर कितनी भौतिक मेमोरी उपलब्ध है और मेमोरी के कौन से क्षेत्र वीजीए जैसे उपकरणों के लिए आरक्षित हैं। एक मेमोरी कार्ड को BIOS या यूईएफआई फर्मवेयर से अनुरोध किया जा सकता है, लेकिन केवल बूट प्रक्रिया की शुरुआत में। इस कारण से, लोडर को इसे प्रदान करना होगा, क्योंकि तब कर्नेल अब इस जानकारी को प्राप्त करने में सक्षम नहीं होगा। इस लेख में बाद में एक मेमोरी कार्ड काम आएगा।
physical_memory_offsetभौतिक मेमोरी मैपिंग के वर्चुअल प्रारंभ पते की रिपोर्ट करता है। इस ऑफसेट को भौतिक पते में जोड़ने पर, हमें संबंधित वर्चुअल पता मिलता है। यह कर्नेल से मनमानी भौतिक स्मृति तक पहुंच प्रदान करता है।

लोडर फ़ंक्शन के लिए BootInfoतर्क के रूप में कर्नेल के लिए संरचना को पास &'static BootInfoकरता है _start। इसे जोड़ें:

 // in src/main.rs use bootloader::BootInfo; #[cfg(not(test))] #[no_mangle] pub extern "C" fn _start(boot_info: &'static BootInfo) -> ! { // new argument […] }

सही तर्क प्रकार को निर्दिष्ट करना महत्वपूर्ण है, क्योंकि कंपाइलर हमारे प्रवेश बिंदु फ़ंक्शन के सही हस्ताक्षर प्रकार को नहीं जानता है।

प्रवेश बिंदु मैक्रो

चूंकि फ़ंक्शन _startलोडर से बाहरी रूप से कहा जाता है, इसलिए फ़ंक्शन के हस्ताक्षर की जांच नहीं की जाती है। इसका मतलब यह है कि हम इसे संकलन त्रुटियों के बिना मनमानी तर्क को स्वीकार करने दे सकते हैं, लेकिन यह अपवाहित रनटाइम व्यवहार को क्रैश या कारण देगा।

यह सुनिश्चित करने के लिए कि प्रविष्टि बिंदु फ़ंक्शन में हमेशा सही हस्ताक्षर हैं, टोकरा bootloaderएक मैक्रो प्रदान करता है entry_point। हम इस मैक्रो का उपयोग करके अपने फ़ंक्शन को फिर से लिखते हैं:

 // in src/main.rs use bootloader::{BootInfo, entry_point}; entry_point!(kernel_main); #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] }

अब आपको प्रवेश बिंदु के लिए उपयोग करने की आवश्यकता नहीं है extern "C"या no_mangle, चूंकि मैक्रो हमारे लिए निचले स्तर के वास्तविक प्रवेश बिंदु को परिभाषित करता है _start। फ़ंक्शन kernel_mainअब पूरी तरह से सामान्य रस्ट फ़ंक्शन बन गया है, इसलिए हम इसके लिए एक मनमाना नाम चुन सकते हैं। महत्वपूर्ण बात यह है कि यह प्रकार द्वारा जाँच की जाती है, इसलिए यदि आप गलत हस्ताक्षर का उपयोग करते हैं, उदाहरण के लिए, एक तर्क जोड़कर या उसका प्रकार बदलकर, एक संकलन त्रुटि उत्पन्न होगी

कार्यान्वयन

अब हमारे पास भौतिक मेमोरी तक पहुंच है, और हम अंततः सिस्टम के कार्यान्वयन को शुरू कर सकते हैं। सबसे पहले, वर्तमान सक्रिय पृष्ठ तालिकाओं पर विचार करें, जिस पर कर्नेल चलता है। दूसरे चरण में, एक ट्रांसलेशन फ़ंक्शन बनाएं जो भौतिक पते को लौटाता है जिससे यह वर्चुअल पता मैप किया जाता है। अंतिम चरण में, हम नया मानचित्रण बनाने के लिए पृष्ठ तालिकाओं को संशोधित करने का प्रयास करेंगे।

सबसे पहले, कोड में एक नया मॉड्यूल बनाएं memory:

 // in src/lib.rs pub mod memory;

मॉड्यूल के लिए, एक खाली फ़ाइल बनाएं src/memory.rs।

पृष्ठ तालिकाओं तक पहुंच

पिछले लेख के अंत में , हमने उन पृष्ठों की तालिका को देखने की कोशिश की जिन पर कर्नेल काम करता है, लेकिन रजिस्टर द्वारा बताए गए भौतिक फ्रेम तक नहीं पहुंच सकता है CR3। अब हम इस जगह से काम करना जारी रख सकते हैं: फ़ंक्शन active_level_4_tableचौथे स्तर के पृष्ठों की सक्रिय तालिका का लिंक लौटा देगा:

 // in src/memory.rs use x86_64::structures::paging::PageTable; /// Returns a mutable reference to the active level 4 table. /// /// This function is unsafe because the caller must guarantee that the /// complete physical memory is mapped to virtual memory at the passed /// `physical_memory_offset`. Also, this function must be only called once /// to avoid aliasing `&mut` references (which is undefined behavior). pub unsafe fn active_level_4_table(physical_memory_offset: u64) -> &'static mut PageTable { use x86_64::{registers::control::Cr3, VirtAddr}; let (level_4_table_frame, _) = Cr3::read(); let phys = level_4_table_frame.start_address(); let virt = VirtAddr::new(phys.as_u64() + physical_memory_offset); let page_table_ptr: *mut PageTable = virt.as_mut_ptr(); &mut *page_table_ptr // unsafe }

सबसे पहले, हमने रजिस्टर से चौथे स्तर की सक्रिय तालिका के भौतिक फ्रेम को पढ़ा CR3। फिर हम इसका भौतिक आरंभिक पता लेते हैं और इसे जोड़कर आभासी पते में बदल देते हैं physical_memory_offset। अंत में, पते को *mut PageTableविधि द्वारा कच्चे पॉइंटर में परिवर्तित करें as_mut_ptr, और उसके बाद इससे अनजाने में लिंक बनाएं &mut PageTable। हम &mutइसके बजाय लिंक बनाते हैं &, क्योंकि बाद में लेख में हम इन पेज तालिकाओं को संशोधित करेंगे।

यहां असुरक्षित ब्लॉक डालने की आवश्यकता नहीं है, क्योंकि रस्ट पूरे शरीर unsafe fnको एक बड़े, असुरक्षित ब्लॉक के रूप में मानता है । इससे जोखिम बढ़ जाते हैं, क्योंकि पिछली लाइनों में गलती से एक असुरक्षित ऑपरेशन शुरू करना संभव है। इससे असुरक्षित संचालन का पता लगाना भी मुश्किल हो जाता है। Rust के इस व्यवहार को संशोधित करने के लिए पहले से ही एक RFC बनाया गया है ।

अब हम चौथे स्तर तालिका के रिकॉर्ड को आउटपुट करने के लिए इस फ़ंक्शन का उपयोग कर सकते हैं:

 // in src/main.rs #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] // initialize GDT, IDT, PICS use blog_os::memory::active_level_4_table; let l4_table = unsafe { active_level_4_table(boot_info.physical_memory_offset) }; for (i, entry) in l4_table.iter().enumerate() { if !entry.is_unused() { println!("L4 Entry {}: {:?}", i, entry); } } println!("It did not crash!"); blog_os::hlt_loop(); }

हम physical_memory_offsetसंरचना के संबंधित क्षेत्र में गुजरते हैं BootInfo। फिर हम प्रत्येक तत्व में एक सूचकांक जोड़ने के iterलिए पृष्ठ तालिका प्रविष्टियों और एक संयोजन के माध्यम से पुनरावृति करने के लिए एक फ़ंक्शन का उपयोग करते हैं। केवल गैर-रिक्त प्रविष्टियाँ प्रदर्शित की जाती हैं, क्योंकि सभी 512 प्रविष्टियाँ स्क्रीन पर फिट नहीं होंगी। जब हम कोड चलाते हैं, तो हम इस परिणाम को देखते हैं: हम कई गैर-खाली रिकॉर्ड देखते हैं जो विभिन्न तृतीय-स्तरीय तालिकाओं में मैप किए जाते हैं। इसलिए कई मेमोरी क्षेत्रों का उपयोग किया जाता है क्योंकि कर्नेल कोड, कर्नेल स्टैक, भौतिक मेमोरी अनुवाद और बूट जानकारी के लिए अलग-अलग क्षेत्रों की आवश्यकता होती है। पृष्ठ तालिकाओं के माध्यम से जाने के लिए और तीसरे स्तर की तालिका को देखने के लिए, हम फिर से प्रदर्शित फ्रेम को आभासी पते में बदल सकते हैं:enumeratei

 // in the for loop in src/main.rs use x86_64::{structures::paging::PageTable, VirtAddr}; if !entry.is_unused() { println!("L4 Entry {}: {:?}", i, entry); // get the physical address from the entry and convert it let phys = entry.frame().unwrap().start_address(); let virt = phys.as_u64() + boot_info.physical_memory_offset; let ptr = VirtAddr::new(virt).as_mut_ptr(); let l3_table: &PageTable = unsafe { &*ptr }; // print non-empty entries of the level 3 table for (i, entry) in l3_table.iter().enumerate() { if !entry.is_unused() { println!(" L3 Entry {}: {:?}", i, entry); } } }

दूसरे और पहले स्तरों की तालिकाओं को देखने के लिए, क्रमशः तीसरे और दूसरे स्तर के रिकॉर्ड के लिए, इस प्रक्रिया को दोहराएं। जैसा कि आप कल्पना कर सकते हैं, कोड की मात्रा बहुत तेज़ी से बढ़ रही है, इसलिए हम पूरी लिस्टिंग प्रकाशित नहीं करेंगे।

मैन्युअल रूप से ट्रैवर्सिंग टेबल दिलचस्प है क्योंकि यह समझने में मदद करता है कि प्रोसेसर कैसे पते का अनुवाद करता है। लेकिन आमतौर पर हम केवल एक विशिष्ट वर्चुअल पते के लिए एक भौतिक पता प्रदर्शित करने में रुचि रखते हैं, तो चलिए इसके लिए एक फ़ंक्शन बनाते हैं।

पता अनुवाद

वर्चुअल एड्रेस को फिजिकल एड्रेस में ट्रांसलेट करने के लिए, हमें मैप किए गए फ्रेम तक पहुंचने तक चार-स्तरीय पेज टेबल से गुजरना होगा। आइए एक फ़ंक्शन बनाएं जो इस पते का अनुवाद करता है:

 // in src/memory.rs use x86_64::{PhysAddr, VirtAddr}; /// Translates the given virtual address to the mapped physical address, or /// `None` if the address is not mapped. /// /// This function is unsafe because the caller must guarantee that the /// complete physical memory is mapped to virtual memory at the passed /// `physical_memory_offset`. pub unsafe fn translate_addr(addr: VirtAddr, physical_memory_offset: u64) -> Option<PhysAddr> { translate_addr_inner(addr, physical_memory_offset) }

हम translate_addr_innerअसुरक्षित कोड की मात्रा को सीमित करने के लिए एक सुरक्षित फ़ंक्शन का उल्लेख करते हैं । जैसा कि ऊपर उल्लेख किया गया है, जंग पूरे शरीर unsafe fnको एक बड़े असुरक्षित ब्लॉक के रूप में मानता है । एक सुरक्षित फ़ंक्शन को लागू करके, हम फिर से प्रत्येक ऑपरेशन को स्पष्ट करते हैं unsafe।

एक विशेष आंतरिक फ़ंक्शन में वास्तविक कार्यक्षमता होती है:

 // in src/memory.rs /// Private function that is called by `translate_addr`. /// /// This function is safe to limit the scope of `unsafe` because Rust treats /// the whole body of unsafe functions as an unsafe block. This function must /// only be reachable through `unsafe fn` from outside of this module. fn translate_addr_inner(addr: VirtAddr, physical_memory_offset: u64) -> Option<PhysAddr> { use x86_64::structures::paging::page_table::FrameError; use x86_64::registers::control::Cr3; // read the active level 4 frame from the CR3 register let (level_4_table_frame, _) = Cr3::read(); let table_indexes = [ addr.p4_index(), addr.p3_index(), addr.p2_index(), addr.p1_index() ]; let mut frame = level_4_table_frame; // traverse the multi-level page table for &index in &table_indexes { // convert the frame into a page table reference let virt = frame.start_address().as_u64() + physical_memory_offset; let table_ptr: *const PageTable = VirtAddr::new(virt).as_ptr(); let table = unsafe {&*table_ptr}; // read the page table entry and update `frame` let entry = &table[index]; frame = match entry.frame() { Ok(frame) => frame, Err(FrameError::FrameNotPresent) => return None, Err(FrameError::HugeFrame) => panic!("huge pages not supported"), }; } // calculate the physical address by adding the page offset Some(frame.start_address() + u64::from(addr.page_offset())) }

फ़ंक्शन को पुन: उपयोग करने के बजाय, active_level_4_tableहमने रजिस्टर से चौथे स्तर के फ्रेम को फिर से पढ़ा CR3, क्योंकि यह प्रोटोटाइप के कार्यान्वयन को सरल करता है। चिंता न करें, हम जल्द ही समाधान में सुधार करेंगे।

संरचना VirtAddrपहले से ही चार स्तरों के पृष्ठों की तालिका में अनुक्रमित की गणना के लिए तरीके प्रदान करती है। हम इन अनुक्रमों को एक छोटे से सरणी में संग्रहीत करते हैं, क्योंकि यह आपको सभी तालिकाओं के माध्यम से लूप करने की अनुमति देता है for। लूप के बाहर, हमें याद है कि आखिरी फ्रेम बाद में भौतिक पते की गणना करने के लिए दौरा किया गया था। frameपृष्ठ पुनरावृत्ति के दौरान पृष्ठ तालिका के फ़्रेमों और अंतिम पुनरावृत्ति के बाद संबद्ध फ़्रेम पर, जो कि स्तर 1 रिकॉर्ड को पारित करने के बाद इंगित करता है।

लूप के अंदर, हम फिर से आवेदन करते हैं।physical_memory_offsetफ़्रेम को पेज टेबल लिंक में बदलने के लिए। फिर हम वर्तमान पृष्ठ तालिका का रिकॉर्ड पढ़ते हैं और PageTableEntry::frameमिलान किए गए फ्रेम को पुनः प्राप्त करने के लिए फ़ंक्शन का उपयोग करते हैं । यदि रिकॉर्ड फ़्रेम में मैप नहीं किया गया है, तो वापस लौटें None। यदि रिकॉर्ड 2 MiB या 1 GiB के विशाल पृष्ठ को प्रदर्शित करता है, तो अब तक हमें घबराहट होगी।

तो, कुछ पते पर अनुवाद समारोह की जाँच करें:

 // in src/main.rs #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] // initialize GDT, IDT, PICS use blog_os::memory::translate_addr; use x86_64::VirtAddr; let addresses = [ // the identity-mapped vga buffer page 0xb8000, // some code page 0x20010a, // some stack page 0x57ac_001f_fe48, // virtual address mapped to physical address 0 boot_info.physical_memory_offset, ]; for &address in &addresses { let virt = VirtAddr::new(address); let phys = unsafe { translate_addr(virt, boot_info.physical_memory_offset) }; println!("{:?} -> {:?}", virt, phys); } println!("It did not crash!"); blog_os::hlt_loop(); }

जब हम कोड चलाते हैं, तो हमें निम्न परिणाम मिलते हैं:

जैसा कि अपेक्षित था, एक समान मानचित्रण के साथ, पता 0xb8000उसी भौतिक पते में परिवर्तित हो जाता है। कोड पृष्ठ और स्टैक पृष्ठ को मनमाने ढंग से भौतिक पते में परिवर्तित किया जाता है, जो इस बात पर निर्भर करता है कि लोडर ने हमारी कर्नेल के लिए प्रारंभिक मैपिंग कैसे बनाई। मैपिंग physical_memory_offsetको भौतिक पते पर इंगित करना चाहिए 0, लेकिन विफल रहता है, क्योंकि अनुवाद दक्षता के लिए विशाल पृष्ठों का उपयोग करता है। बूटलोडर का भावी संस्करण कर्नेल और स्टैक पृष्ठों के लिए एक ही अनुकूलन लागू कर सकता है।

MappedPageTable का उपयोग करना

भौतिक पतों में आभासी पतों का अनुवाद OS कर्नेल का एक विशिष्ट कार्य है, इसलिए टोकरा इसके x86_64लिए एक अमूर्तता प्रदान करता है। यह पहले से ही विशाल पृष्ठों और कई अन्य कार्यों का समर्थन करता है translate_addr, इसलिए, हम अपने स्वयं के कार्यान्वयन के लिए बड़े पृष्ठों के लिए समर्थन जोड़ने के बजाय इसका उपयोग करते हैं।

अमूर्तता का आधार दो लक्षण हैं जो पृष्ठ तालिका के विभिन्न अनुवाद कार्यों को परिभाषित करते हैं:

लक्षण Mapperपृष्ठों पर काम करने वाले कार्य प्रदान करता है। उदाहरण के लिए, translate_pageइस पृष्ठ को उसी आकार के फ्रेम में अनुवाद करने के लिए, साथ ही map_toतालिका में एक नया मानचित्रण बनाने के लिए।
विशेषता का MapperAllSizesतात्पर्य Mapperसभी पृष्ठ आकारों के लिए आवेदन से है । इसके अलावा, यह ऐसे फ़ंक्शंस प्रदान करता है जो विभिन्न आकारों के पृष्ठों के साथ काम करते हैं, जिसमें translate_addrया सामान्य भी शामिल है translate।

लक्षण केवल इंटरफ़ेस को परिभाषित करते हैं, लेकिन कोई कार्यान्वयन प्रदान नहीं करते हैं। अब टोकरा x86_64दो प्रकार प्रदान करता है जो लक्षण को लागू करते हैं: MappedPageTableऔर RecursivePageTable। पहले के लिए आवश्यक है कि पृष्ठ तालिका का प्रत्येक फ्रेम कहीं पर प्रदर्शित हो (उदाहरण के लिए, ऑफ़सेट के साथ)। दूसरे प्रकार का उपयोग किया जा सकता है यदि चौथे स्तर की तालिका को पुन: प्रदर्शित किया जाता है।

हमारे पास सभी भौतिक मेमोरी मैप की गई हैं physical_memory_offset, इसलिए आप मैप्डपेजेज प्रकार का उपयोग कर सकते हैं। इसे आरंभ करने के लिए, initमॉड्यूल में एक नया फ़ंक्शन बनाएं memory:

 use x86_64::structures::paging::{PhysFrame, MapperAllSizes, MappedPageTable}; use x86_64::PhysAddr; /// Initialize a new MappedPageTable. /// /// This function is unsafe because the caller must guarantee that the /// complete physical memory is mapped to virtual memory at the passed /// `physical_memory_offset`. Also, this function must be only called once /// to avoid aliasing `&mut` references (which is undefined behavior). pub unsafe fn init(physical_memory_offset: u64) -> impl MapperAllSizes { let level_4_table = active_level_4_table(physical_memory_offset); let phys_to_virt = move |frame: PhysFrame| -> *mut PageTable { let phys = frame.start_address().as_u64(); let virt = VirtAddr::new(phys + physical_memory_offset); virt.as_mut_ptr() }; MappedPageTable::new(level_4_table, phys_to_virt) } // make private unsafe fn active_level_4_table(physical_memory_offset: u64) -> &'static mut PageTable {…}

हम सीधे MappedPageTableकिसी फ़ंक्शन से नहीं लौट सकते क्योंकि यह एक क्लोजर प्रकार के लिए सामान्य है। हम इस समस्या को एक सिंटैक्स निर्माण के साथ प्राप्त करेंगे impl Trait। एक अतिरिक्त लाभ यह है कि आप RecursivePageTableफ़ंक्शन के हस्ताक्षर को बदले बिना कर्नेल को स्विच कर सकते हैं ।

फ़ंक्शन MappedPageTable::newदो मापदंडों की उम्मीद करता है: स्तर 4 के पेज टेबल के लिए एक परस्पर लिंक और एक बंद phys_to_virtजो पेज फ्रेम पॉइंटर में भौतिक फ्रेम को परिवर्तित करता है *mut PageTable। पहले पैरामीटर के लिए, हम फ़ंक्शन का पुन: उपयोग कर सकते हैं active_level_4_table। दूसरे के लिए, हम एक क्लोजर बनाते physical_memory_offsetहैं जो रूपांतरण करने के लिए उपयोग करता है।

हम इसे एक active_level_4_tableनिजी समारोह भी बनाते हैं , क्योंकि अब से इसे केवल कहा जाएगा init।

विधि का उपयोग करने के लिएMapperAllSizes::translate_addrअपने स्वयं के कार्य के बजाय memory::translate_addr, हमें केवल कुछ पंक्तियों को बदलने की आवश्यकता है kernel_main:

 // in src/main.rs #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] // initialize GDT, IDT, PICS // new: different imports use blog_os::memory; use x86_64::{structures::paging::MapperAllSizes, VirtAddr}; // new: initialize a mapper let mapper = unsafe { memory::init(boot_info.physical_memory_offset) }; let addresses = […]; // same as before for &address in &addresses { let virt = VirtAddr::new(address); // new: use the `mapper.translate_addr` method let phys = mapper.translate_addr(virt); println!("{:?} -> {:?}", virt, phys); } println!("It did not crash!"); blog_os::hlt_loop(); }

शुरू करने के बाद, हम पहले जैसे ही अनुवाद परिणाम देखते हैं, लेकिन अब केवल विशाल पृष्ठ भी काम करते हैं:

जैसा कि अपेक्षित था, आभासी पते को physical_memory_offsetभौतिक पते में बदल दिया जाता है 0x0। प्रकार के लिए अनुवाद फ़ंक्शन का उपयोग करते हुए MappedPageTable, हम विशाल पृष्ठों के लिए समर्थन को लागू करने की आवश्यकता को समाप्त करते हैं। हमारे पास अन्य पृष्ठ कार्यों तक भी पहुंच है, जैसे कि map_toहम अगले भाग में उपयोग करेंगे। इस स्तर पर, हमें अब फ़ंक्शन की आवश्यकता नहीं है memory::translate_addr, आप चाहें तो इसे हटा सकते हैं।

एक नई मैपिंग बनाएं

अब तक, हमने केवल पृष्ठ तालिकाओं को देखा है, लेकिन कुछ भी नहीं बदला है। पहले प्रदर्शित न किए गए पृष्ठ के लिए एक नया मानचित्रण बनाते हैं।

हम फ़ंक्शन का उपयोग map_toविशेषता से करेंगे Mapper, इसलिए पहले हम इस फ़ंक्शन पर विचार करेंगे। प्रलेखन कहता है कि इसके लिए चार तर्क आवश्यक हैं: वह पृष्ठ जिसे हम प्रदर्शित करना चाहते हैं; जिस फ़्रेम को पृष्ठ मैप किया जाना चाहिए। पृष्ठ तालिका और फ्रेम वितरक लिखने के लिए झंडे का सेट frame_allocator। एक फ्रेम एलोकेटर आवश्यक है क्योंकि इस पृष्ठ को मैप करने के लिए अतिरिक्त तालिकाओं के निर्माण की आवश्यकता हो सकती है जिन्हें बैकअप स्टोरेज के रूप में अप्रयुक्त फ़्रेम की आवश्यकता होती है।

समारोह `create_example_mapping`

हमारे कार्यान्वयन में पहला कदम एक नया फ़ंक्शन बनाना है create_example_mappingजो इस पृष्ठ को 0xb8000वीजीए टेक्स्ट बफर के भौतिक फ्रेम में मैप करता है । हम इस फ्रेम का चयन करते हैं क्योंकि यह जांचना आसान बनाता है कि क्या डिस्प्ले सही तरीके से बनाई गई थी: हमें बस हाल ही में प्रदर्शित पेज पर लिखने की जरूरत है और देखें कि क्या यह स्क्रीन पर दिखाई देता है।

फ़ंक्शन create_example_mappingइस तरह दिखता है:

 // in src/memory.rs use x86_64::structures::paging::{Page, Size4KiB, Mapper, FrameAllocator}; /// Creates an example mapping for the given page to frame `0xb8000`. pub fn create_example_mapping( page: Page, mapper: &mut impl Mapper<Size4KiB>, frame_allocator: &mut impl FrameAllocator<Size4KiB>, ) { use x86_64::structures::paging::PageTableFlags as Flags; let frame = PhysFrame::containing_address(PhysAddr::new(0xb8000)); let flags = Flags::PRESENT | Flags::WRITABLE; let map_to_result = unsafe { mapper.map_to(page, frame, flags, frame_allocator) }; map_to_result.expect("map_to failed").flush(); }

पेज के अलावा pageहै कि आप संबद्ध करना चाहते हैं समारोह एक उदाहरण की उम्मीद है mapperऔर frame_allocator। प्रकार mapperउस विशेषता को लागू करता Mapper<Size4KiB>है जो विधि प्रदान करती है map_to। आम पैरामीटर Size4KiBआवश्यक है क्योंकि विशेषता Mapperहै आम विशेषता के लिए PageSizeमानक 4 KiB पृष्ठों के साथ और भारी पृष्ठों 2 और MiB 1 GiB साथ काम करना,। हम केवल 4 KiB पेज बनाना चाहते हैं, इसलिए हम Mapper<Size4KiB>आवश्यकता के बजाय इसका उपयोग कर सकते हैं MapperAllSizes।

तुलना के लिए, ध्वज को सेट करें PRESENT, क्योंकि यह सभी मान्य प्रविष्टियों के लिए आवश्यक है, और ध्वज WRITABLEपृष्ठ प्रदर्शित करने योग्य बनाने के लिए। कॉलmap_toअसुरक्षित: आप अमान्य तर्कों के साथ स्मृति सुरक्षा का उल्लंघन कर सकते हैं, इसलिए आपको एक ब्लॉक का उपयोग करना होगा unsafe। सभी संभावित झंडों की सूची के लिए, पिछले लेख का "पेज टेबल प्रारूप" अनुभाग देखें ।

फ़ंक्शन map_toविफल हो सकता है, इसलिए यह वापस आ जाता है Result। चूंकि यह केवल कोड का एक उदाहरण है जो विश्वसनीय नहीं होना चाहिए, हम बस expectएक त्रुटि की स्थिति में घबराहट के लिए इसका उपयोग करते हैं । यदि सफल होता है, तो फ़ंक्शन एक प्रकार देता है MapperFlushजो विधि का उपयोग करके गतिशील अनुवाद बफर (टीएलबी) से हाल ही में प्रदर्शित पृष्ठ को साफ़ करने का एक आसान तरीका प्रदान करता है flush। जैसे Result, यह प्रकार [ #[must_use]] विशेषता पर लागू होता हैचेतावनी जारी करना अगर हम गलती से इसका उपयोग करना भूल जाते हैं ।

काल्पनिक `FrameAllocator`

कॉल करने के लिए create_example_mapping, आपको पहले बनाना होगा FrameAllocator। जैसा कि ऊपर उल्लेख किया गया है, एक नया प्रदर्शन बनाने की जटिलता उस आभासी पृष्ठ पर निर्भर करती है जिसे हम प्रदर्शित करना चाहते हैं। सबसे सरल मामले में, पृष्ठ के लिए एक स्तर 1 तालिका पहले से ही मौजूद है, और हमें केवल एक रिकॉर्ड बनाने की आवश्यकता है। सबसे कठिन मामले में, पृष्ठ एक मेमोरी क्षेत्र में है जिसके लिए स्तर 3 अभी तक नहीं बनाया गया है, इसलिए पहले आपको स्तर 3, 2 और 1. के पेज टेबल बनाने होंगे।

आइए एक साधारण केस से शुरू करें और मान लें कि आपको नया पेज टेबल बनाने की आवश्यकता नहीं है। एक फ्रेम वितरक जो हमेशा रिटर्न करता है, इसके लिए पर्याप्त है None। हम EmptyFrameAllocatorपरीक्षण के लिए इस तरह के एक प्रदर्शन समारोह बनाते हैं :

 // in src/memory.rs /// A FrameAllocator that always returns `None`. pub struct EmptyFrameAllocator; impl FrameAllocator<Size4KiB> for EmptyFrameAllocator { fn allocate_frame(&mut self) -> Option<PhysFrame> { None } }

अब आपको एक पृष्ठ खोजने की आवश्यकता है जो नए पृष्ठ तालिकाओं को बनाए बिना प्रदर्शित किया जा सकता है। लोडर को वर्चुअल एड्रेस स्पेस के पहले मेगाबाइट में लोड किया जाता है, इसलिए हम जानते हैं कि इस क्षेत्र के लिए एक मान्य स्तर 1 तालिका है। हमारे उदाहरण के लिए, हम इस मेमोरी क्षेत्र में किसी भी अप्रयुक्त पृष्ठ का चयन कर सकते हैं, उदाहरण के लिए, पते पर पेज 0x1000।

फ़ंक्शन का परीक्षण करने के लिए, हम पहले पृष्ठ 0x1000प्रदर्शित करते हैं, और फिर मेमोरी की सामग्री प्रदर्शित करते हैं:

 // in src/main.rs #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] // initialize GDT, IDT, PICS use blog_os::memory; use x86_64::{structures::paging::Page, VirtAddr}; let mut mapper = unsafe { memory::init(boot_info.physical_memory_offset) }; let mut frame_allocator = memory::EmptyFrameAllocator; // map a previously unmapped page let page = Page::containing_address(VirtAddr::new(0x1000)); memory::create_example_mapping(page, &mut mapper, &mut frame_allocator); // write the string `New!` to the screen through the new mapping let page_ptr: *mut u64 = page.start_address().as_mut_ptr(); unsafe { page_ptr.offset(400).write_volatile(0x_f021_f077_f065_f04e)}; println!("It did not crash!"); blog_os::hlt_loop(); }

सबसे पहले, हम पेज के लिए एक मैपिंग बनाते हैं 0x1000, जो एक फ़ंक्शन create_example_mappingको उदाहरणों के लिए एक परस्पर लिंक के साथ बुलाता है mapperऔर frame_allocator। यह पृष्ठ 0x1000को वीजीए टेक्स्ट बफर फ्रेम में मैप करता है , इसलिए हमें यह देखना चाहिए कि स्क्रीन पर वहां क्या लिखा गया है।

फिर पृष्ठ को कच्चे सूचक में परिवर्तित करें और ऑफ़सेट को मान लिखें 400। हम पृष्ठ के शीर्ष पर नहीं लिखते क्योंकि वीजीए बफर की शीर्ष पंक्ति सीधे स्क्रीन से इस प्रकार स्थानांतरित की जाती है println। मान लिखें जो 0x_f021_f077_f065_f04eस्ट्रिंग "नया!" से मेल खाती है एक सफेद पृष्ठभूमि पर। जैसा कि हमने लेख "वीजीए टेक्स्ट मोड" में सीखा है , वीजीए बफर को लिखना अस्थिर होना चाहिए, इसलिए हम विधि का उपयोग करते हैं write_volatile।

जब हम QEMU में कोड चलाते हैं, तो हमें निम्न परिणाम दिखाई देते हैं:

पेज पर लिखने के बाद 0x1000, शिलालेख "नया!" ।इसलिए, हमने पेज टेबल में एक नया मैपिंग सफलतापूर्वक बनाया है।

इस टकराव ने काम किया क्योंकि टकराव के लिए पहले से ही एक स्तर 1 टेबल था 0x1000। जब हम किसी ऐसे पृष्ठ को मैप करने का प्रयास करते हैं जिसके लिए एक स्तर 1 तालिका अभी तक मौजूद नहीं है, तो फ़ंक्शन map_toविफल हो जाता है क्योंकि यह EmptyFrameAllocatorनए टेबल बनाने के लिए फ़्रेम आवंटित करने का प्रयास करता है । हम देखते हैं कि ऐसा तब होता है जब हम 0xdeadbeaf000इसके बजाय पृष्ठ प्रदर्शित करने का प्रयास करते हैं 0x1000:

 // in src/main.rs #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] let page = Page::containing_address(VirtAddr::new(0xdeadbeaf000)); […] }

यदि इसे प्रारंभ किया जाता है, तो निम्न त्रुटि संदेश के साथ एक घबराहट होती है:

 panicked at 'map_to failed: FrameAllocationFailed', /…/result.rs:999:5

उन पृष्ठों को प्रदर्शित करने के लिए जिनके पास अभी तक पृष्ठ स्तर 1 तालिका नहीं है, आपको सही एक बनाने की आवश्यकता है FrameAllocator। लेकिन आप कैसे जानते हैं कि कौन से फ्रेम मुफ्त हैं और कितनी भौतिक मेमोरी उपलब्ध है?

फ्रेम चयन

नए पृष्ठ तालिकाओं के लिए, आपको सही फ्रेम वितरक बनाने की आवश्यकता है। आइए सामान्य कंकाल के साथ शुरू करें:

 // in src/memory.rs pub struct BootInfoFrameAllocator<I> where I: Iterator<Item = PhysFrame> { frames: I, } impl<I> FrameAllocator<Size4KiB> for BootInfoFrameAllocator<I> where I: Iterator<Item = PhysFrame> { fn allocate_frame(&mut self) -> Option<PhysFrame> { self.frames.next() } }

क्षेत्र framesको एक मनमाना फ्रेम पुनरावृत्ति के साथ आरंभ किया जा सकता है। यह आपको allocविधि को केवल कॉल प्रतिनिधि बनाने की अनुमति देता है Iterator::next।

आरंभीकरण के लिए, हम BootInfoFrameAllocatorमेमोरी कार्ड का उपयोग करते हैं memory_mapजो बूटलोडर संरचना के हिस्से के रूप में स्थानांतरित हो जाता है BootInfo। जैसा कि बूट सूचना अनुभाग में बताया गया है , मेमोरी कार्ड BIOS / UEFI फर्मवेयर द्वारा प्रदान किया जाता है। यह बूट प्रक्रिया की शुरुआत में ही अनुरोध किया जा सकता है, इसलिए बूटलोडर ने पहले से ही आवश्यक कार्य कहा है।

एक मेमोरी कार्ड में संरचनाओं की एक सूची होती MemoryRegionहै जिसमें प्रत्येक मेमोरी क्षेत्र का शुरुआती पता, लंबाई और प्रकार (उदाहरण के लिए, अप्रयुक्त, आरक्षित, आदि) होते हैं। अनुपयोगी क्षेत्रों से फ़्रेम बनाने वाला एक इटरेटर बनाकर, हम एक वैध बना सकते हैं BootInfoFrameAllocator।

प्रारंभिक BootInfoFrameAllocatorकार्य एक नए समारोह में होता है init_frame_allocator:

 // in src/memory.rs use bootloader::bootinfo::{MemoryMap, MemoryRegionType}; /// Create a FrameAllocator from the passed memory map pub fn init_frame_allocator( memory_map: &'static MemoryMap, ) -> BootInfoFrameAllocator<impl Iterator<Item = PhysFrame>> { // get usable regions from memory map let regions = memory_map .iter() .filter(|r| r.region_type == MemoryRegionType::Usable); // map each region to its address range let addr_ranges = regions.map(|r| r.range.start_addr()..r.range.end_addr()); // transform to an iterator of frame start addresses let frame_addresses = addr_ranges.flat_map(|r| r.step_by(4096)); // create `PhysFrame` types from the start addresses let frames = frame_addresses.map(|addr| { PhysFrame::containing_address(PhysAddr::new(addr)) }); BootInfoFrameAllocator { frames } }

यह फ़ंक्शन उपयोग MemoryMapकिए गए भौतिक फ़्रेमों के पुनरावृत्ति में प्रारंभिक नक्शे को परिवर्तित करने के लिए एक संयोजन का उपयोग करता है :

सबसे पहले, हम iterमेमोरी कार्ड को पुनरावृत्ति में बदलने के लिए विधि कहते हैं MemoryRegion। तब हम filterआरक्षित या दुर्गम क्षेत्रों को छोड़ने के लिए विधि का उपयोग करते हैं। लोडर अपने द्वारा बनाए गए सभी मैपिंग के लिए मेमोरी कार्ड को अपडेट करता है, इसलिए कर्नेल (कोड, डेटा या स्टैक) द्वारा उपयोग किए जाने वाले फ़्रेम या बूट के बारे में जानकारी संग्रहीत करने के लिए पहले से ही InUseया इसी तरह से चिह्नित हैं । इस प्रकार, हम यह सुनिश्चित कर सकते हैं कि फ़्रेम का Usableउपयोग कहीं और नहीं किया गया है ।
map range Rust .
: into_iter , 4096- step_by . 4096 (= 4 ) — , . , . flat_map map , Iterator<Item = u64> Iterator<Item = Iterator<Item = u64>> .
PhysFrame , Iterator<Item = PhysFrame> . BootInfoFrameAllocator .

अब हम इसके बजाय kernel_mainउदाहरण के लिए अपना फ़ंक्शन बदल सकते हैं :BootInfoFrameAllocatorEmptyFrameAllocator

 // in src/main.rs #[cfg(not(test))] fn kernel_main(boot_info: &'static BootInfo) -> ! { […] let mut frame_allocator = memory::init_frame_allocator(&boot_info.memory_map); […] }

इस बार पता मानचित्रण सफल रहा और हम फिर से "नया!" ।दृश्यों के पीछे, विधि map_toअनुपलब्ध पेज टेबल बनाती है:

प्रेषित एक से अप्रयुक्त फ्रेम का चयन करें frame_allocator।
एक नया खाली पृष्ठ तालिका बनाने के लिए शून्य फ्रेम।
इस फ़्रेम में उच्च स्तरीय तालिका प्रविष्टि को मैप करें।
तालिका के अगले स्तर पर जाएं।

यद्यपि हमारा कार्य create_example_mappingकेवल नमूना कोड है, हम अब मनमाने पन्नों के लिए नए मानचित्रण बना सकते हैं। यह स्मृति को आवंटित करने और भविष्य के लेखों में मल्टीथ्रेडिंग को लागू करने के लिए आवश्यक होगा।

सारांश

इस लेख में, हमने पृष्ठ तालिकाओं के भौतिक फ़्रेमों तक पहुँचने के विभिन्न तरीकों के बारे में सीखा, जिसमें पहचान मानचित्रण, पूर्ण भौतिक स्मृति मैपिंग, अस्थायी मानचित्रण और पुनरावर्ती पृष्ठ तालिकाओं को शामिल किया गया। हमने पूर्ण भौतिक स्मृति को एक सरल और शक्तिशाली विधि के रूप में प्रदर्शित करने के लिए चुना।

हम पेज टेबल तक पहुँच के बिना कर्नेल से भौतिक मेमोरी को मैप नहीं कर सकते हैं, इसलिए बूटलोडर समर्थन की आवश्यकता है। रैक bootloaderअतिरिक्त कार्गो कार्यों के माध्यम से आवश्यक मैपिंग बनाता है। यह &BootInfoप्रवेश बिंदु फ़ंक्शन के तर्क के रूप में कर्नेल को आवश्यक जानकारी देता है ।

हमारे कार्यान्वयन के लिए, हम पहले मैन्युअल रूप से पृष्ठ तालिकाओं के माध्यम से गए, एक अनुवाद कार्य किया, और फिर MappedPageTableटोकरा के प्रकार का उपयोग कियाx86_64। हमने यह भी सीखा कि पेज टेबल में नए मैपिंग कैसे बनाएं और उन्हें FrameAllocatorबूटलोडर द्वारा प्रेषित मेमोरी कार्ड पर कैसे बनाया जाए ।

आगे क्या है?

अगले लेख में, हम अपने कर्नेल के लिए एक ढेर स्मृति क्षेत्र बनाएंगे, जो हमें मेमोरी आवंटित करने और विभिन्न प्रकार के संग्रह का उपयोग करने की अनुमति देगा ।

हम रस्ट पर एक ऑपरेटिंग सिस्टम लिखते हैं। पेज मेमोरी लागू करना (नया)

सामग्री

परिचय

निर्भरता अद्यतन

पृष्ठ तालिकाओं तक पहुंच

पहचान मानचित्रण

फिक्स्ड ऑफसेट नक्शा

पूर्ण भौतिक स्मृति मानचित्रण

अस्थायी प्रदर्शन

पुनरावर्ती पृष्ठ सारणी

पता गणना

रस्ट कोड

बूटलोडर समर्थन

बूट जानकारी

प्रवेश बिंदु मैक्रो

कार्यान्वयन

पृष्ठ तालिकाओं तक पहुंच

पता अनुवाद

MappedPageTable का उपयोग करना

एक नई मैपिंग बनाएं

समारोह `create_example_mapping`

काल्पनिक `FrameAllocator`

फ्रेम चयन

सारांश

आगे क्या है?

More articles:

हम रस्ट पर एक ऑपरेटिंग सिस्टम लिखते हैं। पेज मेमोरी लागू करना (नया)

सामग्री

परिचय

निर्भरता अद्यतन

पृष्ठ तालिकाओं तक पहुंच

पहचान मानचित्रण

फिक्स्ड ऑफसेट नक्शा

पूर्ण भौतिक स्मृति मानचित्रण

अस्थायी प्रदर्शन

पुनरावर्ती पृष्ठ सारणी

पता गणना

रस्ट कोड

बूटलोडर समर्थन

बूट जानकारी

प्रवेश बिंदु मैक्रो

कार्यान्वयन

पृष्ठ तालिकाओं तक पहुंच

पता अनुवाद

MappedPageTable का उपयोग करना

एक नई मैपिंग बनाएं

समारोह create_example_mapping

काल्पनिक FrameAllocator

फ्रेम चयन

सारांश

आगे क्या है?

More articles:

समारोह `create_example_mapping`

काल्पनिक `FrameAllocator`