From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFtqu-0007ed-3O for qemu-devel@nongnu.org; Wed, 02 Dec 2009 13:23:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFtqo-0007X0-GN for qemu-devel@nongnu.org; Wed, 02 Dec 2009 13:22:59 -0500 Received: from [199.232.76.173] (port=36918 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFtqo-0007WU-5K for qemu-devel@nongnu.org; Wed, 02 Dec 2009 13:22:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1026) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NFtqn-00059C-Jn for qemu-devel@nongnu.org; Wed, 02 Dec 2009 13:22:53 -0500 From: Juan Quintela In-Reply-To: <20091202144333.GB18519@redhat.com> (Michael S. Tsirkin's message of "Wed, 2 Dec 2009 16:43:33 +0200") References: <67f3d61df137cfd59fbf5da6b0b999cdf8d28758.1259754427.git.quintela@redhat.com> <20091202144333.GB18519@redhat.com> Date: Wed, 02 Dec 2009 19:22:11 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH 15/41] virtio: remove save/load_queue for virtio List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org "Michael S. Tsirkin" wrote: > On Wed, Dec 02, 2009 at 01:04:13PM +0100, Juan Quintela wrote: >> diff --git a/hw/virtio.c b/hw/virtio.c >> index c136005..b565bf9 100644 >> --- a/hw/virtio.c >> +++ b/hw/virtio.c >> @@ -643,8 +643,10 @@ void virtio_save(VirtIODevice *vdev, QEMUFile *f) >> qemu_put_be32(f, vdev->vq[i].vring.num); >> qemu_put_be64(f, vdev->vq[i].pa); >> qemu_put_be16s(f, &vdev->vq[i].last_avail_idx); >> - if (vdev->binding->save_queue) >> - vdev->binding->save_queue(vdev->binding_opaque, i, f); >> + if (vdev->type == VIRTIO_PCI && >> + virtio_pci_msix_present(vdev->binding_opaque)) { >> + qemu_put_be16s(f, &vdev->vq[i].vector); >> + } >> } >> } >> > > I think this will break build on systems without PCI > because virtio_pci.c is not linked in there. > Correct? It compiles for syborg (it has pci). There are no other users. > Making generic virtio.c depend on virtio_pci.c looks > wrong in any case. We have bindings to > resolve exactly this dependency problem. There is no way that you throw "this" blob to vmstate and it will know what to do there. if it is needed, we can create an empty virtio_pci_msix_present() function for !CONFIG_PCI. Later, Juan.