Is this sudden invasion of new posters a sign of osdevelopers, generated by AI?
Hopefully, they will be less plastic, than AI generated girls.
An address space owner is a process, it owns it in its entirety, as a concept, with that part, where the kernel resides incl. I like this view, it's simple and clear. The kernel, thus, is a kind of library, loaded into the process AS. There is a public part of the kernel, which is mapped the same for all processes and private one, with per process mapping. The former is for objects that should point to the same phisically content from any thread (every thread belongs to some process and runs in the process' address space), say kernel code, the latter is for things, that should point to the private parts of the process when it runs priveleged, kernel code. I believe, threads' kernel mode stacks are from this category. Or maps themselves*. For the public part some address A in the "virtual" AS points to the same thing both class wise and instance wise, for the private, - normally same only class wise. So, address A for process P1 would be say stack location at system/physical address S1 and for process P2, it also would be a stack location, but the mapping would be to the physical address S2.
* - for every address space, every process, that is, you would need to build page tables for the entire mapping, both user mode accessible and kernel mode. It can't reside in the user mode accessible part, otherwise it would be a huge security risk. On the other hand, the mapping would consume a significant amount of address range, so it wouldn't be wise to make it into the public part, allocating some part of it for every new process, it's the way for denial of service. apparently, that you need to introduce a range in your layout, classified to be used as a container for maps. It would start at the same address for every AS, but will point to different physical locations, each for every process. hope, you get the idea from my messy explanation.