Passthrough
Paravirtualised devices are shared, portable, and under MX's control. Passthrough is the other trade: the guest gets the real hardware, the host loses it for a while, and an IOMMU has to stand between that hardware's DMA and everyone else's memory.
MX Studio exposes three related surfaces: USB assignment, PCIe assignment, and an IOMMU policy.
What the real device means
A virtio-net or MX GPU device is a model. The guest driver is written for that model. A passthrough device is the physical function. The guest loads the vendor driver. Features, firmware, and bugs are the device's, not MX's.
That is the appeal for a Windows GPU, a capture card, a hardware security key, or a radio the guest's own stack already knows. It is also why passthrough is exclusive. The host cannot keep using a function that now belongs to the guest.
USB
USB passthrough assigns a host device by vendor, product, and location. The guest sees a USB device on its virtual controller and talks to it with its ordinary stack.
Not every assignment is native. Studio marks a device native, wrapper required, or unsupported. A wrapper means MX still has to translate the host's idea of the device into something the guest controller can present. Unsupported means this host cannot assign it; if a VM already has one configured, the Devices page keeps the row so you can remove it, rather than hiding a device that would block boot.
Unplug the physical device and the assignment goes stale. The VM does not grow a new function to replace it.
PCIe
PCIe passthrough assigns a host function by bus, device, and function number. The guest sees that BDF as a PCI device. This is the path people mean when they say GPU passthrough.
The same wrapper badge applies. Some functions can be handed through. Some need MX to keep a model in front of them. Some are rejected on this host, with a reason, and cannot be added.
Once a function is assigned, it is gone from the host for the life of that assignment. Displays, boot GPUs, and the IOMMU itself are the functions people assign by accident.
Why the IOMMU is not optional
A passthrough device bus-masters. It writes physical addresses the guest programmed. Without an IOMMU those addresses are host physical addresses. The guest could point the device at host kernel memory.
MX exposes an IOMMU setting on the VM. Passthrough of a DMA-capable PCIe device wants it on. The IOMMU translates the device's DMA into the guest's assigned frames and faults the rest.
The guest's own board model may already include an IOMMU. That is part of the machine, not the same thing as assigning a host GPU into the VM.
When passthrough is the wrong tool
Use a hardware wrapper or virtio when the guest just needs a disk, a NIC, or a display. Those scale to many VMs, migrate, snapshot cleanly, and leave the host's devices alone.
Use MX GPU or virtio-gpu when the guest needs accelerated graphics but not a particular physical GPU.
Use passthrough when the guest's vendor driver and the physical function are the requirement, you can dedicate that function, and the IOMMU policy is on. The rest of the machine (CPU, timers, firmware, the devices you did not assign) still goes through MX. Passthrough is a device, not an escape hatch from the hypervisor.