ملزومات مجازی‌سازی پوپک و گلدبرگ
ملزومات مجازی سازی پوپک و گلدبرگ مجموعه‌ای از شرایط کافی برای یک معماری کامپیوتر در جهت پشتیبانی مؤثر از مجازی‌سازی کارآمد هستند. این شرایط توسط جرالد جی. پوپک و رابرت پی. گلدبرگ در مقاله سال ۱۹۷۴ آنها یعنی «ملزومات رسمی برای معماری‌های نسل سوم با پشتیبانی مجازی‌سازی» معرفی شدند.[۱] با وجود اینکه این الزامات تحت فرضیات ساده شده‌ای به دست می‌آیند، اما همچنان راهی مناسب برای تعیین اینکه آیا یک معماری کامپیوتر از مجازی‌سازی کارآمدی پشتیبانی می‌کند یا اینکه آیا دستورالعمل‌هایی را برای طراحی معماری‌های رایانه مجازی ارائه می‌دهد می‌باشند.
تعریف VMM ویرایش
ماشین‌های مجازی سیستم قادر به مجازی‌سازی مجموعه کاملی از منابع سخت‌افزاری از جمله یک یا چند پردازنده، منابع حافظه و ذخیره‌سازی و دستگاه‌های جانبی هستند. مانیتور ماشین مجازی (VMM، که هایپروایزر نیز نامیده می‌شود) قطعه نرم‌افزاری است که تجرید یک ماشین مجازی را فراهم می‌کند. هنگام تجزیه و تحلیل محیط ایجاد شده توسط VMM سه ویژگی مورد توجه وجود دارد:[۲]
- هم‌ارزی / وفاداری
- برنامه‌ای که تحت VMM اجرا می‌شود باید رفتاری اساساً مشابه با زمانی که مستقیماً روی یک ماشین معادل اجرا می‌شود، داشته باشد.
- نظارت منابع / ایمنی
- VMM باید بر منابع مجازی‌سازی نظارت تام داشته باشد.
- کارایی / عملکرد
- بخش آماری غالب دستورالعمل‌های ماشین باید بدون دخالت VMM اجرا شود.
در اصطلاح پوپک و گلدبرگ، یک VMM باید هر سه ویژگی را داشته باشد. در اصطلاحات مورد استفاده در کتاب مرجع اسمیت و نیر (۲۰۰۵)، فرض شده که VMMها در بیشتر مواقع ویژگی‌های هم‌ارزی و نظارت منابع را برآورده می‌کنند و آنهایی که علاوه بر این‌ها ویژگی عملکرد / کارایی را نیز دارند، VMM کارآمد نامیده می‌شوند.[۳]
پوپک و گلدبرگ ویژگی‌هایی را که مجموعه دستورالعمل (ISA) ماشین فیزیکی باید داشته باشد تا VMMهایی را که دارای ویژگی‌های فوق هستند اجرا کند، توصیف می‌کنند. تجزیه و تحلیل آنها چنین ویژگی‌هایی را با استفاده از مدلی از «معماری‌های نسل سوم» (به عنوان مثال، IBM 360، Honeywell 6000، DEC PDP-10) به دست می‌آورد که درهرحال به اندازه کافی کلی هست که ماشین‌های نوین را نیز دربرگیرد. این مدل شامل یک پردازنده است که یا در حالت سیستمی یا در حالت کاربری عمل می‌کند و به حافظه خطی و آدرس‌پذیر یکنواخت دسترسی دارد. فرض بر این است که یک زیرمجموعه از مجموعه دستورالعمل‌ها تنها در حالت سیستمی در دسترس است و آن حافظه نسبت به یک ثبت جابجایی آدرس‌دهی می‌شود. ورودی/خروجی‌ها و وقفه‌ها مدل‌سازی نشده‌اند.
قضایای مجازی‌سازی ویرایش
پوپک و گلدبرگ برای استخراج قضایای مجازی‌سازی خود، که شرایط کافی (اما نه لازم) را برای مجازی‌سازی ارائه می‌دهند، برخی دستورالعمل‌های یک ISA را در سه گروه مختلف معرفی می‌کنند؛ ۳ گروه مذکور به شرح ذیل می باشند.
- دستورالعمل‌های ممتاز(انحصاری)
- دستورالعمل‌هایی که باعث تله می‌شوند اگر پردازنده در حالت کاربری باشد و باعث تله نمی‌شوند اگر پردازنده در حالت سیستمی(حالت سوپروایزر) باشد.
- دستورالعمل‌های حساس به نظارت
- دستورالعمل‌هایی که سعی در تغییر پیکربندی منابع سیستم دارند.
- دستورالعمل‌های حساس به رفتار
- دستورالعمل‌هایی که رفتار یا نتیجه آنها به پیکربندی منابع (محتوای ثبات جابجایی یا حالت پردازنده) بستگی دارد.
پس نتیجه اصلی تحلیل و بررسی پوپک و گلدبرگ را می‌توان به صورت زیر بیان کرد:
قضیه ۱. برای هر کامپیوتر نسل سوم معمولی، اگر مجموعه دستورالعمل‌های حساس برای آن کامپیوتر زیرمجموعه‌ای از مجموعه دستورالعمل‌های ممتاز باشد، می‌توان یک VMM مؤثر طراحی کرد.
به‌طور شهودی، این قضیه بیانگر این است که: برای ساخت یک VMM کافی است تمام دستورالعمل‌هایی که می‌توانند بر عملکرد صحیح VMM تأثیر بگذارند(دستورالعمل‌های حساس)، همیشه باعث تله می‌شوند و نظارت را به VMM منتقل کنند. این ویژگی نظارت منابع را برآورده می‌کند. دستورالعمل‌های غیرممتاز باید در عوض به صورت بومی (یعنی کارآمد) اجرا شوند. همچنین ویژگی هم‌ارزی نیز حفظ می‌شود.
این قضیه همچنین یک روش ساده برای پیاده‌سازی یک VMM، به نام مجازی‌سازی trap-and-emulate ارائه می‌کند که اخیراً مجازی‌سازی کلاسیک هم نامیده شده است: از آنجا که تمام دستورالعمل‌های حساس به خوبی رفتار می‌کنند، کل کاری که VMM باید انجام دهد این است که هر بار دچار تله شده و شبیه‌سازی کند.[۴][۵]
یک مشکل مرتبط به استخراج شرایط کافی برای مجازی‌سازی بازگشتی بازمی‌گردد، یعنی شرایطی که تحت آن بتوان یک VMM که می‌تواند روی یک کپی از خودش اجرا شود، ساخت. پوپک و گلدبرگ شروط (کافی) زیر را ارائه می‌دهند.
قضیه ۲. یک کامپیوتر نسل سوم معمولی به صورت بازگشتی مجازی‌سازی می‌شود اگر:
- بتواند مجازی‌سازی شود و
- یک VMM بدون هیچ گونه وابستگی زمانی بتوان برای آن طراحی کرد.
برخی از معماری‌ها، مانند x86 نامبتنی بر سخت‌افزار، این شرایط را ندارند، بنابراین نمی‌توان آنها را به روش کلاسیک مجازی‌سازی کرد. اما معماری‌ها باز هم می‌توانند با بهره بردن از روش‌های متفاوتی مانند ترجمه دودویی-که دستورالعمل‌های حساسی که تله ایجاد نمی‌کنند و گاهی اوقات دستورالعمل‌های بحرانی نیز نامیده می‌شوند را جایگزین می‌کنند- به صورت کامل مجازی‌سازی شوند(در x87 در سطح CPU و MMU).[۴] با این حال، این پردازش اضافی باعث می‌شود VMM از جنبه نظری کارایی کمتری داشته باشد،[۵] اما تله‌های سخت‌افزاری هزینه عملکردی دارند که نمی‌توان از آن چشم‌پوشی کرد.[نیازمند منبع] یک سیستم ترجمه باینری ذخیره‌سازی خوب تنظیم شده ممکن است عملکرد قابل مقایسه‌ای داشته باشد، و در ترجمه باینری x86 نسبت به کمک سخت‌افزاری نسل اول x86 که صرفاً به دستورالعمل‌های حساس قابلیت تله نیز داده است، چنین است.[۶] عملاً این یک قضیه با شرایط کافی متفاوتی به دست می‌دهد.[نیازمند منبع]
قضیه ۳. می‌توان یک VMM ترکیبی برای هر ماشین نسل سومی طراحی کرد به طوری که در آن مجموعه دستورالعمل‌های حساس به کاربر، زیرمجموعه‌ای از مجموعه دستورالعمل‌های ممتاز هستند:
رسیدگی به دستورالعمل‌های بحرانی ویرایش
شرایط ذکر شده برای مجازی‌سازی ISA در قضیه ۱ ممکن است با قربانی خاصیت کارایی برآورده شود. VMMها برای ISAهای فاقد قابلیت مجازی‌سازی (دربیان Popek و Goldberg) به‌طور معمول ساخته شده‌اند.
مجازی‌سازی این چنین معماری‌هایی مستلزم مدیریت صحیح دستورالعمل‌های بحرانی، یعنی دستورالعمل‌های حساس اما غیرممتاز است. یک رویکرد، که به عنوان وصله(patching) نیز شناخته می‌شود، از روش‌هایی استفاده می‌کند که معمولاً در کامپایل مجدد پویا استفاده می‌شوند: دستورالعمل‌های حیاتی در زمان اجرا کشف و با یک تله در VMM جایگزین می‌شوند. مکانیسم‌های مختلفی مانند ذخیره کردن کد شبیه‌سازی یا کمک‌های سخت‌افزاری در حافظه نهان برای کارآمدتر کردن فرایند وصله پیشنهاد شده‌اند. یکی از رویکردهای متفاوت، شبیه‌سازی فرامجازی‌سازی است که نیاز به اصلاح(پورت شدن) سیستم عامل مهمان قبل از اجرا در محیط مجازی دارد.
مجموعه دستورالعمل‌های معماری‌های رایج ویرایش
این بخش برخی از معماری‌های مرتبط و نحوه ارتباط آنها با الزامات مجازی‌سازی را ارائه می‌دهد.
PDP-10 ویرایش
معماری PDP-10 تنها چند دستورالعمل دارد که حساس هستند (حالت پردازنده را تغییر داده یا پرس و جو می‌کنند) اما ممتاز نیستند. این دستورالعمل‌ها کدهای شرط حاوی بیت‌های USER یا IOT را ذخیره یا بازیابی می‌کنند:
- JSR: پرش به زیربرنامه
- JSP: پرش و ذخیره شمارنده برنامه
- PUSHJ: هل به پایین و پرش
- JRST: پرش و بازیابی
System/370 ویرایش
همه دستورالعمل‌های حساس در System/370 ممتاز هستند: همین الزامات مجازی‌سازی را برآورده می‌کند.[۷]
موتورولا MC68000 ویرایش
Motorola MC68000 تنها یک دستورالعمل حساس غیرممتاز دارد:
- MOVE از SR
این دستورالعمل حساس است زیرا امکان دسترسی به کل ثبات وضعیت(status register) را فراهم می‌کند، که نه تنها شامل کدهای شرط، بلکه شامل بیت کاربر/سرپرست، سطح وقفه و کنترل ردیابی نیز می‌شود. در اکثر اعضای خانواده بعدی، با شروع با MC68010، دستور MOVE from SR ممتاز بود، و یک دستورالعمل جدید MOVE از CCR ارائه می‌شد تا فقط به ثبات کد شرط(CCR یا همان ثبات وضعیت) دسترسی داشته باشد.
IA-32 (x86) ویرایش
مجموعه دستورالعمل IA-32 پردازنده پنتیوم شامل ۱۸ دستورالعمل حساس و غیرممتاز است. آنها را می‌توان در دو گروه دسته‌بندی کرد:
- دستورالعمل‌های حساس ثبات: رجیسترهای حساس یا مکان‌های حافظه مانند ثبات کلاک یا رجیسترهای وقفه را خوانده و تغییر می‌دهند:
- SGDT, SIDT, SLDT
- SMSW
- PUSHF, POPF
- دستورالعمل‌های حفاظتی سیستم: به سیستم حفاظتی منبع، حافظه یا سیستم جابه‌جایی آدرس ارجاع می‌دهند:
- LAR, LSL, VERR, VERW
- POP
- PUSH
- CALL FAR, JMP FAR, INT n، RETF
- STR
- MOV (رجیسترهای بخشی)
معرفی مجموعه دستورالعمل‌های AMD-V و Intel VT-x در سال ۲۰۰۵ به پردازنده‌های x86 اجازه می‌دهد تا ملزومات مجازی‌سازی Popek و Goldberg را برآورده کنند.
IA-64 ویرایش
تلاش مورد نیاز برای پشتیبانی از مجازی‌سازی در معماری IA-64 در مقاله‌ای در سال ۲۰۰۰ توسط Magenheimer و Christian توضیح داده شده‌است.
SPARC ویرایش
یک حالت "hyperprivileged" برای معماری UltraSPARC در معماری UltraSPARC 2005 بیان شد. این یک پلتفرم sun4v را تعریف می‌کند که یک ابرمجموعه از پلت فرم sun4u است، اما همچنان با مشخصات SPARC v9 Level-1 مطابقت دارد.
پاور پی سی ویرایش
همه دستورالعمل‌های حساس در مجموعه دستورالعمل‌هایPowerPC ممتاز هستند.[۸][۹]
کارایی در عمل ویرایش
الزامات کارایی در تعریف پوپک و گلدبرگ از VMM فقط به اجرای دستورالعمل‌های غیرممتاز مربوط می‌شود که باید به صورت بومی اجرا شوند. این همان چیزی است که یک VMM را از کلاس عمومی‌تر نرم‌افزارهای شبیه‌سازی سخت‌افزاری متمایز می‌کند. متأسفانه، حتی در یک معماری که الزامات پوپک و گلدبرگ را برآورده می‌کند، عملکرد یک ماشین مجازی می‌تواند به‌طور قابل توجهی با سخت‌افزار واقعی متفاوت باشد. آزمایش‌های اولیه روی System/370 (که ملزومات رسمی قضیه ۱ را برآورده می‌کرد) نشان داد که عملکرد یک ماشین مجازی می‌تواند در برخی از معیارها به حد بسیار کمی مانند ۲۱ درصد از ماشین بومی برسد. هزینه به دام انداختن و شبیه‌سازی دستورالعمل‌های ممتاز در VMM می‌تواند قابل توجه باشد. این امر باعث شد که مهندسان IBM تعدادی کمک سخت‌افزاری را معرفی کنند که تقریباً عملکرد ماشین‌های مجازی System/370 را دو برابر می‌کرد.[۱۰] کمک‌ها در چند مرحله اضافه شدند. در نهایت، بیش از ۱۰۰ کمک در مدل‌های اخیر System/370 وجود داشت.[۱۱]
یکی از عوامل محرک اصلی برای توسعه کمک‌های سخت‌افزاری System/370 خود حافظه مجازی بود. وقتی مهمان سیستم عاملی بود که خودش حافظه مجازی را پیاده‌سازی می‌کرد، حتی دستورالعمل‌های غیرممتاز می‌توانستند زمان اجرای طولانی‌تری داشته باشند - هزینه‌ای که با الزام دسترسی به جداول ترجمه که در اجرای اصلی استفاده نمی‌شدند پرداخت می‌شد (به جداول صفحه سایه مراجعه کنید).[۱۲]
منابع ویرایش
- ↑ Popek, G. J.; Goldberg, R. P. (July 1974). "Formal requirements for virtualizable third generation architectures". Communications of the ACM. 17 (7): 412–421. doi:10.1145/361011.361073.
- ↑ Rogier Dittner, David Rule, The best damn server virtualization book period, Syngress, 2007, شابک ۱−۵۹۷۴۹−۲۱۷−۵, p. 19
- ↑ Smith and Nair, p. 387
- ↑ ۴٫۰ ۴٫۱ Adams and Agesen, 2006, pp. 2-3
- ↑ ۵٫۰ ۵٫۱ Smith and Nair, p. 391
- ↑ Adams and Agesen, p. 1 and 5
- ↑ Smith and Nair, p. 395
- ↑ http://www.pagetable.com/?p=15
- ↑ https://www.cs.cmu.edu/~410-s07/lectures/L38_Virtualization.pdf
- ↑ Smith and Nair, p. 415-416 and 426
- ↑ Gum, p. 535
- ↑ Gum, p. 533