qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).