On 20.03.23 14:17, Jan Beulich wrote:
On 20.03.2023 14:02, Juergen Gross wrote:On 20.03.23 11:19, Jan Beulich wrote:On 17.03.2023 14:56, Juergen Gross wrote:+void __init xen_pv_fix_mitigations(void) +{ + if (!xen_vm_assist_ibpb(true)) + setup_clear_cpu_cap(X86_FEATURE_ENTRY_IBPB);... using both setup_clear_cpu_cap() (here) and setup_force_cpu_cap() (in retbleed_select_mitigation() won't work: The latter wins, due to how apply_forced_caps() works.Oh, right. Just a wild guess of mine: probably the x86 maintainers would still prefer a single Xen hook plus something like a setup_unforce_cpu_cap() addition.If so, I'm not willing to make such a patch. That's clearly more fragile than the approach chosen. I guess once I've made the one adjustment you have pointed out, I'll resubmit otherwise unchanged and include x86 folks. We'll see what the responses are going to be, if any at all.
Fine with me.
But of course calling both functions for the same feature is bogus anyway. In fact I think it is for a good reason that in Xen we log a message in such an event.Depends. For Xen we do so in the kernel for multiple features, see xen_init_capabilities().I don't see anything there which looks like it might be both "force"d and "clear"ed in a single session.
Oh, I misunderstood you then. Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
