From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45457) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXNHx-0001OV-E9 for qemu-devel@nongnu.org; Mon, 16 Mar 2015 01:10:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YXNHs-0005hj-H8 for qemu-devel@nongnu.org; Mon, 16 Mar 2015 01:10:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YXNHs-0005hM-BO for qemu-devel@nongnu.org; Mon, 16 Mar 2015 01:10:00 -0400 Date: Mon, 16 Mar 2015 06:09:56 +0100 From: "Michael S. Tsirkin" Message-ID: <20150316060805-mutt-send-email-mst@redhat.com> References: <1426142455-3739-1-git-send-email-famz@redhat.com> <20150312103850-mutt-send-email-mst@redhat.com> <20150312100028.GC15561@ad.nay.redhat.com> <20150312111125-mutt-send-email-mst@redhat.com> <20150312115534-mutt-send-email-mst@redhat.com> <20150312120624-mutt-send-email-mst@redhat.com> <20150313060719.GB30421@ad.nay.redhat.com> <20150313062820.GC30421@ad.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150313062820.GC30421@ad.nay.redhat.com> Subject: Re: [Qemu-devel] [PATCH] virtio-pci: Clear IRQ at reset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Peter Maydell , QEMU Developers On Fri, Mar 13, 2015 at 02:28:20PM +0800, Fam Zheng wrote: > On Fri, 03/13 14:07, Fam Zheng wrote: > > On Thu, 03/12 12:15, Michael S. Tsirkin wrote: > > > On Thu, Mar 12, 2015 at 11:04:33AM +0000, Peter Maydell wrote: > > > > On 12 March 2015 at 10:57, Michael S. Tsirkin wrote: > > > > > This isn't a device reset though. > > > > > The function that Fam is touching is called > > > > > when a special "virtio reset" register to > > > > > poked by the driver. > > > > > It only resets part of the device, not all of it, > > > > > and it seems reasonable to ask that it clear the > > > > > interrupt. > > > > > > > > Oh, right, sorry. Yes, that should clear the interrupt, then. > > > > (Is there a similar bug on other virtio transports?) > > > > > > > > -- PMM > > > > > > Hmm interesting. > > > > > > I looked at virtio_reset and that one does: > > > vdev->isr = 0; > > > vdev->config_vector = VIRTIO_NO_VECTOR; > > > virtio_notify_vector(vdev, vdev->config_vector); > > > > > > which in turn would call > > > static void virtio_pci_notify(DeviceState *d, uint16_t vector) > > > { > > > VirtIOPCIProxy *proxy = to_virtio_pci_proxy_fast(d); > > > > > > if (msix_enabled(&proxy->pci_dev)) > > > msix_notify(&proxy->pci_dev, vector); > > > else { > > > VirtIODevice *vdev = virtio_bus_get_device(&proxy->bus); > > > pci_set_irq(&proxy->pci_dev, vdev->isr & 1); > > > } > > > } > > > > > > since isr is 0, and msi is disabled, it looks like > > > pci_set_irq will get invoked automatically. > > > > > > so at this point I stopped understanding how can > > > this patch help. > > > > > > Fam, does your patch actually help some guests? > > > Could you pls investigate why isn't virtio_reset > > > sufficient? > > > > Because virtio_reset doesn't disable msix, so here > > "msix_notify(&proxy->pci_dev, 0)" is called. > > s/0/VIRTIO_NO_VECTOR/ My answer still holds - we don't need to clear msix interrupts, and with msi enabled we know intx is low. No? > > > > I tested by applying your patch: > > > > http://www.spinics.net/lists/kernel/msg1943182.html > > > > and adding printf's in QEMU's virtio_reset and virtio_pci_notify. > > > > It shows pci_set_irq is never called. > > > > Fam > > > >