qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: liu ping fan <qemulist@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Anthony Liguori <aliguori@us.ibm.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	qemu-devel@nongnu.org,
	Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/6] proposal to make hostmem listener RAM unplug safe
Date: Mon, 06 May 2013 08:17:55 +0200	[thread overview]
Message-ID: <51874B13.1080304@redhat.com> (raw)
In-Reply-To: <CAJnKYQkv7Q0pKvgRE5WuAFhakFo353skboe_WJerXP_BpgNemw@mail.gmail.com>

Il 06/05/2013 03:42, liu ping fan ha scritto:
> On Sat, May 4, 2013 at 5:53 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> Il 03/05/2013 04:45, Liu Ping Fan ha scritto:
>>> v1->v2:
>>>   1.split RCU prepared style update and monitor the RAM-Device refcnt into two patches (patch 2,4)
>>>   2.introduce AddrSpaceMem, which is similar to HostMem, but based on address space, while
>>>     the original HostMem only server system memory address space
>>
>> This looks suspiciously similar to FlatView, doesn't it?
>>
> FlatView is used for all the listeners, including for mmio dispatching,
> which aims to mapping from hwaddr to DeviceState for dispatching service.
> While here, we mapping from hwaddr to hva.
> 
>> Perhaps the right thing to do is to add the appropriate locking and
>> RCU-style updating to address_space_update_topology and
> 
> RCU implementation is data struct related,  and each listener has its
> local table, so I think it is more reasonable to implement them
> separately.

I mentioned address_space_update_topology simply because it is where the
FlatView is replaced.

>> memory_region_find.   (And replacing flatview_destroy with ref/unref
>> similar to HostMem in your patch 2).  Then just switch dataplane to use
>> memory_region_find...
>>
> In fact, I think, HostMem listener can be an substitute for
> cpu_physical_memory_map(),  the main issue can be the migration
> support.  But before getting big patches, I hope to have this smaller
> and simpler one.

I think replacing HostMem with FlatView is a smaller patch than these
ones.  I'll try to make a prototype.

Paolo

      reply	other threads:[~2013-05-06  6:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-03  2:45 [Qemu-devel] [PATCH v2 0/6] proposal to make hostmem listener RAM unplug safe Liu Ping Fan
2013-05-03  2:45 ` [Qemu-devel] [PATCH v2 1/6] hostmem: make hostmem single, not per Vring related Liu Ping Fan
2013-05-03  8:54   ` Stefan Hajnoczi
2013-05-03  2:45 ` [Qemu-devel] [PATCH v2 2/6] hostmem: AddressSpace has its own map and maintained by RCU prepared style Liu Ping Fan
2013-05-03  9:10   ` Stefan Hajnoczi
2013-05-06  1:44     ` liu ping fan
2013-05-03  2:45 ` [Qemu-devel] [PATCH v2 3/6] memory: add ref/unref interface for MemroyRegionOps Liu Ping Fan
2013-05-03  2:45 ` [Qemu-devel] [PATCH v2 4/6] hostmem: hostmem listener pin RAM-Device by refcnt Liu Ping Fan
2013-05-03  9:35   ` Stefan Hajnoczi
2013-05-06  1:45     ` liu ping fan
2013-05-03  2:45 ` [Qemu-devel] [PATCH v2 5/6] Vring: use hostmem's RAM safe api Liu Ping Fan
2013-05-03 10:02   ` Stefan Hajnoczi
2013-05-06  1:45     ` liu ping fan
2013-05-03  2:45 ` [Qemu-devel] [PATCH v2 6/6] virtio-blk: release reference to RAM's memoryRegion Liu Ping Fan
2013-05-03 10:09   ` Stefan Hajnoczi
2013-05-06  2:39     ` liu ping fan
2013-05-04  9:53 ` [Qemu-devel] [PATCH v2 0/6] proposal to make hostmem listener RAM unplug safe Paolo Bonzini
2013-05-06  1:42   ` liu ping fan
2013-05-06  6:17     ` Paolo Bonzini [this message]

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=51874B13.1080304@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=jan.kiszka@siemens.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemulist@gmail.com \
    --cc=stefanha@redhat.com \
    --cc=vasilis.liaskovitis@profitbricks.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;
as well as URLs for NNTP newsgroup(s).