Messages in this thread | | | From | "Li, Xin3" <> | Subject | RE: [PATCH v4 5/5] x86/gsseg: use the LKGS instruction if available for load_gs_index() | Date | Thu, 20 Oct 2022 06:24:40 +0000 |
| |
> On 20.10.22 07:58, Li, Xin3 wrote: > >> On 19.10.22 19:45, Li, Xin3 wrote: > >>>>> +static inline void __init lkgs_init(void) { #ifdef > >>>>> +CONFIG_PARAVIRT_XXL #ifdef CONFIG_X86_64 > >>>>> + if (cpu_feature_enabled(X86_FEATURE_LKGS)) > >>>>> + pv_ops.cpu.load_gs_index = native_lkgs; > >>>> > >>>> For this to work correctly when running as a Xen PV guest, you need > >>>> to add > >>>> > >>>> setup_clear_cpu_cap(X86_FEATURE_LKGS); > >>>> > >>>> to xen_init_capabilities() in arch/x86/xen/enlighten_pv.c, as > >>>> otherwise the Xen specific .load_gs_index vector will be overwritten. > >>> > >>> Yeah, we definitely should add it to disable LKGS in a Xen PV guest. > >>> > >>> So does it mean that the Xen PV uses a black list during feature detection? > >>> If yes then new features are often required to be masked with an > >>> explicit call to setup_clear_cpu_cap. > >>> > >>> Wouldn't a white list be better? > >>> Then the job is more just on the Xen PV side, and it can selectively > >>> enable a new feature, sometimes with Xen PV specific handling code > added. > >> > >> This is not how it works. Feature detection is generic code, so we'd > >> need to tweak that for switching to a whitelist. > >> > > > > Yes, a Xen PV guest is basically a Linux system. However IIRC, the > > Xen PV CPUID is para-virtualized, so it's Xen hypervisor's > > responsibility to decide features exposed to a Xen PV guest. No? > > In theory you are right, of course. > > OTOH the Xen PV interface has a long and complicated history, and we have to > deal with old hypervisor versions, too. > > >> Additionally most features don't require any Xen PV specific > >> handling. This is needed for some paravirtualized privileged > >> operations only. So switching to a whitelist would add more effort. > >> > > > > LKGS is allowed only in ring 0, thus only Xen hypervisor could use it. > > Right, it would be one of the features where a whitelist would be nice. > > OTOH today only 11 features need special handling in Xen PV guests, while the > rest of more than 300 features doesn't. >
Got to say, nothing is more convincing than strong data. Xin
> > Juergen
| |