From: "Michael S. Tsirkin" <mst@redhat.com>
To: Zhao Liu <zhao1.liu@intel.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Philippe Mathieu-DaudÃ" <philmd@linaro.org>,
qemu-devel@nongnu.org
Subject: Re: [PATCH RESEND] i386: Only configure HPET firmware info when HPET is enabled
Date: Thu, 20 Feb 2025 10:16:56 -0500 [thread overview]
Message-ID: <20250220101525-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20250121140121.84550-1-zhao1.liu@intel.com>
On Tue, Jan 21, 2025 at 10:01:21PM +0800, Zhao Liu wrote:
> At present, the hpet_cfg is written unconditionally since 40ac17cd56eb
> ("pass info about hpets to seabios.]"), because it concerns ACPI HPET is
> created unconditionally.
>
> But that fact has changed since 51124bbfd2ea ("i386: acpi: Don't build
> HPET ACPI entry if HPET is disabled") and ACPI checks if HPET device
> exists in (hw/i386/acpi-build.c).
>
> Therefore, configure HPET firmware information if and only if HPET is
> enabled.
>
and what is the gain from this change? just a cleanup?
> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> ---
> Resend:
> * Resend the patch since it was missed on https://lore.kernel.org/qemu-devel/.
> ---
> hw/i386/fw_cfg.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/hw/i386/fw_cfg.c b/hw/i386/fw_cfg.c
> index 91bf1df0f2e4..d2cb08715a21 100644
> --- a/hw/i386/fw_cfg.c
> +++ b/hw/i386/fw_cfg.c
> @@ -149,7 +149,14 @@ FWCfgState *fw_cfg_arch_create(MachineState *ms,
> #endif
> fw_cfg_add_i32(fw_cfg, FW_CFG_IRQ0_OVERRIDE, 1);
>
> - fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, &hpet_cfg, sizeof(hpet_cfg));
> +#ifdef CONFIG_HPET
> + PCMachineState *pcms =
> + (PCMachineState *)object_dynamic_cast(OBJECT(ms), TYPE_PC_MACHINE);
> + if (pcms && pcms->hpet_enabled) {
> + fw_cfg_add_bytes(fw_cfg, FW_CFG_HPET, &hpet_cfg, sizeof(hpet_cfg));
> + }
> +#endif
> +
Hmm. Wouldn't this break cross version migration? I suspect we need
a compat tweak if we do this. Might not be worth it ...
> /* allocate memory for the NUMA channel: one (64bit) word for the number
> * of nodes, one word for each VCPU->node and one word for each node to
> * hold the amount of memory.
> --
> 2.34.1
next prev parent reply other threads:[~2025-02-20 15:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-21 14:01 [PATCH RESEND] i386: Only configure HPET firmware info when HPET is enabled Zhao Liu
2025-02-20 15:16 ` Michael S. Tsirkin [this message]
2025-02-24 15:33 ` Zhao Liu
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=20250220101525-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=eduardo@habkost.net \
--cc=imammedo@redhat.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=zhao1.liu@intel.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).