All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Evensky <evensky@dancer.ca.sandia.gov>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	Pekka Enberg <penberg@kernel.org>, Alexander Graf <agraf@suse.de>,
	kvm@vger.kernel.org, cam@cs.ualberta.ca
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 08:08:06 -0700	[thread overview]
Message-ID: <20110825150806.GF24996@dancer.ca.sandia.gov> (raw)
In-Reply-To: <1314271548.3692.22.camel@lappy>


Adding in the rest of what ivshmem does shouldn't affect our use, *I
think*.  I hadn't intended this to do everything that ivshmem does,
but I can see how that would be useful. It would be cool if it could
grow into that.

Our requirements for the driver in kvm tool are that another program
on the host can create a shared segment (anonymous, non-file backed)
with a specified handle, size, and contents. That this segment is
available to the guest at boot time at a specified address and that no
driver will change the contents of the memory except under direct user
action. Also, when the guest goes away the shared memory segment
shouldn't be affected (e.g. contents changed). Finally, we cannot
change the lightweight nature of kvm tool.

This is the feature of ivshmem that I need to check today. I did some
testing a month ago, but it wasn't detailed enough to check this out.

\dae




On Thu, Aug 25, 2011 at 02:25:48PM +0300, Sasha Levin wrote:
> On Thu, 2011-08-25 at 11:59 +0100, Stefan Hajnoczi wrote:
> > On Thu, Aug 25, 2011 at 11:37 AM, Pekka Enberg <penberg@kernel.org> wrote:
> > > Hi Stefan,
> > >
> > > On Thu, Aug 25, 2011 at 1:31 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > >>> It's obviously not competing. One thing you might want to consider is
> > >>> making the guest interface compatible with ivshmem. Is there any reason
> > >>> we shouldn't do that? I don't consider that a requirement, just nice to
> > >>> have.
> > >>
> > >> The point of implementing the same interface as ivshmem is that users
> > >> don't need to rejig guests or applications in order to switch between
> > >> hypervisors.  A 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.  The question should be: how
> > >> is this shmem device different and better than ivshmem?  If 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 not 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 people
> > > 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.
> 
> I support doing it ivshmem-compatible, though it doesn't have to be a
> requirement right now (that is, use this patch as a base and build it
> towards ivshmem - which shouldn't be an issue since this patch provides
> the PCI+SHM parts which are required by ivshmem anyway).
> 
> ivshmem is a good, documented, stable interface backed by a lot of
> research and testing behind it. Looking at the spec it's obvious that
> Cam had KVM in mind when designing it and thats exactly what we want to
> have in the KVM tool.
> 
> David, did you have any plans to extend it to become ivshmem-compatible?
> If not, would turning it into such break any code that depends on it
> horribly?
> 
> -- 
> 
> Sasha.
> 

  reply	other threads:[~2011-08-25 15:08 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-24 22:25 [PATCH] kvm tools: adds a PCI device that exports a host shared segment as a PCI BAR in the guest David Evensky
2011-08-25  3:27 ` Alexander Graf
2011-08-25  4:49   ` David Evensky
2011-08-25  4:52     ` Alexander Graf
2011-08-25  5:11       ` Pekka Enberg
     [not found]         ` <A16CB574-D2F7-440B-BD26-12EB4DEAD917@suse.de>
2011-08-25  5:37           ` Pekka Enberg
2011-08-25  5:38             ` Alexander Graf
2011-08-25  5:06     ` Pekka Enberg
2011-08-25  5:49       ` David Evensky
2011-08-25 10:31       ` Stefan Hajnoczi
2011-08-25 10:37         ` Pekka Enberg
2011-08-25 10:59           ` Stefan Hajnoczi
2011-08-25 11:15             ` Pekka Enberg
2011-08-25 11:30               ` Avi Kivity
2011-08-25 11:38                 ` Pekka Enberg
2011-08-25 11:51                   ` Avi Kivity
2011-08-25 12:01                     ` Pekka Enberg
2011-08-25 11:51                 ` Sasha Levin
2011-08-25 11:25             ` Sasha Levin
2011-08-25 15:08               ` David Evensky [this message]
2011-08-25 22:08                 ` Eric Northup
2011-08-25 22:27                   ` David Evensky
2011-08-26  6:33                 ` Sasha Levin
2011-08-26 15:05                   ` David Evensky
     [not found]               ` <30669_1314285268_p7PFESZN013126_20110825150806.GF24996@dancer.ca.sandia.gov>
2011-08-25 21:00                 ` David Evensky
2011-08-25 21:11                   ` Avi Kivity
2011-08-25 22:03                     ` David Evensky
2011-08-28  7:34                       ` Avi Kivity
2011-08-29  4:55                         ` David Evensky
2011-08-25  5:41 ` Avi Kivity
2011-08-25  6:01   ` David Evensky
2011-08-25  6:02 ` Pekka Enberg
2011-08-25  6:11   ` David Evensky
     [not found] ` <CAFO3S41WOutTEmMGAeor6w=OZ_cax_AHB7Wo24jfUioynv3DFg@mail.gmail.com>
     [not found]   ` <4E55E378.4060904@kernel.org>
2011-08-25  6:30     ` Asias He
2011-08-25  7:02       ` Pekka Enberg
2011-08-25  7:20         ` Asias He
2011-08-25  7:24           ` Pekka Enberg
2011-08-25 21:35 ` Anthony Liguori
2011-08-25 21:50   ` David Evensky
2011-08-26  6:11   ` Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110825150806.GF24996@dancer.ca.sandia.gov \
    --to=evensky@dancer.ca.sandia.gov \
    --cc=agraf@suse.de \
    --cc=cam@cs.ualberta.ca \
    --cc=kvm@vger.kernel.org \
    --cc=levinsasha928@gmail.com \
    --cc=penberg@kernel.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.