Got the solution from Tonux599 on github:
I added
GRUB_CMDLINE_XEN_DEFAULT="$GRUB_CMDLINE_XEN_DEFAULT spec-ctrl=ibpb-entry=no-pv"
to the end of /etc/default/grub and updated with grub2-mkconfig -o /boot/grub2/grub.cfg and then reboot. Then updated Xen from 4.17.3-4 to 4.17.4-2 and other xen-hvm-stubdom* packages from 4.2.9 to 4.2.12, rebooted again, and now all my Qubes boot with latest Xen.
NOTE This is opening up a big security hole as marmarek explains:
So, I’m afraid there is not much hope for this old-ish system… The only way to make the system kinda-usable has a tradeoff with security here, by disabling the mitigation for PV domains (which should mean just stubdomains, make sure you don’t have any really untrusted PV qubes) with
spec-ctrl=ibpb-entry=no-pv. It does mean that stubdomain will be able to mount the attack, potentially leaking memory of any other VM (so isolation of sys-net/sys-usb and any other HVM becomes weaker). If that is not an acceptable risk, blame AMD for making buggy CPU, and replace with something newer…
And the Qubes team has declined to attempt to address this bug in the future.