אסף גליל
המקרים בהם נשקול וירטואליזציה כזו
מערכות משולבות רבות בנויות משתי יחידות מחשב : האחת מריצה מע”ה לזמן אמת, והשניה מריצה Windows .
הסיבה לחלוקה זו היא האופי המגוון של הדרישות שבעבר לא ניתן היה לספק באותה הפלטפורמה.
מצד אחד – דטרמיייסטיות ורובוסטיות לכיוון רכיבי החומרה שאותם מפעילה מע”ה לזמן אמת. מצד שני נוחיות ועושר המימשק למפעיל המערכת המסופקים ע”י Windows .
מספר רב של מערכות כאלו שניתן לכנותן Two Box Solutions פותחו במשך השנים, והושקעה בהם – ובמיוחד במרכיב לזמן אמת – השקעה גדולה בתוכנה ובדיקות.
במשך השנים, מיוצרות מערכות רבות כאלו, ובעוד שחומרת ה PC ניתנת להחלפה על ידי רכיבי חומרה חדשים, נשארת המערכת לזמן אמת עם רכיבי החומרה הישנים, בגלל הקושי בשינוי. החומרה שמעליה בנויה המערכת הופכת למיושנת , ולעיתים אף קשה להשיג אותה, וקיים צורך גובר והולך לעבור לשימוש בחומרה חדשה וזמינה. בנוסף לכך הפתרון באמצעות שתי “קופסאות” אינו נוח מבחינת מחירו ומחיר תחזוקתו, מבחינת המקום שהוא תופס ומבחינת רגישותו לתקלות בתקשורת בין שני חלקיו.
עם הזמינות והמחיר הנמוך של מעבדים מרובי ליבות מתעוררת שאלה: האם ניתן לנצל התפתחות זו ולעבור לפתרון של “קופסא” אחת , ואם כן – איך ניתן לבצע זאת?
התשובה לשאלה הראשונה הינה חיובית – סכמת המעבר מבחינת הזכרון לקופסא אחת נראה בשרטוט הבא : אחרי המעבר, ממופה מערכת לזמן אמת לאיזור בזכרון שאינו חופף את הזכרון של Windows , ומקצים למע”ה לזמן אמת ליבה אחת לטיפולו.
שרטוט מס 1- מעבר מפות הזכרון בין Two Box Solution ל One Box
התשובה לשאלה השניה גם היא חיובית : קימות לפחות שתי אפשרויות למעבר בין Two Box Solution ל One Box .
האפשרות הראשונה היא להסב את ה- code של ה- RTOS לאחד מאופני הרחבה לזמן אמת של Windows כמו INtime . הקוד המוסב משתמש ביכולות לזמן אמת של INtime על ליבה אחת או יותר – בתוך מערכת מבוססת Windows . קיימים מוצרים כמו ה- OsChanger של חברת Mapusoft שמספקים כלים להסבה בין כל מע”ה -זמן אמת ( RTOS ) ל Intime – בהסבה כמעט אוטומטית . הסבה כזו על מחשב מרובה ליבות מאפשרת להריץ את INtime על ליבה אחת או יותר במבנה של Asymmetrical Multiprocessing , ולהריץ את Windows על יתר הליבות במבנה של Symmetrical Multiprocessing.
פרט לעלות ההסבה (בין אם זה באמצעות תוכנת Mapusoft או באמצעים אחרים) ,שינוי כזה של מע”ה לזמן אמת מחייב גם סידרה של בדיקות מחמירות – כיון שקוד הפיתרון השתנה. בדיקות כאלה לוקחות זמן ומשאבים.
אם משימת ההסבה אינה מתקבלת – קימת האפשרות השניה לעבור מ Two Box Solution ל One Box על מחשב מרובה ליבות , ובאפשרות זו נעסוק במאמר זה. הפתרון קרוי EVM והינו Real Time Hypervisor שבמעבר בשימוש אליו אין צורך להסב את ה code המפותח עבור מע”ה לזמן אמת – אלא להריץ אותו כמות שהוא ,ואת מע”ה ש”מתחתיו” על אחת הליבות .
הדרישות מפתרון הוירטואליזציה למערכות זמן אמת
את מערכות הוירטאליזציה שנפוצות היום מטיפוס VMware או Virtual PC ניתן לכנות
Server Software Based Virtualization Solution . הן מאפשרות לכמה מערכות General Purpose Operating Systems או GPOS כמו Windows או Linux לרוץ בכמה “עותקים” על מחשב מרובה ליבות. הדגש במערכות אלו היא חלוקת משאבים “הוגנת” בין מערכות ההפעלה האורחות מטיפוס GPOS . התהליכים שמבצעות מערכות כאלה הינם מטיפוס תהליכי Batch , או תהליכים אינטראקטיביים מול מפעיל . בתהליכים כאלה מהירות התגובה הדרושה נמדדת במילי שניות רבות , כך שהמעבר ממעבד “פרטי” לליבה מתוך כמה ליבות – לא משפיע לרעה על חווית המשתמשים מול המערכת.
מאידך ,לישומים של זמן אמת , שמאופינים על ידי פעולה מול מכונות , נדרשים תגובות הרבה יותר מהירות – בסדרי גודל של מיקרו שניות ולפיכך נדרשים מנגנונים אחרים לוירטואליזציה של Real Time Operating Systems – RTOS. מה שדרוש הוא Hardware Based Embedded Virtualization Solution . הדרישה המרכזית הינה שהמשאבים שמע”ה לזמן אמת היתה “רגילה” לקבל כשהיא רצה על מעבד משלה – מהירות הביצוע של המעבד , ה- Interrupt Latency and Jitter , וזמני פניה ל I/O הטבעי שלה – יתקבלו ללא שינוי במעבר למצב בו ליבה אחת מריצה RTOS ויתר הליבות מריצות Windows .
ה EVM הינה מערכת וירטואליזציה כזו. התוכנה היא Real Time Hypervisor שהינה תוכנת ישום שעולה מ Windows . התוכנה כוללת מרכיב קונפיגורציה שמקצה את המשאבים, ומרכיב ריצה שמאפשר לשתי מערכות ההפעלה – Windows ו RTOS לרוץ במקביל ולהתיחס למשאבים לפי מה שהוגדר בשלב הקונפיגורציה. ה RTOS יכול להיות אחת ממערכות ההפעלה לזמן אמת VXworks QNX Linux Windows CE iTron ו RMX .
RTOS מבצעת Boot מהדיסק של Windows מקובץ שכולל את ה Boot File שלה כאילו היתה מע”ה ההפעלה היחידה, Windows מבצע Bootגם הוא כאילו היה מע”ה היחידה.
ברגע ששתי מע”ה עולות מתבצעים הקשרים שהוגדרו קודם לכן בתהליך הקונפיגורציה שהגדיר את חלוקת המשאבים בין מע”ה. המערכות יכולות להתקשר ביניהן כמו מקודם – ע”י אפיקי תקשורת וירטואלים של Ethernet או .Serial Ports
הדרישות מחומרת המערכת
• מעבד מרובה ליבות של אינטל או מעבד ליבה אחת עם Hyperthreading
• מעבד שתומך בטכנולוגית VT-x
• כמות הזכרון ש”נלקחת” מ windows היא 320 Kilo Bytes , לריצת ה eVM דרושים 64 Mega Bytes ובנוסף יש להוסיף את כמות הזכרון הנדרשת עבור RTOS
• במקרה ש RTOS פועלת עם רכיבי DMA – רצוי שהרכיבים הפריפריאליים יתמכו ב VT-d שהינו Intel Virtualization Technology for Direct I-O . באמצעות VT-d ממפה eVM את פעולות ה DMA
.
חלוקת המשאבים
תהליך חלוקת המשאבים נועד להגדיר את המשאבים שיאפשרו למע”ה RTOS ולקוד של הלקוח לקבל את אותה הסביבה אליה פותחו בקונפיגורציה של Two Box Solution .
השלב הראשון הוא לטפל במשאבים הבסיסיים של RTOS – מה גודל הזכרון שתדרוש , והיכן נמצא ה Boot file שלה. זוהי חלוקת זכרון בין המערכת המארחת – Windows למערכת הזמן אמת האורחת – RTOS , באופן כזה שאף מערכת אינה יכולה “לחדור” לרעותה. מיפוי זכרון כזה מאפשר לכל מרכיבי I/O ממופי זכרון לעבוד ללא שינוי.
השלב השני הוא מתן אפשרות גישה טבעית מהירה ל Interrupts שדרושים ומופעלים על ידי המערכת לזמן אמת . כל רכיבי ה I/O “מועברים” על ידי כלי גרפי מ Windows ל eVM . אלה ההתקנים שדורשים דטרמיניסטיות בטיפול ומקבלים את הטיפול – כולל מהירות התגובה הדטרמיניסטית – כאילו היו מופעלים על ידי מעבד ייחודי עבורם.
זהו השלב בו יש לנסות למצוא במידת האפשר כרטיסי I/O שעבורם ישנם Drivers ל מערכת RTOS . לגבי כרטיסי שלא ניתן לרכוש וגם לא ניתן למצוא כרטיסים חליפים בעלי Driver – ניתנת אפשרות למפות את הגישה לרכיבי I/O אליהם ולכתוב קוד חיצוני בתוך סביבת ה eVM כך שיוכלו להיות מופעלים ללא שינוי הקוד במע”ה לזמן אמת .
הטיפול בפסיקות
כדי לספק מכונה וירטואלית שנראית ל RTOS כמו PC ה- EVM קולט את הפסיקות המיועדות ל RTOS ומשמש כבקר פסיקות וירטואלי עבור RTOS .
ניתן לראות בשרטוט מספר 2 את המצבים השונים במיפוי הפסיקות .
התקן A מיצר פסיקה מטיפוס MSI ( Message Signaled Interrupt ) . וה Driver של Windows תומך בו ) מע”ה XP וקודמות לה לא תמכו ב MSI ) . EVM אינו מעורב.
התקן B השייך ל Windows מיצר פסיקת חומרה – IRQ ו Windows מטפל בו וגם כאן EVM אינו מעורב.
התקנים C ו D – שני ההתקנים האחד של Windows והשני של RTOS שותפים באותה פסיקה. זהו מקרה שרצוי למנוע, וניתן לעיתים למנוע על ידי פעולות ב Bios או שינוי יצרן ה- Motherboard . אולם באם לא ניתן – אזי התקן C ב Windows משתמש בפסיקה , והתקן D ששיך ל RTOS יש לשנות את ההפעלה שלו ממצב פסיקה למצב Polling .
התקן E : הפסיקה מועברת ע”י חמרת ה APIC ל EVM שיוצר Virtual Interrupt לכיוון RTOS .
התקן F : ההתקן יוצר פסיקה מטיפוס MSI . הפסיקה נקלטת ע”י eVM וזו שולחת Virtual Interrupt לכיוון RTOS .
שרטוט מספר 2 : מיפוי הפסיקות באמצעות eVM
הטיפול בהתקני I/O
באמצעות כלי גרפי – נעשית הפרדת ההתקנים הפיזיים שבתחילה כולם משוייכים ל Windows והעברת החלק הרלוונטי ל . RTOS .
ההתקנים שנדרשים ל RTOS ולא מקבלים את רכיב החומרה לטיפולם מטופלים ע”י וירטואליזציה שלהם שמבצע ה eVM :
רכיב Ethernet שמדמה עבור RTOS כרטיס רשת – אולם בפועל זהו חיבור ל Windows שגם מצידו ישנו כרטיס רשת וירטואלי .
Serial Ports של RTOS יכולים לקבל התחברות ל Virtual Serial ports מצידו של . Windows .
Disk Access – ה RTOS מקבל איזור על ה disk של Windows שהוא מתיחס אליו כ”פרטי”.
לסיכום
מימוש מערכות RTOS מעל מעבדים מרובי ליבות שונה מהמימוש של מערכות GPOS . באמצעות eVM ניתן לבצע זאת ולתת: אורך נשימה” למערכות ישנות שהשוק עבורן לא דעך.
המעבר לוירטואליזציה אינו דורש משאבים רבים , ויכול להתבצע בזמן קצר.
ניתן לקרוא על הטכנולוגיות שהוצגו במסמך :
EVMhttp://www.tenasys.com/products/eVM.php
INtime http://www.tenasys.com/products/intime.php
Mapusoft oschanger http://www.mapusoft.com/
על המחבר :
אסף גליל הוא מהנדס יישומים של חברת TenAsys (www.TenAsys.com ) לאסף למעלה מ 30 שנות נסיון במערכות משובצות מחשב עם דגש על מעבדים ותוכנות למשפחותX86 .
