October 2012 - kernelnewbies@kernelnewbies.org

IO operations and MOV to/from CR3
by Onkar N Mahajan Oct. 27, 2012

Oct. 27, 2012

Hi List, I prepared some notes for CR3 involvement in different IO operations, so here are the notes - memory-mapped IO & DMA IO: - Each such operation involves MOV to/from CR3 : - MOV from CR3 causes "Unconditional VM exit" - MOV to CR3 causes "Conditional VM exit" : - The MOV to CR3 instruction causes a VM exit unless the value of its source operand is equal to one of the CR3-target values specified in the VMCS (controlled by Hypervisor). This feature allows a guest kernel to change the CR3 value without causing a world switch to the hypervisor, provided that the value written into the CR3 register was previously specified by the hypervisor in the CR3-Target registers. An execution of MOV to CR3 in VMX non-root operation does not cause a VM exit if its source operand matches one of these previsously stored values. If the CR3-target count is n, only the first n (0 .. (n-1)) CR3-target values do not cause VM-Exit. nth value causes VM-Exit. if n=0 , MOV to CR3 always causes VM-Exit. Please comment if I understood something incorrectly here. Regards, K Arun Kumar

1 0

IO operations and MOV to/from CR3
by K Arun Kumar Oct. 27, 2012

Oct. 27, 2012

Hi List, I prepared some notes for CR3 involvement in different IO operations, so here are the notes - memory-mapped IO & DMA IO: - Each such operation involves MOV to/from CR3 : - MOV from CR3 causes "Unconditional VM exit" - MOV to CR3 causes "Conditional VM exit" : - The MOV to CR3 instruction causes a VM exit unless the value of its source operand is equal to one of the CR3-target values specified in the VMCS (controlled by Hypervisor). This feature allows a guest kernel to change the CR3 value without causing a world switch to the hypervisor, provided that the value written into the CR3 register was previously specified by the hypervisor in the CR3-Target registers. An execution of MOV to CR3 in VMX non-root operation does not cause a VM exit if its source operand matches one of these previsously stored values. If the CR3-target count is n, only the first n (0 .. (n-1)) CR3-target values do not cause VM-Exit. nth value causes VM-Exit. if n=0 , MOV to CR3 always causes VM-Exit. Please comment if I understood something incorrectly here. Regards, K Arun Kumar

1 0

wait, two more observations/questions about uapi ...
by Robert P. J. Day Oct. 26, 2012

Oct. 26, 2012

sorry for the fixation, i just want to really understand what's happening here. first, here's an example of a header file that seems odd -- include/linux/xz.h: ... snip ... #ifdef __KERNEL__ # include <linux/stddef.h> # include <linux/types.h> #else # include <stddef.h> # include <stdint.h> #endif ... snip ... that certainly seems like a candidate for uapi refactoring, yet it doesn't appear in any uapi/ directory, and it isn't collected for userspace export by "make headers_install". so what's happening here? also, i'm assuming that references to all of the new uapi/ directories will be eventually added to the MAINTAINERS file? ok, i'll shut up now. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

looking to clarify the uapi/ refactoring, and some oddities
by Robert P. J. Day Oct. 26, 2012

Oct. 26, 2012

after reading the overview of the uapi refactoring, let me summarize what i *think* is going on, point out some oddities, and ask some questions. (good writeup is here: http://lwn.net/Articles/507794/) first, a question -- is the uapi reorg meant to completely obsolete "make headers_install"? with userspace API content now broken off into its own uapi/ subdirectories, does this not make that target entirely superfluous? or is there something else happening here? i can see the Kbuild infrastructure is still there but, theoretically, why would it be necessary anymore given the refactoring? next, as i read it, all of the kernel header file content can be broken into exactly three (reasonable) categories: * kernel-only * shared between kernel and userspace * userspace only so far, so good, so let's look at each category. header files that contain kernel-only content should now reside in a "normal" include directory like include/linux and, as i read it, they shouldn't need any "__KERNEL__" preprocessor checks anymore, but there's still a lot of that: $ cd include/linux $ grep -r "#if.*__KERNEL__" * | wc -l 101 $ admittedly, those checks don't *hurt*, but is the plan that all of that eventually gets cleared out? in the other category/categories, we have all userspace content that should now be moved under some uapi/ directory. now those files *might* have checks of the form: #ifndef __KERNEL__ to reflect userspace-only content, that's fine. what they *shouldn't* have is: #ifdef __KERNEL__ since that reflects kernel space content and shouldn't be in a uapi/ directory, correct? unless, as i see it, it's a test that affects an actual structure definition, then there's really no way around it, like this in acct.h: #ifdef __KERNEL__ __u32 ac_etime; /* Elapsed Time */ #else float ac_etime; /* Elapsed Time */ #endif and i mentioned the strangeness with coda.h yesterday as well; here's the regular file: #if defined(__linux__) typedef unsigned long long u_quad_t; #else <-- that's a bit strange #endif #include <uapi/linux/coda.h> and here's the uapi version: ... snip ... #ifdef KERNEL <--- why is this here? typedef unsigned long u_long; typedef unsigned int u_int; typedef unsigned short u_short; typedef u_long ino_t; typedef u_long dev_t; typedef void * caddr_t; ... snip ... anyway, i'm sure this all works fine, but it certainly seems that there's a lot of leftover cruft that could still be deleted. is that still part of the plan? rday p.s. amusingly, what's still left in some of the uapi/ headers are *comments* referring to kernel checks that obviously don't exist anymore. eg., in include/uapi/linux/virtio_config.h: /* This header, excluding the #ifdef __KERNEL__ part, is BSD licensed so * anyone can use the definitions to implement compatible drivers/servers. i might throw together some cheap patches to get rid of that stuff. it offends my pedantic sensibilities. :-) -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

puzzled by a couple things related to "uapi"
by Robert P. J. Day Oct. 25, 2012

Oct. 25, 2012

looking at the "uapi" reorganization in the kernel source for the first time, and a couple things confuse me. i see the principle -- collect all the userspace API content in one place, in this case include/uapi/. this obviously(?) is supposed to represent a newer way to represent what you got formerly with $ make headers_install that is, header files identified in Kbuild files, cleansed of any kernel-only content, then placed under usr/include in the source tree. is that about right -- is that what it's supposed to represent? so at a *guess*, it would seem that, if a header file that should be part of uapi didn't need any cleaning, it could go straight into include/uapi untouched. on the other hand, if a header file *did* have some kernel-only content, i would have *thought* that there would be two versions of that header file: a) the one with the kernel-only content still under include/linux, which would turn around and, in some way, include ... b) the common content file under include/uapi does that make sense? because i took a quick look and here's an example i don't understand. there's include/linux/coda.h, with the contents: #if defined(__linux__) typedef unsigned long long u_quad_t; #else #endif #include <uapi/linux/coda.h> #endif ok, so far, so good. but then there's this in include/uapi/linux/coda.h: ... snip ... #ifdef KERNEL <--- ????? typedef unsigned long u_long; typedef unsigned int u_int; typedef unsigned short u_short; typedef u_long ino_t; typedef u_long dev_t; typedef void * caddr_t; ... snip ... why is there still kernel-only content in the uapi/ directory? maybe i just don't understand the rationale for what's going on here. also, does all of this make the command: $ make headers_install obsolete? because it's still there, doing *something*. is there a writeup on this that would clarify how this was designed? thanks. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

2 3

having trouble getting device from kobject
by Christopher Harvey Oct. 25, 2012

Oct. 25, 2012

I added an entry to a sysfs device (drivers/mtd/nand/omap2.c) like this: static int __devinit omap_nand_probe(struct platform_device *pdev) { ... ... ret = sysfs_create_group(&pdev->dev.kobj, &ef_group); if (ret) { err = -ENOMEM; goto out_free_info; } ... ... } that works, I get the following files: /sys/devices/platform/omap2-nand.0/0xEF/set /sys/devices/platform/omap2-nand.0/0xEF/unset (I added the 0xEF directory and the set and unset files) then in the store function of one of the attributes I do this, in an attempt to get the original pdev back: static ssize_t EF_set_store(struct kobject *kobj, struct kobj_attribute *attr, const char *buf, size_t count) { struct kobject *nand_kobj = kobj->parent; struct device *dev = container_of(nand_kobj, struct device, kobj); struct platform_device *pdev = container_of(dev, struct platform_device, dev); printk(KERN_ALERT "pdev is 0x%x\n", (unsigned int)pdev); return count; } but I'm not getting the same address back. Not sure why. thanks, Chris

1 0

some janitorial work -- fixing kernel-doc content
by Robert P. J. Day Oct. 25, 2012

Oct. 25, 2012

if some folks want some janitorial work for the fun of it, consider cleaning up some of the kernel-doc content scattered throughout the source files. if you don't know what that is, you can generate manuals from the embedded kernel-doc content with variations of: $ make htmldocs $ make pdfdocs and so on -- the resulting docs will show up under Documentation/DocBook/. unsurprisingly, the kernel-doc content sometimes lags behind the code, so feel free to generate the docs, check out the warnings and submit patches to clean it up. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================

1 0

Programmer's manual for 82865GV graphics controller
by Prabhu nath Oct. 25, 2012

Oct. 25, 2012

Dear All, I just want to dirty my hands on the display driver. I am just looking out for the programmer's manual for the "Intel 82865GV graphics controller". I got one but it is of little help. Request to send me one complete programmer's manual. Thanks, Prabhu

1 0

set_super_anon in fs/super.c
by Abhijit Chandrakant Pawar Oct. 25, 2012

Oct. 25, 2012

I am working on the layered file systems. I came across a function called set_super_anon. This is a callback to the sget function to compare the superblock . This function accepts two parameters. first is superblock * and second is void *. If you look at the definition of this function, the void* is never used. Many filesystem uses this function when they are mounting the superblock. Some pass NULL and some pass actual data.I have looked till 2.6.31 but there isnt any trace of the usage of second parameter. If it is never used then why its added to the function param list? Is there any historical reason during the older kernel days? Regards, Abhijit Pawar

3 5

Chekpatch does not warn about some quoted string split across lines
by Anmol Sarma Oct. 24, 2012

Oct. 24, 2012

I've noticed that that some quoted string split across lines are not reported by checkpatch.pl. For example, running it on /drivers/staging/android/binder.c does not warn of multi-line strings at lines 512, 544, 776, 804 and several others. Does anyone know why this is happening? Thanks!

2 1