Re: exception handling in kernel code
On Tue, 22 Aug 2006 12:36:40 +0200 Attilio Rao [EMAIL PROTECTED] mentioned: Mmm, I think that a better approach would be refering to different MSRs tables for pentium, p6 and Pentium 4 (if I remind correctly they are which show differences). It is more extensible, portable and possibly cleaner (I.E: you could port automatically to openbsd/netbsd, adding new table and make minimum modifies, etc.) I don't agree. We have a bunch of i386-compatible cpu vendors (Winbond, Cyrix, Intel, AMD, etc) and several models for each of them. Each have specific MSR set available. Thus, in that case we should add a table per each cpu model into the code, that seems to me bogus, since it will grow codesize dramatically and will not save from #GP faults in case of 'degenerate' cpu models. That is, it requires fault handlers anyway. Current implementation works well providing MSR access to userland and it garantee no kernel faults at all. It reports MSR reading errors to userland too. Furthermore, porting to other BSD isn't a goal. -- Stanislav Sedov MBSD labs, Inc. [EMAIL PROTECTED] Россия, Москва http://mbsd.msk.ru If the facts don't fit the theory, change the facts. -- A. Einstein PGP fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 signature.asc Description: PGP signature
Re: exception handling in kernel code
2006/8/14, Stanislav Sedov [EMAIL PROTECTED]: On Mon, 14 Aug 2006 09:32:57 -0400 John Baldwin [EMAIL PROTECTED] mentioned: You can make use of pcb_onfault to recover from a page fault, but that's about it. Kernel code is expected to not generate exceptions. :) Thanks a lot! I'll try it. To clarify: I've implemented driver to allow user-level code to read MSRs (Model specific registers) (like linux's /dev/cpu/msr). It's required for some programs like x86info. As long as not all MSRs documented and reading/writing unexistent MSR leads to GP fault, I need to recover in that case. Mmm, I think that a better approach would be refering to different MSRs tables for pentium, p6 and Pentium 4 (if I remind correctly they are which show differences). It is more extensible, portable and possibly cleaner (I.E: you could port automatically to openbsd/netbsd, adding new table and make minimum modifies, etc.) You could find differences in the tables in the Intel manual (vol. 3) and for undocumented MSRs (if I remind correctly) you could find informations here: http://www.x86.org/articles/p5msr/pentiummsrs.htm or similar sites. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: exception handling in kernel code
Ok, I've finally done it. The module itself is located at http://mbsd.msk.ru/dist/msr-0.1.tar.bz2 port - http://mbsd.msk.ru/dist/devmsr.tar.bz2 Port PR - ports/102158 Now we can use x86info to get all available information about cpu. I could not test amd64 and smp version, so any information (success/failure) will be very apprecated. Thank to all for help. -- Stanislav Sedov MBSD labs, Inc. [EMAIL PROTECTED] Россия, Москва http://mbsd.msk.ru If the facts don't fit the theory, change the facts. -- A. Einstein PGP fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 signature.asc Description: PGP signature
Re: exception handling in kernel code
On Mon, Aug 14, 2006 at 11:12:23PM +0600, Stanislav Sedov wrote: On Mon, 14 Aug 2006 11:15:22 -0700 John-Mark Gurney [EMAIL PROTECTED] mentioned: You should make a MD API for reading these out (if one doesn't already exist) that handle the faulting for you, and then have your driver hook into this api... I had to do something similar for accessing PCI config registers that don't exist and cause a fault... Do you know some examples to look at? The problem is that i can't make modifications in trap.c or anywhere else in src tree as such driver isn't likely to become a part of FreeBSD kernel. Hmm, I think that jhb@ somewhat misguided your. For kernel-mode faults on i386, GPF and Segment not Present faults both results in calling of pcb_onfault handler. This is true for both STABLE and CURRENT. And this is true for amd64 as well. Look at the code at the arch/arch/trap.c, for arch in i386, amd64. pgp0S7hcaY8fS.pgp Description: PGP signature
Re: exception handling in kernel code
On Tuesday 15 August 2006 03:43, Kostik Belousov wrote: On Mon, Aug 14, 2006 at 11:12:23PM +0600, Stanislav Sedov wrote: On Mon, 14 Aug 2006 11:15:22 -0700 John-Mark Gurney [EMAIL PROTECTED] mentioned: You should make a MD API for reading these out (if one doesn't already exist) that handle the faulting for you, and then have your driver hook into this api... I had to do something similar for accessing PCI config registers that don't exist and cause a fault... Do you know some examples to look at? The problem is that i can't make modifications in trap.c or anywhere else in src tree as such driver isn't likely to become a part of FreeBSD kernel. Hmm, I think that jhb@ somewhat misguided your. For kernel-mode faults on i386, GPF and Segment not Present faults both results in calling of pcb_onfault handler. This is true for both STABLE and CURRENT. And this is true for amd64 as well. Look at the code at the arch/arch/trap.c, for arch in i386, amd64. Hmm, well that's handy then. Learn something new everyday. :) You can see how to use pcb_onfault in some of the routines in i386/i386/support.s. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: exception handling in kernel code
On Monday 14 August 2006 02:46, Stanislav Sedov wrote: Hi! I'm trying to write kernel code where exceptions are unavoidable. To clarify , I need to recover after GP (general protection) exception on i386 cpu and return an error in that case. Unfortunately, looking in trap.c kernel code I can't find any exception handling mechanism except inserting hooks into trap.c. So, the question is: how can one recover after exception in kernel code? AFAIK, linux build special exception table from various __ex_table sections to allow placing recover code into .fixup section. Does any such mechanism exists in freebsd? Thanks! You can make use of pcb_onfault to recover from a page fault, but that's about it. Kernel code is expected to not generate exceptions. :) -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: exception handling in kernel code
On Mon, 14 Aug 2006 09:32:57 -0400 John Baldwin [EMAIL PROTECTED] mentioned: You can make use of pcb_onfault to recover from a page fault, but that's about it. Kernel code is expected to not generate exceptions. :) Thanks a lot! I'll try it. To clarify: I've implemented driver to allow user-level code to read MSRs (Model specific registers) (like linux's /dev/cpu/msr). It's required for some programs like x86info. As long as not all MSRs documented and reading/writing unexistent MSR leads to GP fault, I need to recover in that case. -- Stanislav Sedov MBSD labs, Inc. [EMAIL PROTECTED] Россия, Москва http://mbsd.msk.ru If the facts don't fit the theory, change the facts. -- A. Einstein PGP fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 signature.asc Description: PGP signature
Re: exception handling in kernel code
Stanislav Sedov wrote this message on Mon, Aug 14, 2006 at 19:47 +0600: I've implemented driver to allow user-level code to read MSRs (Model specific registers) (like linux's /dev/cpu/msr). It's required for some programs like x86info. As long as not all MSRs documented and reading/writing unexistent MSR leads to GP fault, I need to recover in that case. You should make a MD API for reading these out (if one doesn't already exist) that handle the faulting for you, and then have your driver hook into this api... I had to do something similar for accessing PCI config registers that don't exist and cause a fault... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: exception handling in kernel code
On Monday 14 August 2006 09:47, Stanislav Sedov wrote: On Mon, 14 Aug 2006 09:32:57 -0400 John Baldwin [EMAIL PROTECTED] mentioned: You can make use of pcb_onfault to recover from a page fault, but that's about it. Kernel code is expected to not generate exceptions. :) Thanks a lot! I'll try it. To clarify: I've implemented driver to allow user-level code to read MSRs (Model specific registers) (like linux's /dev/cpu/msr). It's required for some programs like x86info. As long as not all MSRs documented and reading/writing unexistent MSR leads to GP fault, I need to recover in that case. Hmm pcb_onfault won't help with this (it does PF#, not GP#). You will have to hack trap() to provide some sort of fallback for your case. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: exception handling in kernel code
On Mon, 14 Aug 2006 11:15:22 -0700 John-Mark Gurney [EMAIL PROTECTED] mentioned: You should make a MD API for reading these out (if one doesn't already exist) that handle the faulting for you, and then have your driver hook into this api... I had to do something similar for accessing PCI config registers that don't exist and cause a fault... Do you know some examples to look at? The problem is that i can't make modifications in trap.c or anywhere else in src tree as such driver isn't likely to become a part of FreeBSD kernel. Thanks! -- Stanislav Sedov MBSD labs, Inc. [EMAIL PROTECTED] Россия, Москва http://mbsd.msk.ru If the facts don't fit the theory, change the facts. -- A. Einstein PGP fingerprint: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 signature.asc Description: PGP signature
Re: exception handling in kernel code
Stanislav Sedov wrote this message on Mon, Aug 14, 2006 at 23:12 +0600: On Mon, 14 Aug 2006 11:15:22 -0700 John-Mark Gurney [EMAIL PROTECTED] mentioned: You should make a MD API for reading these out (if one doesn't already exist) that handle the faulting for you, and then have your driver hook into this api... I had to do something similar for accessing PCI config registers that don't exist and cause a fault... Do you know some examples to look at? The problem is that i can't make modifications in trap.c or anywhere else in src tree as such driver isn't likely to become a part of FreeBSD kernel. That will be very difficult to do then The work I did for accessing PCI config registers had to be merged into the tree... Maybe introducing a method for adding a MD callback to the trap handler for other modules that need this?Short of modifing the function in real time to point to your code, I don't have any suggestions... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
