We are working on a virtio-pci implementation on a Type-1 hypervisor where backend drivers are hosted in another VM and are considered untrusted. PCI is the virtio transport used in this case.
One issue that crops up is a read/write of config space can potentially block forever, as the backend is untrusted and could be causing a denial-of-service of sorts. This causes the vcpu to stall forever. I was wondering if we can timeout in such case and have the hypervisor break the stall by letting read return "error" (-1) along with setting DEVICE_NEEDS_RESET in status register. Will that allow Linux guest driver to gracefully fail its probe? I don't see where Linux handles DEVICE_NEEDS_RESET currently and also am not sure if returning -1 will lead to graceful failure of the driver alone (we don't want VM to come down or panic because of a mis-behaving device). I saw some discussions in this regard for vDPA where similar solution seem to have been discussed. https://lkml.org/lkml/2021/7/6/219 Would that work for PCI transport also? Thanks vatsa --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
