Sep 12 – 14, 2022
Europe/Dublin timezone

Proposed microconferences

Microconferences proposed for LPC 2022


Android

Continuing in the same direction as last year, this year's Android microconference will be an opportunity to foster collaboration between the Android and Linux kernel communities. Discussions will be centered on the goal of ensuring that both the Android and Linux development moves in a lockstep fashion going forward.

Projected talks:

  • io_uring in Android (Akilesh Kailash)
  • MGLRU results on Android (Kalesh Singh or Yu Zhao presenting over VC)
  • Hermetic builds with Bazel (Matthias Männich)
  • Android kernel testing updates (Steve Muckle)
  • pKVM (Quentin Perret)
  • erofs as a replacement for f2fs and the deprecation of ext4 (David Anderson)
  • eBPF-based FUSE (Paul Lawrence)
  • stgdiff tools (Giuliano Procida)
  • Technical debt (Lee Jones)
  • Parallelized suspend/resume (Saravana Kannan)
  • CPU DVFS for guest thread migrations (Saravana Kannan)

Accomplishments since the last Android MC:

  • fw_devlink: Fixed the correctness of sync_state() callbacks when simple-bus devices are involved
  • Implemented a prototype for the cgroup-based accounting of DMA-BUF allocations -- current review doc: https://patchwork.kernel.org/project/linux-media/patch/20220328035951.1817417-2-tjmercier@google.com/
  • Other dependencies for tracking shared gfx buffers now merged
  • Improved community collaboration:
  • Collaboration page set up: https://aosp-developers-community.github.io/
  • Integrating v4l2_codec2 HAL on v4l2-compliant upstream codecs WIP

MC leads:

  • Karim Yaghmour
  • Suren Baghdasaryan
  • John Stultz
  • Amit Pundir
  • Sumit Semwal

Compute Express Link

Compute Express Link is a cache coherent fabric that is gaining a lot of momentum in the industry and subsuming many competing specifications. Several hardware vendors have begun to ramp up on CXL 2.0 hardware and software must not lag behind. The current software ecosystem looks promising. Enough components are mature enough to begin provisioning test systems. While Intel has been on the forefront of the software enabling for memory expander devices, many other interested parties are beginning to ask questions about how to participate and support their hardware.

The Compute Express Link microconference focuses around how to evolve the Linux CXL kernel driver and userspace for full support of the CXL 2.0 spec (and beyond). It allows us to open the discussion to incorporate and grow the CXL community making sure that everyone's needs are met and expectations are set around what use-cases are expected and will be supported. Finally, it will be a good opportunity to articulate what the current set of developers have a good handle on how to support and what needs more brain power.

Suggested topics:

  • Ecosystem & Architectural review
  • Future kernel work - regions
  • QEMU support now and later
  • Security: IDE and SPDM
  • Avoiding vendor specificity
  • Collaboration on Future Spec enhancements
  • Type 2 accelerator support (bias flip management)
  • Hot remove
  • RAS (GPF, AER, Poison handling )
  • 1.1 to 2.0 compatibility
  • topics currently under embargo (p2p)
  • Hot add policy daxctl

MC leads:

  • Ben Widawsky
  • Dan Williams

Confidential Computing MC

Last years inaugural Confidential Computing microconference brought together plumbers enabling secure execution features in hypervisors, firmware, Linux Kernel, over low-level user space up to container runtimes.

Good progress was made on a couple of topics, most outstanding here is the development of Linux guest support for Intel TDX and AMD SEV-SNP. The patch-sets for both are under intensive review and come close to be merged upstream.Android

The discussions in the microconference also helped to move other topics forward, such as support for unaccepted memory or deferred memory pinning for confidential guests.

But enabling Confidential Computing in the Linux ecosystem is an ongoing process, and there are still many problems to solve. The most important ones are:

  • Design and implementation of Intel TDX and AMD SEV-SNP host support
  • Linux kernel memory management changes for secure execution environments
  • Support of upcoming secure execution hardware extensions from ARM and RISC-V
  • Pre-launch and runtime attestation workflows
  • Interrupt security for AMD SEV-SNP
  • Debuggability and live migration of encrypted virtual machines
  • Proper testing of confidential computing support code

The Confidential Computing Microconference wants to bring together plumbers working on secure execution features to discuss these and other open problems.

MC lead:

  • Joerg Roedel

Containers and Checkpoint/Restore MC

The Containers and Checkpoint/Restore Microconference focuses on both userspace and kernel related work. The micro-conference targets the wider container ecosystem ideally with participants from all major container runtimes as well as init system developers.

Contributions to the micro-conference are expected to be problem statements, new use-cases, and feature proposals both in kernel- and userspace.

Containers topics:

  • User namespace improvements
  • System call interception
  • LSM improvements and LSM namespacing
  • CGroup2 transition, emulation and future extensions
  • Memory isolation

Checkpoint/restore topics:

  • CRIU and hardware security features
  • Restartable sequences (rseq()) support
  • Shadow stacks support
  • GPU support (and other directly accessed hardware)
  • Checkpoint/Restore standardization effort (driven by HPC)
  • Kubernetes support

MC Leads:

  • Adrian Reber
  • Christian Brauner
  • Mike Rapoport
  • Stéphane Graber

CPU Isolation

CPU Isolation can be considered as an holistic functionality that stems from a close combination of several kernel and userspace components working together to shield workloads with extreme latency or performance requirements from interruptions (also known as Operating System noise). An example of such type of workloads are DPDK (Data Plane Development Kit) use cases (Telco/5G) where even the shortest interruption (e.g., a few microseconds to service an IPI) can cause packet losses, eventually leading to exceeding QoS requirements.

Despite considerable improvements in the last few years towards implementing full CPU Isolation (nohz_full, rcu_nocb, isolcpus, etc.), a certain amount of issues remain to be addressed, as it is still relatively simple to highlight sources of OS noise just by running synthetic workloads mimicking polling (always running) type of application similar to the ones mentioned above.

Recently, Improvements and discussions about CPU isolation features have been made and discussed in LKML [1,2,3], and tools such as osnoise tracer and rtla osnoise [3,4] improved the CPU isolation analysis. Nevertheless, this is an ongoing process, and discussions are needed to speed up solutions for existing discussions and improve the existing tools and methods.

With this microconference we thus want to get together to discuss open problems, most notably: how to improve the identification of OS noise sources (expanding runtime tracing and/or code inspection tools), how to track them publicly (repo/DB) and how to tackle the sources of noise that have already been identified (e.g, [1,2,3]).

A non exhaustive list of potential topics is:

  • OS noise profiling (format and public DB for the community)
  • Tracing to detect OS noise: the rtla osnoise tracer and what it’s missing
  • TLB/icache flush deferral [1]
  • Extend cpuset v2 cpu partition feature to replace isolcpus kernel cmdline
  • rt-trace-bpf tool
  • Task isolation
  • smp_call_function API improvements

Potential attendees list:

Peter Zijlstra, Thomas Gleixner, Steven Rostedt, Juri Lelli, Daniel Bristot de Oliveira, Sebastian Andrzej Siewior, Valentin Schneider, Clark Williams, Paul E. McKenney, Paul Turner, Rik van Riel, Phil Auld, Waiman Long, Frederic Weisbecker, Nicolas Saenz Julienne, Marcelo Tosatti, Karl Rister, Andrew Theurer, Luis Claudio R. Gonçalves

References:
1 - https://lore.kernel.org/all/20210929151723.162004989@infradead.org/
2 - https://lore.kernel.org/lkml/20220315153132.717153751@fedora.localdomain/
3 - https://lore.kernel.org/lkml/20211103170512.2745765-1-nsaenzju@redhat.com/
4 - https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html
5 - https://www.kernel.org/doc/html/latest/tools/rtla/rtla-osnoise.html

MC leads:

  • Juri Lelli
  • Daniel Bristot de Oliveira

IoTs a 4-Letter Word

The IoT microconference is back for its fourth year and our Open Source HW / SW / FW communities are productizing Linux and Zephyr in ways that we have never seen before.

A lot has happened in the last year to discuss and bring forward:

Each of the above items were large efforts made by Linux centric communities actively pushing the bounds of what is possible in IoT.

Whether you are an apprentice or master, we welcome you to bring your plungers and join us for a deep dive into the pipework of Linux IoT!

MC Leads:

  • Christopher Friedt
  • Stefan Schmidt

Kernel Memory Management

Current problems of interest to kernel developers who focus on memory management:

  • Multi-generational LRU vs traditional LRU
  • Do we need three different slab allocators?
  • How far do we take the folio conversion?
  • Can we handle page pinning and page mapcount more effectively?
  • How can we effectively cache reflinked files?
  • Can we support 1GB pages other than through hugetlbfs?
  • How should we handle memory failures better?

More problems will undoubtedly present themselves before the start of the conference.

MC Leads:

  • Matthew Wilcox
  • Vlastimil Babka

Kernel Testing & Dependability

The Linux Plumbers 2022 Kernel Testing & Dependability track focuses on advancing the current state of testing of the Linux Kernel and its related infrastructure. The main purpose is to improve software quality and dependability for applications that require predictability and trust. We aim to create connections between folks working on similar projects, and help individual projects make progress.

This track is a merge of the Linux Plumbers 2021 Testing and Fuzzing and the Kernel Dependability and Assurance MC tracks into a single session. These two tracks have a lot of overlap in topics and attendees. A dependable kernel is the goal of testing it and combining the two tracks will promote collaboration between all the interested communities and people.
We ask that any topic discussions focus on issues/problems they are facing and possible alternatives to resolving them. The Microconference is open to all topics related to testing on Linux, not necessarily in the kernel space.

Potential testing and dependability topics:

  • KernelCI: Improving user experience and new web dashboard
    (https://github.com/kernelci/kernelci-project/discussions/28)
  • Growing KCIDB, integrating more sources (https://kernelci.org/docs/kcidb/)
  • Better sanitizers: KFENCE, improving KCSAN. (https://lwn.net/Articles/835367/)
  • Using Clang for better testing coverage: Now that the kernel fully supports building with clang, how can all that work be leveraged into using clang's features?
  • How to spread KUnit throughout the kernel?
  • Building and testing in-kernel Rust code.
  • Identify missing features that will provide assurance in safety critical systems.
  • Which test coverage infrastructures are most effective to provide evidence for kernel quality assurance? How should it be measured?
  • Explore ways to improve testing framework and tests in the kernel with a specific goal to increase traceability and code coverage.
  • Regression Testing for safety: Prioritize configurations and tests critical and important for quality and dependability.
  • Transitioning to test-driven kernel release cycles for mainline and stable: How to start relying on passing tests before releasing a new version?
  • Explore how do SBOMs figure into dependability?

Things accomplished from last year:

  • KCIDB is continuing to gather results from many test systems: KernelCI, Red Hat's CKI, syzbot, ARM, Gentoo, Linaro's TuxSuite etc. The current focus is on generating common email reports based on this data and dealing with known issues.
  • KFENCE was successfully merged. (https://lwn.net/Articles/835367/)
  • Clang: CFI, weeding out issues upstream, etc.
  • KUnit started acting as the standard for some drivers. (https://www.youtube.com/watch?v=78gioY7VYxc)
  • The Runtime Verification (RV) interface patch series
    (https://lore.kernel.org/linux-doc/cover.1621414942.git.bristot@redhat.com/) from Daniel Bristot de Oliveira is in review
  • ELISA Tools WG (hhttps://lists.elisa.tech/g/tool-investigation) as incorporated syzkaller
    in their testing workflow
    (https://elisa-builder-00.iol.unh.edu/syzkaller/reportid=34e8ccdc0c7fb916735e544ea99234de75455d32)

MC Leads:

  • Sasha Levin
  • Guillaume Tucker
  • Shuah Khan

linux/arch

Historically, the code in arch/ was developed for one architecture and then copied and adjusted by others. This created a lot of duplicated or almost duplicated code with subtle differences which prevents easy refactoring and consolidation.

The linux/arch microconference aims to bring architecture maintainers in one room to discuss how the code in arch/ can be improved, consolidated and generalized, at least where it makes sense.

The discussion at the previous linux/arch microconfernece in 2020 lead to updates in RISC-V kprobes implementation [1], removal of  DISCOTIGMEM memory model [2] and enablement of generic entry on s390 [3].

[1] https://git.kernel.org/torvalds/c/c22b0bcb1dd0
[2] https://git.kernel.org/torvalds/c/bb1c50d3967f
[3] https://git.kernel.org/torvalds/c/56e62a737028

The possible topics could be:

  • reducing code duplication and generalizing the common code in arch/
  • making headers in include/asm consistent
  • on-boarding more architectures to use common entry code
  • devicetree (unless they have their own microconf)
  • identifying old machine support that may be either still in
    active use vs only in hobbyist/retro-computing vs completely
    obsolete and broken

MC Leads:

  • Mike Rapoport
  • Arnd Bergmann

Open Printing 

OpenPrinting has been improving the way we print in Linux. Over the years we have changed many conventional ways of printing and scanning. Over the last few years we have been emphasizing on the fact that driverless print and scan has made life easier however this does not make us stop improving. Every day we are trying to design new ways of printing to make your printing and scanning experience better than that of today.

To make this a success, Linux Plumbers conference is helping us immensely. This will be our fourth year of participation at the Plumbers.

The wonderful discussion that we had last year has helped us achieve the following:

Restarted and organized development activity on CUPS:

Since Apple has abandoned the CUPS development and Michael Sweet and Till Kamppeter have moved the upstream home of CUPS to OpenPrinting, the accumulated bugs got fixed and development restarted. Following our discussion from the OpenPrinting MC in 2021 we have started a 2,4,x series, will start 2.5.x near the end of this year and 3.x near the end of 2023, where the latter is a new generation not using the obsolete PPD (PostScript Printer Description, we have PDF workflow for a decade now) files, splitting daemons in user daemon and printer-sharing server, … We also assigned release managers for each series, Zdenek Dohnal (Red Hat) for 2.4.x, Till Kamppeter for 2.5.x, and Michael Sweet for 3.x.

Coordinated and initiated work on Printer Setup Tool in the GNOME Control Center:

We also discussed on the 2021 MC how a printer setup tool for the New Architecture of pure IPP and now PPD-file-and-filter-based printer drivers any more should look like and this made the base for designing a new GNOME Control Center module which I am currently discussing with the Desktop Team and Design Team at Canonical for an implementation which is intended to submit to GNOME upstream. Coding is also carried out partially in Google Summer of Code projects.

All free software printer drivers available as Printer Applications now:

For the New Architecture for printing and scanning using pure IPP and not classic CUPS and SANE drivers any more we need a way to keep the non-driverless printers working and the solution are the Printer Applications, software emulations of driverless IPP printers which on their back end pass the jobs on to the physical printer and internally they convert incoming PDF or Raster into the printer's native format. We have discussed concept and design on all our three MCs from 2019 to 2021 and with this Michael Sweet created Printer Application framework PAPPL and Till Kamppeter made use of it to retro-fit all free software classic printer drivers which are available for Debian Linux into 4 retro-fitting Printer Application Snaps in the Snap Store. This way it is assured that printers which currently work do not lose support and so we can smoothly switch over to the New Architecture.

Planned further development for scanning support in PAPPL:

To support multi-function devices containing a printer and a scanner but also for general scanner support which works with sandboxed, distribution-independent packaging we are extending the concept of Printer Applications to also provide scan services via IPP Scan or eSCL. For this we want to add scanning support to PAPPL.

Based on Bhavna Kosta's GSoC work to start the scanning support in PAPPL we have discussed the further development and divided up the work to propose it as GSoC projects so that we can get the project completed this year.

Proposed Topics :

CUPS 2.5 and 3.0 Development (90 Mins)
Speaker: Michael Sweet
Topic Details: In this session we will first finalize the features and the roadmap for CUPS 2.5, especially finalize how we will support OAuth here, but also which further containerization/sandboxing/distribution-independent packaging systems we will explicitly support besides Snap, Docker for example. Then, most importantly, we will discuss the details of the CUPS 3.0 architecture, user daemon, printer-sharing daemon, how to integrate cups-filters, …
Link: https://github.com/OpenPrinting/cups

3D Printing (45 Mins)
Speakers: Till Kamppeter, Michael Sweet, TBD
Topic Details: 3D printing gets more and more popular, not only in the industry but also in the DIYer's garages. Especially for consumers but also for professional users it would be great to have an easy workflow, so that 3D printing "just works" like conventional 2D printing. Somehow one could think about clicking "Print" in the 3D design/CAD/CAM software and the object gets printed. As we already have CUPS filters for 2D printing data formats get converted to get the 3D printer's native language in the end. Also we need some standard format for the applications to send, like as we have PDF for 2D printing. We will discuss here how such a 3D printing workflow could look like.

Testing and CI for OpenPrinting projects (45 Mins)
Speakers: Till Kamppeter, TBD
Topic Details: cups-filters (and also other projects on OpenPrinting) get larger and more and more complex with the time. It is always harder to overview the code and to predict the exact effects of a change, adding a feature or fixing a bug one can easily cause a regression. One tests the code but has one really tested all types of input, all settings, … As human beings easily forget we need some automated testing, useful things being done when running "make check", and tests being triggered on each GIT commit. Here we will discuss strategies of automatic testing. We will also take CUPS' testing as an example and see whether we can proceed similarly on cups-filters.
Link: https://github.com/OpenPrinting/ , https://github.com/OpenPrinting/cups

Documentation for OpenPrinting projects (30 Mins)
Speakers: Till Kamppeter, TBD
Topic Details: Good documentation is something neglected a lot in the free software world. One is driving the coding of certain projects quickly forward to get something which actually works and one can try it out. One wants to get one's new library finally released. But how should people know how to use it? Documentation! CUPS is well documented, but cups-filters (and pappl-retrofit) lack API documentation. Also the user documentation on the sites of distributions like Debian or SUSE are often much better than our upstream documentation. Here we will discuss how to solve this. API documentation generators for libraries? Upstreamizing documentation from distros to OpenPrinting? …?
Link: http://www.openprinting.org/, https://github.com/OpenPrinting/openprinting.github.io

Sandboxing/Containerizing alternatives to Snap for Printer Applications or CUPS (30 Mins)
Speaker Name: Till Kamppeter
Topic Details: There are Snaps of CUPS and 5 Printer Applications, but Snap has also disadvantages, most prominently the one-and-only Snap Store. Are there alternatives to create distribution-independent packages, especially of Printer Applications? Docker? Flatpak? AppImage? …?
Link: https://github.com/OpenPrinting/ , https://openprinting.github.io/OpenPrinting-News-March-2022/#flatpak-and-printing

Participants who have confirmed they plan to attend:

  • Till Kamppeter
  • Aveek Basu
  • Jeff Licquia
  • Kate Stewart
  • Michael Sweet
  • Ira McDonald
  • Dhiraj Yadav
  • Sahil Arora
  • Jai Luthra
  • Sambhav Dusad
  • Lakshay Bandlish
  • Mohit Mohan
  • Vikrant Malik
  • Rithvik Patibandla
  • Deepak Patankar
  • Zdenek Dohnal

MC Leads:

  • Aveek Basu
  • Till Kamppeter

Power Management and Thermal Control

The Power Management and Thermal Control microconference focuses on frameworks related to power management and thermal control, CPU and device power-management mechanisms, and thermal-control methods. In particular, we are interested in extending the energy-efficient scheduling concept beyond the energy-aware scheduling (EAS), improving the thermal control framework in the kernel to cover more use cases and making system-wide suspend (and power management in general) more robust.

The goal is to facilitate cross-framework and cross-platform discussions that can help improve energy-awareness and thermal control in Linux.

Suggested topics:

  • Energy-efficient scheduling beyond EAS (Len Brown).
  • Per-CPU idle injection from user space for thermal control (Srinivas Pandruvada).
  • A generic energy model description (Daniel Lezcano).
  • Extending the DTPM framework by adding more supported devices to it (Daniel Lezcano).
  • Thermal control core code improvements (Daniel Lezcano, Rafael Wysocki).
  • Combining DTPM with the thermal control framework (Daniel Lezcano).
  • Generic DVFS support for SCMI-based platforms (Ulf Hansson).
  • Improving the genpd governor for CPUs (Ulf Hansson).
  • More integration between PM-runtime and system-wide PM (Rafael Wysocki).

More topics will be added based on CfP for this microconference.

MC Lead:

  • Rafael Wysocki

Real-time Microconference

Since 2004, the project that has become known as PREEMPT_RT, formally the real-time patch, has improved the real-time and low-latency features of the Linux kernel. Over the past decade, many parts of PREEMPT_RT have been included into the official Linux codebase. Examples include: mutexes, high-resolution timers, lockdep, ftrace, RT scheduling, SCHED_DEADLINE, RCU_PREEMPT, generic interrupts, priority inheritance futexes, threaded interrupt handlers, and more. The number of patches that need integration has been significantly reduced, and the rest is mature enough to make their way into mainline Linux.

The following accomplishments have been made as a result of last year’s microconference:

  • The Real-time Linux Analysis tool was merged in 5.17
  • Progress on tools to facilitate maintenance of the stable RT releases.
  • Progress on the full mainline merge, but some challenges were raised and more is to be done.

This year’s topics to be discussed include:

  • How to scale PREEMPT_RT for very-large systems
  • Improve overall system partitioning for real-time HPC workloads
  • New tools for PREEMPT_RT analysis.
  • How do we teach the rest of the kernel developers how not to break PREEMPT_RT?
  • Stable maintainers tools discussion & improvements.
  • The usage of PREEMPT_RT on safety-critical systems: what do we need to do?
  • How do we close the documentation gap
  • The status of the merge, and how can we resolve the last issues that block the merge.
  • How can we improve the testing of the -rt, to follow the problems raised as the Linus tree advances?
  • What’s next?

MC Leads:

  • Daniel Bristot de Oliveira
  • Steven Rostedt
  • Kate Stewart

RISC-V Microconference

Possible topics for discussion include:

  • Various specification updates and plans for supporting them, with candidates including SBI, EFI, memory models (WMO, IO, etc), IOMMU, TEE
  • How we're going to handle user visible errata, with the most notable current example being the D1.
  • How to move froward with support for the V extension, including probing from userspace (VLENMAX, performance, etc)
  • How we're going to handle runtime probing of various performance knobs in the kernel, like strings.h and locks.
  • What, if any, rules we're going to have for portable/distro kernels.

Highlights from last year include:

  • KVM!

MC Leads:

  • Palmer Dabbelt
  • Atish Patra

Service Management and Systemd Microconference

The focus of this microconference will be on topics related to the current state of host-level service management and ideas for the future.

As systemd is one of the most widely adopted service managers in Linux distributions today, we expect that most of the contributions will be based around the systemd ecosystem. We're also welcome to proposals that are not specific to systemd so we can discover and share new ideas on how to improve service management in general.

MC Lead:

  • Anita Zhang

System Boot and Security

In the fourth year in a row, we are going to bring together people interested in the
firmware, bootloaders, system boot, security, etc., and discuss all these topics
during the System Boot and Security microconference. This year we would like to focus on better communication and closer cooperation between Free Software and Open Source projects which are building blocks of Free OSes. Past months and even years showed us that the lack of one or both very often delays introduction of very interesting and important features. A good example is the TrenchBoot project. Lack of or sporadic communication and cooperation between the TrenchBoot project and Linux kernel developers made it difficult to understand each other's requirements and needs. This has resulted in the TrenchBoot project being stuck in limbo. This situation is improving due to the interactions from last year’s System Boot and Security MC, but there are still areas for improvement. As such we think the System Boot and Security MC is a good place to discuss technical and organizational problems which may happen due to not ideal communication and cooperation. Though we do not limit this MC to this kind of problems and want to encourage all stakeholders to bring and discuss issues that they are encountering in broadly understood system boot and security.

Below is the list of topics that would be nice to cover. This is not exhaustive and can be extended if needed.

Expected topics:

  • TPMs, HSMs, secure elements
  • https://trustedcomputinggroup.org/work-groups/pc-client/
  • Roots of Trust: SRTM and DRTM
  • https://trustedcomputinggroup.org/resource/d-rtm-architecture-specification/
  • Intel TXT, SGX, TDX
  • https://software.intel.com/content/www/us/en/develop/articles/intel-sdm.html
  • https://ww.intel.com/content/www/us/en/software-developers/intel-txt-software-development-
  • guide.html
  • https://software.intel.com/content/dam/develop/external/us/en/documents/intel-tdx-module-1eas.pdf
  • AMD SKINIT, SEV,
  • https://www.amd.com/system/files/TechDocs/24593.pdf
  • ARM DRTM
  • Growing Attestation ecosystem,
  • IMA,
  • https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture
  • TrenchBoot, tboot,
  • https://github.com/TrenchBoot
  • https://sourceforge.net/projects/tboot/
  • UEFI, coreboot, U-Boot, LinuxBoot, hostboot,
  • Measured Boot, Verified Boot, UEFI Secure Boot, UEFI Secure Boot Advanced Targeting (SBAT),
  • shim,
  • https://github.com/rhboot/shim
  • boot loaders: GRUB2, SeaBIOS, network boot, PXE, iPXE,
  • u-root,
  • OpenBMC, u-bmc,
  • https://github.com/openbmc/openbmc
  • https://github.com/u-root/u-bmc
  • legal, organizational and other similar issues relevant for
  • people interested in system boot and security.

If you are interested in participating in this microconference and have topics
to propose, please use the CFP process.

MC Leads:

  • Daniel Kiper
  • Michał Żygowski
  • Matthew Garrett
  • Piotr Król

VFIO/IOMMU/PCI

The PCI interconnect specification, the devices that implement it, and the system IOMMUs that provide memory and access control to them are nowadays a de-facto standard for connecting high-speed components, incorporating more and more features such as:

These features are aimed at high-performance systems, server and desktop computing, embedded and SoC platforms, virtualization, and ubiquitous IoT devices.

The kernel code that enables these new system features focuses on coordination between the PCI devices, the IOMMUs they are connected to and the VFIO layer used to manage them (for userspace access and device passthrough) with related kernel interfaces and userspace APIs to be designed in-sync and in a clean way for all three sub-systems.

The VFIO/IOMMU/PCI micro-conference focuses on the kernel code that enables these new system features that often require coordination between the VFIO, IOMMU and PCI sub-systems.

Following up the successful LPC 2017, 2019, 2020 and 2021 VFIO/IOMMU/PCI micro-conference, the Linux Plumbers Conference 2022 VFIO/IOMMU/PCI track will therefore focus on promoting discussions on the current kernel patches aimed at VFIO/IOMMU/PCI sub-systems with specific sessions targeting discussion for the kernel patches that enable technology (e.g., device/sub-device assignment, PCI core, IOMMU virtualization, VFIO updates, DMA ownership models, Trusted Computing, etc.) requiring the three sub-systems coordination. The micro-conference will also cover VFIO/IOMMU/PCI sub-system specific tracks to debate the status of patches for the respective sub-systems.

See the following video recordings from LPC 2019, 2021 and 2022 VFIO/IOMMU/PCI micro-conference:

And the archived LPC 2017 VFIO/IOMMU/PCI micro-conference web page at Linux Plumbers Conference 2017, where the audio recordings from the micro-conference track and links to presentation materials are available.

The tentative schedule will provide an update on the current state of VFIO/IOMMU/PCI kernel sub-systems followed by a discussion of current issues in the proposed topics.

The following was a result of last years successful Linux Plumbers micro-conference:

  • Support for the /dev/iommufd device has been discussed and then later refined moving it closer to the final design before implementation work would start

  • The groundwork for refactoring the Shared Virtual Address (SVA) and I/O Page Fault (IOPF) support in IOMMU has been laid out readying it for future inclusion in the mainline kernel

  • The SVA for in-kernel users support has taken a completely different direction following a discussion that was held concerning the proposed implementation (for instance, the KVA approach has since been retired). A new effort is to converge on the DMA API offering support through a set of possible extensions to it, however, the work is still ongoing and the final solution is yet to be decided upon

  • A framework for managing group DMA ownership and removal of the BUG_ON in VFIO is now ready to be merged into the mainline kernel

  • A series of enhancements for extending IOMMU domain to support more I/O Page Table types have been included in the mainline kernel

  • The work to bring support for the Compute Express Link (CXL) in the Linux kernel is ongoing and it has been widely reviewed and debated, especially concerning Data Object Exchange (DOE), Component Measurement and Authentication (CMA) and Security Protocol and Data Model (SPDM) support is under heavy development. A lot of work has been put into resolving and addressing issues around the implementation, however, it will take many kernel releases before the CXL support is refined to the point where it would be considered stable to use, nonetheless good progress has been achieved thus far

Tentative topics that are under consideration for this year include (but not limited to):

  • PCI
  • Cache Coherent Interconnect for Accelerators (CCIX)/Compute Express Link (CXL) expansion memory and accelerators management
  • Data Object Exchange (DOE)
  • Integrity and Data Encryption (IDE)
  • Component Measurement and Authentication (CMA)
  • Security Protocol and Data Model (SPDM)
  • I/O Address Space ID Allocator (IOASID)
  • INTX/MSI IRQ domain consolidation
  • Gen-Z interconnect fabric
  • ARM64 architecture and hardware
  • PCI native host controllers/endpoints drivers current challenges and improvements (e.g., state of PCI quirks, etc.)
  • PCI error handling and management e.g., Advanced Error Reporting (AER), Downstream Port Containment (DPC), ACPI Platform Error Interface (APEI) and Error Disconnect Recover (EDR)
  • Power management and devices supporting Active-state Power Management (ASPM)
  • Peer-to-Peer DMA (P2PDMA)
  • Resources claiming/assignment consolidation
  • Probing of native PCIe controllers and general reset implementation
  • Prefetchable vs non-prefetchable BAR address mappings
  • Untrusted/external devices management
  • DMA ownership models
  • Thunderbolt, DMA, RDMA and USB4 security

  • VFIO

  • Write-combine on non-x86 architectures
  • I/O Page Fault (IOPF) for passthrough devices
  • Shared Virtual Addressing (SVA) interface
  • Single-root I/O Virtualization(SRIOV)/Process Address Space ID (PASID) integration
  • PASID in SRIOV virtual functions
  • Device assignment/sub-assignment

  • IOMMU

  • /dev/iommufd development
  • IOMMU virtualization
  • IOMMU drivers SVA interface
  • DMA-API layer interactions and the move towards generic dma-ops for IOMMU drivers
  • Possible IOMMU core changes (e.g., better integration with device-driver core, etc.)

If you are interested in participating in this micro-conference and have topics to propose, please use the Call for Proposals (CfP) process. More topics will be added based on CfP for this micro-conference.

Come and join us in the discussion in helping Linux keep up with the new features being added to the PCI interconnect specification.

We hope to see you there!

Key Attendees:

  • Alex Williamson
  • Arnd Bergmann
  • Ashok Raj
  • Benjamin Herrenschmidt
  • Bjorn Helgaas
  • Dan Williams
  • Eric Auger
  • Jacob Pan
  • Jason Gunthorpe
  • Jean-Philippe Brucker
  • Jonathan Cameron
  • Jörg Rödel
  • Kevin Tian
  • Lorenzo Pieralisi
  • Lu Baolu
  • Marc Zyngier
  • Pali Rohár
  • Peter Zijlstra
  • Thomas Gleixner

MC Leads:

  • Alex Williamson
  • Bjorn Helgaas
  • Jörg Roedel
  • Lorenzo Pieralisi
  • Krzysztof Wilczyński

Zoned Storage Devices (SMR HDDs & ZNS SSDs)

The Zoned Storage interface has been introduced to make more efficient use of the storage medium, improving both device raw capacity and performance. Initially implemented for Shingled magnetic recording (SMR) HDDs, and recently also for flash-based SSDs through Zoned Namespace (ZNS) SSDs. Zoned storage devices expose their storage through zone semantics. Each zone has a set of read/write rules associated. One example is requiring zones to be written sequentially, which requires the host to be aware of such requirements.

The Linux kernel has had a general zoned subsystem for SMR HDDs since kernel 4.10 and gained support for ZNS SSDs in kernel 5.9. Furthermore, to help faster adoption of Zoned Storage devices, a few parts of the storage stack has been extended with zone support. Examples are filesystems such btrfs and f2fs, and the device mapper targets dm-linear and dm-zoned. This all eases the barrier to adoption.

The Zoned Storage micro-conference is to communicate the benefits of Zoned Storage to a broader audience, present the current and future challenges within the Linux storage stack, and collaborate with the wider community.

MC Leads:

  • Luis Chamberlain
  • Adam Manzanares
  • Matias Bjørling