00:10 ity: Hmm, I am trying to get familiar with the overall thing so that I can identify what I want to delve deeper into.
00:13 ity: Hmm, EGL & GLX share the actual OpenGL implementation I presume, right?
00:21 jenatali: For GL, the code in src/mesa calls through the gallium (pipe) interface to the code in src/gallium/drivers/<driver>. Also the code in GLX/EGL calls through (on Linux) the src/gallium/frontend/dri code which then also calls that same pipe interface
00:21 mareko: stepping through the code using a debugger is probably the fastest way to figure out how it works
00:22 jenatali: The various gallium drivers get support code like compiler bits or image tiling libraries from the corresponding vendor-specific dirs
00:23 jenatali: mareko: that extra indirection from the dri frontend confounded me for a while
00:23 jenatali: Since wgl doesn't have it
00:24 ity: Pipe interface?
00:24 ity: I will certainly try stepping with a debugger
00:28 airlied: ity: you can't get familiar with the overall thing, it's too big
00:28 airlied: just get a vague outline, work out what might be interesting or needs a fix, and focus on that
00:29 jenatali: ity: it's the interface between frontend and driver. All the types are prefixed with pipe_
01:07 alyssa: airlied: is right
01:07 alyssa: I openly don't grok e.g. the GL frontend
01:08 alyssa: or the GLSL compiler
01:08 alyssa: hasn't been particularly career limiting :D
01:08 alyssa: (the galliumy and nir-y bits I get. the _mesa-y and yacc-y bits I don't)
01:18 ity: Ooooh, yea I want a vague outline, then find something interesting and delve into that
01:18 ity: jenatali: Oh, I see! Interesting, I'll try grepping for pipe_
01:20 jenatali: ity: https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/gallium/include/pipe
01:21 ity: OH, thx!
07:36 passimoto: There's also suchthat functionality by two lists as well as list1 in openmath , so it has everything but is rather large codebase.
07:49 passimoto: set1 but anyways it looks like we can expose this mode this year with using openmath and w3 consortium and some libs.
07:52 passimoto: There's no point to fight over it, it's not very complex, those people on the island were just crazy hope to never deal with them again, don't send such around me, very obnoxious, enjoy your work instead, it's rewarded with salaries after all.
08:09 passimoto: I have been somewhat doing the needed work but with half barrels from my free time, I think there's no big problem and I have the needed experience around systems, those kits look good to me they offer everything imaginable.
08:16 passimoto: If everything works out this year, like expected the big thanks goes to hosts of the tournaments who arranged work to me so I could buy something at times, this has opened up all the research in free days. https://store.pfu-us.ricoh.com/cg01000-298001/ that gadget looks good there are other pictures it has tablet mode at 270 degree rotation too, this seems universal and good to mount foldable keyboard with magnet.
09:09 trenchsitting: You would not get any salary from such opportunity, since you need to have proper results in that series of tournaments to claim salary, your only results are at terroring customers in tropical regions. They do not pay for such "heroics".
09:19 airlied: Lynne: i did make a little progress on av1. hopefully figure out tomorrow
10:06 karolherbst: mareko: should I just push to your MR (the pipe_box one) and merge it or do you want to include the patch I posted?
10:46 jani: tzimmermann: where should I apply https://lore.kernel.org/r/cover.1709913674.git.jani.nikula@intel.com during the merge window?
10:49 transmittingsense: there was a pdf as to how i reached into numerateweb github , they carry mit license on the generated code, but openmath is sharealike common public license in other words public domain and so is rdf from w3, and i have another translator that would generate code without license incompatibility, i.e generator is mit but end program is not .
10:49 transmittingsense: https://github.com/lszeremeta/mizgra/blob/main/mizgra/outputs/yarspg.py
10:51 tzimmermann: jani, drm-misc-next is always open for features
10:51 jani: tzimmermann: point is, they're fixes cc: stable
10:52 tzimmermann: drm-misc-fixes then if the Fixes: commits are in upstream already
10:53 tzimmermann: jani, let me know if you need to drm-misc-fixes to be forwarded
10:55 jani: tzimmermann: it's so old I didn't even bother searching for the Fixes:, just slammed cc: stable on them
10:55 tzimmermann: jani, sure. makes sense
10:55 jani: tzimmermann: so do you send drm-misc-fixes with the old base for -rc1, and then rebase after that, or how do you manage it?
10:56 tzimmermann: i can backmerge at any time
10:56 tzimmermann: it goes into drm/drm-fixes
10:56 tzimmermann: and from there into upstream
10:56 tzimmermann: every week
10:57 jani: normally yes, but it's the merge window, is all
10:58 jani: anyway, ack on https://lore.kernel.org/r/ffc58be256d71e6a98eb9f13337add64458d3476.1709898638.git.jani.nikula@intel.com as-is with the FIXME comments? it's a bit awkward to document for me, and it's only used in a couple of places I think
10:58 jani: (jumping on to a different series)
10:59 tzimmermann: jani, ack
10:59 jani: thanks!
11:06 jani: hrmh, not pushing because 674dc7f61aef ("drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue") just regressed drm-misc-next for me: https://lore.kernel.org/r/87il1tt4f6.fsf@intel.com
12:35 alyssa: gm
13:25 prophetalike: so all the opencl was already implemented in llvm clang boyi and multi2sim m2s-mgn and btw 2.1 compliance was included in both the frontend perser as well as in the hardware for gcn cards, so it's nothing that karolherbst had done, those solutions came out from my research labs, and i work alone. And every possible REAL solution you might have originates from my intermediate work. Just to say you are german scum karolherbst, and very
13:25 prophetalike: annoying puppet.
13:26 prophetalike: my all relatives send you straight to hell.
13:42 Ristovski: that guy needs a hobby other than trolling this channel lol
13:45 bcheng: airlied, Lynne: is the av1 problem you're working on the references thing still?
13:52 gloomineyes: since my father borrowed around million dollars to the hotel where you came to terror me, when you contact him he lurks you into his place, removes your genitals and forces you to eat them. You viral scum puppet karolherbst , the island is entirely empty and out of tourism horizon ever since i left, so people know you are entire scammer terrorists.
13:52 gloomineyes: you are a fucking suicidal perv you motherfucker.
14:01 grillo_0: pq: about the possibility of combining the pixel conversion of the DRM core with that of VKMS. I think it could be viable, but the DRM goes from XRGB8888 -> format and in VKMS we have format -> ARGB8888 and ARGB8888 -> format. One option would be to just join these VKMS conversions to drm_format_helper, just adding another type of conversion.
14:01 grillo_0: Another option would be to change the DRM conversions from XRGB8888 -> format to ARGB8888 -> format, and after that add the VKMS conversions, to create a more cohesive API. But I don't know if this is desired, but I like the "not reinventing the wheel" thing
14:06 pq: wasn't it argb_u16?
14:07 pq: is that A vs. X such a big problem? I don't think I understand.
14:12 pq: VKMS must be able to ignore the X of XRGB formats too, FWIW
15:03 eric_engestrom: gfxstrand: I don't understand `nvk_device_physical()`, given a `struct nvk_device *dev;` what's the difference between `dev->vk.physical` and `dev->pdev`?
15:03 eric_engestrom: `nvk_CreateDevice()` sets `dev->pdev` to the `VkPhysicalDevice` but I didn't dig further to figure out if these two are always a copy or if they can diverge, and if they can, when to use which
15:04 eric_engestrom: (in the context of your backport request of !27927)
16:16 tzimmermann: grillo_0, the current DRM conversion is tailored towards copying to the hardware framebuffer
16:16 tzimmermann: and there's no ARGB there
16:17 tzimmermann: so it's not really supported
16:18 gfxstrand: eric_engestrom: I'm trying to wean us off of dev->pdev. That's all.
16:18 gfxstrand: I should make a treewide change, probably
16:18 gfxstrand: Well, driver-wide
16:18 gfxstrand: They're the same pointer, just different types
16:18 tzimmermann: a few systems annouce argb surfaces that are really just xrgb; hence the xrgb_to_argb functions that set alpha to 0xff
16:19 gfxstrand: Yeah, xrgb is a mess. It's actually a different format in some hardware
16:20 tzimmermann: grillo_0, would it be possible to make vkms 'close enough' to drm helpers so that later patches could merge both?
16:22 eric_engestrom: gfxstrand: ack, so it looks weird because it's in a transition
16:22 tzimmermann: i.e., per-line conversion, clipping in the outer loop
16:25 gfxstrand: eric_engestrom: Yeah
16:40 grillo_0: pq: yeah, argb_16, sorry for the confusion
16:43 gfxstrand: eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28105
17:11 eric_engestrom: hehe, did you already have it in a local branch, or did my question trigger you into doing it? 😅
17:12 gfxstrand: Your question triggered it
17:12 gfxstrand: I've been meaning to do it for a while.
17:12 eric_engestrom: :]
17:36 lumag: mripard, mlankhorst, dianders: There is a question on which abelvesa and me have been crashing our heads for quite a while. drm/msm/dp driver can support both eDP and DP targets. We are looking for a way to distinguish the sink type. Querying next_bridge->type will not work as it is the output of the bridge, not the input. Checking for aux-bus presense doesn't seem like a future-proof idea granted that bindings file explicitly mentions a
17:36 lumag: possibility of using it for DP too. Checking for the panel node also seems like a hack, especially because a panel can be under aux-bus or it can be a platform-bus node. Do we have any sensible solution in the DRM field?
17:46 dianders: lumag: Can you explain why `next_bridge->type` won't work in more detail? This is what Laurent came up with for `ti_sn_bridge_probe()`...
17:48 lumag: dianders, because that type represents the output of the bridge.
17:48 lumag: So for eDP-to-anything it will be that anything
17:48 lumag: So we need next_bridge->input_type of some kind
17:49 lumag: We can probably add it, but looks like a bit of overkill
17:50 dianders: lumag: Ah, got it. I guess you could do what `ti_sn_bridge_probe()` does and assume that if the next bridge is "DisplayPort" then you're full DP. Otherwise you're eDP. I guess I'd imagine most of the cases of conversion are for internal displays?
17:54 lumag: Then we'd need to fix all the interim bridges to be DisplayPort too.
17:57 lumag: dianders, is it safe to configure the PHY to eDP mode before probing AUX bus?
17:57 lumag: As we don't have next_bridge before aux-bus being probed anyway
17:58 lumag: This wouldn't be a question, but dp-aux-bus.yaml explicitly mentions that it can be repurposed to handle DP too.
18:15 dianders: lumag: To be fair `dp-aux-bus.yaml` is just speculating that it could later be extended. Right now it's always eDP. FWIW from the yaml file you could safely assume that if your AUX bus has a "panel" child that it's eDP, right?
18:15 lumag: dianders, yeah, but we should keep old platform panel-edp devices in mind and remain compatible
18:16 lumag: So, do you think that for now we can safely assuem aux-bus => eDP
18:17 lumag: so it should be (!aux_bus && next_bridge->type == DP) => DP
18:17 dianders: lumag: Yeah, I think that would be OK. ...but if you wanted to be safe you could say "AUX bus + panel node under the AUX bus => eDP"
18:18 dianders: lumag: Or just a comment next to it saying that if aux bus ever needs to be used for eDP we can check the panel node...
18:18 lumag: dianders, ah. And the 'panel' is a part of the bindings, so it will always be like that
18:18 dianders: lumag: exactly
18:19 dianders: lumag: Even so far as to be a "required" property. ...and the yaml file says that if it was used for DP later it would list a connector instead of a panel.
18:19 lumag: dianders, thanks!
18:23 lumag: dianders, should we care about panel-edp on a platform bus?
18:23 lumag: Or such DTs are long gone?
18:25 dianders: lumag: IMO we shouldn't care about in the MSM eDP driver. If my memory serves, the eDP support in the MSM eDP driver is _newer_ than the concept of putting the panels on the AUX bus. That means that there _should_ be no old device trees out there that put their panel on the platform bus. The only reason I'm aware of to support the platform bus for eDP panels is backward compat.
18:25 lumag: yep
18:25 lumag: ack, thank you!
18:55 Ermine: Is Mesa NIR an alternative to LLVM?
18:58 kisak: alternative for what exactly?
19:02 Ermine: Iiuc mesa uses llvm to compile shaders, so is nir does the same thing?
19:03 gfxstrand: Only for AMD and LLVM/lavapipe. Everything else uses NIR and a custom back-end compiler
19:04 gfxstrand: Describing NIR as an LLVM alternative wouldn't be the worst comparison
19:05 psykose: amd also has ACO as a llvm-free replacement now, if you build it that way
19:07 kisak: everybody with a non-ancient GPU gets their shaders run through at least some of the common set of optimizations with NIR these days, right? After the optimization passes it gets handed to the backend compiler to be converted into hardware specific bytecode, which is where LLVM might be involved.
19:08 gfxstrand: Correct. Where LLVM is used in mesa, we treat it as a back-end, not as the primary optimizer
19:09 Ristovski: Speaking of, is there a better way to dump RADV shaders apart from using RADV_DEBUG=shaders?
19:10 gfxstrand: Depends on your use case
19:12 Ristovski: General debugging - more specifically, I would like to make sure my shaders are emitting the right/expected instructions. Not sure if there is a better to get the dumps from within the program itself. Otherwise, I guess I could make a small prog that does nothing but compile shaders and write a wrapper that captures the stdout output
19:12 gfxstrand: VK_KHR_pipeline_executable_properties
19:12 gfxstrand: It's already integrated with RenderDoc so you can look at any pipeline and look at the assembly dump from right there in RenderDoc
19:12 gfxstrand: Or you can use it yourself from your app if you'd prefer
19:14 Ristovski: Oh? I was under the assumption that RenderDoc needed Radeon GPU Analyzer to do the disassembly
19:14 gfxstrand: Nope. It gets the assembly straight from RADV
19:14 gfxstrand: I think it also has a radeon GPU analyzer thing
19:15 Ristovski: Aaah, that's cool. Thanks!
19:15 gfxstrand: But VK_KHR_pipeline_executable properties should also work. It also works with most Mesa drivers so it'll work on NVK, the Intel driver, etc.
19:15 Ristovski: Yeah not sure how I missed the fact that it can do what I am looking for
19:31 Ermine: gfxstrand: thank you!
19:53 airlied: bcheng: yeah ffmpeg vs new khr api
20:07 bcheng: airlied: are your fixes in ffmpeg or radv? when I last checked the reason it wasn't working was that ffmpeg was sending many references, even if they were pointing to the same resource
20:08 DemiMarie: Are there any circumstances under which a CPU mapping of VRAM can be revoked? “Revoked” meaning that subsequent accesses fault or no longer point to the same physical memory.
20:09 DemiMarie: This could be a problem for Xen grant-based virtio, because there is no way to force a Xen guest to relinquish its mappings.
20:09 DemiMarie: (short of tearing down the guest, obviously)
20:10 airlied: bcheng: I haven't fixed it yet :-P
20:17 bcheng: well you said you made some progress, was just wondering what that was
20:28 airlied: bcheng: oh I was fixing the ffmpeg side so far
20:35 Ristovski: Last time I looked into Vulkan video there was some intricacy that made it memory inefficient, has that been addressed since? (extremely out of the loop on vk video :/)
20:40 CounterPillow: that sounds like an extremely made up concern
20:41 marex: hey uh , I am rolling me an PCIe FPGA experimental setup and I need a continuous buffer on x86 machine for that to work ... on ARM this is fine with drm_gem_dma_create() , but on x86 this seems unavailable ?
20:41 Ristovski: Indeed most of that is me misremembering: Its apparently only a corner case on older AMD hw. I remember it from https://lynne.ee/vulkan-video-decoding.html
20:42 Ristovski: > This is a problematic mode, as you have to allocate all references you need upfront, even if they're never used. Which, for 8k HEVC video, is around 3.2 gigabytes of Video RAM. Older AMD hardware requires this.
20:42 marex: or rather, on x86, there is no CMA enabled by default , there is the SHMEM allocator which ... for this hardware ... is not really good
20:43 mareko: karolherbst: you can push to my MR
20:46 Ermine: Ristovski: I wonder which hardware is meant by 'older'
20:47 Ristovski: Ermine: Supposedly hw that doesn't support VK_VIDEO_CAPABILITY_SEPARATE_REFERENCE_IMAGES_BIT_KHR
20:47 airlied: pre navi21
20:47 Ristovski: heh, "older"
20:48 Ristovski: I'd have guessed like pre GCN5 or something :P
20:49 bcheng: Ristovski: that's not a vulkan video problem, that's due to HW design
20:49 ninjaturtle: https://www.w3.org/TR/exi/ is the hack that likely makes things work without scala or signal collect or any of the external compression provider lib on openmath. This document needs to be read, hdt is modeled after that. https://oa.upm.es/37158/1/INVE_MEM_2014_198918.pdf , they have rich documentation as to what this interface does.
20:50 Ermine: interesting design...
20:50 Ristovski: bcheng: Indeed, back then when I read that post I didn't realize that and thus had been carrying that faulty assumption up until now
20:51 Ermine: guess I should pick rdna 3 card or newer next time
20:53 Ristovski: How is that even implemented in hw? What exactly did navi21 gain that makes this possible?
21:12 bcheng: Ristovski: There's a HW block inside the decode engine that fetches the reference data from memory. At a minimum there needs to be more HW registers to assign addresses for separate references, whereas previously a base address would have been enough. Although there's probably more to it
21:14 bcheng: anyway H.264 and H.265 SPS has information about the max number of references in the stream, ideally encoders would actually make that mean something so that the decoder can allocate the minimum required
21:32 ninjaturtle: well w3c has many of those, turtle carries similar compression, but it much looks like the dictionaries can be left to xml through exi, really there's many specs i expect json to have something similar too.
21:34 Ristovski: bcheng: Hmm, are these decode engines separate (and thus vk specific?) from what's used in let's say VA-API with VCN?
21:35 Ristovski: (I'm failing to understand how this is a hw limitation on vk and not on vaapi for example)
21:41 bcheng: Ristovski: it is a limitation for vaapi, thats why I said its not a vulkan video problem
21:42 bcheng: vaapi just hides the fact that you have to allocate a big array, the driver does it for you
21:42 Ristovski: Aaaaah, now it clicked :)
21:42 Ristovski: See, I was under the assumption that it somehow automagically worked on vaapi but not on vulkan
21:43 Ristovski: thanks for the explanation, makes sense now
21:50 ninjaturtle: i wonder if that openmath turned out to have mit license requirement , is a show stopper for anyone, there are more such libraries as openmath is , i dig a bit to in those, if something alike on sets or sequences/dicts can be found as suchthat function.
21:55 karolherbst: mareko: pushed
22:26 marex: is there something convenient on x86 that would give me a continuous buffer for PCIe DMA ?
22:28 marex: I mean, something like drm_gem_dma_create() which is available with CMA on ARM, but not on x86
22:37 tnt: marex: hugepages ?
22:53 marex: tnt: but doesn't that mean throwing away the CMA backed allocator and then switching over to SHMEM backed by hugepages ?
22:53 DemiMarie: Are there any conditions under which DRM will revoke user access to a PCIe BAR?
22:54 marex: at least that is what i915 seems to be doing
22:55 marex: but I was under the impression that with THP , there is no guarantee the allocation will be continuous , or is there ?
22:55 marex: I am not that deep in the hugepages, I just recall there was something about it
22:57 marex: why is CMA even disabled on x86 anyway ?
23:00 Ristovski: I swear I saw something relevant once
23:00 Ristovski: hrm, https://www.kernel.org/doc/html/next/core-api/mm-api.html#c.alloc_contig_pages
23:02 marex: Ristovski: isnt that CMA ?
23:02 DemiMarie: marex: why do you need a contiguous buffer? No-IOMMU systems?
23:03 Ristovski: not sure, this is kinda beyond me tbh
23:03 marex: DemiMarie: ummmm ... wait ...
23:03 marex: DemiMarie: could it be that I can use IOMMU to make a non-continuous buffer look continuous toward the FPGA using IOMMU ?
23:03 DemiMarie: marex: yes
23:04 DemiMarie: at least in theory
23:04 marex: DemiMarie: do you have a hint what should I grep for ?
23:04 DemiMarie: I don’t know what the appropriate kernel interfaces are
23:04 DemiMarie: marex: no
23:04 marex: heh
23:04 DemiMarie: Also unmapping IOMMU buffers is very expensive
23:04 marex: but this approach does sound familiar at laest
23:05 marex: hmmmm, right, because you have to talk the page tables of every device or something like that, right ?
23:05 DemiMarie: Best practice for using an IOMMU is to map all the buffers you need at startup and never use them for anything but I/O.
23:05 DemiMarie: IOMMUs have TLBs and flushing them is hilariously slow due to a bad specification.
23:06 marex: DemiMarie: I kinda need continuous DMABUFs to go in and out
23:06 marex: DemiMarie: or something along the lines, with the CMA it was easy
23:06 marex: seems on x86 it is ... harder
23:06 DemiMarie: marex: port CMA to x86?
23:06 DemiMarie: I know nothing about the kernel interfaces, sorry. I do know something about what the hardware can do, though.
23:07 marex: OK
23:07 DemiMarie: But my interest comes from the security perspective
23:12 HdkR: I do love hardware that optimizes contiguous mapped pages
23:12 DemiMarie: What happens to pages mapped with vkMapMemory when I get VK_ERROR_DEVICE_LOST?
23:13 DemiMarie: Specifically, what happens if VK_ERROR_DEVICE_LOST happens on one thread while another thread was accessing the pages? Will that cause SIGSEGV or SIGBUS?
23:15 gfxstrand: Depends on how bad the device loss is
23:16 DemiMarie: Are there any cases where the kernel will unmap the pages out from under userspace?
23:16 karolherbst: it was considered for the eGPU use case
23:16 gfxstrand: It's theoretically possible for the gpu to just vanish before the kernel has the chance to fix your maps
23:17 DemiMarie: I’m actually fine with userspace (really a guest VM) accessing a BAR of a nonexistent PCI device
23:17 gfxstrand: But in the classic "the card hung" scenario, you should still have your maps
23:17 karolherbst: should trigger a SIGBUS, no?
23:17 gfxstrand: I would think
23:17 DemiMarie: The bad case is where the kernel tries to unmap the memory out from under userspace
23:18 karolherbst: I think for the eGPU case something more graceful was considered, like replacing it with zero maps or something like that? dunno.. the discussion was old :D
23:18 DemiMarie: Because under Xen, unmapping memory that has been shared with another Xen VM is fundamentally cooperative
23:18 gfxstrand: That's fine. The kernel can re-map it to zero pages or something.
23:18 gfxstrand: The bad case is where someone unplugs their eGPU and the PCI device is just gone
23:18 DemiMarie: gfxstrand: Under Xen, you can’t!
23:18 DemiMarie: Not for memory shared with guests
23:19 gfxstrand: That's entertaining
23:19 karolherbst: guess they get a SIGBUS then
23:19 karolherbst: DemiMarie: why can't we though? it's not like this is RAM, this is device memory and if the device is gone, so is the memory
23:20 DemiMarie: gfxstrand: So my concern is something like this:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/BAmXMQVltZfSMHDWdxskZmky>)
23:20 karolherbst: sure
23:20 karolherbst: but this isn't RAM
23:21 karolherbst: there is no "freed" memory, it's gone memory in the case of the GPU going boom
23:21 DemiMarie: So device physically going away isn’t a problem, so long as the system faults rather than just hanging forever.
23:21 karolherbst: yeah.. clients will get a SIGBUS
23:21 DemiMarie: But what if the user plugs the device back in? Those mappings could still be there.
23:21 karolherbst: nah, they are gone
23:22 DemiMarie: what do you mean? where do the page tables now point?
23:22 DemiMarie: or are physical addresses never reused?
23:22 karolherbst: so I don't know if you can do it quickly enough, but normally if the PCIe decide is gone, the connection is marked as such on a kernel level
23:22 karolherbst: *device
23:23 karolherbst: however I don't really know _if_ you can make the application access memory after the device goes back in, but that's kinda unlikely I would say
23:24 DemiMarie: what happens to those accesses?
23:24 karolherbst: at least when I was looking into eGPU things, the bigger concern was the system just going down entirely
23:24 karolherbst: they should SIGBUS
23:24 karolherbst: and I say should, because anything else I'd consider a bug
23:24 DemiMarie: will the physical address space backing them ever be reused?
23:25 karolherbst: I don't think that's even relevant here
23:25 karolherbst: the kernel should just nuke all entries after the device was detected to be gone
23:25 karolherbst: and I _think_ it does
23:26 DemiMarie: under Xen, it can’t, which probably means that any idea of grant-based virtio-GPU is dead
23:26 karolherbst: why can't it?
23:26 DemiMarie: Because there is no hypercall that would allow it
23:27 karolherbst: well.. sounds like Xen misses a feature then?
23:27 karolherbst: how does it all work for hotpluggable PCIe devices then?
23:27 DemiMarie: The underlying operations are “let domain A map page X of my memory” and “stop letting domain A map page X of my memory, failing if page X is still mapped”
23:28 DemiMarie: karolherbst: I agree with you :)
23:28 karolherbst: I mean.. it would be surprising if the hypervisor couldn't nuke pages
23:28 karolherbst: but maybe that's just not a considered use case?
23:28 karolherbst: dunno
23:28 DemiMarie: # CONFIG_HOTPLUG_PCI is not set
23:29 karolherbst: yeah well...
23:29 DemiMarie: not a considered use-case
23:29 DemiMarie: I think
23:29 karolherbst: don't hotunplug your pcie devices then :P
23:29 DemiMarie: or maybe technical debt
23:29 karolherbst: but yeah... PCIe device needing a full reset.. mhhh
23:29 karolherbst: probably the same situation from a high level pov
23:29 DemiMarie: nuking pages is not a good idea because the guest might not be able to handle the fault, but pointing them at a per-domain scratch page should be fine
23:30 DemiMarie: ouch
23:30 karolherbst: yeah.. might make sense to revive the old threads on how to deal with eGPUs
23:30 DemiMarie: does KVM’s MMU support nuking PTEs?
23:30 karolherbst: it's _kinda_ the same problem
23:30 karolherbst: I have no idea, but it would kinda surprise me if there is no handling for SIGBUS situations, but dunno
23:32 DemiMarie: SIGBUS is just delivered to the guest as-is.
23:32 DemiMarie: Or rather the underlying hardware fault is delivered.
23:33 karolherbst: mhh right.. if the device is assigned to the guest
23:33 karolherbst: so it's the guests problem to nuke pages for their clients
23:33 karolherbst: or signal SIGBUS on access
23:43 DemiMarie: so in this case only some VRAM is exposed to the guest
23:45 DemiMarie: and so the host driver is responsible for unmapping the pages, which it can’t do, so this is a limitation in Xen that needs to be addressed.
23:48 airlied: marex: use an iommu :-)
23:50 airlied: DemiMarie: we nuke userspace mappings of device memory all the time
23:50 DemiMarie: airlied: ouch!
23:50 airlied: it's how we migrate things from system memory to vram etc
23:50 airlied: and deal with visibile vs invisible vram
23:51 DemiMarie: I suggest adding a comment in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21658 and mentioning the MR author @pepp. The kernel code is probably very much broken under Xen unless there is something I am completely unaware of.
23:52 DemiMarie: How bad would it be to never migrate stuff?
23:54 DemiMarie: For context: a Xen grant is basically a FOLL_LONGTERM pin by a driver that doesn’t support MMU notifiers and instead requires a pinned reference to the memory.
23:54 airlied: yeah not getting involved with Xen
23:55 DemiMarie: bad experiences in the past?
23:56 airlied: my employer has no interest in it
23:57 DemiMarie: Mine does, but I don’t expect you to know anything about Xen.
23:57 DemiMarie: Hence the analogy
23:59 airlied: I know enough about Xen to know I don't want to know anymore :-)
23:59 DemiMarie: from just what I wrote above?