Package Details: linux-vfio 6.12.6-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.000154
First Submitted: 2015-01-30 06:41 (UTC)
Last Updated: 2024-12-23 09:17 (UTC)

Dependencies (19)

Required by (6)

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 .. 22 23 24 25 26 27 28 29 30 31 32 Next › Last »

zipeldiablo commented on 2016-04-05 11:59 (UTC)

Hi, since i don't need the i915 patch (using ovmf) can i remove it through the pkgbuild or something? Also, is it possible to use an already customed kernel for this? I'm looking for ck kernel optimized for my cpu : https://wiki.archlinux.org/index.php/Repo-ck

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

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