Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How does a Host machine really "host" a virtual machine? How is it given a kernel of its own? Are instructions and syscalls of a virtual machine translated into machine language and passed to the host? Is it passed down as a byte stream? Is there an interpreter which converts syscalls from the virtual operating system to the host operating system?
The more I think about Virtual Machines the more confusing it gets.
Answers to any of these would be great!
Part of the confusion is that the term 'virtual machine' has been co-opted to describe different things, so each requires a different answer. For example, the 'Java Virtual Machine (JVM)' is really just a program built to interpret a bytecode instruction set custom-built to support Java (though there is more to it than that, of course), so any attempt to answer your question in that context would be to explain how an interpreter works. What I am going to do is go back to the original meaning of 'virtual machine' and explain that. (note: I have no idea how much of what I am about to describe applies for modern VMs)
The term virtual machine originally described a multi-programming operating-system technique used to provide each of a large number of users their own complete computing environment. By 'complete' I mean this: Normally each user is given a 'space' for running programs, but each program can reach outside of its space only via a fixed, common operating system; in this technique, each user would be given a 'space' which appears to be an entire bare machine, so in particular each user could run their own multi-tasking operating system if they so chose.
The way this was achieved depended on two features of the hardware: (1) Programs could be run in one of two modes - user mode or system mode; (2) Some of the instructions are privileged (reserved for the OS), and may only be used in system mode - otherwise the machine 'traps' and tries to execute an illegal-instruction handler routine. This was exploited by having the base OS implement each user's space as a simulation of the same hardware, with simulated user-mode and simulated system-mode, etc. All of the user's code was always run in actual user-mode, regardless of the simulated mode. That means each instruction's execution was simulated by the actual hardware itself, with no interpretive overhead. The privileged instructions were an exception: They would always 'trap' to the actual operating system, which would handle the interrupt according to the user's simulated mode. If the user's 'machine' was in simulated user-mode, the actual operating system would simulate the hardware interrupt, adjusting the simulated machine state and transferring control to the instruction handler routine -in the simulation- (i.e in the user's space); if the user's 'machine' was in simulated system-mode, the actual operating system would emulate the privileged instruction, changing the user's 'machine state' accordingly.
Related
This question already has answers here:
How does the OS scheduler regain control of CPU?
(3 answers)
Closed 5 years ago.
I know that a single-CPU system can run only one process at any instant. My doubt is, how does OS being itself a separate process runs on the CPU mean while managing to schedule some other process aswell simultaneously (which is not possible,as only one process can be run on a single-CPU system).
In other words,if another process is consuming the CPU at any time does the OS be context switched ?? or where does the OS runs(as it has to be active always to monitor) ??
I even don't know whether its an appropriate question... but kindly let me know if you have an answer. OR correct me if I am wrong !!
Thanks in Advance !!
In a modern operating system the kernel, the core of the OS, in complete control of how much time it allocates to the various user processes it's managing. It can interrupt the execution of a user process through various mechanisms provided by the CPU itself. This is called preempting the process and can be done on a schedule, like executing a user process for a particular number of nanoseconds before automatically interrupting it.
In older operating systems, like DOS and Windows 1.0 through 3.11, macOS 9 and earier, plus many others, they employ a different mode where the user process is responsible for yielding control. If the process doesn't yield there may be little recourse to reassert control of the system. This can lead to crashes or lock-ups, a frequent problem with non-preemptive operating systems of all stripes.
Even then there is often hardware support for things like hardware timers that can trigger a particular chunk of code on a regular basis which can be used to rescue the system from a run-away process. Just because a bit of code is running is no guarantee that it will continue to run indefinitely, without interruption.
A modern CPU is a fantastically complicated piece of equipment. Those with support for things like CPU virtualization can make the single physical CPU behave as if it's a number of virtual CPUs all sharing the same hardware. Each of these virtual CPUs is free to do whatever it wants, including dividing up its time using either a pre-emptive or cooparative model, as well as splitting itself into even more virtual CPUs.
The long and the short of it here is to not assume that the kernel must be actively executing to be in control. It has a number of tools at its disposal to wrest control of the CPU back from any process that might be running.
I read this paragraph from " Modern Operating Systems , Tanenbaum "
Most computers have two modes of operation: kernel
mode and user mode. The operating system is the most fundamental piece of software and runs in kernel mode (also called supervisor mode). In this mode it has complete access to all the hardware and can execute any instruction the machine is capable of executing. The rest of the software runs in user mode, in which only a subset of the machine instructions is available.
I am unable to get how they are describing difference in these two modes on basis of machine instructions available , at user end any software has the capability to make any changes at the hardware level ,like we have software which can affect the functioning of CPU , can play with registry details , so how can we say that at user mode , we have only subset of machine instructions available ?
The instructions that are available only in kernel mode are tend to be very few. These instructions are those that are only needed to manage the system.
For example, most processors have a HALT instruction that stops the CPU that is used for system shutdowns. Obviously you would not want any user to be able to execute HALT and stop the computer for everyone. Such instructions are then made only accessible in kernel mode.
Processors use a table of handlers for interrupt and exceptions. The Operating system creates such a table listing the handlers for these events. Then it loads register(s) giving the location(and size) of the table. The instructions for loading this register(s) are kernel mode only. Otherwise, any application could create total havoc on the system.
Instructions of these nature will trigger an exception if executing in user mode.
Such instructions tend to be few in number.
Well, in user-mode, there is definitely a subset of instructions available. This is the reason we have System Calls.
Example:
A user wants to create a new process in C. He cannot do that without entering kernel-mode, because certain set of instructions are only available to kernel-mode, So he uses the system call fork, that executes instructions for creating a new process (not available in user-mode). So System call is a mechanism of requesting a service from kernel of the OS to do something for the user, which he/she cannot write code for.
Following excerpt from above link sums it up in the best way:
A program is usually limited to its own address space so that it
cannot access or modify other running programs or the operating system
itself, and is usually prevented from directly manipulating hardware
devices (e.g. the frame buffer or network devices).
However, many normal applications obviously need access to these
components, so system calls are made available by the operating system
to provide well defined, safe implementations for such operations. The
operating system executes at the highest level of privilege, and
allows applications to request services via system calls, which are
often initiated via interrupts. An interrupt automatically puts the
CPU into some elevated privilege level, and then passes control to the
kernel, which determines whether the calling program should be granted
the requested service. If the service is granted, the kernel executes
a specific set of instructions over which the calling program has no
direct control, returns the privilege level to that of the calling
program, and then returns control to the calling program.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
Okay as we know that a single processor can execute one instruction at one time, which means a single processor can execute either the Operating system's instruction or the user program's instruction at one time.
Now how is it possible that an operating system, and a user program can run at the same time in single processor?
Is cpu assigned to a user program when you open the program and when you close the user program the cpu is assigned back to the Operating system ??
Basically it is impossible to run two threads on a single processor core at once. However it is possible for the system to pretend to do this by swapping threads on and off the CPU. There are basically two ways to do this. Cooperative and Preemptive multitasking.
In the days of Windows 3, CPUs had a single core (I'm sure some big expensive machines had more but not that normal people got to see). Windows 3 didn't interrupt processes. What happened was processes had to periodically relinquish control to the OS. The OS would then continue the process again at a later time. This model is called cooperative multitasking.
Cooperative multitasking has a bit of an issue though. If a process fails to relinquish control to the OS (normally due to a bug) it can hog the system's resources and the system needs rebooting. This is why when Windows 95 was released Microsoft switched to a pre-emptive multitasking model.
With pre-emptive multitasking the hardware allows the OS to set an interrupt for a future time (how this is done varies by hardware system). This means that the OS can guarantee to get back on the CPU. When it does this, it stores the state (mainly the CPU registers) of the running thread and then loads a different one. This means that the OS always has control as it does not rely on the processes relinquishing control.
I'm sure other OS used pre-emptive multitasking before Windows 95 but it was Win 95 that really brought it to the mainstream on the PC.
Another issue that can occur is that one process tries to write to the memory used by another process, or a process tries to directly access some hardware without the operating system's permission. When the CPU starts up it is in Real Mode and loads the OS, the OS can then set up certain restrictions and switch the CPU to protected mode before running a process. While in protected mode the CPU will stop the process from accessing memory addresses and hardware that the OS has not allowed, forcing the process to call back to the OS to access these resources.
This is called Preemption or Time Slicing
In simple terms:
There are multi-threaded CPU's which can manage multiple threads (instructions)
But even that's not enough. The CPU has to split the workload, it does this by pausing a thread (called an interrupt) and working on another.
An average computer might have over a thousand threads running, but only 4 CPU Cores (which can only run 4 threads at a time)
How does it do it?
Some CPU's can only run 4 threads at a time, to manage all the other thousands of threads it must pause the thread and work on another and pause that and work on another, This is called Time Slicing time is not the only factor, priorities & usage come into play too. CPU's are really fast and can do this in < 1ms
EDIT: The "System Interrupts" is what manages all of this, it's not really a process in sense but this piece of windows is what controls all thread execution
Here a simple explanation from : http://doc.qt.io/qt-5/thread-basics.html:
So how is concurrency implemented? Parallel work on single core CPUs
is an illusion which is somewhat similar to the illusion of moving
images in cinema. For processes, the illusion is produced by
interrupting the processor's work on one process after a very short
time. Then the processor moves on to the next process. In order to
switch between processes, the current program counter is saved and the
next processor's program counter is loaded.
This question already has answers here:
What is an OS kernel ? How does it differ from an operating system? [closed]
(11 answers)
Closed last month.
i know that operating system is nothing without kernel. But I had been asked a question in interview that-
What is (OS-Kernel). So what exactly is left if we remove kernel from operating system.
(Please do not give it negative rating if it is silly, please give answer in comments and then i will delete this question).
In addition to Sam Dunk's (see other post) statement, there is one other part that is part of the "operating system" - for a given value of operating system: The boot loader.
When a PC (and presumably other architectures) boot up, the BIOS loads the boot sector. The BIOS is not part of the operating system. The boot sector (arguably) is. The boot sector (limited to 512 bytes!) loads the bootloader.
The bootloader may give options between different operating systems (where multiple operating systems are installed on the same computer), and/or options for loading the operating system (e.g. "Safe mode", or different run levels for Unix - q.v. etc). The bootloader then loads the (appropriate) kernel, runs it. As soon as control is passed to the kernel, the bootloader is discarded (until the next boot).
The above is somewhat simplified.
For further reading on how the parts fit together (in the case of Linux), see "Inside the Linux boot process" http://www.ibm.com/developerworks/library/l-linuxboot/ for example. The master boot record is referred to as "Stage 1 boot loader", and what I referred to as "the boot loader" they refer to as "Stage 2 boot loader".
Details will vary from O/S to O/S.
To add to Sam Dunk's answer, we have to think what is the purpose of having an operating system. An OS does memory management, process scheduling, devices management etc etc...but that is not why we need an OS. It is how the OS do its job. The reason we need an OS is it abstracts the underlying hardware infrastructure for applications. Period. Nothing else. The other stuff like user interface, system utilities, are just sugar added on top (hey a command line OS is still an OS). This is the kernel, or the core of the OS. It provides a simplified and consistent platform for applications to execute across multiple hardware configurations.
For an analogy, think about the pipes and cables behind the walls in your house. Without them your wall sockets and water taps are practically useless. The sinks, cabinets, walls to separate rooms, are the system applications. (They usually come with the house, but they aren't absolutely necessary.)
I'm studying for my operating systems final and was wondering if someone could tell me why the OS needs to switch into kernel mode for syscalls?
A syscall is used specifically to run an operating in the kernel mode since the usual user code is not allowed to do this for security reasons.
For example, if you wanted to allocate memory, the operating system is privileged to do it (since it knows the page tables and is allowed to access memory of other processes), but you as a user program should not be allowed to peek or ruin the memory of other processes.
It's a way of sandboxing you. So you send a syscall requesting the operating system to allocate memory, and that happens at the kernel level.
Edit: I see now that the Wikipedia article is surprisingly useful on this
Since this is tagged "homework", I won't just give the answer away but will provide a hint:
The kernel is responsible for accessing the hardware of the computer and ensuring that applications don't step on one another. What would happen if any application could access a hardware device (say, the hard drive) without the cooperation of the kernel?