וירטורליזציה של מערכות משולבות לזמן אמת מעל מעבדים מרובי ליבות

אסף גליל

המקרים בהם נשקול וירטואליזציה כזו 
מערכות משולבות רבות בנויות משתי יחידות מחשב : האחת מריצה מע”ה לזמן אמת, והשניה מריצה 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  .