AMD Ryzen NPT / GPU passthrough performance bug fixed

phoronix.com/scan.php?page=news_item&px=AMD-NPT-GPU-Pass-Through

So this was the most important feature ever according to some of Sup Forumsentoomen. It's fixed, what now?
>it was Linux kernel's bug all along

Other urls found in this thread:

phoronix.com/scan.php?page=news_item&px=AMD-NPT-GPU-Pass-Through
lists.linuxfoundation.org/pipermail/iommu/2017-October/024824.html
wccftech.com/amd-shares-plummet-13-4-decline-q4-guidance-seasonality-end-bull-run/
wiki.archlinux.org/index.php/Kernels/Arch_Build_System
phoronix.com/forums/forum/phoronix/latest-phoronix-articles/985575-amd-ryzen-npt-fix-discovered-for-better-pass-through-graphics-performance?p=985583#post985583
patchwork.kernel.org/patch/10027523/
youtube.com/watch?v=I5xdbPI3v3s
level1techs.com/article/patch-npt-ryzen-better-performance
digitimes.com/news/a20171027PD200.html
twitter.com/SFWRedditImages

Now they should add pcie lanes to the current chipsets, so you can get the most out of your pcie lanes.

Holy shit, I was a Ryzen early adopter so I could play games in VM's easily, was extremely disappointed when I found out games were a stuttery mess on Ryzen VM's.

>phoronix.com/scan.php?page=news_item&px=AMD-NPT-GPU-Pass-Through
Fix isn't out, but it would be nice if he releases it.

Nice cat, OP.

>This is a 10 year old bug
>The state of the Linux kernel

>10 year old bug
>AMD didn't try to have it fixed
The state of AMD quality assurance

Not mine, it's some twitter shill's. Saved though, nice indeed.

sugoi neko op-chan

more pics from that dude's twitter then

...

When is the fix going to be released?

Posts say that this could lead others to a fix, but where's the fix?

SHUT IT DOWN
GOYIM KNOWS

cat :3

WHERE IS THE FIX?1? CAN SOMEONE LINK THE FIX PLEASE?

watching this cat heals my body and soul

lists.linuxfoundation.org/pipermail/iommu/2017-October/024824.html
>IOMMU is not the right list for such a change. I'm dubious this is
correct since you're basically going against the comment immediately
previous in the code, but perhaps it's a hint in the right direction.
Thanks,

FFS OP is this just bullsit?

what a beauty

Garbage thread there isn't even a fix. Fuck you op You got my hopes up for nothing.

And fuck you for bot spamming the cat garbage just to keep thread alive. It's fucking nothing.

He found it and will post some code or patch once he cleans it up, no problem IMHO.

N-NO he won't, there is only one fix for your problem goyim

Cats? Cats choose Ryzen.

Wendell probably just came spontaneously

What a beautiful cat.

nice that settles it then
im getting poozen

Just because of this feature?

why is it the responsibility of amd to fix bugs in the linux kernel

>THE ABSOLUTE STATE OF POOZEN
KEK

yes
i was considering intel because id didnt want to deal with this bug
people were saying xen works without the bug but i found nothing confirming that.

>AMD too lazy to write their own drivers
eh, what else is new?

>KVM
>driver

he probably thought this kvm issue is the same issue as the segfault one

That's right everyone AMD is SAVE....

wccftech.com/amd-shares-plummet-13-4-decline-q4-guidance-seasonality-end-bull-run/

GPU passthrough is a meme. There are literally no real world uses for it (muh gaymz do not count). It requires using enterprise virtualization features with consumer graphics cards, does anyone seriously wonder why it never fucking works? Take off your propellor beanie and use a dedicated box for Windows games.

>It's fixed, what now?
>Fix not available.
what did you mean by this?

Nice try schlomo

this is making me regret my r5 1600

Do you need the extra 2 cores or will you need them for the next few years?

old from 2 days ago, i already patched my kernel and it's fucking awesome, everything is smooth

>old from 2 days ago, i already patched my kernel and it's fucking awesome, everything is smooth
Dude where's the patch. How to do this?

shit man you're on Sup Forums get your shit together for once
oh fuck it i'll help you only if you're on argh loonix

follow this guide
wiki.archlinux.org/index.php/Kernels/Arch_Build_System
once you reach "Modifying the PKGBUILD", add Modifying the PKGBUILD, add in prepare()
patch -p1 -i ${srcdir}/kvm.patch
then keep going
once you reach "Compiling", add in ./src , 'kvm.patch'
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index af256b786a70..b2e4b912f053 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -3626,6 +3626,12 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr)
u32 ecx = msr->index;
u64 data = msr->data;
switch (ecx) {
+ case MSR_IA32_CR_PAT:
+ if (!kvm_mtrr_valid(vcpu, MSR_IA32_CR_PAT, data))
+ return 1;
+ vcpu->arch.pat = data;
+ svm->vmcb->save.g_pat = data;
+ break;
case MSR_IA32_TSC:
kvm_write_tsc(vcpu, msr);
break;

and it should be ok, you can compile your kernel and keep going with the wiki

you can also dowload a prepatched kernel, but well i'm not confident with faggots distributing it
captcha: Parking Belmont

>shit man you're on Sup Forums get your shit together for once
I've been looking at level1tech, and the mailing list, but none was able to get it to work.

>FOSS CAN'T FLOSS

join the /r/vfio discord, it's reddit ok but it's where the shit goes on if you want to talk about pci passthrough
and yes i'm waiting the wendel news, but he'll maybe talk about it once the patch will be merged (linux 1.14 or 1.15?)

why would i want passthrough when there are more native games coming than i have time to play?

>tainting your pure OS install with filthy proprietary drivers and software

At least the VM is isolated.

>tainting your OS with usability and features
Yeah who would want a fully supported computer with a software warranty, company support and professional software, right?

there's only room for one poser cat on this board

If steam, buggy Nvidiot drivers that segfault on drawing 2D, and Ubishit games are your idea of professional software.

idiots, it's not decline if it is due to known seasonality and the year-over-year growth is just as much as the quarter before.

The cat wants R7, I guess. But hey, you can't give the furs everything they want, they will start to rule your life.

Fake fix rumour to drive up shares?

Shares usually don't even react to product launch. No response for Vega, Threadripper, or now Ryzen Mobile.

>up to 5 times performance boost
are you moist?

They have to fix it eventually, one of the main gimmicks of Vega is SRIOV which lets you partition the GPU's resources to various VM's. If AMD can't get GPU passthrough working then they're fucked, SRIOV won't work properly and Vega SRIOV would only be compatible with Xeons.

>are you moist?
Very, but irritated that it's not real yet.

Blini not angry because was bamboozled into buying Intel

Fuck off faggot. Shitpost somewhere else.

>Your fix does work and I cant find anything wrong with it but you're still a cunt for posting this on the wrong mailing list
Why is OSS community so hostile?

He didn't say that it works though.
The other guy was all like here I did a thing, and my pc is super fast now. Figure out how to make this happen for everyone now else nerds.

> the quality of AMD advertisement

The good thing about FLOSS is that if something doesn't work, you can fix it yourself.
The bad thing about FLOSS is that if something doesn't work, you have to fix it yourself.

okay

>GPU passthrough is a meme. There are literally no real world uses for it (muh gaymz do not count). It requires using enterprise virtualization features with consumer graphics cards,

PCIe pass-through is a fucking band-aid, not an "enterprise feature".
Real quality solution would be SR-IOV, but AMD didn't enable it in consumer Vega (and maybe not even the pro cards for all I know).

Why is it up to AMD to enable features for you? Why don't you just fix it yourself if that something doesn't work?
What you're complaining about isn't even thread related, because thread is about pretending that the npt bug is fixed.

Great caturday thread op

>BTW in subsequent emails from that thread there is some debate about what a proper fix would look like, but this looks like enough to let people start working out what that proper fix would be. Another user (Nick Sarnie) passed the word to us a couple of days ago and our server SW team is going to have someone work on a "hopefully final" fix.

>One interesting thing I found was that before kernel 4.2 the value that Nick changed was hard-coded very similarly to what he did, but between 4.1 and 4.2 the hard-coding was removed. There was apparently some debate at the time re: whether that change was correct.

phoronix.com/forums/forum/phoronix/latest-phoronix-articles/985575-amd-ryzen-npt-fix-discovered-for-better-pass-through-graphics-performance?p=985583#post985583

oh, official patch now
patchwork.kernel.org/patch/10027523/

somebody on reddit posted an step by step guide to building the patched version on debian/ubuntu systemcs

Its not that hard, it's actually how I developed the fix

sudo apt-get build-dep linux-image-$(uname -r)
mkdir build
cd build
apt-get source linux-image-$(uname -r)
cd linux-image-$(uname -r)
cp debian/config/amd64/config .config
patch -P1 < thepatch.patch
make -j16 (assuming your building on a processor with 16 threads, adjust as appropriate)
sudo cp arch/x86/kvm/kvm-amd.ko /lib/modules/$(uname -r)/kernel/arch/x86/kvm/
sudo depmod -a (shouldn't be needed, but for good measure)
sudo rmmod kvm-amd
sudo modprobe kvm-amd
These instructions are written off the top of my head, they might need adjusting slightly. You could also just patch the file and build a full kernel package and install that.

sudo apt-get build-dep linux-image-$(uname -r)
mkdir build
cd build
apt-get source linux-image-$(uname -r)
cd linux-image-$(uname -r)
patch -P1 < thepatch.patch
dpkg-buildpackage -b
sudo dpkg -i ../linux-image-$(uname-r).deb
sudo rmmod kvm-amd
sudo modprobe kvm-amd
Be aware though that because this package wont be signed apt will want to replace it with the official on upgrades/updates. Best to hold the package or bump the version by editing 'debian/changelog' adding your own entry before you build.

Thanks.

Are people collectively just pretending that this does something, because I'm not seeing any gains bruv.

Consumers don't care about anything IOMMU related. That's why Intel uses VT-d for market segmentation.

SR-IOV is for GPGPU on servers. It isn't for muh gaymz. Don't be surprised if they don't even bother supporting any kind of display output while it's enabled.

youtube.com/watch?v=I5xdbPI3v3s
fresh in

I wish people would still write stuff in terse text form, not in videoblogs. So much work to scour for the information.

Does the patch work?

They have an article
level1techs.com/article/patch-npt-ryzen-better-performance

Oh, thanks.

>SR-IOV is for GPGPU on servers. It isn't for muh gaymz. Don't be surprised if they don't even bother supporting any kind of display output while it's enabled.

SR-IOV is 99% for NICs and to a lesser extent other IO devices, not GPUs.

Also, AMD was explicitly promising exposing display access through VMs, which is clearly not for GPGPU or even cloud GPU usage.

I would easily pay a $100 premium to be able to run host and guest VMs natively on a single GPU, provided there was some way that display output could be pumped from one into a window on the other.

Maybe some day, just how virtualization itself trickled into consumer space.
Today, they need it as cashcow (not meaning it in a bad way, they need to make more money to be viable in the GPU business).

And they are nowhere need as pushy as Nvidia.
digitimes.com/news/a20171027PD200.html

I wonder how much of this is to avoid pissing of MS.
I know I'd like few things more than to shove Windows into a little VM box and use it as a glorified games launcher, and I'm probably not the only one.

I doubt that even shows at their radar, "threat"-wise. They probably couldn't care less, since people wanting that already use Linux. Actually, if they bought Windows and installed it albeit in VM, it's a plus for them.

>SR-IOV is 99% for NICs and to a lesser extent other IO devices, not GPUs.

Currently yes. However this whole discussion has been about AMD using it for GPUs as well.

>Also, AMD was explicitly promising exposing display access through VMs, which is clearly not for GPGPU or even cloud GPU usage.

Got a source for that? There is some market for pushing graphics output back out over a network for VDI, etc. I was limping that in with GPGPU.

But, anything involving the physical display interfaces on the cards themselves is probably a no-go. They *might* let you assign the display pipeline (planes/CRTCs/encoders) to 1 VM exclusively, but I can't think of who would seriously use that.

>cat isn't pawing a threadripper box
You'll get nowhere with that salesmanship cat

actually look at the pic.
presumably only 1 VM at a time ("Host VM" in diagram) can actually fuck with the display outputs (KMS etc.) at a time, but that's fine.

>They *might* let you assign the display pipeline (planes/CRTCs/encoders) to 1 VM exclusively, but I can't think of who would seriously use that.

the diagram also claims the HW VCE/UVD codecs are enabled under SR-IOV.
If everything in the render/compute and codec chains are shareable, I don't see how it matter much if only the physical display output are limited to 1 VM at a time, assuming again that a guest VM's video drivers are given virtual output hooks to pipe screen buffers over some memory channel available to the host VM.

It's real right now, are you telling me you can't patch and compile a kernel?

That diagram shows display in the host context only. I think if they wanted to advertise remapping to VMs they'd explicitly show that - there's already a crossbar in the diagram so they could just have put display under that.

Remapping display to VMs would be used by basically nobody, as I keep saying. So this makes total sense to me.

HW VCE/UVD aren't part of the display pipeline.

I'm not saying you couldn't hypothetically write a PV aware guest driver that ships its output to a viewer app on the host. But it's a lot of work, and who would do that? 99% of the users for this are using remote clients over the network; nobody cares about running a console on the VM host.

Well, that'll solve the only thing preventing me from moving to Ryzen.

Maybe it was shot before TR was released. Cats live from day to day, not planning ahead.

I'm not trying to argue that control of displays can be shared by multiple VMs, just that it appears that VDI-style guests are allowed to run in parallel with a single compositor-running host VM.

Beyond that, it's hard for me to see how supporting a loopback/short-circuit path on a GPU from rendered guest VMs buffers to the host compositor would be that big a challenge.

who is "that dude" or rather what is his twitter?

>GeForce GTX 1080 Ti paired with a Ryzen 7 processor.
Behead the infidel.

>buying AMD for any reason other than to shill for them on Youtube in exchange for money

Why?

There's literally nothing wrong with this. Buy the better value CPU, then the better value GPU.

It's a shame AMD can't break nvidia's anti-trust practices.

>I wish people would still write stuff in terse text form, not in videoblogs.
can't force you to watch product placement etc. that way.

>10 year old bug
why is linux such a bloated mess?

>muh gpu passthrough
>can’t even compile a kernel
lmao

yep, Sup Forums is a bit like Sup Forums sometimes