John Zhao has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/31917 )
Change subject: soc/intel/cnl: Generate DMAR ACPI table ......................................................................
Patch Set 14:
(2 comments)
https://review.coreboot.org/#/c/31917/10/src/soc/intel/cannonlake/romstage/s... File src/soc/intel/cannonlake/romstage/systemagent.c:
https://review.coreboot.org/#/c/31917/10/src/soc/intel/cannonlake/romstage/s... PS10, Line 32: if (dev) : config = dev->chip_info; : if (config && config->VtdDisable) : return; :
Well, IIRC, the current logic ensures the opposite: disabling VT-x when […]
Along with cpu/memory/graphics virtualization, VT-d is one of virtual-machine extension(VMX). I only run the test application at uefi shell. It seems applicable to check the vmx enabled/locked along with virtualization accomplishment like VT-d.
https://review.coreboot.org/#/c/31917/10/src/soc/intel/cannonlake/romstage/s... PS10, Line 42: sa_set_mch_bar(soc_vtd_resources, ARRAY_SIZE(soc_vtd_resources));
I fear, we are talking past each other. I'm merely concerned about the […]
Sorry, I was lost and considered others. vtd2_low (0x7880) and vtd2_high(0x7884) are categorized as MCHBAR offset. I do not see alignment issue. The bios specification states base address programmed in B0.D5.F0.R0F4 and MCHBASE offset 0x7884, which appears contradictory to fsp implementation. Literally fsp clears both of R0F4 and 0x7884 and it programs base address into R0F0 and 0x7880 orderly. Agreed with you about the order issue. We just had further update to drop the programming for 0x7884 and change IPUVTBAR value from 0x7884 to 0x7880 to sync with fsp code.