Механізм обслуговування системних викликів
Контрольная работа - Компьютеры, программирование
Другие контрольные работы по предмету Компьютеры, программирование
?оже перестати виконуватися коректно. При цьому системний виклик в кожній віртуальній машині повинен обслуговуватися тільки з тими параметрами (файловий дескриптор), які відносяться до ресурсів даної ВМ.
При перехопленні запиту на виконання системного виклику, що вимагає одночасного виконання в обох ВМ, гіпервізор, використовуючи таблицю віддалених ресурсів, розшивають фактичні параметри на два непересічних набору (по одному для кожної з ВМ) і виконує виклик одночасно в обох ВМ з відповідними наборами параметрів. Модифікований набір параметрів записується в память довіреної процесу поверх оригінального. Перед поверненням управління процесу (після обслуговування системного виклику) гіпервізор відновлює вихідний набір параметрів, можливо, коректуючи його з урахуванням результатів системного виклику, отриманих з сервісної ВМ. Підсумковим результатом виконання системного виклику є результат тієї ВМ, яка хронологічно першою закінчила виконання своєї частини виклику, результати другий ВМ відкидаються.
Після отримання результатів від однієї з ВМ гіпервізор виробляє скасування виконання системного виклику в іншій ВМ. Механізм скасування виконання системного виклику реалізований в обох віртуальних машинах по-різному. У разі обчислювальної ВМ модуль ядра посилає довіреній процесу певний сигнал (не використовується процесом). При цьому модуль системи захисту безпосередньо перед посилкою сигналу реєструє для процесу спеціальний порожній обробник сигналу, що представляє собою адресу RET інструкції в коді довіреної програми. Адреса інструкції вказується в паспорті завдання. Реєстрація обробника гарантує, що посилка сигналу не призведе до аварійного останову процесу. У сервісній ВМ всі системні виклики, які можуть виконуватися одночасно в обох ВМ, виконуються в окремому потоці (нитки) делегати. Скасування виконання системного виклику проводиться за допомогою примусового завершення цього потоку.
3. Продуктивність системи
Описана в цій роботі система реалізована на базі монітора віртуальних машин KVM [9]. KVM включений в основну гілку розробки ядра ОС Linux і являє собою модуль, що динамічно завантажений в ядро базової (хост) операційної системи Linux. Управління виконанням ВМ реалізується спільно ядром хост системи, модулем KVM та користувацький програмою QEMU. QEMU віртуалізується периферійні пристрої та забезпечує спільний доступ віртуальних машин до обладнання, встановленого на компютері і керованого базовою системою.
Реалізація, представлена в цій роботі, побудована на базової операційної системи Linux з ядром версії 2.6.31.6 і моніторі віртуальних машин KVM версії 88. Сумарний обсяг коду компонент системи складає близько 16 тис. рядків. Віртуальні машини виконуються під управлінням ОС Linux з дистрибутива Fedora версії 9 зі штатним ядром версії 2.6.27.1278.2.8.fc9.i686. На компютері встановлений чотирьохядерних процесор Phenom 9750 компанії AMD з тактовою частотою 2.4 Ггц і 2 Гбайта оперативної памяті. Даний процесор підтримує технологію апаратної віртуалізації, включаючи віртуалізацію памяті на базі вкладених (NPT) таблиць приписки віртуальної машини. Базова операційна система використовує всі чотири ядра процесора (ядро базової ОС зібрано в SMP-конфігурації). Кожній віртуальній машині виділяється по одному віртуальному процесору і по 512 Мбайт оперативної памяті.
Для проведення ряду тестів використовується другий компютер такої ж конфігурації. В обох компютерах встановлені 100 Мбіт-ві мережеві адаптери, повязані один з одним через мережевий концентратор (хаб). До концентратора підключені тільки дані дві машини.
Доступ віртуальної машини до мережі здійснюється за допомогою створення в базовій ОС штатними засобами ядра ОС програмного мережевого інтерфейсу (TAP0). Цей інтерфейс є образом мережевого інтерфейсу (ETH0) віртуальної машини в базовій системі. Привязка інтерфейсу TAP0 до фізичної середовищі здійснюється через програмний Ethernet-міст (bridge) в ядрі базової ОС, також організовуваний штатними засобами ОС Linux. Така конфігурація (мал. 1) дозволяє відкрити ВМ для інших машин в мережі, на відміну від конфігурації QEMU за замовчуванням, що приховує ВМ від інших машин в мережі за допомогою механізму трансляції мережевих адрес (NAT) і роздільної лише вихідні зєднання в ВМ.
Для тестування продуктивності ми використовували чотири спеціально розроблених синтетичних тесту, моделюючих важкі для системи сценарії використання, і три типових програми: утиліту тестування продуктивності мережі TTCP, програму віддаленого доступу SSH і веб-сервер Apache.
Синтетичні тести засновані на виконанні системного виклику select () з одним або двома файловий дескриптор. Один з дескрипторів (локальний), позначимо його LocalFD, являє собою файл, відкритий в контексті обчислювальної ВМ, другий (віддалений), позначимо його RemoteFD, сокет, створений в сервісній ВМ. У всіх тестах, крім першого, виконання системного виклику вимагає взаємодії між ВМ. Тести запускаються з контексту обчислювальної ВМ.
Рисунок 5. Конфігурація мережі для тестування продуктивності.
Обрамлення дескриптора квадратними дужками означає, що запитувана операція не може бути виконана для даного ресурсу, і системний виклик заблокує виконання відповідного користувацького процесу в одній з ВМ. Відсутність квадратних дужок означає можливість виконання операції і негайне повернення управління для користувача процесу. Тоді синтетичні тести пер