Duplicate all threads or just the calling thread if fork()
called?
- What if the child calls exec just after the fork?
- What if child does not call exec and current threads
including the thread calling fork are using mutexes.
- Duplicate all threads (POSIX - no, just the calling thread,
but...)
- Solaris: fork (all threads duplicated) and fork1 (Only
calling thread
- POSIX provides calls to ensure other threads than calling
thread do not own mutex locks (duplicated in child process)
Low Level
- Handles organization of files on disks/media: data structure
to find/allocate disk blocks
- File meta data: permissions, owner, times
Higer Level
E.g., Linux VFS (virtual file system)
- Interface for accessing a file system
- Support multiple file systems. Each one implements the vfs interface.
Window supports multiple file systems: e.g., FAT16, FAT32,
NTFS
Linux VFS supports multiple file ext2, ext3, ext4, and the
Windows file systems.
Linux Interface in C
Each file system has its own FileObject (below) and must
provide the functions that are inserted into its FileObject's
array of file_ops.
typedef struct {
unsigned short refcount;
struct file_ops *file_op;
/* function pointers */
} FileObject;
Access at higher level is through an array of function
pointers. Higher level uses same interface for all file
systems, just a different FileObject instance.
An "efficient" isolated duplicate of a real machine.
Virtual Machine |
Real Machine |
User |
|
Privileged |
User |
|
Privileged |
The virtual machine runs on the (real) processor.
- virtual user mode: (real) processor is in user mode.
- virtual privileged mode: (real) processor is in user mode.
This pops a value off the stack and uses it to set the flags
register.
This is a sensitive instruction.
If the processor is in user mode, the bit in the flags register
to disable interrupts will not be changed by popf regardless of
the value popped off the stack.
Virtualization: Guest OS runs unmodified on host vmm.
Paravirtualization: Small modificatinos of Guest to make
virtualization simpler and/or more efficient.
Modifications include to guests some hypervisor
calls.
A hypervisor call is a mechanism that allows a guest
os to make calls to the vmm (virtual machine monitor) running on
the real machine.
Xen (see the text) provides virtual machines using paravirtualization.
Xen (like VMWare) uses a standard operating system for control
functions including controlling actual devices. But it must be
modified somewhat to handle the hypervisor calls from virtual
machines and their guest OS's.
Unlike VMWare, guests VMs are NOT run as processes under
control of the standard os.
In Xen guests are run in Xen "domains" that communicate with
the standard os via hypervisor calls.
Three examples of paravirtualization in Xen:
- To avoid flushing the TLB (translation lookaside buffer:
page table entry cache) when invoking the vmm, Xen mapped into
the upper 64Mb of each VM address space.
- Guest allowed to allocated pages, just check that it didn't
violate protection restrictions.
- To protect guest OS from user programs, Xen takes advantage
of Intel processor's 4 protection levels:
- Most OS's running on Intel only use level 0 (kernel) and
level 3 (user)
- Xen runs as VMM at level 0
- Guest OS runs at level 1
- Applications run at level 3
The operating systems that can be used as the "standard os"
supported by Xen currently includes recent versions of Linux and
NetBSD.
To simplify I/O, a separate domain can be used just to handle a
device (perhaps running at a lower privilege level, but not at
user level; e.g. level 1) - sometimes called a "driver
domain".
(In Xen, "domain" == virtual machine)
- Driver domains run physical device drivers
- Regular guest domains use simple virtual drivers and
communicate with driver domains or the standard domain
(how?).
- Data is exchanged between guest and driver domains by page
remapping; that is, no copying of data.
Linux has optimizations for:
- network interface to directly store packets at different
memory locations to avoid having to copy from buffers to the network protocol
functions that process the packets. Not Xen. This results in up
to 4 times as many L2 cache misses for Xen compared to native
Linux.
- Data TLB misses. Linux also has optimizations here not currently
addressed in Xen. Causes 12 - 24 times as many Data TLB misses
The functions you are to write to build your uthreads library
naturally fall into 2 groups: the synchronization functions and
the thread management functions (creation, scheduling, etc.)
Here is a suggested guide for first implementing and testing
the management functions.
Once you have those working, you can implement and test the
second group.