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: qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
Date: Tue, 14 Aug 2012 13:49:10 +0300	[thread overview]
Message-ID: <502A2D26.4060702@redhat.com> (raw)
In-Reply-To: <CAJnKYQn5zfmEk1-+auZZapUkh-XMFL-prbM9ATCxsEAoQJ0dpg@mail.gmail.com>

On 08/14/2012 11:30 AM, liu ping fan wrote:
> To make memoryRegion survive without the protection of qemu big lock,
> we need to pin its based Object.
> In current code, the type of mr->opaque are quite different.  Lots of
> them are Object, but quite of them are not yet.
> 
> The most challenge for changing from memory_region_init_io(..., void
> *opaque, ...) to memory_region_init_io(..., Object *opaque,...) is
> such codes:
> hw/ide/cmd646.c:
> static void setup_cmd646_bar(PCIIDEState *d, int bus_num)
> {
>     IDEBus *bus = &d->bus[bus_num];
>     CMD646BAR *bar = &d->cmd646_bar[bus_num];
> 
>     bar->bus = bus;
>     bar->pci_dev = d;
>     memory_region_init_io(&bar->cmd, &cmd646_cmd_ops, bar, "cmd646-cmd", 4);
>     memory_region_init_io(&bar->data, &cmd646_data_ops, bar, "cmd646-data", 8);
> }
> If we passed in mr's based Object @d to substitute @bar, then we can
> not pass the extra info @bus_num.
> 
> To solve such issue, introduce extra member "Object *base" for MemoryRegion.
> 
> diff --git a/memory.c b/memory.c
> index 643871b..afd5dea 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -931,6 +931,7 @@ static void memory_region_dispatch_write(MemoryRegion *mr,
> 
>  void memory_region_init_io(MemoryRegion *mr,
>                             const MemoryRegionOps *ops,
> +                           Object *base,
>                             void *opaque,
>                             const char *name,
>                             uint64_t size)
> @@ -938,6 +939,7 @@ void memory_region_init_io(MemoryRegion *mr,
>      memory_region_init(mr, name, size);
>      mr->ops = ops;
>      mr->opaque = opaque;
> +    mr->base = base;
>      mr->terminates = true;
>      mr->destructor = memory_region_destructor_iomem;
>      mr->ram_addr = ~(ram_addr_t)0;
> diff --git a/memory.h b/memory.h
> index bd1bbae..2746e70 100644
> --- a/memory.h
> +++ b/memory.h
> @@ -120,6 +120,7 @@ struct MemoryRegion {
>      /* All fields are private - violators will be prosecuted */
>      const MemoryRegionOps *ops;
>      void *opaque;
> +    Object *base;
>      MemoryRegion *parent;
>      Int128 size;
>      target_phys_addr_t addr;
> 
> 
> Any comment?
> 

I prefer that we convert the third parameter (opaque) to be an Object.
That is a huge change, but I think it will improve the code base overall.

Other options are:

1) add MemoryRegionOps::ref(MemoryRegion *) and ::unref(MemoryRegion *)

If NULL, these callbacks are ignored.  If not, they are called with the
MemoryRegion as a parameter.  Their responsibility is to derive the
Object from the MemoryRegion (through the opaque or using
container_of()) and ref or unref it respectively.

2) add Object *MemoryRegionOps::object(MemoryRegion *)

Similar; if NULL it is ignored, otherwise it is used to derive the
Object, which the memory core will ref and unref.

3) add bool MemoryRegionOps::opaque_is_object

Tells the memory core that it is safe to cast the opaque into an Object.

4) add memory_region_set_object(MemoryRegion *, Object *)

Like your proposal, but avoids adding an extra paramter and changing all
call sites.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2012-08-14 10:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-14  8:30 [Qemu-devel] memory: could we add extra input param for memory_region_init_io()? liu ping fan
2012-08-14 10:49 ` Avi Kivity [this message]
2012-08-16  3:22   ` liu ping fan
2012-08-16  9:23     ` Avi Kivity
2012-08-17  2:52       ` liu ping fan
2012-08-17  7:41         ` liu ping fan
2012-08-19 10:12           ` Avi Kivity
2012-08-19 11:23             ` Peter Maydell
2012-08-19 11:36               ` Avi Kivity
2012-08-21  4:48                 ` liu ping fan
2012-08-21  8:57                   ` Avi Kivity
2012-08-21  9:25                     ` liu ping fan
2012-08-21 10:13                       ` Avi Kivity
2012-08-21 11:18                         ` liu ping fan
2012-08-21 12:41                           ` Avi Kivity
2012-08-24  9:47                             ` liu ping fan
2012-08-19 12:03               ` Peter Maydell
2012-08-19 13:05                 ` Blue Swirl
2012-08-19 10:10         ` Avi Kivity

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=502A2D26.4060702@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    --cc=qemulist@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).