All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Cam Macdonell <cam@cs.ualberta.ca>, kvm@vger.kernel.org
Subject: Re: [PATCH v2] Shared memory device with interrupt support
Date: Tue, 19 May 2009 13:31:08 -0500	[thread overview]
Message-ID: <4A12FAEC.9070601@codemonkey.ws> (raw)
In-Reply-To: <4A123639.9000901@redhat.com>

Avi Kivity wrote:
> Anthony Liguori wrote:
>> I'd strongly recommend working these patches on qemu-devel and lkml.  
>> I suspect Avi may disagree with me, but in order for this to be 
>> eventually merged in either place, you're going to have additional 
>> requirements put on you.
>
> I don't disagree with the fact that there will be additional 
> requirements, but I might disagree with some of those additional 
> requirements themselves.

It actually works out better than I think you expect it to...

We can't use mmap() directly.  With the new RAM allocation scheme, I 
think it's pretty reasonable to now allow portions of ram to come from 
files that get mmap() (sort of like -mem-path).

This RAM area could be setup as a BAR.

>   In particular I think your proposal was unimplementable; I would 
> like to see how how you can address my concerns.

I don't remember what my proposal was to be perfectly honest :-)  I 
think I suggested registering a guest allocated portion of memory as a 
sharable region via virtio?  Why is that unimplementable?

> I don't think bulk memory sharing and the current transactional virtio 
> mechanisms are a good fit for each other; but if we were to add a 
> BAR-like capability to virtio that would address the compatibility 
> requirement (though it might be difficult to implement on s390 with 
> its requirement on contiguous host virtual address space).

It doesn't necessarily have to be virtio if that's not what makes sense.

The QEMU bits and the device model bits are actually relatively simple.  
The part that I think needs more deep thought is the guest-visible 
interface.

A char device is probably not the best interface.  I think you want 
something like tmpfs/hugetlbfs.  Another question is whether you want a 
guest to be able to share a portion of it's memory with another guest or 
have everything setup by the host.

If everything is setup by the host, hot plug is important.

Regards,

Anthony Liguori

  reply	other threads:[~2009-05-19 18:31 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-07 16:16 [PATCH v2] Shared memory device with interrupt support Cam Macdonell
2009-05-16  2:45 ` Kumar, Venkat
2009-05-16  3:27   ` Cam Macdonell
2009-05-17 21:39     ` Avi Kivity
2009-05-18 18:54 ` Anthony Liguori
2009-05-19  4:31   ` Avi Kivity
2009-05-19 18:31     ` Anthony Liguori [this message]
2009-05-20  9:01       ` Avi Kivity
2009-05-20 13:45         ` Anthony Liguori
2009-05-20 14:26           ` Avi Kivity
     [not found] <3D9CB4061D1EB3408D4A0B910433453C030BCA8892@inbmail01.lsi.com>
2009-05-16  3:30 ` Cam Macdonell
2009-05-17 21:51   ` Avi Kivity
2009-05-18 11:12     ` Gregory Haskins
2009-05-18 11:38       ` Avi Kivity
2009-05-18 16:50     ` Cam Macdonell
2009-05-18 17:19       ` Avi Kivity
2009-05-18 12:11   ` Kumar, Venkat
2009-05-18 16:20     ` Cam Macdonell
2009-05-19  3:52       ` Kumar, Venkat
2009-05-19 11:20         ` Jayaraman, Bhaskar
2009-05-19 11:35           ` Gregory Haskins

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=4A12FAEC.9070601@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=cam@cs.ualberta.ca \
    --cc=kvm@vger.kernel.org \
    /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.