If the problem is row-hammer style attacks on the TLB that let you map userspace writable pages into the kernel address space then any kernel entries remaining in the TLB when userspace is running are going to be a security hole. The problem won’t be a process writing to the kernel entry (that would be forbidden by existing code / hardware) but a process updating it’s own TLB entries in ways that corrupt adjacent kernel ones. PCID doesn't help you here - indeed it hurts, because it means there are more TLB entries from the hypervisor or other virtual machines remaining in the TLB to be corrupted!
(Unless I have entirely the wrong end of the stick about this?)
I took OP to mean "rowhammer style" in the sense of a chip operation having unexpected physical effects on nearby transistors; not an attack literally identical to rowhammer.
No, the attack is simply a timing side-channel infoleak attack made possible by the TLB speeding up page fault handling to locate kernel structures mapped into the process' address space.
As far as I know PCID hidden entries in the TLB result in the same page fault as non-existent entries, so the page fault handling becomes constant timed.
(Unless I have entirely the wrong end of the stick about this?)