Intel Xe Driver: Faulty VRAM Pages Now Taken Offline Like Bad Sectors for Linux
By Indie Kings | October 17, 2026
Updated October 17, 2026: A new Linux kernel patch confirms Nova Lake integrated graphics support SR-IOV virtualization through the Xe driver, adding to a stretch of Linux-side progress for Intel graphics that started in August. In that window, the driver also learned to take faulty VRAM pages offline and SteamOS 3.9 Main learned to boot an Arc B580 with no Radeon card swap.
Three separate developments, tracked from August through this week by videocardz coverage of Intel's Linux graphics work, all point the same direction. The Arc stack on Linux is moving from a workaround-driven hobbyist setup toward a managed platform: hardware virtualization in the kernel, self-monitoring memory in the driver, and a stock Valve operating system that boots without tricks.
Nova Lake graphics join the Xe VFIO virtualization table
A new Linux kernel patch confirms that Nova Lake-S, the desktop version of Intel's upcoming processor family, and Nova Lake-P, the mobile version, support Single Root I/O Virtualization (SR-IOV) through the Xe graphics driver. Per videocardz's October 16 report, the update adds the corresponding device IDs to the xe-vfio-pci driver, and the patch comes from an Intel engineer.
The patch adds three device families to the VFIO device table: Nova Lake-S (NVL-S), Nova Lake-P (NVL-P), and Crescent Island (CRI), which is now marketed as the Intel GPU D Series. They join hardware already listed there: Battlemage, Panther Lake, and Wildcat Lake.
Per the same report, this is not the first sign of SR-IOV plans for Nova Lake. Intel already submitted Xe driver changes for Nova Lake-S and Nova Lake-P earlier in 2026, which videocardz noted in its May coverage of the rumored Nova Lake Edge processor. The new patch expands VFIO device matching rather than introducing the underlying SR-IOV capability itself.
AMD is moving on a parallel track. Per videocardz's May report, AMD prepared SR-IOV support for its next generation Ryzen AI XDNA NPUs, with patches targeting the upcoming AIE4 accelerator through the AMDXDNA Linux driver. Unlike Intel's implementation for Xe integrated graphics, AMD's changes concern the neural processing unit rather than the Radeon GPU. Both developments point toward broader virtualization support in future client processors.
What SR-IOV means for virtual machines
SR-IOV allows one physical GPU to expose multiple virtual functions that can be assigned to separate virtual machines. Conventional PCIe passthrough typically hands an entire GPU to a single virtual machine, so a host running two or three guests needs two or three cards. With SR-IOV, several guests can get direct access to the same graphics processor.
There is a catch, and it matters for expectations. Per the videocardz report, actual functionality still depends on firmware, hypervisor, and driver support. A device ID in the kernel's VFIO table is the plumbing that makes assignment possible; it does not guarantee every hypervisor or every firmware build will cooperate with it on day one.
For anyone who has built a GPU passthrough rig, the practical difference is concrete: one Nova Lake system could, in principle, serve a gaming virtual machine and a second workload virtual machine from the same integrated GPU, instead of dedicating a whole discrete card to the guest.
Faulty VRAM pages now get taken offline like bad sectors
A second Linux-side change targets hardware that misbehaves. Per videocardz's September 20 report, citing Phoronix, Intel is adding video memory health features to the Xe driver for Linux 7.4: an early VRAM sanity check plus a way to permanently remove faulty memory pages from future GPU allocations.
The first feature is a basic VRAM health check performed during driver initialization. Intel uses the last page of video memory as a canary, on the logic that problems with BAR sizing, CCS sizing, or memory mapping tend to show up there first. Intel engineer Matthew Auld explained the motivation on some Battlemage cards: the CCS offset was programmed misaligned, and the driver's handling was broken, so part of the memory reserved for compression metadata could end up inside the regular VRAM allocator. The driver effectively stresses that final page during early probe, so such bugs surface immediately instead of corrupting data later.
The second change handles GPUs that develop real memory faults. After 21 revisions, the Xe driver now supports memory page offlining. If a physical VRAM page is known to be faulty, the driver permanently removes it from the pool used for new allocations.
The model here is storage, not graphics. Just as a drive controller stops handing out a bad sector, the driver marks a damaged memory region unavailable. Instead of repeatedly giving applications the same bad memory and risking corruption, crashes, or GPU resets, the GPU keeps running with slightly less usable memory. A card that would previously degrade into instability can now limp along in a healthy, predictable state.
SteamOS 3.9 Main boots the Arc B580 directly
The third change lives at the operating system layer. Per videocardz's August 20 report, the Intel Arc B580 can now run Valve's SteamOS without the installation workaround previously required for Intel's discrete GPU. Tester ETA Prime used SteamOS Main branch version 3.9, a build from Valve's main development branch rather than the current public Beta channel, and booted directly into the operating system with the B580 installed.
The contrast with June is stark. Per the videocardz report, SteamOS already recognized the Arc B580 back in June, but installing it required an AMD Radeon card in the system. Users had to install an older SteamOS image, update the system, then swap the Radeon card out for the B580. That process is no longer needed, which removes a large barrier for anyone building an Intel based SteamOS desktop.
Valve has been expanding Intel support on this branch over several releases. Version 3.8.25 added initial gamepad support for the Intel powered MSI Claw 8 EX AI+ handheld. The same Main branch build is what ETA Prime used to test an AMD Strix Halo laptop a couple of weeks before the B580 test.
The 1440p test results, game by game
ETA Prime paired the 12GB Arc B580 with a Core Ultra 5 250K Plus processor and tested five games at 1440p. Per the videocardz writeup of the testing, the card held playable frame rates across the board, with occasional dips that stayed above 60 FPS. The Windows comparison figures come as reported ranges from the same testing.
| Game | SteamOS 3.9 Main result | Settings | Windows, as reported |
|---|---|---|---|
| Cyberpunk 2077 | Mid 70 FPS | 1440p High, XeSS Quality | Roughly 75 to 90 FPS depending on scene |
| Horizon Zero Dawn Remastered | Mid 60 FPS | 1440p High, XeSS Balanced | Mid 70 FPS |
| Forza Horizon 6 | About 74 FPS average | 1440p High, no scaling | Mid 80 FPS |
| Fallout 4 | 60 FPS | 1440p | Not broken out |
| Elden Ring | 60 FPS | 1440p maximum settings, no upscaling | Not broken out |
Put plainly: in the tested games, the Linux performance gap against Windows on identical hardware ranged from none to roughly 10 FPS. For a discrete card that was, in mid 2025, still associated with driver growing pains, running Cyberpunk 2077 in the mid 70s at 1440p High on a stock Valve operating system is a real marker.
What still trails Windows on Linux
The test also documented the remaining gap, and it is about features rather than raw frames. Per the videocardz report, the Arc B580 has dedicated XMX engines, but the current open source Linux driver path does not expose them for XeSS acceleration. XeSS still runs through its shader based fallback path, and the difference shows most in lower quality scaling modes.
The practical consequence: XeSS image quality will simply be higher in Windows, because the hardware accelerated path is not available on the Linux side yet. XeSS Frame Generation and Multi Frame Generation are also unavailable in this setup, since Intel's XeSS Frame Generation documentation lists Windows 10/11 and DirectX 12 as requirements.
There is a substitute. FSR Frame Generation remains an option under SteamOS, so frame generation is not off the table entirely, it just comes from AMD's upscaler rather than Intel's. Direct boot support removes the biggest barrier for Arc B580 systems, while the feature set continues to trail Intel's Windows driver.
From workarounds to a managed platform
Lay the three items on a timeline and the pattern holds. In August, per videocardz, a stock Valve operating system booted Intel's discrete GPU with no Radeon card in the install path. In September, per videocardz citing Phoronix, the kernel driver gained a health check for memory mapping bugs and the ability to quarantine faulty VRAM pages. This month, per videocardz, a kernel patch added SR-IOV device IDs for three families of Intel graphics, including the upcoming Nova Lake desktop and mobile chips.
| Development | First reported | What changed | Status |
|---|---|---|---|
| SteamOS 3.9 Main boots Arc B580 | August 20, 2026 | Direct boot replaces the AMD Radeon install workaround | Works on SteamOS Main branch; XMX and XeSS FG unavailable |
| VRAM health check and page offlining | September 20, 2026 | Init time canary page check plus permanent offlining of faulty pages | Filmed for Linux 7.4 via Phoronix |
| Nova Lake SR-IOV in Xe VFIO driver | October 16, 2026 | Device IDs added for NVL-S, NVL-P, and Crescent Island | Kernel patch; function depends on firmware, hypervisor, driver |
Each item sits at a different layer: the distribution, the kernel driver, and the virtualization plumbing. None of them is alone a headline that changes buying decisions. Together they describe a driver stack that is being built to run unattended and to be relied on, which is what the Steam Deck did for AMD's handheld existence and what Linux server virtualization did for datacenter GPUs years ago.
Our take
We think the most underrated item of the three is the VRAM page offlining. Benchmarks get the attention, but a driver that quarantines a failing memory page instead of crashing is the difference between a hobby card and infrastructure, and a 21 revision patch process suggests Intel is treating it that way. The SR-IOV news is the most forward looking, because turning integrated graphics into a shareable virtualization resource is a feature enterprise buyers notice, and it gives Nova Lake a talking point that beats raw clock speeds. What we would watch next is whether the open source Xe driver exposes the B580's XMX engines for XeSS, because that single gap explains most of the remaining image quality difference against Windows in the tested games.
FAQ
What is SR-IOV support on Intel Nova Lake graphics?
Single Root I/O Virtualization lets one physical GPU expose multiple virtual functions, each assignable to a different virtual machine. Per the October 16 videocardz report, a Linux kernel patch added Nova Lake-S, Nova Lake-P, and Crescent Island device IDs to the xe-vfio-pci driver, confirming the capability exists in the Xe driver stack.
Does the kernel patch mean SR-IOV works in virtual machines today?
Not guaranteed yet. Per the report, actual functionality depends on firmware, hypervisor, and driver support, and the patch expands VFIO device matching rather than introducing the underlying capability. Nova Lake hardware is also unreleased.
What can the Linux Xe driver do about faulty GPU memory?
Per the September 20 videocardz report, Linux 7.4 adds an init time VRAM health check using the last memory page as a canary, plus page offlining that permanently removes a known faulty page from future allocations. The GPU keeps running with slightly less usable memory instead of corrupting data or resetting.
Do you still need a workaround to install SteamOS on an Arc B580?
Not on the tested build. Per the August 20 videocardz report, ETA Prime booted directly into SteamOS Main branch version 3.9 with the B580 installed, while the June method required installing SteamOS with an AMD Radeon card present and swapping it out.
Should you use XeSS on SteamOS with a B580?
The Linux driver path does not expose the card's XMX engines for XeSS acceleration, so XeSS runs a shader based fallback and image quality trails Windows, especially at lower scaling modes. XeSS Frame Generation is also unavailable, so FSR Frame Generation is the working option under SteamOS.
Which games were tested at 1440p on the B580 under SteamOS?
Per the videocardz writeup of ETA Prime's testing with a Core Ultra 5 250K Plus: Cyberpunk 2077 (mid 70 FPS High, XeSS Quality), Horizon Zero Dawn Remastered (mid 60 FPS High, XeSS Balanced), Forza Horizon 6 (about 74 FPS High, no scaling), Fallout 4 and Elden Ring (60 FPS, Elden Ring at maximum settings without upscaling).
Bottom Line
Intel's graphics stack on Linux had a good few months, and three checkpoints say so: the Arc B580 boots SteamOS 3.9 Main with no workarounds and hits playable 1440p frame rates within about 10 FPS of Windows in the tested games, the Xe driver learns to detect and quarantine faulty VRAM pages for Linux 7.4, and a kernel patch adds SR-IOV device IDs covering Nova Lake desktop and mobile integrated graphics. Attribution matters in each case: virtualization support still depends on firmware and hypervisor cooperation, the offlining feature arrives with Linux 7.4, and the SteamOS results come from one tester's hardware pairing. The direction of travel, from workaround driven setup to managed platform, is the story.
Sources
- videocardz: Intel Nova Lake-S/P Xe graphics get SR-IOV virtualization support in Linux (October 16, 2026)
- videocardz: Intel Linux driver can isolate damaged GPU memory pages (September 20, 2026)
- videocardz: SteamOS 3.9 Main now boots on Intel Arc B580 without workarounds, 1440p gaming tested (August 20, 2026)
Image credit: Videocardz (Intel Nova Lake rendering)