From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH v2] Driver for Inter-VM shared memory device for KVM supporting interrupts. Date: Tue, 19 May 2009 13:39:24 -0500 Message-ID: <4A12FCDC.5040008@codemonkey.ws> References: <1241713567-17256-1-git-send-email-cam@cs.ualberta.ca> <200905181607.32924.borntraeger@de.ibm.com> <4A117007.7040202@redhat.com> <200905191100.14252.borntraeger@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Avi Kivity , Cam Macdonell , kvm@vger.kernel.org, Rusty Russell , Christian Ehrhardt To: =?UTF-8?B?Q2hyaXN0aWFuIEJvcm50csOkZ2Vy?= Return-path: Received: from qw-out-2122.google.com ([74.125.92.26]:55421 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752952AbZESSj1 (ORCPT ); Tue, 19 May 2009 14:39:27 -0400 Received: by qw-out-2122.google.com with SMTP id 5so3109282qwd.37 for ; Tue, 19 May 2009 11:39:28 -0700 (PDT) In-Reply-To: <200905191100.14252.borntraeger@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Borntr=C3=A4ger wrote: > Am Montag 18 Mai 2009 16:26:15 schrieb Avi Kivity: > =20 >> Christian Borntraeger wrote: >> =20 >>> Sorry for the late question, but I missed your first version. Is th= ere a >>> way to change that code to use virtio instead of PCI? That would al= low us >>> to use this driver on s390 and maybe other virtio transports. >>> =20 >> 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. >> =20 > > I think the current virtio interface is not ideal for importing host = memory,=20 > but we can change that. If you look at the dcssblk driver for s390, i= t allows=20 > a guest to map shared memory segments via a diagnose (hypercall). Thi= s driver=20 > uses PCI regions to map memory. > > My point is, that the method to map memory is completely irrelevant, = we just=20 > need something like mmap/shmget between the guest and the host. We co= uld=20 > define an interface in virtio, that can be used by any transport. In = case of=20 > pci this could be a simple pci map operation.=20 > > What do you think about something like: (CCed Rusty) > --- > include/linux/virtio.h | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > Index: linux-2.6/include/linux/virtio.h > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- linux-2.6.orig/include/linux/virtio.h > +++ linux-2.6/include/linux/virtio.h > @@ -71,6 +71,31 @@ struct virtqueue_ops { > }; > =20 > /** > + * 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 */ > +}; > =20 Perhaps something that maps closer to the current add_buf/get_buf API. = =20 Something like: struct iovec *(*map_buf)(struct virtqueue *vq, unsigned int *out_num,=20 unsigned int *in_num); void (*unmap_buf)(struct virtqueue *vq, struct iovec *iov, unsigned int= =20 out_num, unsigned int in_num); There's symmetry here which is good. The one bad thing about it is=20 forces certain memory to be read-only and other memory to be=20 read-write. I don't see that as a bad thing though. I think we'll need an interface like this so support driver domains too= =20 since "backend". To put it another way, in QEMU, map_buf =3D=3D=20 virtqueue_pop and unmap_buf =3D=3D virtqueue_push. Regards, Anthony Liguori