From: Igor Mammedov <imammedo@redhat.com>
To: Hal Martin <hal.martin@gmail.com>
Cc: mst@redhat.com, qemu-devel@nongnu.org, anisinha@redhat.com
Subject: Re: [PATCH v3] hw/smbios: support for type 7 (cache information)
Date: Thu, 26 Sep 2024 16:05:01 +0200 [thread overview]
Message-ID: <20240926160501.593c2b96@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <20240925190445.20700-1-hal.martin@gmail.com>
On Wed, 25 Sep 2024 19:04:45 +0000
Hal Martin <hal.martin@gmail.com> wrote:
> This patch adds support for SMBIOS type 7 (Cache Information) to qemu.
add here a use-case for this (i.e. why it would be useful for users)
given size semantics it would not be easy for enduser to set correct values here.
> level: cache level (1-8)
> size: cache size in bytes
>
> Example usage:
> -smbios type=7,level=1,size=0x8000
>
> Signed-off-by: Hal Martin <hal.martin@gmail.com>
> ---
> hw/smbios/smbios.c | 65 ++++++++++++++++++++++++++++++++++++
> include/hw/firmware/smbios.h | 18 ++++++++++
> qemu-options.hx | 2 ++
> 3 files changed, 85 insertions(+)
>
> diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
> index a394514264..c8c62d8064 100644
> --- a/hw/smbios/smbios.c
> +++ b/hw/smbios/smbios.c
> @@ -83,6 +83,12 @@ static struct {
> .processor_family = 0x01, /* Other */
> };
>
> +struct type7_instance {
> + uint16_t level, size;
> + QTAILQ_ENTRY(type7_instance) next;
> +};
> +static QTAILQ_HEAD(, type7_instance) type7 = QTAILQ_HEAD_INITIALIZER(type7);
> +
> struct type8_instance {
> const char *internal_reference, *external_reference;
> uint8_t connector_type, port_type;
> @@ -330,6 +336,23 @@ static const QemuOptDesc qemu_smbios_type4_opts[] = {
> { /* end of list */ }
> };
>
> +static const QemuOptDesc qemu_smbios_type7_opts[] = {
> + {
> + .name = "type",
> + .type = QEMU_OPT_NUMBER,
> + .help = "SMBIOS element type",
> + },{
> + .name = "level",
> + .type = QEMU_OPT_NUMBER,
> + .help = "cache level",
> + },{
> + .name = "size",
> + .type = QEMU_OPT_NUMBER,
shouldn't it be QEMU_OPT_SIZE?
then on CLI you can say
-smbios type=7,level=1,size=2M
instead of obscure hex or bytes in decimal
(which also not very readable for typical values expected here)
> + .help = "cache size",
> + },
> + { /* end of list */ }
> +};
> +
> static const QemuOptDesc qemu_smbios_type8_opts[] = {
> {
> .name = "type",
> @@ -733,6 +756,34 @@ static void smbios_build_type_4_table(MachineState *ms, unsigned instance,
> smbios_type4_count++;
> }
>
> +static void smbios_build_type_7_table(void)
> +{
> + unsigned instance = 0;
> + struct type7_instance *t7;
> + char designation[20];
> +
> + QTAILQ_FOREACH(t7, &type7, next) {
> + SMBIOS_BUILD_TABLE_PRE(7, T0_BASE + instance, true);
> + sprintf(designation, "CPU Internal L%d", t7->level);
> + SMBIOS_TABLE_SET_STR(7, socket_designation, designation);
> + /* cache not socketed, enabled, write back */
> + t->cache_configuration = cpu_to_le16(0x180 | ((t7->level) - 1));
> + t->installed_size = cpu_to_le16(t7->size);
> + /* set max size to installed size */
> + t->maximum_cache_size = cpu_to_le16(t7->size);
commit message says 'size' is specified in bytes,
however as I read spec granularity bit lets specify size only
in 1K or 64k units. Don't you need to massage user provided 'bytes'
matching granularity?
> + t->supported_sram_type = cpu_to_le16(0x10); /* pipeline burst */
> + t->current_sram_type = cpu_to_le16(0x10); /* pipeline burst */
> + t->cache_speed = 0x1; /* 1 ns */
> + t->error_correction_type = 0x6; /* Multi-bit ECC */
> + t->system_cache_type = 0x05; /* Unified */
> + t->associativity = 0x6; /* Fully Associative */
> + t->maximum_cache_size2 = cpu_to_le32(t7->size);
> + t->installed_cache_size2 = cpu_to_le32(t7->size);
theses 2 are for 3.1 tables only, so it should be conditional
see smbios_build_type_4_table() for such an example.
> + SMBIOS_BUILD_TABLE_POST;
> + instance++;
> + }
> +}
> +
> static void smbios_build_type_8_table(void)
> {
> unsigned instance = 0;
> @@ -1120,6 +1171,7 @@ static bool smbios_get_tables_ep(MachineState *ms,
> }
> }
>
> + smbios_build_type_7_table();
> smbios_build_type_8_table();
> smbios_build_type_9_table(errp);
> smbios_build_type_11_table();
> @@ -1478,6 +1530,19 @@ void smbios_entry_add(QemuOpts *opts, Error **errp)
> UINT16_MAX);
> }
> return;
> + case 7:
> + if (!qemu_opts_validate(opts, qemu_smbios_type7_opts, errp)) {
> + return;
> + }
> + struct type7_instance *t7_i;
> + t7_i = g_new0(struct type7_instance, 1);
> + t7_i->level = qemu_opt_get_number(opts, "level", 0x0);
> + t7_i->size = qemu_opt_get_number(opts, "size", 0x0200);
also looking at your assumptions, you need a sanity check for size that
it would fit into 14:0 bit range.
or properly implement granularity handling, but size check would be needed anyways
> + /* Only cache levels 1-8 are permitted */
> + if (t7_i->level > 0 && t7_i->level < 9) {
> + QTAILQ_INSERT_TAIL(&type7, t7_i, next);
> + }
instead of silently ignoring not supported cache levels, one should error out.
> + return;
> case 8:
> if (!qemu_opts_validate(opts, qemu_smbios_type8_opts, errp)) {
> return;
> diff --git a/include/hw/firmware/smbios.h b/include/hw/firmware/smbios.h
> index f066ab7262..1ea1506b46 100644
> --- a/include/hw/firmware/smbios.h
> +++ b/include/hw/firmware/smbios.h
> @@ -220,6 +220,24 @@ typedef enum smbios_type_4_len_ver {
> SMBIOS_TYPE_4_LEN_V30 = offsetofend(struct smbios_type_4, thread_count2),
> } smbios_type_4_len_ver;
>
> +/* SMBIOS type 7 - Cache Information (v2.0+) */
> +struct smbios_type_7 {
> + struct smbios_structure_header header;
> + uint8_t socket_designation;
> + uint16_t cache_configuration;
> + uint16_t maximum_cache_size;
> + uint16_t installed_size;
> + uint16_t supported_sram_type;
> + uint16_t current_sram_type;
> + uint8_t cache_speed;
> + uint8_t error_correction_type;
> + uint8_t system_cache_type;
> + uint8_t associativity;
> + uint32_t maximum_cache_size2;
> + uint32_t installed_cache_size2;
> + /* contained elements follow */
> +} QEMU_PACKED;
> +
> /* SMBIOS type 8 - Port Connector Information */
> struct smbios_type_8 {
> struct smbios_structure_header header;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index d94e2cbbae..21c05821d5 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -2706,6 +2706,8 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
> " [,asset=str][,part=str][,max-speed=%d][,current-speed=%d]\n"
> " [,processor-family=%d][,processor-id=%d]\n"
> " specify SMBIOS type 4 fields\n"
> + "-smbios type=7[,level=%d][,size=%d]\n"
> + " specify SMBIOS type 7 fields\n"
> "-smbios type=8[,external_reference=str][,internal_reference=str][,connector_type=%d][,port_type=%d]\n"
> " specify SMBIOS type 8 fields\n"
> "-smbios type=11[,value=str][,path=filename]\n"
next prev parent reply other threads:[~2024-09-26 14:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-11 10:45 [PATCH] hw/smbios: support for type 7 (cache information) Hal Martin
2024-09-11 11:19 ` Michael S. Tsirkin
2024-09-21 7:29 ` [PATCH v2] " Hal Martin
2024-09-24 14:29 ` Igor Mammedov
2024-09-25 19:04 ` [PATCH v3] " Hal Martin
2024-09-26 14:05 ` Igor Mammedov [this message]
2024-12-22 10:40 ` [PATCH v4] " Hal Martin
2024-12-30 15:21 ` Igor Mammedov
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=20240926160501.593c2b96@imammedo.users.ipa.redhat.com \
--to=imammedo@redhat.com \
--cc=anisinha@redhat.com \
--cc=hal.martin@gmail.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).