Package Details: linux-vfio-headers 5.17.4.arch1-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
Upstream URL: https://github.com/archlinux/linux/commits/v5.17.4-arch1
Keywords: acs arbiter assignment gpu i915 kvm override passthrough pci qemu vfio vga
Licenses: GPL2
Submitter: zman0900
Maintainer: markzz (slowbro)
Last Packager: slowbro
Votes: 71
Popularity: 0.75
First Submitted: 2015-01-30 06:41 (UTC)
Last Updated: 2022-04-22 19:35 (UTC)

Pinned Comments

markzz commented on 2020-05-01 15:44 (UTC) (edited on 2020-05-01 16:06 (UTC) by markzz)

A few things BEFORE building this package and/or commenting here:

READ THE WIKI AND UNDERSTAND HOW TO USE MAKEPKG AND EVERYTHING IT ENTAILS

If you do not read the wiki and ask a stupid question, you'll either get a stupid/terse response from me or you will be ignored. If this continues, this may require me to bring this up to a TU for account suspensions.

Remember, there's also search engines that you can also look up errors that you get related to makepkg.

WE WILL NOT MODIFY THE CONFIG FILE

This package's goal is to be as close to the Arch Linux linux package. Therefore, we use the config file from that package. We will not, unless under very special circumstances, modify the config file for any reason.

You can make changes yourself. You should be capable enough to make any changes you see fit without us making the changes on our end.

WE WILL NOT ADD X PATCH

This one has been more recent. The goal of this package is to add a MINIMAL patch set for IOMMU grouping and for VGA arbitration on Intel iGPUs. Under no circumstances will I backport patches that are not present in the linux repository on git.archlinux.org nor will I add a patch that adds a feature outside of the intended goal of this project.

If you absolutely feel that your patch is completely necessary, you MUST have ready a link to the appropriate discussion from the OFFICIAL LINUX KERNEL MAILING LISTS and/or from Arch Linux's Bug Tracker at bugs.archlinux.org. For the latter, they must be bugs present in the linux package in [core] and do NOT open a task on there if it is specific to this package (or any AUR package for that matter). I do not want to see links to reddit talking about some patch that you want to add.

If you want to add patches to your own build, that's completely fine.

DO NOT USE AN AUR HELPER THEN EXPECT US TO HELP

AUR helpers are unsupported and therefore we will not provide help to you unless you have verified it's not working with makepkg. I always make sure this package builds in a clean chroot before uploading here, so I know it builds on a clean and up to date Arch Linux system.

BINARY PACKAGES ARE PROVIDED FOR YOUR CONVENIENCE

Both maintainers of this package provide signed binary packages in unofficial pacman repositories maintained and signed by ourselves. If you do not want to compile this kernel yourself for whatever reason, feel free to make use of them.

slowbro commented on 2020-02-26 23:21 (UTC) (edited on 2020-02-26 23:22 (UTC) by slowbro)

Like markzz was, I'm providing updated builds in my (unofficial) user repository, if you don't want to build this yourself.

Info here: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#slowbro

Signing key: 85186206

Details on importing a key for pacman are here.

Latest Comments

Jeka commented on 2022-07-04 11:01 (UTC) (edited on 2022-07-04 11:05 (UTC) by Jeka)

Has anyone tried the Manjaro kernel with the ACS patch on Arch Linux? (linux-acs-manjaro)

giostark commented on 2022-06-05 00:58 (UTC)

Maybe a tip for other noobs like me. Now the system update work with the gcc 12.1. Installing the pre-compiled kernel (done with gcc 11.2) or via helper (yay always search for gcc 11.2) result in error with the latest nvidia modules (that use the gcc 12.1). Solutions: 1) downgrade the gcc to the 11.2 (bleah solution) 2) (better solution) compile the kernel from the source without helpers using: makepkg -Crso Then: makepkg -ers Then: sudo pacman -U (3 packs generated before) Here the topic of the issue: https://bbs.archlinux.org/viewtopic.php?pid=2039309#p2039309

JuniorJPDJ commented on 2021-12-09 00:31 (UTC)

pssst, this version is 2 patches old now

Mine-turtle commented on 2021-10-27 05:45 (UTC) (edited on 2021-11-21 11:32 (UTC) by Mine-turtle)

HI, I'm unable to completely update my Manjaro for two update cycles now. These three are the last stragglers: linux-vfio, linux-vfio-docs, linux-vfio-headers.

This is all I get from pacman (gui) before update terminates:


  Preparing...
  Cloning linux-vfio build files...
  Generating linux-vfio-docs information...
  Failed to prepare transaction:
  Failed to generate linux-vfio-docs information

Any advice?

hurrian commented on 2021-09-11 14:37 (UTC) (edited on 2021-09-12 06:49 (UTC) by hurrian)

Hello, I've noticed that this has been out of date for a while - I've updated the package to sync with the latest Arch vanilla kernel.

The ACS patch was successfully tested on a Gigabyte X570-UD, by passing through a chipset USB controller.

The i915 patch needed minor refactoring to build on 5.14, however I don't have any Intel hardware, so I am unable to test this patch.

Here's the link to my tree for 5.14.2-arch1-2: https://github.com/hurrian/linux-vfio/tree/5.14.2-arch1-2-vfio . I've also submitted this as a PR to @slowbro's repository.

Edit: The update to 5.14.2 has been merged.

daniel_shub commented on 2021-07-27 16:01 (UTC)

@slowbro how were you testing the package. Were you running it through a formal test suite of some sort or just seeing if passthrough was working?

slowbro commented on 2021-07-22 07:53 (UTC)

Hey all. I no longer have a machine that runs (or needs) this package, so I have no direct way to test it. Regardless, I will continue updating it. Please be sure to report any issues you run into.

JuniorJPDJ commented on 2021-07-11 13:31 (UTC)

Consider testing 5.13 ;D

JuniorJPDJ commented on 2021-07-11 04:46 (UTC)

I never actually played too much with github actions so I doubt I would be useful - I'm sorry ;/

Anyway - good idea! I'm not sure if it will be easy to test like that, but then someone will tell us here that it's broken ;V

slowbro commented on 2021-07-11 03:45 (UTC) (edited on 2021-07-11 04:12 (UTC) by slowbro)

Thank you - I don't have permission to do that, I don't think; however, since Arch is now using Github for their repo, I was considering using my Github account + GH Actions to so a similar thing. Admittedly, I am upgrading my PC very soon and likely will no longer need this package myself.. but I would like to continue to keep it available for others, as I know how helpful it can be.

I believe the default GH Actions disk space allowance well undershoots the size of the archlinux-linux repo, so I'll have to see about getting that working with a shallow clone. If you'd be willing to help, it would be appreciated! I was previously using this repository, and was planning on continuing there: https://github.com/slowbro/linux-vfio

Edit: by the way, I am in the process of building the latest package. I like to make sure it builds & boots before releasing it, so it will be ~20min.

JuniorJPDJ commented on 2021-07-11 00:04 (UTC)

Hey, I'm the guy flagging it out of date whole time.

Maybe you can just add me as co-maintainer, I'll update it instead of flagging and waiting ;)

I would be doing just dumb bumps for minor versions when new version of linux would become available in core repos.

slowbro commented on 2021-07-01 05:52 (UTC)

I'll get this updated ASAP, sorry! Been pulled in all directions lately.

JuniorJPDJ commented on 2021-06-28 23:27 (UTC)

Yup, official linux package seems to use github now: https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/PKGBUILD

This is the repo it uses: https://github.com/archlinux/linux

jsutton commented on 2021-06-28 17:29 (UTC)

It looks like this package does not build at the moment.

==> Retrieving sources... -> Cloning archlinux-linux git repo... Cloning into bare repository '/home/jpsutton/.cache/yay/linux-vfio/archlinux-linux'... fatal: repository 'https://git.archlinux.org/linux.git/' not found

I suspect it has something to do with the deprecation of git.archlinux.org...

https://lists.archlinux.org/pipermail/arch-dev-public/2021-June/030466.html

daniel_shub commented on 2021-02-17 15:11 (UTC)

I did a little more digging and it looks like the problem is not this package, but rather that the linux package might be broken in the core repo (opps). It looks like the Arch Devs are on it and there is a 5.11 version of the linux package in testing with a patch for a recent upgrade to Sphinx. My guess is once the new version hits core and this package is updated, everything will be fine.

daniel_shub commented on 2021-02-16 20:37 (UTC)

I am having trouble building in a clean chroot.

cat: /etc/os-release: No such file or directory SPHINX htmldocs --> file:///build/linux-vfio/src/archlinux-linux/Documentation/output PARSE include/uapi/linux/dvb/audio.h PARSE include/uapi/linux/dvb/ca.h PARSE include/uapi/linux/dvb/dmx.h PARSE include/uapi/linux/dvb/frontend.h PARSE include/uapi/linux/dvb/net.h PARSE include/uapi/linux/dvb/video.h PARSE include/uapi/linux/videodev2.h PARSE include/uapi/linux/media.h PARSE include/uapi/linux/cec.h PARSE include/uapi/linux/lirc.h WARNING: The kernel documentation build process support for Sphinx v3.0 and above is brand new. Be prepared for possible issues in the generated output. /build/linux-vfio/src/archlinux-linux/Documentation/driver-api/usb/usb:158: ./drivers/usb/core/message.c:961: WARNING: Duplicate C declaration, also defined at driver-api/usb/gadget:759. Declaration is '.. c:function:: int usb_string (struct usb_device dev, int index, char buf, size_t size)'. /build/linux-vfio/src/archlinux-linux/Documentation/driver-api/usb/usb.rst:961: WARNING: Duplicate C declaration, also defined at driver-api/usb/gadget:759. Declaration is '.. c:struct:: usb_string'. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/drm-kms:349: ./drivers/gpu/drm/drm_fourcc.c:312: WARNING: Duplicate C declaration, also defined at gpu/drm-kms:3. Declaration is '.. c:function:: const struct drm_format_info * drm_format_info (u32 format)'. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/drm-kms:433: ./drivers/gpu/drm/drm_modeset_lock.c:338: WARNING: Duplicate C declaration, also defined at gpu/drm-kms:46. Declaration is '.. c:function:: int drm_modeset_lock (struct drm_modeset_lock lock, struct drm_modeset_acquire_ctx ctx)'. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/drm-uapi:346: ./drivers/gpu/drm/drm_ioctl.c:919: WARNING: Duplicate C declaration, also defined at gpu/drm-uapi:70. Declaration is '.. c:function:: bool drm_ioctl_flags (unsigned int nr, unsigned int flags)'. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/todo.rst:283: WARNING: Unexpected indentation. /build/linux-vfio/src/archlinux-linux/Documentation/gpu/todo.rst:284: WARNING: Block quote ends without a blank line; unexpected unindent. /build/linux-vfio/src/archlinux-linux/Documentation/driver-api/miscellaneous:48: ./drivers/pwm/core.c:667: WARNING: Duplicate C declaration, also defined at driver-api/miscellaneous:294. Declaration is '.. c:function:: int pwm_capture (struct pwm_device pwm, struct pwm_capture result, unsigned long timeout)'. /build/linux-vfio/src/archlinux-linux/Documentation/driver-api/80211/mac80211:109: ./include/net/mac80211.h:4719: WARNING: Duplicate C declaration, also defined at driver-api/80211/mac80211:1011. Declaration is '.. c:function:: void ieee80211_tx_status (struct ieee80211_hw hw, struct sk_buff *skb)'.

Exception occurred: File "/usr/lib/python3.9/site-packages/sphinx/builders/html/init.py", line 1039, in <lambda> ctx['css_files'].sort(key=lambda js: js.priority) AttributeError: 'str' object has no attribute 'priority' The full traceback has been saved in /tmp/sphinx-err-ct3buvc5.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at https://github.com/sphinx-doc/sphinx/issues. Thanks! make[1]: [Documentation/Makefile:91: htmldocs] Error 2 make: [Makefile:1665: htmldocs] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Build failed, check /chroot/base-devel/dshub/build

giostark commented on 2020-12-28 13:54 (UTC)

@slowbro OT/ RTX4000 user here , but big thanks for your constant effort !!! :-) Happy holidays to both of you that help us to use this kernel ;-) /OT

slowbro commented on 2020-12-23 06:41 (UTC)

I have the patch & package prepped for 5.10.2 - waiting for it to come out of testing. There were significant changes to i915 in 5.10 - is anyone running 5.10.x already, on i915, and willing to test the linux-vfio package before 5.10 hits core?

derwhalfisch commented on 2020-12-09 07:58 (UTC)

5.9.11 has fixed the IOMMU groups problem for me, but I have had to include a patch to deal with an AMD reset bug.

peterh commented on 2020-12-04 07:11 (UTC)

5.9.11 fixed the problem also for me. Thanks.

spamad commented on 2020-12-02 19:17 (UTC)

I was having the same issue as peterh where the IOMMU grouping stopped working at 5.9.1 (I7-3770, Gigabyte Z77X-UD3H). After compiling 5.9.11, the issue is now resolved.

Zetein commented on 2020-11-30 04:35 (UTC)

An easy way to import the required gpg keys, if anyone is having problems with it as I was.

curl https://keybase.io/heftig/pgp_keys.asc | gpg --import

markzz commented on 2020-10-27 04:48 (UTC)

I can confirm there's an issue with it. I cannot get to investigating until this weekend though.

peterh commented on 2020-10-22 18:12 (UTC)

The IOMMU groups on my system (Z77, I7-3770) are broken if I'm using version linux-vfio 5.9.1.arch1-1. Any idea ?

slowbro commented on 2020-10-18 22:22 (UTC) (edited on 2020-10-18 22:22 (UTC) by slowbro)

5.9.1 is up now, but note that nvidia is only partially supported on 5.9.x; nvidia expects to have an update ready in november. this seems to only affect cuda and opencl.

https://forums.developer.nvidia.com/t/nvidia-driver-not-yet-supported-for-linux-kernel-5-9/157263

there are supposedly some patches available that workaround this issue; you'll need to find/apply those yourself if you need cuda/opencl on 5.9.x.

slowbro commented on 2020-09-30 18:47 (UTC)

Do you have any custom gpg configs or are you perhaps using an alternative keyring? I also am not able to reproduce the problem. Make sure your GPG keyring has all the listed signatures from your first post...

:: PGP keys need importing:
 -> ABAF11C65A2970B130ABE3C479BE3E4300411886, required by: linux-vfio
 -> 647F28654894E3BD457199BE38DBBDC86092693E, required by: linux-vfio
 -> A2FF3A36AAA56654109064AB19802F8B0D70FC30, required by: linux-vfio

c3924754 commented on 2020-09-30 15:04 (UTC)

gpg --recv-keys 3B94A80E50A477C7
git clone https://aur.archlinux.org/linux-vfio.git
cd linux-vfio
makepkg -si

These steps do not work for me, without helpers. Even after having a clean repo/folder.

==> Verifying source file signatures with gpg...
    archlinux-linux git repo ... SIGNATURE NOT FOUND
==> ERROR: One or more PGP signatures could not be verified!

TheUnknownZ commented on 2020-09-29 21:13 (UTC) (edited on 2020-09-29 21:14 (UTC) by TheUnknownZ)

gpg --recv-keys 3B94A80E50A477C7

git clone https://aur.archlinux.org/linux-vfio.git

cd linux-vfio

makepkg -si

Works here. I suggest reading the pinned comment as AUR helpers are not supported.

c3924754 commented on 2020-09-29 18:56 (UTC)

:: PGP keys need importing:
 -> ABAF11C65A2970B130ABE3C479BE3E4300411886, required by: linux-vfio
 -> 647F28654894E3BD457199BE38DBBDC86092693E, required by: linux-vfio
 -> A2FF3A36AAA56654109064AB19802F8B0D70FC30, required by: linux-vfio
==> Import? [Y/n] y
:: Importing keys with gpg...
gpg: key 19802F8B0D70FC30: 6 duplicate signatures removed
gpg: key 19802F8B0D70FC30: 6 signatures reordered
gpg: key 19802F8B0D70FC30: public key "Jan Alexander Steffens (heftig) <jan.steffens@gmail.com>" imported
gpg: key 38DBBDC86092693E: public key "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" imported
gpg: key 79BE3E4300411886: public key "Linus Torvalds <torvalds@kernel.org>" imported
gpg: Total number processed: 3
gpg:               imported: 3
==> Making package: linux-vfio 5.8.12.arch1-1
==> Retrieving sources...
  -> Cloning archlinux-linux git repo...
Cloning into bare repository '/home/user/.cache/yay/linux-vfio/archlinux-linux'...
remote: Enumerating objects: 19718, done.
remote: Counting objects: 100% (19718/19718), done.
remote: Compressing objects: 100% (9357/9357), done.
remote: Total 7741632 (delta 13062), reused 13650 (delta 10325), pack-reused 7721914
Receiving objects: 100% (7741632/7741632), 2.29 GiB | 6.63 MiB/s, done.
Resolving deltas: 100% (6468837/6468837), done.
  -> Found config
  -> Found add-acs-overrides.patch
  -> Found i915-vga-arbiter.patch
  -> Found sphinx-workaround.patch
==> Validating source files with sha256sums...
    archlinux-linux ... Skipped
    config ... Passed
    add-acs-overrides.patch ... Passed
    i915-vga-arbiter.patch ... Passed
    sphinx-workaround.patch ... Passed
==> Verifying source file signatures with gpg...
    archlinux-linux git repo ... SIGNATURE NOT FOUND
==> ERROR: One or more PGP signatures could not be verified!
error downloading sources: linux-vfio

Getting all of heftig's keys from KeyBase does not work either. Suggestion gpg --recv-keys 3B94A80E50A477C7 also does not work. What is going on here?

slowbro commented on 2020-06-10 03:15 (UTC)

Just threw 5.6.15 up, sorry for the delay. Note that heftig's GPG key was rotated recently, so you'll probably need to gpg --recv-keys 3B94A80E50A477C7 before building.

shaybox commented on 2020-06-10 02:44 (UTC)

5.6.10 Is no longer supported by kernel modules, and 5.7 is testing, at-least update to 5.6.13 for module support so the nvidia drivers work, the current patch-set works with 5.6.13 no change required.

plntyk commented on 2020-05-19 16:06 (UTC)

with gcc 10 i have a compile error on virt/kvm/kvm main.c:2236

it seems upstream bug: https://bugzilla.kernel.org/show_bug.cgi?id=207173 should be fixed with 5.7 upstream mentioned there

commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=78a5255ffb6a1

adding that patch makes it compile again

markzz commented on 2020-05-11 06:29 (UTC) (edited on 2020-05-11 06:31 (UTC) by markzz)

It wouldn't matter much anyways because I'm almost certain that X does not support hot plugging display devices. Heck, if you notice in the 0/6 patch, the submitter mentions that he restarts X when hot plugging, which is what I would expect.

The patch seems to be for people who are hotplugging PCI-e devices (which I would expect to be over Thunderbolt), which is something I would bet a vast majority of users do not attempt. I do not expect this patch would improve AMDGPU users' experiences while running a "normal" setup with just a AMD video device plugged directly into one of the available PCI-e slots inside their machines and not touching it while the machine is running (as is a very good idea to not touch an active device on a PCI-e slot/device that isn't specifically designed for hot plugging).

Also, it appears that the issues discussed in the earlier comments are related to certain AMD processors and not video devices.

slowbro commented on 2020-05-11 04:51 (UTC)

I'll admit I don't know much in the ways of DRI or internal kernel workings. There's a patchset that has been penned by Andrey Grodzovsky, a Software Engineer at AMD, that purports to resolve some of these issues. For those using AMDGPU who are experiencing issues, I suggest you read his patch summary, and look into testing these patches on your system(s).

I hope that in the coming days/weeks more detailed information and better patches will be released; it looks like this, at the very least, has the attention of AMD.

https://lists.freedesktop.org/archives/dri-devel/2020-May/265386.html

yankeedoodle commented on 2020-05-08 14:26 (UTC)

QEMU5 update is breaking windows VM's on newer Ryzen processors. Apparently fix is to disable amd-stibp in the cpu flags or use earlier kernel for the moment. Various workarounds in the vfio discord.

meadovv commented on 2020-05-08 14:18 (UTC)

I get the same error as purploid, AMD host GPU, passing down an Nvidia; last kernel update seems to have broken something because switching to LTS fixed it. I'm on x570 chipset if that matters

purploid commented on 2020-05-08 05:05 (UTC)

markzz: I am not. I am using AMDGPU for my host system and am passing an nvidia card to the guest VM. It's possible there was another change somewhere along the way but this issue popped up after upgrading from 5.6.8 to 5.6.10-1.

I am finding that the LTS kernel doesn't give me this issue. Now that I can boot the Windows guest, the only thing I can see in the minidump file is NTOSKRNL.exe crashing which doesn't give me much to go on and I haven't had any major updates on the guest VM in a while.

markzz commented on 2020-05-08 00:49 (UTC)

purploid: Are you using i915 VGA arbitration?

purploid commented on 2020-05-07 23:09 (UTC)

@slowbro thank you, but I have already set that option.

These GSOD/BSOD errors only started after I updated to this kernel. I switched to vfio-lts and it's working again.

I'll try the non-lts version in a few updates and see if that stabilizes things.

slowbro commented on 2020-05-07 20:59 (UTC)

@purploid https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Bluescreen_at_boot_since_Windows_10_1803

purploid commented on 2020-05-07 20:51 (UTC)

@markzz I am currently unable to boot my Windows VM with "KERNEL SECURITY CHECK FAILURE" Blue/Green Screen of Death.

I have attempted to boot into Windows Installer as well and I am seeing the same behaviour on a brand new ISO from MS.

markzz commented on 2020-05-06 21:23 (UTC)

Anyone who uses this PKGBUILD that actually uses the i915 VGA Arbitration patch, please let me know if you are currently having issues. It looks like to me that there's an issue in the current patch, but I do not personally use that part of this kernel.

I will be updating to 5.6.10.arch1-2 in the coming hours and would like to know if anyone can confirm my hunch.

markzz commented on 2020-05-06 20:28 (UTC)

Pushed commit 757f0700.

markzz commented on 2020-05-06 19:48 (UTC) (edited on 2020-05-06 20:02 (UTC) by markzz)

I'm trying to determine the cause now. I looked and saw that your package isn't built on a clean arch linux system (or chroot), so I'm doing some investigating.

EDIT: Since I didn't actually answer your question, it is a compiler error in the xen module, which is something neither patch touches directly in any way, so I'm poking around at what may be the issue that is related to that.

slowbro commented on 2020-05-06 19:33 (UTC)

What error do you get? I was able to build it last night and am running it now.

markzz commented on 2020-05-06 19:25 (UTC)

5.6.10.arch1-1 does not appear to build in a clean chroot.

markzz commented on 2020-05-01 15:52 (UTC)

daniel_shub: You're probably right, I added a pinned message. Heck, I wrote the patch that added that feature, I probably should use it. :-P

markzz commented on 2020-05-01 15:44 (UTC) (edited on 2020-05-01 16:06 (UTC) by markzz)

A few things BEFORE building this package and/or commenting here:

READ THE WIKI AND UNDERSTAND HOW TO USE MAKEPKG AND EVERYTHING IT ENTAILS

If you do not read the wiki and ask a stupid question, you'll either get a stupid/terse response from me or you will be ignored. If this continues, this may require me to bring this up to a TU for account suspensions.

Remember, there's also search engines that you can also look up errors that you get related to makepkg.

WE WILL NOT MODIFY THE CONFIG FILE

This package's goal is to be as close to the Arch Linux linux package. Therefore, we use the config file from that package. We will not, unless under very special circumstances, modify the config file for any reason.

You can make changes yourself. You should be capable enough to make any changes you see fit without us making the changes on our end.

WE WILL NOT ADD X PATCH

This one has been more recent. The goal of this package is to add a MINIMAL patch set for IOMMU grouping and for VGA arbitration on Intel iGPUs. Under no circumstances will I backport patches that are not present in the linux repository on git.archlinux.org nor will I add a patch that adds a feature outside of the intended goal of this project.

If you absolutely feel that your patch is completely necessary, you MUST have ready a link to the appropriate discussion from the OFFICIAL LINUX KERNEL MAILING LISTS and/or from Arch Linux's Bug Tracker at bugs.archlinux.org. For the latter, they must be bugs present in the linux package in [core] and do NOT open a task on there if it is specific to this package (or any AUR package for that matter). I do not want to see links to reddit talking about some patch that you want to add.

If you want to add patches to your own build, that's completely fine.

DO NOT USE AN AUR HELPER THEN EXPECT US TO HELP

AUR helpers are unsupported and therefore we will not provide help to you unless you have verified it's not working with makepkg. I always make sure this package builds in a clean chroot before uploading here, so I know it builds on a clean and up to date Arch Linux system.

BINARY PACKAGES ARE PROVIDED FOR YOUR CONVENIENCE

Both maintainers of this package provide signed binary packages in unofficial pacman repositories maintained and signed by ourselves. If you do not want to compile this kernel yourself for whatever reason, feel free to make use of them.

daniel_shub commented on 2020-05-01 14:33 (UTC)

@markzz first, let me start by saying thanks to you and slowbro for maintaining this package. Second, I think your decision to not deviate from the Arch Kernel except for the patches needed for VFIO/GPU pass through is the correct decision. The fact that the diff between this package and the linux package is so clean gave me a lot of confidence to install a custom kernel.

Finally, you may want to pin your message that says that the package will not deviate and if you want extra things to modify the PKGBUILD yourself.

markzz commented on 2020-05-01 07:00 (UTC)

lazerl0rd: As stated before further down the comments, no.

lazerl0rd commented on 2020-05-01 06:28 (UTC) (edited on 2020-05-01 06:29 (UTC) by lazerl0rd)

Could the following two patches be added:

https://clbin.com/OaR0H (for AMD Zen2)

https://github.com/ZestProjects/linux/commit/ac7e184bddfb559c29e9b97de11a0f496aad696e (for HP ProLiant Gen8 servers)

meshedpotato commented on 2020-04-27 16:25 (UTC)

Thanks @slowbro, you set me off the in the right direction - very very thanks ;) - my VMs are booting in 25 seconds now compared to 4 mins of total boot time prior to this flag.

markzz commented on 2020-04-26 23:37 (UTC)

I also do not consider grabbing patches from reddit as a good idea either. I would prefer that patch suggestions of any kind should also be accompanied by a Linux Kernel mail list thread OR an Arch Linux Flyspray link so there's discussion from those ends as well. Also, as a reminder, do not open Flyspray reports for upstream bugs.

NovaMoon commented on 2020-04-26 23:14 (UTC)

https://www.reddit.com/r/VFIO/comments/eba5mh/workaround_patch_for_passing_through_usb_and/ There is A bit more discussion around it but I understand. Its not needed to get passthrough working

markzz commented on 2020-04-26 21:18 (UTC)

I usually take a hard line stance of not adding any patches except those introduced by the linux package. The goal of this patch-set is not to be an all encompassing kernel for various VM related issues, but instead is just what is needed to do VFIO and GPU passthrough.

As I've said before, there's nothing stopping you from making changes to the PKGBUILD for your own build of the kernel with whatever patches you want.

slowbro commented on 2020-04-26 21:13 (UTC)

@NovaMoon do you have any links to more discussion/reports around that issue (vs just a link to a patch)?

NovaMoon commented on 2020-04-26 20:57 (UTC)

Hello Is it possible to add another patch to the kernel? this is describing the patch.

Zen2 CPU users experiencing FLR timeout errors in dmesg when passing the USB or Audio controllers can use this patch to bypass the issue. Typically the host will also crash shortly after. This issue affects all AM4 300/400/500 series boards when fitted with new Zen2 CPUs. The workaround is to disable FLR reset until AMD fixes it on their end via AGESA/BIOS update. Kernel patch: https://clbin.com/OaR0H

markzz commented on 2020-04-24 13:57 (UTC)

beetlejuice: This package will not deviate from the ARCH kernel's config. If you want to change the options when you go to build, you are free to do so.

beetlejuice commented on 2020-04-24 09:18 (UTC) (edited on 2020-04-24 09:21 (UTC) by beetlejuice)

CONFIG_PREEMPT_VOLUNTARY=yes

CONFIG_PREEMPT is not set

Should be default settings for this package. I don't like waiting 30 or more seconds and 100% CPU usage just to start OVMF bios. If there is a better solution for long boot time with OVMF please advice me.

slowbro commented on 2020-04-19 05:05 (UTC)

@meshedpotato, you can simply edit the 'config' file in the tar.gz you download from AUR. If you're currently using an AUR helper to install (i.e. yay) you would have to abandon that in favor of manually building it. There's plenty of docs on the wiki about how to build an AUR package, so I'll skip the details; but for your specific situation, you'd:

  1. Edit the 'config' file and change whatever parameters you want
  2. run sha256sum config and replace the value in the PKGBUILD
  3. build the package

Best of luck!

meshedpotato commented on 2020-04-19 04:45 (UTC)

Hi Folks, any pointers on how i would be able to build with CONFIG_PREEMPT_VOLUNTARY=yes, the ACS patch has sorted out my IOMMU groups but I have large boot times.

I think I'm facing https://forums.unraid.net/topic/72172-unraid-os-version-653-available/

not sure where to start, Thank!

slowbro commented on 2020-04-10 02:00 (UTC)

the sphinx issue will be worked-around in 5.6.3, from upstream: link. building/testing now.

aknarts commented on 2020-04-09 07:31 (UTC) (edited on 2020-04-09 07:32 (UTC) by aknarts)

JuniorJPDJ: For the sphinx issue, another "fix" is to install python-sphinx-1 also fixes the issue, but might break other dependency so it is up to you which solution you chose. (It is an alternate dependency on the docs package)

markzz commented on 2020-04-08 17:12 (UTC)

Zauberfisch: I"m honestly going to unpin that comment as it should be expected that people read the wiki and know how to use makepkg before trying to build any packages.

JuniorJPDJ commented on 2020-04-08 14:01 (UTC)

If someone will have similar problem there's bug link to follow: https://bugs.archlinux.org/task/66156 I temporary removed line make htmldocs and removed $pkgbase-docs from loop at the end of PKGBUILD so it compiles again.

JuniorJPDJ commented on 2020-04-08 13:51 (UTC)

I've very weird problem with compilation of this package:

Running Sphinx v3.0.0                                                                                                 

Extension error:                                                                                                      
Could not import extension cdomain (exception: cannot import name 'c_funcptr_sig_re' from 'sphinx.domains.c' (/usr/lib/python3.8/site-packages/sphinx/domains/c.py))
make[1]: *** [Documentation/Makefile:81: htmldocs] Error 2                                                            
make: *** [Makefile:1549: htmldocs] Error 2 

Zauberfisch commented on 2020-04-08 04:29 (UTC)

@markzz: sorry. I wasn't actually asking, I know how to import a key or skip key checking. I just figured because there is a pinned comment for adding 2 of the 3 keys, it might be worth updating that message to include all 3 keys.

slowbro commented on 2020-04-08 04:18 (UTC) (edited on 2020-04-08 04:19 (UTC) by slowbro)

Not to dogpile, but I'd like to add "..or plug the error into google" :)

https://www.google.com/search?q=FAILED+unknown+public+key+A5E9288C4FA415FA

markzz commented on 2020-04-08 03:36 (UTC)

Zauberfish: Can you kindly read the wiki before being the 40,000th person to ask this?

Zauberfisch commented on 2020-04-08 03:20 (UTC)

I see the pinned comment saying I need to add 2 keys. But for me I still get an additional key error:

FAILED (unknown public key A5E9288C4FA415FA) ==> ERROR: One or more PGP signatures could not be verified!

seems the key for "Jan Alexander Steffens (heftig)" is also missing.

PrfStrwberry commented on 2020-04-04 22:31 (UTC)

@giostark seems I have to dig deeper. After booting the default arch kernel, the problem continues to exist.

giostark commented on 2020-04-04 16:36 (UTC) (edited on 2020-04-04 16:38 (UTC) by giostark)

@PrfStrwberry- I have a 7700K and differ for two instruction from your: Intel® vPro™ Platform Eligibility and Intel® Trusted Execution Technology. And to me the mitigations seems to work. In general mitigation come activate host side but is not mandatory that the guest will use them. Those security mitigations are for you really necessary? Are you using those for networking VMs. Seems not bios options are available in Asus firmware. Kernel side I'm a noob so I can't say a thing. Thanks slowbro and markzz for your work. Me too I could not make my stuffs without this kernel.

PrfStrwberry commented on 2020-04-04 14:29 (UTC) (edited on 2020-04-04 16:23 (UTC) by PrfStrwberry)

Hey thanks for keeping this package up to date. I could not do anything without it. I am using an i7 8700k with an ASUS Maximus X CODE. I just have a small problem, after compiling and installing everything. When I create a VM inside virt-manager, I cannot enable and apply the box at enable cpu flaw mitigations. After clicking and applying, the tickbox goes blank again. Any tips?

slowbro commented on 2020-03-28 19:10 (UTC)

ShayBox, it's unfortunately just the one little server on the west coast; it was probably busy with the binge watching I was doing on Plex last night. Should be okay now?

markzz commented on 2020-03-28 15:30 (UTC)

I'm going to set up my build system again and keep this package up to date as regards to this PKGBUILD to keep it up to date on my repository. The 5.5.13.arch1-1 is built and up on my repository.

markzz commented on 2020-03-28 04:41 (UTC)

This is my queue to actually use my work from home time and compile a new version of the package.

shaybox commented on 2020-03-28 01:54 (UTC)

slowbro your repo is running at a few hundred kbps

slowbro commented on 2020-03-27 18:23 (UTC)

Sorry for the update delay; I had made 5.5.10, but then forgot to push it. Then work-from-home happened and things have been cuh-ray-zee.

5.5.13 is up now. If anyone is using my repo, as an FYI, I have switched to zstd (.tar.zst).

I hope everyone is doing well.

slowbro commented on 2020-03-16 05:53 (UTC)

Got 5.5.9 out; note that this kernel is compiled w/ gcc 9.3.0; you may need to pacman -Syu before building the new version (I'm not entirely sure since I did a roundabout way). Either way, the pre-compiled version is available on my repo.

osakasys commented on 2020-03-15 15:09 (UTC) (edited on 2020-03-15 15:10 (UTC) by osakasys)

And now my graphics card I've attached for use with VFIO isn't initializing correctly. Looking deeper it seems like this is a kernel issue, but I don't know the cause. Looking through dmesg, I get this: pci-stub 0000:07:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff and some message saying it couldn't turn on the device. Is anyone else having these problems? I'm building the LTS version of this kernel in the hopes it fixes my problems. I'll edit my post as I find more information.

EDIT: I should mention that it's not the card itself since I booted into Windows 10 briefly with it and it appears to work fine.

osakasys commented on 2020-03-14 18:51 (UTC)

Seems my build wasn't working. If I use slowbro's build it works fine.

markzz commented on 2020-03-14 18:31 (UTC)

Did you try the regular arch kernel? This patchset does not touch anything regarding disk mounts.

osakasys commented on 2020-03-14 14:51 (UTC) (edited on 2020-03-15 15:13 (UTC) by osakasys)

Getting an error when using fusermount: fuse: missing mountpoint parameter

Everything I can find points to this being a kernel issue.

EDIT: This may be fixed in 5.6 due to this commit
EDIT2: This problem seems to have been fixed by using slowbro's build. I think my gcc and gcc-libs versions may have been to blame.

scootz commented on 2020-03-08 19:03 (UTC)

Thanks slowbro for providing the updated version. much appreciated.

markzz commented on 2020-02-27 01:59 (UTC)

When I get back to Michigan this weekend, I'll be making a build for my repository as well.

slowbro commented on 2020-02-26 23:21 (UTC) (edited on 2020-02-26 23:22 (UTC) by slowbro)

Like markzz was, I'm providing updated builds in my (unofficial) user repository, if you don't want to build this yourself.

Info here: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#slowbro

Signing key: 85186206

Details on importing a key for pacman are here.

slowbro commented on 2020-02-23 00:52 (UTC)

Thanks, markzz. I just published a better version of 5.5.5 now, with updated kernel config - so if you already installed 5.5.5.arch1-1 from below, be sure to update to 5.5.5.arch1-2 from aur. Same kernel, just matches the 'linux' package's config.

I'll keep my eye out for upstream updates and try to get them released ASAP.

markzz commented on 2020-02-22 14:53 (UTC)

I have just added slowbro as a co-maintainer to assist me in keeping this up to date when I get into busy seasons like I have been trying to crawl out of. Sorry about the lack of updates and hopefully the two of us can keep this up to date more effectively than I can alone.

slowbro commented on 2020-02-22 08:23 (UTC)

Patches applied as-is for 5.5.5; untested.. https://github.com/slowbro/linux-vfio/tree/v5.5.5-arch1

shaybox commented on 2020-02-19 08:43 (UTC)

@slowbro I used your patches to update linux-zen-vfio :thumbsup:

slowbro commented on 2020-02-17 01:48 (UTC) (edited on 2020-02-17 02:08 (UTC) by slowbro)

Here's the two latest versions. 5.5.4 seems to work just as well as 5.5.3.

5.5.4.arch1-1: https://github.com/slowbro/linux-vfio/tree/v5.5.4-arch1

5.5.3.arch1-1: https://github.com/slowbro/linux-vfio/tree/v5.5.3-arch1

@glostark happy to help.

giostark commented on 2020-02-16 22:50 (UTC)

TNKS slowbro for the instructions. It worked as you stated. ;-) The kernel boot fine and my VM for work is finally on again.

slowbro commented on 2020-02-16 22:43 (UTC) (edited on 2020-02-16 22:49 (UTC) by slowbro)

Okay, the sha256sums are fixed: https://github.com/slowbro/linux-vfio/tree/v5.5.3-arch1

I just git push --force'd because I am a bad person.

BTW: 5.5.4.arch1 built successfully, I'm testing a full makepkg now.

slowbro commented on 2020-02-16 21:56 (UTC)

Ah, whoops.. I had reorganized the patches to make the diffs smaller and forgot to re-hash. I'll fix that asap, but in the mean time you can update the sha256sum lines in the PKGBUILD. Just run 'sha256sum *.patch' to get the new ones. The sum array has the hashes in the same order as the sources array.

giostark commented on 2020-02-16 21:52 (UTC)

Thanks for you time and work... :-)

I receive this : ==> Validating source files with sha256sums... archlinux-linux ... Skipped config ... Passed add-acs-overrides.patch ... FAILED i915-vga-arbiter.patch ... FAILED ==> ERROR: One or more files did not pass the validity check!

Tried to delete the files and re-download , happen the same.

slowbro commented on 2020-02-16 21:09 (UTC) (edited on 2020-02-16 22:50 (UTC) by slowbro)

Alright, everything seems to be working on 5.5.3.arch1. I had switched to .3 because I noticed yesterday .4 was still in -testing.. but now .4 is out. This should just work with 5.5.4, you'll just need to change the PKGBUILD pkgver line. The patches apply cleanly. I'm compiling it now for 5.5.4 and will report back with results.

For now, enjoy 5.5.3.arch1: https://github.com/slowbro/linux-vfio/tree/v5.5.3-arch1

(Note: I make no guarantees, minimally tested,etc. My IOMMU groups are identical with this as they were with 5.3.7-arch1. I was able to boot my windows VM and it worked.)

alegru commented on 2020-02-16 13:57 (UTC)

I backported the changes to the linux-vfio-lts package, if someone wants to use it in the mean time

slowbro commented on 2020-02-15 20:31 (UTC)

I've been working on a PKGBUILD based on 5.5.4-arch1. I got the patches re-worked for all the recent intel_vga changes, and things seem good, I'll update later this weekend with a yay/nay.

arkaid commented on 2020-02-14 11:09 (UTC)

Does anybody know of a good tutorial on how to apply the patches by hand?

I usually rely on markzz to update the package, since I don't know how to do it myself, but I need to update the kernel soon.

shaybox commented on 2020-02-13 18:58 (UTC)

@aknarts This kernel is too out of date to work with most up to date dkms modules now.

aknarts commented on 2020-02-12 20:42 (UTC)

Anybody has an elegant solution to "incompatible gcc/plugin versions" when building dkms modules(namely nvidia-dkms)?

JuniorJPDJ commented on 2020-02-03 07:11 (UTC)

Don't worry. I'm just making sure you remember :D

markzz commented on 2020-02-03 06:10 (UTC)

I only forgot a little bit. I did some traveling over the last week and didn't have time to get to it. I will make every attempt to get to this in the next week, but sometimes life gets busy.

JuniorJPDJ commented on 2020-02-03 04:57 (UTC) (edited on 2020-02-03 04:57 (UTC) by JuniorJPDJ)

Next weekend just finished and new linux major version came. Do you remember about us? ;)

markzz commented on 2020-01-22 07:37 (UTC)

Yeah, that's on me. I'll put it on my TODO list for this weekend.

thearcherblog commented on 2020-01-22 06:05 (UTC)

Hello,

This package has been flagged out-of-date for some time... any news about updates?

Thanks a lot!

Zackptg5 commented on 2020-01-05 08:10 (UTC) (edited on 2020-01-05 08:12 (UTC) by Zackptg5)

Just thought I'd add this in here For those looking to compile for 5.4.6.2:

Change pkgver in PKGBUILD

Replace add-acs-override.patch with updated one listed in a previous comment

Modify i915-vga-arbiter.patch as follows:

  • For last diff, change all instances of intel_drv.h to display/intel_display.h

  • Change 1457 to 432 (line numbers beneath above)

Finally update sha256 as needed in PKGBUILD

NeoTheFox commented on 2019-12-14 16:05 (UTC)

So if anyone needs a newer patch it's here https://gitlab.com/Queuecumber/linux-acs-override/raw/master/workspaces/5.4/acso.patch

markzz commented on 2019-12-03 17:59 (UTC) (edited on 2019-12-03 18:01 (UTC) by markzz)

jklc: https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux

They are makedepends as well, you can remove them after building.

jklc commented on 2019-12-03 17:47 (UTC)

5.3.13(1ec4cb075348) wants the following additional dependencies:

Packages (32) gd-2.2.5-2 ghostscript-9.50-2 giflib-5.2.1-1 gsfonts-20180524-2 gts-0.7.6-5 ijs-0.35-2 jbig2dec-0.17-1 libidn-1.35-2 liblqr-0.4.2-2 libpaper-1.1.24-11 libraqm-0.7.0-1 libwebp-1.0.3-1 openjpeg2-2.3.1-1 python-babel-2.7.0-3 python-docutils-0.14-4 python-imagesize-1.1.0-3 python-jinja-2.10.3-3 python-markupsafe-1.1.1-3 python-pygments-2.5.2-1 python-pytz-2019.3-3 python-snowballstemmer-2.0.0-3 python-sphinx-alabaster-theme-0.7.12-3 python-sphinxcontrib-applehelp-1.0.1-4 python-sphinxcontrib-devhelp-1.0.1-4 python-sphinxcontrib-htmlhelp-1.0.2-4 python-sphinxcontrib-jsmath-1.0.1-4 python-sphinxcontrib-qthelp-1.0.2-4 python-sphinxcontrib-serializinghtml-1.1.3-4 graphviz-2.42.3-1 imagemagick-7.0.9.7-1 python-sphinx-2.2.1-2 python-sphinx_rtd_theme-0.4.3-3

why?

jklc commented on 2019-10-29 01:07 (UTC)

It was a mce Hardware Error. I have since installed rasdaemon and updated the intel microcode to the latest(0xae). 5.3.7.arch1-1 has been running smoothly for the past 18 hours.

markzz commented on 2019-10-28 15:21 (UTC)

jklc: I cannot confirm this issue. The kernel appears to be working fine on my machine. The only difference I can think of is I do not use an Intel iGPU on the host.

jklc commented on 2019-10-27 22:06 (UTC)

Tried 5.3.7.arch1-1 on a Z390/9700k today with the lated -Syu pull. KVM/qemu Windows 10 guest with NVidia 2080Ti passthrough is running with some glitch and crashed the arch host within 60 minutes. Still investigating the cause. The last stable working version of linux-vfio for me has been 5.0.13-arch1-1 (f483bc1a95dc)

markzz commented on 2019-09-21 04:19 (UTC)

I will not update this package until I have made the necessary modifications to all patches.

shaybox commented on 2019-09-21 04:02 (UTC)

Looks like the i915 vga patch is broken 5.3+, gonna have to be removed until someone produces a new modified patch to patch the patch

markzz commented on 2019-09-08 03:00 (UTC)

dszryan: put that in your makepkg.conf....................

dszryan commented on 2019-09-08 02:58 (UTC)

the build could do with: build() { cd $_srcname make -j $(($(cat /proc/cpuinfo | awk '/^processor/{print $3}' | wc -l) + 1)) bzImage modules }

to speed the build up, #jobs = #processors + 1

what do you think?

Youngsie97 commented on 2019-07-30 15:25 (UTC) (edited on 2019-07-30 15:25 (UTC) by Youngsie97)

Just wanted to comment to thank ironicbadger and also confirm their findings I was having issues in particular with discord and FF14(FFXIV) crashing and losing sound randomly rolling back to 4.19-20 via LTS package appears to have fixed these issues.

ironicbadger commented on 2019-07-22 04:02 (UTC)

I was running into some issues with 5.2.1 kernel today in a Windows 10 guest where 3d apps (such as Firefox, Chrome and Fusion 360) would just randomly quit.

According to my research I found the following on the VFIO discord

A new bug in kernel 5.2 is causing KMODE_EXPECTION_NOT_HANDLED and other anomalies for some people. A few folks reporting artifacting/crashing issues on 5.1 say that issue persists on 5.2 as well, but this is may be a different bug. Root cause of both issues remains unknown currently. Rollback to the last known good or LTS kernels.

I downgraded to 4.19.x via the linux-vfio-lts package and stability returned to my guest. Hope this helps someone out.

markzz commented on 2019-07-10 17:19 (UTC)

If this is a requirement for you, you will need to add this patch yourself when you build.

igno2k commented on 2019-07-10 11:00 (UTC)

Any chance to add the Agesa Patch? https://clbin.com/VCiYJ

Also see: https://forum.level1techs.com/t/attention-amd-vfio-users-do-not-update-your-bios/142685

giostark commented on 2019-05-09 15:58 (UTC) (edited on 2019-05-09 16:07 (UTC) by giostark)

I am getting the following build error:

 Extension error:
Could not import extension kerneldoc (exception: cannot import name 
'AutodocReporter' from 'sphinx.ext.autodoc' (/usr/lib/python3.7/site-packages/sphinx/ext/autodoc/__init__.py))

As the same here: https://aur.archlinux.org/packages/linux-rt-bfq/

Following those patch instructions I deleted some lines in the PKGBUILD and I'm now compiling.

https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=cfe52e9aa8168d9571bedf8a376e2cfbd25223fd

markzz commented on 2019-04-25 18:43 (UTC)

PiMaker101: One of the goals of this package is to model it after the standard linux package in the official repositories. This includes configuration options. This does not, however, stop you from changing the config yourself when you build it though.

PiMaker101 commented on 2019-04-25 18:16 (UTC)

Tested with 5.0.9 by changing the git tag in the PKGBUILD, working fine, including testing with QEMU 4.0. Noteworthy though, that I had to disable building the doc package (removed htmldocs from make), since there was a build error with sphinx.

By the way, I think it might be a good idea to change the default kernel config in this package to enable voluntary preemption (CONFIG_PREEMPT_VOLUNTARY=y), since this fixes a bug with QEMU/OMVF boot times when configured with a lot of RAM/cores (see https://forums.unraid.net/topic/72172-unraid-os-version-653-available/). Personally using this configuration, have not noticed any side-effects or performance losses on the host so far.

Youngsie97 commented on 2019-03-24 10:56 (UTC)

Just wanted to say that In regards to jmandawg and markzz that I have been updating by just changing the versions for about a week now (starting with 5.0-1) with no unexpected behaviour or side effects. Although I should state I haven't done any deep testing outside of just running my normal vms etc.

markzz commented on 2019-03-24 04:26 (UTC) (edited on 2019-03-24 04:40 (UTC) by markzz)

jmandawg: You can certainly try just changing the PKGBUILD with no new patches, but I would bet on the fact that the current patches will not work. The issue is, it's on my list of things I have to get done, but that list has grown in the last few months to the point where I'm trying to catch up. No ETA at this moment.

EDIT: I take it all back, it looks like the patches did apply, so I'm running a build and will quickly test it tomorrow.

jmandawg commented on 2019-03-24 02:46 (UTC)

Thanks for the great work, 5.0.x coming anytime soon? Or is it safe to change the _srcver and rebuild?

NeoTheFox commented on 2018-12-12 20:10 (UTC)

The latest version (4.19.8-arch1-1-vfio) has build error due to patch:

drivers/pci/quirks.c:4617:28: error: ‘pci_acs_overrides’ undeclared here (not in a function); did you mean ‘pcie_acs_overrides’? { PCI_ANY_ID, PCI_ANY_ID, pci_acs_overrides }, ^~~~~~~~~~~~~~~~~ pcie_acs_overrides

markzz commented on 2018-12-12 16:30 (UTC)

I have pushed something that the patches apply, but I haven't tested the package itself.

markzz commented on 2018-12-12 14:09 (UTC) (edited on 2018-12-12 15:24 (UTC) by markzz)

whight: The vga arbiter patch does not apply in 4.19.x.

Applying: i915: Add module option to support VGA arbiter on HD devices (4.17)
error: patch failed: drivers/gpu/drm/i915/i915_params.c:133
error: drivers/gpu/drm/i915/i915_params.c: patch does not apply
error: patch failed: drivers/gpu/drm/i915/i915_params.h:58
error: drivers/gpu/drm/i915/i915_params.h: patch does not apply
error: patch failed: drivers/gpu/drm/i915/intel_display.c:15402
error: drivers/gpu/drm/i915/intel_display.c: patch does not apply

whight commented on 2018-12-12 08:36 (UTC)

You shouldn't have any troubles using the patch in your sources for 4.19.8. Built and tested it myself with linux from the core repo. If you'd like, I can help keep this maintained.

markzz commented on 2018-12-05 14:00 (UTC)

archqemu: I try to keep up to date with regards to whatever version is in [core]. The problem is, on version releases (e.g. 4.14 -> 4.15), I often have to rewrite the patches (this isn't normally a problem on patch releases like 4.16.7 -> 4.16.8). Because I'm both a full time student and work full time as a software engineer, I am sometimes unable to set aside enough time to update the patches and I get to it when I can. The semester is almost over at the time of this comment, so I should be able to set aside time for sure then, if not sooner.

archqemu commented on 2018-12-05 13:51 (UTC) (edited on 2018-12-05 13:51 (UTC) by archqemu)

okay cool, thanks for your quick reply!

I was just curious if there is any systematic release schedule related to the kernel releases.

markzz commented on 2018-12-05 10:14 (UTC)

archqemu: When it's done.

archqemu commented on 2018-12-05 10:07 (UTC) (edited on 2018-12-05 10:07 (UTC) by archqemu)

When can we expect an update of this package?

jmandawg commented on 2018-10-29 17:51 (UTC)

Awesome thanks markzz, I didn't know this, i'm still a bit of a noob (switched from debian) i'm going to try this for the next kernel update. Thanks again.

markzz commented on 2018-10-29 14:44 (UTC)

jmandawg: This is because when you boot this kernel without building the dkms module for it, it will of course not work. Because this is information any user of DKMS should know about, I don't see a reason to pin a comment about that.

I think this is something that you should read what the wiki states on DKMS because it actually lays out the steps to make sure the module is built for your kernel in use and does not require a reinstall of the nvidia-dkms package.

https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support

jmandawg commented on 2018-10-29 14:36 (UTC) (edited on 2018-10-29 14:37 (UTC) by jmandawg)

Someone should sticky the comment by (erylflynn commented on 2016-04-21 17:23 (edited on 2016-07-28 04:34 by erylflynn))

Installing this new kernel will break Xorg if you are using nvidia-dkms, but a re-install of nvidia-dkms fixes it.

Unfortunately there is no way to search the comments on here.

MurkyDepths commented on 2018-09-08 22:00 (UTC)

Sorry it took so long to reply, got busy with some other stuff.

I've done with and without AUR helpers. Pacaur seemed to work fine, without was a 70/30ish of it working or not. Over the course of some ten+ installs about 3 or 5 ended up working. Without doing anything different before the install.

Essentially, I have no idea what the problem is.

markzz commented on 2018-09-05 03:11 (UTC)

The -headers and -docs packages are not required to use the base package. The headers package are just that, headers for developers that need them. The docs package is also just that, documentation for the kernel and you don't need them to run the kernel.

If you are using an AUR helper, don't. They are not supported and I will not even entertain issues with packages built with them. Try building using makepkg alone and if that doesn't work, use a clean chroot (check the wiki).

If you really want to try a known good built package done in a clean chroot, you can try the package in my public repository. Again, check the wiki. I know for a fact that this PKGBUILD is known to work as I use it every day with no issue (and on an Nvidia card with the nouveau drivers).

MurkyDepths commented on 2018-09-04 18:20 (UTC)

When I install it asks if I want to install linux-vfio-headers and docs. They should be installed, but I don't even know. I'll go test that when I have time. If headers aren't installed that's likely the problem, if they are I'll get the version number. I'll also check dkms as you mentioned. And if anything doesn't really work, I'll try rebuilding it.

erylflynn commented on 2018-09-04 17:40 (UTC)

Only time I saw anything like this was when the kernel was built but the headers was not. I tried a new AUR tool and it only built the linux-vfio package, not linux-vfio-headers. Once I rebuilt everything making sure the headers installed it worked.

Check linux-vfio-headers installed version. Also "dkms status" to show if the module for your video drivers was built. If not force dkms to rebuild and see what happens.

MurkyDepths commented on 2018-09-04 17:32 (UTC)

I've searched as extensively as I could manage. Every time was a fresh install. With or without nvidia drivers. Blacklisting nouveau or nvidia, setting a default output card does nothing, binding the card with pci-stub and/or vfio-bind doesn't change anything. Different desktop managers changes nothing, reinstalling desktop managers and Xorg doesn't change anything. Haven't found anything special in the logs I've looked at or using dmesg(or whatever it's called, I can't recall). If there are any other drivers I need to worry about I don't know which ones they are.

Honestly I'm at my wits end, I'm far from a veteran but I'm at least a decently good user, but nothing special. Though searches on google and scouring wikis and forums I haven't found anything that solves it. I've found ones with similar problems to mine, but either with no solution or one that doesn't work for me.

Is there a way to log the installation process of linux-vfio? I've noticed some red text pop up here and there, but am not sure how to get my hands on it. Only thought of that during my writing of this. Usually, at the end, or close to it, there is usually a rather large red block of text, probably ten lines at the very least. I have no idea if these are errors or not, but if I can get my hands on that log it might help solving whatever problem is causing this. Whether that's a hardware issue or software I can't say.

markzz commented on 2018-09-03 16:25 (UTC) (edited on 2018-09-03 16:27 (UTC) by markzz)

MurkyDepths: Did you check the Wiki, the forums, Google?

I can tell you this kernel is working fine on at least my system. Check your drivers, check your logs, etc...

MurkyDepths commented on 2018-09-03 13:45 (UTC)

For some reason installing this now kills graphical boot and it’s stuck on a blackscreen with a blinking cursor. Non-graphical boot works fine though. Have you encountered this before? If so, do you know of a way to fix it?

MurkyDepths commented on 2018-08-30 15:42 (UTC)

Sorry, I'm like maybe day one on arch so I have little to no idea how AUR works properly. Though I'm learning, it doesn't stop me from being stupid.

markzz commented on 2018-08-30 14:59 (UTC)

The answer to that question is always "When it's done."

Also, seeing as this PKGBUILD is on 4.18.4 right now tells you something about your question...

MurkyDepths commented on 2018-08-30 14:23 (UTC) (edited on 2018-08-30 14:31 (UTC) by MurkyDepths)

Is the patch available to 4.18.*? If it isn't, how long do you think it'll be until it's updated?

markzz commented on 2018-08-25 19:24 (UTC)

jugs: Usually that's the case, but this time I'm just being slow.

jugs commented on 2018-08-25 00:12 (UTC)

Does the patch not work on 4.18?

codekoala commented on 2018-08-13 16:30 (UTC)

Looks like recompiling this package did the trick for me.

codekoala commented on 2018-08-13 15:33 (UTC)

I'm having problems with nvidia-dkms and this package:

==> dkms install nvidia/396.24 -k 4.17.3-1-vfio Error! Bad return status for module build on kernel: 4.17.3-1-vfio (x86_64) Consult /var/lib/dkms/nvidia/396.24/build/make.log for more information.

I'm not sure when the problems started happening, but it's probably started within the last week. Anyone else having issues with nvidia drivers failing to install for this kernel lately?

I'm trying to get operational again by trying combinations of different kernel and nvidia versions. Still no luck yet.

markzz commented on 2018-06-09 15:59 (UTC)

DocMAX: That line appears to be doing a job. Removing it would make me feel uneasy and without further information, I will not remove it.

You are free to do so when you build it though. The details of that reddit post also show that the person was using an Atom/Pentium/Celeron with a possible ACS cap and that line should absolutely not be removed.

If you want to discuss it with me further, I'd recommend turning to email and contacting me directly, especially if you have more information that will change my mind.

DocMAX commented on 2018-06-09 15:26 (UTC)

Could you remove the line described here?:

https://www.reddit.com/r/VFIO/comments/63j1p7/any_ideas_why_all_pcie_ports_are_assigned_to_the/?st=ji7jr7e9&sh=a6f321b2

markzz commented on 2018-05-30 23:33 (UTC)

I'll add it soon then.

moffat commented on 2018-05-30 22:39 (UTC)

This patch was needed to enable ACS override on my machine using an i7-7260U

https://lkml.org/lkml/2018/4/25/1194

giostark commented on 2018-05-09 19:00 (UTC)

@Fleetscut ...damn TNX. Im a noob in linux so I was stuck thinking that was a nvidia problem. After the last gcc-8.1.0 I wasn't able to reinstall the nvidia-dkms module. By the way the virtual machine and the pci pass through worked fine, was only the host to have a 800x600 resolution ^_^ For the moment ill blacklist the new gcc.

Fleetscut commented on 2018-05-08 01:09 (UTC)

i cant seem to build this kernel with gcc-8.1.0. i keep getting a message that mv cannot stat the temp directory that is being used to build. happens no matter where i point the build directory. i had to downgrade to my last version of gcc to get it to work.

markzz commented on 2018-04-13 15:59 (UTC)

When you build this PKGBUILD, you will get the three packages. As for how pacaur or ANY other aur helper works, I cannot say.

mcardillo55 commented on 2018-04-13 07:16 (UTC)

Does the kernel need to be rebuilt to install linux-vfio-headers? For example, I run pacaur -S linux-vfio, it compiles and installs the kernel. Then I run pacaur -S linux-vfio-headers, it compiles the kernel again before installing the headers. Aren't the headers just extracted from the tarball?

Thanks

markzz commented on 2018-04-06 16:30 (UTC)

Dehir: What?

Dehir commented on 2018-04-06 15:18 (UTC)

IF there is every possible to get realtime kernel with vfio same time :P

markzz commented on 2018-03-08 21:25 (UTC)

If either of you can get a core dump, I can investigate, but I don't know what else to tell you because I do not have the same hardware as you.

c3924754 commented on 2018-03-08 21:19 (UTC)

I can also confirm that with 4.11.4+ I cannot start my VMs that have a dedicated GPU. Experiencing output very similar to @cinna .

markzz commented on 2018-02-10 01:51 (UTC)

cinna: None of those functions in the call trace are in the patches that this kernel provide. I would either file a bug with Arch or with upstream.

cinna commented on 2018-02-10 01:39 (UTC) (edited on 2018-02-10 01:41 (UTC) by cinna)

I'm having a similar issue as zatricky where a VM refuses to launch when I have a dedicated gpu attached. Here's a relevant dmesg when I attempt to launch it. As for my hardware I'm running a Ryzen processor with a dedicated GPU for my host and another for my VMs

https://gist.github.com/anonymous/650925d4d58f7fd689b951f99c5d35f5

markzz commented on 2018-02-09 19:46 (UTC) (edited on 2018-02-09 20:02 (UTC) by markzz)

zatricky: Are you using an Intel iGPU for the host? Also, some relevant dmesg output would be helpful.

zatricky commented on 2018-02-08 20:19 (UTC) (edited on 2018-02-08 20:24 (UTC) by zatricky)

Latest package 4.15.1-1 resulted in sporadic errors from libvirtd when attempting to launch VM with dedicated GPU: Feb 08 22:08:04 <hostname> libvirtd[612]: 2018-02-08 20:08:04.406+0000: 612: error : virNetSocketReadWire:1808 : End of file while reading data: Input/output error</hostname>

Other VMs (not using GPU) were functional. From the moment I attempted to start the dedicated-GPU VM, virsh commands would no longer complete and virt-manager would become unresponsive.

Downgraded to 4.14.11-1 - all is working again.

  • Z68MA-G45 (MS-7676)
  • i7 3770
  • AMD Radeon R9 380

markzz commented on 2018-02-07 21:23 (UTC) (edited on 2018-02-08 03:42 (UTC) by markzz)

Sorry about the lack of updates (if only I had unlimited time). I am currently building and testing 4.15 and you can expect it by this coming Friday.

EDIT: It is up and I need i915 users to tell me if everything's okay.

fr3dx commented on 2018-01-24 12:06 (UTC) (edited on 2018-01-24 12:06 (UTC) by fr3dx)

Hiya, how can I use this kernel on Manjaro Linux? ty

markzz commented on 2017-12-14 06:10 (UTC)

(4.14.5+) Because Arch itself has dropped i686 support, I have removed i686 from the PKGBUILD and there is no config file either.

abrilevskiy commented on 2017-12-06 06:26 (UTC)

I use Nvidia cards and Intel hardware and in order to get it working - ACS patch is required. Therefore AGESA update will not eliminate for ACS.

cinna commented on 2017-12-05 17:29 (UTC)

The NPT patch is included in the kernel as of 4.13.3 for you AMD people. When the upcoming AGESA update releases we probably won't even need this ACS patch anymore either ^_^

markzz commented on 2017-12-03 00:46 (UTC)

Almost always a minor release causes the patches to need to be rewritten. I'll be getting on this soon.

timofonic commented on 2017-12-02 23:02 (UTC)

Any news about 4.14? I tried to apply i915-vga-arbiter.patch to linux-drm-tip-git without success :(

markzz commented on 2017-11-27 02:42 (UTC)

marandus: WHOOPS! Thanks for catching that. I will fix. timofonic: If you require the features the patches provide, yes, the patches will be required for 4.14. I will not update this PKGBUILD until linux 4.14 is released in core. fantacinni: That patch is not what this PKGBUILD is trying to do. If you need/want that patch in the kernel you build for your system, you can add it yourself. I don't think it's necessary to turn this PKGBUILD into the catch-all VM set.

fantacinni commented on 2017-11-26 18:37 (UTC)

Patch request Would you add the AMD SVM performance fix patch? https://level1techs.com/article/patch-npt-ryzen-better-performance Thanks!

timofonic commented on 2017-11-26 14:23 (UTC) (edited on 2017-11-26 14:25 (UTC) by timofonic)

4.14 available. Are patches still required in 4.14.x?

marandus commented on 2017-11-25 20:21 (UTC)

Is there any specific reason why the add-acs-overrides.patch contains in line 121 a check for a semicolon if (*p != ';') { instead of a colon? if (*p != ':') { The semicolon check prevents single ID ACS overrides to be possible, always fails with error message "PCIe ACS invalid ID". The patch you find via google has a colon check there, which is actually the only check that makes sense at that line.

markzz commented on 2017-10-28 17:51 (UTC) (edited on 2017-10-28 18:00 (UTC) by markzz)

Kalinda: That is a patch that is irrelevant to what this package is doing. This package only fixes the specific issues related to ACS and Intel VGA arbitration along with general kernel bug fixes. This is not a catch-all patch set for all VM problems.

Kalinda commented on 2017-10-28 16:58 (UTC)

Hello, Would it be possible to get the new patch that fixes the NPT bug for the AMD folks included in this packages? It's here - https://patchwork.kernel.org/patch/10027525/ I and a few other people from the VFIO reddit/discord have tested it and it works amazingly well, we can finally game in our VMs now. I do have a PKGBUILD all lined for this and was going to submit it, but since we have this package it seems like it'd be better to just include the patch here. I'd be happy to test any future changes made to it to ensure they work. Thanks

markzz commented on 2017-10-27 19:25 (UTC) (edited on 2017-11-27 03:03 (UTC) by markzz)

Just an update, I've been not uploading new versions of this package due to a problem with USB devices. This problem should be fixed by a patch that I am testing right now. If it works, you'll see 4.13.9 uploaded today.

hondaciv commented on 2017-10-03 02:27 (UTC)

==> Starting package_linux-vfio-headers()... install: cannot stat 'Documentation/DocBook/Makefile': No such file or directory ==> ERROR: A failure occurred in package_linux-vfio-headers(). I have this same error.

codekoala commented on 2017-10-01 20:27 (UTC)

I keep getting the following error when trying to build this package (both with pacaur and manually): ==> Starting package_linux-vfio-headers()... install: cannot stat 'Documentation/DocBook/Makefile': No such file or directory ==> ERROR: A failure occurred in package_linux-vfio-headers(). Aborting... It only appeared with the most recent update (afaik).

markzz commented on 2017-09-25 13:33 (UTC)

Not until it is released in [core].

danalec commented on 2017-09-25 06:05 (UTC)

thanks for the hard work any chances to get updates based on 4.13?

markzz commented on 2017-07-30 02:55 (UTC)

I updated to 4.12.3-1 and had to redo the patches. As always, let me know if this breaks your system (not meaning that third party modules don't work).

markzz commented on 2017-07-18 16:55 (UTC)

Did you verify that the dkms hook built it for this kernel?

Xanatos commented on 2017-07-16 01:36 (UTC) (edited on 2017-07-16 02:16 (UTC) by Xanatos)

Does this require me to not be using the nvidia proprietary drivers? Whenever I use this kernel it stops during the boot up process, also when compiling the kernel it mentions missing some nvidia modules. I am using 1080 ti cards. edit: Well I installed the nvidia-dkms package and the LTS verison boots. This one still doesn't but for now I can play around with the LTS verison.

flack commented on 2017-07-03 22:27 (UTC)

For me linux-vfio 4.11.8-1 not work with intel VGA at host. I roll back to 4.11.6-2-vfio version.

markzz commented on 2017-06-23 00:06 (UTC)

Sorry about the lack of updates, I've been enormously busy lately. I will try really really hard to get the patches updated to 4.11.x this weekend, but will get them done by the end of next week for sure.

markzz commented on 2017-05-01 15:42 (UTC)

sheenik: Are you using an Intel integrated video for your host? If not, then the arbitration patch does nothing for you. I can also say that this package does work as expected on my system, but I do not use an Intel video device.

spheenik commented on 2017-05-01 07:30 (UTC) (edited on 2017-05-01 07:31 (UTC) by spheenik)

Arbitration patch (I suppose) seems not to work on 4.10-11 kernel. VM starts, but passed through GPU never turns on, and VM will remain stuck in this state. Reverting to a 4.8 vfio kernel resolves the issue.

markzz commented on 2017-03-16 02:53 (UTC) (edited on 2017-03-16 03:04 (UTC) by markzz)

Spartus: You shouldn't need this package if you're using an AMD chip. That is one of the few advantages of them (I kid I kid). ;-) On a side note, it takes me over an hour on my i7-4790K and I usually set it to compile when I go to bed. I also do provide this package on my repository, in the case you do actually need this package and you don't want to take the time to compile it (scroll down in the comments feed for more info).

Spartus commented on 2017-03-16 02:14 (UTC)

Thanks markzz. While I do appreciate that compile time is directly a function of computer speed, of course, it seems especially long for a brand new Ryzen 7 (although I fear baiting a conversation of AMD vs. Intel). Regardless, does 4+ hours seem reasonable based on other's experience?

markzz commented on 2017-03-15 17:30 (UTC)

Spartus: On a slow computer, this will take a while to compile.

Spartus commented on 2017-03-15 15:50 (UTC) (edited on 2017-03-15 17:16 (UTC) by Spartus)

Um,I just got a new system with IOMMU and wanted to install this... it has been compiling for 4 hours now. Is this normal? Certainly not what I expected. Update: ended in failure... CC drivers/md/dm-log-userspace.mod.o LD [M] drivers/md/dm-log-userspace.ko CC drivers/md/dm-log-writes.mod.o LD [M] drivers/md/dm-log-writes.ko CC drivers/md/dm-log.mod.o LD [M] drivers/md/dm-log.ko CC drivers/md/dm-mirror.mod.o gcc: internal compiler error: Segmentation fault (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions. make[1]: *** [scripts/Makefile.modpost:114: drivers/md/dm-mirror.mod.o] Error 4 make: *** [Makefile:1198: modules] Error 2 ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build linux-vfio. ==> Restart building linux-vfio ? [y/N]

markzz commented on 2017-03-05 20:44 (UTC) (edited on 2017-03-05 20:54 (UTC) by markzz)

I have built kernel 4.10.1 with some updated patches and if you would like to test them out (and please do), you can find both binary and source packages here [1]. I especially would like people who rely on the i915 arbitration patch to test it since I don't use that part. As always, test at your own risk. [1] http://duna.markzz.net/linux-vfio-4.10/

markzz commented on 2017-03-03 19:06 (UTC) (edited on 2017-03-05 20:00 (UTC) by markzz)

jpbd: *grumble* Usually minor releases of Linux do this, still is annoying though to rewrite the patches. I also do pay attention to linux in [core] before upgrading this package.

jpbd commented on 2017-03-02 08:58 (UTC) (edited on 2017-03-02 09:04 (UTC) by jpbd)

@markzz I was doing some testing on linux 4.10, I know it is still in testing there are significant changes. 1. change-default-console-loglevel.patch This patch has been dropped. https://bbs.archlinux.org/viewtopic.php?id=223686 2. i915-vga-arbiter.patch Patch is not working. Hunk #2 FAILS 16370 Problem Child: This is from linux-4.10/drivers/gpu/drm/i915/intel_display.c void i915_redisable_vga_power_on(struct drm_i915_private *dev_priv) { i915_reg_t vga_reg = i915_vgacntrl_reg(dev_priv); if (!(I915_READ(vga_reg) & VGA_DISP_DISABLE)) { DRM_DEBUG_KMS("Something enabled VGA plane, disabling it\n"); i915_disable_vga(dev_priv); } } I tried to change to patch to resemble this but it didn't work. So I'm lost. Not sure if it is needed anymore anyways. 3. add-acs-overrides.patch It seems as if the Documentation in the Linux-4.10/Documentation/ has changed from Documentation/kernel-parameters.txt to Documentation/admin-guide/kernel-parameters.txt. Making this makes the patch pass successfully. 4. Need to update the config config.x86_64 is needed. Hope this helps thing for the near future. Send me some feedback.

f4bio commented on 2017-02-04 05:53 (UTC)

I updated this package (to v4.9.7) somewhat (no VGA arbiter patch): https://github.com/f4bio/aur-linux-vfio (also, my first ever kernel build, feedback would be very much appreciated)

markzz commented on 2017-01-27 16:44 (UTC) (edited on 2017-01-29 20:15 (UTC) by markzz)

Well, this package is normally updated when Arch updates it's version of linux in core. It looks like they have released 4.9.6-1 only hours ago and I haven't had the time to look at it and see if the patches work. I have been updating the package on my repository along the 4.8.x releases. EDIT: The patches don't work again so I have to rewrite them again.

simpleauthority commented on 2017-01-27 09:42 (UTC)

Will this continue to be updated? Very useful.

markzz commented on 2016-11-28 16:25 (UTC)

dominicm: Some aur helpers seem to not be able to handle split packages. When it encounters them, they seem to add the packages that are produced multiple times which causes pacman to error. You can see this first hand if you run makepkg on a PKGBUILD then do `pacman -U pkg-ver.pkg.tar.xz pkg-ver.pkg.tar.xz`. Yaourt doesn't do this, but it has an issue that it will build this PKGBUILD three times if you do a `yaourt -Sua` which could get annoying very quickly.

dominicm commented on 2016-11-23 13:58 (UTC)

@soul Thanks, yaourt does indeed work though it's annoying to have to use it just for the kernel. Hopefully someone can shed some light on this issue.

s0ul commented on 2016-11-22 18:30 (UTC)

@dominicm, I had that same issue several times with packer and pacaur but using yaourt -S linux-vfio works as intended. This may not be the solution you want but it's something.

dominicm commented on 2016-11-22 17:57 (UTC)

I am getting duplicate target error after which the kernel is downloaded again and compiled and so on and on. This has happened with the last 5+ releases. Have to install manually which is annoying with frequent updates. Using packer -S to install. Anyone else having this problem? root Password: loading packages... error: 'linux-vfio-headers-4.8.8-1-x86_64.pkg.tar.xz': duplicate target error: 'linux-vfio-docs-4.8.8-1-x86_64.pkg.tar.xz': duplicate target

markzz commented on 2016-10-23 18:32 (UTC)

I have updated the package on my repository to 4.8.4. If you want to build this yourself, since the patches needed to be redone in order for it to work, I have uploaded a source package for anyone to use [1]. Feel free to use either and I will continue to keep both updated if this PKGBUILD falls behind again. [1] http://arch.markzz.com/linux-vfio-4.8.4-1.src.tar.gz

dominicm commented on 2016-10-21 00:22 (UTC)

@Myd Sorry for late reply, That's what I have too and nothing else as far as vfio config. It's probably due to different hardware, I am using Asus Z170 Deluxe with 6700k cpu.

Myd commented on 2016-10-05 15:46 (UTC)

@dominicm what kernel params are you using? I have: "intel_iommu=on pcie_acs_override=downstream" and each of my devices is in separate IOMMU group

dominicm commented on 2016-09-30 15:22 (UTC)

@Myd Updating to 4.7.4-1 seems to have fixed it, I don't think I changed anything else. The group is still not clean as I have 3 other devices in it but I am able to passthrough anyways. IOMMU worked just fine before it was just this one device.

Myd commented on 2016-09-29 19:37 (UTC)

@dominicm I just updated to 4.7.4 and IOMMU groups look fine, you can check with "dmesg | grep -i IOMMU"

dominicm commented on 2016-09-04 17:57 (UTC)

Has anyone had issues with pci grouping after updating to 4.7.2 (from 4.5)? An integrated audio card can no longer be passed through due to the IOMMU group being nonviable where it was before. Is there a way to verify acs patch is actually active/applied?

batarjal commented on 2016-07-25 17:46 (UTC)

Thanks for letting me know. I found that nvidia-dkms was sufficient, as well.

s0ul commented on 2016-07-21 02:30 (UTC)

Installing nvidia-dkms is sufficient, you don't need nvidia driver installed with it.

erylflynn commented on 2016-07-21 01:57 (UTC)

batarjal, that is what I did at the time to resolve it. But it looks like things have been packaged differently for Antergos drivers. Below are what I have installed. I suspect you can drop the nvidia and just install nvidia-dkms and nvidia-utils now. Below are the nvidia packages I have installed and working. extra/libvdpau 1.1.1-2 [installed] extra/libxnvctrl 367.35-1 [installed] extra/nvidia-dkms 367.35-1 [installed] extra/nvidia-libgl 367.35-1 [installed] extra/nvidia-settings 367.35-1 [installed] extra/nvidia-utils 367.35-1 [installed] multilib/lib32-libvdpau 1.1.1-2 [installed] multilib/lib32-nvidia-libgl 367.35-1 [installed] multilib/lib32-nvidia-utils 367.35-1 [installed]

batarjal commented on 2016-07-21 01:44 (UTC)

erylflynn: I'm on antergos, as well, and when I try to run "sudo pacman -S nvidia nvidia-utils nvidia-dkms", I receive an error stating that nvidia and nvidia-dkms are in conflict. Is there a typo in the command you used?

markzz commented on 2016-07-20 05:26 (UTC)

electricprism: We know about this: https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

electricprism commented on 2016-07-20 04:36 (UTC)

gpg --recv-key 79BE3E4300411886 gpg --recv-key 38DBBDC86092693E

s0ul commented on 2016-07-02 05:33 (UTC)

Thanks for the kernel, it worked like a charm :)

erylflynn commented on 2016-04-21 17:23 (UTC) (edited on 2016-07-28 04:34 (UTC) by erylflynn)

Changing this from a help, to a informational. After installing this kernel and headers I could boot but lightdm and even SDDM would not start. What I found was an error in Xorg.0.log about no module found for my NVIDIA driver. I am on Antergos so I just re-installed all my drivers, which alone did not help. I reinstalled the NVIDIA DKMS sudo pacman -S nvidia-dkms This will vary based on how you installed your drivers.

zipeldiablo commented on 2016-04-07 12:15 (UTC) (edited on 2016-04-07 12:34 (UTC) by zipeldiablo)

I see, thanks for the info. The tricky part seems to be the recompilation of the custom kernel to change configs (in order to enhance gaming experience) Hopefully i will manager to build the kernel of my need from your git source

zman0900 commented on 2016-04-06 02:36 (UTC)

You can disable the patch if you want by commenting out the appropriate patch line in the prepare() function of the PKGBUILD file, but it's not really necessary. The patch does nothing unless you provide the required kernel command line arg. If you want to use the patches on another kernel, that is also pretty simple. Compare this PKGBUILD to the main Arch "linux" package and you'll see that I had to make very minimal changes. Mainly, you need to add the patches to the source array, the patch checksums to the sha256sums array, and then actually apply the patches by calling the patch command from the prepare function. You might also want to change the "pkgbase" variable at the top so you can install both kernels at the same time.

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

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.

markzz commented on 2016-01-09 05:52 (UTC)

Pssst, the PKGBUILD states you are at pkgrel=2 but the .SRCINFO isn't reflecting that change. Might you re-run mksrcinfo?

markzz commented on 2016-01-04 04:41 (UTC)

@electricprism, that information is in the PKGBUILD.

electricprism commented on 2016-01-04 04:30 (UTC)

Requires importing GPG Keys to build # Linus Torvalds gpg --recv-keys 79BE3E4300411886 # Greg Kroah-Hartman (Linux kernel stable release signing key) gpg --recv-keys 38DBBDC86092693E

zman0900 commented on 2015-11-22 06:31 (UTC)

You need to actually read the error messages above to see what the problem is. You are probably getting the same issue that gets comes up constantly for any aur package using signed sources - you don't have the public keys in your key ring. https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

markzz commented on 2015-11-22 01:04 (UTC) (edited on 2016-01-04 05:13 (UTC) by markzz)

I do know for a fact that this package builds. If you cannot build this (it may be because you're using something like yaourt and you have not enough ram), you can use my repository and install it from there. A direct link to the information for the repository [1] (so you can add to your pacman.conf if you wish) and a direct link to the package [2] and its signature (key ID 3CADDFDD) below [3] (for x86_64 only). [1] https://wiki.archlinux.org/index.php/Unofficial_user_repositories#markzz [2] http://repo.markzz.com/arch/markzz/x86_64/linux-vfio-4.2.5-1-x86_64.pkg.tar.xz [3] http://repo.markzz.com/arch/markzz/x86_64/linux-vfio-4.2.5-1-x86_64.pkg.tar.xz.sig

lolwtfidk commented on 2015-11-22 01:00 (UTC) (edited on 2015-11-22 01:03 (UTC) by lolwtfidk)

Thats odd, installing from your repo worked fine, but I get ' A failure occurred in prepare()' when building it manually.

markzz commented on 2015-11-22 00:36 (UTC)

It builds fine for me.

lolwtfidk commented on 2015-11-22 00:35 (UTC)

Needs maintenance, 'Failed to prepare()'.

Onishin commented on 2015-11-02 23:16 (UTC)

Working perfectly Thanks zman0900

zman0900 commented on 2015-10-23 02:56 (UTC)

Thanks for the info. I actually signed up to that mailing list a month or so ago and immediately forgot about it. Guess it's time for some reading.

markzz commented on 2015-10-22 17:21 (UTC) (edited on 2015-10-22 20:43 (UTC) by markzz)

It was mentioned on the vfio-users mailing list [1] that 4.3 and a fix in OVMF may solve some issue. If I were you, I would start seriously looking for a solution when kernel 4.3 is released. As for now, I will look for a solution in my spare time. [1] https://www.redhat.com/archives/vfio-users/2015-October/msg00145.html

zman0900 commented on 2015-10-22 16:53 (UTC)

Looks like my issue with screen shutting off when I log into gnome is related to one of the patches on this kernel. I have realized that the same version (4.2.3) of the main arch kernel allows all my screens to turn on. Considering gpu pass through is also broken for me with 4.2+ of this kernel, I'm assuming all the problems are caused by the ACS patch. I think I'll try to figure out the issue this weekend, but I'm a Java programmer so it probably won't go well. If anyone has any advice on where to start or already knows the problem, please let me know.

markzz commented on 2015-10-07 13:10 (UTC)

It could also be that you are using something like yaourt and you do not have enough RAM to compile it fully in /tmp. See the wiki [1] for details. [1] https://wiki.archlinux.org/index.php/Yaourt#Build_directory

zman0900 commented on 2015-10-07 04:46 (UTC)

"No space left on device" That means you are out of hard drive space. Free up some space or use another partition.

Brayden.Dean commented on 2015-10-07 04:29 (UTC)

net/ipv4/syncookies.c:401:1: fatal error: closing dependency file net/ipv4/.syncookies.o.d: No space left on device } ^ compilation terminated. {standard input}: Assembler messages: {standard input}: Fatal error: can't write net/ipv4/.tmp_syncookies.o: No space left on device {standard input}: Fatal error: can't close net/ipv4/.tmp_syncookies.o: No space left on device scripts/Makefile.build:258: recipe for target 'net/ipv4/syncookies.o' failed make[2]: *** [net/ipv4/syncookies.o] Error 1 scripts/Makefile.build:403: recipe for target 'net/ipv4' failed make[1]: *** [net/ipv4] Error 2 Makefile:949: recipe for target 'net' failed make: *** [net] Error 2 Having further errors, I will just add your repo

markzz commented on 2015-10-07 03:43 (UTC)

If you don't want to compile this package yourself, I am providing the package on my repo [1]. [1] https://wiki.archlinux.org/index.php/Unofficial_user_repositories#markzz

Brayden.Dean commented on 2015-10-07 03:33 (UTC)

Thanks, just needed to uncomment the auto key retrieval

zman0900 commented on 2015-10-06 02:35 (UTC)

https://wiki.archlinux.org/index.php/Makepkg#Signature_checking

Brayden.Dean commented on 2015-10-06 01:37 (UTC)

I keep getting ==> Verifying source file signatures with gpg... linux-4.2.tar ... FAILED (unknown public key 79BE3E4300411886) patch-4.2.2 ... FAILED (unknown public key 38DBBDC86092693E) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build linux-vfio. how should I fix it?

ohetfi commented on 2015-10-01 14:53 (UTC)

Really nice, Dan. Appreciate your effort in packaging that. Currently trying it out. :)

zman0900 commented on 2015-10-01 02:18 (UTC)

I just put together linux-vfio-lts which is currently just a copy of linux-vfio-4.1.6 with a different name: https://aur.archlinux.org/packages/linux-vfio-lts That will let you install both at once. I'm working on getting that upgraded to 4.1.9 soon, assuming it doesn't break anything for me. I have the hd 7850 for the host and an r9 280x for the vm and those both end up in the same iommu group without the acs patch. I'm pretty sure my 7850 isn't supposed to be supported by the amdgpu driver, so that shouldn't be the problem. Don't think the 280x is supported either.

ohetfi commented on 2015-10-01 01:40 (UTC)

My motherboard is an ASRock Z87 Extreme6. If I only attach a GTX 980 and a Renesas USB 3.0 card, I do not need to enable the ACS Override patch. But since I attach IBM M1015 card but for the host (not assigning the vfio-pci driver), I have to enable the ACS Override patch. If I recall correctly the IOMMU groups have the same grouping as it used to in 4.1.6. Last night I just downgraded back to 4.1.6 using your link, thanks! Is there any way in Arch AUR to install both version of the same kernel edition (linux-vfio-4.1.6 and linux-vfio-4.2.1) so I can just switch on GRUB menu? Does your HD Radeon issue is because of the new amdgpu driver on 4.2?

zman0900 commented on 2015-10-01 00:38 (UTC)

I am using OVFM also. My vm gets 6 cores and 8 GB memory, and I also require the acs override for my motherboard (asrock z77 extreme 6). Are you also using acs override? Maybe the patch isn't working properly anymore. But I also had other problems with this 4.2.1 kernel. I have a hd 7850 for my host gpu with a triple monitor setup. A big 1440p in the middle and two rotated 1080p on either side. As soon as I would log into gnome, the main 1440p screen would just shut off.

ohetfi commented on 2015-09-30 15:44 (UTC)

Yup, my setup also broken with this update. Though I found a workaround after seeing this ticket [1]. In kernel 4.1.6, I always had 8 vcpus with 16 GB of memory, but in 4.2.1 I need to decrease the settings to just 4 vcpus with 8 GB of memory. Seems related to [2] and [3], which told us that the miscoding looks like on the OVMF side. Do you happen to also use OVMF? Meanwhile, I'm struggling to downgrade to 4.1.6 until this issue has resolved. :) [1] https://github.com/tianocore/edk2/issues/21 [2] https://www.redhat.com/archives/vfio-users/2015-September/msg00395.html [3] http://thread.gmane.org/gmane.linux.kernel/1952205/focus=1996025

zman0900 commented on 2015-09-30 01:55 (UTC)

So, I've upgraded this to 4.2.1, but it has completely broken gpu passthrough for me, among various other things, so I can't say I recommend actually upgrading to this. I am open to any suggestions as to how to fix this. If you need an older version, click the "view changes" link above. 4.1.6 is the last version that works for me, which you can download here: https://aur.archlinux.org/cgit/aur.git/snapshot/aur-5edfba302fe2307a9e1920d5b30324e3d5147ade.tar.gz

anoa commented on 2015-08-15 09:33 (UTC)

wwwkeys.de.pgp.net didn't seem to work for me. Instead pool.sks-keyservers.net seems to be up. gpg --keyserver pool.sks-keyservers.net --recv-keys 79BE3E4300411886 gpg --keyserver pool.sks-keyservers.net --recv-keys 38DBBDC86092693E

zman0900 commented on 2015-07-03 04:03 (UTC)

I have added the patch from https://bugs.archlinux.org/task/43885 at the suggestion of Frans-Willem to fix the separate build of the headers package.

zman0900 commented on 2015-06-29 06:27 (UTC)

Yeah, builds fine in the chroot too.

zman0900 commented on 2015-06-29 05:42 (UTC)

It built fine on my system...but I'm giving it a try now in a clean chroot (testing-x86_64-build). Are you sure you have base-devel and all the dependencies installed?

Frans-Willem commented on 2015-06-27 12:28 (UTC)

Current version (4.0.6-1) fails to create linux-vfio-headers package. Error: ==> Entering fakeroot environment... ==> Starting package_linux-vfio-headers()... cp: cannot stat ‘arch//Makefile’: No such file or directory ==> ERROR: A failure occurred in package_linux-vfio-headers(). Aborting... ==> ERROR: Makepkg was unable to build linux-vfio. I have yet to debug the PKGBUILD, but I figured a warning for anyone else using this was in order.

zman0900 commented on 2015-05-23 00:17 (UTC)

If you've been using this kernel (or the main arch kernel) and you have a filesystem mounted with the discard option on raid0, read this: https://www.archlinux.org/news/data-corruption-on-software-raid-0-when-discard-is-used/ You may have corrupted data. Current 4.0.4-2 update has the patch that is supposed to fix it.

kingd commented on 2015-03-26 06:10 (UTC)

#### gpg --recv-keys 79BE3E4300411886 gpg --recv-keys 38DBBDC86092693E #### Won`t work in my case. I manually had to add a keyserver like this: gpg --keyserver wwwkeys.de.pgp.net --recv-keys 79BE3E4300411886 gpg --keyserver wwwkeys.de.pgp.net --recv-keys 38DBBDC86092693E

PureTryOut commented on 2015-03-24 15:53 (UTC)

Thanks that did the trick! Thanks for putting this in the AUR, much more convenient then patching it myself every time.

nbhs commented on 2015-03-23 02:54 (UTC)

You need to import the keys gpg --recv-keys 79BE3E4300411886 gpg --recv-keys 38DBBDC86092693E

PureTryOut commented on 2015-03-22 13:59 (UTC)

Getting the following error, on both header and kernel package: ==> Verifying source file signatures with gpg... linux-3.19.tar ... FAILED (unknown public key 79BE3E4300411886) patch-3.19.2 ... FAILED (unknown public key 38DBBDC86092693E) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build linux-vfio. ==> Restart building linux-vfio-headers ? [y/N] Are these keys wrong, where can I change them?

zman0900 commented on 2015-03-20 06:01 (UTC)

Updated to 3.19.2. Only changes are from the main Arch package.

zman0900 commented on 2015-02-12 05:04 (UTC)

My intention with this kernel is for it to be as close as possible to the main arch kernel, but with any necessary patches added to support the use of VFIO with KVM to pass through real GPUs and other PCI/PCIe things to VMs. This is very similar to the kernel available at https://bbs.archlinux.org/viewtopic.php?id=162768, but based off the main arch kernel package instead of the aur linux-mainline package. Sometimes I might get the PKGBUILD ready earlier for a new version, but I won't upload it here until sometime after arch releases that version. You can get it ahead of time from my github repo: https://github.com/zman0900/linux-vfio-aur Currently 3.19 is ready there, based off of what is in arch testing right now.