Consider merging verification test configs with release configs because they're almost identical

[kent-mcleod]

I wonder whether the cost of running Verification separately from Release is worth any benefit

There's almost no distinction between them anymore.

Arm has: KernelArmHypEnableVCPUCP14SaveAndRestore was the only option I could find that would be on for release but off for verification

x86 has: KernelVTX, KernelX86_64VTX64BitGuests and KernelIOMMU as options that can't be on for verification but could be on otherwise.

RISCV has no difference.

So essentially the "release" option could be merged with the "verification" option in non-x86 platforms

And we should check and see why KernelArmHypEnableVCPUCP14SaveAndRestore can't be enabled with verification

Would save a bunch of time running tests

[lsf37]

Agreed, that would cut running time by a lot, I'll look into KernelArmHypEnableVCPUCP14SaveAndRestore.

(It probably just wasn't in the config when ARM_HYP was done originally)

[Indanz]

To me it seems weird that the VM is allowed to use debug features, while native user space isn't. That is a weird default setting. I'd expect it to follow CONFIG_HARDWARE_DEBUG_API by default. So personally I'd disable KernelArmHypEnableVCPUCP14SaveAndRestore for release instead of enabling it for verification, while keeping it on for debug builds.

[lsf37]

The option does bring in the API functions Arch_debugAssociateVCPUTCB and Arch_debugDissociateVCPUTCB. That doesn't look too good for verification, but I need to dig deeper.

Confirmed that this would be a bigger job at least. It draws in all the debug breakpoint stuff. It's not something we can support on the side.