Add cpu policy helper and test

[TSnake41]

Add a CPU policy tooling to be able to check for certain CPU feature.
The test_cpu_policy also logs hosts CPU policies for debugging purposes (especially around live migrations).

Required by #393

[glehmann]

The test doesn't seem actually to validate anything. Am I missing something?

[TSnake41]

The test doesn't seem actually to validate anything. Am I missing something?

There's nothing to validate aside that it doesn't errors.

[glehmann]

Suggested change

	def __init__(self, cpuid: dict[(int, int), int], msr: dict[int, int]):
	def __init__(self, cpuid: dict[tuple[int, int], tuple[int, int, int, int]], msr: dict[int, int]):

[dinhngtu]

@glehmann, is the current recommendation to use native types for typing or the ones from the typing module?

[glehmann]

tuple[int, int, int, int] might be better represented with

@dataclass(frozen=True)
class CpuidRegisters:
    eax: int
    ebx: int
    ecx: int
    edx: int

and used as

def __init__(self, cpuid: dict[tuple[int, int], CpuidRegisters], msr: dict[int, int]):

                current_policy.cpuid[key] = CpuidRegisters(
                    int(eax, 16),
                    int(ebx, 16),
                    int(ecx, 16),
                    int(edx, 16)
                )

Each element can then be accessed by name:

current_policy.cpuid[key].eax

[glehmann]

@glehmann, is the current recommendation to use native types for typing or the ones from the typing module?

No, we had diverging opinions on that last time we discussed it.
I'm proposing to go with builtin types in #460

[dinhngtu]

Please fix the checkers first.

[stormi]

@TSnake41 After a force push, if your PR is ready for re-review, always ask the reviewers who commented for a re-review.

[stormi]

This seems to be a test that doesn't test anything. I understand from the commit message that its goal is to log data about the CPUs, but I have no idea when and why this data is supposed to be gathered. Well, no, by following the link to another PR from this PR's description I understand that it's related to #393, but this explains why the lib was added (which I would probably have done in the other PR), not the test itself.

I assume that you rely on the fact that you put the test in the xen directory, and that, for the time being, it will get selected by the current selection criteria for the xen job in jobs.py, but this seems fragile to me.

I don't think we should have tests whose sole objective is to log data without testing anything in particular. But if we do, they it should be made very clear in the test description.

[TSnake41]

It does log thing, but it also does tests, as if we can't gather this information (this is mostly going to happen in a change in xen-cpuid) the test would now fail, instead of making all the tests that depends on cpu policy fail.

[stormi]

The tests that depend on it would also fail, if executed first.

I guess we can keep it as it is, but it would be good to add explanations as a comment, and rename the test to indicate what it really tests: we don't test the CPU policies, here, we test CPU policies collection.

[stormi]

There's a "requirements" comment here, in test files.