[vfio-users] Avoiding VFIO NOIOMMU taint in safe situations

2019-04-03 Thread Shawn Anastasio
Hello all, I'm currently writing an application that makes use of Qemu's ivshmem shared memory mechanism, which exposes shared memory regions from the host via PCI-E BARs. MSI-X interrupts that are tied to host eventfds are also exposed. Since ivshmem doesn't have an in-tree kernel driver, I

Re: [vfio-users] Avoiding VFIO NOIOMMU taint in safe situations

2019-04-03 Thread Shawn Anastasio
On 4/3/19 10:23 PM, Alex Williamson wrote: On Wed, 3 Apr 2019 22:01:14 -0500 Shawn Anastasio wrote: Hello all, I'm currently writing an application that makes use of Qemu's ivshmem shared memory mechanism, which exposes shared memory regions from the host via PCI-E BARs. MSI-X interrupts

Re: [vfio-users] Avoiding VFIO NOIOMMU taint in safe situations

2019-04-04 Thread Shawn Anastasio
On 4/4/19 11:24 AM, Alex Williamson wrote: On Wed, 3 Apr 2019 23:31:22 -0500 Shawn Anastasio wrote: On 4/3/19 10:23 PM, Alex Williamson wrote: On Wed, 3 Apr 2019 22:01:14 -0500 Shawn Anastasio wrote: Hello all, I'm currently writing an application that makes use of Qemu's ivshmem

Re: [vfio-users] dev_WARN for hotplugging to live VFIO group

2020-08-21 Thread Shawn Anastasio
On 8/21/20 4:43 PM, Alex Williamson wrote: When a device is added to a live group there's a risk that it will be auto-probed by a host driver, if that occurs then isolation of the group has been violated and vfio code will BUG_ON to halt the system. The warning is effectively just a

[vfio-users] dev_WARN for hotplugging to live VFIO group

2020-08-21 Thread Shawn Anastasio
Hello, While developing the userspace VFIO components of libkvmchan[1], I've run into a dev_WARN in VFIO when hotplugging devices on the same pci host bridge as other VFIO-managed devices: [ 111.220260][ T6281] pci 0001:00:01.0: Device added to live group 1! [ 111.220390][ T6281] WARNING: