Arch Linux User Repository

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.

• markzz's repository: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#markzz
• slowbro's repository: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#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.

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

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

pssst, this version is 2 patches old now

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?

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.

@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?

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.

Consider testing 5.13 ;D

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

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.

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.

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

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

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

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.

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

@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

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?

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.

5.9.11 fixed the problem also for me. Thanks.

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.

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

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

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 ?

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.

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

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!

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.

:: 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?

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.

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.

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

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.

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

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.

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

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.

purploid: Are you using i915 VGA arbitration?

@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.

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

@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.

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.

Pushed commit 757f0700.

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.

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

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

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

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.

• markzz's repository: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#markzz
• slowbro's repository: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#slowbro

@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.

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

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)

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.

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.

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

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.

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

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

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.

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.

@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!

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!

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

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)

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.

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.

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 

@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.

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

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

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.

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

@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.

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?

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?

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.

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

slowbro your repo is running at a few hundred kbps

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.

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.

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.

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

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

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.

Thanks slowbro for providing the updated version. much appreciated.

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

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.)

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

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.

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.

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

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

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

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.

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

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

Hello,

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

Thanks a lot!

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

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

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.

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?

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.

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.

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)

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

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

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

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?

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.

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.

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

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

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

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.

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.

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.

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.

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

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

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

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

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.

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.

okay cool, thanks for your quick reply!

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

archqemu: When it's done.

When can we expect an update of this package?

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.

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

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.

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.

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).

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.

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.

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.

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...

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?

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.

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...

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

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

Does the patch not work on 4.18?

Looks like recompiling this package did the trick for me.

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.

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.

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

I'll add it soon then.

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

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

@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.

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.

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

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

Dehir: What?

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

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.

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 .

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.

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

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

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

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.

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

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

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.

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 ^_^