From patchwork Tue May 19 09:00:13 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Borntraeger X-Patchwork-Id: 24681 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n4J92WPL007059 for ; Tue, 19 May 2009 09:02:32 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755985AbZESJBE (ORCPT ); Tue, 19 May 2009 05:01:04 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755976AbZESJBE (ORCPT ); Tue, 19 May 2009 05:01:04 -0400 Received: from mtagate8.de.ibm.com ([195.212.29.157]:52272 "EHLO mtagate8.de.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755035AbZESJBC (ORCPT ); Tue, 19 May 2009 05:01:02 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate8.de.ibm.com (8.14.3/8.13.8) with ESMTP id n4J912Cq102418 for ; Tue, 19 May 2009 09:01:02 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n4J912IN4350080 for ; Tue, 19 May 2009 11:01:02 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n4J911LD004618 for ; Tue, 19 May 2009 11:01:02 +0200 Received: from cborntra.localnet (dyn-9-152-212-32.boeblingen.de.ibm.com [9.152.212.32]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n4J911v4004612; Tue, 19 May 2009 11:01:01 +0200 From: Christian =?utf-8?q?Borntr=C3=A4ger?= Organization: IBM To: Avi Kivity Subject: Re: [PATCH v2] Driver for Inter-VM shared memory device for KVM supporting interrupts. Date: Tue, 19 May 2009 11:00:13 +0200 User-Agent: KMail/1.11.2 (Linux/2.6.30-rc6-self-00043-g22ef37e; KDE/4.2.2; i686; ; ) Cc: Cam Macdonell , kvm@vger.kernel.org, Rusty Russell , Christian Ehrhardt References: <1241713567-17256-1-git-send-email-cam@cs.ualberta.ca> <200905181607.32924.borntraeger@de.ibm.com> <4A117007.7040202@redhat.com> In-Reply-To: <4A117007.7040202@redhat.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200905191100.14252.borntraeger@de.ibm.com> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org Am Montag 18 Mai 2009 16:26:15 schrieb Avi Kivity: > Christian Borntraeger wrote: > > Sorry for the late question, but I missed your first version. Is there a > > way to change that code to use virtio instead of PCI? That would allow us > > to use this driver on s390 and maybe other virtio transports. > > Opinion differs. See the discussion in > http://article.gmane.org/gmane.comp.emulators.kvm.devel/30119. > > To summarize, Anthony thinks it should use virtio, while I believe > virtio is useful for exporting guest memory, not for importing host memory. I think the current virtio interface is not ideal for importing host memory, but we can change that. If you look at the dcssblk driver for s390, it allows a guest to map shared memory segments via a diagnose (hypercall). This driver uses PCI regions to map memory. My point is, that the method to map memory is completely irrelevant, we just need something like mmap/shmget between the guest and the host. We could define an interface in virtio, that can be used by any transport. In case of pci this could be a simple pci map operation. What do you think about something like: (CCed Rusty) --- include/linux/virtio.h | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-2.6/include/linux/virtio.h =================================================================== --- linux-2.6.orig/include/linux/virtio.h +++ linux-2.6/include/linux/virtio.h @@ -71,6 +71,31 @@ struct virtqueue_ops { }; /** + * virtio_device_ops - operations for virtio devices + * @map_region: map host buffer at a given address + * vdev: the struct virtio_device we're talking about. + * addr: The address where the buffer should be mapped (hint only) + * length: THe length of the mapping + * identifier: the token that identifies the host buffer + * Returns the mapping address or an error pointer. + * @unmap_region: unmap host buffer from the address + * vdev: the struct virtio_device we're talking about. + * addr: The address where the buffer is mapped + * Returns 0 on success or an error + * + * TBD, we might need query etc. + */ +struct virtio_device_ops { + void * (*map_region)(struct virtio_device *vdev, + void *addr, + size_t length, + int identifier); + int (*unmap_region)(struct virtio_device *vdev, void *addr); +/* we might need query region and other stuff */ +}; + + +/** * virtio_device - representation of a device using virtio * @index: unique position on the virtio bus * @dev: underlying device. @@ -85,6 +110,7 @@ struct virtio_device struct device dev; struct virtio_device_id id; struct virtio_config_ops *config; + struct virtio_device_ops *ops; /* Note that this is a Linux set_bit-style bitmap. */ unsigned long features[1]; void *priv;