search for: device_lock

...t when the device was hot unplugged while the block device was still open. Reported-by: Lance Digby <ldigby at redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> --- If someone has a simpler solution please let me know. I looked at various approaches including reusing device_lock(&vblk->vdev.dev) but they were more complex and extending the lifetime of virtio_device after remove() has been called seems questionable. --- drivers/block/virtio_blk.c | 85 ++++++++++++++++++++++++++++++++++---- 1 file changed, 77 insertions(+), 8 deletions(-) diff --git a/drivers/block...

...t when the device was hot unplugged while the block device was still open. Reported-by: Lance Digby <ldigby at redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> --- If someone has a simpler solution please let me know. I looked at various approaches including reusing device_lock(&vblk->vdev.dev) but they were more complex and extending the lifetime of virtio_device after remove() has been called seems questionable. --- drivers/block/virtio_blk.c | 85 ++++++++++++++++++++++++++++++++++---- 1 file changed, 77 insertions(+), 8 deletions(-) diff --git a/drivers/block...

...ot;0000:01.07.0" > /sys/bus/pci/devices/pciback/unbind - and when the guest is done with (internally when the guest is not using the PCI device anymore). I ran in one issue which is that I could not do pci_reset_function call when "bind" or "unbind" were done as the device_lock was held (and pci_reset_function tried to acquire the mutex). The solution was to introduce a new "pci_reset_function": [PATCH 1/5] pci: Introduce __pci_reset_function_locked to be used and then piggyback on that in [PATCH 2/5] xen/pciback: Support pci_reset_function, aka FLR or D3 Also...

...ll fix. > > > > > Reported-by: Lance Digby <ldigby at redhat.com> > > Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> > > --- > > If someone has a simpler solution please let me know. I looked at > > various approaches including reusing device_lock(&vblk->vdev.dev) but > > they were more complex and extending the lifetime of virtio_device after > > remove() has been called seems questionable. > > --- > > drivers/block/virtio_blk.c | 85 ++++++++++++++++++++++++++++++++++---- > > 1 file changed, 77 inserti...

...ee and leak) upfront, then discuss the fix? > > Reported-by: Lance Digby <ldigby at redhat.com> > Signed-off-by: Stefan Hajnoczi <stefanha at redhat.com> > --- > If someone has a simpler solution please let me know. I looked at > various approaches including reusing device_lock(&vblk->vdev.dev) but > they were more complex and extending the lifetime of virtio_device after > remove() has been called seems questionable. > --- > drivers/block/virtio_blk.c | 85 ++++++++++++++++++++++++++++++++++---- > 1 file changed, 77 insertions(+), 8 deletions(-) &g...

Hi everyone, I would like to ask what the current status of FLR, or better of FLR emulation is in latest Xen and if we can expect better support in the future. I''m asking because with xl (latest build and traditional qemu, not upstream), I always had problems with rebooting domUs which have vga cards passed through to them, because appearently they don''t get reinitialized and

...io: > > CPU0 > ---- > lock(cpu_hotplug_lock.rw_sem); > lock(cpu_hotplug_lock.rw_sem); > > *** DEADLOCK *** > > May be due to missing lock nesting notation > > 3 locks held by swapper/0/1: > #0: (____ptrval____) (&dev->mutex){....}, at: device_lock > include/linux/device.h:1134 [inline] > #0: (____ptrval____) (&dev->mutex){....}, at: __driver_attach+0x15f/0x2f0 > drivers/base/dd.c:820 > #1: (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: get_online_cpus > include/linux/cpu.h:126 [inline] > #1: (____ptrval____...

...io: > > CPU0 > ---- > lock(cpu_hotplug_lock.rw_sem); > lock(cpu_hotplug_lock.rw_sem); > > *** DEADLOCK *** > > May be due to missing lock nesting notation > > 3 locks held by swapper/0/1: > #0: (____ptrval____) (&dev->mutex){....}, at: device_lock > include/linux/device.h:1134 [inline] > #0: (____ptrval____) (&dev->mutex){....}, at: __driver_attach+0x15f/0x2f0 > drivers/base/dd.c:820 > #1: (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: get_online_cpus > include/linux/cpu.h:126 [inline] > #1: (____ptrval____...

...diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c index > 9327378..8c2d95c 100644 > --- a/drivers/misc/mei/hw-txe.c > +++ b/drivers/misc/mei/hw-txe.c > @@ -951,7 +951,7 @@ irqreturn_t mei_txe_irq_thread_handler(int irq, void > *dev_id) > mutex_lock(&dev->device_lock); > mei_io_list_init(&complete_list); > > - if (pci_dev_msi_enabled(dev->pdev)) > + if (pci_dev_msi_enabled(dev->pdev, MSI_TYPE | MSIX_TYPE)) > mei_txe_check_and_ack_intrs(dev, true); > > /* show irq events */ > diff --git a/drivers/misc/mei/pci-me.c b/dri...

...diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c index > 9327378..8c2d95c 100644 > --- a/drivers/misc/mei/hw-txe.c > +++ b/drivers/misc/mei/hw-txe.c > @@ -951,7 +951,7 @@ irqreturn_t mei_txe_irq_thread_handler(int irq, void > *dev_id) > mutex_lock(&dev->device_lock); > mei_io_list_init(&complete_list); > > - if (pci_dev_msi_enabled(dev->pdev)) > + if (pci_dev_msi_enabled(dev->pdev, MSI_TYPE | MSIX_TYPE)) > mei_txe_check_and_ack_intrs(dev, true); > > /* show irq events */ > diff --git a/drivers/misc/mei/pci-me.c b/dri...

...* check if ME wants a reset */ diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c index 9327378..8c2d95c 100644 --- a/drivers/misc/mei/hw-txe.c +++ b/drivers/misc/mei/hw-txe.c @@ -951,7 +951,7 @@ irqreturn_t mei_txe_irq_thread_handler(int irq, void *dev_id) mutex_lock(&dev->device_lock); mei_io_list_init(&complete_list); - if (pci_dev_msi_enabled(dev->pdev)) + if (pci_dev_msi_enabled(dev->pdev, MSI_TYPE | MSIX_TYPE)) mei_txe_check_and_ack_intrs(dev, true); /* show irq events */ diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c index 1b46c64.....

This RFC is to demonstrate below ideas, a) Build vhost-mdev on top of the same abstraction defined in the virtio-mdev series [1]; b) Introduce /dev/vhost-mdev to do vhost ioctls and support setting mdev device as backend; Now the userspace API looks like this: - Userspace generates a compatible mdev device; - Userspace opens this mdev device with VFIO API (including doing IOMMU

This RFC is to demonstrate below ideas, a) Build vhost-mdev on top of the same abstraction defined in the virtio-mdev series [1]; b) Introduce /dev/vhost-mdev to do vhost ioctls and support setting mdev device as backend; Now the userspace API looks like this: - Userspace generates a compatible mdev device; - Userspace opens this mdev device with VFIO API (including doing IOMMU

...t; > lock(cpu_hotplug_lock.rw_sem); > > lock(cpu_hotplug_lock.rw_sem); > > > > *** DEADLOCK *** > > > > May be due to missing lock nesting notation > > > > 3 locks held by swapper/0/1: > > #0: (____ptrval____) (&dev->mutex){....}, at: device_lock > > include/linux/device.h:1134 [inline] > > #0: (____ptrval____) (&dev->mutex){....}, at: __driver_attach+0x15f/0x2f0 > > drivers/base/dd.c:820 > > #1: (____ptrval____) (cpu_hotplug_lock.rw_sem){++++}, at: get_online_cpus > > include/linux/cpu.h:126 [inline]...

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use