Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On Thu, 2017-06-29 at 15:59 -0500, Michael Roth wrote: > > > Patches 1-4 address 1) by deferring rebinding of a hostdev to the host > > > driver > > > until all the devices in the group have been detached, at which point all > > > the hostdevs are rebound as a group. Until that point, the devices

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On 06/29/2017 03:44 PM, Alex Williamson wrote: > On Thu, 29 Jun 2017 14:50:15 -0400 > Laine Stump wrote: > >> On 06/28/2017 08:24 PM, Michael Roth wrote: >>> Hi everyone. Hoping to get some feedback on this approach, or some >>> alternatives proposed below, to the following

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

Quoting Alex Williamson (2017-06-29 14:28:11) > On Thu, 29 Jun 2017 09:33:19 +0100 > "Daniel P. Berrange" wrote: > > > On Wed, Jun 28, 2017 at 07:24:55PM -0500, Michael Roth wrote: > > > Hi everyone. Hoping to get some feedback on this approach, or some > > > alternatives

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

Quoting Laine Stump (2017-06-29 13:50:15) > On 06/28/2017 08:24 PM, Michael Roth wrote: > > Hi everyone. Hoping to get some feedback on this approach, or some > > alternatives proposed below, to the following issue: > > > > Currently libvirt immediately attempts to rebind a managed device back to

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On Thu, 29 Jun 2017 14:50:15 -0400 Laine Stump wrote: > On 06/28/2017 08:24 PM, Michael Roth wrote: > > Hi everyone. Hoping to get some feedback on this approach, or some > > alternatives proposed below, to the following issue: > > > > Currently libvirt immediately attempts to

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On Thu, 29 Jun 2017 13:22:44 -0500 Michael Roth wrote: > Quoting Daniel P. Berrange (2017-06-29 03:33:19) > > On Wed, Jun 28, 2017 at 07:24:55PM -0500, Michael Roth wrote: > > > Hi everyone. Hoping to get some feedback on this approach, or some > > > alternatives

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On Thu, 29 Jun 2017 09:33:19 +0100 "Daniel P. Berrange" wrote: > On Wed, Jun 28, 2017 at 07:24:55PM -0500, Michael Roth wrote: > > Hi everyone. Hoping to get some feedback on this approach, or some > > alternatives proposed below, to the following issue: > > > > Currently

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On 06/28/2017 08:24 PM, Michael Roth wrote: > Hi everyone. Hoping to get some feedback on this approach, or some > alternatives proposed below, to the following issue: > > Currently libvirt immediately attempts to rebind a managed device back to the > host driver when it receives a DEVICE_DELETED

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

Quoting Daniel P. Berrange (2017-06-29 03:33:19) > On Wed, Jun 28, 2017 at 07:24:55PM -0500, Michael Roth wrote: > > Hi everyone. Hoping to get some feedback on this approach, or some > > alternatives proposed below, to the following issue: > > > > Currently libvirt immediately attempts to rebind

Re: [Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

On Wed, Jun 28, 2017 at 07:24:55PM -0500, Michael Roth wrote: > Hi everyone. Hoping to get some feedback on this approach, or some > alternatives proposed below, to the following issue: > > Currently libvirt immediately attempts to rebind a managed device back to the > host driver when it

[Qemu-devel] [RFC PATCH 0/5] hotplug: fix premature rebinding of VFIO devices to host

Hi everyone. Hoping to get some feedback on this approach, or some alternatives proposed below, to the following issue: Currently libvirt immediately attempts to rebind a managed device back to the host driver when it receives a DEVICE_DELETED event from QEMU. This is problematic for 2 reasons: