|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [ovmf baseline-only test] 75480: trouble: blocked/broken
This run is configured for baseline tests only. flight 75480 ovmf real [real] http://osstest.xensource.com/osstest/logs/75480/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm <job status> broken build-i386 <job status> broken build-amd64-pvops <job status> broken build-i386-xsm <job status> broken build-amd64 <job status> broken build-i386-pvops <job status> broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a build-i386 4 host-install(4) broken baseline untested build-amd64 4 host-install(4) broken baseline untested build-i386-pvops 4 host-install(4) broken baseline untested build-i386-xsm 4 host-install(4) broken baseline untested build-amd64-pvops 4 host-install(4) broken baseline untested build-amd64-xsm 4 host-install(4) broken baseline untested version targeted for testing: ovmf 073891a3e74059e996258e32b56b3f0770c6fe55 baseline version: ovmf 95aea2fac9117e95ead90378e6bb975e327d7da4 Last test of basis 75476 2018-10-22 05:50:16 Z 0 days Testing same since 75480 2018-10-22 14:20:46 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Eric Dong <eric.dong@xxxxxxxxx> Laszlo Ersek <lersek@xxxxxxxxxx> Zhaozh1x <zhiqiangx.zhao@xxxxxxxxx> ZhiqiangX Zhao <zhiqiangx.zhao@xxxxxxxxx> jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvops broken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked ------------------------------------------------------------ sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xensource.com/osstest/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-job build-i386-pvops broken broken-step build-i386 host-install(4) broken-step build-amd64 host-install(4) broken-step build-i386-pvops host-install(4) broken-step build-i386-xsm host-install(4) broken-step build-amd64-pvops host-install(4) broken-step build-amd64-xsm host-install(4) Push not applicable. ------------------------------------------------------------ commit 073891a3e74059e996258e32b56b3f0770c6fe55 Author: Zhaozh1x <zhiqiangx.zhao@xxxxxxxxx> Date: Thu Oct 18 10:42:34 2018 +0800 BaseTools: Convert "Unicode string" to "byte array" if value type diff V2: Fixed 3 typo. Use startswith(('L"',"L'")) to check if a string is Unicode string. Use a set PcdValueTypeSet instead of a list PcdValueTypeList to save memory. V1: For the same one VOID* pcd, if the default value type of one SKU is "Unicode string", the other SKUs are "OtherVOID*"(ASCII string or byte array),Then convert "Unicode string" to "byte array". Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: ZhiqiangX Zhao <zhiqiangx.zhao@xxxxxxxxx> Cc: Liming Gao <liming.gao@xxxxxxxxx> Cc: Yonghong Zhu <yonghong.zhu@xxxxxxxxx> Cc: Bob Feng <bob.c.feng@xxxxxxxxx> Reviewed-by: Bob Feng <bob.c.feng@xxxxxxxxx> commit 32be12235d68c0bf20337f8eed9386c4835d408a Author: Zhaozh1x <zhiqiangx.zhao@xxxxxxxxx> Date: Wed Oct 10 16:27:02 2018 +0800 BaseTool: Support different PCDs that refers to the same EFI variable. V2: Make the code of patch both compatible for Python2 and Python3. V1: If different PCDs refer to the same EFI variable, then do EFI variable combination, according to the VariableOffset of different PCDS. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: ZhiqiangX Zhao <zhiqiangx.zhao@xxxxxxxxx> Cc: Liming Gao <liming.gao@xxxxxxxxx> Cc: Yonghong Zhu <yonghong.zhu@xxxxxxxxx> Cc: Bob Feng <bob.c.feng@xxxxxxxxx> Reviewed-by: Bob Feng <bob.c.feng@xxxxxxxxx> commit d28daaddb3e732468e930a809d3d3943a5de9558 Author: Eric Dong <eric.dong@xxxxxxxxx> Date: Wed Oct 17 09:24:05 2018 +0800 UefiCpuPkg/CpuCommonFeaturesLib: Register MSR base on scope Info. Because MSR has scope attribute, driver has no needs to set MSR for all APs if MSR scope is core or package type. This patch updates code to base on the MSR scope value to add MSR to the register table. Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx> Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> commit 38381e18bf08dadad91627949996d106612f4753 Author: Eric Dong <eric.dong@xxxxxxxxx> Date: Wed Oct 17 09:01:15 2018 +0800 UefiCpuPkg/CpuS3DataDxe: Keep old data if value already existed. AcpiCpuData add new fields, keep these fields if old data already existed. Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx> Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx> Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx> commit 93324390582d6a5beaab226c74466e3b2497edca Author: Eric Dong <eric.dong@xxxxxxxxx> Date: Mon Oct 15 10:34:59 2018 +0800 UefiCpuPkg/PiSmmCpuDxeSmm: Add logic to support semaphore type. V4 changes: 1. Serial console log for different threads when program register table. 2. Check the AcpiCpuData before use it to avoid potential ASSERT. V3 changes: 1. Use global variable instead of internal function to return string for register type and dependence type. 2. Add comments for some complicated logic. V1 changes: Because this driver needs to set MSRs saved in normal boot phase, sync semaphore logic from RegisterCpuFeaturesLib code which used for normal boot phase. Detail see below change for RegisterCpuFeaturesLib: UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type. Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx> Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Acked-by: Laszlo Ersek <lersek@xxxxxxxxxx> Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx> commit b3c71b472dff2c02f0cc38d7a1959cfb2ba8420d Author: Eric Dong <eric.dong@xxxxxxxxx> Date: Wed Oct 17 09:31:03 2018 +0800 UefiCpuPkg/RegisterCpuFeaturesLib: Add logic to support semaphore type. V4 changes include: 1. Serial debug message for different threads when program the register table. V3 changes include: 1. Use global variable instead of internal function to return string for register type and dependence type. 2. Add comments for some complicated logic. V2 changes include: 1. Add more description for the code part which need easy to understand. 2. Refine some code base on feedback for V1 changes. V1 changes include: In a system which has multiple cores, current set register value task costs huge times. After investigation, current set MSR task costs most of the times. Current logic uses SpinLock to let set MSR task as an single thread task for all cores. Because MSR has scope attribute which may cause GP fault if multiple APs set MSR at the same time, current logic use an easiest solution (use SpinLock) to avoid this issue, but it will cost huge times. In order to fix this performance issue, new solution will set MSRs base on their scope attribute. After this, the SpinLock will not needed. Without SpinLock, new issue raised which is caused by MSR dependence. For example, MSR A depends on MSR B which means MSR A must been set after MSR B has been set. Also MSR B is package scope level and MSR A is thread scope level. If system has multiple threads, Thread 1 needs to set the thread level MSRs and thread 2 needs to set thread and package level MSRs. Set MSRs task for thread 1 and thread 2 like below: Thread 1 Thread 2 MSR B N Y MSR A Y Y If driver don't control execute MSR order, for thread 1, it will execute MSR A first, but at this time, MSR B not been executed yet by thread 2. system may trig exception at this time. In order to fix the above issue, driver introduces semaphore logic to control the MSR execute sequence. For the above case, a semaphore will be add between MSR A and B for all threads. Semaphore has scope info for it. The possible scope value is core or package. For each thread, when it meets a semaphore during it set registers, it will 1) release semaphore (+1) for each threads in this core or package(based on the scope info for this semaphore) 2) acquire semaphore (-1) for all the threads in this core or package(based on the scope info for this semaphore). With these two steps, driver can control MSR sequence. Sample code logic like below: // // First increase semaphore count by 1 for processors in this package. // for (ProcessorIndex = 0; ProcessorIndex < PackageThreadsCount ; ProcessorIndex ++) { LibReleaseSemaphore ((UINT32 *) &SemaphorePtr[PackageOffset + ProcessorIndex]); } // // Second, check whether the count has reach the check number. // for (ProcessorIndex = 0; ProcessorIndex < ValidApCount; ProcessorIndex ++) { LibWaitForSemaphore (&SemaphorePtr[ApOffset]); } Platform Requirement: 1. This change requires register MSR setting base on MSR scope info. If still register MSR for all threads, exception may raised. Known limitation: 1. Current CpuFeatures driver supports DXE instance and PEI instance. But semaphore logic requires Aps execute in async mode which is not supported by PEI driver. So CpuFeature PEI instance not works after this change. We plan to support async mode for PEI in phase 2 for this task. Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx> Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> commit 87e9395109672ff225c934c342cac536644b2bbe Author: Eric Dong <eric.dong@xxxxxxxxx> Date: Mon Oct 15 09:21:06 2018 +0800 UefiCpuPkg/RegisterCpuFeaturesLib.h: Add new dependence types. V4 changes: 1. Update comments. v3 changes: 1. Move CPU_FEATURE_DEPENDENCE_TYPE definition to AcpiCpuData.h. 2. Add comments for CPU_FEATURE_BEFORE/CPU_FEATURE_AFTER. v1 changes: Add new core/package dependence types which consumed by different MSRs. Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx> Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> commit d5aa2078f74cd0ce3f87deb6a3350d6b251cf7ed Author: Eric Dong <eric.dong@xxxxxxxxx> Date: Mon Oct 15 09:19:18 2018 +0800 UefiCpuPkg/Include/AcpiCpuData.h: Add Semaphore related Information. v3 changes: 1. Move CPU_FEATURE_DEPENDENCE_TYPE definition here from RegisterCpuFeaturesLib.h file. 2. Add Invalid type for REGISTER_TYPE which will be used in code. v2 changes: 1. Add more description about why we do this change. 2. Change structure field type from pointer to EFI_PHYSICAL_ADDRESS because it will be share between PEI and DXE. v1 Changes: In order to support semaphore related logic, add new definition for it. In a system which has multiple cores, current set register value task costs huge times. After investigation, current set MSR task costs most of the times. Current logic uses SpinLock to let set MSR task as an single thread task for all cores. Because MSR has scope attribute which may cause GP fault if multiple APs set MSR at the same time, current logic use an easiest solution (use SpinLock) to avoid this issue, but it will cost huge times. In order to fix this performance issue, new solution will set MSRs base on their scope attribute. After this, the SpinLock will not needed. Without SpinLock, new issue raised which is caused by MSR dependence. For example, MSR A depends on MSR B which means MSR A must been set after MSR B has been set. Also MSR B is package scope level and MSR A is thread scope level. If system has multiple threads, Thread 1 needs to set the thread level MSRs and thread 2 needs to set thread and package level MSRs. Set MSRs task for thread 1 and thread 2 like below: Thread 1 Thread 2 MSR B N Y MSR A Y Y If driver don't control execute MSR order, for thread 1, it will execute MSR A first, but at this time, MSR B not been executed yet by thread 2. system may trig exception at this time. In order to fix the above issue, driver introduces semaphore logic to control the MSR execute sequence. For the above case, a semaphore will be add between MSR A and B for all threads. Semaphore has scope info for it. The possible scope value is core or package. For each thread, when it meets a semaphore during it set registers, it will 1) release semaphore (+1) for each threads in this core or package(based on the scope info for this semaphore) 2) acquire semaphore (-1) for all the threads in this core or package(based on the scope info for this semaphore). With these two steps, driver can control MSR sequence. Sample code logic like below: // // First increase semaphore count by 1 for processors in this package. // for (ProcessorIndex = 0; ProcessorIndex < PackageThreadsCount ; ProcessorIndex ++) { LibReleaseSemaphore ((UINT32 *) &SemaphorePtr[PackageOffset + ProcessorIndex]); } // // Second, check whether the count has reach the check number. // for (ProcessorIndex = 0; ProcessorIndex < ValidApCount; ProcessorIndex ++) { LibWaitForSemaphore (&SemaphorePtr[ApOffset]); } Platform Requirement: 1. This change requires register MSR setting base on MSR scope info. If still register MSR for all threads, exception may raised. Known limitation: 1. Current CpuFeatures driver supports DXE instance and PEI instance. But semaphore logic requires Aps execute in async mode which is not supported by PEI driver. So CpuFeature PEI instance not works after this change. We plan to support async mode for PEI in phase 2 for this task. Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx> Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx> Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |