As Mat wrote, this is probably unreasonably scoped. However, I'll try to devote as much attention to the sum of the questions as I would to one reasonably scoped question, in the hopes that this will help you to begin researching.
1 What is the difference between "preemption" and "context switch" ?
Preemption is the act of interrupting a process without its involvement. In this context, that probably means a timer interrupt will fire. The word comes from a legal concept of preemption: the act or right of claiming or purchasing before or in preference to others. For your purposes, that means that when the timer interrupt fires, that the interrupt service routine (ISR) has preference over the code which was previously running. This doesn't necessarily need to involve a kernel at all; you can have code running in any ISR which will run preemptively.
A context switch is what happens when the OS code (running preemptively) alters the state of the processor (the registers, mode, and stack) between one process or thread's context and another. The state of the processor may be at a certain line of code in a one thread. It will have temporary data in registers, a stack pointer at a certain region of memory, and other state information. A preemptive OS can store this state (either to static memory or onto the processes' stack) and load the state of a previous process. This is known as a context switch.
2 What are the key differences between a preemptive and nonpreemptive kernel ? What all work is required from a programmer to make the kernel preemptive ?
In a preemptive kernel, an interrupt can fire in between any two assembly instructions (known as 'sequence points'). In a non-preemptive kernel, the running process must call a yield() function to allow the other threads to run. Preemptive kernels are more complex, but provide a better illusion of concurrency. Non-premptive kernels can be done very simply with setjmp.h, but each thread must regularly call yield() or the other threads will not run.
When a function like yield() is called, the state of the processor is stored automatically. When you want to make your OS preemptive, you must store this information manually.
3 How to create and work with user mode ?
ARM docs say that in user mode, any instruction switching to a privileged mode will be treated as undefined instruction.
Correct. However, they also say that any interrupt will run in privileged mode automatically. On an ARM system, you can use the svc instruction to generate a software interrupt. The SVC code (part of your OS) will then be able to run in privileged mode.
4 If so, the only way for a userspace program to use kernel code is syscalls ?
Correct. At least, this is the only safe or correct way.
5 How does a kernel respond or interact with userspace then ?
On ARM, the SVC instruction can get an 8-bit value. This can be used to generate 256 syscalls such as yield, enable interrupts, disable interrupts, or whatever you need. You may also choose to create a shared memory or message passing interaction mechanism if you need that.
6 Does that mean the only kernel thread after booting (in a simple system) would be the idle thread ?
That depends entirely on how you design your system. It's probably simpler if you choose to start your kernel only after all your threads have been created - that way you don't need to worry about dynamically allocating threads. Or, you can start with the idle thread and add other threads later (through a remote shell? I think you'd want at least one user thread running consistently...)
7 If the Page where kernel code and data resides is unmapped when switching to a user process, then on a syscall or interrupt, how does the kernel code execute without being mapped in the virtual address space ?
Just as kernel mode code runs in privileged mode even if the code was previously executing in user mode, so will kernel mode code run from the main stack pointer (MSP) even if the process code was using a different address space.
8 Does a 'preemptible kernel' only mean that the kernel was designed in a way that it would be safe to have context switch during execution of kernel code ? or does it require more work to be done if any ?
I think that means that the kernel can preempt the user code, not that the kernel itself can be preempted. It would be difficult and unusual for anything to interrupt the kernel. That would require more work, and I'm struggling to see why you'd want it.
