From: Eduardo Habkost <ehabkost@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: peter.maydell@linaro.org, sbhat@linux.ibm.com, david@redhat.com,
richard.henderson@linaro.org, qemu-devel@nongnu.org,
shameerali.kolothum.thodi@huawei.com, qemu-arm@nongnu.org,
pbonzini@redhat.com, imammedo@redhat.com,
eric.auger.pro@gmail.com
Subject: Re: [Qemu-devel] [PATCH v2] machine: Move acpi_nvdimm_state into struct MachineState
Date: Thu, 7 Mar 2019 14:26:12 -0300 [thread overview]
Message-ID: <20190307172612.GC8899@habkost.net> (raw)
In-Reply-To: <20190307090639.8261-1-eric.auger@redhat.com>
On Thu, Mar 07, 2019 at 10:06:39AM +0100, Eric Auger wrote:
> As NVDIMM support is looming for ARM and SPAPR, let's
> move the acpi_nvdimm_state to the generic machine struct
> instead of duplicating the same code in several machines.
> It is also renamed into nvdimms_state.
>
> nvdimm and nvdimm-persistence become generic machine options.
> We also add a description for those options.
>
> We also remove the nvdimms_state.is_enabled initialization to
> false as objects are guaranteed to be zero initialized.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Suggested-by: Igor Mammedov <imammedo@redhat.com>
>
> ---
>
> v1 -> v2:
> - s/acpi_nvdimm_state/nvdimms_state
> - remove ms->nvdimms_state.is_enabled initialization to false.
[...]
> @@ -765,6 +806,20 @@ static void machine_class_init(ObjectClass *oc, void *data)
> &error_abort);
> object_class_property_set_description(oc, "memory-encryption",
> "Set memory encryption object to use", &error_abort);
> +
> + object_class_property_add_bool(oc, "nvdimm",
> + machine_get_nvdimm, machine_set_nvdimm, &error_abort);
> + object_class_property_set_description(oc, "nvdimm",
> + "Set on/off to enable/disable NVDIMM "
> + "instantiation", NULL);
> +
> + object_class_property_add_str(oc, "nvdimm-persistence",
> + machine_get_nvdimm_persistence,
> + machine_set_nvdimm_persistence, &error_abort);
> + object_class_property_set_description(oc, "nvdimm-persistence",
> + "Set NVDIMM persistence"
> + "Valid values are cpu and mem-ctrl",
> + NULL);
As noted in another reply, I don't mind adding new MachineState
fields, but now I noticed you are adding new user-visible
options, which requires more care.
This patch seems to make all machines except PC silently ignore
the new nvdimm options. If the current machine doesn't support
nvdimm, "nvdimm-persistence=..." and "nvdimm=on" should be
rejected by QEMU instead of silently ignored.
Probably the simplest way to do that is by making the
registration of those QOM properties conditional.
We could add a simple
bool MachineClass::nvdimm_supported
field, or we could add a
static void nvdimm_machine_class_init(MachineClass *mc);
helper that would enable nvdimm support on the machine type.
--
Eduardo
WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Habkost <ehabkost@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
qemu-arm@nongnu.org, peter.maydell@linaro.org,
shameerali.kolothum.thodi@huawei.com, imammedo@redhat.com,
david@redhat.com, pbonzini@redhat.com,
richard.henderson@linaro.org, sbhat@linux.ibm.com
Subject: Re: [Qemu-devel] [PATCH v2] machine: Move acpi_nvdimm_state into struct MachineState
Date: Thu, 7 Mar 2019 14:26:12 -0300 [thread overview]
Message-ID: <20190307172612.GC8899@habkost.net> (raw)
In-Reply-To: <20190307090639.8261-1-eric.auger@redhat.com>
On Thu, Mar 07, 2019 at 10:06:39AM +0100, Eric Auger wrote:
> As NVDIMM support is looming for ARM and SPAPR, let's
> move the acpi_nvdimm_state to the generic machine struct
> instead of duplicating the same code in several machines.
> It is also renamed into nvdimms_state.
>
> nvdimm and nvdimm-persistence become generic machine options.
> We also add a description for those options.
>
> We also remove the nvdimms_state.is_enabled initialization to
> false as objects are guaranteed to be zero initialized.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> Suggested-by: Igor Mammedov <imammedo@redhat.com>
>
> ---
>
> v1 -> v2:
> - s/acpi_nvdimm_state/nvdimms_state
> - remove ms->nvdimms_state.is_enabled initialization to false.
[...]
> @@ -765,6 +806,20 @@ static void machine_class_init(ObjectClass *oc, void *data)
> &error_abort);
> object_class_property_set_description(oc, "memory-encryption",
> "Set memory encryption object to use", &error_abort);
> +
> + object_class_property_add_bool(oc, "nvdimm",
> + machine_get_nvdimm, machine_set_nvdimm, &error_abort);
> + object_class_property_set_description(oc, "nvdimm",
> + "Set on/off to enable/disable NVDIMM "
> + "instantiation", NULL);
> +
> + object_class_property_add_str(oc, "nvdimm-persistence",
> + machine_get_nvdimm_persistence,
> + machine_set_nvdimm_persistence, &error_abort);
> + object_class_property_set_description(oc, "nvdimm-persistence",
> + "Set NVDIMM persistence"
> + "Valid values are cpu and mem-ctrl",
> + NULL);
As noted in another reply, I don't mind adding new MachineState
fields, but now I noticed you are adding new user-visible
options, which requires more care.
This patch seems to make all machines except PC silently ignore
the new nvdimm options. If the current machine doesn't support
nvdimm, "nvdimm-persistence=..." and "nvdimm=on" should be
rejected by QEMU instead of silently ignored.
Probably the simplest way to do that is by making the
registration of those QOM properties conditional.
We could add a simple
bool MachineClass::nvdimm_supported
field, or we could add a
static void nvdimm_machine_class_init(MachineClass *mc);
helper that would enable nvdimm support on the machine type.
--
Eduardo
next prev parent reply other threads:[~2019-03-07 17:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-07 9:06 [Qemu-arm] [PATCH v2] machine: Move acpi_nvdimm_state into struct MachineState Eric Auger
2019-03-07 9:06 ` [Qemu-devel] " Eric Auger
2019-03-07 9:48 ` [Qemu-arm] " Igor Mammedov
2019-03-07 9:48 ` [Qemu-devel] " Igor Mammedov
2019-03-07 12:44 ` Eduardo Habkost
2019-03-07 12:44 ` Eduardo Habkost
2019-03-07 10:56 ` [Qemu-arm] " Philippe Mathieu-Daudé
2019-03-07 10:56 ` Philippe Mathieu-Daudé
2019-03-07 15:15 ` [Qemu-arm] " Auger Eric
2019-03-07 15:15 ` Auger Eric
2019-03-07 15:21 ` [Qemu-arm] " David Hildenbrand
2019-03-07 15:21 ` David Hildenbrand
2019-03-07 15:36 ` Philippe Mathieu-Daudé
2019-03-07 15:51 ` [Qemu-arm] " David Hildenbrand
2019-03-07 15:51 ` David Hildenbrand
2019-03-07 16:58 ` [Qemu-arm] " Eduardo Habkost
2019-03-07 16:58 ` Eduardo Habkost
2019-03-07 17:10 ` Philippe Mathieu-Daudé
2019-03-07 17:10 ` Philippe Mathieu-Daudé
2019-03-07 17:26 ` Eduardo Habkost [this message]
2019-03-07 17:26 ` Eduardo Habkost
2019-03-07 17:56 ` Auger Eric
2019-03-07 17:56 ` Auger Eric
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=20190307172612.GC8899@habkost.net \
--to=ehabkost@redhat.com \
--cc=david@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=sbhat@linux.ibm.com \
--cc=shameerali.kolothum.thodi@huawei.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.