All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Liu Ping Fan <qemulist@gmail.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
	Anthony Liguori <anthony@codemonkey.ws>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>
Subject: Re: [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



WARNING: multiple messages have this Message-ID (diff)
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: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-25  3:31 [PATCH 0/5] prepare unplug out of protection of global lock Liu Ping Fan
2012-07-25  3:31 ` [Qemu-devel] " Liu Ping Fan
2012-07-25  3:31 ` [PATCH 1/5] qom: adopt rwlock to protect accessing dev from removing it Liu Ping Fan
2012-07-25  3:31   ` [Qemu-devel] " Liu Ping Fan
2012-07-25  9:08   ` Paolo Bonzini
2012-07-25  9:08     ` [Qemu-devel] " Paolo Bonzini
2012-07-26 12:56     ` liu ping fan
2012-07-26 12:56       ` [Qemu-devel] " liu ping fan
2012-07-26 13:00       ` Avi Kivity
2012-07-26 13:00         ` [Qemu-devel] " Avi Kivity
2012-07-26 13:14         ` liu ping fan
2012-07-26 13:14           ` [Qemu-devel] " liu ping fan
2012-07-26 13:15           ` Avi Kivity
2012-07-26 13:15             ` [Qemu-devel] " Avi Kivity
2012-07-26 13:21             ` liu ping fan
2012-07-26 13:21               ` [Qemu-devel] " liu ping fan
2012-07-26 13:46               ` Avi Kivity
2012-07-26 13:46                 ` [Qemu-devel] " Avi Kivity
2012-07-25  3:31 ` [PATCH 2/5] exec.c: use refcnt to protect device during dispatching Liu Ping Fan
2012-07-25  3:31   ` [Qemu-devel] " Liu Ping Fan
2012-07-25  7:43   ` Stefan Hajnoczi
2012-07-25  7:43     ` [Qemu-devel] " Stefan Hajnoczi
2012-07-25  8:12     ` liu ping fan
2012-07-25  8:12       ` [Qemu-devel] " liu ping fan
2012-07-25  9:18       ` Paolo Bonzini
2012-07-25  9:18         ` [Qemu-devel] " Paolo Bonzini
2012-07-26 13:00         ` liu ping fan
2012-07-26 13:00           ` [Qemu-devel] " liu ping fan
2012-07-25 10:58   ` Avi Kivity [this message]
2012-07-25 10:58     ` Avi Kivity
2012-07-25 12:27     ` Avi Kivity
2012-07-25 12:27       ` [Qemu-devel] " Avi Kivity
2012-07-26 13:06       ` liu ping fan
2012-07-26 13:06         ` [Qemu-devel] " liu ping fan
2012-07-26 13:13         ` Avi Kivity
2012-07-26 13:13           ` [Qemu-devel] " Avi Kivity
2012-07-25  3:31 ` [PATCH 3/5] hotplug: introduce qdev_unplug_ack() to remove device from views Liu Ping Fan
2012-07-25  3:31   ` [Qemu-devel] " Liu Ping Fan
2012-07-25 10:58   ` Avi Kivity
2012-07-25 10:58     ` [Qemu-devel] " Avi Kivity
2012-07-25  3:31 ` [PATCH 4/5] qom: delay DeviceState's reclaim to main-loop Liu Ping Fan
2012-07-25  3:31   ` [Qemu-devel] " Liu Ping Fan
2012-07-25  7:03   ` Stefan Hajnoczi
2012-07-25  7:03     ` [Qemu-devel] " Stefan Hajnoczi
2012-07-25  7:37     ` Paolo Bonzini
2012-07-25  7:37       ` [Qemu-devel] " Paolo Bonzini
2012-07-25  8:16       ` liu ping fan
2012-07-25  8:16         ` [Qemu-devel] " liu ping fan
2012-07-25  8:22         ` Paolo Bonzini
2012-07-25  8:22           ` [Qemu-devel] " Paolo Bonzini
2012-07-25  8:17     ` liu ping fan
2012-07-25  8:17       ` [Qemu-devel] " liu ping fan
2012-07-25  3:31 ` [PATCH 5/5] e1000: using new interface--unmap to unplug Liu Ping Fan
2012-07-25  3:31   ` [Qemu-devel] " Liu Ping Fan
2012-07-25  7:12   ` Stefan Hajnoczi
2012-07-25  7:12     ` [Qemu-devel] " 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 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.