[Bug] VM Failing to start on XSTATE check

[andrewla]

Describe the bug

On trying to start a VM, we get this error from Firecracker (v1.13.1):

RunWithApiError error: 
  Failed to build MicroVM from Json:
  Could not Start MicroVM from one single json:
  Kvm error:
    Architecture specific error:
      Failed to request permission for dynamic XSTATE features:
        Failed to request permission for XSTATE feature (18):
          Invalid argument (os error 22)
Error: RunWithApi(BuildFromJson(StartMicroVM(Kvm(ArchError(XstateFeatures(RequestFeaturePermission(18, Os { code: 22, kind: InvalidInput, message: "Invalid argument" })))))))

To Reproduce

It appears that this happens on older kernels (pre-5.16) running on CPUs that support AMX. The supported flags apparently returns TILE_DATA, but that flag is greater than XFEATURE_MAX (https://github.com/torvalds/linux/blame/master/arch/x86/include/asm/fpu/types.h#L130) in the kernel, so attempting to request permissions fails with EINVAL

Expected behaviour

Should boot successfully.

Environment

• Firecracker version: 1.13.1
• Host and guest kernel versions: 5.15.0-1090-aws; failure is before guest kernel starts
• Rootfs used: not used
• Architecture: x86_64 -- works on 8252C but fails on 8488C
• Any other relevant software versions:

Additional context

This is in a cloud environment where we do not have strict control over CPU models

Checks

• Have you searched the Firecracker Issues database for similar problems?
• Have you read the existing relevant Firecracker documentation?
• [~] Are you certain the bug being reported is a Firecracker issue?
  • This seems like it could be more of a kernel issue; it is saying that it supports a flag but erroring on its use

[andrewla]

Non-working CPU flags:

flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cat_l2 cdp_l3 invpcid_single intel_ppin cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect avx_vnni avx512_bf16 wbnoinvd dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq la57 rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk pconfig arch_lbr amx_bf16 avx512_fp16 amx_tile amx_int8 flush_l1d arch_capabilities

flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req pku ospke avx512_vnni md_clear flush_l1d arch_capabilities

Note amx_tile in the non-working flags.

[andrewla]

I suspect that this would repro with kernel 5.10 (a supported kernel) running on newer hardware, but have not validated that

[Manciukic]

Hey @andrewla,
thanks for the bug report.

5.15 shouldn't have the arch_prctl(ARCH_GET_XCOMP_PERM) at all (https://elixir.bootlin.com/linux/v5.15.192/source/arch/x86/include/uapi/asm/prctl.h). This looks like an incomplete backport from Ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1967750 . Ubuntu back-ported ARCH_GET_XCOMP_PERM from 5.16 but not ARCH_REQ_XCOMP_GUEST_PERM from 5.17.
Firecracker uses the first to check if the feature is available, and assumes that if it's available, also the guet perm ioctl is (see also comment in code https://github.com/firecracker-microvm/firecracker/blob/main/src/vmm/src/arch/x86_64/xstate.rs#L75), because no LTS has that combination.
However, even if we ignore the failure, I'm not sure whether the guest would boot, as it may get into the issue #5065 was fixing and that was finally fixed upstream in 6.4, depending on whether all the required patches are back-ported on 5.15.

@zulinx86 maybe you have some ideas?

[zulinx86]

First, my understanding is same as what Riccardo said. As this kernel doc says, the supported feature can be retrieved using ARCH_GET_XCOMP_SUPP and the supported features should be able to be enabled using ARCH_REQ_XCOMP_GUEST_PERM. So I think it is a bug on the kernel side.

Second, as Riccardo mentioned, ignoring the arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM) error may result in GP fault inside guest if the CPU and the kernel support Intel AMX, I think.

One thing we can do in Firecracker would be unsetting both AMX flags (bit 17 for ARCH_XCOMP_TILECFG and bit 18 for ARCH_XCOMP_TILEDATA) in the KVM_GET_SUPPORTED_CPUID result (CPUID.0xD:EAX) if ARCH_REQ_XCOMP_GUEST_PERM failed around here.

firecracker/src/vmm/src/arch/x86_64/kvm.rs

Lines 53 to 57 in 3eab936

	request_dynamic_xstate_features().map_err(KvmArchError::XstateFeatures)?;
	let supported_cpuid = fd
	.get_supported_cpuid(KVM_MAX_CPUID_ENTRIES)
	.map_err(KvmArchError::GetSupportedCpuId)?;

I'm not sure if it really doesn't cause any issue, though.

[zulinx86]

If I have access to the host kernel (5.15.0-1090-aws), I should be able to reproduce the issue and test the fix on my side. Although it may take a week or so to find time to work on this, I'll give it a try.

[zulinx86]

@andrewla I was trying to get a repro env, but I wasn't able to find free Ubuntu AMI using kernel 5.15. Could you tell me which AMI you are using (AMI ID and region)?

Instead, I tested Amazon Linux 2 AMI with kernel 5.15 works well on m7i.metal-24xl supporting Intel AMX. This is because it doesn't backport the change and Intel AMX features are not detected by the kernel.

# uname -r
5.15.191-132.213.amzn2.x86_64

# lscpu | grep Flags
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cat_l2 cdp_l3 invpcid_single intel_ppin cdp_l2 ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb intel_pt avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local split_lock_detect avx_vnni avx512_bf16 wbnoinvd dtherm ida arat pln pts hwp hwp_act_window hwp_epp hwp_pkg_req avx512vbmi umip pku ospke waitpkg avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg tme avx512_vpopcntdq rdpid bus_lock_detect cldemote movdiri movdir64b enqcmd fsrm md_clear serialize tsxldtrk pconfig arch_lbr avx512_fp16 flush_l1d arch_capabilities

[zulinx86]

I was re-understanding the context behind this issue and I realized that this issue can also happen on kernel versions >= 5.16 and < 5.17, as Riccardo mentioned.

In other words, the dynamic XSTATE feature enabling for userspace applications was introduced in v5.16 and some arch_prctl() APIs (ARCH_GET_XCOMP_SUPP, ARCH_GET_XCOMP_PERM and ARCH_REQ_XCOMP_PERM) were added. That for KVM guests was introduced in v5.17 and additional arch_prctl() APIs (ARCH_GET_XCOMP_GUEST_PERM and ARCH_REQ_XCOMP_GUEST_PERM) were introduced. Note that ARCH_XCOMP_GUEST_SUPP does not exist, so regardless of userspace application or KVM guest, ARCH_GET_XCOMP_SUPP is used to retrieve supported features.

I'll try to get such an env later and test #5447 works on it.