From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sasha Levin Subject: Re: [PATCH] kvm tools: adds a PCI device that exports a host shared segment as a PCI BAR in the guest Date: Thu, 25 Aug 2011 14:51:18 +0300 Message-ID: <1314273078.3692.32.camel@lappy> References: <20110824222510.GC14835@dancer.ca.sandia.gov> <232C9ABA-F703-4AE5-83BC-774C715D4D8F@suse.de> <20110825044913.GA24996@dancer.ca.sandia.gov> <1314248794.32391.60.camel@jaguar> <4E56325E.4010807@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Pekka Enberg , Stefan Hajnoczi , David Evensky , Alexander Graf , David Evensky , kvm@vger.kernel.org, Ingo Molnar To: Avi Kivity Return-path: Received: from mail-fx0-f46.google.com ([209.85.161.46]:60689 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753035Ab1HYLvX (ORCPT ); Thu, 25 Aug 2011 07:51:23 -0400 Received: by fxh19 with SMTP id 19so1680380fxh.19 for ; Thu, 25 Aug 2011 04:51:21 -0700 (PDT) In-Reply-To: <4E56325E.4010807@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, 2011-08-25 at 14:30 +0300, Avi Kivity wrote: > On 08/25/2011 02:15 PM, Pekka Enberg wrote: > > On Thu, Aug 25, 2011 at 1:59 PM, Stefan Hajnoczi wrote: > > > Introducing yet another non-standard and non-Linux interface doesn't > > > help though. If there is no significant improvement over ivshmem then > > > it makes sense to let ivshmem gain critical mass and more users > > > instead of fragmenting the space. > > > > Look, I'm not going to require QEMU compatibility from tools/kvm > > contributors. If you guys really feel that strongly about the > > interface, then either > > > > - Get Rusty's "virtio spec pixie pee" for ivshmem > > It's not a virtio device (doesn't do dma). It does have a spec in > qemu.git/docs/specs. Please note that the spec you have in /docs/specs is different from what Cam has in his git tree (https://gitorious.org/nahanni/guest-code/blobs/master/device_spec.txt ). If we are going to add it to KVM tool maybe it's a good time to move it out of QEMU tree and make it less QEMU specific? > > > - Get the Linux driver merged to linux-next > > ivshmem uses uio, so it doesn't need an in-kernel driver, IIRC. Map > your BAR from sysfs and go. > > > - Help out David and Sasha to change interface > > > > But don't ask me to block clean code from inclusion to tools/kvm > > because it doesn't have a QEMU-capable interface. > > A lot of thought has gone into the design and implementation of > ivshmem. But don't let that stop you from merging clean code. Theres a big difference in requiring it to be ivshmem compatible because ivshmem is good and requiring it to be ivshmem compatible because thats what QEMU is doing. Looking at the comments in this thread I would have expected to see much more comments regarding the technical supremacy of ivshmem over a simple memory shared block instead of the argument that KVM tools has to conform to QEMU standards. -- Sasha.