Message ID | 74eb1e77-7445-92fa-25b1-ece1d6699eb9@suse.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | (remaining) XSA-292 follow-up | expand |
On 25/09/2019 16:23, Jan Beulich wrote: > I can't see any technical or performance reason why we should treat > 32-bit PV different from 64-bit PV in this regard. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> There are technical reasons, and a very good perf reason not to... There is no such thing as a user/kernel split for 32bit guests (as TF_kernel_mode remains set unconditionally), and there is no such thing as an XPTI split (32bit code can't attack Xen using meltdown). What you would gain is the perf hit of maintaining unused PCID's worth of mappings (seeing as INVPCID is horribly expensive even on modern CPUs). The only way this might not hurt performance is if it was tied to a PV ABI extension letting 32bit PV guests split their user/kernel mappings and have Xen handle the transition automatically, at which point a user/kernel PCID split in Xen would be better than the guest kernel trying to do KPTI on its own. ~Andrew
--- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -180,7 +180,24 @@ int switch_compat(struct domain *d) d->arch.x87_fip_width = 4; d->arch.pv.xpti = false; - d->arch.pv.pcid = false; + + if ( use_invpcid && cpu_has_pcid ) + switch ( ACCESS_ONCE(opt_pcid) ) + { + case PCID_OFF: + case PCID_XPTI: + d->arch.pv.pcid = false; + break; + + case PCID_ALL: + case PCID_NOXPTI: + d->arch.pv.pcid = true; + break; + + default: + ASSERT_UNREACHABLE(); + break; + } return 0; @@ -324,7 +341,7 @@ int pv_domain_initialise(struct domain * opt_xpti_domu = 2; } - if ( !is_pv_32bit_domain(d) && use_invpcid && cpu_has_pcid ) + if ( use_invpcid && cpu_has_pcid ) switch ( ACCESS_ONCE(opt_pcid) ) { case PCID_OFF: