[PATCH XTF RFC] force-enable UMIP for UMIP testing

Jan Beulich posted 1 patch 5 years ago
Failed in applying to current master (apply log)
[PATCH XTF RFC] force-enable UMIP for UMIP testing
Posted by Jan Beulich 5 years ago
Enable UMIP even if underlying hardware doesn't support it (assuming
the respective change supporting its emulation is in place). Obviously,
as explained in that patch, the SMSW test is then expected to fail on
Intel hardware.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/tests/umip/Makefile
+++ b/tests/umip/Makefile
@@ -4,6 +4,8 @@ NAME      := umip
 CATEGORY  := functional
 TEST-ENVS := hvm32 hvm64
 
+TEST-EXTRA-CFG := extra.cfg.in
+
 obj-perenv += main.o
 
 include $(ROOT)/build/gen.mk
--- /dev/null
+++ b/tests/umip/extra.cfg.in
@@ -0,0 +1 @@
+cpuid = "host,umip=1"


Re: [PATCH XTF RFC] force-enable UMIP for UMIP testing
Posted by Andrew Cooper 5 years ago
On 29/01/2021 11:47, Jan Beulich wrote:
> Enable UMIP even if underlying hardware doesn't support it (assuming
> the respective change supporting its emulation is in place). Obviously,
> as explained in that patch, the SMSW test is then expected to fail on
> Intel hardware.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/tests/umip/Makefile
> +++ b/tests/umip/Makefile
> @@ -4,6 +4,8 @@ NAME      := umip
>  CATEGORY  := functional
>  TEST-ENVS := hvm32 hvm64
>  
> +TEST-EXTRA-CFG := extra.cfg.in
> +
>  obj-perenv += main.o
>  
>  include $(ROOT)/build/gen.mk
> --- /dev/null
> +++ b/tests/umip/extra.cfg.in
> @@ -0,0 +1 @@
> +cpuid = "host,umip=1"

So while I agree in principle that having UMIP emulation is a good
thing, this particular change in XTF would be rejected by the OSSTest
bisector.

The only reason it doesn't fail straight away for the PV guests is
because there's no error handling from problematic CPUID requests, which
is something still to be fixed.

Given that SMSW is a known (and acceptable) hole in UMIP emulation under
Intel, it should be converted into a skip.  However, that is also a
logical change to the test, and will cause other problems for bisection.

This does need the test-revision logic (as does one other bug in the
UMIP test IIRC), which I need to get around to finishing.

I'll see about trying to do that early next release cycle, because the
"tests are logically immutable to avoid the bisector saying no"
restriction is getting in the way of a lot of people, myself included.

~Andrew