[wasi-nn] Update openvino-rs

[rahulchaphalkar]

Updates openvino-rs to 0.11.0 i.e. openvino native updated to 2026.1.2

I have been trying to repro some wasi-nn CI failures on windows runners with error Illegal Instruction, and I believe updating Openvino dependency is possibly a good way to address that.
Its tricky to root cause this, as but I have been running isolated runs of openvino tests and winml tests on windows-2025 runners (in my fork) but haven't hit it yet. (The original failing winml tests ran both openvino and winml).

In short, OneDNN which is a dependency of openvino uses JIT to generate some code, checking the underlying CPU capabilities. This is one of the strongest possibilities for ISA mismatch on a github runner. Updating openvino also updates OneDNN from 3.6.2 to 3.10.2. I see a couple of fixes during that timeframe in OneDNN for illegal instructions, [1], [2]

If we still see these failures after this patch (and I have not been to repro it in my fork till then) then I can introduce additional logging and/or separation of threads/jobs for winml and openvino to identify it.

@alexcrichton this should fail cargo-vet test

[alexcrichton]

Thanks!

[alexcrichton]

I suppose that (regrettably) answers that :(

[rahulchaphalkar]

@alexcrichton Can we merge this?

[alexcrichton]

I can re-queue, but the last failure segfaulted the same as before, so I don't think that this resolves the underlying issue

[rahulchaphalkar]

I don't see failures for this PR? I saw some of the newer seg fault failures you have linked in the other issues, and they come from various backend tests enabling onnx, winml, and openvino, so its actually more likely its coming from openvino, as that is the common backend being run by default every time along with other tests. This patch hopefully addresses that.

[alexcrichton]

The failure is in this event and you have to hit "Show Details" next to it. It's the CI run from being in the merge queue, not the CI run from the PR itself here.

[rahulchaphalkar]

Ah, thanks @alexcrichton , didn't realize the failure was in the merge queue.
I dug deeper into this, and believe I finally have the root cause. It is indeed OneDNN (from openvino) as hypothesized in the PR. I managed to capture a couple of failures in my private fork with more logs.
Whenever a INTEL(R) XEON(R) PLATINUM 8573C or similar Emerald Rapids CPU is assigned, OneDNN rightfully assumes bf16 is supported, and dispatches bf16 kernels, and these seem to have a problem actually executing.
E.g.

onednn_verbose,v1,primitive,exec,cpu,reorder,jit:uni,undef,src:bf16::blocked:abcd::f0 dst:bf16::blocked:acdb::f0,,,1x3x224x224,0.1788

I will file an issue in OneDNN. In the meantime, to stop these CI failures, I tried limiting openvino/onednn to AVX2 on windows CI and that seems to work (kind of tricky to verify since I have to keep rerunning jobs until the right CPU is assigned to that runner).

Do you want me to push that patch here to stop the CI failures, and then work on limiting ISA from within wasmtime, would you rather we do both together? (And then later removing these limitations once OneDNN issue has been resolved).

[alexcrichton]

Doing both together sounds reasonable to me, and thanks for the help for tracking this down!