RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1974595 - [svvp] job "SystemGuard Test" failed on Win2022
Summary: [svvp] job "SystemGuard Test" failed on Win2022
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: unspecified
Hardware: x86_64
OS: Windows
high
medium
Target Milestone: rc
: ---
Assignee: Marek Kedzierski
QA Contact: dehanmeng
URL:
Whiteboard:
Depends On:
Blocks: 1968315 2057757
TreeView+ depends on / blocked
 
Reported: 2021-06-22 06:44 UTC by menli@redhat.com
Modified: 2022-06-20 09:29 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-12 04:54:22 UTC
Type: ---
Target Upstream Version:
Embargoed:
menli: needinfo-


Attachments (Terms of Use)

Description menli@redhat.com 2021-06-22 06:44:40 UTC
Description of problem:
as $summary

Version-Release number of selected component (if applicable):
qemu-kvm-6.0.0-18.module+el8.5.0+11243+5269aaa1.x86_64
seabios-1.14.0-1.module+el8.4.0+8855+a9e237a9.x86_64
kernel-4.18.0-305.7.el8.kpq1.x86_64
virtio-win-1.9.16-2.el8.iso

How reproducible:
100%

Steps to Reproduce:
1.boot up with win2022

/usr/libexec/qemu-kvm -name SUTINT850ATEST1 -machine q35,kernel-irqchip=split -cpu Broadwell,hv_stimer,hv_synic,hv_time,hv_vpindex,hv_relaxed,hv_spinlocks=0xfff,hv_vapic,hv_frequencies,hv_runtime,hv_tlbflush,hv_reenlightenment,hv_stimer_direct,hv_ipi,hv-vendor-id=KVMtest -enable-kvm -nodefaults -m 16G -smp 25,cores=25 -k en-us -boot menu=on -uuid 8a342302-d6b3-417e-bdeb-92267e897eaf -device piix3-usb-uhci,id=usb -device usb-tablet,id=tablet0 -rtc base=localtime,clock=host,driftfix=slew -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x3 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x3.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x3.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x3.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x3.0x4 -netdev tap,script=/etc/qemu-ifup,id=hostnet1,vhost=on -device virtio-net-pci,netdev=hostnet1,id=net1,mac=00:52:20:22:a9:a9,mq=on,bus=pci.3,iommu_platform=on,ats=on,disable-legacy=on,disable-modern=off -blockdev driver=file,cache.direct=off,cache.no-flush=on,filename=SUTINT850ATEST1,node-name=system_file -blockdev driver=qcow2,node-name=drive_system_disk,file=system_file -object iothread,id=thread0 -device virtio-blk-pci,scsi=off,iothread=thread0,drive=drive_system_disk,id=virtio-disk0,bootindex=1,bus=pci.4,disable-legacy=on,disable-modern=off,iommu_platform=on,ats=on -device usb-ehci,id=ehci0,bus=pci.5 -drive id=drive_cd1,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=/home/kvm_autotest_root/iso/ISO/Win2022/Windows_InsiderPreview_Server_vNext_en-us_20344.iso -device ide-cd,id=cd1,drive=drive_cd1,bus=ide.0,unit=0 -drive id=drive_cd3,if=none,snapshot=off,aio=threads,cache=none,media=cdrom,file=SUTINT850ATEST1.iso -device ide-cd,id=cd3,drive=drive_cd3,bus=ide.1,unit=0 -cdrom /home/kvm_autotest_root/iso/windows/virtio-win-latest-signed-el8.iso -vnc :0 -vga std -monitor stdio -drive file=usb-disk-UKm.raw,if=none,id=drive-usb-2-0,media=disk,format=raw,cache=none,werror=stop,rerror=stop,aio=threads -device usb-storage,bus=ehci0.0,drive=drive-usb-2-0,id=usb-2-0,removable=on 

2. submit hlk svvp job ""Hardware Security Testability Interface Test" and "SystemGuard Test"

Actual results:
job failed:
"Hardware Security Testability Interface Test" job error:
[HRESULT: 0x8007007E] A failure occurred while preparing to run tests in 'HSTILogoTest.dll'. (Failed to load "C:\HLK\JobsWorkingDir\Tasks\WTTJobRun360C0BF6-EAC8-EB11-9954-0052253A9E00\HSTILogoTest.dll" or one of its dependencies. Try running TE.exe with the /reportLoadingIssue switch to get more details. If that doesn't help, use gflags.exe to enable loader snaps for TE.ProcessHost.exe (gflags -i TE.ProcessHost.exe +sls). Then run your tests under a debugger so you can view the loader snaps output while TAEF loads your test DLL.)

"SystemGuard Test"job error:
Failed to check AutoProvisioning status.
HR = 0X800710DF
onecore\base\ngscb\internaltools\tpmhlk\toggles.cpp (Line 15)




Expected results:
job can pass

Additional info:

Comment 1 Marek Kedzierski 2021-06-22 09:34:34 UTC
According to log

"SystemGuard Test"job error:
Failed to check AutoProvisioning status.
HR = 0X800710DF
onecore\base\ngscb\internaltools\tpmhlk\toggles.cpp (Line 15)

probably tests fails because it can't find vTPM device.

Please configure the vTPM and try to run the test again.

Comment 2 menli@redhat.com 2021-06-24 08:12:12 UTC
(In reply to Marek Kedzierski from comment #1)
> According to log
> 
> "SystemGuard Test"job error:
> Failed to check AutoProvisioning status.
> HR = 0X800710DF
> onecore\base\ngscb\internaltools\tpmhlk\toggles.cpp (Line 15)
> 
> probably tests fails because it can't find vTPM device.
> 
> Please configure the vTPM and try to run the test again.

Thanks Marek

"SystemGuard Test" job can pass on Win2022 ovmf after add  vTPM.

Comment 3 menli@redhat.com 2021-06-29 08:02:33 UTC
Hi Marek,

"Hardware Security Testability Interface Test" seem not related to TPM, could you help to check it when you free, thanks

"Hardware Security Testability Interface Test" job error:
[HRESULT: 0x8007007E] A failure occurred while preparing to run tests in 'HSTILogoTest.dll'. (Failed to load "C:\HLK\JobsWorkingDir\Tasks\WTTJobRun360C0BF6-EAC8-EB11-9954-0052253A9E00\HSTILogoTest.dll" or one of its dependencies. Try running TE.exe with the /reportLoadingIssue switch to get more details. If that doesn't help, use gflags.exe to enable loader snaps for TE.ProcessHost.exe (gflags -i TE.ProcessHost.exe +sls). Then run your tests under a debugger so you can view the loader snaps output while TAEF loads your test DLL.)

Comment 6 lijin 2021-07-01 02:09:08 UTC
Hello Martin,

For win2022 svvp, some job need TPM device which means we need to run with OVMF images.

Currently, svvp certification is based on q35+seabios, do we want to change the bios type from seabios to ovmf?

Comment 7 John Ferlan 2021-09-09 15:07:12 UTC
Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Comment 8 dehanmeng 2021-12-16 09:41:18 UTC
After testing with the latest rpm virtio-win-1.9.20-1.el8_4, this case can be passed on ws-2022-uefi on RHEL840.

Comment 9 Qianqian Zhu 2022-01-12 04:54:22 UTC
Closing as WONTFIX since we are moving to ovmf for Win2022 SVVP and it passed.

Comment 10 Martin Tessun 2022-06-20 09:29:40 UTC
(In reply to lijin from comment #6)
> Hello Martin,
> 
> For win2022 svvp, some job need TPM device which means we need to run with
> OVMF images.
> 
> Currently, svvp certification is based on q35+seabios, do we want to change
> the bios type from seabios to ovmf?

Yes, as discussed in Mails.


Note You need to log in before you can comment on or make changes to this bug.