Re: [PATCH v3] hw/s390x: Fix a possible crash with passed-through virtio devices

[Thomas Huth <thuth@redhat.com>]

On 18/11/2025 22.45, Eric Farman wrote:
> On Tue, 2025-11-18 at 18:40 +0100, Thomas Huth wrote:
>> From: Thomas Huth <thuth@redhat.com>
>>
>> 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.
>> But since the QEMU in L2 defined this device as vfio-ccw, the function
>> handle_virtio_ccw_notify() cannot handle this and crashes: It calls
>> virtio_ccw_get_vdev() that casts sch->driver_data into a VirtioCcwDevice,
>> but since "sch" belongs to a vfio-ccw device, that driver_data rather
>> points to a CcwDevice instead. So as soon as QEMU tries to use some
>> VirtioCcwDevice specific data from that device, we've lost.
>>
>> We must not take virtio notifications for such devices. Thus fix the
>> issue by adding a check to the handle_virtio_ccw_notify() handler to
>> refuse all devices that are not our own virtio devices. Like in the
>> other branches that detect wrong settings, we return -EINVAL from the
>> function, which will later be placed in GPR2 to inform the guest about
>> the error.
> 
> I still think this is a good idea, but of course "let's try it" got me into the weeds. I
> reconstructed a configuration (dasd->virtio-blk-ccw->vfio-ccw->virtio-blk-ccw) that crashes the
> nested guest upon startup with today's master. Applying this patch generates that message to point
> out where it's broken (yay!), but the nested guest hangs during boot. Need to ponder this more
> tomorrow.

FWIW, we only tried to passthrough a virtio-input device to the L3 guest, we 
did not try a virtio-blk device here ... so that might be the reason why I 
did not see any further hangs after applying my fix.

  Thomas