I had this same question and thought I'd share what I found - it varies between computer architectures.
ARM processors - the support for two different tables is available.
In short, there are 2 Page-Table Base Registers and another Control Register for splitting the address space. One of the PTBR can be used for the kernel while the other can be used for whichever user process is running. ARM calls these registers: TTBR1/TTBR2 (Translation Table Base Register) and TTBCR (Translation Table Base Control Register)
x86 processors - the support (in hardware) is not available. x86 processors only have the CR3 register which holds the current page table address.
However, the duplication of the kernel page table only really exists for each process in the very first level of the page table directory. All the virtual page table entries for the kernel portion of one virtual address (in the top-level page table) will point to the same level 2 page tables as the top-level page table for other processes.
Meaning: only half of the top-level page table (which is designed to be at most a single page frame) is actually duplicated.
This is also related to the Meltdown security vulnerability published in 2018. Because the kernel page table was mapped into each virtual address space, and thus appeared in each process's page table, a race condition allowed user space code to read any memory accessible from that process's page table (i.e. kernel memory). The fix was to implement Kernel page-table isolation:
KPTI fixes these leaks by separating user-space and kernel-space page tables entirely. One set of page tables includes both kernel-space and user-space addresses same as before, but it is only used when the system is running in kernel mode. The second set of page tables for use in user mode contains a copy of user-space and a minimal set of kernel-space mappings that provides the information needed to enter or exit system calls, interrupts and exceptions.