openhcl/virt_mshv_vtl: On TDX, always report that MCE,MCA,MTRR CPUID bits are set regardless of what the hardware says #2142
Conversation
…f what the hardware says
smalis-msft
added
the
backport_2505
There was a problem hiding this comment.
Pull Request Overview
This PR fixes a regression with newer TDX firmware modules by ensuring that specific CPU features (MCE, MCA, and MTRR) are always reported as supported to guests, regardless of what the underlying hardware reports.
- Always sets MCE, MCA, and MTRR feature bits in CPUID responses for TDX guests
- Adds fixup logic for both VersionAndFeatures and ExtendedVersionAndFeatures CPUID functions
chris-oo
changed the title
|
One thing Ben raised was questions around MSR handling. I think we already emulated the associated MSRs in usermode (IE the hardware didn't do anything), but can we confirm? Wondering if we need to try some guest accesses? |
|
What MSRs would that be? |
|
Ben thinks that booting windows should exercise MTRRs and MCA/MCE, lets double check with Alex & Ben. |
smalis-msft
added
the
release-ci-required
|
The TDX spec just states "applicable MSRs" - For MTRR I expect they would be MTRR_CAP, MTRR_PHYSMASK* and MTRR_FIX* The machine check registers are MC*_CTL/STATUS/ADDR/MISC |
|
The kernel side change will be needed. In case of the availability and opt-in of feature (TDCS.REDUCE_VE = 1), setting of the TDCS.FEATURE_PARAVIRT_CTLS bits will in turn dictate the tdx module behavior when guest accesses the MTRRs and MCA/MCE registers. |
|
Could you clarify - does this mean the TDX module won't even exit to the L1 if the L2 accesses these MSRs when the CTLS bit is 0-ed? |
|
I have successfully booted a TDX Windows VM with this patch and the new TDX module that did not boot without this patch. |
|
According to wikipedia the duplicated bits in ExtendedInfo here are only present on AMD cpus, not Intel. We may want to remove them? |
5 participants
This fixes a regression with newer TDX firmware modules.
Closes #2131