Xen FAQ Design and in Depth

From Xen
Jump to navigationJump to search

How does Xen Work?

How does Xen process System Calls on para-virtualized guest?

When ever a system call is invoked via interrupt or sys center control gets transferred to the kernel (ring 0), which is then handled via system call handler. System call never goes to libc but Libc is a library that provides POSIX interface to the user space applications and in a way wrapper for invocation of a system call.

System call interrupt based [i386]: During booting process, linux kernel of a domU register's its IDT with Xen Hypervisor via HYPERVISOR_set_trap_table(trap_table); [arch/i386/kernel/traps-xen.c]. Xen maintains two IDT's, one global IDT (its own) and other per domain IDT. Xen uses global IDT to register the entire trap handler except for system call handler (int 0x80). When a VM gets scheduled, its system call handler (from per domain IDT table) is registered with the processor. Hence when a domain/VM executes a system call, its own handler is executed.

Implementation differs for x86_64: Xen registers its own system call handler with the processor and from that handler routes the request to VM/Domain specific handler.

How does Xen process System Calls on fully virtualized guest (HVM)?

For HVM domU there is no change in the behavior of the system call. HVM is only supported for Intel-VT and AMD-SVM processors. These processors are virtualization aware. Virtualization aware processors provide a new ring (Root-Ring 0) with higher privilege for VMM and Guest OS continues to runs with the same privilege (as without Xen) in Non-Root Ring 0. Guest OS can issue the system calls the way it used to without Xen.

Can I run various DomU operating systems on a different Dom0 operating system?

Yes.

How can I tell if my OS is running on a physical machine or a virtual machine ?

You should be able to get some useful information from the DMI, e.g: 

% for i in system-manufacturer system-product-name system-version\ system-serial-number; do echo
-n "$i: "; sudo dmidecode -s $i; done

system-manufacturer: Xen system-product-name: HVM domU system-version: 3.3.1 system-serial- number: 89e5915f-dead-beef-cefd-46904ea94c4a

OR

Probably checking kernel process, check your process table for: [xenwatch] [xenbus] Another clue is checking the kernle suffix, for example: 

# uname -r 2.6.24-23-xen and the proc files:
/proc/xen/capabilities

What is STUBDOM ?

Stubdoms are lightweight 'service' or 'driver' domains. The initial purpose was to offload qemu (for hvm guests) out of dom0.

So with stubdoms you can run hvm guest qemu in a separate stubdom, which boosts performance and makes it more secure.

stubdoms can also run for example pv-grub for pv guests, making it more secure compared to pygrub, which always runs in dom0.

http://wiki.xensource.com/xenwiki/StubDom

Presentation about stubdoms at Xen Summit: http://www.xen.org/files/xensummitboston08/SamThibault_XenSummit.pdf

http://blog.xen.org/index.php/2008/08/28/xen-33-feature-stub-domains/ http://blog.xen.org/index.php/2008/08/28/xen-33-feature-hvm-device-model-domain/ http://lxr.xensource.com/lxr/source/stubdom/README

When is hardware virtualization used in Xen? Is it required?

Xen uses hardware virtualization for HVM guests. Xen will not launch a HVM guest unless hardware virtualization is turned on.

Retrieved from "https://wiki.xenproject.org/index.php?title=Xen_FAQ_Design_and_in_Depth&oldid=5390"