From: Cam Macdonell <cam@cs.ualberta.ca>
To: subbu kl <subbukl@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] Add shared memory PCI device that shares a memory object betweens VMs
Date: Wed, 22 Apr 2009 16:41:53 -0600 [thread overview]
Message-ID: <49EF9D31.4030605@cs.ualberta.ca> (raw)
In-Reply-To: <f3b32c250904202348t6514d3efjc691b48c4dafe76a@mail.gmail.com>
subbu kl wrote:
> correct me if wrong,
> can we do the sharing business by writing a non-transparent qemu PCI
> device in host and guests can access each other's address space ?
Hi Subbu,
I'm a bit confused by your question. Are you asking how this device
works or suggesting an alternative approach? I'm not sure what you mean
by a non-transparent qemu device.
Cam
>
> ~subbu
>
> On Sun, Apr 19, 2009 at 3:56 PM, Avi Kivity <avi@redhat.com
> <mailto:avi@redhat.com>> wrote:
>
> Cameron Macdonell wrote:
>
>
> Hi Avi and Anthony,
>
> Sorry for the top-reply, but we haven't discussed this aspect
> here before.
>
> I've been thinking about how to implement interrupts. As far as
> I can tell, unix domain sockets in Qemu/KVM are used
> point-to-point with one VM being the server by specifying
> "server" along with the unix: option. This works simply for two
> VMs, but I'm unsure how this can extend to multiple VMs. How
> would a server VM know how many clients to wait for? How can
> messages then be multicast or broadcast? Is a separate
> "interrupt server" necessary?
>
>
>
> I don't think unix provides a reliable multicast RPC. So yes, an
> interrupt server seems necessary.
>
> You could expand its role an make it a "shared memory PCI card
> server", and have it also be responsible for providing the backing
> file using an SCM_RIGHTS fd. That would reduce setup headaches for
> users (setting up a file for which all VMs have permissions).
>
> --
> Do not meddle in the internals of kernels, for they are subtle and
> quick to panic.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> <mailto:majordomo@vger.kernel.org>
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
>
> --
> ~subbu
next prev parent reply other threads:[~2009-04-22 22:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-01 15:43 [PATCH] Add shared memory PCI device that shares a memory object betweens VMs Cam Macdonell
2009-04-01 16:29 ` Anthony Liguori
2009-04-01 18:07 ` Avi Kivity
2009-04-01 18:52 ` Anthony Liguori
2009-04-01 20:32 ` Cam Macdonell
2009-04-02 7:07 ` Avi Kivity
2009-04-03 16:54 ` Cam Macdonell
2009-04-02 7:05 ` Avi Kivity
2009-04-19 5:22 ` Cameron Macdonell
2009-04-19 10:26 ` Avi Kivity
[not found] ` <f3b32c250904202348t6514d3efjc691b48c4dafe76a@mail.gmail.com>
2009-04-22 22:41 ` Cam Macdonell [this message]
[not found] ` <f3b32c250904222355y687c39ecl11c52267a1ea7386@mail.gmail.com>
2009-04-23 16:28 ` Cam Macdonell
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=49EF9D31.4030605@cs.ualberta.ca \
--to=cam@cs.ualberta.ca \
--cc=kvm@vger.kernel.org \
--cc=subbukl@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox