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: Wed, 20 May 2009 08:26:46 -0500 Message-ID: <4A140516.6080706@codemonkey.ws> References: <1241713567-17256-1-git-send-email-cam@cs.ualberta.ca> <200905191100.14252.borntraeger@de.ibm.com> <4A12FCDC.5040008@codemonkey.ws> <200905200933.07661.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 mail-qy0-f180.google.com ([209.85.221.180]:35312 "EHLO mail-qy0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753035AbZETN0t (ORCPT ); Wed, 20 May 2009 09:26:49 -0400 Received: by qyk10 with SMTP id 10so661979qyk.33 for ; Wed, 20 May 2009 06:26:49 -0700 (PDT) In-Reply-To: <200905200933.07661.borntraeger@de.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Christian Borntr=C3=A4ger wrote: > Am Dienstag 19 Mai 2009 20:39:24 schrieb Anthony Liguori: > =20 >> Perhaps something that maps closer to the current add_buf/get_buf AP= I. >> Something like: >> >> struct iovec *(*map_buf)(struct virtqueue *vq, unsigned int *out_num= , >> unsigned int *in_num); >> void (*unmap_buf)(struct virtqueue *vq, struct iovec *iov, unsigned = int >> out_num, unsigned int in_num); >> >> There's symmetry here which is good. The one bad thing about it is >> forces certain memory to be read-only and other memory to be >> 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 >> since "backend". To put it another way, in QEMU, map_buf =3D=3D >> virtqueue_pop and unmap_buf =3D=3D virtqueue_push. >> =20 > > > You are proposing that the guest should define some guest memory to b= e used as=20 > shared memory (some kind of replacement), right? No. map_buf() returns a mapped region of memory. Where that memory=20 comes from is up to the transport. It can be the result of an ioremap=20 of a PCI BAR. The model of virtio frontends today is: o add buffer of guest's memory o let backend do something with it o get back buffer of guest's memory The backend model (as implemented by QEMU) is: o get buffer of mapped front-end memory o do something with memory o give buffer back =46or implementing persistent shared memory, you need a vring with enou= gh=20 elements to hold all of the shared memory regions at one time. This=20 becomes more practical with indirect scatter/gather entries. Of course, whether vring is used at all is a transport detail. Regards, Anthony Liguori