Випуск гіпервізорів Xen 4.16 та Intel Cloud Hypervisor 20.0

Після восьми місяців розробки опубліковано реліз вільного гіпервізора Xen 4.16. У розробці нового випуску взяли участь такі компанії, як Amazon, Arm, Bitdefender, Citrix та EPAM Systems. Випуск оновлень для гілки Xen 4.16 триватиме до 2 червня 2023, а публікація виправлень уразливостей до 2 грудня 2024 року.

Ключові зміни в Xen 4.16:

  • TPM Manager, що забезпечує роботу віртуальних чіпів для зберігання криптографічних ключів (vTPM), що реалізуються на базі загального фізичного TPM (Trusted Platform Module), внесено виправлення для подальшої реалізації підтримки специфікації TPM 2.0.
  • Підвищена залежність від прошарку PV Shim, що застосовується для запуску немодифікованих паравіртуалізованих гостьових систем (PV) в оточеннях PVH та HVM. Надалі використання 32-розрядних паравіртуалізованих гостьових систем буде можливим лише в режимі PV Shim, що дозволить зменшити кількість місць у гіпервізорі, в яких потенційно можуть бути вразливі.
  • Додано можливість завантаження на пристроях Intel без програмованого таймера (PIT, Programmable Interval Timer).
  • Проведено чищення застарілих компонентів, припинено складання за умовчанням коду «qemu-xen-traditional» та PV-Grub (необхідність у даних специфічних для Xen форках зникла після передачі змін із підтримкою Xen до основного складу QEMU та Grub).
  • Для гостьових систем з архітектрою ARM реалізовано початкову підтримку віртуалізованих лічильників для відстеження продуктивності (Performance Monitor Counters).
  • Поліпшено підтримку режиму dom0less, що дозволяє обійтися без розгортання оточення dom0 при запуску віртуальних машин на ранній стадії завантаження сервера. Внесені зміни дозволили реалізувати підтримку 64-розрядних систем ARM з EFI-прошивками.
  • Поліпшено підтримку гетерогенних 64-розрядних систем ARM на базі архітектури big.LITTLE, що комбінують в одному чіпі потужні, але споживають багато енергії, ядра, і менш продуктивні, але більш енергоефективні ядра.

Одночасно компанія Intel опублікувала випуск гіпервізора Cloud Hypervisor 20.0, побудованого на основі компонентів спільного проекту Rust-VMM, в якому, крім Intel, також беруть участь компанії Alibaba, Amazon, Google і Red Hat. Rust-VMM написаний мовою Rust і дозволяє створювати специфічні для певних завдань гіпервізори. Cloud Hypervisor є одним із таких гіпервізорів, який надає високорівневий монітор віртуальних машин (VMM), що працює поверх KVM та оптимізований для вирішення завдань, властивих для хмарних систем. Код проекту доступний за ліцензією Apache 2.0.

Cloud Hypervisor cфокусовано на запуску сучасних дистрибутивів Linux з використанням паравіртуалізованих пристроїв на базі virtio. З ключових завдань згадується: висока чуйність, низьке споживання пам'яті, висока продуктивність, спрощення налаштування та скорочення можливих векторів для атак. Підтримка емуляції зведена до мінімуму і ставка робиться на паравіртуалізацію. В даний час підтримуються тільки системи x86_64, але в планах є підтримка AArch64. З гостьових систем поки що підтримується тільки 64-розрядні збірки Linux. Налаштування CPU, пам'яті, PCI та NVDIMM здійснюється на етапі збирання. Передбачено можливість міграції віртуальних машин між серверами.

В новой версії:

  • Для архітектур x86_64 та aarch64 тепер допускається створення до 16 PCI-сегментів, що збільшує загальну кількість допустимих PCI-пристроїв з 31 до 496.
  • Реалізовано підтримку прив'язки віртуальних CPU до фізичних ядр CPU (CPU pinning). Для кожного vCPU тепер можна визначити обмежений набір хостових CPU, на яких допускається виконання, що може бути корисним при прямому відображенні (1:1) ресурсів хоста та гостьової системи або запуску віртуальної машини на певному вузлі NUMA.
  • Поліпшено підтримку віртуалізації вводу/виводу. Кожен регіон VFIO тепер може бути відображений на згадку про те, що знижує кількість операцій виходу з віртуальної машини і дозволяє досягти підвищення продуктивності прокидання пристроїв у віртуальну машину.
  • У коді мовою Rust проведено роботу із заміни unsafe-секцій на альтернативні реалізації, що виконуються в режимі safe. Для unsafe-секцій, що залишилися, додані докладні коментарі з поясненням чому залишений unsafe-код можна вважати безпечним.

Джерело: opennet.ru

Додати коментар або відгук