Pagkatapos ng isang taon ng pag-unlad, ang libreng hypervisor Xen 4.17 ay inilabas. Ang mga kumpanya tulad ng Amazon, Arm, Bitdefender, Citrix, EPAM Systems at Xilinx (AMD) ay nakibahagi sa pagbuo ng bagong release. Ang pagbuo ng mga update para sa Xen 4.17 branch ay tatagal hanggang Hunyo 12, 2024, at ang paglalathala ng mga pag-aayos sa kahinaan hanggang Disyembre 12, 2025.
Mga pangunahing pagbabago sa Xen 4.17:
- Ang bahagyang pagsunod ay ibinibigay sa mga kinakailangan para sa pagbuo ng ligtas at maaasahang mga programa sa wikang C, na binuo sa mga pagtutukoy ng MISRA-C na ginamit sa paglikha ng mga sistemang kritikal sa misyon. Opisyal na ipinapatupad ng Xen ang 4 na direktiba at 24 na panuntunan ng MISRA-C (mula sa 143 na panuntunan at 16 na direktiba), at isinasama rin ang MISRA-C static analyzer sa mga proseso ng pagpupulong, na nagpapatunay sa pagsunod sa mga kinakailangan sa detalye.
- Nagbibigay ng kakayahang tumukoy ng isang static na configuration ng Xen para sa mga ARM system, na nag-hard-code sa lahat ng mga mapagkukunang kailangan para ma-boot ang mga bisita nang maaga. Ang lahat ng mga mapagkukunan, tulad ng nakabahaging memorya, mga channel ng notification ng kaganapan, at hypervisor heap space, ay paunang inilalaan sa hypervisor startup sa halip na dynamic na inilalaan, na inaalis ang mga posibleng pagkabigo dahil sa mga kakulangan ng mapagkukunan sa panahon ng operasyon.
- Para sa mga naka-embed na system batay sa arkitektura ng ARM, ipinatupad ang eksperimental (tech preview) na suporta para sa virtualization ng I/O gamit ang mga protocol ng VirtIO. Ang virtio-mmio transport ay ginagamit upang makipagpalitan ng data sa isang virtual na I/O device, na nagsisiguro ng compatibility sa isang malawak na hanay ng mga VirtIO device. Ang suporta para sa Linux frontend, toolkit (libxl/xl), dom0less mode at mga backend na tumatakbo sa user space ay naipatupad na (virtio-disk, virtio-net, i2c at gpio backends ay nasubok na).
- Pinahusay na suporta para sa dom0less mode, na nagbibigay-daan sa iyong maiwasan ang pag-deploy ng dom0 environment kapag nagsisimula ng mga virtual machine sa maagang yugto ng server boot. Posibleng tukuyin ang mga CPU pool (CPUPOOL) sa yugto ng boot (sa pamamagitan ng device tree), na nagbibigay-daan sa iyong gumamit ng mga pool sa mga configuration na walang dom0, halimbawa, upang i-bind ang iba't ibang uri ng CPU core sa ARM system batay sa malaki.LITTLE arkitektura, pinagsasama ang makapangyarihan, ngunit umuubos ng enerhiya na mga core, at hindi gaanong produktibo ngunit mas mahusay sa enerhiya na mga core. Bilang karagdagan, ang dom0less ay nagbibigay ng kakayahang itali ang paravirtualization frontend/backend sa mga guest system, na nagbibigay-daan sa iyong i-boot ang mga guest system gamit ang mga kinakailangang paravirtualized na device.
- Sa mga ARM system, ang mga istruktura ng virtualization ng memorya (P2M, Physical to Machine) ay inilalaan na ngayon mula sa memory pool na nilikha noong ginawa ang domain, na nagbibigay-daan para sa mas mahusay na paghihiwalay sa pagitan ng mga bisita kapag may nangyaring mga pagkabigo na nauugnay sa memorya.
- Para sa mga sistema ng ARM, idinagdag ang proteksyon laban sa kahinaan ng Spectre-BHB sa mga istrukturang microarchitectural ng processor.
- Sa mga ARM system, posibleng patakbuhin ang Zephyr operating system sa Dom0 root environment.
- Ang posibilidad ng isang hiwalay na (out-of-tree) hypervisor assembly ay ibinigay.
- Sa mga x86 system, ang malalaking IOMMU page (superpage) ay sinusuportahan para sa lahat ng uri ng guest system, na nagbibigay-daan sa pagtaas ng throughput kapag nagpapasa ng mga PCI device. Nagdagdag ng suporta para sa mga host na nilagyan ng hanggang 12 TB ng RAM. Sa yugto ng boot, ang kakayahang magtakda ng mga parameter ng cpuid para sa dom0 ay ipinatupad. Upang makontrol ang mga hakbang sa proteksyon na ipinatupad sa antas ng hypervisor laban sa mga pag-atake sa CPU sa mga guest system, ang mga parameter na VIRT_SSBD at MSR_SPEC_CTRL ay iminungkahi.
- Ang VirtIO-Grant transport ay binuo nang hiwalay, na naiiba sa VirtIO-MMIO sa pamamagitan ng mas mataas na antas ng seguridad at ang kakayahang magpatakbo ng mga humahawak sa isang hiwalay na nakahiwalay na domain para sa mga driver. Ang VirtIO-Grant, sa halip na direktang pagmamapa ng memorya, ay gumagamit ng pagsasalin ng mga pisikal na address ng guest system sa mga grant link, na nagpapahintulot sa paggamit ng mga paunang napagkasunduang bahagi ng shared memory para sa pagpapalitan ng data sa pagitan ng guest system at ng VirtIO backend, nang hindi nagbibigay ang mga karapatan sa backend na magsagawa ng memory mapping. Ang suporta ng VirtIO-Grant ay ipinatupad na sa kernel ng Linux, ngunit hindi pa kasama sa mga backend ng QEMU, sa virtio-vhost at sa toolkit (libxl/xl).
- Ang inisyatiba ng Hyperlaunch ay patuloy na umuunlad, na naglalayong magbigay ng mga naiaangkop na tool para sa pag-configure ng paglulunsad ng mga virtual machine sa panahon ng system boot. Sa kasalukuyan, ang unang hanay ng mga patch ay naihanda na na nagbibigay-daan sa iyong makita ang mga PV domain at ilipat ang kanilang mga larawan sa hypervisor kapag naglo-load. Naipatupad na rin ang lahat ng kailangan para patakbuhin ang mga naturang paravirtualized na domain, kabilang ang mga bahagi ng Xenstore para sa mga driver ng PV. Kapag natanggap na ang mga patch, magsisimula ang trabaho upang paganahin ang suporta para sa mga PVH at HVM na device, gayundin ang pagpapatupad ng isang hiwalay na domain ng domB (tagabuo ng domain), na angkop para sa pag-aayos ng isang sinusukat na boot, na nagkukumpirma sa bisa ng lahat ng na-load na bahagi.
- Patuloy ang trabaho sa paglikha ng port ng Xen para sa arkitektura ng RISC-V.
Pinagmulan: opennet.ru