From: Eric Auger <eric.auger@linaro.org>
To: Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: "qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
Alex Williamson <alex.williamson@redhat.com>,
eric.auger@st.com,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
Patch Tracking <patches@linaro.org>
Subject: Re: [Qemu-devel] [PATCH v2] sysbus: add irq_routing_notifier
Date: Tue, 28 Apr 2015 08:46:01 +0200 [thread overview]
Message-ID: <553F2CA9.90303@linaro.org> (raw)
In-Reply-To: <CAEgOgz61=-jvDGg7BWWAJSVCceaCJ21t_7jjqF_H_B5BuhVdXg@mail.gmail.com>
Hi Peter,
On 04/27/2015 07:43 PM, Peter Crosthwaite wrote:
> On Mon, Apr 27, 2015 at 8:01 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>>
>> On 27/04/2015 16:56, Eric Auger wrote:
>>> Peter, Paolo,
>>>
>>> After your feedbacks, I feel I need to spend some more time on the
>>> original check() track. I would prefer not to introduce any patch that
>>> will make issue in the future.
>>
>> Peter, see the other threads between me and Eric. See in particular
>> http://lists.gnu.org/archive/html/qemu-devel/2015-04/msg02749.html
>> starting at "The notifier actually is not even necessary" and the
>> replies from there.
>>
>
> Thanks,
>
> I see the problem with check. In this reply
>
> http://lists.gnu.org/archive/html/qemu-devel/2015-04/msg02956.html
>
> Eric says that the problem with the check hook is it happens before
> the setting. I think this can be solved with a RYO link setter for
> GPIOs. We almost have an in-tree precedent with MemoryRegion and the
> container property (memory.c):
>
> 960 op = object_property_add(OBJECT(mr), "container",
> 961 "link<" TYPE_MEMORY_REGION ">",
> 962 memory_region_get_container,
> 963 NULL, /* memory_region_set_container */
> 964 NULL, NULL, &error_abort);
>
> Now in reality we could have done this link normal style as it is only
> a trivial getter, but the reason the link was done this way in the
> first place, is because I have a follow up patch to memory.c that adds
> a customer Link setter:
>
> +static void memory_region_set_container(Object *obj, Visitor *v, void *opaque,
> + const char *name, Error **errp)
> +{
> + MemoryRegion *mr = MEMORY_REGION(obj);
> + Error *local_err = NULL;
> + MemoryRegion *old_container = mr->container;
> + MemoryRegion *new_container = NULL;
> + char *path = NULL;
> +
> + visit_type_str(v, &path, name, &local_err);
> +
> + if (!local_err && strcmp(path, "") != 0) {
> + new_container = MEMORY_REGION(object_resolve_link(obj, name, path,
> + &local_err));
> + while (new_container->alias) {
> + new_container = new_container->alias;
> + }
> + }
> +
> + if (local_err) {
> + error_propagate(errp, local_err);
> + return;
> + }
> +
> + object_ref(OBJECT(new_container));
> +
> + memory_region_transaction_begin();
> + memory_region_ref(mr);
> + if (old_container) {
> + memory_region_del_subregion(old_container, mr);
> + }
> + mr->container = new_container;
> + if (new_container) {
> + memory_region_update_container_subregions(mr);
> + }
> + memory_region_unref(mr);
> + memory_region_transaction_commit();
> +
> + object_unref(OBJECT(old_container));
> +}
> +
>
> op = object_property_add(OBJECT(mr), "container",
> "link<" TYPE_MEMORY_REGION ">",
> memory_region_get_container,
> - NULL, /* memory_region_set_container */
> + memory_region_set_container,
> NULL, NULL, &error_abort);
>
>
> The function does the normal link setting - similar to
> object_set_link_property (not to be confused with
> object_property_set_link!) but is surrounded by class specific side
> effects. Specifically in this case, it does
> memory_region_transaction_begin/ref/unref/commit etc for the MR.
>
> For this GPIO case, you could create a custom setter that does the
> normal set, then calls the DeviceClass installed hook (or you can
> install the hook to the object and init it at qdev_init_gpio_out_named
> time as suggested in the eariler thread). The callback will happen
> after the link is populated.
>
> To reduce verbosity, I suggest making object_set_link_property() a
> visible API, then RYO link setters can call it surrounded by custom
> behavior e.g:
>
> foo_object_set_bar_property(...)
> {
> pre_set_link_side_effects();
> object_set_link_property();
> post_set_link_side_effects();
> }
>
> object_set_link_property() would need to be coreified and wrapped to
> remove it's awareness of LinkProperty type (as that doesn't exist in
> RYO properties) in this case.
Thank you Peter for detailing this.
Yesterday I re-worked on the solution based on the check() method where
- check would take a Object **child as a 3d parameter
- we would assign *child before the call and in case the check fails set
the *child back to NULL in object_set_link_property.
I need to do some more testing.
I don't know if this solution would be acceptable too. If not I will
implement according to your guidelines.
Best Regards
Eric
>
> Regards,
> Peter
>
>> If you have any idea, please help.
>>
>> Paolo
>>
next prev parent reply other threads:[~2015-04-28 6:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 12:39 [PATCH v2] sysbus: add irq_routing_notifier Eric Auger
2015-04-24 12:39 ` [Qemu-devel] " Eric Auger
2015-04-27 4:09 ` Peter Crosthwaite
2015-04-27 4:09 ` Peter Crosthwaite
2015-04-27 8:26 ` Eric Auger
2015-04-27 8:26 ` Eric Auger
2015-04-27 10:39 ` Paolo Bonzini
2015-04-27 12:20 ` Eric Auger
2015-04-27 12:20 ` [Qemu-devel] " Eric Auger
2015-04-27 13:37 ` Paolo Bonzini
2015-04-27 14:39 ` Peter Crosthwaite
2015-04-27 14:39 ` Peter Crosthwaite
2015-04-27 14:56 ` Eric Auger
2015-04-27 15:01 ` Paolo Bonzini
2015-04-27 17:43 ` Peter Crosthwaite
2015-04-27 17:43 ` [Qemu-devel] " Peter Crosthwaite
2015-04-28 6:46 ` Eric Auger [this message]
2015-04-28 6:57 ` Peter Crosthwaite
2015-04-28 7:01 ` Eric Auger
2015-04-28 9:04 ` Paolo Bonzini
2015-04-28 9:04 ` [Qemu-devel] " Paolo Bonzini
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=553F2CA9.90303@linaro.org \
--to=eric.auger@linaro.org \
--cc=alex.williamson@redhat.com \
--cc=eric.auger@st.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=patches@linaro.org \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=qemu-devel@nongnu.org \
/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.