env_process: Refactor huge pages setup/cleanup steps
Creating a new Setuper subclass for setting and cleaning huge pages up. Removing the original code from virttest.env_process and replacing it instead with the new HugePagesSetup class being registered in the setup_manager.
_pre_hugepages_surp and _post_hugepages_surp were left in env_process. Their goal is to provide a mechanism in env_process to raise a TestFail in case pages were leaked during a test. If that mechanism was refactored into the setuper, the TestFail would be masked by just an Error due to the way setup_manager handles postprocess exceptions. Changing the way SetupManager handles that requires bigger discussion on how the test infrastructure should handle test status reports, which is a way broader topic that what this patch aims to be.
This is a patch from a larger patch series refactoring the env_process preprocess and postprocess functions. In each of these patches, a pre/post process step is identified and replaced with a Setuper subclass so the following can finally be met: - Only cleanup steps of successful setup steps are run to avoid possible environment corruption or hard to read errors. - Running setup/cleanup steps symmetrically during env pre/post process. - Reduce explicit pre/post process function code length.
Hi @PaulYuuu Could you help to review it? Thanks.
Memory huge_page test runs passed with RHEL 10 and Win2025 guests
(01/18) Host_RHEL.m10.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.10.0.x86_64.io-github-autotest-qemu.unattended_install.cdrom.extra_cdrom_ks.default_install.aio_threads.q35: STARTED
(01/18) Host_RHEL.m10.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.10.0.x86_64.io-github-autotest-qemu.unattended_install.cdrom.extra_cdrom_ks.default_install.aio_threads.q35: PASS (955.79 s)
(02/18) Host_RHEL.m10.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.10.0.x86_64.io-github-autotest-qemu.system_reset_bootable.q35: STARTED
(02/18) Host_RHEL.m10.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.10.0.x86_64.io-github-autotest-qemu.system_reset_bootable.q35: PASS (385.09 s)
...
(18/18) Host_RHEL.m10.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.10.0.x86_64.io-github-autotest-qemu.hugepage_mem_stress.non_existent_mem_path.q35: STARTED
(18/18) Host_RHEL.m10.u0.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.RHEL.10.0.x86_64.io-github-autotest-qemu.hugepage_mem_stress.non_existent_mem_path.q35:PASS (135.92 s)
RESULTS : PASS 15 | ERROR 0 | FAIL 0 | SKIP 3 | WARN 0 | INTERRUPT 0 | CANCEL 0
(01/18) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.unattended_install.cdrom.extra_cdrom_ks.default_install.aio_threads.q35: STARTED
(01/18) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.unattended_install.cdrom.extra_cdrom_ks.default_install.aio_threads.q35: PASS (5306.26 s)
(02/18) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.disable_win_update.q35: STARTED
(02/18) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.disable_win_update.q35: PASS (499.09 s)
...
(18/18) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.migrate.tcp.with_filter_off.with_post_copy.q35: STARTED
(18/18) Host_RHEL.m9.u6.ovmf.qcow2.virtio_scsi.up.virtio_net.Guest.Win2025.x86_64.io-github-autotest-qemu.migrate.tcp.with_filter_off.with_post_copy.q35: PASS (274.00 s)
RESULTS : PASS 15 | ERROR 0 | FAIL 0 | SKIP 3 | WARN 0 | INTERRUPT 0 | CANCEL 0
Hi @dzhengfy @chunfuwen I assume that this change may affect the libvirt test. Could you help to review it from the libvirt side? Thanks a lot.