[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] add maximum combined fw size as machine configuration option
|
From: |
Laszlo Ersek |
|
Subject: |
Re: [PATCH] add maximum combined fw size as machine configuration option |
|
Date: |
Wed, 23 Sep 2020 10:24:32 +0200 |
On 09/23/20 05:24, Erich Mcmillan wrote:
> From: Erich McMillan <erich.mcmillan@hp.com>
>
> Signed-off-by: Erich McMillan <erich.mcmillan@hp.com>
> ---
> hw/i386/pc.c | 50 ++++++++++++++++++++++++++++++++++++++++++++
> hw/i386/pc_sysfw.c | 13 ++----------
> include/hw/i386/pc.h | 2 ++
> 3 files changed, 54 insertions(+), 11 deletions(-)
- The inter-version changelog has completely disappeared. While it is
not supposed to end up in the git history (which is why we keep it out
of the commit message), it does help reviewers perform incremental
reviews, on v2, v3, etc iterations of a patch or series.
- The commit message is still empty. There's no justification given why
this patch is necessary or useful. Your original message stated "We have
a need for increased firmware size". Please include at least that in the
commit message. Possibly formulated as "At HP, we have a need for
increased firmware size". *Something* should be stated about the use case.
- The subject prefix does not contain "v3" (by my count, this is version
3 of the patch). Please pass "-v3" to git-format-patch in such cases;
that option will set the subject prefix automatically to "PATCH v3".
Please post a v4 with at least the commit message updated and the
subject prefix corrected (it should be "PATCH v4"). I'll try to compare
your v4 submission against my v2 feedback.
... actually, here's one more request: please use the following subject
line:
hw/i386/pc: add maximum combined fw size as machine configuration option
QEMU has many subsystems, and it's best to identify the subsystem in the
subject. Apologies for not noticing this before.
Thanks,
Laszlo
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index d11daacc23..89775e7d5b 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -1869,6 +1869,49 @@ static void pc_machine_set_max_ram_below_4g(Object
> *obj, Visitor *v,
> pcms->max_ram_below_4g = value;
> }
>
> +static void pc_machine_get_max_fw_size(Object *obj, Visitor *v,
> + const char *name, void *opaque,
> + Error **errp)
> +{
> + PCMachineState *pcms = PC_MACHINE(obj);
> + uint64_t value = pcms->max_fw_size;
> +
> + visit_type_size(v, name, &value, errp);
> +}
> +
> +static void pc_machine_set_max_fw_size(Object *obj, Visitor *v,
> + const char *name, void *opaque,
> + Error **errp)
> +{
> + PCMachineState *pcms = PC_MACHINE(obj);
> + Error *error = NULL;
> + uint64_t value;
> +
> + visit_type_size(v, name, &value, &error);
> + if (error) {
> + error_propagate(errp, error);
> + return;
> + }
> +
> + /*
> + * We don't have a theoretically justifiable exact lower bound on the base
> + * address of any flash mapping. In practice, the IO-APIC MMIO range is
> + * [0xFEE00000..0xFEE01000] -- see IO_APIC_DEFAULT_ADDRESS --, leaving
> free
> + * only 18MB-4KB below 4G. For now, restrict the cumulative mapping to
> 8MB in
> + * size.
> + */
> + if (value > 16 * MiB) {
> + error_setg(errp,
> + "User specified max allowed firmware size %" PRIu64 " is "
> + "greater than 16MiB. If combined firwmare size exceeds "
> + "16MiB the system may not boot, or experience
> intermittent"
> + "stability issues.",
> + value);
> + }
> +
> + pcms->max_fw_size = value;
> +}
> +
> static void pc_machine_initfn(Object *obj)
> {
> PCMachineState *pcms = PC_MACHINE(obj);
> @@ -1884,6 +1927,7 @@ static void pc_machine_initfn(Object *obj)
> pcms->smbus_enabled = true;
> pcms->sata_enabled = true;
> pcms->pit_enabled = true;
> + pcms->max_fw_size = 8 * MiB; /* use default */
>
> pc_system_flash_create(pcms);
> pcms->pcspk = isa_new(TYPE_PC_SPEAKER);
> @@ -2004,6 +2048,12 @@ static void pc_machine_class_init(ObjectClass *oc,
> void *data)
>
> object_class_property_add_bool(oc, PC_MACHINE_PIT,
> pc_machine_get_pit, pc_machine_set_pit);
> +
> + object_class_property_add(oc, PC_MACHINE_MAX_FW_SIZE, "size",
> + pc_machine_get_max_fw_size, pc_machine_set_max_fw_size,
> + NULL, NULL);
> + object_class_property_set_description(oc, PC_MACHINE_MAX_FW_SIZE,
> + "Maximum combined firmware size");
> }
>
> static const TypeInfo pc_machine_info = {
> diff --git a/hw/i386/pc_sysfw.c b/hw/i386/pc_sysfw.c
> index b6c0822fe3..22450ba0ef 100644
> --- a/hw/i386/pc_sysfw.c
> +++ b/hw/i386/pc_sysfw.c
> @@ -39,15 +39,6 @@
> #include "hw/block/flash.h"
> #include "sysemu/kvm.h"
>
> -/*
> - * We don't have a theoretically justifiable exact lower bound on the base
> - * address of any flash mapping. In practice, the IO-APIC MMIO range is
> - * [0xFEE00000..0xFEE01000] -- see IO_APIC_DEFAULT_ADDRESS --, leaving free
> - * only 18MB-4KB below 4G. For now, restrict the cumulative mapping to 8MB in
> - * size.
> - */
> -#define FLASH_SIZE_LIMIT (8 * MiB)
> -
> #define FLASH_SECTOR_SIZE 4096
>
> static void pc_isa_bios_init(MemoryRegion *rom_memory,
> @@ -182,10 +173,10 @@ static void pc_system_flash_map(PCMachineState *pcms,
> }
> if ((hwaddr)size != size
> || total_size > HWADDR_MAX - size
> - || total_size + size > FLASH_SIZE_LIMIT) {
> + || total_size + size > pcms->max_fw_size) {
> error_report("combined size of system firmware exceeds "
> "%" PRIu64 " bytes",
> - FLASH_SIZE_LIMIT);
> + pcms->max_fw_size);
> exit(1);
> }
>
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index fe52e165b2..f7c8e7cbfe 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -43,6 +43,7 @@ struct PCMachineState {
> bool smbus_enabled;
> bool sata_enabled;
> bool pit_enabled;
> + uint64_t max_fw_size;
>
> /* NUMA information: */
> uint64_t numa_nodes;
> @@ -59,6 +60,7 @@ struct PCMachineState {
> #define PC_MACHINE_SMBUS "smbus"
> #define PC_MACHINE_SATA "sata"
> #define PC_MACHINE_PIT "pit"
> +#define PC_MACHINE_MAX_FW_SIZE "max-fw-size"
>
> /**
> * PCMachineClass:
>