On 18/11/2025 15.25, Cornelia Huck wrote:
On Tue, Nov 18 2025, Thomas Huth <[email protected]> wrote:
On 18/11/2025 13.02, Halil Pasic wrote:
On Tue, 18 Nov 2025 10:39:45 +0100
Thomas Huth <[email protected]> wrote:
Consider the following nested setup: An L1 host uses some virtio device
(e.g. virtio-keyboard) for the L2 guest, and this L2 guest passes this
device through to the L3 guest. Since the L3 guest sees a virtio device,
it might send virtio notifications to the QEMU in L2 for that device.
...
So I think it would really make sense to prevent passing through
virtio-ccw devices with vfio-ccw.
That could be a nice addition on top (in another patch), but we have to fix
handle_virtio_ccw_notify() anyway to avoid that the L3 guest can crash QEMU,
so it's certainly not a replacement for this patch, I think.
"Prevent crashing" is certainly the correct first step :)
I'm not sure where we would want prevent assignment of non-dasd
devices. The kernel can't (because we're dealing with a subchannel
driver.) I think maybe management software on top of QEMU?
The other direction would be supporting things like diag500, so we could
pass through virtio-ccw devices as well. But I'm not really seeing a
use case for it, or is there one?
It could be a very nice test setup to check vfio-ccw in CI pipelines (where
you likely don't have access to a real DASD) ... but apart from that, I also
don't see a real usecase for it.
Thomas
