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
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
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