I'm trying to implement a "Semantic based memory sharing model" for Xen. As a part of my project, i'm trying to share kernel code pages across VMs. I' ve assumed that the code segments of linux kernels with similar version are 100% identical. But when i carry out some experiments using Virtual Machines running Debian Squeeze, i have found 3 memory pages are different in kernel code segment.
So my question is that, does the linux kernel modifies its code pages at runtime?
Yes, it can - for example, spinlocks can be dynamically patched out of the code if the kernel sees at runtime that it is running on a uniprocessor system. I do not know of an exhaustive list of such cases, you will need to inspect the code.
See the LWN article on SMP Alternatives for more information on one system that does runtime patching within the kernel.
Related
I'm currently struggling to determine how I can get an emulated environment via QEMU to correctly display output on the command line. I have an environment that displays perfectly well using the virt reference board, a cortex-a9CPU, and the 4.1 Linux kernel cross-compiled for ARM. However, if I swap out the 4.1 kernel for 2.6 or 3.1, suddenly I can no longer see console output.
While solving this issue is my main goal, I feel like I lack a critical understanding of how Linux and the hardware initially integrate before userspace configurations via boot scripts and whatnot have a chance to execute. I am aware of the device tree, and have a loose understanding of how it works. But the issue I ran into where a different kernel version broke console availability entirely confounds me. Can someone explain how Linux initially maps console output to a hardware device on the ARM architecture?
Thank you!
The answer depends quite a bit on which kernel version, what config options are set, what hardware, and also possibly on kernel command line arguments.
For modern kernels, the answer is that it looks in the device tree blob it is passed for descriptions of devices, some of which will be serial ports, and it initializes those. The kernel config or command line will specify which of those is to be used for the console. For earlier kernels, especially if you go all the way back to 2.6, use of device tree was less universal, and for some hardware the boot loader simply said "this is a versatile express board" (for instance) and the kernel had compiled-in data structures to tell it where the devices were for each board that it supported. As the transition to device tree progressed, boards were converted one by one, and sometimes a few devices at a time, so what exactly the situation was for any specific kernel version depends on which board you're using.
The other thing that I rather suspect you're running into is that if the kernel crashes early in bootup (ie before it finds the serial port at all) then it will never output anything. So if the kernel is just too early to support the "virt" board properly at all, or if your kernel config is missing something important, then the chances are good that it crashes in early boot without being able to print you a useful message. (Sometimes "earlycon" or "earlyprintk" kernel arguments can assist here, but not always.)
We have built a simple instruction set simulator for the sparc v8 processor. The model consists of a v8 processor, a main memory and a character input and a character output device. Currently I am able to run simple user-level programs on this simulator which are built using a cross compiler and placed in the modeled main memory directly.
I am trying to get a linux kernel to run on this simulator by building a simplest bootloader. (I'm considering uClinux which is made for mmu-less systems). The uncompressed kernel and the filesystem are both assumed to be present in the main memory itself, and all that my bootloader has to do is pass the relevant information to the kernel and make a jump to the start of the kernel code. I have no experience in OS development or porting linux.
I have the following questions :
What is this bare minimum information that a bootloader has to supply to the kernel ?
How to pass this information?
How to point the kernel to use my custom input/output devices?
There is some documentation available for porting linux to ARM boards, and from this documentation, it seems that the bootloader passes information about the size of RAM etc
via a data structure called ATAGS. How is it done in the case of a Sparc processor? I could not find much documentation for Sparc on the internet. There exists a linux bootloader for the Leon3 implementation of Sparc v8, but I could not find the specific information I was looking for in its code.
I will be grateful for any links that explain the bare minimum information to be passed to a kernel and how to pass it.
Thanks,
-neha
I've a vmware image with windows 7 and a program needs winring0 dll but when I start the program I get the error message: I cannot initialize winring0 dll but my program works in native Windows 7? Is this a known problem with a vmware image? How can I initialize winring0 in vmware image? In my folder there is winring0 dll for 32 bit and 64 bit.
Basically, you are attempting to find information about your hardware on virtual hardware. This concept alone is likely to be full of problems.
VMware utilizes Binary Translation(See here) to execute privileged instructions in the kernel if your processor does not support VT-x (assuming intel) . It is quite possible that it was unable to properly translate the file when attempting to load, due to the fact that the dll very well may contain instructions that vmware was not built to translate, or non-virtualizable instructions, at which point it would fail to initialize. If your processor does support hypervisor assist technology (VT-x or Pacifica), further research may be required. See Here for a high level of overview of how VMware works.
Finally, as a last ditch attempt, the dll may require that it load into a specific memory address which conflicts with VMware memory spaces, at which point it would fail to initialize as well. Like said, being inside of vmware increases the complexity of this problem.
Check out the following two links :-
http://www.techpowerup.com/realtemp/docs.php
http://openlibsys.org/
RealTemp is a CPU temperature monitoring application that uses the winring0.dll library distributed by openlibsys.org. It doesn't look like the library will run without actual Intel or AMD processors to act on.
Again, VMWare might be passing through these registers but I doubt it. What software are you trying to run?
I am aware of windows kernel but new to linux kernel. I just need to know how its done in linux, i.e. the program development.
You can check there (free-electrons.com), it's a good informations source for kernel developement. (specialized in embedded linux, but most of the docs are available for standard development)
You have also the classical Linux Devices Drivers, which is very complete and detailled.
And last but not least, the Linux kernel documentation.
Linux does not have a stable kernel API. This is by design, so you should generally avoid writing kernel code if you can; it is unlikely to remain source-compatible indefinitely, and will definitely NOT be binary-compatible, even between minor releases.
This is less-or-more true for vendor kernels; Redhat etc DO maintain source & binary kernel compatibility between major revisions.
More work is gradually being done in the kernel to reduce the amount of kernel-code required to carry out various tasks, such as driver development (for example, USB drivers can typically be done in userspace with libusb), filesystem development (FUSE) and network filtering (NFQUEUE). However, there are still some cases where you need to; in particular, block devices still need to be in the kernel to be able to be usefully used for boot devices and swap.
What is kernel's KMS(kernel mode setting) API?
ModeSetting does refer to the graphic stack. It is the process of setting up the clocks and scanout buffers, initialize the chips, lighting up the displays and so on.
The kernel subsystem responsible for this is the DRM subsystem. It has a userspace library that is developed in lock-step with the kernel part and allows i.e. Xorg access to the userland facing part of the interface (normally called ABI). The hardware-facing side of the kernel interface is usually referred to as the API.
Specifically you can use the 'xrandr' binary to instruct XOrg via the randr-protocol to instruct the kernel to change the mode. That binary is installed alongside the X server and also gives you some information about the graphics card and the current mode.
The DRM ModeSetting API is IOCTL based and the following site gives an technical overview: http://dri.freedesktop.org/wiki/DrmModesetting
Also the documentation in the current linux-3.7 releases is quite improved. To check that out, you have to fetch the latest kernel sources, and then, in the kernel sourcetree do
$ make htmldocs
and then look at the generated file Documentation/DocBook/drm/index.html .
Hth
Mode setting is usually related to Graphics setup.
A reference article dated April 19, 2008 notes,
kernel mode-setting involves moving the mode-setting code for video adapters from the user-space X server drivers into the Linux kernel. This may seem like an uninteresting topic for end-users, but having the mode-setting done in the kernel allows for a cleaner and richer boot process, improved suspend and resume support, and more reliable VT switching (along with other advantages). Kernel mode-setting isn't yet in the mainline Linux kernel nor is the API for it frozen, but Fedora 9 shipping next month will be the first major distribution carrying this initial support. In this article we're looking more closely at kernel mode-setting with the Intel X.Org driver as well as showing videos of kernel-based mode-setting in action.
Here is a Fedora wiki KernelModesetting page.