On 14/09/2023 7:09 am, Jan Beulich wrote: > On 14.09.2023 08:03, Juergen Gross wrote: >> On 14.09.23 06:47, Xin Li wrote: >>> From: "H. Peter Anvin (Intel)" <hpa@xxxxxxxxx> >>> >>> Any FRED CPU will always have the following features as its baseline: >>> 1) LKGS, load attributes of the GS segment but the base address into >>> the IA32_KERNEL_GS_BASE MSR instead of the GS segment’s descriptor >>> cache. >>> 2) WRMSRNS, non-serializing WRMSR for faster MSR writes. >>> >>> Signed-off-by: H. Peter Anvin (Intel) <hpa@xxxxxxxxx> >>> Tested-by: Shan Kang <shan.kang@xxxxxxxxx> >>> Signed-off-by: Xin Li <xin3.li@xxxxxxxxx> >> In order to avoid having to add paravirt support for FRED I think >> xen_init_capabilities() should gain: >> >> + setup_clear_cpu_cap(X86_FEATURE_FRED); > I don't view it as very likely that Xen would expose FRED to PV guests > (Andrew?), at which point such a precaution may not be necessary. PV guests are never going to see FRED (or LKGS for that matter) because it advertises too much stuff which simply traps because the kernel is in CPL3. That said, the 64bit PV ABI is a whole lot closer to FRED than it is to IDT delivery. (Almost as if we decided 15 years ago that giving the PV guest kernel a good stack and GSbase was the right thing to do...) In some copious free time, I think we ought to provide a minorly-paravirt FRED to PV guests because there are still some improvements available as low hanging fruit. My plan was to have a PV hypervisor leaf advertising paravirt versions of hardware features, so a guest could see "I don't have architectural FRED, but I do have paravirt-FRED which is as similar as we can reasonably make it". The same goes for a whole bunch of other features. ~Andrew
