Add a user-configurable option to control whether VFIO device MMIO BAR
regions are DMA-mapped into the host IOMMU address space.
This mapping is required for peer-to-peer DMA between devices (e.g.
NVLink, RDMA NIC accessing GPU VRAM). However, iommufd on upstream
kernels does not support mapping device MMIO pages (VM_PFNMAP), causing
IOMMU_IOAS_MAP to fail with -EFAULT. Kernels with the NVIDIA PFNMAP
workaround or future kernels with DMABUF-based mapping
(IOMMU_IOAS_MAP_FILE) handle this correctly.
The option defaults to `on` to preserve existing behavior. Users on
vanilla kernels using iommufd should set `vfio_p2p_dma=off` to skip
MMIO BAR DMA mapping.
A validation check ensures that `x_nv_gpudirect_clique` (which depends
on P2P DMA) cannot be used when `vfio_p2p_dma=off`.
Signed-off-by: Bo Chen <bchen@crusoe.ai>
When `--platform iommufd=on` is set, use the vfio cdev interface backed
by iommufd instead of the legacy vfio container/group interface for
device passthrough.
The cdev path opens '/dev/iommu' via IommuFd, allocates an IOAS, and
binds VFIO devices through VfioIommufd. The legacy container/group path
remains the default and is used when iommufd is not enabled.
Add iommufd-ioctls as a workspace dependency and enable the "vfio_cdev"
feature on vfio-ioctls for KVM builds.
Fixes: #6892
Signed-off-by: Bo Chen <bchen@crusoe.ai>
This option allows user to configure VFIO device pass-through with
iommufd (e.g. vfio cdev mode) or not (e.g. vfio legacy mode).
Signed-off-by: Bo Chen <bchen@crusoe.ai>
The `--platform` help string was hardcoded and did not reflect which
optional features (tdx, sev_snp) were actually enabled in. Build the
syntax string dynamically as `PlatformConfig::syntax()`, conditionally
appending feature-gated options so the CLI help stays accurate.
Signed-off-by: Bo Chen <bchen@crusoe.ai>
A 4M uefi_region is allocated unconditionally. When directly booting a
kernel, it goes unused. Avoid the allocation in this case by moving the
call to add_uefi_flash() to load_firmware().
Also extended add_uefi_flash() to riscv64 since it shares the
load_firmware() path. It looked like up to this point a firmware boot on
riscv64 would panic with an uninitialized uefi_flash.
Signed-off-by: JP Kobryn <inwardvessel@gmail.com>
It is desirable to be able to track the progress of memory hotplug.
Update the memory_actual_size field to query the current plugged size
from virtio-mem to enable this.
Signed-off-by: Jared White <git@jaredwhite.dev>
This gate behaves like a barrier, but it can be opened, meaning that
threads can be released before all threads arrived at the gate. This
lets us release waiting threads in case of an error, which will be
important for the sender side of a live migration with multiple
TCP connections.
On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
Adds the functionality to accept multiple connections on the receiver
side of a live migration. A thread listens for incoming connections and
creates a worker for each new connection.
On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
With this, the receiver side of a migration can wait for incoming
connections, while also being able to abort the accept when the
migration is done.
On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
That way we avoid having to grab a lock when receiving a chunk of memory
over the migration socket. This is a necessary prerequisite for having
multiple memory receiving threads.
On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
The memory manager is guarded by a mutex, thus parallel accesses to it
and its members are not possible. But we have to execute this function
in parallel when we introduce multiple TCP connections. Otherwise, the
workers who receive the data and write it into guest memory will block
on each other, and thus slow down the migration.
Also rename the function to receive_memory_ranges for better naming
consistency.
On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
When doing a local migration using a UNIX socket, we removed the UNIX
socket file after accepting the connection. The VMM does not own this
socket file, which makes this an unsafe operation. Thus, we stop doing
that.
On-behalf-of: SAP sebastian.eydam@sap.com
Signed-off-by: Sebastian Eydam <sebastian.eydam@cyberus-technology.de>
Refactor PciDevice::allocate_bars trait and all implementations
to take &mut SystemAllocator instead of &Arc<Mutex<SystemAllocator>>,
removing double indirection.
The caller in device_manager.rs now acquires the lock before
calling allocate_bars.
Signed-off-by: Chinmoy <daschinmoyy21@gmail.com>
Remove the old async_io::DiskFile trait implementation from
RawFileDiskAio, now that the new disk_file trait hierarchy
is fully implemented.
Clean up unused imports: DiskFile and DiskFileResult from
crate::async_io.
Signed-off-by: Muminul Islam <muislam@microsoft.com>
Previously, GSIs were eagerly allocated for all MSI-X vectors a device
advertises (i.e. the maximum the device can support). This can easily
exhaust KVM_MAX_IRQ_ROUTES (4096) with modern NVMe devices that support
up to 2048 MSI-X vectors.
Defer GSI allocation to the first time an interrupt vector is
unmasked. The EventFd is still created eagerly since external
components (e.g. VFIO) need it at device init time.
Signed-off-by: Bo Chen <bchen@crusoe.ai>
Previously, KVM_KVMCLOCK_CTRL was skipped when kvm_hyperv=on because
Windows does not use pvclock directly. However, KVM internally uses
pvclock data structures as the basis for computing the Hyper-V
Reference TSC page parameters. Not calling KVM_KVMCLOCK_CTRL means
there is no mechanism to signal time discontinuity to Windows guests
after pause/resume, contributing to multi-minute hangs.
Remove the kvm_hyperv guard so all guests receive the clock-paused
notification.
Signed-off-by: CMGS <ilskdw@gmail.com>
Reorder resume() to: set_clock, device_manager.resume,
cpu_manager.resume. This matches the inverse of pause()
which correctly saves the clock before pausing vCPUs.
Signed-off-by: CMGS <ilskdw@gmail.com>
Classify the io::Error as BlockErrorKind::Io with ErrorOp::Open.
Update vmm CreateFixedVhdDiskSync to take BlockError.
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
Update device_manager.rs to construct DiskBackend::Next
instead of DiskBackend::Legacy for the synchronous raw
backend.
Signed-off-by: Muminul Islam <muislam@microsoft.com>
Update device_manager.rs to construct DiskBackend::Next
instead of DiskBackend::Legacy for the io_uring raw backend.
Signed-off-by: Muminul Islam <muislam@microsoft.com>
Fix broken URL reported by Lychee. The binutils-gdb github repo no
longer exists. Use the equivalent sourceware.org link.
Signed-off-by: Anirudh Rayabharam <anrayabh@microsoft.com>
When landlock support was added, creation of file descriptors was
moved out into a function called pre_create_console_devices, with the
idea being that this could be run before Landlock rules are applied
and access to all the necessary paths are dropped.
This idea didn't take reboots into account, though. When a VM is
rebooted, pre_create_console_devices is called again, but now the
Landlock rules have been applied, so they need to allow access to all
those paths anyway.
I imagine the way this was intended to work was that file descriptors
would be preserved across reboot, but that's not currently the case,
and it's not a trivial change to make because they get dropped when
the VM is destroyed. Longer term it would be ideal if Cloud
Hypervisor's implementation was more focused on file descriptors than
paths[1], and if created VMs only took references to file descriptors,
so they were easily preserved across reboots.
Fixes: b3e5738b4 ("vmm: Introduce ApplyLandlock trait")
Closes: https://github.com/cloud-hypervisor/cloud-hypervisor/issues/7547
Link: https://github.com/cloud-hypervisor/cloud-hypervisor/issues/7704 [1]
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Add BLKGETSIZE64 0x80081272 to the VMM seccomp ioctl allow list
alongside the existing BLK* ioctls. This is needed for querying
block device size without seeking.
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
Following the `VfioContainer` to `VfioOps` trait switch, update the
remaining field names, method names, comments, and log messages to use
`vfio_ops` and "host IOMMU address space" consistently.
No fucntional changes.
Signed-off-by: Bo Chen <bchen@crusoe.ai>
Replace the concrete `VfioContainer` type with the `VfioOps` trait
object for device passthrough. This decouples the VFIO DMA mapping
interface from the legacy VFIO container/group implementation, allowing
it to be extended to support VFIO cdev and iommufd in the future.
Signed-off-by: Bo Chen <bchen@crusoe.ai>
The actual size of the balloon is taken directly from the guest. A
misbehaving guest can set it to an arbitrary value and cause underflow
on the next vm.info call. Use a saturation_sub instead to avoid a panic
in a debug build or a crazy number in a release build.
Signed-off-by: Dylan Reid <dgreid@dylanreid.com>
As far as I can tell, PIDTYPE_PID is a kernel-internal name, and
PR_SCHED_CORE_SCOPE_THREAD is the UAPI name. There's no PIDTYPE_PID
in the UAPI headers, and the core scheduling documentation says that
the fourth prctl argument should be a "PR_SCHED_CORE_SCOPE_-prefixed
macro constant".
Link: https://www.kernel.org/doc/html/v6.19/admin-guide/hw-vuln/core-scheduling.html#usage
Fixes: 3f800d2bb ("vmm: Add core scheduling support for vCPU threads")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
