From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Hajnoczi 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 11:59:43 +0100 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: David Evensky , Alexander Graf , David Evensky , Sasha Levin , kvm@vger.kernel.org To: Pekka Enberg Return-path: Received: from mail-gx0-f174.google.com ([209.85.161.174]:44229 "EHLO mail-gx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946Ab1HYK7o convert rfc822-to-8bit (ORCPT ); Thu, 25 Aug 2011 06:59:44 -0400 Received: by gxk21 with SMTP id 21so1636066gxk.19 for ; Thu, 25 Aug 2011 03:59:44 -0700 (PDT) In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Aug 25, 2011 at 11:37 AM, Pekka Enberg wro= te: > Hi Stefan, > > On Thu, Aug 25, 2011 at 1:31 PM, Stefan Hajnoczi = wrote: >>> It's obviously not competing. One thing you might want to consider = is >>> making the guest interface compatible with ivshmem. Is there any re= ason >>> we shouldn't do that? I don't consider that a requirement, just nic= e to >>> have. >> >> The point of implementing the same interface as ivshmem is that user= s >> don't need to rejig guests or applications in order to switch betwee= n >> hypervisors. =A0A different interface also prevents same-to-same >> benchmarks. >> >> There is little benefit to creating another virtual device interface >> when a perfectly good one already exists. =A0The question should be:= how >> is this shmem device different and better than ivshmem? =A0If there = is >> no justification then implement the ivshmem interface. > > So which interface are we actually taking about? Userspace/kernel in = the > guest or hypervisor/guest kernel? The hardware interface. Same PCI BAR layout and semantics. > Either way, while it would be nice to share the interface but it's no= t a > *requirement* for tools/kvm unless ivshmem is specified in the virtio > spec or the driver is in mainline Linux. We don't intend to require p= eople > to implement non-standard and non-Linux QEMU interfaces. OTOH, > ivshmem would make the PCI ID problem go away. 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. Stefan