Assuming we're talking about x86/x64: Once paging is enabled - this is done by setting the PG bit (bit 31) of CR0, and this happens very early in the boot - all addresses asserted by the executing code, including the addresses OF the code, are interpreted as virtual addresses.
It is not so much that the processor produces virtual addresses in some way different from producing physical ones, it is just that once that bit is turned on, that enables address translation, and from then on every address that comes out of the code is interpreted by the MMU as a virtual address.
User vs. kernel mode doesn't matter, process vs. system context doesn't matter. All addresses are virtual and are translated via the page tables to RAM (physical) addresses. And a page table entry might have its "page present" bit clear, meaning that the reference would incur a page fault.
There is just one sort-of exception that comes immediately to mind: The CR3 register contains the physical address of the top-level page table (the PML4 table in x64). And of course code that manipulates page table entries, etc., must deal with physical addresses. But, these physical addresses are never actually asserted, used as the target of a fetch or store operation, by running code; they are merely calculated, stored, and retrieved.
There is no way to "escape" this and temporarily assert physical addresses. (If you did turn off the PG bit, the next instruction in your instruction stream would not be executed, unless its virtual and physical addresses just happened to be the same! Similar concerns for the stack pointer and every other saved address your code needs...)
If you need to reference a particular physical address, you allocate a previously unused virtual page and set up the corresponding page table entry to specify the physical page number you want. This is how driver code accesses I/O "register" space while virtual addressing is enabled.