Jump to content

dkabot

Members
  • Content Count

    22
  • Joined

  • Last visited

Community Reputation

0 Neutral

About dkabot

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. You may want to avoid passing in SMT cores, but you should be fine to put in as many real cores as you want. QEMU (I think it was QEMU) is actually hardcoded to assume that AMD processors can't do SMT, and will pass through any SMT cores as if they were real ones. In my basic testing, while this does improve CPU performance a bit, you also lose some GPU performance for it.
  2. We've been discussing this the entire page, though the update is appreciated regardless. Looking forward to trying the new build! I'll be sure to look into a license (been using trials every month or two to check the situation) once things are cooperating.
  3. Theoretically they should be able to apply the patch, but I'd be inclined toward thinking they won't. Edit: I don't have any reason to actually think so or not, just my gut.
  4. Now we just need to hope the patch makes it in for 4.1X or something, then we can bug LimeTech to use it.
  5. Yes, KVM is in the kernel and as such, this would require building a kernel yourself. Considering how old the only documentation for that (on Unraid) is, not something I'd recommend.
  6. Hopefully it's just a matter of time before something gets upstream and Unraid gets an update. I'm still tempted by the idea of being lazy and using Unraid for the management aspect, even if I can just install a normal distro. I suppose someone could try to compile a kernel on top of current Unraid, but considering the documentation, I don't think I'll be doing that.
  7. I linked the wrong one, thought I had to remove and repost for some reason, and then forgot to. Sorry, that was me being dumb. There is, however, further good news in that a KVM maintainer has seen this and is trying to make a real patch. Edit: Sarnex has graced me with the link to this development: https://marc.info/?l=kvm&m=150891787704371&w=2
  8. You haven't seen anything because nothing's happened. It's still there, and the only "discovery" is that this bug is 10 years old and on other AMD processors. If you have a more technical hand, you can try other hypervisors which apparently are unaffected, such as Xen or ESXi. Xen seems to be very lenient on what you can pass through, but requires modifying nVidia drivers to install them and setup is obtuse. ESXi apparently works, and has a far easier way to just hide the VM status (like KVM), but I know of no way to work around my poor IOMMU groupings. There's also the possibility that some other hypervisor like Bhyve (BSD) will add GPU passthrough, in which case it could probably be used instead, but we have no estimate for if/when that'll happen. As much as I hate to say it, if you want things to Just Work(TM) get an Intel processor.
  9. Yeah, I'd be using Xen right now (which doesn't have the NPT bug at all, so I hear), but it refused to acknowledge that I had SVM on regardless of the fact that it definitely was. Running bare Windows is a tragedy, but I'm not the type to dual boot. Edit: My recollection was wrong. It knew I had SVM on, but due to some ACPI table thing, it was unable to enable AMD-Vi (IOMMU).
  10. It's been quite a while since I've touched this, but I'm fairly certain NPT can be toggled without changes to the VMs. NPT is a host hardware setting, not something you apply to virtual hardware on the guest. As such, while performance will differ, as far as the VM is concerned, nothing has changed.
  11. NPT is still busted as ever from what I can tell; it murders GPU performance, but turning it off hurts CPU performance a good deal.
  12. Alright, reverted my board back to latest stable. While the GPUs were detected in their own group, neither Unraid nor Arch were able to actually pass it through. Going into the VM externally with TeamViewer showed the resolution was 640x480 and there were no graphics adapters at all. Also, the RGB light cycle was messed up, and it would show red instead of purple on my CPU fan. Clearly the worst of tragedies. Anyway, looks promising, be nice to see what happens on stable release.
  13. With ACS on this board, one USB controller is exposed, which is for the two USB 3.1 (one of them Type-C) ports. The rest are intermingled with other system components, even with the patch.