On Fri, Mar 30, 2012 at 10:18:31PM +0200, Jan Kiszka wrote: > >>> The root cause of the problem is that the 'reset_assigned_device()' code > >>> first writes a 0 to the command register. Then, when qemu subsequently does > >>> a kvm_deassign_irq() (called by assign_irq(), in the system_reset path), > >>> the kernel ends up calling '__msix_mask_irq()', which performs a write to > >>> the memory mapped msi vector space. Since, we've explicitly told the device > >>> to disallow mmio access (via the 0 write to the command register), we end > >>> up with the above 'Unsupported Request'. > >>> > >>> The fix here is to first call kvm_deassign_irq(), before doing the reset, > >> > >> s/fix/workaround/. This is a kernel bug if userspace can crash the > >> system like this, no? Let's fix the kernel first and then look at what > >> needs to be changed here. > >> > >> Jan > >> > > > > But don't I need special privalege to run the device assignment bits? > > Yes, but even that might be moderated by a management component like > libvirt. > > > For example, this crash is precipitated by a write of '0' to the pci > > device config register from userspace. Surely, not every is allowed to > > do that write. So it seems to me, that this patch is in keeping with the > > current model of how things work. > > No user should needlessly be able to crash the host by issuing valid > commands in a special order. > > Jan > Right, but as I see device-assign.c, we are essentially programming the pci device directly from userspace. Put another way, the kernel could crash the system if it programmed a pci device in the wrong order. So I don't see how this is different. But maybe I'm misunderstanding the model here? Thanks, -Jason -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
