<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Passthrough on Damien Dye&#39;s Blog</title>
    <link>https://blogs.damiendye.uk/en/tags/passthrough/</link>
    <description>Recent content in Passthrough on Damien Dye&#39;s Blog</description>
    <generator>Hugo</generator>
    <language>en-GB</language>
    <lastBuildDate>Fri, 07 Aug 2026 17:00:00 +0100</lastBuildDate>
    <atom:link href="https://blogs.damiendye.uk/en/tags/passthrough/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Licence-Free Windows VDI on Proxmox with an Intel Arc Pro B50 — and the Firmware Limit That Stopped It</title>
      <link>https://blogs.damiendye.uk/en/proxmox/licence-free-vdi-intel-arc-pro-sriov/</link>
      <pubDate>Fri, 07 Aug 2026 17:00:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/licence-free-vdi-intel-arc-pro-sriov/</guid>
      <description>Intel&amp;#39;s Arc Pro cards do SR-IOV natively, with no vGPU licence to buy — which makes a licence-free Windows VDI on Proxmox genuinely possible. The whole build on a B50, the Windows-first bootstrap problem, why the firmware caps it at two virtual functions, and how many each card in the B-series gives you.</description>
    </item>
    <item>
      <title>Two Boot Lines — Which Kernel Flags Belong on a Proxmox Host, and Which Belong in the Guest</title>
      <link>https://blogs.damiendye.uk/en/proxmox/kernel-boot-flags-host-guest/</link>
      <pubDate>Fri, 07 Aug 2026 15:00:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/kernel-boot-flags-host-guest/</guid>
      <description>Most Proxmox tuning lines you find online are one blob of kernel flags. Half of them belong on the hypervisor, half belong inside the guest, two of the popular ones do nothing at all, and a few change meaning depending on which side of the boundary they land.</description>
    </item>
    <item>
      <title>PCIe Passthrough Performance on Proxmox VE — The IOMMU Tax and How to Minimise It</title>
      <link>https://blogs.damiendye.uk/en/proxmox/pcie-passthrough-performance-the-iommu-tax/</link>
      <pubDate>Fri, 07 Aug 2026 10:00:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/pcie-passthrough-performance-the-iommu-tax/</guid>
      <description>Why PCIe devices lose throughput when passed through to a VM via VFIO, and the practical tuning steps that claw most of it back.</description>
    </item>
    <item>
      <title>NUMA Alignment on Proxmox VE — Why It Matters and How to Get It Right</title>
      <link>https://blogs.damiendye.uk/en/proxmox/numa-alignment-proxmox/</link>
      <pubDate>Fri, 07 Aug 2026 09:40:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/numa-alignment-proxmox/</guid>
      <description>On multi-socket systems, a VM with its vCPUs on one NUMA node and its passed-through device on another loses 20–30% throughput before you&amp;#39;ve even looked at anything else.</description>
    </item>
    <item>
      <title>PCIe ASPM and Why You Should Disable It for Passthrough</title>
      <link>https://blogs.damiendye.uk/en/proxmox/pcie-aspm-passthrough/</link>
      <pubDate>Fri, 07 Aug 2026 09:20:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/pcie-aspm-passthrough/</guid>
      <description>Active State Power Management saves a few watts on idle PCIe links. Under VFIO passthrough, it adds latency jitter that&amp;#39;s hard to diagnose and easy to fix.</description>
    </item>
    <item>
      <title>PCIe MaxPayloadSize — A Free Performance Win for Passthrough</title>
      <link>https://blogs.damiendye.uk/en/proxmox/pcie-maxpayloadsize/</link>
      <pubDate>Fri, 07 Aug 2026 09:00:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/pcie-maxpayloadsize/</guid>
      <description>QEMU&amp;#39;s virtual root complex defaults to 128-byte TLP payloads. Most devices support 256 or 512. One kernel parameter fixes it.</description>
    </item>
    <item>
      <title>Always Use Q35, Not i440fx — Why It Matters on Proxmox VE</title>
      <link>https://blogs.damiendye.uk/en/proxmox/q35-not-i440fx/</link>
      <pubDate>Fri, 07 Aug 2026 08:45:00 +0100</pubDate>
      <guid>https://blogs.damiendye.uk/en/proxmox/q35-not-i440fx/</guid>
      <description>The two QEMU virtual chipsets are not interchangeable. Q35 provides a proper PCIe topology that passthrough, modern Windows, and the wider KVM ecosystem all depend on.</description>
    </item>
  </channel>
</rss>
