Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID serialisation is sorted

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 15/06/2020 16:34, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 2/9] tests/cpu-policy: Confirm that CPUID 
> serialisation is sorted"):
>> Nothing runs it by default, but it is part of my prepush testing for
>> anything in the relevant area.
>>
>> We should do something better, but its not totally trivial.  The x86
>> emulator test for example needs a fairly bleeding edge version of
>> binutils, given that we routinely add support for bleeding edge
>> instruction groups.
> Hmmm.  Is it likely that installing the version from Debian testing
> (say) would work ?  Or do we want to build it from source ?  These are
> all possibilities.

Pulling from Sid may work, if they're fairly prompt to update to new
binutils releases.  (They're certainly up to date ATM)

Jan: are we ever in a position where we need something more bleeding
edge than the latest binutils release?

>
> We could build binutils from source with a job-specific --prefix
> setting and that wouldn't stop it sharing the build host with other
> jobs.  Maybe it could be a seperate job which provides an anointed
> binutils build.
>
> What other awkward requirements are there ?

Most of the tests require running under a suitably configured Xen, and
even then, require doing some fairly custom things with the guest.

Perhaps a good start would be to split our "unit test like" tests away
from our "need a specifically configured Xen" tests.  The former would
be rather more amenable to running by default.

~Andrew