In Xen code ./xen/include/asm-x86/config.h, I saw the memory layout code is:
/*
137 * Meng: Xen-definitive guide: P81
138 * Memory layout:
139 * 0x0000000000000000 - 0x00007fffffffffff [128TB, 2^47 bytes, PML4:0-255]
140 * Guest-defined use (see below for compatibility mode guests).
141 * 0x0000800000000000 - 0xffff7fffffffffff [16EB]
142 * Inaccessible: current arch only supports 48-bit sign-extended VAs.
143 * 0xffff800000000000 - 0xffff803fffffffff [256GB, 2^38 bytes, PML4:256]
I'm very confused at what the PML4 is short for. I did know that the x86_64 only uses 48 bits out of 64bits. But what is the PML4 short for? It may help me understand the number behind it.
Thanks!
It's short for Page Map Level 4. A bit of explanation can be found here. Basically it's just the way AMD decided to label page tables.
Related
I'm almost getting the handle of GHC cost centres.... it is an awesome idea, and you can actually fix memory leaks with their profiling tools. But my problem is that the information I'm getting in the .hp profiling is too truncated:
(1319)GHC.Conc.Signal.CAF 640
(1300)GHC.Event.Thread.CAF 560
(2679)hGetReplies/connect/c... 112
(2597)insideConfig/CAF:lvl2... 32
(1311)GHC.IO.Handle.FD.CAF 656
(2566)setLoggerLevels/confi... 208
(2571)configureLoggingToCon... 120
(2727)reply/Database.Redis.... 32
How do I know for example what is the full cost centre stack in (2566) or (2559)? Is there a tool for that or a command-line option?
Pass +RTS -L100 to your the program when you run it with profiling, and change 100 to whatever number of characters you want to see of your cost centres.
The documentation can be found in the GHC user guide, section “RTS options for heap profiling”.
How does the processor differentiate between these two instructions?
81 /2 iw - Add with carry imm16 to r/m16.
81 /2 id - Add with carry imm32 to r/m32.
The only thing different I can see in the instruction is the size of the immediate value and that isn't enough, right? I mean if the immediate is two bytes an instruction could be right after it and the processor wouldn't know if it was 4 bytes of immediate or 2 bytes and another instruction.
Also am I supposed to add a REX prefix to these for 64-bit operation or just REX.R for the 9-16 registers?
Mode and operand size prefix. In 16 bit mode, 81 /2 will be adc rm16, imm16. In 32 or 64 bit mode, it will be adc rm32, imm32. Unless you add the operand size override, then they switch places.
To make it adc rm64, imm32 (there is no adc rm64, imm64), it needs an REX.W prefix, REX.R is useless since there is no r operand, REX.B/X will just allow you to use extended registers as (part of) the rm operand, and don't change the operand size. So for example adc r8d, 0xDEADBEEF is valid and would be 41 81 D0 EF BE AD DE.
In the last couple of days, I've trying to implement a simple interrupt handler in C. So far so good, I think I've achieved my initial task. My ultimate goal is to inject some faults in the kernel through bit-flipping some CPU registers. After reading this, this and this, I chose IRQ number 10, since it seems it is a free, "open interrupt". My doubt is: how can I know if this is the "best" IRQ to call my interrupt handler? How can I possibly decide on this?
Thanks and all the best,
João
P.S.: As far as I know, there are 16 IRQ lines, but Linux has 256 IDT entries, as clearly stated in /include/asm/irq_vectors.h (please see below). This also seems to be puzzling me.
/*
* Linux IRQ vector layout.
*
* There are 256 IDT entries (per CPU - each entry is 8 bytes) which can
* be defined by Linux. They are used as a jump table by the CPU when a
* given vector is triggered - by a CPU-external, CPU-internal or
* software-triggered event.
*
* Linux sets the kernel code address each entry jumps to early during
* bootup, and never changes them. This is the general layout of the
* IDT entries:
*
* Vectors 0 ... 31 : system traps and exceptions - hardcoded events
* Vectors 32 ... 127 : device interrupts
* Vector 128 : legacy int80 syscall interface
* Vectors 129 ... 237 : device interrupts
* Vectors 238 ... 255 : special interrupts
*
* 64-bit x86 has per CPU IDT tables, 32-bit has one shared IDT table.
*
* This file enumerates the exact layout of them:
*/
The story
I have a C program which generates automatically a list of syscall numbers, as I prefer automated generation from real world reference than hand‑written generated files when, applicable. The target is an Ada package. I've run a test with the classical “Hello world” involving the common write syscall… it failed. I figured the syscall number was wrong: 64 instead of 4.
I generated the list from a C program including <asm-generic/unistd.h>. The platform is 32 bits and no tool‑chain targeting 64 bits platform was ever installed.
Examples definitions from this unistd.h: #define __NR_write 64 (should be 4), #define __NR_read 63 (should be 3), #define __NR_getuid 174 (should be 24), and so on…
I've run a text search in all files in /usr/** for occurrences of __NR_write which would be part of the expected definition, and found no one.
The question
Why this header specify weird syscall numbers? Why is the expected definitions found nowhere? Is this a new ABI?
Note: the platform is Ubuntu 12.04, 32 bits.
Update
I figured something running this command:
find /usr/include/ -name "unistd*" -exec nano '{}' \;
It shows the header /usr/include/i386-linux-gnu/asm/unistd_32.h contains the good numbers, and that header is included from /usr/include/i386-linux-gnu/asm/unistd.h, but many of the symbols are not defined when <asm/unistd.h> is included.
Update 2
Not only the numbers differs, but many names too. Ex. __NR_socket vs __NR_socketcall. The start of an explanation may be given in the possible duplicate: arch/x86/include/asm/unistd.h vs. include/asm-generic/unistd.h.
If you start with /usr/include/sys/syscall.h (as indicated in syscall(2)) and repeatedly follow the include directives you arrive at /usr/include/asm/unistd_32.h. Hence I recommend you use this header.
From the source of asm-generic.h:
6 /*
7 * This file contains the system call numbers, based on the
8 * layout of the x86-64 architecture, which embeds the
^^^^^^
9 * pointer to the syscall in the table.
10 *
...
15 */
I'm porting / debugging a device driver (that is used by another kernel module) and facing a dead end because dma_sync_single_for_device() fails with an kernel oops.
I have no clue what that function is supposed to do and googling does not really help, so I probably need to learn more about this stuff in total.
The question is, where to start?
Oh yeah, in case it is relevant, the code is supposed to run on a PowerPC (and the linux is OpenWRT)
EDIT:
On-line resources preferrable (books take a few days to be delivered :)
On-line:
Anatomy of the Linux slab allocator
Understanding the Linux Virtual Memory Manager
Linux Device Drivers, Third Edition
The Linux Kernel Module Programming Guide
Writing device drivers in Linux: A brief tutorial
Books:
Linux Kernel Development (2nd Edition)
Essential Linux Device Drivers ( Only the first 4 - 5 chapters )
Useful Resources:
the Linux Cross Reference ( Searchable Kernel Source for all Kernels )
API changes in the 2.6 kernel series
dma_sync_single_for_device calls dma_sync_single_range_for_cpu a little further up in the file and this is the source documentation ( I assume that even though this is for arm the interface and behavior are the same ):
/**
380 * dma_sync_single_range_for_cpu
381 * #dev: valid struct device pointer, or NULL for ISA and EISA-like devices
382 * #handle: DMA address of buffer
383 * #offset: offset of region to start sync
384 * #size: size of region to sync
385 * #dir: DMA transfer direction (same as passed to dma_map_single)
386 *
387 * Make physical memory consistent for a single streaming mode DMA
388 * translation after a transfer.
389 *
390 * If you perform a dma_map_single() but wish to interrogate the
391 * buffer using the cpu, yet do not wish to teardown the PCI dma
392 * mapping, you must call this function before doing so. At the
393 * next point you give the PCI dma address back to the card, you
394 * must first the perform a dma_sync_for_device, and then the
395 * device again owns the buffer.
396 */
Understanding The Linux Kernel?
The chapters of the Linux Device Drivers book (in the same series as Understanding the Linux Kernel, recommended by #Matthew Flaschen) might be useful.
You can download the indiivudal chapters from the LWN Website. Chapter 16 deals with DMA.