qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Cam Macdonell <cam@cs.ualberta.ca>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [PATCH v7 0/4] Inter-VM shared memory device
Date: Mon, 26 Jul 2010 14:41:53 -0500	[thread overview]
Message-ID: <4C4DE501.2080202@codemonkey.ws> (raw)
In-Reply-To: <AANLkTi=fGngVkktjrULceOGqXr_goWtLt5AD=oagjm_3@mail.gmail.com>

On 07/26/2010 02:01 PM, Cam Macdonell wrote:
> On Mon, Jul 26, 2010 at 7:48 AM, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>    
>> On 06/15/2010 03:23 PM, Cam Macdonell wrote:
>>      
>>> Latest patch for PCI shared memory device that maps a host shared memory
>>> object
>>> to be shared between guests
>>>
>>>        
>> Is this against qemu.git or qemu-kvm.git?  It depends on functions like
>> qemu_ram_map() which are not present in qemu.git (and are present in
>> qemu-kvm.git).
>>      
> It is against qemu-kvm.git.  Is qemu_ram_map() going into qemu.git?
> Another function I use (and virtio in qemu-kvm uses as well) is
> kvm_set_irqfd() that is not qemu.git either.  Do I need ifdef these
> functions with CONFIG_KVM?
>    

kvm_set_irqfd() is fine, it just needs to be ported.  It should be there 
due to vhost though?

qemu_ram_map() is more difficult.  I would think the better approach 
would be to invert things.  Instead of a "give me a stable mapping that 
is shared atomically with a guest to this ram region", I would go with 
"go create a ram region with this preallocated memory" and then just 
assume that afterwards, you can make use of it and it's exposed as 
atomic memory.

They're both layering violations, but at least the later is encapsulated 
to just the shared memory driver.

Regards,

Anthony Liguori

> Please advise as to how to handle these two functions and then I can
> rebase against qemu.git.
>
> Thanks,
> Cam
>
>    
>> Regards,
>>
>> Anthony Liguori
>>
>>      
>>> new in this series
>>>
>>>      - replace marking memory from v6 with marking device as unmigratable
>>> indicating
>>>        that it should be unplugged before migration and re-added after.
>>>      - 'peer' case changed to require removal before migration, only
>>> 'master'
>>>        devices can be migrated while attached.
>>>
>>>      v6
>>>      - migration support with 'master' and 'peer' roles for guest to
>>> determine
>>>        who "owns" memory
>>>      - modified phys_ram_dirty array for marking memory as not to be
>>> migrated
>>>
>>>      v5:
>>>      - fixed segfault for non-server case
>>>      - code style fixes
>>>      - removed limit on the number of guests
>>>      - shared memory server is now in qemu.git/contrib
>>>      - made ioeventfd setup function generic
>>>      - removed interrupts when guest joined (let application handle it)
>>>
>>>      v4:
>>>      - moved to single Doorbell register and use datamatch to trigger
>>> different
>>>        VMs rather than one register per eventfd
>>>      - remove writing arbitrary values to eventfds.  Only values of 1 are
>>> now
>>>        written to ensure correct usage
>>>
>>> Cam Macdonell (4):
>>>    Device specification for shared memory PCI device
>>>    Add function to assign ioeventfd to MMIO.
>>>    Support marking a device as non-migratable
>>>    Inter-VM shared memory PCI device
>>>
>>>   Makefile.target                    |    3 +
>>>   docs/specs/ivshmem_device_spec.txt |   96 +++++
>>>   hw/hw.h                            |    1 +
>>>   hw/ivshmem.c                       |  823
>>> ++++++++++++++++++++++++++++++++++++
>>>   kvm-all.c                          |   32 ++
>>>   kvm.h                              |    1 +
>>>   qemu-char.c                        |    6 +
>>>   qemu-char.h                        |    3 +
>>>   qemu-doc.texi                      |   43 ++
>>>   savevm.c                           |   32 ++-
>>>   10 files changed, 1037 insertions(+), 3 deletions(-)
>>>   create mode 100644 docs/specs/ivshmem_device_spec.txt
>>>   create mode 100644 hw/ivshmem.c
>>>
>>>
>>>
>>>
>>>        
>>
>>      

  reply	other threads:[~2010-07-26 19:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-15 20:23 [Qemu-devel] [PATCH v7 0/4] Inter-VM shared memory device Cam Macdonell
2010-06-15 20:23 ` [Qemu-devel] [PATCH v7 1/4] Device specification for shared memory PCI device Cam Macdonell
2010-06-15 20:23   ` [Qemu-devel] [PATCH v7 2/4] Add function to assign ioeventfd to MMIO Cam Macdonell
2010-06-15 20:23     ` [Qemu-devel] [PATCH v7 3/4] Support marking a device as non-migratable Cam Macdonell
2010-06-15 20:23       ` [Qemu-devel] [PATCH v7 4/4] Inter-VM shared memory PCI device Cam Macdonell
2010-06-23 15:57         ` [Qemu-devel] [PATCH v7 RESEND " Cam Macdonell
2010-07-08 21:08           ` Cam Macdonell
2010-07-08 23:45             ` [Qemu-devel] " David S. Ahern
2010-07-02 18:12 ` [Qemu-devel] Re: [PATCH v7 0/4] Inter-VM shared memory device Cam Macdonell
2010-07-26 13:48 ` [Qemu-devel] " Anthony Liguori
2010-07-26 19:01   ` Cam Macdonell
2010-07-26 19:41     ` Anthony Liguori [this message]
2010-07-26 20:27       ` Avi Kivity
2010-07-26 20:41         ` Anthony Liguori
2010-07-26 21:46           ` Cam Macdonell
2010-07-26 22:18             ` Anthony Liguori
2010-07-26 19:51     ` Avi Kivity
2010-07-26 20:03       ` Cam Macdonell
2010-07-26 20:11         ` Avi Kivity
2010-07-26 20:16           ` Cam Macdonell
2010-07-26 20:20             ` Avi Kivity
2010-07-26 20:05       ` Anthony Liguori

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=4C4DE501.2080202@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=cam@cs.ualberta.ca \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).