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
next prev parent 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 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.