Device virtualization and management in xen
2 likes3,083 views
The document discusses device virtualization and management in the Xen virtualization platform. It covers topics such as Xen architecture, paravirtualization of devices using the backend/frontend model, full virtualization of devices using emulation, and direct assignment of physical devices to virtual machines. The backend driver runs in privileged domain 0 and multiplexes access to the actual device, while the frontend driver runs in unprivileged guest domains. Paravirtualized devices use XenBus and XenStore for communication, while fully virtualized devices rely on emulation with QEMU. Direct device assignment grants physical devices directly to guests without virtualization.
Device virtualization and management in xen
- 1. Device Virtualization and Management in Xen Lingfei Kong 2014-11-10 Contents 1 Device Virtualization and Management in Xen 2 1.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Agenda 3 3 Xen Virtualizaiton Architecture 4 3.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 Device Virtualization 4 4.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 Paravirtualization of Devices 4 6 Backends and Frontends 6 7 Backends and Frontends 7 7.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 Backends and Frontends - Device Initialization 10 8.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9 Backends and Frontends - Device Closedown 11 10 Backends and Frontends - Device Closedown 13 11 Full Virtualization of Devices 14 11.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 12 No Virtualization 15 1
- 2. 13 No Virtualization 16 13.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 14 No Virtualization 17 14.1 Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 15 Reference 18 16 Q & A 18 1 Device Virtualization and Management in Xen slide 2
- 3. 1.1 Note notes • All test cases: 268, related to device: 100, The are important cases 2 Agenda slide • Xen Virtualization Architecture • Device Virtualization • Paravirtualization of Devices • Backends and Frontends • Backends and Frontends - Device Initialization • Backends and Frontends - Device Closedown • Full Virtualization of Devices • No Virtualization • Q & A • Reference 3
- 4. 3 Xen Virtualizaiton Architecture slide 3.1 Note notes • 3 layers 4 Device Virtualization slide • Paravirtualization of Devices • Full Virtualization of Devices • No Virtualization 4.1 Note notes 5 Paravirtualization of Devices slide • General approach to device management 4
- 5. • Dom0 manages the actual device driver and exports a generic class of device • Use Backend/Frontend model • PV on HVM – From rhel6 * xen_emul_unplug=never -> this will force guest to use em-ulated devices * xen_emul_unplug=unnecessary -> will use pv driver if there are xen pv drivers loaded • Advantage of Paravirtualization Devices: – Allows guest operating systems to implement only one device driver for each generic class of devices – Much easier to make a new operating system usable – Similar performance to physical machine > 90% • Each virtual device has three major components – A shared memory page containing the ring buffers – An event channel signaling activity in the ring – A XenStore entry containing configuration information 5
- 6. 6 Backends and Frontends slide • Guest issues device request to frontend driver, frontend driver commu-nicates with backend driver. Backend queues up the request and eventually issues the request to the actual underlying hardware • Backend – Runs in privileged domain – Multiplexing the use of the device – Responsible for protecting the security and privacy of data • Frontend – Runs in unpriviledge guests – Need pv drivers installed on guest os 6
- 7. 7 Backends and Frontends slide • XenBus and XenStore – XenBus provides a bus abstraction for paravirtualized drivers to communicate between backend/frontend drivers – Use XenStore to exchange the basic parameters needed to make the connection between frontend and backend drivers – Both user space and kernel code can write to the XenStore.The kernel code writes to the XenStore by using XenBus. * xenstore-ls, xenstore-list, xenstore-read, xenstore-write, xenstore-r – Glance of XenStore 7
- 8. – Backend and Frontend connect(take block device driver for exam-ple) 7.1 Note notes • /vm/uuid/{image,device,shadow_memory,uuid,on_crash,on_reboot,start_time,on_poweroff,name,• /vm/uuid/image/{ostype,kernel,cmdline,ramdisk} • /vm/uuid/device/{frontend,frontend-id,backend-id,backend} • local/domain 8
- 9. 9
- 10. 8 Backends and Frontends - Device Initialization slide 10
- 11. 8.1 Note notes • The details to be written are: The details to be written are: /local/domain/0/backend/vbd/U/<deviceID>/... frontend /local/domain/U/device/vbd/<deviceID> frontend-id U state XenbusStateInitialising ... <device-specific details> /local/domain/U/device/vbd/<deviceID>/... backend /local/domain/0/backend/vbd/U/<deviceID> backend-id 0 state XenbusStateInitialising ... <device-specific details> • netback_probe(), blkback_prob() • page map, page transfer 9 Backends and Frontends - Device Closedown slide • Device unplug request to Xend 11
- 12. 12
- 13. 10 Backends and Frontends - Device Closedown slide • Device driver encounter an error 13
- 14. 11 Full Virtualization of Devices slide • Use actual device driver to communicate with the emulated device 14
- 15. • No need pv/frontend drivers installed on guest os • Use qemu-dm to provide device emulation for HVM guests with virtu-alization extensions such as Intel-VT or AMD-V • Disadvantage of full virtualization devices – Less portable than the paravirtualized model – Less performance than the paravirtualized mode 11.1 Note notes • VT-x add 10 opcodes, such as: VMCALL, VMXON, VMXOFF, VM-RESUME, VMWRITE, VMREAD • AMD-V add 8 opcodes • VMD-V, IOMMU, VT-D • VMCS, VMCB • There is of course a performance cost for using QEMU, so there are chances that usage of QEMU will be replaced in the future with dif-ferent soulutions which have lower performance costs. • SVM stands for "Secure Virtual Machine". 12 No Virtualization slide • Grant physical devices directly to an unprivileged domain 15
- 16. • The guest (domU) needs to have a driver for the actual PCI device, PV guests also need to have a generic Xen PCI frontend driver. • Xen PCI passthru to a PV (paravirtual) guest – If you want DMA * Add "swiotlb=force" to guest’s kernel command line – PCI quirks * No permission pciback 0000:08:00.0: Driver tried to write to a read-only configuration space field at offset 0xe0, size 2. This may be harmless, but if you have problems with your device: * lspci -nn * Add vendor id to /etc/xen/xend-pci-permissive.sxp 13 No Virtualization slide • Xen PCI passthru to an HVM (fully virtualized) guest – No special configuration for the guest kernel • Granting Control of a PCI Device – PCI pass-through * Enable VT-d in BIOS * Hide PCI Device from Dom0 16
- 17. #lspci -D |grep USB 0000:00:0b.0 USB controller: NVIDIA Corporation MCP51 USB Controller (rev 0000:00:0b.1 USB controller: NVIDIA Corporation MCP51 USB Controller (rev # echo 0000:00:0b.1 > /sys/bus/pci/devices/0000:00:0b.1/driver/unbind 13.1 Note notes • NIC, disk controller, HBA, USB controller, firewire controller, sound-card, etc 14 No Virtualization slide • – * Binding the PCI Device to pciback driver # modprobe pciback # lsmod |grep pciback pciback 65617 0 # echo 0000:00:0b.1 > /sys/bus/pci/drivers/pciback/new_slot # echo 0000:00:0b.1 > /sys/bus/pci/drivers/pciback/bind * Check the hidden PCI Device # xm pci-list-assignable-devices 0000:00:0b.1 * Granting the PCI Device to Another Domain # xm pci-detach <guest> <pci device> 14.1 Note • <domain>:<bus>:<slot>.<function>: domain refers to a PCI do-main not xen domain • 17
- 18. 15 Reference slide • Block device model • PCI pass-through • Xen PCI Passthrough • XenStore • Backend and Fontend • Virtualization Background • Driver Domain 16 Q & A slide 18