In D22434#490491, @kib wrote:

Could you please point me to the specific PLX datasheet and the chapter/section that explains the originator handling by the device.

I did quick test with PLX NTB with this patch to its driver:

In D22224#486144, @mjg wrote:

The point was ACLs are always walked if needed which is not hard to verify and it answers the question.

In D22224#485861, @mjg wrote:

If the flag is unset, fast path bails. If no acls deny exec, the flag is set and fastpath continues.

In D22224#485688, @mjg wrote:

You can see the fast path is gated by ZFS_NO_EXECS_DENIED. Should anything be there to deny an exec to /someone/, fast path fails.

In D21807#476430, @pjd wrote:

I see what you mean. Others implement this the same way:
Linux: https://github.com/torvalds/linux/blob/master/drivers/scsi/virtio_scsi.c#L304
Windows: https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/vioscsi/vioscsi.c#L1621

In D21807#476160, @pjd wrote:

What do you mean by 'too strict parsing of ASC/ASCQ'?

This virtio API looks ugly. They conform themselves that device should also report normal UNIT ATTENTION with the same status, which is already handled by CAM DA driver. If we assume that device does generate UNIT ATTENTION, then we should be able to make cam send TUR request to see it by using AC_SCSI_AEN async. Alternatively, it is possible to simulate UNIT ATTENTION receive by using AC_UNIT_ATTENTION with fake CCB, including ASC/ASCQ received from virtio API. Your method should also work, but what I don\t very like it too strict parsing ASC/ASCQ and sending not exactly correct async.

Generally I think it is good, but I think it should be set higher, after the "softc->quirks |= DA_Q_NO_6_BYTE;" line.