It may not be quite as bad as that looks.
I do not know if AMD bothered to make chipsets that lack IOMMU hardware capability - usually the problem seems to be with the BIOS or ACPI tables (which are generated by the BIOS). Having seem a Linux log file that found an IOMMU for your CPU, my hunch is that it is a software, not a hardware, issue that is the blocker.
Right now you do not really have any of Xen's debug logging turned on - maybe if it is enabled, Xen will provide some more information about what it sees and does not see. Edit /boot/grub2/grub.cfg (for example, run 'sudo vi /boot/grub2/grub.cfg'), and at the first line starting with "multiboot" (assuming you are booting using the top "Qubes, with Xen hypervisor" boot option), add the following after word "placeholder":
"loglvl=all iommu=debug,amd-iommu-perdev-intremap"
For example, the revised line might look like:
multiboot /xen-4.4.3.gz placeholder loglvl=all iommu=debug,amd-iommu-perdev-intremap console=none ${xen_rm_opts}
The very last option (amd-iommu-perdev-intremap) might get around a bug that was common in AMD BIOSes at one point.
Then reboot, and run the 'xl dmesg' command again. It would be helpful to post the output here. To do that, you can redirect the output of the xl command to a file in your appvm. For example, you can run (from a dom0 console):
xl dmesg | qvm-run --pass-io myappvm 'cat > /home/user/xl-output.txt'
where "myappvm" is the name of the appvm running the browser or email client that you are using to post to qubes-users. Then you can just attach the file xl-output.txt to your post.
Finally, please make sure the IOMMU was turned on in the BIOS settings, assuming the option is available (although it may be a bad sign if the option is not there).
Best,
Eric