similar to: [PATCH 0/2] virtio: recover from vector assignment failure

virtio currently fails to find any vqs if the device supports msi-x but fails to assign it to a queue. Turns out, this actually happens for old host kernels which can't allocate a gsi for the vector. As a result guest does not use virtio net. Fix this by retrying with less vectors and finally disabling msi on such failures and falling back on regular interrupts. Reported-by: Amit Shah

virtio currently fails to find any vqs if the device supports msi-x but fails to assign it to a queue. Turns out, this actually happens for old host kernels which can't allocate a gsi for the vector. As a result guest does not use virtio net. Fix this by retrying with less vectors and finally disabling msi on such failures and falling back on regular interrupts. Reported-by: Amit Shah

On (Tue) Jul 21 2009 [19:54:00], Michael S. Tsirkin wrote: > On Fri, Jul 17, 2009 at 06:34:40PM +0530, Amit Shah wrote: > > Hello, > > > > Using recent qemu-kvm userspace with a slightly older kernel module I > > get this when using the virtio-net device: I was getting this with a very recent kernel in the guest with an older host kernel. 2.6.31-rc3 in the guest and

On (Tue) Jul 21 2009 [19:54:00], Michael S. Tsirkin wrote: > On Fri, Jul 17, 2009 at 06:34:40PM +0530, Amit Shah wrote: > > Hello, > > > > Using recent qemu-kvm userspace with a slightly older kernel module I > > get this when using the virtio-net device: I was getting this with a very recent kernel in the guest with an older host kernel. 2.6.31-rc3 in the guest and

Let host know of our state (partial yet) so that the host PCI device is up to where we were when we were suspended. This is still an RFC as this doesn't completely work: an unused device at the time of suspend will work fine after resume, but a device that has seen some activity doesn't behave well after resume. Especially, host->guest communication doesn't go through. This could

Let host know of our state (partial yet) so that the host PCI device is up to where we were when we were suspended. This is still an RFC as this doesn't completely work: an unused device at the time of suspend will work fine after resume, but a device that has seen some activity doesn't behave well after resume. Especially, host->guest communication doesn't go through. This could

On Wed, Jul 2, 2014 at 6:41 AM, Jason Cooper <jason at lakedaemon.net> wrote: > On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: >> Hi Jason, >> >> On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: >> > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" >> > added a call to rng_get_data() from the

On (Wed) 02 Jul 2014 [09:41:56], Jason Cooper wrote: > On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > > Hi Jason, > > > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > > added a call to rng_get_data() from the hwrng_register() function. > >

Hi Jason, On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > Also, the virtio-rng device does not behave properly when this call is >

In the case where a virtio-console port is in use (opened by a program) and a virtio-console device is removed, the port is kept around but all the virtio-related state is assumed to be gone. When the port is finally released (close() called), we call device_destroy() on the port's device. This results in the parent device's structures to be freed as well. This includes the PCI regions

In the case where a virtio-console port is in use (opened by a program) and a virtio-console device is removed, the port is kept around but all the virtio-related state is assumed to be gone. When the port is finally released (close() called), we call device_destroy() on the port's device. This results in the parent device's structures to be freed as well. This includes the PCI regions

Commit d9e7972619334 "hwrng: add randomness to system from rng sources" added a call to rng_get_data() from the hwrng_register() function. However, some rng devices need initialization before data can be read from them. Also, the virtio-rng device does not behave properly when this call is made in its probe() routine - the virtio core sets the DRIVER_OK status bit only on a successful

On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > Hi Jason, > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > added a call to rng_get_data() from the hwrng_register() function. > > However, some rng devices need initialization before data can be read > >

On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > Hi Jason, > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > added a call to rng_get_data() from the hwrng_register() function. > > However, some rng devices need initialization before data can be read > >

On restore, virtio pci does the following: + set features + init vqs etc - device can be used at this point! + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits This is in violation of the virtio spec, which requires the following order: - ACKNOWLEDGE - DRIVER - init vqs - DRIVER_OK This behaviour will break with hypervisors that assume spec compliant behaviour. It seems like a good idea to have

On restore, virtio pci does the following: + set features + init vqs etc - device can be used at this point! + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits This is in violation of the virtio spec, which requires the following order: - ACKNOWLEDGE - DRIVER - init vqs - DRIVER_OK This behaviour will break with hypervisors that assume spec compliant behaviour. It seems like a good idea to have

On Mon, Oct 06, 2014 at 06:10:40PM +0300, Michael S. Tsirkin wrote: > On restore, virtio pci does the following: > + set features > + init vqs etc - device can be used at this point! > + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits > > This is in violation of the virtio spec, which > requires the following order: > - ACKNOWLEDGE > - DRIVER > - init vqs > -

On (Fri) 06 Sep 2013 [10:28:36], Aaron Lu wrote: > > The virtio_pci_freeze/restore are defined under CONFIG_PM but is used > by SET_SYSTEM_SLEEP_PM_OPS macro, which is defined under > CONFIG_PM_SLEEP. So if CONFIG_PM_SLEEP is not cofigured but > CONFIG_PM_RUNTIME is, the following warning message appeared: > > drivers/virtio/virtio_pci.c:770:12: warning: ?virtio_pci_freeze?

On Tue, Sep 23, 2014 at 3:32 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On restore, virtio pci does the following: > + set features > + init vqs etc - device can be used at this point! > + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits > > This is in violation of the virtio spec, which > requires the following order: > - ACKNOWLEDGE > - DRIVER > -

The following changes since commit 48de8cb7847d040c8892701c1ff3c55eff1f46b4: Linus Torvalds (1): Merge branch 'perf-fixes-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Amit Shah (1): MAINTAINERS: Put the virtio-console entry in