Christian Brauner
1d0a8e5dbd
This is the bulk of the runtime block-device hotplug feature. The
boot-time qmp_setup_regular_drive() path is rewritten on top of a new
vmspawn_qmp_add_block_device() that owns the DriveInfo, drives a four
QMP-command pipeline (add-fd → blockdev-add → remove-fd → device_add)
through staged ref-counted callbacks, and registers the drive in a
per-bridge block-device registry on success.
New on the bridge:
- block_devices: user-id → DriveInfo* registry (owned ref).
- hotplug_port_owner[VMSPAWN_PCIE_HOTPLUG_SPARES]: per-port owner
string for the spare pcie-root-ports, allocated/released through
vmspawn_qmp_bridge_{allocate,release_pcie_port_by_idx}().
- scsi_controller_port_idx / scsi_controller_created: track the
on-demand virtio-scsi-pci controller so the first SCSI hotplug
creates it (against an allocated spare port) and subsequent ones
just attach.
- next_block_counter: already in place from the previous commit, now
actually consumed by add_block_device().
New on DriveInfo:
- bridge (weak), id (varlink-visible — caller-supplied or auto-set
to qmp_device_id), disk_type (for List replies later), counter,
qmp_node_name / qmp_device_id (already added), fdset_path,
pcie_port_idx (the hotplug port reserved by this drive — stays
set across the add pipeline so drive_info_free releases it when
the registry ref drops at DEVICE_DELETED time),
rollback_mask (BlockDeviceAddStage bits of completed stages —
plus a FAILED sentinel that suppresses cascading errors), and
link (NULL ⇒ boot-time, sd_event_exit on fail; non-NULL ⇒
hotplug, varlink reply on fail).
Helpers:
- drive_info_unref() now releases any reserved hotplug port through
the bridge and unrefs link.
- drive_info_add_fail(): single failure entry point — fires the
teardown for completed stages, sets the FAILED bit, and sends
either the varlink error or sd_event_exit. Boot-time failures
(link == NULL) always exit the loop, so late-arriving ephemeral
continuation replies don't get silenced after cont.
- vmspawn_qmp_block_device_teardown(): post-hoc blockdev-del when
blockdev-add succeeded but a later stage failed.
- reply_qmp_error: varlink reply helper — disconnect errors map to
io.systemd.MachineInstance.NotConnected, everything else goes
through sd_varlink_error_errno.
- on_add_observe_stage / on_add_blockdev_stage /
on_add_device_add_complete: the staged callbacks that drive the
add pipeline, each holding one slot ref on the DriveInfo. The
ephemeral blockdev-create continuation reuses the latter two so
its post-cont replies go through drive_info_add_fail instead of
the generic on_qmp_complete (which would silently log under
setup_done).
- on_scsi_controller_complete: handles the SCSI controller setup
(releases the reserved port on failure, propagates the boot-time
fatal error policy).
- qmp_build_blockdev_add_inline(): single blockdev-add JSON that
creates the file+format pair as one node, used by the hotplug
path (the boot-time helpers stay separate so they can stack with
the ephemeral path's base/overlay format nodes).
EphemeralDriveCtx is trimmed down to a DriveInfo ref plus the two
ephemeral-local scratch node names (overlay-file, base-fmt). The
copies of disk_driver/serial/pcie_port/flags/qmp_node_name/
qmp_device_id go away — the continuation reads them straight off the
ref'd drive. qmp_setup_ephemeral_drive now sets drive->bridge /
drive->id / drive->counter up front (matching the hotplug path) and
folds the feature-dependent DISCARD_NO_UNREF into drive->flags so
qmp_build_blockdev_add_format picks it up.
vmspawn_qmp_bridge_free() unrefs the qmp client first — its pending
callbacks may still reach for the bridge's hotplug port table when
they drop their last DriveInfo ref — then tears down the hashmaps
and the port owner strings.
The boot-time qmp_setup_regular_drive() collapses to a thin wrapper
that asserts "caller hasn't pre-set drive->id", takes ownership and
calls vmspawn_qmp_add_block_device(); the dispatcher in
vmspawn_qmp_setup_drives() now hands ownership over with TAKE_PTR.
The previous qmp_setup_drive() dispatcher disappears (its body is
inlined into the loop). vmspawn_qmp_init() initialises
scsi_controller_port_idx to -1.
The cosmetic (*d) → DriveInfo *drive = *d; locals in
drives_need_scsi_controller (vmspawn-qmp.c) and assign_pcie_ports
(vmspawn.c) ride along — they live in code touched by this commit
and would otherwise produce churn.
vmspawn_qmp_remove_block_device() — the symmetric remove API — is
added in the next commit so this one stays focused on the add path.
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release