02:17 androidui: how exactly does a virtio-pci device (such as virtio-pmem) communicate with a virtio-pmem driver via virtio-over-pci ?
02:43 swardokplec: I assume that permutations and combinations are not the same thing. Likely one of them allows/considers collisions and another does not. But i do not remember clearly which one. But the paradigm can be tested , and i expect the outcome to come similar as to how i stated, that all the alu collision spectrum can base on the more sparsely removed adder collision spectrum, but it is tough
02:43 swardokplec: logics behind the theory, immediate reactions coult trigger opinions that i am insane indeed, however this is likely as with other scientists who did the number theory not so. So you just test my words on cpu and move to DMA after the theory is validated. I do the same thing btw.
03:28 swardokplec: As it will also lead to a filesystem as of storing such minified powers and just having dma encoder decoders, all becomes opened up, there is a path for secure and performance and low power protocols immediately making anything possible. Then you get the real idea as how human worth becomes less and less and even more so if you do not practice, robots start to take over, human designed
03:28 swardokplec: the computers to be too capable, but those were very bright humans from the head, not all can keep up with the smartest ones works later on, but it's not about moral side of that all, such outcomes are possible whether good or bad depends overall on many factors.
03:39 swardokplec: microtubules in anatomy is yes something that manipulates with sensory nerve feedbacks.
04:06 swardokplec: I've been having a good rest in the country side my own, some of the logics appeared to signal towards more of reality paths. However i think one can find a solver that does such things already, like find all permutations of a set that was stashed to a bigger number, now eliminate some of the numbers and combine, you could very fast kickstart a executable code that way. But i have not
04:06 swardokplec: looked at this lately, with one friend i just talked that classical debuggers would not forward such info, but some solvers likely would , needs touch more research.
04:09 swardokplec: cheers.
04:55 Lynne: managed to crash glslang
04:57 Lynne: I think we've succeeded in running code on GPUs, just not writing code that runs on GPUs
08:29 colinmarc: I'm currently reading about GPU (para-)virtualization (@demi I just watched your talk about Xen, that was super helpful, thank you!). I have a question about SR-IOV. Given that consumer nvidia cards seem to have hardware support for SR-IOV, is there a future where nvk/noveau support it? Or is that off the table for some reason?
11:55 karolherbst: colinmarc: needs somebody to write the code
11:57 androidui: does anyone know how to implement a virtio-over-pci device ?
13:04 androidui: sadly this uses MMIO ;-; https://github.com/redoste/riscv-emulator/blob/master/emulator/device_virtio.c
13:46 DemiMarie: Colin Marc: You're welcome! karolherbst is correct that someone would need to write the code. Also, there are concerns that the feature might have gotten no testing and so be broken in a security-relevant way.
13:47 colinmarc: cloud providers presumably use it, no?
13:48 karolherbst: cloud providers don't use nouveau
13:48 colinmarc: ah, I thought "the feature" meant sr-iov
13:48 karolherbst: ohh, sure
13:48 karolherbst: but if nouveau implements it and nobody uses it, it's kinda meaningless
13:49 colinmarc: makes sense
13:49 karolherbst: it's quite low on the priority list, because there are way more critical things to work on for the time being, maybe long-term at some point once things are figured out
13:51 colinmarc: that also makes sense :) I was asking in case the answer was like "licensing means that'll never be a thing" or something
14:00 DemiMarie: karolherbst: Is Nouveau ready for serious use on recent cards, or will that need to wait for Nova?
14:02 DemiMarie: Colin Marc: Cloud workloads using Nvidia GPUs need the blobby stack for CUDA.
14:43 DemiMarie: Colin Marc: Have you considered native contexts?
14:55 androidui: the closest one i can find is https://github.com/matthias-prangl/VirtualBox6/blob/2db58873a4141dd42b3f7d34dbd713dca2fa1984/src/VBox/Devices/VirtIO/Virtio.cpp#L832-#L905
15:10 colinmarc: <DemiMarie> "Colin Marc: Have you considered..." <- In your talk you said malicious or broken code could reset the whole host GPU with native context, but that's not the case with SR-IOV - or did I misunderstand that? Otherwise the native context stuff seems really cool
15:11 colinmarc: I don't really understand how sr-iov would prevent that, so I probably just misunderstood it
15:14 DemiMarie: Colin Marc: SR-IOV *may* do better at containing the impact of a fault. This depends *entirely* on the GPU hardware and firmware.
15:16 colinmarc: I'm trying to read between the lines here, but if google/aws use SR-IOV for gpu instances they must feel reasonably good about it?
15:17 DemiMarie: The only major cloud I know of that offers SR-IOV VFs is Azure.
15:17 DemiMarie: I suspect Microsoft's answer is to have a support contract with the GPU vendor.
15:19 colinmarc: then I really misunderstood something. do you mean "offer" in the sense of they let you use SR-IOV? or they partition their GPUs into "GPU instances" with SR-IOV behind the scenes?
15:20 DemiMarie: The latter I think
15:23 DemiMarie: What is your use-case? On desktop denial of service is often more of a reliability issue than a security issue.
15:23 colinmarc: I'm pondering what it would look like to offer a hosted version of my game streaming thing (https://github.com/colinmarc/magic-mirror)
15:24 colinmarc: so one question would be, what kind of GPUs would I need, and could I actually run them in a meaningfully multitenant way
15:25 colinmarc: it's closer to the "I'm a cloud provider and want to offer gpu instances" than the desktop case, since I have to assume remote code execution probably
15:27 DemiMarie: Personally, I would run that on top of an actual cloud provider and pass the costs to the user. That makes the cloud provider responsible for security.
15:28 DemiMarie: Specifically GPU security
15:28 colinmarc: that's probably not really tenable, because of cost and because of how AI has changed the cloud gpu landscape
15:29 DemiMarie: Azure has instances specifically for VDI (Virtual Desktop Infrastructure).
15:30 colinmarc: but my background is in cloud infra so I'm not that scared of running computers/vms actually... and also I'm just doing research at the moment :)
15:31 DemiMarie: The big cloud providers will do things like conduct white-box security audits of vendor firmware and build custom hardware specifically for their needs.
15:32 colinmarc: since you're warning me off this, what do you see as the biggest threat in terms of gpu security? assuming single-tenant for now
15:32 colinmarc: (that is, 1:1 gpus-VMs)
15:32 DemiMarie: For PCI passthrough: hardware infection
15:33 DemiMarie: It's trivially easy to prevent with custom board designs and very hard to prevent otherwise.
15:34 colinmarc: would you mind pointing me to an example exploit so I can read up on it?
15:34 DemiMarie: I don't know of one actually, but I do know that vBIOS locks have been defeated.
15:36 DemiMarie: The OpenStack docs have a good explanation of what hardware infection is.
15:36 DemiMarie: I do wonder what Google Stadia used before it was shut down.
15:37 colinmarc: they had custom amd gpus made
15:37 colinmarc: and used SR-IOV
15:37 colinmarc: based on something I read today
15:37 DemiMarie: That would not surprise me at all.
15:38 colinmarc: native context would be better than PCI-passthrough even for a single tenant, then, if I want to avoid hardware infection
15:38 DemiMarie: Correct
15:38 DemiMarie: Also weekly kernel updates (so low uptimes).
15:40 colinmarc: thanks for the input!
15:40 DemiMarie: You're welcome!
15:40 DemiMarie: What is your intended user base for this?
15:41 colinmarc: this is getting off-topic :) I'll DM you if that's ok
15:41 DemiMarie: Sure
16:08 markieiole: So the hardware can not supposedly be allowed to make any mistakes on the bus proportions be that digital or analog, cause all is mathematically proven, so first operand is rounded to the closest real power of two which by the way is so , because the next, not previous closest power comes closer to with any number of previous powers yielding a result distance away from next power. In which
16:08 markieiole: case to get the next possible value that is unique is where first operand is concrete power manipulated and second operand is verbatim. This would give the correct result from alu, so considering alus multiply op becomes pinned to the hash yielding round about 1k*1k combinations, so i expect single alu to cost round about one million times 5 storage, so without intrinsics the storage
16:08 markieiole: needed starts somewhere from 22bits, so that does fit only 800 alu banks roughly, using intrinsic, you can stretch the precision supposedly, and fit as many 800banks as needed limited to max-1k-storage allocated for index and bases. so with intrinsics you could stich max/5thousand which is already 858993, i.e nearing to a million times 800 alus so it is now maxing up 687million alus , so
16:08 markieiole: with intrinsics it is getting more executions , a wider range of executed alus, it's like on a telescope or so to speak supervision in terms of throughput on lower storage requirements at the same time. all together it is expected that there is 1million unique non collision based answers per alu with a large but not so large possible error without even testing it. the error can be maximum
16:08 markieiole: million off as to how i see, but it does not matter. it is close enough so never wrong answers are possible, so maximum precision, i understand such theories not the ones you do, that is why i am different "a bit".
19:26 airlied: colinmarc: nvidia don't supply a stable ABI there so it's a mess to use in nouveau upstream
19:26 airlied: also SRIOV enabled GPUs are quite rare and sometimes need special tooling to turn on sriov
23:58 androidui: ughhh why are PCI registration interfaces so different ;-;