[PATCH kdevops] defconfig: add linux-modules-kpd defconfig symlink

2024-10-12 Thread Luis Chamberlain
We have now two kdevops proof of concepts with kernel-patches-daemon [0],
one for Linux kernel modules testing [1] and the other with radix tree
testing (xarray, maple tree) [2]. These trees just contain the required
.github/workflows/* files used to trigger a github self-hosted runner
to run kdevops since evaluation shows that using github hosted runners
will just not work or scale for Linux kernel testing [3]. The way this
works with KPD is that KPD has an app in the linux-kdevops organization
which is in charge of taking patch series posted to your respective
subsystem patchwork (you can have dedicated filters on a mailing list
for only specific files if you don't have a dedicated mailing list), it
creates a git tree branch using your configured KPD main development
tree source, and pushes it out to a respective test tree under github
for for you. For example, in the case of development for Linux modules
it pushes out a branch with a delta onto the linux-modules-kpd tree [4]
and in it, it will also merge the latest kdevops-ci-modules [1] work,
which is where the github runner work gets developed. For the radix tree
we currently do not yet have a patchwork instance defined but we *could*,
and the way it would work is that KPD would push out a branch into
the linux-radix-tree-kpd [5] tree with the github actions defined in its
respective kdevops-ci-radix-tree [3] tree.

What these PoC shows is that the way kdevops has designed testing
selftests is that we actually only need to differ in *one* single line
of code on the github actions runner to test either of these two Linux
kernel subsystems: the defconfig used.

To be able to *share* the *same* Linux kernel github actions runner
code development between the Linux kernel module tests and the radix
tree, all we need to do then is use the git tree onto which a delta
was pushed onto as the source for the defconfig. So all we have to do
now is just add a symlink of the respective development test tree onto
its corresponding defconfig.

Add the respective defconfig then for linux-modules-kpd by symlinking it
to the seltests-kmod-cli defconfig. This will let us later share *one*
github development action runner code for self-hosted runners for *all*
Linux kernel sefltests we define in *one* development tree which KPD
could leverage.

Now that we have locked down the linux-kdevops github organization to
only allow respective developers to be able to trigger pushes or PRs,
this also allows us to add dedicated self-hosted runners per target
test development repository so we can scale our testing as we need with
security in mind. The only thing left to do here now, is to evaluate
if we want an allow check for who's patches we want to enable automatic
testing for through KPD.

[0] https://github.com/facebookincubator/kernel-patches-daemon
[1] https://github.com/linux-kdevops/kdevops-ci-modules
[2] https://github.com/linux-kdevops/kdevops-ci-radix-tree
[3] 
https://lore.kernel.org/kdevops/CAB=ne6vkwskv1jz_z2lkq4o7+jbkkc6u8wa1zxxbnghog4b...@mail.gmail.com/T/#u
[4] https://github.com/linux-kdevops/linux-modules-kpd
[5] https://github.com/linux-kdevops/linux-radix-tree-kpd
Signed-off-by: Luis Chamberlain 
---
 defconfigs/linux-modules-kpd | 1 +
 1 file changed, 1 insertion(+)
 create mode 12 defconfigs/linux-modules-kpd

diff --git a/defconfigs/linux-modules-kpd b/defconfigs/linux-modules-kpd
new file mode 12
index ..e61fd7f687b0
--- /dev/null
+++ b/defconfigs/linux-modules-kpd
@@ -0,0 +1 @@
+seltests-kmod-cli
\ No newline at end of file
-- 
2.43.0




Re: [PATCH v3 3/4] vfio: Add VFIO_DEVICE_PASID_[AT|DE]TACH_IOMMUFD_PT

2024-10-12 Thread Yi Liu

On 2024/10/1 20:11, Jason Gunthorpe wrote:

On Mon, Sep 30, 2024 at 07:55:08AM +, Tian, Kevin wrote:


+struct vfio_device_pasid_attach_iommufd_pt {
+   __u32   argsz;
+   __u32   flags;
+   __u32   pasid;
+   __u32   pt_id;
+};
+
+#define VFIO_DEVICE_PASID_ATTACH_IOMMUFD_PT_IO(VFIO_TYPE,
VFIO_BASE + 21)


Not sure whether this was discussed before. Does it make sense
to reuse the existing VFIO_DEVICE_ATTACH_IOMMUFD_PT
by introducing a new pasid field and a new flag bit?


Maybe? I don't have a strong feeling either way.

There is somewhat less code if you reuse the ioctl at least


I had a rough memory that I was suggested to add a separate ioctl for
PASID. Let's see Alex's opinion.

@Alex.

--
Regards,
Yi Liu