From: Avi Kivity <avi@redhat.com>
To: Liu Ping Fan <qemulist@gmail.com>
Cc: kvm@vger.kernel.org, Jan Kiszka <jan.kiszka@siemens.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>,
Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 2/5] exec.c: use refcnt to protect device during dispatching
Date: Wed, 25 Jul 2012 13:58:03 +0300 [thread overview]
Message-ID: <500FD13B.7040108@redhat.com> (raw)
In-Reply-To: <1343187070-27371-3-git-send-email-qemulist@gmail.com>
On 07/25/2012 06:31 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan <pingfank@linux.vnet.ibm.com>
>
> acquire device's refcnt with qemu_device_tree_mutex rwlock, so we
> can safely handle it when mmio dispatch.
>
> If in radix-tree, leaf is subpage, then move further step to acquire
> opaque which is the type --DeiveState.
>
>
> +static MemoryRegionSection *subpage_get_backend(subpage_t *mmio,
> + target_phys_addr_t addr)
> +{
> + MemoryRegionSection *section;
> + unsigned int idx = SUBPAGE_IDX(addr);
> +
> + section = &phys_sections[mmio->sub_section[idx]];
> + return section;
> +}
> +
> +void *get_backend(MemoryRegion* mr, target_phys_addr_t addr)
> +{
> + MemoryRegionSection *p;
> + Object *ret;
> +
> + if (mr->subpage) {
> + p = subpage_get_backend(mr->opaque, addr);
> + ret = OBJECT(p->mr->opaque);
> + } else {
> + ret = OBJECT(mr->opaque);
> + }
> + return ret;
> +}
> +
You don't enforce that mr->opaque is an object.
The name 'backend' is inappropriate here (actually I don't like it
anywhere). If we can s/opaque/object/ (and change the type too, we can
call it get_object() (and return an Object *).
> static const MemoryRegionOps subpage_ops = {
> .read = subpage_read,
> .write = subpage_write,
> @@ -3396,13 +3420,25 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> uint32_t val;
> target_phys_addr_t page;
> MemoryRegionSection *section;
> + Object *bk;
>
> while (len > 0) {
> page = addr & TARGET_PAGE_MASK;
> l = (page + TARGET_PAGE_SIZE) - addr;
> if (l > len)
> l = len;
> +
> + qemu_rwlock_rdlock_devtree();
> section = phys_page_find(page >> TARGET_PAGE_BITS);
Does the devtree lock also protect the data structures accessed by
phys_page_find()? Seems wrong.
> + if (!(memory_region_is_ram(section->mr) ||
> + memory_region_is_romd(section->mr)) && !is_write) {
> + bk = get_backend(section->mr, addr);
> + object_ref(bk);
> + } else if (!memory_region_is_ram(section->mr) && is_write) {
> + bk = get_backend(section->mr, addr);
> + object_ref(bk);
> + }
Best push the ugliness that computes bk into a small helper, and do just
the object_ref() here.
> + qemu_rwlock_unlock_devtree();
>
> if (is_write) {
> if (!memory_region_is_ram(section->mr)) {
> @@ -3426,6 +3462,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> io_mem_write(section->mr, addr1, val, 1);
> l = 1;
> }
> + object_unref(bk);
> } else if (!section->readonly) {
> ram_addr_t addr1;
> addr1 = memory_region_get_ram_addr(section->mr)
> @@ -3464,6 +3501,7 @@ void cpu_physical_memory_rw(target_phys_addr_t addr, uint8_t *buf,
> stb_p(buf, val);
> l = 1;
> }
> + object_unref(bk);
> } else {
> /* RAM case */
> ptr = qemu_get_ram_ptr(section->mr->ram_addr
> diff --git a/memory.h b/memory.h
> index 740c48e..e5a86dc 100644
> --- a/memory.h
> +++ b/memory.h
> @@ -748,6 +748,8 @@ void memory_global_dirty_log_stop(void);
>
> void mtree_info(fprintf_function mon_printf, void *f);
>
> +void *get_backend(MemoryRegion* mr, target_phys_addr_t addr);
> +
This is a private interface, shouldn't be in memory.h.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2012-07-25 10:58 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-25 3:31 [Qemu-devel] [PATCH 0/5] prepare unplug out of protection of global lock Liu Ping Fan
2012-07-25 3:31 ` [Qemu-devel] [PATCH 1/5] qom: adopt rwlock to protect accessing dev from removing it Liu Ping Fan
2012-07-25 9:08 ` Paolo Bonzini
2012-07-26 12:56 ` liu ping fan
2012-07-26 13:00 ` Avi Kivity
2012-07-26 13:14 ` liu ping fan
2012-07-26 13:15 ` Avi Kivity
2012-07-26 13:21 ` liu ping fan
2012-07-26 13:46 ` Avi Kivity
2012-07-25 3:31 ` [Qemu-devel] [PATCH 2/5] exec.c: use refcnt to protect device during dispatching Liu Ping Fan
2012-07-25 7:43 ` Stefan Hajnoczi
2012-07-25 8:12 ` liu ping fan
2012-07-25 9:18 ` Paolo Bonzini
2012-07-26 13:00 ` liu ping fan
2012-07-25 10:58 ` Avi Kivity [this message]
2012-07-25 12:27 ` Avi Kivity
2012-07-26 13:06 ` liu ping fan
2012-07-26 13:13 ` Avi Kivity
2012-07-25 3:31 ` [Qemu-devel] [PATCH 3/5] hotplug: introduce qdev_unplug_ack() to remove device from views Liu Ping Fan
2012-07-25 10:58 ` Avi Kivity
2012-07-25 3:31 ` [Qemu-devel] [PATCH 4/5] qom: delay DeviceState's reclaim to main-loop Liu Ping Fan
2012-07-25 7:03 ` Stefan Hajnoczi
2012-07-25 7:37 ` Paolo Bonzini
2012-07-25 8:16 ` liu ping fan
2012-07-25 8:22 ` Paolo Bonzini
2012-07-25 8:17 ` liu ping fan
2012-07-25 3:31 ` [Qemu-devel] [PATCH 5/5] e1000: using new interface--unmap to unplug Liu Ping Fan
2012-07-25 7:12 ` Stefan Hajnoczi
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=500FD13B.7040108@redhat.com \
--to=avi@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
--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 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).