linux-kernel - Re: [RFC] cxl_test: upgrade as a first class citizen selftests capable driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y6Crh5DiGPPzKoYp@bombadil.infradead.org>
Date:   Mon, 19 Dec 2022 10:20:55 -0800
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     Jonathan Cameron <Jonathan.Cameron@...wei.com>
Cc:     Dan Williams <dan.j.williams@...el.com>,
        alison.schofield@...el.com, vishal.l.verma@...el.com,
        ira.weiny@...el.com, bwidawsk@...nel.org, dave@...olabs.net,
        a.manzanares@...sung.com, linux-cxl@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC] cxl_test: upgrade as a first class citizen selftests
 capable driver

On Sun, Dec 18, 2022 at 04:08:24PM +0000, Jonathan Cameron wrote:
> QEMU based CI should go two ways:
> 1) QEMU CI would typically pin particular kernel version and verify that
>    QEMU changed don't break that. If we need new features for a new test,
>    we move that kernel version used.  Existing tests should never break
>    against a fixed kernel version as that's a regression in QEMU (or
>    maybe a bug elsewhere) Ultimately we should have this running in the
>    normal QEMU gitlab CI.

Sounds sensible.

> 2) Kernel CI against QEMU would typically pin particular QEMU version
>    and check that kernel changes don't break.  This will have rough edges
>    for a while yet as we are still adding mandatory features to the QEMU
>    emulation (e.g. events support).  Again, as we add new features / tests
>    may need to move the QEMU version forwards to support them.

Sure - but for this today other than ensuring a kernel does not crash upon
bootup we also have cxl_test, but not much else.

We'll want to exand a set of target tests on CXL enabled nodes, without
cxl_test. Other than verifying the topology matches, we'll want to start
mimicking actual use cases / performance stuff.

> I don't think we much care about backwards compatibility so once we've
> moved the pinned element forwards in the above, we won't care about the
> old version. 

Making tests simply skip if the feature is not available doens't take
much effort but forward thinking.

> The aim here isn't really to ensure no regressions when
> running on QEMU (though that CI is nice to have), but more that we have
> no problems in kernel side of things.

Sure.

> This is a way off yet.  Not seeing this as being part of linux.git.
> The QEMU CI stuff will be in the qemu.git and Kernel CI stuff probably
> sit out of tree - there shouldn't be a tight coupling beyond new tests
> wanting to check available features etc. I might ask a friendly
> CI project to add this to their normal runs.

OK in case it helps, cxl-enabled qemu building bringup / ndctl building
and install is all now automated and integratead as part of kdevops so
patches welcomed to expand that coverage.

> I don't have strong feelings on cxl_test. Tend not to use it myself
> and haven't yet contributed to it.

Thanks, this is useful information.

  Luis