action #100512
closed[Tumbleweed][security][backlog] security_swtpm_uefi is not multi-arch
100%
Description
Observation¶
openQA test in scenario opensuse-Tumbleweed-DVD-aarch64-security_swtpm_uefi@aarch64 fails in
swtpm_verify
security_swtpm_uefi
is not multi-arch yet and supports x86 only atm.
You can see the failure on aarch64 here: https://openqa.opensuse.org/tests/1955722/modules/swtpm_verify/steps/12
swtpm/swtpm_aarch64_uefi.xml
variant of swtpm/swtpm_uefi.xml
should be created and used.
Test suite description¶
Reproducible¶
Fails since (at least) Build 20210929
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
Files
Updated by maritawerner over 3 years ago
- Subject changed from security_swtpm_uefi is not multi-arch to [security] security_swtpm_uefi is not multi-arch
Updated by llzhao over 3 years ago
- Subject changed from [security] security_swtpm_uefi is not multi-arch to [Tumbleweed][security] security_swtpm_uefi is not multi-arch
- Category changed from Bugs in existing tests to Enhancement to existing tests
- Assignee set to rfan1
- Estimated time set to 16.00 h
Updated by ggardet_arm over 3 years ago
This is already in dev group: https://openqa.opensuse.org/tests/1962934#step/swtpm_verify/14
And I confirm there is no nested virt on aarch64 for now.
Updated by shawnhao over 3 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Closed this poo since security_swtpm_uefi supports only x86 for now.
Updated by ggardet_arm over 3 years ago
- Status changed from Resolved to New
shawnhao wrote:
Closed this poo since security_swtpm_uefi supports only x86 for now.
Reopen.
The purpose of this ticket is to make it compatible with aarch64, so closing it with 'x86 only for now' does not seem right.
Are there any limitations making it really incompatible with aarch64?
Updated by rfan1 over 3 years ago
ggardet_arm wrote:
shawnhao wrote:
Closed this poo since security_swtpm_uefi supports only x86 for now.
Reopen.
The purpose of this ticket is to make it compatible with aarch64, so closing it with 'x86 only for now' does not seem right.
Are there any limitations making it really incompatible with aarch64?
We are carrying out this tests with nested virtualization on x86_64 platform, however, on aarch64, we may not support nested virtualization for now, correct?
please correct me if I am wrong, then we can implement the tests on aarch64 as well.
Updated by ggardet_arm over 3 years ago
Sorry, but I do not understand why nested virt is mandatory. We can run qemu inside qemu, without kvm. It is already done for openqa_bootstrap
test.
Updated by rfan1 over 3 years ago
Thanks,
Qemu in qemu without kvm should have very low performance, can you please help point me the test link? I will try to test it manually at first.
The reason why I used virt is that: this new feature as SLES15SP3 should support libvirt as well. so I tested the x86_64 with libvirt with qemu+kvm emulator.
BR//Richard.
Updated by ggardet_arm over 3 years ago
Updated by rfan1 over 3 years ago
ggardet_arm wrote:
openqa_bootstrap
test without kvm:
Thanks, I will try with qemu L2 guest then.
Updated by rfan1 over 3 years ago
I have trouble to boot up my L2 vm on my local aarch64 setup.
#/usr/bin/qemu-system-aarch64 \
-m 2048 \
-machine virt,usb=off,gic-version=2,its=off \
-netdev user,id=qanet0,hostfwd=tcp::2222-:22 \
-device virtio-net,netdev=qanet0,mac=52:54:00:12:34:57 \
-boot menu=on,splash-time=5000 \
-smp 2 \
-vnc :92 \
-device virtio-scsi-pci,id=scsi0 \
-blockdev driver=file,node-name=hd0-overlay0-file,filename=opensuse-Tumbleweed-aarch64-20211028-textmode@aarch64.qcow2,cache.no-flush=on \
-blockdev driver=qcow2,node-name=hd0-overlay0,file=hd0-overlay0-file,cache.no-flush=on \
-device virtio-blk-device,id=hd0-device,drive=hd0-overlay0,serial=hd0 \
-drive id=pflash-code-overlay0,if=pflash,file=/home/aavmf-aarch64-code.bin,readonly=on \
-drive id=pflash-vars-overlay0,if=pflash,file=/home/aavmf-aarch64-vars.bin,unit=1,format=raw \
-serial stdio
I failed to boot up my VM and qemu seemed hang there.
BTW, do we have any ipmi setup to run the swtpm tests? it will not need nested virtualization then.
Updated by llzhao almost 3 years ago
- Subject changed from [Tumbleweed][security] security_swtpm_uefi is not multi-arch to [Tumbleweed][security][backlog] security_swtpm_uefi is not multi-arch
Updated by shawnhao almost 3 years ago
- Assignee changed from shawnhao to StarryWang
Updated by StarryWang over 2 years ago
- Status changed from New to In Progress
- % Done changed from 100 to 0
I'll try to add swtpm/swtpm_aarch64_uefi.xml
and add aarch64 support for this test case.
Updated by StarryWang over 2 years ago
- Status changed from In Progress to Rejected
The aarch64 platform does not support nested virtualization, so this ticket will be rejected.
https://openqa.opensuse.org/tests/2416048#step/swtpm_verify/12
Updated by ggardet_arm over 2 years ago
I see 2 possibilities to workaround this:
- Use non-kvm virtualization
- Use the Raspberry Pi 4 target
Updated by StarryWang over 2 years ago
StarryWang wrote:
The aarch64 platform does not support nested virtualization, so this ticket will be rejected.
https://openqa.opensuse.org/tests/2416048#step/swtpm_verify/12
Hi, thanks for your reminder,
Just discussed with @rfan1, we can not use non-kvm virtualization since swtpm requires it.
So can you help to provide some docs about how to run it on RPI4? thanks.
Updated by StarryWang over 2 years ago
- Status changed from Rejected to In Progress
Updated by ggardet_arm over 2 years ago
Here is an example of test on the Raspberry Pi 4 with vagrant: https://openqa.opensuse.org/tests/2415755
You can have a look at schedule/vagrant.yaml
for the 1st steps needed to boot and prepare the RPi 4, before running the tests for TPM.
Also, pevik_
(Petr Vorel) reached out to me on IRC yesterday, for tests using LetsTrust TPM module. See: https://en.opensuse.org/HCL:Raspberry_Pi3_TPM
So, I plugged this TPM module in the Raspberry Pi 4 used on o3 (WORKER_CLASS=generalhw_RPi4_TPM
).
Updated by StarryWang over 2 years ago
- % Done changed from 0 to 50
I've updated the test code to add JeOS support for this test case,
and now these tests are passed in the Dev group.
https://openqa.opensuse.org/tests/2420013#
https://openqa.opensuse.org/tests/2420014#
I'll submit a PR when these tests are stable in Dev group.
Updated by StarryWang over 2 years ago
- % Done changed from 50 to 60
The flavor of create_swtpm_hdd_aarch
is DVD, and the flavor of security_swtpm_jeos
is JeOS-for-RPi-aarch64,
I can not add START_AFTER_TEST
dependencies between these two tests since they use different flavors,
and I also can not set the flavor of create_swtpm_hdd_aarch
to JeOS-for-RPi-aarch64
since it needs to start after create_hdd_textmode@aarch64
.
So I updated the test code in swtpm_env_setup.pm
to check the status of create_swtpm_hdd_aarch
by using openQA API.
Here is the test result after I changed the test code:
create_swtpm_hdd_aarch: https://openqa.opensuse.org/tests/2432209#
security_swtpm_jeos: https://openqa.opensuse.org/tests/2432404#
Updated by StarryWang over 2 years ago
- Status changed from In Progress to Workable
- % Done changed from 60 to 80
Updated by StarryWang over 2 years ago
@bchou suggests I rename the new test name to security_swtpm_jeos_rpi4
.
And I renamed the yaml schedule file name to swtpm_jeos_rpi4.yaml
.
Here is the VR after rename the test suite: https://openqa.opensuse.org/tests/2433943#
Updated by StarryWang over 2 years ago
- Status changed from Workable to Feedback
- % Done changed from 80 to 100
PR Merged.
Updated by StarryWang over 2 years ago
- Related to action #113063: [Tumbleweed][security][backlog] Move swtpm aarch64 tests to production job group added
Updated by StarryWang over 2 years ago
- Status changed from Feedback to Resolved
Test passed successfully in development job group:
create_swtpm_hdd_aarch: https://openqa.opensuse.org/tests/2436019
security_swtpm_jeos_rpi4: https://openqa.opensuse.org/tests/2435932