Change the code in OS to make it easier to virtualize.
Xeno Linux: A version of Linux ported over to Xen
1% to 3% code changes required to port over the system
Xen Architecture:
- Type 1 hypervisor: runs directly over the hardware.
- Trap and Emulate architecture:
- Xen runs in ring 0 and Guest OS in Ring 1
- Guest OS traps to the Xen for privileged instruction.
- Xen sits in top 64MB of the address space of guests
- Guest VM is also called a domain:
- dom0: special domain that runs control/management software
CPU Virtualization
Q: So what are the modifications required?
A: Guest OS is modified to not invoke any privileged instructions. Any privilege instruction is trapped in Xen and then executed.
Guest → Xen
Hypercalls: guest OS voluntarily invokes Xen to perform privileged ops.
- very similar to syscalls where userspace programs invoke the kernel
- synchronous: guest pauses while Xen services the hypercall.
Xen → Guest
Asynchronous Event Mechanism: communication from Xen to Domain:
- Much like interrupts from hardware to kernel
- Used to deliver hardware interrupts and other notifications to domain
- Domain registers event handler callback functions
so when Xen needs to send an interrupt due to hardware (maybe keypress ) or maybe shut down requests
virtual interrupts are used, it sends an event which is handled by the event handler on the guest os side of things.
Steps: Xen Sending an Event to a Guest Domain
- Guest OS registers an event handler (callback function) with Xen.
- Xen receives an event (e.g., a network packet or disk I/O completion).
- Xen queues the event in the guest’s event channel.
- Guest OS is notified asynchronously, similar to an interrupt.
- Guest OS executes the registered event handler to process the event.
Trap Handling
Copies the trap frame onto the guest os kernel stack, invokes guest interrupt handler.
Guest registers interrupt descriptor table with Xen
- Interrupt handlers are validated by Xen (check no privileged segments are loaded)
Guest Trap Handlers then use the information on the kernel stack to perform the operation, no modifications required to guest OS code.
- Except page fault handler, which needs to read CR2 register to find faulting address.
- So page fault handler is modified to read the address from kernel stack instead of the register. Xen places the address in the stack
CR2 holds the virtual address of the last page that caused page fault
CR3 holds the physical address of the base of the current table.
What if interrupt handler invokes privileged?
Traps to Xen again and Xen detecs it as double fault (trap followed by another trap from interrupt handler code) and terminates misbehaving guest.
Memory Virtualization in Xen:
One copy of GVA → HPA is maintained by guestOS.
- CR3 points to the page table
- Like shadow page table but stored in guest memory not in VMM
Guest is given read only access to the Guest “RAM” mappings (GPA → HPA) - Using this guest can construct combined GVA → GPA mapping
Guest Page table is in guest memory so Xen validates the address requested. how?
- Guest marks its pages as read only, cannot modify
- When guest needs to update, it makes a hypercall to Xen to update page table
- Xen validates updates (is guest accessing it’s slice of RAM) and applies them
- Batches updates for better performance
Segment descriptors tables are also maintained similarly:
- read only copy in guest memory, updates are validated and applied by Xen
- Segments are truncated to exclude top 64MB occupied by Xen
I/O Virtualization in Xen
similar to virtio: shared memory ring
frontend is guest domain
backend is dom0
Requests placed by guest domain
I/O requests handled by Xen/domain0, responses placed in ring
descriptors in queue: pointers to request data (DMA buffers to write, empty DMA buffers for reads etc.)
similar design to virtio
- No copying of request data
- Memory Pages swapped between domains for request and response
- Batching for higher performance
