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