From: Laszlo Ersek <lersek@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: qemu devel list <qemu-devel@nongnu.org>,
Ben Warren <ben@skyportsystems.com>,
Igor Mammedov <imammedo@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] hw/acpi/vmgenid: prevent more than one vmgenid device
Date: Mon, 20 Mar 2017 17:22:16 +0100 [thread overview]
Message-ID: <3b0262b6-1f63-a962-edcb-dfed64eca2b1@redhat.com> (raw)
In-Reply-To: <783bd4f6-faf9-1562-99f6-36556ed3d0cb@redhat.com>
On 03/20/17 16:13, Laszlo Ersek wrote:
> On 03/20/17 15:16, Michael S. Tsirkin wrote:
>> On Mon, Mar 20, 2017 at 12:59:51PM +0100, Laszlo Ersek wrote:
>>> Multiple instances make no sense.
>>>
>>> Cc: "Michael S. Tsirkin" <mst@redhat.com>
>>> Cc: Ben Warren <ben@skyportsystems.com>
>>> Cc: Igor Mammedov <imammedo@redhat.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>
>> find_vmgenid_dev would be a better place for this.
>> This is where the single instance assumption comes from ATM.
>
> object_resolve_path_type() -- used internally in find_vmgenid_dev() --
> returns NULL in either of two cases: there is no such device, or there
> are multiple devices. You can tell them apart by looking at the last
> parameter (called "ambiguous"), but find_vmgenid_dev() doesn't use that
> parameter.
>
> By the time we are in the vmgenid_realize() function, at least one
> vmgenid device is guaranteed to exist (the one which we are realizing).
> Therefore, this patch could be simplified as:
>
> if (find_vmgenid_dev() == NULL) {
> error_setg(errp, "at most one %s device is permitted", VMGENID_DEVICE);
> return;
> }
>
> I found that confusing, and wanted to spell out "ambiguous" with the
> assert(). If you prefer the above simpler (but harder to understand)
> check, I can do that too.
Also, find_vmgenid_dev() only captures the single instance assumption,
it does not dictate the assumption. The assumption comes from the spec.
With the above in mind, what do you say about this patch? Do you want me
to call find_vmgenid_dev() in the realize function (which will require a
comment about object_resolve_path_type's behavior), or are you okay with
the patch as-is? (The asserts make it clear IMO.)
Thanks
Laszlo
>
>>
>>
>>> ---
>>> hw/acpi/vmgenid.c | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>>
>>> diff --git a/hw/acpi/vmgenid.c b/hw/acpi/vmgenid.c
>>> index c3ddcc8e7cb0..b5c0dfcf19e1 100644
>>> --- a/hw/acpi/vmgenid.c
>>> +++ b/hw/acpi/vmgenid.c
>>> @@ -214,6 +214,8 @@ static Property vmgenid_properties[] = {
>>> static void vmgenid_realize(DeviceState *dev, Error **errp)
>>> {
>>> VmGenIdState *vms = VMGENID(dev);
>>> + Object *one_vmgenid;
>>> + bool ambiguous;
>>>
>>> if (!vms->write_pointer_available) {
>>> error_setg(errp, "%s requires DMA write support in fw_cfg, "
>>> @@ -221,6 +223,14 @@ static void vmgenid_realize(DeviceState *dev, Error **errp)
>>> return;
>>> }
>>>
>>> + one_vmgenid = object_resolve_path_type("", VMGENID_DEVICE, &ambiguous);
>>> + if (one_vmgenid == NULL) {
>>> + assert(ambiguous);
>>> + error_setg(errp, "at most one %s device is permitted", VMGENID_DEVICE);
>>> + return;
>>> + }
>>> + assert(one_vmgenid == OBJECT(vms));
>>> +
>>> qemu_register_reset(vmgenid_handle_reset, vms);
>>> }
>>>
>>> --
>>> 2.9.3
>
next prev parent reply other threads:[~2017-03-20 16:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-20 11:59 [Qemu-devel] [PATCH 0/2] some remaining vmgenid tweaks for 2.9 Laszlo Ersek
2017-03-20 11:59 ` [Qemu-devel] [PATCH 1/2] hw/acpi/vmgenid: prevent device realization on pre-2.9 machine types Laszlo Ersek
2017-03-20 14:19 ` Michael S. Tsirkin
2017-03-20 14:39 ` Paolo Bonzini
2017-03-20 15:08 ` Laszlo Ersek
2017-03-20 15:09 ` Paolo Bonzini
2017-03-20 11:59 ` [Qemu-devel] [PATCH 2/2] hw/acpi/vmgenid: prevent more than one vmgenid device Laszlo Ersek
2017-03-20 14:16 ` Michael S. Tsirkin
2017-03-20 15:13 ` Laszlo Ersek
2017-03-20 16:22 ` Laszlo Ersek [this message]
2017-03-20 16:26 ` Michael S. Tsirkin
2017-03-20 16:39 ` Laszlo Ersek
2017-03-20 16:57 ` Michael S. Tsirkin
2017-03-20 17:05 ` Laszlo Ersek
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=3b0262b6-1f63-a962-edcb-dfed64eca2b1@redhat.com \
--to=lersek@redhat.com \
--cc=ben@skyportsystems.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.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 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).