@marmarek Thanks a lot for looking into this – and sharing your valuable insights! 
I fully agree, that “magic values” and an unreliable patch are trouble brewing - and I see that this is well beyond my skills to help with … but if I can help with eg. testing solutions, let me know.
What happens if you add pci=nomsi to kernelopts of sys-net (and revert to the original kernel)?
ath11k_pci doesn’t like that.
failed to enable msi: -22
probe with driver ath11k_pci failed with error -22
How do I install 6.17.13-200.fc42.x86_64 on a template?
Hi qubesosforum7328 - and welcome to the forum.
Note that 6.17.13-200.fc42.x86_64 is an example output from the command:
uname -r
… so you don’t really need that version for the example to work – you “just” need the version that matches what you get when you, when you run
uname -r
in a new HVM template, where the kernel is selected to be (provided by qube).
Please note, that the solution is a hack that @marmarek advised against – the real solution needs some work/knowledge from Xen … but I’m not aware of anything testing it. 
Regarding step 7.
To make changes to the load parameters permanent add it to grub config.
edit grub:
sudo vim /etc/default/grub.qubes
add this line with he correct parameters:
GRUB_CMDLINE_LINUX=“$GRUB_CMDLINE_LINUX ath11k_pci.host_msi_vector_addr=0xfee0a000 ath11k_pci.host_msi_vector_data=0x4000”
update grub:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
After reboot the module should be loaded with correct parameters
Hi Sune - and welcome to the forum!
Note that message from @marmarek on 2026-01-01, that the current “fix” relies on “magic values” and that the correct values might change at random times (suspend?).
A proper fix might needs some work (maybe from some Xen people?), that is well beyond my skill … but since I have the hardware – and currently don’t depend on it – I can test and report back, when there is a proper (or less ugly workaround), as marmarek put it …
Hi,
I am well aware of the fragility of this hack, but until there is a proper fix i want to be able to use my wifi 
Right now I am pinning the kernel in the patched template and so far the hardcoded address did not change. And coming from relying on a usb-dongle for wifi, this is , for me at least, an improvement.
Hi sune
Fine … I just wanted to be sure, that you knew about the risks – and I’m also on the “something that might give me WiFi is better than a brick”-boat … and carry a USB-dongle as backup! 
Hi, thank you for the solution. Is there any plan to include this fix in a future Qubes OS release?
Hi nickvanorton – and welcome to the forum!
The Github issue (that Skyhawk linked) is still open and I don’t know if @marmarek was able to coordinate anything with the Xen people. :-/
But as long as there is an open Github issue, there is the chance that a fix will be added to a Qubes OS release. 
Hi ChrisA, many thanks for your answer! Fingers crossed for the fix!
Hi 
I just did a quick search on the Xen-devel list and found these posts (from January):
It’s unclear to me, if the discussion went elsewhere or simply stalled after the last message .. :-/
So I was going through the steps you’ve outlined here and I am stuck at this point:
sed -e ‘s/work-qubesos/\[sys-builder\]/g’ -e ‘s/qubes-builder-dvm/\[sys-builder-dvm\]/g’ rpc/policy/50-qubesbuilder.policy > /home/user/policy
As of this writing, the available file in the qubes-builderv2 repository is rpc/policy/50-qubesbuilder.policy.j2. When I tried the workaround of copying it to rpc/policy/50-qubesbuilder.policy and proceeding, I realised later on that I had disabled paste via the global keyboard (I could still do Ctrl+Shift+C to copy).
I saw this thread which indicated that I would need to edit the `policy.j2` file further in order to make it suitable for running as is. Will come back and update if I succeed.
This has actually recently updated, the documentation now has a nicer solution than the old.
The end result is the same, it’s just a nicer way of getting there. The whole ‘sed’ business is because we need to edit their fixed qube names, while the new method doesn’t make assumptions and uses a simple shell script (technically not even a script I don’t think, just variable substitution) to establish whatever names you want.
See this section of the readme.
As far as Copy/Paste goes, getting stuff into and out of dom0 is a pain in the ass, and that’s by design. In normal operations, nothing should ever be going in or out of dom0.
If you can get the complete and correct policy file into [sys-builder]:/home/user/policy the way my original instructions do, the rest of the instructions should work as expected.
Let’s actually expand this properly
#!/bin/sh
SOURCE_QUBE=sys-builder
BUILDER_DVM=sys-builder-dvm
cat <<EOF > /home/user/policy
admin.vm.CreateDisposable * ${SOURCE_QUBE} dom0 allow target=dom0
admin.vm.CreateDisposable * ${SOURCE_QUBE} ${BUILDER_DVM} allow target=dom0
admin.vm.CurrentState * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow target=dom0
admin.vm.List * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow target=dom0
admin.vm.Start * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow target=dom0
admin.vm.Kill * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow target=dom0
admin.vm.Remove * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow target=dom0
qubesbuilder.FileCopyIn * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow
qubesbuilder.FileCopyOut * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow
qubes.Filecopy * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow
qubes.WaitForSession * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow
qubes.VMShell * ${SOURCE_QUBE} @tag:disp-created-by-${SOURCE_QUBE} allow
EOF
Instead of the instruction with sed, do this:
nano /home/user/policy.in.sh
paste the above, adjust the qube names if desired, ctrl-x, y, <enter>
/bin/sh /home/user/policy.in.sh
I do hope, if a less ugly fix is found for Xen, that this can also be used to benefit other hypervisors.