Package Details: linux-vfio 6.9.5-1

Git Clone URL: https://aur.archlinux.org/linux-vfio.git (read-only, click to copy)
Package Base: linux-vfio
Description: The Linux kernel and modules (ACS override and i915 VGA arbiter patches)
Upstream URL: https://www.kernel.org
Keywords: acs arbiter assignment gpu i915 kvm override passthrough pci qemu vfio vga
Licenses: GPL-2.0-or-later
Provides: KSMBD-MODULE, VIRTUALBOX-GUEST-MODULES, WIREGUARD-MODULE
Submitter: zman0900
Maintainer: xiota
Last Packager: xiota
Votes: 73
Popularity: 0.006387
First Submitted: 2015-01-30 06:41 (UTC)
Last Updated: 2024-06-18 11:32 (UTC)

Dependencies (19)

Required by (5)

Sources (7)

Pinned Comments

xiota commented on 2024-01-09 18:43 (UTC) (edited on 2024-01-11 16:53 (UTC) by xiota)

  • Leaving eclairvoyant's comment pinned because it contains some useful information.
  • Patch policy is different, but similar.
    • Primary purpose of this package are the ACS override and i915 VGA arbiter patches.
    • Upstream Arch patches will be applied to maintain parity with the standard kernel.
    • No other patches will be added.
  • Package does have options that can be changed, like building with clang or disabling Arch patches.
    • Defaults will match Arch packages, except when incompatible with this package's primary patches.
    • Options are subject to change. Read PKGBUILD for details.
  • Avoid commenting and flagging at the same time for the same issue.
    • Flag for common issues with standard solutions, like new releases, key changes, etc.
    • Comment for issues requiring explanation or debugging.
      • Use a pastebin for blocks of text more than a few lines.

eclairevoyant commented on 2023-04-06 21:24 (UTC) (edited on 2023-04-06 21:31 (UTC) by eclairevoyant)

This package exists for the specific purpose of adding ported patches based on those originally created by Alex Williamson for:

Arbitrary patches will not be added.

Refer to the wiki on PCI passthrough and this blog post on IOMMU groups for risks/caveats before using this package.

Regular AUR etiquette applies as well (knowledge of makepkg and searching the wiki/Arch forums is expected, and AUR helpers or Arch-based distros that are not Arch Linux are unsupported).

Latest Comments

« First ‹ Previous 1 .. 21 22 23 24 25 26 27 28 29 30 31 Next › Last »

icewind commented on 2016-02-23 17:19 (UTC)

retested today and all works fine again

zman0900 commented on 2016-01-21 02:06 (UTC)

Have you tried 4.4-4? If you still have problems, try the plain arch 4.4-4 from the testing repo. If the problem still exists there, file a bug against the main arch package.

icewind commented on 2016-01-20 09:51 (UTC)

After updating to 4.4-3 it no longer detects my nvme ssd during boot

zman0900 commented on 2016-01-20 03:18 (UTC)

Updated with the 2 patches for arch testing 4.4-4 plus a patch to fix CVE-2016-0728.

markzz commented on 2016-01-18 00:11 (UTC) (edited on 2016-01-18 00:13 (UTC) by markzz)

Just so that there's at least one other person showing good signs, this version (4.4-3) works beautifully with my setup. Without the hugepages and with an Nvidia card. It works so well that I put the package on my repo.

zman0900 commented on 2016-01-17 02:01 (UTC)

I am only running 8 GB of guest memory with the remaining 24 GB for the host, but I am using 1 GB hugepages. I also have only 4 cores / 8 threads (of 6/12) used by the guest. Not sure if it makes a difference for what we're talking about, but I have the cpu pinning set up so each vcpu is pinned to a different host thread and the emulator is pinned to the remaining 4 host threads. AMD gpu too, so maybe things would be different with nvidia.

ohetfi commented on 2016-01-17 01:46 (UTC)

Hmm, that's weird. It seems that I'm the only one who has this issue. My guest is a Windows 10 guest, I put all my cores/threads on this guest (6 cores with 12 threads). The Tianocore splash screen took the same amount of time as with 4.1.15, but Windows loading took a while with all my threads on the Linux host are maxed. I put 24 GB of memory to it. Probably that's the case, what are you guest memory? Let's see if I can improve the boot performance if I reduce the memory size.

zman0900 commented on 2016-01-17 01:30 (UTC) (edited on 2016-01-17 01:32 (UTC) by zman0900)

I haven't tried the latest mainline. I did notice with 4.4 that cpu usage maxes out 2 cores for a second or 2 during boot, but it seems to actually boot faster for me. The tianocore screen doesn't even time to show now when it used to appear for 3-5 seconds. Running windows 8.1 in the guest.

ohetfi commented on 2016-01-17 01:28 (UTC)

The patch for the bug has been merged since 4.4rc7 [1]. Although it can now boot successfully, I still felt the boot time is considerably slower and took higher CPU usage than in previous 4.1.15 kernel. Have you experienced the similar behavior in the latest mainline kernel? [1] https://bugzilla.kernel.org/show_bug.cgi?id=107561

zman0900 commented on 2016-01-17 00:39 (UTC) (edited on 2016-01-17 00:41 (UTC) by zman0900)

I usually keep this package in sync with the main Arch package, but I have recently built 4.4 and for the first time since 4.1 it is actually working to boot a VM with OVMF and pcie passthrough. I am running git version of OVMF (17560.ccdf8bc), qemu (2.5.0.r43284.5a57acb), and libvirt (1.3.1.rc2.3.g8f0a157 - custom package from my github), so it may or may not work with the repo versions. Before upgrading, consider that this package is very closely based on the main Arch package which hasn't been released yet. You are taking the same risk as running the testing repo. It is possible that it could contain some system-destroying bug that you would normally not be exposed to because it would be fixed by the time it is released. You have been warned.

« First ‹ Previous 1 .. 21 22 23 24 25 26 27 28 29 30 31 Next › Last »