First of all, I would like to thank everyone for their support of “Discussion on CUDA Shared Virtualization Support“!Here, I would like to add adisadvantage of the driver forwarding scheme.In the division of CUDA computing power and video memory, there is a significant approach that involves creating a fake libcuda library. This fake libcuda library intercepts all CUDA operations, allowing for various management and restrictions on CUDA access before forwarding to the real libcuda, thus achievingthe division of computing power and video memory.Although this technique may seem superficial and its restriction capabilities appear limited, it is favored for its simplicity and ease of implementation.Some friends might question why I mentioned in my previous article that libcuda forwarding is difficult, while here I state that this type of scheme is simple and easy to implement. Let me explain: becauselibcuda forwarding occurs within a VM, where there is no real GPU present, making it challenging to run the real libcuda. However, this division occurs on the host, typically within a runc container, where the GPU is visible, allowing the real libcuda to run. Therefore, intercepting and forwarding on top of that is relatively easy; I have conducted such experiments myself.Of course, I do not rule out the possibility that this scheme may also have pitfalls, but compared to many current approaches involving modified drivers, it is indeed much easier.Having digressed a bit, let me return to the main topic. It is quite difficult to use the driver forwarding scheme in conjunction with this approach, as the VM is likely to forward driver access to the host, which would render the libcuda on the host unnecessary, thus making it impossible to use alongside the fake libcuda interception method on the host.