On hardware supporting the fsgsbase feature, 64bit PV guests can set and clear the applicable control bit in its virtualised %cr4, but the feature remains fully active in hardware. Therefore, the associated instructions are actually usable. Linux, which does not currently support this feature, has various optimisations in its context switch path which justifiably assume that userspace can't actually make changes without a system call. Xen's behaviour of having this feature active behind the guest kernel's back undermines the correctness of any context switch logic which depends on the feature being disabled. Userspace can therefore corrupt fsbase or gsbase (commonly used for Thread Local Storage) in the next thread to be scheduled on the current vcpu.
References: https://seclists.org/oss-sec/2019/q1/164
Created xen tracking bugs for this issue: Affects: fedora-all [bug 1685577]