Re: [PATCH v2 16/35] tcg/loongarch64: Support TCG_COND_TST{EQ,NE}
On 28/10/23 21:45, Richard Henderson wrote: Signed-off-by: Richard Henderson --- tcg/loongarch64/tcg-target.c.inc | 56 ++-- 1 file changed, 38 insertions(+), 18 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v2 17/35] tcg/mips: Support TCG_COND_TST{EQ,NE}
Hi Richard, On 28/10/23 21:45, Richard Henderson wrote: Signed-off-by: Richard Henderson --- tcg/mips/tcg-target.c.inc | 41 +++ 1 file changed, 41 insertions(+) @@ -1053,6 +1071,14 @@ static void tcg_out_setcond2(TCGContext *s, TCGCond cond, TCGReg ret, tcg_out_setcond(s, cond, ret, tmp1, TCG_REG_ZERO); break; +case TCG_COND_TSTEQ: +case TCG_COND_TSTNE: +tcg_out_opc_reg(s, OPC_AND, TCG_TMP0, al, bl); +tcg_out_opc_reg(s, OPC_AND, TCG_TMP1, ah, bh); +tcg_out_opc_reg(s, OPC_OR, ret, TCG_TMP0, TCG_TMP1); +tcg_out_setcond(s, tcg_eqne_cond(cond), ret, tmp1, TCG_REG_ZERO); Where is tcg_eqne_cond() declared? +break;
Re: [RFC PATCH] tests/tcg: finesse the registers check for "hidden" regs
On Fri Nov 17, 2023 at 3:39 AM AEST, Alex Bennée wrote:
> The reason the ppc64 and s390x test where failing was because gdb
> hides them although they are still accessible via regnum. We can
> re-arrange the test a little bit and include these two arches in our
> test.
>
> We still don't explicitly fail for registers that just disappear like
> in the ARM case:
>
> xml-tdesc has 228 registers
> remote-registers has 219 registers
> of which 0 are hidden
> {'name': 'CNTP_CVAL', 'regnum': 96} wasn't seen in remote-registers
> {'name': 'CNTV_CVAL', 'regnum': 101} wasn't seen in remote-registers
> {'name': 'PAR', 'regnum': 113} wasn't seen in remote-registers
> {'name': 'CPUACTLR', 'regnum': 114} wasn't seen in remote-registers
> {'name': 'CPUECTLR', 'regnum': 127} wasn't seen in remote-registers
> {'name': 'CPUMERRSR', 'regnum': 140} wasn't seen in remote-registers
> {'name': 'TTBR1', 'regnum': 148} wasn't seen in remote-registers
> {'name': 'L2MERRSR', 'regnum': 161} wasn't seen in remote-registers
> {'name': 'TTBR0', 'regnum': 168} wasn't seen in remote-registers
Nice! Thanks for getting ppc64 working, comment below.
>
> Signed-off-by: Alex Bennée
> Cc: Ilya Leoshkevich
> Cc: qemu-s3...@nongnu.org
> Cc: Nicholas Piggin
> Cc: Daniel Henrique Barboza
> Cc: qemu-...@nongnu.org
> Cc: Luis Machado
> ---
> tests/tcg/multiarch/gdbstub/registers.py | 80 ++--
> tests/tcg/ppc64/Makefile.target | 7 ---
> tests/tcg/s390x/Makefile.target | 4 --
> 3 files changed, 61 insertions(+), 30 deletions(-)
>
> diff --git a/tests/tcg/multiarch/gdbstub/registers.py
> b/tests/tcg/multiarch/gdbstub/registers.py
> index ff6076b09e..342d6fd78f 100644
> --- a/tests/tcg/multiarch/gdbstub/registers.py
> +++ b/tests/tcg/multiarch/gdbstub/registers.py
> @@ -44,7 +44,6 @@ def fetch_xml_regmap():
>
> total_regs = 0
> reg_map = {}
> -frame = gdb.selected_frame()
>
> tree = ET.fromstring(xml)
> for f in tree.findall("feature"):
> @@ -61,12 +60,8 @@ def fetch_xml_regmap():
> for r in regs:
> name = r.attrib["name"]
> regnum = int(r.attrib["regnum"])
> -try:
> -value = frame.read_register(name)
> -except ValueError:
> -report(False, f"failed to read reg: {name}")
>
> -entry = { "name": name, "initial": value, "regnum": regnum }
> +entry = { "name": name, "regnum": regnum }
>
> if name in reg_map:
> report(False, f"duplicate register {entry} vs
> {reg_map[name]}")
> @@ -80,6 +75,15 @@ def fetch_xml_regmap():
>
> return reg_map
>
> +def get_register_by_regnum(reg_map, regnum):
> +"""
> +Helper to find a register from the map via its XML regnum
> +"""
> +for regname, entry in reg_map.items():
> +if entry['regnum'] == regnum:
> +return entry
> +return None
> +
> def crosscheck_remote_xml(reg_map):
> """
> Cross-check the list of remote-registers with the XML info.
> @@ -90,6 +94,7 @@ def crosscheck_remote_xml(reg_map):
>
> total_regs = len(reg_map.keys())
> total_r_regs = 0
> +total_r_elided_regs = 0
>
> for r in r_regs:
> fields = r.split()
> @@ -100,6 +105,15 @@ def crosscheck_remote_xml(reg_map):
> r_name = fields[0]
> r_regnum = int(fields[6])
>
> +# Some registers are "hidden" so don't have a name
> +# although they still should have a register number
> +if r_name == "''":
> +total_r_elided_regs += 1
Should this also increment total_r_regs so that it doesn't trip the
warning?
Thanks,
Nick
> +x_reg = get_register_by_regnum(reg_map, r_regnum)
> +if x_reg is not None:
> +x_reg["hidden"] = True
> +continue
> +
> # check in the XML
> try:
> x_reg = reg_map[r_name]
> @@ -118,14 +132,40 @@ def crosscheck_remote_xml(reg_map):
> # registers on a 32 bit machine. Also print what is missing to
> # help with debug.
> if total_regs != total_r_regs:
> -print(f"xml-tdesc has ({total_regs}) registers")
> -print(f"remote-registers has ({total_r_regs}) registers")
> +print(f"xml-tdesc has {total_regs} registers")
> +print(f"remote-registers has {total_r_regs} registers")
> +print(f"of which {total_r_elided_regs} are hidden")
>
> for x_key in reg_map.keys():
> x_reg = reg_map[x_key]
> -if "seen" not in x_reg:
> +if "hidden" in x_reg:
> +print(f"{x_reg} elided by gdb")
> +elif "seen" not in x_reg:
> print(f"{x_reg} wasn't seen in remote-registers")
>
> +def initial_register_read(reg_map):
> +"""
> +Do an initial read of all registers that we know gdb cares about
> +(so ignore
[PATCH v6 13/16] i386: Add cache topology info in CPUCacheInfo
From: Zhao Liu
Currently, by default, the cache topology is encoded as:
1. i/d cache is shared in one core.
2. L2 cache is shared in one core.
3. L3 cache is shared in one die.
This default general setting has caused a misunderstanding, that is, the
cache topology is completely equated with a specific cpu topology, such
as the connection between L2 cache and core level, and the connection
between L3 cache and die level.
In fact, the settings of these topologies depend on the specific
platform and are not static. For example, on Alder Lake-P, every
four Atom cores share the same L2 cache.
Thus, we should explicitly define the corresponding cache topology for
different cache models to increase scalability.
Except legacy_l2_cache_cpuid2 (its default topo level is
CPU_TOPO_LEVEL_UNKNOW), explicitly set the corresponding topology level
for all other cache models. In order to be compatible with the existing
cache topology, set the CPU_TOPO_LEVEL_CORE level for the i/d cache, set
the CPU_TOPO_LEVEL_CORE level for L2 cache, and set the
CPU_TOPO_LEVEL_DIE level for L3 cache.
The field for CPUID[4].EAX[bits 25:14] or CPUID[0x801D].EAX[bits
25:14] will be set based on CPUCacheInfo.share_level.
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* Fix cache topology uninitialization bugs for some AMD CPUs. (Babu)
* Move the CPUTopoLevel enumeration definition to the previous 0x1f
rework patch.
Changes since v1:
* Add the prefix "CPU_TOPO_LEVEL_*" for CPU topology level names.
(Yanan)
* (Revert, pls refer "i386: Decouple CPUID[0x1F] subleaf with specific
topology level") Rename the "INVALID" level to CPU_TOPO_LEVEL_UNKNOW.
(Yanan)
---
target/i386/cpu.c | 36
target/i386/cpu.h | 7 +++
2 files changed, 43 insertions(+)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 84f305130a6f..5dcc41329805 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -558,6 +558,7 @@ static CPUCacheInfo legacy_l1d_cache = {
.sets = 64,
.partitions = 1,
.no_invd_sharing = true,
+.share_level = CPU_TOPO_LEVEL_CORE,
};
/*FIXME: CPUID leaf 0x8005 is inconsistent with leaves 2 & 4 */
@@ -572,6 +573,7 @@ static CPUCacheInfo legacy_l1d_cache_amd = {
.partitions = 1,
.lines_per_tag = 1,
.no_invd_sharing = true,
+.share_level = CPU_TOPO_LEVEL_CORE,
};
/* L1 instruction cache: */
@@ -585,6 +587,7 @@ static CPUCacheInfo legacy_l1i_cache = {
.sets = 64,
.partitions = 1,
.no_invd_sharing = true,
+.share_level = CPU_TOPO_LEVEL_CORE,
};
/*FIXME: CPUID leaf 0x8005 is inconsistent with leaves 2 & 4 */
@@ -599,6 +602,7 @@ static CPUCacheInfo legacy_l1i_cache_amd = {
.partitions = 1,
.lines_per_tag = 1,
.no_invd_sharing = true,
+.share_level = CPU_TOPO_LEVEL_CORE,
};
/* Level 2 unified cache: */
@@ -612,6 +616,7 @@ static CPUCacheInfo legacy_l2_cache = {
.sets = 4096,
.partitions = 1,
.no_invd_sharing = true,
+.share_level = CPU_TOPO_LEVEL_CORE,
};
/*FIXME: CPUID leaf 2 descriptor is inconsistent with CPUID leaf 4 */
@@ -621,6 +626,7 @@ static CPUCacheInfo legacy_l2_cache_cpuid2 = {
.size = 2 * MiB,
.line_size = 64,
.associativity = 8,
+.share_level = CPU_TOPO_LEVEL_INVALID,
};
@@ -634,6 +640,7 @@ static CPUCacheInfo legacy_l2_cache_amd = {
.associativity = 16,
.sets = 512,
.partitions = 1,
+.share_level = CPU_TOPO_LEVEL_CORE,
};
/* Level 3 unified cache: */
@@ -649,6 +656,7 @@ static CPUCacheInfo legacy_l3_cache = {
.self_init = true,
.inclusive = true,
.complex_indexing = true,
+.share_level = CPU_TOPO_LEVEL_DIE,
};
/* TLB definitions: */
@@ -1947,6 +1955,7 @@ static const CPUCaches epyc_cache_info = {
.lines_per_tag = 1,
.self_init = 1,
.no_invd_sharing = true,
+.share_level = CPU_TOPO_LEVEL_CORE,
},
.l1i_cache = &(CPUCacheInfo) {
.type = INSTRUCTION_CACHE,
@@ -1959,6 +1968,7 @@ static const CPUCaches epyc_cache_info = {
.lines_per_tag = 1,
.self_init = 1,
.no_invd_sharing = true,
+.share_level = CPU_TOPO_LEVEL_CORE,
},
.l2_cache = &(CPUCacheInfo) {
.type = UNIFIED_CACHE,
@@ -1969,6 +1979,7 @@ static const CPUCaches epyc_cache_info = {
.partitions = 1,
.sets = 1024,
.lines_per_tag = 1,
+.share_level = CPU_TOPO_LEVEL_CORE,
},
.l3_cache = &(CPUCacheInfo) {
.type = UNIFIED_CACHE,
@@ -1982,6 +1993,7 @@ static const CPUCaches epyc_cache_info = {
.self_init = true,
.inclusive = true,
.complex_indexing = true,
+.share_level = CPU_TOPO_LEVEL_DIE,
},
};
@@ -1997,6 +2009,7 @@ static CPUCaches epyc_v4_cache_info = {
.lines_per_tag = 1,
.self_init = 1,
.no_invd_sharing = true,
+
[PATCH v6 12/16] hw/i386/pc: Support smp.clusters for x86 PC machine
From: Zhuocheng Ding As module-level topology support is added to X86CPU, now we can enable the support for the cluster parameter on PC machines. With this support, we can define a 5-level x86 CPU topology with "-smp": -smp cpus=*,maxcpus=*,sockets=*,dies=*,clusters=*,cores=*,threads=*. Additionally, add the 5-level topology example in description of "-smp". Signed-off-by: Zhuocheng Ding Signed-off-by: Zhao Liu Reviewed-by: Yanan Wang Tested-by: Babu Moger Tested-by: Yongwei Ma Acked-by: Michael S. Tsirkin --- hw/i386/pc.c| 1 + qemu-options.hx | 10 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/hw/i386/pc.c b/hw/i386/pc.c index 29b9964733ed..7046288fb547 100644 --- a/hw/i386/pc.c +++ b/hw/i386/pc.c @@ -1846,6 +1846,7 @@ static void pc_machine_class_init(ObjectClass *oc, void *data) mc->default_cpu_type = TARGET_DEFAULT_CPU_TYPE; mc->nvdimm_supported = true; mc->smp_props.dies_supported = true; +mc->smp_props.clusters_supported = true; mc->default_ram_id = "pc.ram"; pcmc->default_smbios_ep_type = SMBIOS_ENTRY_POINT_TYPE_64; diff --git a/qemu-options.hx b/qemu-options.hx index 42fd09e4de96..73a68118cc5a 100644 --- a/qemu-options.hx +++ b/qemu-options.hx @@ -337,14 +337,14 @@ SRST -smp 8,sockets=2,cores=2,threads=2,maxcpus=8 The following sub-option defines a CPU topology hierarchy (2 sockets -totally on the machine, 2 dies per socket, 2 cores per die, 2 threads -per core) for PC machines which support sockets/dies/cores/threads. -Some members of the option can be omitted but their values will be -automatically computed: +totally on the machine, 2 dies per socket, 2 clusters per die, 2 cores per +cluster, 2 threads per core) for PC machines which support sockets/dies +/clusters/cores/threads. Some members of the option can be omitted but +their values will be automatically computed: :: --smp 16,sockets=2,dies=2,cores=2,threads=2,maxcpus=16 +-smp 32,sockets=2,dies=2,clusters=2,cores=2,threads=2,maxcpus=32 The following sub-option defines a CPU topology hierarchy (2 sockets totally on the machine, 2 clusters per socket, 2 cores per cluster, -- 2.34.1
[PATCH v6 07/16] i386: Support modules_per_die in X86CPUTopoInfo
From: Zhuocheng Ding
Support module level in i386 cpu topology structure "X86CPUTopoInfo".
Since x86 does not yet support the "clusters" parameter in "-smp",
X86CPUTopoInfo.modules_per_die is currently always 1. Therefore, the
module level width in APIC ID, which can be calculated by
"apicid_bitwidth_for_count(topo_info->modules_per_die)", is always 0
for now, so we can directly add APIC ID related helpers to support
module level parsing.
In addition, update topology structure in test-x86-topo.c.
Signed-off-by: Zhuocheng Ding
Co-developed-by: Zhao Liu
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* Drop the description about not exposing module level in commit
message.
* Update topology related calculation in newly added helpers:
num_cpus_by_topo_level() and apicid_offset_by_topo_level().
* Since the code change, drop the "Acked-by" tag.
Changes since v1:
* Include module level related helpers (apicid_module_width() and
apicid_module_offset()) in this patch. (Yanan)
---
hw/i386/x86.c | 3 ++-
include/hw/i386/topology.h | 22 +++
target/i386/cpu.c | 17 +-
tests/unit/test-x86-topo.c | 45 --
4 files changed, 55 insertions(+), 32 deletions(-)
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 24628c1d2f73..8503d30a133a 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -72,7 +72,8 @@ static void init_topo_info(X86CPUTopoInfo *topo_info,
MachineState *ms = MACHINE(x86ms);
topo_info->dies_per_pkg = ms->smp.dies;
-topo_info->cores_per_die = ms->smp.cores;
+topo_info->modules_per_die = ms->smp.clusters;
+topo_info->cores_per_module = ms->smp.cores;
topo_info->threads_per_core = ms->smp.threads;
}
diff --git a/include/hw/i386/topology.h b/include/hw/i386/topology.h
index d4eeb7ab8290..517e51768c13 100644
--- a/include/hw/i386/topology.h
+++ b/include/hw/i386/topology.h
@@ -56,7 +56,8 @@ typedef struct X86CPUTopoIDs {
typedef struct X86CPUTopoInfo {
unsigned dies_per_pkg;
-unsigned cores_per_die;
+unsigned modules_per_die;
+unsigned cores_per_module;
unsigned threads_per_core;
} X86CPUTopoInfo;
@@ -77,7 +78,13 @@ static inline unsigned apicid_smt_width(X86CPUTopoInfo
*topo_info)
/* Bit width of the Core_ID field */
static inline unsigned apicid_core_width(X86CPUTopoInfo *topo_info)
{
-return apicid_bitwidth_for_count(topo_info->cores_per_die);
+return apicid_bitwidth_for_count(topo_info->cores_per_module);
+}
+
+/* Bit width of the Module_ID (cluster ID) field */
+static inline unsigned apicid_module_width(X86CPUTopoInfo *topo_info)
+{
+return apicid_bitwidth_for_count(topo_info->modules_per_die);
}
/* Bit width of the Die_ID field */
@@ -92,10 +99,16 @@ static inline unsigned apicid_core_offset(X86CPUTopoInfo
*topo_info)
return apicid_smt_width(topo_info);
}
+/* Bit offset of the Module_ID (cluster ID) field */
+static inline unsigned apicid_module_offset(X86CPUTopoInfo *topo_info)
+{
+return apicid_core_offset(topo_info) + apicid_core_width(topo_info);
+}
+
/* Bit offset of the Die_ID field */
static inline unsigned apicid_die_offset(X86CPUTopoInfo *topo_info)
{
-return apicid_core_offset(topo_info) + apicid_core_width(topo_info);
+return apicid_module_offset(topo_info) + apicid_module_width(topo_info);
}
/* Bit offset of the Pkg_ID (socket ID) field */
@@ -127,7 +140,8 @@ static inline void x86_topo_ids_from_idx(X86CPUTopoInfo
*topo_info,
X86CPUTopoIDs *topo_ids)
{
unsigned nr_dies = topo_info->dies_per_pkg;
-unsigned nr_cores = topo_info->cores_per_die;
+unsigned nr_cores = topo_info->cores_per_module *
+topo_info->modules_per_die;
unsigned nr_threads = topo_info->threads_per_core;
topo_ids->pkg_id = cpu_index / (nr_dies * nr_cores * nr_threads);
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index f600c0ee9df1..b4055e4dd62e 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -278,10 +278,11 @@ static uint32_t num_cpus_by_topo_level(X86CPUTopoInfo
*topo_info,
case CPU_TOPO_LEVEL_CORE:
return topo_info->threads_per_core;
case CPU_TOPO_LEVEL_DIE:
-return topo_info->threads_per_core * topo_info->cores_per_die;
+return topo_info->threads_per_core * topo_info->cores_per_module *
+ topo_info->modules_per_die;
case CPU_TOPO_LEVEL_PACKAGE:
-return topo_info->threads_per_core * topo_info->cores_per_die *
- topo_info->dies_per_pkg;
+return topo_info->threads_per_core * topo_info->cores_per_module *
+ topo_info->modules_per_die * topo_info->dies_per_pkg;
default:
g_assert_not_reached();
}
@@ -450,7 +451,9 @@ static void encode_cache_cpuid801d(CPUCacheInfo *cache,
/* L3 is shared among multiple cores */
[PATCH v6 08/16] i386: Expose module level in CPUID[0x1F]
From: Zhao Liu
Linux kernel (from v6.4, with commit edc0a2b595765 ("x86/topology: Fix
erroneous smp_num_siblings on Intel Hybrid platforms") is able to
handle platforms with Module level enumerated via CPUID.1F.
Expose the module level in CPUID[0x1F] if the machine has more than 1
modules.
(Tested CPU topology in CPUID[0x1F] leaf with various die/cluster
configurations in "-smp".)
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* New patch to expose module level in 0x1F.
* Add Tested-by tag from Yongwei.
---
target/i386/cpu.c | 12 +++-
target/i386/cpu.h | 2 ++
target/i386/kvm/kvm.c | 2 +-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index b4055e4dd62e..0fcdd6f5f349 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -277,6 +277,8 @@ static uint32_t num_cpus_by_topo_level(X86CPUTopoInfo
*topo_info,
return 1;
case CPU_TOPO_LEVEL_CORE:
return topo_info->threads_per_core;
+case CPU_TOPO_LEVEL_MODULE:
+return topo_info->threads_per_core * topo_info->cores_per_module;
case CPU_TOPO_LEVEL_DIE:
return topo_info->threads_per_core * topo_info->cores_per_module *
topo_info->modules_per_die;
@@ -297,6 +299,8 @@ static uint32_t apicid_offset_by_topo_level(X86CPUTopoInfo
*topo_info,
return 0;
case CPU_TOPO_LEVEL_CORE:
return apicid_core_offset(topo_info);
+case CPU_TOPO_LEVEL_MODULE:
+return apicid_module_offset(topo_info);
case CPU_TOPO_LEVEL_DIE:
return apicid_die_offset(topo_info);
case CPU_TOPO_LEVEL_PACKAGE:
@@ -316,6 +320,8 @@ static uint32_t cpuid1f_topo_type(enum CPUTopoLevel
topo_level)
return CPUID_1F_ECX_TOPO_LEVEL_SMT;
case CPU_TOPO_LEVEL_CORE:
return CPUID_1F_ECX_TOPO_LEVEL_CORE;
+case CPU_TOPO_LEVEL_MODULE:
+return CPUID_1F_ECX_TOPO_LEVEL_MODULE;
case CPU_TOPO_LEVEL_DIE:
return CPUID_1F_ECX_TOPO_LEVEL_DIE;
default:
@@ -347,6 +353,10 @@ static void encode_topo_cpuid1f(CPUX86State *env, uint32_t
count,
if (env->nr_dies > 1) {
set_bit(CPU_TOPO_LEVEL_DIE, topo_bitmap);
}
+
+if (env->nr_modules > 1) {
+set_bit(CPU_TOPO_LEVEL_MODULE, topo_bitmap);
+}
}
*ecx = count & 0xff;
@@ -6393,7 +6403,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
break;
case 0x1F:
/* V2 Extended Topology Enumeration Leaf */
-if (topo_info.dies_per_pkg < 2) {
+if (topo_info.modules_per_die < 2 && topo_info.dies_per_pkg < 2) {
*eax = *ebx = *ecx = *edx = 0;
break;
}
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index da58d41c9969..95cbbb1de906 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1018,6 +1018,7 @@ enum CPUTopoLevel {
CPU_TOPO_LEVEL_INVALID,
CPU_TOPO_LEVEL_SMT,
CPU_TOPO_LEVEL_CORE,
+CPU_TOPO_LEVEL_MODULE,
CPU_TOPO_LEVEL_DIE,
CPU_TOPO_LEVEL_PACKAGE,
CPU_TOPO_LEVEL_MAX,
@@ -1032,6 +1033,7 @@ enum CPUTopoLevel {
#define CPUID_1F_ECX_TOPO_LEVEL_INVALID CPUID_B_ECX_TOPO_LEVEL_INVALID
#define CPUID_1F_ECX_TOPO_LEVEL_SMT CPUID_B_ECX_TOPO_LEVEL_SMT
#define CPUID_1F_ECX_TOPO_LEVEL_CORE CPUID_B_ECX_TOPO_LEVEL_CORE
+#define CPUID_1F_ECX_TOPO_LEVEL_MODULE 3
#define CPUID_1F_ECX_TOPO_LEVEL_DIE 5
/* MSR Feature Bits */
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 11b8177eff21..b6d297aff730 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -1913,7 +1913,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
break;
}
case 0x1f:
-if (env->nr_dies < 2) {
+if (env->nr_modules < 2 && env->nr_dies < 2) {
break;
}
/* fallthrough */
--
2.34.1
[PATCH v6 11/16] tests: Add test case of APIC ID for module level parsing
From: Zhuocheng Ding
After i386 supports module level, it's time to add the test for module
level's parsing.
Signed-off-by: Zhuocheng Ding
Co-developed-by: Zhao Liu
Signed-off-by: Zhao Liu
Reviewed-by: Yanan Wang
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
tests/unit/test-x86-topo.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/tests/unit/test-x86-topo.c b/tests/unit/test-x86-topo.c
index f21b8a5d95c2..55b731ccae55 100644
--- a/tests/unit/test-x86-topo.c
+++ b/tests/unit/test-x86-topo.c
@@ -37,6 +37,7 @@ static void test_topo_bits(void)
topo_info = (X86CPUTopoInfo) {1, 1, 1, 1};
g_assert_cmpuint(apicid_smt_width(_info), ==, 0);
g_assert_cmpuint(apicid_core_width(_info), ==, 0);
+g_assert_cmpuint(apicid_module_width(_info), ==, 0);
g_assert_cmpuint(apicid_die_width(_info), ==, 0);
topo_info = (X86CPUTopoInfo) {1, 1, 1, 1};
@@ -74,13 +75,22 @@ static void test_topo_bits(void)
topo_info = (X86CPUTopoInfo) {1, 1, 33, 2};
g_assert_cmpuint(apicid_core_width(_info), ==, 6);
-topo_info = (X86CPUTopoInfo) {1, 1, 30, 2};
+topo_info = (X86CPUTopoInfo) {1, 6, 30, 2};
+g_assert_cmpuint(apicid_module_width(_info), ==, 3);
+topo_info = (X86CPUTopoInfo) {1, 7, 30, 2};
+g_assert_cmpuint(apicid_module_width(_info), ==, 3);
+topo_info = (X86CPUTopoInfo) {1, 8, 30, 2};
+g_assert_cmpuint(apicid_module_width(_info), ==, 3);
+topo_info = (X86CPUTopoInfo) {1, 9, 30, 2};
+g_assert_cmpuint(apicid_module_width(_info), ==, 4);
+
+topo_info = (X86CPUTopoInfo) {1, 6, 30, 2};
g_assert_cmpuint(apicid_die_width(_info), ==, 0);
-topo_info = (X86CPUTopoInfo) {2, 1, 30, 2};
+topo_info = (X86CPUTopoInfo) {2, 6, 30, 2};
g_assert_cmpuint(apicid_die_width(_info), ==, 1);
-topo_info = (X86CPUTopoInfo) {3, 1, 30, 2};
+topo_info = (X86CPUTopoInfo) {3, 6, 30, 2};
g_assert_cmpuint(apicid_die_width(_info), ==, 2);
-topo_info = (X86CPUTopoInfo) {4, 1, 30, 2};
+topo_info = (X86CPUTopoInfo) {4, 6, 30, 2};
g_assert_cmpuint(apicid_die_width(_info), ==, 2);
/* build a weird topology and see if IDs are calculated correctly
@@ -91,6 +101,7 @@ static void test_topo_bits(void)
topo_info = (X86CPUTopoInfo) {1, 1, 6, 3};
g_assert_cmpuint(apicid_smt_width(_info), ==, 2);
g_assert_cmpuint(apicid_core_offset(_info), ==, 2);
+g_assert_cmpuint(apicid_module_offset(_info), ==, 5);
g_assert_cmpuint(apicid_die_offset(_info), ==, 5);
g_assert_cmpuint(apicid_pkg_offset(_info), ==, 5);
--
2.34.1
[PATCH v6 10/16] i386/cpu: Introduce cluster-id to X86CPU
From: Zhuocheng Ding
Introduce cluster-id other than module-id to be consistent with
CpuInstanceProperties.cluster-id, and this avoids the confusion
of parameter names when hotplugging.
Following the legacy smp check rules, also add the cluster_id validity
into x86_cpu_pre_plug().
Signed-off-by: Zhuocheng Ding
Co-developed-by: Zhao Liu
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v5:
* Update the comment when check cluster-id. Since current QEMU is
v8.2, the cluster-id support should at least start from v8.3.
Changes since v3:
* Use the imperative in the commit message. (Babu)
---
hw/i386/x86.c | 33 +
target/i386/cpu.c | 2 ++
target/i386/cpu.h | 1 +
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 3e2fabf3d5bd..20308d11c985 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -325,6 +325,14 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
cpu->die_id = 0;
}
+/*
+ * cluster-id was optional in QEMU 8.3 and older, so keep it optional
+ * if there's only one cluster per die.
+ */
+if (cpu->cluster_id < 0 && ms->smp.clusters == 1) {
+cpu->cluster_id = 0;
+}
+
if (cpu->socket_id < 0) {
error_setg(errp, "CPU socket-id is not set");
return;
@@ -341,6 +349,14 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
cpu->die_id, ms->smp.dies - 1);
return;
}
+if (cpu->cluster_id < 0) {
+error_setg(errp, "CPU cluster-id is not set");
+return;
+} else if (cpu->cluster_id > ms->smp.clusters - 1) {
+error_setg(errp, "Invalid CPU cluster-id: %u must be in range
0:%u",
+ cpu->cluster_id, ms->smp.clusters - 1);
+return;
+}
if (cpu->core_id < 0) {
error_setg(errp, "CPU core-id is not set");
return;
@@ -360,16 +376,9 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
topo_ids.pkg_id = cpu->socket_id;
topo_ids.die_id = cpu->die_id;
+topo_ids.module_id = cpu->cluster_id;
topo_ids.core_id = cpu->core_id;
topo_ids.smt_id = cpu->thread_id;
-
-/*
- * TODO: This is the temporary initialization for topo_ids.module_id to
- * avoid "maybe-uninitialized" compilation errors. Will remove when
- * X86CPU supports cluster_id.
- */
-topo_ids.module_id = 0;
-
cpu->apic_id = x86_apicid_from_topo_ids(_info, _ids);
}
@@ -414,6 +423,14 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
}
cpu->die_id = topo_ids.die_id;
+if (cpu->cluster_id != -1 && cpu->cluster_id != topo_ids.module_id) {
+error_setg(errp, "property cluster-id: %u doesn't match set apic-id:"
+" 0x%x (cluster-id: %u)", cpu->cluster_id, cpu->apic_id,
+topo_ids.module_id);
+return;
+}
+cpu->cluster_id = topo_ids.module_id;
+
if (cpu->core_id != -1 && cpu->core_id != topo_ids.core_id) {
error_setg(errp, "property core-id: %u doesn't match set apic-id:"
" 0x%x (core-id: %u)", cpu->core_id, cpu->apic_id,
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 0fcdd6f5f349..84f305130a6f 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7908,12 +7908,14 @@ static Property x86_cpu_properties[] = {
DEFINE_PROP_UINT32("apic-id", X86CPU, apic_id, 0),
DEFINE_PROP_INT32("thread-id", X86CPU, thread_id, 0),
DEFINE_PROP_INT32("core-id", X86CPU, core_id, 0),
+DEFINE_PROP_INT32("cluster-id", X86CPU, cluster_id, 0),
DEFINE_PROP_INT32("die-id", X86CPU, die_id, 0),
DEFINE_PROP_INT32("socket-id", X86CPU, socket_id, 0),
#else
DEFINE_PROP_UINT32("apic-id", X86CPU, apic_id, UNASSIGNED_APIC_ID),
DEFINE_PROP_INT32("thread-id", X86CPU, thread_id, -1),
DEFINE_PROP_INT32("core-id", X86CPU, core_id, -1),
+DEFINE_PROP_INT32("cluster-id", X86CPU, cluster_id, -1),
DEFINE_PROP_INT32("die-id", X86CPU, die_id, -1),
DEFINE_PROP_INT32("socket-id", X86CPU, socket_id, -1),
#endif
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 95cbbb1de906..6a6356e34e62 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -2057,6 +2057,7 @@ struct ArchCPU {
int32_t node_id; /* NUMA node this CPU belongs to */
int32_t socket_id;
int32_t die_id;
+int32_t cluster_id;
int32_t core_id;
int32_t thread_id;
--
2.34.1
[PATCH v6 15/16] i386: Use offsets get NumSharingCache for CPUID[0x8000001D].EAX[bits 25:14]
From: Zhao Liu
The commit 8f4202fb1080 ("i386: Populate AMD Processor Cache Information
for cpuid 0x801D") adds the cache topology for AMD CPU by encoding
the number of sharing threads directly.
>From AMD's APM, NumSharingCache (CPUID[0x801D].EAX[bits 25:14])
means [1]:
The number of logical processors sharing this cache is the value of
this field incremented by 1. To determine which logical processors are
sharing a cache, determine a Share Id for each processor as follows:
ShareId = LocalApicId >> log2(NumSharingCache+1)
Logical processors with the same ShareId then share a cache. If
NumSharingCache+1 is not a power of two, round it up to the next power
of two.
>From the description above, the calculation of this field should be same
as CPUID[4].EAX[bits 25:14] for Intel CPUs. So also use the offsets of
APIC ID to calculate this field.
[1]: APM, vol.3, appendix.E.4.15 Function 8000_001Dh--Cache Topology
Information
Signed-off-by: Zhao Liu
Reviewed-by: Babu Moger
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* Rewrite the subject. (Babu)
* Delete the original "comment/help" expression, as this behavior is
confirmed for AMD CPUs. (Babu)
* Rename "num_apic_ids" (v3) to "num_sharing_cache" to match spec
definition. (Babu)
Changes since v1:
* Rename "l3_threads" to "num_apic_ids" in
encode_cache_cpuid801d(). (Yanan)
* Add the description of the original commit and add Cc.
---
target/i386/cpu.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 86445e833a2d..3ddedd6de120 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -483,7 +483,7 @@ static void encode_cache_cpuid801d(CPUCacheInfo *cache,
uint32_t *eax, uint32_t *ebx,
uint32_t *ecx, uint32_t *edx)
{
-uint32_t l3_threads;
+uint32_t num_sharing_cache;
assert(cache->size == cache->line_size * cache->associativity *
cache->partitions * cache->sets);
@@ -492,13 +492,11 @@ static void encode_cache_cpuid801d(CPUCacheInfo
*cache,
/* L3 is shared among multiple cores */
if (cache->level == 3) {
-l3_threads = topo_info->modules_per_die *
- topo_info->cores_per_module *
- topo_info->threads_per_core;
-*eax |= (l3_threads - 1) << 14;
+num_sharing_cache = 1 << apicid_die_offset(topo_info);
} else {
-*eax |= ((topo_info->threads_per_core - 1) << 14);
+num_sharing_cache = 1 << apicid_core_offset(topo_info);
}
+*eax |= (num_sharing_cache - 1) << 14;
assert(cache->line_size > 0);
assert(cache->partitions > 0);
--
2.34.1
[PATCH v6 14/16] i386: Use CPUCacheInfo.share_level to encode CPUID[4]
From: Zhao Liu
CPUID[4].EAX[bits 25:14] is used to represent the cache topology for
Intel CPUs.
After cache models have topology information, we can use
CPUCacheInfo.share_level to decide which topology level to be encoded
into CPUID[4].EAX[bits 25:14].
And since maximum_processor_id (original "num_apic_ids") is parsed
based on cpu topology levels, which are verified when parsing smp, it's
no need to check this value by "assert(num_apic_ids > 0)" again, so
remove this assert.
Additionally, wrap the encoding of CPUID[4].EAX[bits 31:26] into a
helper to make the code cleaner.
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v1:
* Use "enum CPUTopoLevel share_level" as the parameter in
max_processor_ids_for_cache().
* Make cache_into_passthrough case also use
max_processor_ids_for_cache() and max_core_ids_in_package() to
encode CPUID[4]. (Yanan)
* Rename the title of this patch (the original is "i386: Use
CPUCacheInfo.share_level to encode CPUID[4].EAX[bits 25:14]").
---
target/i386/cpu.c | 70 +--
1 file changed, 43 insertions(+), 27 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 5dcc41329805..86445e833a2d 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -235,22 +235,53 @@ static uint8_t cpuid2_cache_descriptor(CPUCacheInfo
*cache)
((t) == UNIFIED_CACHE) ? CACHE_TYPE_UNIFIED : \
0 /* Invalid value */)
+static uint32_t max_processor_ids_for_cache(X86CPUTopoInfo *topo_info,
+enum CPUTopoLevel share_level)
+{
+uint32_t num_ids = 0;
+
+switch (share_level) {
+case CPU_TOPO_LEVEL_CORE:
+num_ids = 1 << apicid_core_offset(topo_info);
+break;
+case CPU_TOPO_LEVEL_DIE:
+num_ids = 1 << apicid_die_offset(topo_info);
+break;
+case CPU_TOPO_LEVEL_PACKAGE:
+num_ids = 1 << apicid_pkg_offset(topo_info);
+break;
+default:
+/*
+ * Currently there is no use case for SMT and MODULE, so use
+ * assert directly to facilitate debugging.
+ */
+g_assert_not_reached();
+}
+
+return num_ids - 1;
+}
+
+static uint32_t max_core_ids_in_package(X86CPUTopoInfo *topo_info)
+{
+uint32_t num_cores = 1 << (apicid_pkg_offset(topo_info) -
+ apicid_core_offset(topo_info));
+return num_cores - 1;
+}
/* Encode cache info for CPUID[4] */
static void encode_cache_cpuid4(CPUCacheInfo *cache,
-int num_apic_ids, int num_cores,
+X86CPUTopoInfo *topo_info,
uint32_t *eax, uint32_t *ebx,
uint32_t *ecx, uint32_t *edx)
{
assert(cache->size == cache->line_size * cache->associativity *
cache->partitions * cache->sets);
-assert(num_apic_ids > 0);
*eax = CACHE_TYPE(cache->type) |
CACHE_LEVEL(cache->level) |
(cache->self_init ? CACHE_SELF_INIT_LEVEL : 0) |
- ((num_cores - 1) << 26) |
- ((num_apic_ids - 1) << 14);
+ (max_core_ids_in_package(topo_info) << 26) |
+ (max_processor_ids_for_cache(topo_info, cache->share_level) << 14);
assert(cache->line_size > 0);
assert(cache->partitions > 0);
@@ -6262,56 +6293,41 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
int host_vcpus_per_cache = 1 + ((*eax & 0x3FFC000) >> 14);
if (cores_per_pkg > 1) {
-int addressable_cores_offset =
-apicid_pkg_offset(_info) -
-apicid_core_offset(_info);
-
*eax &= ~0xFC00;
-*eax |= (1 << (addressable_cores_offset - 1)) << 26;
+*eax |= max_core_ids_in_package(_info) << 26;
}
if (host_vcpus_per_cache > cpus_per_pkg) {
-int pkg_offset = apicid_pkg_offset(_info);
-
*eax &= ~0x3FFC000;
-*eax |= (1 << (pkg_offset - 1)) << 14;
+*eax |=
+max_processor_ids_for_cache(_info,
+CPU_TOPO_LEVEL_PACKAGE) << 14;
}
}
} else if (cpu->vendor_cpuid_only && IS_AMD_CPU(env)) {
*eax = *ebx = *ecx = *edx = 0;
} else {
*eax = 0;
-int addressable_cores_offset = apicid_pkg_offset(_info) -
- apicid_core_offset(_info);
-int core_offset, die_offset;
switch (count) {
case 0: /* L1 dcache info */
-core_offset = apicid_core_offset(_info);
[PATCH v6 05/16] i386: Decouple CPUID[0x1F] subleaf with specific topology level
From: Zhao Liu
At present, the subleaf 0x02 of CPUID[0x1F] is bound to the "die" level.
In fact, the specific topology level exposed in 0x1F depends on the
platform's support for extension levels (module, tile and die).
To help expose "module" level in 0x1F, decouple CPUID[0x1F] subleaf
with specific topology level.
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* New patch to prepare to expose module level in 0x1F.
* Move the CPUTopoLevel enumeration definition from "i386: Add cache
topology info in CPUCacheInfo" to this patch. Note, to align with
topology types in SDM, revert the name of CPU_TOPO_LEVEL_UNKNOW to
CPU_TOPO_LEVEL_INVALID.
---
target/i386/cpu.c | 136 +-
target/i386/cpu.h | 15 +
2 files changed, 126 insertions(+), 25 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index fe9098353ac3..1713499c44cd 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -269,6 +269,116 @@ static void encode_cache_cpuid4(CPUCacheInfo *cache,
(cache->complex_indexing ? CACHE_COMPLEX_IDX : 0);
}
+static uint32_t num_cpus_by_topo_level(X86CPUTopoInfo *topo_info,
+ enum CPUTopoLevel topo_level)
+{
+switch (topo_level) {
+case CPU_TOPO_LEVEL_SMT:
+return 1;
+case CPU_TOPO_LEVEL_CORE:
+return topo_info->threads_per_core;
+case CPU_TOPO_LEVEL_DIE:
+return topo_info->threads_per_core * topo_info->cores_per_die;
+case CPU_TOPO_LEVEL_PACKAGE:
+return topo_info->threads_per_core * topo_info->cores_per_die *
+ topo_info->dies_per_pkg;
+default:
+g_assert_not_reached();
+}
+return 0;
+}
+
+static uint32_t apicid_offset_by_topo_level(X86CPUTopoInfo *topo_info,
+enum CPUTopoLevel topo_level)
+{
+switch (topo_level) {
+case CPU_TOPO_LEVEL_SMT:
+return 0;
+case CPU_TOPO_LEVEL_CORE:
+return apicid_core_offset(topo_info);
+case CPU_TOPO_LEVEL_DIE:
+return apicid_die_offset(topo_info);
+case CPU_TOPO_LEVEL_PACKAGE:
+return apicid_pkg_offset(topo_info);
+default:
+g_assert_not_reached();
+}
+return 0;
+}
+
+static uint32_t cpuid1f_topo_type(enum CPUTopoLevel topo_level)
+{
+switch (topo_level) {
+case CPU_TOPO_LEVEL_INVALID:
+return CPUID_1F_ECX_TOPO_LEVEL_INVALID;
+case CPU_TOPO_LEVEL_SMT:
+return CPUID_1F_ECX_TOPO_LEVEL_SMT;
+case CPU_TOPO_LEVEL_CORE:
+return CPUID_1F_ECX_TOPO_LEVEL_CORE;
+case CPU_TOPO_LEVEL_DIE:
+return CPUID_1F_ECX_TOPO_LEVEL_DIE;
+default:
+/* Other types are not supported in QEMU. */
+g_assert_not_reached();
+}
+return 0;
+}
+
+static void encode_topo_cpuid1f(CPUX86State *env, uint32_t count,
+X86CPUTopoInfo *topo_info,
+uint32_t *eax, uint32_t *ebx,
+uint32_t *ecx, uint32_t *edx)
+{
+static DECLARE_BITMAP(topo_bitmap, CPU_TOPO_LEVEL_MAX);
+X86CPU *cpu = env_archcpu(env);
+unsigned long level, next_level;
+uint32_t num_cpus_next_level, offset_next_level;
+
+/*
+ * Initialize the bitmap to decide which levels should be
+ * encoded in 0x1f.
+ */
+if (!count) {
+/* SMT and core levels are exposed in 0x1f leaf by default. */
+set_bit(CPU_TOPO_LEVEL_SMT, topo_bitmap);
+set_bit(CPU_TOPO_LEVEL_CORE, topo_bitmap);
+
+if (env->nr_dies > 1) {
+set_bit(CPU_TOPO_LEVEL_DIE, topo_bitmap);
+}
+}
+
+*ecx = count & 0xff;
+*edx = cpu->apic_id;
+
+level = find_first_bit(topo_bitmap, CPU_TOPO_LEVEL_MAX);
+if (level == CPU_TOPO_LEVEL_MAX) {
+num_cpus_next_level = 0;
+offset_next_level = 0;
+
+/* Encode CPU_TOPO_LEVEL_INVALID into the last subleaf of 0x1f. */
+level = CPU_TOPO_LEVEL_INVALID;
+} else {
+next_level = find_next_bit(topo_bitmap, CPU_TOPO_LEVEL_MAX, level + 1);
+if (next_level == CPU_TOPO_LEVEL_MAX) {
+next_level = CPU_TOPO_LEVEL_PACKAGE;
+}
+
+num_cpus_next_level = num_cpus_by_topo_level(topo_info, next_level);
+offset_next_level = apicid_offset_by_topo_level(topo_info, next_level);
+}
+
+*eax = offset_next_level;
+*ebx = num_cpus_next_level;
+*ecx |= cpuid1f_topo_type(level) << 8;
+
+assert(!(*eax & ~0x1f));
+*ebx &= 0x; /* The count doesn't need to be reliable. */
+if (level != CPU_TOPO_LEVEL_MAX) {
+clear_bit(level, topo_bitmap);
+}
+}
+
/* Encode cache info for CPUID[0x8005].ECX or CPUID[0x8005].EDX */
static uint32_t encode_cache_cpuid8005(CPUCacheInfo *cache)
{
@@ -6283,31 +6393,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
break;
[PATCH v6 03/16] i386/cpu: Consolidate the use of topo_info in cpu_x86_cpuid()
From: Zhao Liu
In cpu_x86_cpuid(), there are many variables in representing the cpu
topology, e.g., topo_info, cs->nr_cores/cs->nr_threads.
Since the names of cs->nr_cores/cs->nr_threads does not accurately
represent its meaning, the use of cs->nr_cores/cs->nr_threads is prone
to confusion and mistakes.
And the structure X86CPUTopoInfo names its members clearly, thus the
variable "topo_info" should be preferred.
In addition, in cpu_x86_cpuid(), to uniformly use the topology variable,
replace env->dies with topo_info.dies_per_pkg as well.
Suggested-by: Robert Hoo
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* Fix typo. (Babu)
Changes since v1:
* Extract cores_per_socket from the code block and use it as a local
variable for cpu_x86_cpuid(). (Yanan)
* Remove vcpus_per_socket variable and use cpus_per_pkg directly.
(Yanan)
* Replace env->dies with topo_info.dies_per_pkg in cpu_x86_cpuid().
---
target/i386/cpu.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 069f0b1f19a0..30d11db8844a 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6016,11 +6016,16 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
uint32_t limit;
uint32_t signature[3];
X86CPUTopoInfo topo_info;
+uint32_t cores_per_pkg;
+uint32_t cpus_per_pkg;
topo_info.dies_per_pkg = env->nr_dies;
topo_info.cores_per_die = cs->nr_cores / env->nr_dies;
topo_info.threads_per_core = cs->nr_threads;
+cores_per_pkg = topo_info.cores_per_die * topo_info.dies_per_pkg;
+cpus_per_pkg = cores_per_pkg * topo_info.threads_per_core;
+
/* Calculate & apply limits for different index ranges */
if (index >= 0xC000) {
limit = env->cpuid_xlevel2;
@@ -6056,8 +6061,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
*ecx |= CPUID_EXT_OSXSAVE;
}
*edx = env->features[FEAT_1_EDX];
-if (cs->nr_cores * cs->nr_threads > 1) {
-*ebx |= (cs->nr_cores * cs->nr_threads) << 16;
+if (cpus_per_pkg > 1) {
+*ebx |= cpus_per_pkg << 16;
*edx |= CPUID_HT;
}
if (!cpu->enable_pmu) {
@@ -6094,8 +6099,8 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
*/
if (*eax & 31) {
int host_vcpus_per_cache = 1 + ((*eax & 0x3FFC000) >> 14);
-int vcpus_per_socket = cs->nr_cores * cs->nr_threads;
-if (cs->nr_cores > 1) {
+
+if (cores_per_pkg > 1) {
int addressable_cores_offset =
apicid_pkg_offset(_info) -
apicid_core_offset(_info);
@@ -6103,7 +6108,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
*eax &= ~0xFC00;
*eax |= (1 << (addressable_cores_offset - 1)) << 26;
}
-if (host_vcpus_per_cache > vcpus_per_socket) {
+if (host_vcpus_per_cache > cpus_per_pkg) {
int pkg_offset = apicid_pkg_offset(_info);
*eax &= ~0x3FFC000;
@@ -6248,12 +6253,12 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
switch (count) {
case 0:
*eax = apicid_core_offset(_info);
-*ebx = cs->nr_threads;
+*ebx = topo_info.threads_per_core;
*ecx |= CPUID_TOPOLOGY_LEVEL_SMT;
break;
case 1:
*eax = apicid_pkg_offset(_info);
-*ebx = cs->nr_cores * cs->nr_threads;
+*ebx = cpus_per_pkg;
*ecx |= CPUID_TOPOLOGY_LEVEL_CORE;
break;
default:
@@ -6273,7 +6278,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
break;
case 0x1F:
/* V2 Extended Topology Enumeration Leaf */
-if (env->nr_dies < 2) {
+if (topo_info.dies_per_pkg < 2) {
*eax = *ebx = *ecx = *edx = 0;
break;
}
@@ -6283,7 +6288,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
switch (count) {
case 0:
*eax = apicid_core_offset(_info);
-*ebx = cs->nr_threads;
+*ebx = topo_info.threads_per_core;
*ecx |= CPUID_TOPOLOGY_LEVEL_SMT;
break;
case 1:
@@ -6293,7 +6298,7 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
break;
case 2:
*eax = apicid_pkg_offset(_info);
-*ebx = cs->nr_cores * cs->nr_threads;
+*ebx = cpus_per_pkg;
*ecx |= CPUID_TOPOLOGY_LEVEL_DIE;
break;
default:
@@ -6517,7 +6522,7 @@
[PATCH v6 02/16] i386/cpu: Use APIC ID offset to encode cache topo in CPUID[4]
From: Zhao Liu
Refer to the fixes of cache_info_passthrough ([1], [2]) and SDM, the
CPUID.04H:EAX[bits 25:14] and CPUID.04H:EAX[bits 31:26] should use the
nearest power-of-2 integer.
The nearest power-of-2 integer can be calculated by pow2ceil() or by
using APIC ID offset (like L3 topology using 1 << die_offset [3]).
But in fact, CPUID.04H:EAX[bits 25:14] and CPUID.04H:EAX[bits 31:26]
are associated with APIC ID. For example, in linux kernel, the field
"num_threads_sharing" (Bits 25 - 14) is parsed with APIC ID. And for
another example, on Alder Lake P, the CPUID.04H:EAX[bits 31:26] is not
matched with actual core numbers and it's calculated by:
"(1 << (pkg_offset - core_offset)) - 1".
Therefore the offset of APIC ID should be preferred to calculate nearest
power-of-2 integer for CPUID.04H:EAX[bits 25:14] and CPUID.04H:EAX[bits
31:26]:
1. d/i cache is shared in a core, 1 << core_offset should be used
instand of "cs->nr_threads" in encode_cache_cpuid4() for
CPUID.04H.00H:EAX[bits 25:14] and CPUID.04H.01H:EAX[bits 25:14].
2. L2 cache is supposed to be shared in a core as for now, thereby
1 << core_offset should also be used instand of "cs->nr_threads" in
encode_cache_cpuid4() for CPUID.04H.02H:EAX[bits 25:14].
3. Similarly, the value for CPUID.04H:EAX[bits 31:26] should also be
calculated with the bit width between the Package and SMT levels in
the APIC ID (1 << (pkg_offset - core_offset) - 1).
In addition, use APIC ID offset to replace "pow2ceil()" for
cache_info_passthrough case.
[1]: efb3934adf9e ("x86: cpu: make sure number of addressable IDs for processor
cores meets the spec")
[2]: d7caf13b5fcf ("x86: cpu: fixup number of addressable IDs for logical
processors sharing cache")
[3]: d65af288a84d ("i386: Update new x86_apicid parsing rules with die_offset
support")
Fixes: 7e3482f82480 ("i386: Helpers to encode cache information consistently")
Suggested-by: Robert Hoo
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* Fix compile warnings. (Babu)
* Fix spelling typo.
Changes since v1:
* Use APIC ID offset to replace "pow2ceil()" for cache_info_passthrough
case. (Yanan)
* Split the L1 cache fix into a separate patch.
* Rename the title of this patch (the original is "i386/cpu: Fix number
of addressable IDs in CPUID.04H").
---
target/i386/cpu.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 4a3621cc995a..069f0b1f19a0 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6013,7 +6013,6 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
{
X86CPU *cpu = env_archcpu(env);
CPUState *cs = env_cpu(env);
-uint32_t die_offset;
uint32_t limit;
uint32_t signature[3];
X86CPUTopoInfo topo_info;
@@ -6097,39 +6096,56 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
int host_vcpus_per_cache = 1 + ((*eax & 0x3FFC000) >> 14);
int vcpus_per_socket = cs->nr_cores * cs->nr_threads;
if (cs->nr_cores > 1) {
+int addressable_cores_offset =
+apicid_pkg_offset(_info) -
+apicid_core_offset(_info);
+
*eax &= ~0xFC00;
-*eax |= (pow2ceil(cs->nr_cores) - 1) << 26;
+*eax |= (1 << (addressable_cores_offset - 1)) << 26;
}
if (host_vcpus_per_cache > vcpus_per_socket) {
+int pkg_offset = apicid_pkg_offset(_info);
+
*eax &= ~0x3FFC000;
-*eax |= (pow2ceil(vcpus_per_socket) - 1) << 14;
+*eax |= (1 << (pkg_offset - 1)) << 14;
}
}
} else if (cpu->vendor_cpuid_only && IS_AMD_CPU(env)) {
*eax = *ebx = *ecx = *edx = 0;
} else {
*eax = 0;
+int addressable_cores_offset = apicid_pkg_offset(_info) -
+ apicid_core_offset(_info);
+int core_offset, die_offset;
+
switch (count) {
case 0: /* L1 dcache info */
+core_offset = apicid_core_offset(_info);
encode_cache_cpuid4(env->cache_info_cpuid4.l1d_cache,
-cs->nr_threads, cs->nr_cores,
+(1 << core_offset),
+(1 << addressable_cores_offset),
eax, ebx, ecx, edx);
break;
case 1: /* L1 icache info */
+core_offset = apicid_core_offset(_info);
encode_cache_cpuid4(env->cache_info_cpuid4.l1i_cache,
-cs->nr_threads, cs->nr_cores,
+
[PATCH v6 06/16] i386: Introduce module-level cpu topology to CPUX86State
From: Zhuocheng Ding
smp command has the "clusters" parameter but x86 hasn't supported that
level. "cluster" is a CPU topology level concept above cores, in which
the cores may share some resources (L2 cache or some others like L3
cache tags, depending on the Archs) [1][2]. For x86, the resource shared
by cores at the cluster level is mainly the L2 cache.
However, using cluster to define x86's L2 cache topology will cause the
compatibility problem:
Currently, x86 defaults that the L2 cache is shared in one core, which
actually implies a default setting "cores per L2 cache is 1" and
therefore implicitly defaults to having as many L2 caches as cores.
For example (i386 PC machine):
-smp 16,sockets=2,dies=2,cores=2,threads=2,maxcpus=16 (*)
Considering the topology of the L2 cache, this (*) implicitly means "1
core per L2 cache" and "2 L2 caches per die".
If we use cluster to configure L2 cache topology with the new default
setting "clusters per L2 cache is 1", the above semantics will change
to "2 cores per cluster" and "1 cluster per L2 cache", that is, "2
cores per L2 cache".
So the same command (*) will cause changes in the L2 cache topology,
further affecting the performance of the virtual machine.
Therefore, x86 should only treat cluster as a cpu topology level and
avoid using it to change L2 cache by default for compatibility.
"cluster" in smp is the CPU topology level which is between "core" and
die.
For x86, the "cluster" in smp is corresponding to the module level [2],
which is above the core level. So use the "module" other than "cluster"
in i386 code.
And please note that x86 already has a cpu topology level also named
"cluster" [3], this level is at the upper level of the package. Here,
the cluster in x86 cpu topology is completely different from the
"clusters" as the smp parameter. After the module level is introduced,
the cluster as the smp parameter will actually refer to the module level
of x86.
[1]: 864c3b5c32f0 ("hw/core/machine: Introduce CPU cluster topology support")
[2]: Yanan's comment about "cluster",
https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg04051.html
[3]: SDM, vol.3, ch.9, 9.9.1 Hierarchical Mapping of Shared Resources.
Signed-off-by: Zhuocheng Ding
Co-developed-by: Zhao Liu
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v1:
* The background of the introduction of the "cluster" parameter and its
exact meaning were revised according to Yanan's explanation. (Yanan)
---
hw/i386/x86.c | 1 +
target/i386/cpu.c | 1 +
target/i386/cpu.h | 5 +
3 files changed, 7 insertions(+)
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index b3d054889bba..24628c1d2f73 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -306,6 +306,7 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
init_topo_info(_info, x86ms);
env->nr_dies = ms->smp.dies;
+env->nr_modules = ms->smp.clusters;
/*
* If APIC ID is not set,
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 1713499c44cd..f600c0ee9df1 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -7698,6 +7698,7 @@ static void x86_cpu_initfn(Object *obj)
CPUX86State *env = >env;
env->nr_dies = 1;
+env->nr_modules = 1;
object_property_add(obj, "feature-words", "X86CPUFeatureWordInfo",
x86_cpu_get_feature_words,
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index a214d056ac4b..da58d41c9969 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1904,6 +1904,11 @@ typedef struct CPUArchState {
/* Number of dies within this CPU package. */
unsigned nr_dies;
+/*
+ * Number of modules within this CPU package.
+ * Module level in x86 cpu topology is corresponding to smp.clusters.
+ */
+unsigned nr_modules;
} CPUX86State;
struct kvm_msrs;
--
2.34.1
[PATCH v6 16/16] i386: Use CPUCacheInfo.share_level to encode CPUID[0x8000001D].EAX[bits 25:14]
From: Zhao Liu
CPUID[0x801D].EAX[bits 25:14] NumSharingCache: number of logical
processors sharing cache.
The number of logical processors sharing this cache is
NumSharingCache + 1.
After cache models have topology information, we can use
CPUCacheInfo.share_level to decide which topology level to be encoded
into CPUID[0x801D].EAX[bits 25:14].
Signed-off-by: Zhao Liu
Reviewed-by: Babu Moger
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* Explain what "CPUID[0x801D].EAX[bits 25:14]" means in the commit
message. (Babu)
Changes since v1:
* Use cache->share_level as the parameter in
max_processor_ids_for_cache().
---
target/i386/cpu.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 3ddedd6de120..b45d9eb74e67 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -483,20 +483,12 @@ static void encode_cache_cpuid801d(CPUCacheInfo
*cache,
uint32_t *eax, uint32_t *ebx,
uint32_t *ecx, uint32_t *edx)
{
-uint32_t num_sharing_cache;
assert(cache->size == cache->line_size * cache->associativity *
cache->partitions * cache->sets);
*eax = CACHE_TYPE(cache->type) | CACHE_LEVEL(cache->level) |
(cache->self_init ? CACHE_SELF_INIT_LEVEL : 0);
-
-/* L3 is shared among multiple cores */
-if (cache->level == 3) {
-num_sharing_cache = 1 << apicid_die_offset(topo_info);
-} else {
-num_sharing_cache = 1 << apicid_core_offset(topo_info);
-}
-*eax |= (num_sharing_cache - 1) << 14;
+*eax |= max_processor_ids_for_cache(topo_info, cache->share_level) << 14;
assert(cache->line_size > 0);
assert(cache->partitions > 0);
--
2.34.1
[PATCH v6 09/16] i386: Support module_id in X86CPUTopoIDs
From: Zhuocheng Ding
Add module_id member in X86CPUTopoIDs.
module_id can be parsed from APIC ID, so also update APIC ID parsing
rule to support module level. With this support, the conversions with
module level between X86CPUTopoIDs, X86CPUTopoInfo and APIC ID are
completed.
module_id can be also generated from cpu topology, and before i386
supports "clusters" in smp, the default "clusters per die" is only 1,
thus the module_id generated in this way is 0, so that it will not
conflict with the module_id generated by APIC ID.
Signed-off-by: Zhuocheng Ding
Co-developed-by: Zhao Liu
Signed-off-by: Zhao Liu
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v1:
* Merge the patch "i386: Update APIC ID parsing rule to support module
level" into this one. (Yanan)
* Move the apicid_module_width() and apicid_module_offset() support
into the previous modules_per_die related patch. (Yanan)
---
hw/i386/x86.c | 28 +---
include/hw/i386/topology.h | 17 +
2 files changed, 34 insertions(+), 11 deletions(-)
diff --git a/hw/i386/x86.c b/hw/i386/x86.c
index 8503d30a133a..3e2fabf3d5bd 100644
--- a/hw/i386/x86.c
+++ b/hw/i386/x86.c
@@ -311,11 +311,11 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
/*
* If APIC ID is not set,
- * set it based on socket/die/core/thread properties.
+ * set it based on socket/die/cluster/core/thread properties.
*/
if (cpu->apic_id == UNASSIGNED_APIC_ID) {
-int max_socket = (ms->smp.max_cpus - 1) /
-smp_threads / smp_cores / ms->smp.dies;
+int max_socket = (ms->smp.max_cpus - 1) / smp_threads / smp_cores /
+ms->smp.clusters / ms->smp.dies;
/*
* die-id was optional in QEMU 4.0 and older, so keep it optional
@@ -362,17 +362,27 @@ void x86_cpu_pre_plug(HotplugHandler *hotplug_dev,
topo_ids.die_id = cpu->die_id;
topo_ids.core_id = cpu->core_id;
topo_ids.smt_id = cpu->thread_id;
+
+/*
+ * TODO: This is the temporary initialization for topo_ids.module_id to
+ * avoid "maybe-uninitialized" compilation errors. Will remove when
+ * X86CPU supports cluster_id.
+ */
+topo_ids.module_id = 0;
+
cpu->apic_id = x86_apicid_from_topo_ids(_info, _ids);
}
cpu_slot = x86_find_cpu_slot(MACHINE(x86ms), cpu->apic_id, );
if (!cpu_slot) {
x86_topo_ids_from_apicid(cpu->apic_id, _info, _ids);
+
error_setg(errp,
-"Invalid CPU [socket: %u, die: %u, core: %u, thread: %u] with"
-" APIC ID %" PRIu32 ", valid index range 0:%d",
-topo_ids.pkg_id, topo_ids.die_id, topo_ids.core_id,
topo_ids.smt_id,
-cpu->apic_id, ms->possible_cpus->len - 1);
+"Invalid CPU [socket: %u, die: %u, module: %u, core: %u, thread:
%u]"
+" with APIC ID %" PRIu32 ", valid index range 0:%d",
+topo_ids.pkg_id, topo_ids.die_id, topo_ids.module_id,
+topo_ids.core_id, topo_ids.smt_id, cpu->apic_id,
+ms->possible_cpus->len - 1);
return;
}
@@ -493,6 +503,10 @@ const CPUArchIdList
*x86_possible_cpu_arch_ids(MachineState *ms)
ms->possible_cpus->cpus[i].props.has_die_id = true;
ms->possible_cpus->cpus[i].props.die_id = topo_ids.die_id;
}
+if (ms->smp.clusters > 1) {
+ms->possible_cpus->cpus[i].props.has_cluster_id = true;
+ms->possible_cpus->cpus[i].props.cluster_id = topo_ids.module_id;
+}
ms->possible_cpus->cpus[i].props.has_core_id = true;
ms->possible_cpus->cpus[i].props.core_id = topo_ids.core_id;
ms->possible_cpus->cpus[i].props.has_thread_id = true;
diff --git a/include/hw/i386/topology.h b/include/hw/i386/topology.h
index 517e51768c13..ed1f3d6c1d5e 100644
--- a/include/hw/i386/topology.h
+++ b/include/hw/i386/topology.h
@@ -50,6 +50,7 @@ typedef uint32_t apic_id_t;
typedef struct X86CPUTopoIDs {
unsigned pkg_id;
unsigned die_id;
+unsigned module_id;
unsigned core_id;
unsigned smt_id;
} X86CPUTopoIDs;
@@ -127,6 +128,7 @@ static inline apic_id_t
x86_apicid_from_topo_ids(X86CPUTopoInfo *topo_info,
{
return (topo_ids->pkg_id << apicid_pkg_offset(topo_info)) |
(topo_ids->die_id << apicid_die_offset(topo_info)) |
+ (topo_ids->module_id << apicid_module_offset(topo_info)) |
(topo_ids->core_id << apicid_core_offset(topo_info)) |
topo_ids->smt_id;
}
@@ -140,12 +142,16 @@ static inline void x86_topo_ids_from_idx(X86CPUTopoInfo
*topo_info,
X86CPUTopoIDs *topo_ids)
{
unsigned nr_dies = topo_info->dies_per_pkg;
-unsigned nr_cores = topo_info->cores_per_module *
-topo_info->modules_per_die;
+unsigned nr_modules =
[PATCH v6 01/16] i386/cpu: Fix i/d-cache topology to core level for Intel CPU
From: Zhao Liu
For i-cache and d-cache, current QEMU hardcodes the maximum IDs for CPUs
sharing cache (CPUID.04H.00H:EAX[bits 25:14] and CPUID.04H.01H:EAX[bits
25:14]) to 0, and this means i-cache and d-cache are shared in the SMT
level.
This is correct if there's single thread per core, but is wrong for the
hyper threading case (one core contains multiple threads) since the
i-cache and d-cache are shared in the core level other than SMT level.
For AMD CPU, commit 8f4202fb1080 ("i386: Populate AMD Processor Cache
Information for cpuid 0x801D") has already introduced i/d cache
topology as core level by default.
Therefore, in order to be compatible with both multi-threaded and
single-threaded situations, we should set i-cache and d-cache be shared
at the core level by default.
This fix changes the default i/d cache topology from per-thread to
per-core. Potentially, this change in L1 cache topology may affect the
performance of the VM if the user does not specifically specify the
topology or bind the vCPU. However, the way to achieve optimal
performance should be to create a reasonable topology and set the
appropriate vCPU affinity without relying on QEMU's default topology
structure.
Fixes: 7e3482f82480 ("i386: Helpers to encode cache information consistently")
Suggested-by: Robert Hoo
Signed-off-by: Zhao Liu
Reviewed-by: Xiaoyao Li
Tested-by: Babu Moger
Tested-by: Yongwei Ma
Acked-by: Michael S. Tsirkin
---
Changes since v3:
* Change the description of current i/d cache encoding status to avoid
misleading to "architectural rules". (Xiaoyao)
Changes since v1:
* Split this fix from the patch named "i386/cpu: Fix number of
addressable IDs in CPUID.04H".
* Add the explanation of the impact on performance. (Xiaoyao)
---
target/i386/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 358d9c0a655a..4a3621cc995a 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -6112,12 +6112,12 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index,
uint32_t count,
switch (count) {
case 0: /* L1 dcache info */
encode_cache_cpuid4(env->cache_info_cpuid4.l1d_cache,
-1, cs->nr_cores,
+cs->nr_threads, cs->nr_cores,
eax, ebx, ecx, edx);
break;
case 1: /* L1 icache info */
encode_cache_cpuid4(env->cache_info_cpuid4.l1i_cache,
-1, cs->nr_cores,
+cs->nr_threads, cs->nr_cores,
eax, ebx, ecx, edx);
break;
case 2: /* L2 cache info */
--
2.34.1
RE: [PATCH v5 08/11] hw/net: General GMAC Implementation
-Original Message-
From: Nabih Estefan
Sent: Saturday, October 28, 2023 1:55 AM
To: peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; CS20 KFTing
; wuhao...@google.com; jasonw...@redhat.com; IS20 Avi
Fishman ; nabiheste...@google.com; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: [PATCH v5 08/11] hw/net: General GMAC Implementation
From: Nabih Estefan Diaz
- General GMAC Register handling
- GMAC IRQ Handling
- Added traces in some methods for debugging
- Lots of declarations for accessing information on GMAC Descriptors
(npcm_gmac.h file)
NOTE: With code on this state, the GMAC can boot-up properly and will show up
in the ifconfig command on the BMC
Change-Id: I2658c0cbec4a73b5cd1ea90cfdcabec9eaca1c46
Signed-off-by: Nabih Estefan
---
hw/net/npcm_gmac.c | 26 -
include/hw/net/npcm_gmac.h | 198 ++---
2 files changed, 184 insertions(+), 40 deletions(-)
diff --git a/hw/net/npcm_gmac.c b/hw/net/npcm_gmac.c index
6f8109e0ee..220955346c 100644
--- a/hw/net/npcm_gmac.c
+++ b/hw/net/npcm_gmac.c
@@ -305,22 +305,6 @@ static void npcm_gmac_write(void *opaque, hwaddr offset,
break;
case A_NPCM_GMAC_MAC_CONFIG:
-prev = gmac->regs[offset / sizeof(uint32_t)];
-gmac->regs[offset / sizeof(uint32_t)] = v;
-
-/* If transmit is being enabled for first time, update desc addr */
-if (~(prev & NPCM_GMAC_MAC_CONFIG_TX_EN) &
- (v & NPCM_GMAC_MAC_CONFIG_TX_EN)) {
-gmac->regs[R_NPCM_DMA_HOST_TX_DESC] =
-gmac->regs[R_NPCM_DMA_TX_BASE_ADDR];
-}
-
-/* If receive is being enabled for first time, update desc addr */
-if (~(prev & NPCM_GMAC_MAC_CONFIG_RX_EN) &
- (v & NPCM_GMAC_MAC_CONFIG_RX_EN)) {
-gmac->regs[R_NPCM_DMA_HOST_RX_DESC] =
-gmac->regs[R_NPCM_DMA_RX_BASE_ADDR];
-}
break;
case A_NPCM_GMAC_MII_ADDR:
@@ -371,16 +355,6 @@ static void npcm_gmac_write(void *opaque, hwaddr offset,
"%s: Write of read-only bits of reg: offset: 0x%04"
HWADDR_PRIx ", value: 0x%04" PRIx64 "\n",
DEVICE(gmac)->canonical_path, offset, v);
-} else {
-/* for W1c bits, implement W1C */
-gmac->regs[offset / sizeof(uint32_t)] &=
-~NPCM_DMA_STATUS_W1C_MASK(v);
-if (v & NPCM_DMA_STATUS_NIS_BITS) {
-gmac->regs[offset / sizeof(uint32_t)] &= ~NPCM_DMA_STATUS_NIS;
-}
-if (v & NPCM_DMA_STATUS_AIS_BITS) {
-gmac->regs[offset / sizeof(uint32_t)] &= ~NPCM_DMA_STATUS_AIS;
-}
}
break;
diff --git a/include/hw/net/npcm_gmac.h b/include/hw/net/npcm_gmac.h index
e5729e83ea..c97eb6fe6e 100644
--- a/include/hw/net/npcm_gmac.h
+++ b/include/hw/net/npcm_gmac.h
@@ -34,13 +34,15 @@ struct NPCMGMACRxDesc { };
/* NPCMGMACRxDesc.flags values */
-/* RDES2 and RDES3 are buffer address pointers */
-/* Owner: 0 = software, 1 = gmac */
-#define RX_DESC_RDES0_OWNER_MASK BIT(31)
+/* RDES2 and RDES3 are buffer addresses */
+/* Owner: 0 = software, 1 = dma */
+#define RX_DESC_RDES0_OWN BIT(31)
/* Destination Address Filter Fail */
-#define RX_DESC_RDES0_DEST_ADDR_FILT_FAIL_MASK BIT(30)
-/* Frame length*/
-#define RX_DESC_RDES0_FRAME_LEN_MASK(word) extract32(word, 16, 29)
+#define RX_DESC_RDES0_DEST_ADDR_FILT_FAIL BIT(30)
+/* Frame length */
+#define RX_DESC_RDES0_FRAME_LEN_MASK(word) extract32(word, 16, 14)
+/* Frame length Shift*/
+#define RX_DESC_RDES0_FRAME_LEN_SHIFT 16
/* Error Summary */
#define RX_DESC_RDES0_ERR_SUMM_MASK BIT(15)
/* Descriptor Error */
@@ -83,9 +85,9 @@ struct NPCMGMACRxDesc {
/* Receive Buffer 2 Size */
#define RX_DESC_RDES1_BFFR2_SZ_SHIFT 11 #define
RX_DESC_RDES1_BFFR2_SZ_MASK(word) extract32(word, \
-RX_DESC_RDES1_BFFR2_SZ_SHIFT, 10 + RX_DESC_RDES1_BFFR2_SZ_SHIFT)
+RX_DESC_RDES1_BFFR2_SZ_SHIFT, 11)
/* Receive Buffer 1 Size */
-#define RX_DESC_RDES1_BFFR1_SZ_MASK(word) extract32(word, 0, 10)
+#define RX_DESC_RDES1_BFFR1_SZ_MASK(word) extract32(word, 0, 11)
struct NPCMGMACTxDesc {
@@ -96,9 +98,9 @@ struct NPCMGMACTxDesc { };
/* NPCMGMACTxDesc.flags values */
-/* TDES2 and TDES3 are buffer address pointers */
+/* TDES2 and TDES3 are buffer addresses */
/* Owner: 0 = software, 1 = gmac */
-#define TX_DESC_TDES0_OWNER_MASK BIT(31)
+#define TX_DESC_TDES0_OWN BIT(31)
/* Tx Time Stamp Status */
#define TX_DESC_TDES0_TTSS_MASK BIT(17)
/* IP Header Error */
@@ -122,7 +124,7 @@ struct NPCMGMACTxDesc {
/* VLAN Frame */
#define TX_DESC_TDES0_VLAN_FRM_MASK BIT(7)
/* Collision Count */
-#define TX_DESC_TDES0_COLL_CNT_MASK(word) extract32(word, 3, 6)
+#define TX_DESC_TDES0_COLL_CNT_MASK(word) extract32(word, 3, 4)
/* Excessive Deferral */
#define TX_DESC_TDES0_EXCS_DEF_MASK BIT(2)
/* Underflow Error */
@@ -137,7 +139,7 @@ struct
[PATCH v6 04/16] i386: Split topology types of CPUID[0x1F] from the definitions of CPUID[0xB]
From: Zhao Liu CPUID[0xB] defines SMT, Core and Invalid types, and this leaf is shared by Intel and AMD CPUs. But for extended topology levels, Intel CPU (in CPUID[0x1F]) and AMD CPU (in CPUID[0x8026]) have the different definitions with different enumeration values. Though CPUID[0x8026] hasn't been implemented in QEMU, to avoid possible misunderstanding, split topology types of CPUID[0x1F] from the definitions of CPUID[0xB] and introduce CPUID[0x1F]-specific topology types. Signed-off-by: Zhao Liu Tested-by: Babu Moger Tested-by: Yongwei Ma Acked-by: Michael S. Tsirkin --- Changes since v3: * New commit to prepare to refactor CPUID[0x1F] encoding. --- target/i386/cpu.c | 14 +++--- target/i386/cpu.h | 13 + 2 files changed, 16 insertions(+), 11 deletions(-) diff --git a/target/i386/cpu.c b/target/i386/cpu.c index 30d11db8844a..fe9098353ac3 100644 --- a/target/i386/cpu.c +++ b/target/i386/cpu.c @@ -6254,17 +6254,17 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, case 0: *eax = apicid_core_offset(_info); *ebx = topo_info.threads_per_core; -*ecx |= CPUID_TOPOLOGY_LEVEL_SMT; +*ecx |= CPUID_B_ECX_TOPO_LEVEL_SMT << 8; break; case 1: *eax = apicid_pkg_offset(_info); *ebx = cpus_per_pkg; -*ecx |= CPUID_TOPOLOGY_LEVEL_CORE; +*ecx |= CPUID_B_ECX_TOPO_LEVEL_CORE << 8; break; default: *eax = 0; *ebx = 0; -*ecx |= CPUID_TOPOLOGY_LEVEL_INVALID; +*ecx |= CPUID_B_ECX_TOPO_LEVEL_INVALID << 8; } assert(!(*eax & ~0x1f)); @@ -6289,22 +6289,22 @@ void cpu_x86_cpuid(CPUX86State *env, uint32_t index, uint32_t count, case 0: *eax = apicid_core_offset(_info); *ebx = topo_info.threads_per_core; -*ecx |= CPUID_TOPOLOGY_LEVEL_SMT; +*ecx |= CPUID_1F_ECX_TOPO_LEVEL_SMT << 8; break; case 1: *eax = apicid_die_offset(_info); *ebx = topo_info.cores_per_die * topo_info.threads_per_core; -*ecx |= CPUID_TOPOLOGY_LEVEL_CORE; +*ecx |= CPUID_1F_ECX_TOPO_LEVEL_CORE << 8; break; case 2: *eax = apicid_pkg_offset(_info); *ebx = cpus_per_pkg; -*ecx |= CPUID_TOPOLOGY_LEVEL_DIE; +*ecx |= CPUID_1F_ECX_TOPO_LEVEL_DIE << 8; break; default: *eax = 0; *ebx = 0; -*ecx |= CPUID_TOPOLOGY_LEVEL_INVALID; +*ecx |= CPUID_1F_ECX_TOPO_LEVEL_INVALID << 8; } assert(!(*eax & ~0x1f)); *ebx &= 0x; /* The count doesn't need to be reliable. */ diff --git a/target/i386/cpu.h b/target/i386/cpu.h index cd2e295bd655..5aa0b8cf4137 100644 --- a/target/i386/cpu.h +++ b/target/i386/cpu.h @@ -1009,10 +1009,15 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w, #define CPUID_MWAIT_EMX (1U << 0) /* enumeration supported */ /* CPUID[0xB].ECX level types */ -#define CPUID_TOPOLOGY_LEVEL_INVALID (0U << 8) -#define CPUID_TOPOLOGY_LEVEL_SMT (1U << 8) -#define CPUID_TOPOLOGY_LEVEL_CORE (2U << 8) -#define CPUID_TOPOLOGY_LEVEL_DIE (5U << 8) +#define CPUID_B_ECX_TOPO_LEVEL_INVALID 0 +#define CPUID_B_ECX_TOPO_LEVEL_SMT 1 +#define CPUID_B_ECX_TOPO_LEVEL_CORE 2 + +/* COUID[0x1F].ECX level types */ +#define CPUID_1F_ECX_TOPO_LEVEL_INVALID CPUID_B_ECX_TOPO_LEVEL_INVALID +#define CPUID_1F_ECX_TOPO_LEVEL_SMT CPUID_B_ECX_TOPO_LEVEL_SMT +#define CPUID_1F_ECX_TOPO_LEVEL_CORE CPUID_B_ECX_TOPO_LEVEL_CORE +#define CPUID_1F_ECX_TOPO_LEVEL_DIE 5 /* MSR Feature Bits */ #define MSR_ARCH_CAP_RDCL_NO(1U << 0) -- 2.34.1
[PATCH v6 00/16] Support smp.clusters for x86 in QEMU
From: Zhao Liu
Hi list,
This is the our v6 patch series, rebased on the master branch at the
commit 34a5cb6d8434 (Merge tag 'pull-tcg-20231114' of
https://gitlab.com/rth7680/qemu into staging).
Because the first four patches of v5 [1] have been merged, v6 contains
the remaining patches and reabse on the latest master.
No more change since v5 exclude the comment update about QEMU version
(see Changelog).
Welcome your comments!
PS: About the idea to implement generic smp cache topology, we're
considerring to port the original x-l2-cache-topo option to smp [2].
Just like:
-smp cpus=4,sockets=2,cores=2,threads=1, \
l3-cache=socket,l2-cache=core,l1-i-cache=core,l1-d-cache=core
Any feedback about this direction is also welcomed! ;-)
---
# Introduction
This series adds the cluster support for x86 PC machine, which allows
x86 can use smp.clusters to configure the module level CPU topology
of x86.
This series also is the preparation to help x86 to define the more
flexible cache topology, such as having multiple cores share the
same L2 cache at cluster level. (That was what x-l2-cache-topo did,
and we will explore a generic way.)
About why we don't share L2 cache at cluster and need a configuration
way, pls see section: ## Why not share L2 cache in cluster directly.
# Background
The "clusters" parameter in "smp" is introduced by ARM [3], but x86
hasn't supported it.
At present, x86 defaults L2 cache is shared in one core, but this is
not enough. There're some platforms that multiple cores share the
same L2 cache, e.g., Alder Lake-P shares L2 cache for one module of
Atom cores [4], that is, every four Atom cores shares one L2 cache.
Therefore, we need the new CPU topology level (cluster/module).
Another reason is for hybrid architecture. cluster support not only
provides another level of topology definition in x86, but would also
provide required code change for future our hybrid topology support.
# Overview
## Introduction of module level for x86
"cluster" in smp is the CPU topology level which is between "core" and
die.
For x86, the "cluster" in smp is corresponding to the module level [4],
which is above the core level. So use the "module" other than "cluster"
in x86 code.
And please note that x86 already has a cpu topology level also named
"cluster" [5], this level is at the upper level of the package. Here,
the cluster in x86 cpu topology is completely different from the
"clusters" as the smp parameter. After the module level is introduced,
the cluster as the smp parameter will actually refer to the module level
of x86.
## Why not share L2 cache in cluster directly
Though "clusters" was introduced to help define L2 cache topology
[3], using cluster to define x86's L2 cache topology will cause the
compatibility problem:
Currently, x86 defaults that the L2 cache is shared in one core, which
actually implies a default setting "cores per L2 cache is 1" and
therefore implicitly defaults to having as many L2 caches as cores.
For example (i386 PC machine):
-smp 16,sockets=2,dies=2,cores=2,threads=2,maxcpus=16 (*)
Considering the topology of the L2 cache, this (*) implicitly means "1
core per L2 cache" and "2 L2 caches per die".
If we use cluster to configure L2 cache topology with the new default
setting "clusters per L2 cache is 1", the above semantics will change
to "2 cores per cluster" and "1 cluster per L2 cache", that is, "2
cores per L2 cache".
So the same command (*) will cause changes in the L2 cache topology,
further affecting the performance of the virtual machine.
Therefore, x86 should only treat cluster as a cpu topology level and
avoid using it to change L2 cache by default for compatibility.
## module level in CPUID
Linux kernel (from v6.4, with commit edc0a2b595765 ("x86/topology: Fix
erroneous smp_num_siblings on Intel Hybrid platforms") is able to
handle platforms with Module level enumerated via CPUID.1F.
Expose the module level in CPUID[0x1F] (for Intel CPUs) if the machine
has more than 1 modules since v3.
## New cache topology info in CPUCacheInfo
(This is in preparation for users being able to configure cache topology
from the cli later on.)
Currently, by default, the cache topology is encoded as:
1. i/d cache is shared in one core.
2. L2 cache is shared in one core.
3. L3 cache is shared in one die.
This default general setting has caused a misunderstanding, that is, the
cache topology is completely equated with a specific cpu topology, such
as the connection between L2 cache and core level, and the connection
between L3 cache and die level.
In fact, the settings of these topologies depend on the specific
platform and are not static. For example, on Alder Lake-P, every
four Atom cores share the same L2 cache [3].
Thus, in this patch set, we explicitly define the corresponding cache
topology for different cpu models and this has two benefits:
1. Easy to expand to new CPU models in the future, which has different
cache topology.
2. It can
Re: [PATCH 3/3] tests/avocado: Enable reverse_debugging.py tests in gitlab CI
On Fri Nov 17, 2023 at 4:11 AM AEST, Thomas Huth wrote: > On 16/11/2023 12.53, Nicholas Piggin wrote: > > Let's try enable reverse_debugging.py in gitlab CI. > > > > Signed-off-by: Nicholas Piggin > > --- > > Maybe we could try this again at some point? The bug might have been > > noticed sooner. > > > > They only take a couple of seconds to run so should not take too much > > overhead. But my gitlab CI pipeline doesn't run the avocado tests for > > some reason, so I can't see if it's still causing problems. > > > > Thanks, > > Nick > > --- > > > > tests/avocado/reverse_debugging.py | 7 --- > > 1 file changed, 7 deletions(-) > > FYI, I gave it a try, and it survived my CI run: > > https://gitlab.com/thuth/qemu/-/jobs/5552213972#L403 > > So I went ahead and put it (together with the first patch) in my current > pull request, let's see how it goes... Great, thank you. > (for the second patch, I hope our chardev maintainer Marc-André could > comment on that first) Yeah that would be good, no rush for that one. Maybe it's not desirable for other reasons too. Thanks, Nick
Assessment of the difficulty in porting CPU architecture for qemu
Hello everyone! I am working on implementing a tool to assess the complexity of CPU architecture porting. It primarily focuses on RISC-V architecture porting. In fact, the tool may have an average estimate of various architecture porting efforts.My focus is on the overall workload and difficulty of transplantation in the past and future,even if a project has already been ported.As part of my dataset, I have collected the **qemu** project. **I would like to gather community opinions to support my assessment. I appreciate your help and response!** Based on scanning tools, the porting complexity is determined to be high, with a significant amount of code related to the CPU architecture in the project. Is this assessment accurate?Do you have any opinions on personnel allocation and consumption time?? I look forward to your help and response.
Re: [PATCH v5 00/31] Unified CPU type check
On 17/11/23 00:26, Gavin Shan wrote: Hi Phil, On 11/17/23 02:20, Philippe Mathieu-Daudé wrote: On 16/11/23 14:35, Philippe Mathieu-Daudé wrote: I'm queuing patches 1-3 & 5-23 to my cpus-next tree. No need to repost them, please base them on my tree. I'll follow up with the branch link when I finish my testing and push it. Here are these patches queued: https://github.com/philmd/qemu.git branches/cpus-next Oops, no clue why I wrote github instead of gitlab, sorry =) I might queue more patches before the 9.0 merge window opens. Thanks for queuing these patches, but I don't see 'cpus-next' branch in the repository. Please let me know if I checked out the code properly. $ git clone https://github.com/philmd/qemu.git philmd $ cd philmd $ git branch * staging $ git branch -a | grep cpus-next $ echo $? 1 No need to clone, you can use in your current cloned repository: $ git fetch https://gitlab.com/philmd/qemu.git cpus-next:cpus-next Regards, Phil.
[PATCH-for-8.2? v2 4/4] hw/arm/stm32f100: Report error when incorrect CPU is used
The 'stm32vldiscovery' machine ignores the CPU type requested by
the command line. This might confuse users, since the following
will create a machine with a Cortex-M3 CPU:
$ qemu-system-aarch64 -M stm32vldiscovery -cpu neoverse-n1
Set the MachineClass::valid_cpu_types field (introduced in commit
c9cf636d48 "machine: Add a valid_cpu_types property").
Remove the now unused MachineClass::default_cpu_type field.
We now get:
$ qemu-system-aarch64 -M stm32vldiscovery -cpu neoverse-n1
qemu-system-aarch64: Invalid CPU type: neoverse-n1-arm-cpu
The valid types are: cortex-m3-arm-cpu
Since the SoC family can only use Cortex-M3 CPUs, hard-code the
CPU type name at the SoC level, removing the QOM property
entirely.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/stm32f100_soc.h | 4
hw/arm/stm32f100_soc.c | 9 ++---
hw/arm/stm32vldiscovery.c | 7 ++-
3 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/include/hw/arm/stm32f100_soc.h b/include/hw/arm/stm32f100_soc.h
index 40cd415b28..a74d7b369c 100644
--- a/include/hw/arm/stm32f100_soc.h
+++ b/include/hw/arm/stm32f100_soc.h
@@ -43,12 +43,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(STM32F100State, STM32F100_SOC)
#define SRAM_SIZE (8 * 1024)
struct STM32F100State {
-/*< private >*/
SysBusDevice parent_obj;
-/*< public >*/
-char *cpu_type;
-
ARMv7MState armv7m;
STM32F2XXUsartState usart[STM_NUM_USARTS];
diff --git a/hw/arm/stm32f100_soc.c b/hw/arm/stm32f100_soc.c
index f7b344ba9f..b90d440d7a 100644
--- a/hw/arm/stm32f100_soc.c
+++ b/hw/arm/stm32f100_soc.c
@@ -115,7 +115,7 @@ static void stm32f100_soc_realize(DeviceState *dev_soc,
Error **errp)
/* Init ARMv7m */
armv7m = DEVICE(>armv7m);
qdev_prop_set_uint32(armv7m, "num-irq", 61);
-qdev_prop_set_string(armv7m, "cpu-type", s->cpu_type);
+qdev_prop_set_string(armv7m, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
qdev_prop_set_bit(armv7m, "enable-bitband", true);
qdev_connect_clock_in(armv7m, "cpuclk", s->sysclk);
qdev_connect_clock_in(armv7m, "refclk", s->refclk);
@@ -180,17 +180,12 @@ static void stm32f100_soc_realize(DeviceState *dev_soc,
Error **errp)
create_unimplemented_device("CRC", 0x40023000, 0x400);
}
-static Property stm32f100_soc_properties[] = {
-DEFINE_PROP_STRING("cpu-type", STM32F100State, cpu_type),
-DEFINE_PROP_END_OF_LIST(),
-};
-
static void stm32f100_soc_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
dc->realize = stm32f100_soc_realize;
-device_class_set_props(dc, stm32f100_soc_properties);
+/* No vmstate or reset required: device has no internal state */
}
static const TypeInfo stm32f100_soc_info = {
diff --git a/hw/arm/stm32vldiscovery.c b/hw/arm/stm32vldiscovery.c
index 67675e952f..190db6118b 100644
--- a/hw/arm/stm32vldiscovery.c
+++ b/hw/arm/stm32vldiscovery.c
@@ -47,7 +47,6 @@ static void stm32vldiscovery_init(MachineState *machine)
clock_set_hz(sysclk, SYSCLK_FRQ);
dev = qdev_new(TYPE_STM32F100_SOC);
-qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
qdev_connect_clock_in(dev, "sysclk", sysclk);
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
@@ -58,8 +57,14 @@ static void stm32vldiscovery_init(MachineState *machine)
static void stm32vldiscovery_machine_init(MachineClass *mc)
{
+static const char * const valid_cpu_types[] = {
+ARM_CPU_TYPE_NAME("cortex-m3"),
+NULL
+};
+
mc->desc = "ST STM32VLDISCOVERY (Cortex-M3)";
mc->init = stm32vldiscovery_init;
+mc->valid_cpu_types = valid_cpu_types;
}
DEFINE_MACHINE("stm32vldiscovery", stm32vldiscovery_machine_init)
--
2.41.0
[PATCH-for-8.2? v2 1/4] hw/core/machine: Constify MachineClass::valid_cpu_types[]
From: Gavin Shan
Constify MachineClass::valid_cpu_types[i], as suggested by Richard
Henderson.
Suggested-by: Richard Henderson
Signed-off-by: Gavin Shan
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
[PMD: Constify HPPA machines,
restrict valid_cpu_types to machine_class_init() handlers]
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/boards.h | 2 +-
hw/hppa/machine.c | 22 ++
hw/m68k/q800.c | 11 +--
3 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index a735999298..da85f86efb 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -273,7 +273,7 @@ struct MachineClass {
bool has_hotpluggable_cpus;
bool ignore_memory_transaction_failures;
int numa_mem_align_shift;
-const char **valid_cpu_types;
+const char * const *valid_cpu_types;
strList *allowed_dynamic_sysbus_devices;
bool auto_enable_numa_with_memhp;
bool auto_enable_numa_with_memdev;
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 9d08f39490..c8da7c18d5 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -672,19 +672,18 @@ static void hppa_nmi(NMIState *n, int cpu_index, Error
**errp)
}
}
-static const char *HP_B160L_machine_valid_cpu_types[] = {
-TYPE_HPPA_CPU,
-NULL
-};
-
static void HP_B160L_machine_init_class_init(ObjectClass *oc, void *data)
{
+static const char * const valid_cpu_types[] = {
+TYPE_HPPA_CPU,
+NULL
+};
MachineClass *mc = MACHINE_CLASS(oc);
NMIClass *nc = NMI_CLASS(oc);
mc->desc = "HP B160L workstation";
mc->default_cpu_type = TYPE_HPPA_CPU;
-mc->valid_cpu_types = HP_B160L_machine_valid_cpu_types;
+mc->valid_cpu_types = valid_cpu_types;
mc->init = machine_HP_B160L_init;
mc->reset = hppa_machine_reset;
mc->block_default_type = IF_SCSI;
@@ -709,19 +708,18 @@ static const TypeInfo HP_B160L_machine_init_typeinfo = {
},
};
-static const char *HP_C3700_machine_valid_cpu_types[] = {
-TYPE_HPPA64_CPU,
-NULL
-};
-
static void HP_C3700_machine_init_class_init(ObjectClass *oc, void *data)
{
+static const char * const valid_cpu_types[] = {
+TYPE_HPPA64_CPU,
+NULL
+};
MachineClass *mc = MACHINE_CLASS(oc);
NMIClass *nc = NMI_CLASS(oc);
mc->desc = "HP C3700 workstation";
mc->default_cpu_type = TYPE_HPPA64_CPU;
-mc->valid_cpu_types = HP_C3700_machine_valid_cpu_types;
+mc->valid_cpu_types = valid_cpu_types;
mc->init = machine_HP_C3700_init;
mc->reset = hppa_machine_reset;
mc->block_default_type = IF_SCSI;
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 1d7cd5ff1c..83d1571d02 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -726,19 +726,18 @@ static GlobalProperty hw_compat_q800[] = {
};
static const size_t hw_compat_q800_len = G_N_ELEMENTS(hw_compat_q800);
-static const char *q800_machine_valid_cpu_types[] = {
-M68K_CPU_TYPE_NAME("m68040"),
-NULL
-};
-
static void q800_machine_class_init(ObjectClass *oc, void *data)
{
+static const char * const valid_cpu_types[] = {
+M68K_CPU_TYPE_NAME("m68040"),
+NULL
+};
MachineClass *mc = MACHINE_CLASS(oc);
mc->desc = "Macintosh Quadra 800";
mc->init = q800_machine_init;
mc->default_cpu_type = M68K_CPU_TYPE_NAME("m68040");
-mc->valid_cpu_types = q800_machine_valid_cpu_types;
+mc->valid_cpu_types = valid_cpu_types;
mc->max_cpus = 1;
mc->block_default_type = IF_SCSI;
mc->default_ram_id = "m68k_mac.ram";
--
2.41.0
[PATCH-for-8.2? v2 0/4] hw/arm/stm32xxx: Report error when incorrect CPU is used
Series fully reviewed. Hi, While reviewing this [*] series from Arnaud and Inès, I realized STM32 based boards don't check the requested CPU type is correct, and ignore it. Possibly confusing users. Since these simple boards code is used as template, I took the opportunity to sanitize it a bit, using the MachineClass::valid_cpu_types which seems simpler (to me) for newcomers. Patches are candidate for 8.2 but this is a long standing issue, not a regression from 8.1. Regards, Phil. [*] https://lore.kernel.org/qemu-devel/170003673257.14701.813906180271612010...@git.sr.ht/ Gavin Shan (1): hw/core/machine: Constify MachineClass::valid_cpu_types[] Philippe Mathieu-Daudé (3): hw/arm/stm32f405: Report error when incorrect CPU is used hw/arm/stm32f205: Report error when incorrect CPU is used hw/arm/stm32f100: Report error when incorrect CPU is used include/hw/arm/stm32f100_soc.h | 4 include/hw/arm/stm32f205_soc.h | 4 include/hw/arm/stm32f405_soc.h | 4 include/hw/boards.h| 2 +- hw/arm/netduino2.c | 7 ++- hw/arm/netduinoplus2.c | 7 ++- hw/arm/olimex-stm32-h405.c | 8 ++-- hw/arm/stm32f100_soc.c | 9 ++--- hw/arm/stm32f205_soc.c | 9 ++--- hw/arm/stm32f405_soc.c | 8 +--- hw/arm/stm32vldiscovery.c | 7 ++- hw/hppa/machine.c | 22 ++ hw/m68k/q800.c | 11 +-- 13 files changed, 45 insertions(+), 57 deletions(-) -- 2.41.0
[PATCH-for-8.2? v2 2/4] hw/arm/stm32f405: Report error when incorrect CPU is used
Both 'netduinoplus2' and 'olimex-stm32-h405' machines ignore the
CPU type requested by the command line. This might confuse users,
since the following will create a machine with a Cortex-M4 CPU:
$ qemu-system-aarch64 -M netduinoplus2 -cpu cortex-r5f
Set the MachineClass::valid_cpu_types field (introduced in commit
c9cf636d48 "machine: Add a valid_cpu_types property").
Remove the now unused MachineClass::default_cpu_type field.
We now get:
$ qemu-system-aarch64 -M netduinoplus2 -cpu cortex-r5f
qemu-system-aarch64: Invalid CPU type: cortex-r5f-arm-cpu
The valid types are: cortex-m4-arm-cpu
Since the SoC family can only use Cortex-M4 CPUs, hard-code the
CPU type name at the SoC level, removing the QOM property
entirely.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/stm32f405_soc.h | 4
hw/arm/netduinoplus2.c | 7 ++-
hw/arm/olimex-stm32-h405.c | 8 ++--
hw/arm/stm32f405_soc.c | 8 +---
4 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/include/hw/arm/stm32f405_soc.h b/include/hw/arm/stm32f405_soc.h
index c968ce3ab2..d15c03c4b5 100644
--- a/include/hw/arm/stm32f405_soc.h
+++ b/include/hw/arm/stm32f405_soc.h
@@ -51,11 +51,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(STM32F405State, STM32F405_SOC)
#define CCM_SIZE (64 * 1024)
struct STM32F405State {
-/*< private >*/
SysBusDevice parent_obj;
-/*< public >*/
-
-char *cpu_type;
ARMv7MState armv7m;
diff --git a/hw/arm/netduinoplus2.c b/hw/arm/netduinoplus2.c
index 515c081605..2e58984947 100644
--- a/hw/arm/netduinoplus2.c
+++ b/hw/arm/netduinoplus2.c
@@ -44,7 +44,6 @@ static void netduinoplus2_init(MachineState *machine)
clock_set_hz(sysclk, SYSCLK_FRQ);
dev = qdev_new(TYPE_STM32F405_SOC);
-qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m4"));
qdev_connect_clock_in(dev, "sysclk", sysclk);
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
@@ -55,8 +54,14 @@ static void netduinoplus2_init(MachineState *machine)
static void netduinoplus2_machine_init(MachineClass *mc)
{
+static const char * const valid_cpu_types[] = {
+ARM_CPU_TYPE_NAME("cortex-m4"),
+NULL
+};
+
mc->desc = "Netduino Plus 2 Machine (Cortex-M4)";
mc->init = netduinoplus2_init;
+mc->valid_cpu_types = valid_cpu_types;
}
DEFINE_MACHINE("netduinoplus2", netduinoplus2_machine_init)
diff --git a/hw/arm/olimex-stm32-h405.c b/hw/arm/olimex-stm32-h405.c
index 3aa61c91b7..d793de7c97 100644
--- a/hw/arm/olimex-stm32-h405.c
+++ b/hw/arm/olimex-stm32-h405.c
@@ -47,7 +47,6 @@ static void olimex_stm32_h405_init(MachineState *machine)
clock_set_hz(sysclk, SYSCLK_FRQ);
dev = qdev_new(TYPE_STM32F405_SOC);
-qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m4"));
qdev_connect_clock_in(dev, "sysclk", sysclk);
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
@@ -58,9 +57,14 @@ static void olimex_stm32_h405_init(MachineState *machine)
static void olimex_stm32_h405_machine_init(MachineClass *mc)
{
+static const char * const valid_cpu_types[] = {
+ARM_CPU_TYPE_NAME("cortex-m4"),
+NULL
+};
+
mc->desc = "Olimex STM32-H405 (Cortex-M4)";
mc->init = olimex_stm32_h405_init;
-mc->default_cpu_type = ARM_CPU_TYPE_NAME("cortex-m4");
+mc->valid_cpu_types = valid_cpu_types;
/* SRAM pre-allocated as part of the SoC instantiation */
mc->default_ram_size = 0;
diff --git a/hw/arm/stm32f405_soc.c b/hw/arm/stm32f405_soc.c
index cef23d7ee4..a65bbe298d 100644
--- a/hw/arm/stm32f405_soc.c
+++ b/hw/arm/stm32f405_soc.c
@@ -149,7 +149,7 @@ static void stm32f405_soc_realize(DeviceState *dev_soc,
Error **errp)
armv7m = DEVICE(>armv7m);
qdev_prop_set_uint32(armv7m, "num-irq", 96);
-qdev_prop_set_string(armv7m, "cpu-type", s->cpu_type);
+qdev_prop_set_string(armv7m, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m4"));
qdev_prop_set_bit(armv7m, "enable-bitband", true);
qdev_connect_clock_in(armv7m, "cpuclk", s->sysclk);
qdev_connect_clock_in(armv7m, "refclk", s->refclk);
@@ -287,17 +287,11 @@ static void stm32f405_soc_realize(DeviceState *dev_soc,
Error **errp)
create_unimplemented_device("RNG", 0x50060800, 0x400);
}
-static Property stm32f405_soc_properties[] = {
-DEFINE_PROP_STRING("cpu-type", STM32F405State, cpu_type),
-DEFINE_PROP_END_OF_LIST(),
-};
-
static void stm32f405_soc_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
dc->realize = stm32f405_soc_realize;
-device_class_set_props(dc, stm32f405_soc_properties);
/* No vmstate or reset required: device has no internal state */
}
--
2.41.0
[PATCH-for-8.2? v2 3/4] hw/arm/stm32f205: Report error when incorrect CPU is used
The 'netduino2' machine ignores the CPU type requested by the
command line. This might confuse users, since the following will
create a machine with a Cortex-M3 CPU:
$ qemu-system-arm -M netduino2 -cpu cortex-a9
Set the MachineClass::valid_cpu_types field (introduced in commit
c9cf636d48 "machine: Add a valid_cpu_types property").
Remove the now unused MachineClass::default_cpu_type field.
We now get:
$ qemu-system-arm -M netduino2 -cpu cortex-a9
qemu-system-arm: Invalid CPU type: cortex-a9-arm-cpu
The valid types are: cortex-m3-arm-cpu
Since the SoC family can only use Cortex-M3 CPUs, hard-code the
CPU type name at the SoC level, removing the QOM property
entirely.
Reviewed-by: Richard Henderson
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/arm/stm32f205_soc.h | 4
hw/arm/netduino2.c | 7 ++-
hw/arm/stm32f205_soc.c | 9 ++---
3 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/include/hw/arm/stm32f205_soc.h b/include/hw/arm/stm32f205_soc.h
index 5a4f776264..4f4c8bbebc 100644
--- a/include/hw/arm/stm32f205_soc.h
+++ b/include/hw/arm/stm32f205_soc.h
@@ -49,11 +49,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(STM32F205State, STM32F205_SOC)
#define SRAM_SIZE (128 * 1024)
struct STM32F205State {
-/*< private >*/
SysBusDevice parent_obj;
-/*< public >*/
-
-char *cpu_type;
ARMv7MState armv7m;
diff --git a/hw/arm/netduino2.c b/hw/arm/netduino2.c
index 83753d53a3..501f63a77f 100644
--- a/hw/arm/netduino2.c
+++ b/hw/arm/netduino2.c
@@ -44,7 +44,6 @@ static void netduino2_init(MachineState *machine)
clock_set_hz(sysclk, SYSCLK_FRQ);
dev = qdev_new(TYPE_STM32F205_SOC);
-qdev_prop_set_string(dev, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
qdev_connect_clock_in(dev, "sysclk", sysclk);
sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
@@ -54,8 +53,14 @@ static void netduino2_init(MachineState *machine)
static void netduino2_machine_init(MachineClass *mc)
{
+static const char * const valid_cpu_types[] = {
+ARM_CPU_TYPE_NAME("cortex-m3"),
+NULL
+};
+
mc->desc = "Netduino 2 Machine (Cortex-M3)";
mc->init = netduino2_init;
+mc->valid_cpu_types = valid_cpu_types;
mc->ignore_memory_transaction_failures = true;
}
diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
index c6b75a381d..1a548646f6 100644
--- a/hw/arm/stm32f205_soc.c
+++ b/hw/arm/stm32f205_soc.c
@@ -127,7 +127,7 @@ static void stm32f205_soc_realize(DeviceState *dev_soc,
Error **errp)
armv7m = DEVICE(>armv7m);
qdev_prop_set_uint32(armv7m, "num-irq", 96);
-qdev_prop_set_string(armv7m, "cpu-type", s->cpu_type);
+qdev_prop_set_string(armv7m, "cpu-type", ARM_CPU_TYPE_NAME("cortex-m3"));
qdev_prop_set_bit(armv7m, "enable-bitband", true);
qdev_connect_clock_in(armv7m, "cpuclk", s->sysclk);
qdev_connect_clock_in(armv7m, "refclk", s->refclk);
@@ -201,17 +201,12 @@ static void stm32f205_soc_realize(DeviceState *dev_soc,
Error **errp)
}
}
-static Property stm32f205_soc_properties[] = {
-DEFINE_PROP_STRING("cpu-type", STM32F205State, cpu_type),
-DEFINE_PROP_END_OF_LIST(),
-};
-
static void stm32f205_soc_class_init(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
dc->realize = stm32f205_soc_realize;
-device_class_set_props(dc, stm32f205_soc_properties);
+/* No vmstate or reset required: device has no internal state */
}
static const TypeInfo stm32f205_soc_info = {
--
2.41.0
[PATCH-for-8.2] target/nios2: Deprecate the Nios II architecture
See commit 9ba1caf510 ("MAINTAINERS: Mark the Nios II CPU as orphan"),
last contribution from Chris was in 2012 [1] and Marek in 2018 [2].
[1]
https://lore.kernel.org/qemu-devel/1352607539-10455-2-git-send-email-crwu...@gmail.com/
[2]
https://lore.kernel.org/qemu-devel/805fc7b5-03f0-56d4-abfd-ed010d4fa...@denx.de/
Signed-off-by: Philippe Mathieu-Daudé
---
docs/about/deprecated.rst | 15 +++
hw/nios2/10m50_devboard.c | 1 +
hw/nios2/generic_nommu.c | 1 +
3 files changed, 17 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 78550c07bf..f7aa556294 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -236,6 +236,16 @@ it. Since all recent x86 hardware from the past >10 years
is capable of the
64-bit x86 extensions, a corresponding 64-bit OS should be used instead.
+System emulator CPUs
+
+
+Nios II CPU (since 8.2)
+'''
+
+The Nios II architecture is orphan. The ``nios2`` guest CPU support is
+deprecated and will be removed in a future version of QEMU.
+
+
System emulator machines
@@ -254,6 +264,11 @@ These old machine types are quite neglected nowadays and
thus might have
various pitfalls with regards to live migration. Use a newer machine type
instead.
+Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2)
+'''
+
+The Nios II architecture is orphan.
+
Backend options
---
diff --git a/hw/nios2/10m50_devboard.c b/hw/nios2/10m50_devboard.c
index 952a0dc33e..6cb32f777b 100644
--- a/hw/nios2/10m50_devboard.c
+++ b/hw/nios2/10m50_devboard.c
@@ -160,6 +160,7 @@ static void nios2_10m50_ghrd_class_init(ObjectClass *oc,
void *data)
mc->desc = "Altera 10M50 GHRD Nios II design";
mc->init = nios2_10m50_ghrd_init;
mc->is_default = true;
+mc->deprecation_reason = "Nios II architecture is deprecated";
object_class_property_add_bool(oc, "vic", get_vic, set_vic);
object_class_property_set_description(oc, "vic",
diff --git a/hw/nios2/generic_nommu.c b/hw/nios2/generic_nommu.c
index 48edb3ae37..defa16953f 100644
--- a/hw/nios2/generic_nommu.c
+++ b/hw/nios2/generic_nommu.c
@@ -95,6 +95,7 @@ static void nios2_generic_nommu_machine_init(struct
MachineClass *mc)
{
mc->desc = "Generic NOMMU Nios II design";
mc->init = nios2_generic_nommu_init;
+mc->deprecation_reason = "Nios II architecture is deprecated";
}
DEFINE_MACHINE("nios2-generic-nommu", nios2_generic_nommu_machine_init);
--
2.41.0
Re: [PATCH] linux-headers: Synchronize linux headers from linux v6.7.0-rc1
On 2023/11/17 下午2:35, Cédric Le Goater wrote: Hello, On 11/17/23 02:14, maobibo wrote: Thomas, Linux 6.7-rc1 has already released, LoongArch KVM is supported in this version. LoongArch qemu KVM function depends on linux-headers and I do not know whether LoongArch qemu KVM can be merged in 8.2 cycle. It's too late for 8.2. See https://wiki.qemu.org/Planning/8.2. Got it, and thanks for the clarification. Regards Bibo Mao Thanks, C. Regards Bibo Mao On 2023/11/16 下午9:19, Thomas Huth wrote: On 15/11/2023 11.07, gaosong wrote: Hi, Can this patch be merged in during the 8.2 cycle? Hi! We normally do linux-headers updates along with the patches that need the new definitions ... so is there an urgent reason to push this stand-alone patch into 8.2 without any patches that require these new definitions? Thomas
Re: [PATCH] linux-headers: Synchronize linux headers from linux v6.7.0-rc1
On 17/11/2023 02.14, maobibo wrote: Thomas, Linux 6.7-rc1 has already released, LoongArch KVM is supported in this version. LoongArch qemu KVM function depends on linux-headers and I do not know whether LoongArch qemu KVM can be merged in 8.2 cycle. QEMU is in hard freeze now, see: https://wiki.qemu.org/Planning/8.2 That means, only bug fixes now, no new features will be merged until 8.2 has been released. Thomas On 2023/11/16 下午9:19, Thomas Huth wrote: On 15/11/2023 11.07, gaosong wrote: Hi, Can this patch be merged in during the 8.2 cycle? Hi! We normally do linux-headers updates along with the patches that need the new definitions ... so is there an urgent reason to push this stand-alone patch into 8.2 without any patches that require these new definitions? Thomas
Re: [PATCH] linux-headers: Synchronize linux headers from linux v6.7.0-rc1
Hello, On 11/17/23 02:14, maobibo wrote: Thomas, Linux 6.7-rc1 has already released, LoongArch KVM is supported in this version. LoongArch qemu KVM function depends on linux-headers and I do not know whether LoongArch qemu KVM can be merged in 8.2 cycle. It's too late for 8.2. See https://wiki.qemu.org/Planning/8.2. Thanks, C. Regards Bibo Mao On 2023/11/16 下午9:19, Thomas Huth wrote: On 15/11/2023 11.07, gaosong wrote: Hi, Can this patch be merged in during the 8.2 cycle? Hi! We normally do linux-headers updates along with the patches that need the new definitions ... so is there an urgent reason to push this stand-alone patch into 8.2 without any patches that require these new definitions? Thomas
RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: ltaylorsimp...@gmail.com
> Sent: Thursday, November 16, 2023 1:19 PM
> To: Brian Cain ; qemu-devel@nongnu.org
> Cc: Matheus Bernardino (QUIC) ; Sid Manning
> ; richard.hender...@linaro.org; phi...@linaro.org;
> a...@rev.ng; a...@rev.ng
> Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> oriented
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> > -Original Message-
> > From: Brian Cain
> > Sent: Thursday, November 16, 2023 10:25 AM
> > To: ltaylorsimp...@gmail.com; qemu-devel@nongnu.org
> > Cc: Matheus Bernardino (QUIC) ; Sid
> > Manning ; richard.hender...@linaro.org;
> > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> > oriented
> >
> >
> >
> > > -Original Message-
> > > From: ltaylorsimp...@gmail.com
> > > Sent: Wednesday, November 15, 2023 4:03 PM
> > > To: Brian Cain ; qemu-devel@nongnu.org
> > > Cc: Matheus Bernardino (QUIC) ; Sid
> > Manning
> > > ; richard.hender...@linaro.org;
> > > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > object oriented
> > >
> > > > -Original Message-
> > > > From: Brian Cain
> > > > Sent: Wednesday, November 15, 2023 1:51 PM
> > > > To: Taylor Simpson ; qemu-
> > de...@nongnu.org
> > > > Cc: Matheus Bernardino (QUIC) ; Sid
> > > > Manning ; richard.hender...@linaro.org;
> > > > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > > > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > > object oriented
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Taylor Simpson
> > > > > Sent: Thursday, November 9, 2023 3:26 PM
> > > > > To: qemu-devel@nongnu.org
> > > > > Cc: Brian Cain ; Matheus Bernardino (QUIC)
> > > > > ; Sid Manning ;
> > > > > richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng;
> > > > a...@rev.ng;
> > > > > ltaylorsimp...@gmail.com
> > > > > Subject: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > > > object oriented
> > > > >
> > > > > RFC - This patch handles gen_tcg_funcs.py. I'd like to get
> > > > > comments on the general approach before working on the other
> > Python scripts.
> > > > >
> > > > > The generators are generally a bunch of Python if-then-else
> > > > > statements based on the regtype and regid. Encapsulate
> > > > > regtype/regid into a class hierarchy. Clients lookup the register
> > > > > and invoke methods.
> > > > >
> > > > > This has several advantages for making the code easier to read,
> > > > > understand, and maintain
> > > > > - The class name makes it more clear what the operand does
> > > > > - All the methods for a given type of operand are together
> > > > > - Don't need as many calls to hex_common.bad_register
> > > > > - We can remove the functions in hex_common that use regtype/regid
> > > > > (e.g., is_read)
> > > > >
> > > > > Signed-off-by: Taylor Simpson
> > > > > ---
> > > > > diff --git a/target/hexagon/hex_common.py
> > > > b/target/hexagon/hex_common.py
> > > > > index 0da65d6dd6..13ee55b6b2 100755
> > > > > --- a/target/hexagon/hex_common.py
> > > > > +++ b/target/hexagon/hex_common.py
> > > > > +class PredReadWrite(ReadWrite):
> > > > > +def genptr_decl(self, f, tag, regno):
> > > > > +f.write(f"const int {self.regN} =
> > > > > insn->regno[{regno}];\n")
> > > > > +f.write(f"TCGv {self.regV} = tcg_temp_new();\n")
> > > > > +f.write(f"tcg_gen_mov_tl({self.regV},
> > hex_pred[{self.regN}]);\n")
> > > >
> > > > Instead of successive calls to f.write(), each passing their own
> > > > string with a newline, use triple quotes:
> > > >
> > > > f.write(f"""const int {self.regN} = insn->regno[{regno}];
> > > > TCGv {self.regV} = tcg_temp_new();
> > > > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n""")
> > > >
> > > > If necessary/appropriate, you can also use textwrap.dedent() to make
> > > > the leading whitespace look appropriate:
> > > > https://docs.python.org/3/library/textwrap.html#textwrap.dedent
> > > >
> > > > import textwrap
> > > > ...
> > > > f.write(textwrap.dedent(f"""const int {self.regN} = insn-
> > >regno[{regno}];
> > > > TCGv {self.regV} = tcg_temp_new();
> > > > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n"""))
> > > >
> > >
> > > The indenting is for the readability of the output. We could dedent
> > > everything and run the result through the indent utility as
> > > idef-parser does. Not sure it's worth it though.
> >
> > Regardless of textwrap.dedent(), I think the output is most readable with
> > triple-quotes. It's more readable than it is with multiple f.write("this
> > line\n")
> > invocations.
> >
> > The intent of calling textwrap.dedent is to allow you to not out-dent the
> > text
> > in the python program.
[PATCH v2] arm/kvm: Enable support for KVM_ARM_VCPU_PMU_V3_FILTER
The KVM_ARM_VCPU_PMU_V3_FILTER provide the ability to let the VMM decide
which PMU events are provided to the guest. Add a new option
`pmu-filter` as -accel sub-option to set the PMU Event Filtering.
The `pmu-filter` has such format:
pmu-filter="{A,D}:start-end[;{A,D}:start-end...]"
The A means "allow" and D means "deny", start is the first event of the
range and the end is the last one. The first filter action defines if the whole
event list is an allow or deny list, if the first filter action is "allow", all
other events are denied except start-end; if the first filter action is "deny",
all other events are allowed except start-end. For example:
pmu-filter="A:0x11-0x11;A:0x23-0x3a,D:0x30-0x30"
This will allow event 0x11 (The cycle counter), events 0x23 to 0x3a is
also allowed except the event 0x30 is denied, and all the other events
are disallowed.
Here is an real example shows how to use the PMU Event Filtering, when
we launch a guest by use kvm, add such command line:
# qemu-system-aarch64 \
-accel kvm,pmu-filter="D:0x11-0x11"
And then in guest, use the perf to count the cycle:
# perf stat sleep 1
Performance counter stats for 'sleep 1':
1.22 msec task-clock #0.001 CPUs
utilized
1 context-switches # 820.695 /sec
0 cpu-migrations #0.000 /sec
55 page-faults # 45.138 K/sec
cycles
1128954 instructions
227031 branches # 186.323 M/sec
8686 branch-misses#3.83% of all
branches
1.002492480 seconds time elapsed
0.001752000 seconds user
0.0 seconds sys
As we can see, the cycle counter has been disabled in the guest, but
other pmu events are still work.
Signed-off-by: Shaoqin Huang
---
v1->v2:
- Add more description for allow and deny meaning in
commit message. [Sebastian]
- Small improvement. [Sebastian]
v1: https://lore.kernel.org/all/20231113081713.153615-1-shahu...@redhat.com/
---
include/sysemu/kvm_int.h | 1 +
qemu-options.hx | 16 +
target/arm/kvm.c | 22 +
target/arm/kvm64.c | 51
4 files changed, 90 insertions(+)
diff --git a/include/sysemu/kvm_int.h b/include/sysemu/kvm_int.h
index fd846394be..8f4601474f 100644
--- a/include/sysemu/kvm_int.h
+++ b/include/sysemu/kvm_int.h
@@ -120,6 +120,7 @@ struct KVMState
uint32_t xen_caps;
uint16_t xen_gnttab_max_frames;
uint16_t xen_evtchn_max_pirq;
+char *kvm_pmu_filter;
};
void kvm_memory_listener_register(KVMState *s, KVMMemoryListener *kml,
diff --git a/qemu-options.hx b/qemu-options.hx
index 42fd09e4de..dd3518092c 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -187,6 +187,7 @@ DEF("accel", HAS_ARG, QEMU_OPTION_accel,
"tb-size=n (TCG translation block cache size)\n"
"dirty-ring-size=n (KVM dirty ring GFN count, default 0)\n"
"eager-split-size=n (KVM Eager Page Split chunk size,
default 0, disabled. ARM only)\n"
+"pmu-filter={A,D}:start-end[;...] (KVM PMU Event Filter,
default no filter. ARM only)\n"
"notify-vmexit=run|internal-error|disable,notify-window=n
(enable notify VM exit and set notify window, x86 only)\n"
"thread=single|multi (enable multi-threaded TCG)\n",
QEMU_ARCH_ALL)
SRST
@@ -259,6 +260,21 @@ SRST
impact on the memory. By default, this feature is disabled
(eager-split-size=0).
+``pmu-filter={A,D}:start-end[;...]``
+KVM implements pmu event filtering to prevent a guest from being able
to
+ sample certain events. It has the following format:
+
+ pmu-filter="{A,D}:start-end[;{A,D}:start-end...]"
+
+ The A means "allow" and D means "deny", start if the first event of the
+ range and the end is the last one. For example:
+
+ pmu-filter="A:0x11-0x11;A:0x23-0x3a,D:0x30-0x30"
+
+ This will allow event 0x11 (The cycle counter), events 0x23 to 0x3a is
+ also allowed except the event 0x30 is denied, and all the other events
+ are disallowed.
+
``notify-vmexit=run|internal-error|disable,notify-window=n``
Enables or disables notify VM exit support on x86 host and specify
the corresponding notify window to trigger the VM exit if enabled.
diff --git a/target/arm/kvm.c b/target/arm/kvm.c
index 7903e2ddde..74796de055 100644
--- a/target/arm/kvm.c
+++ b/target/arm/kvm.c
@@ -1108,6 +1108,21 @@ static void kvm_arch_set_eager_split_size(Object *obj,
Visitor *v,
s->kvm_eager_split_size = value;
}
+static char *kvm_arch_get_pmu_filter(Object *obj, Error **errp)
+{
+KVMState *s =
RE: [PATCH v5 07/11] include/hw/net: Implemented Classes and Masks for GMAC Descriptors
-Original Message-
From: Nabih Estefan
Sent: Saturday, October 28, 2023 1:55 AM
To: peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; CS20 KFTing
; wuhao...@google.com; jasonw...@redhat.com; IS20 Avi
Fishman ; nabiheste...@google.com; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: [PATCH v5 07/11] include/hw/net: Implemented Classes and Masks for
GMAC Descriptors
From: Nabih Estefan Diaz
- Implemeted classes for GMAC Receive and Transmit Descriptors
- Implemented Masks for said descriptors
Change-Id: Id671a69137927e169afc9e610dde8dcd7811f6be
Signed-off-by: Nabih Estefan
---
hw/net/npcm_gmac.c | 183 +++
hw/net/trace-events | 9 ++
include/hw/net/npcm_gmac.h | 2 -
tests/qtest/npcm_gmac-test.c | 2 +-
4 files changed, 150 insertions(+), 46 deletions(-)
diff --git a/hw/net/npcm_gmac.c b/hw/net/npcm_gmac.c index
5ce632858d..6f8109e0ee 100644
--- a/hw/net/npcm_gmac.c
+++ b/hw/net/npcm_gmac.c
@@ -32,7 +32,7 @@
REG32(NPCM_DMA_BUS_MODE, 0x1000)
REG32(NPCM_DMA_XMT_POLL_DEMAND, 0x1004) REG32(NPCM_DMA_RCV_POLL_DEMAND,
0x1008) -REG32(NPCM_DMA_RCV_BASE_ADDR, 0x100c)
+REG32(NPCM_DMA_RX_BASE_ADDR, 0x100c)
REG32(NPCM_DMA_TX_BASE_ADDR, 0x1010)
REG32(NPCM_DMA_STATUS, 0x1014)
REG32(NPCM_DMA_CONTROL, 0x1018)
@@ -91,7 +91,8 @@ REG32(NPCM_GMAC_PTP_TTSR, 0x71c)
#define NPCM_DMA_BUS_MODE_SWR BIT(0)
static const uint32_t npcm_gmac_cold_reset_values[NPCM_GMAC_NR_REGS] = {
-[R_NPCM_GMAC_VERSION] = 0x1037,
+/* Reduce version to 3.2 so that the kernel can enable interrupt. */
+[R_NPCM_GMAC_VERSION] = 0x1032,
[R_NPCM_GMAC_TIMER_CTRL] = 0x03e8,
[R_NPCM_GMAC_MAC0_ADDR_HI]= 0x8000,
[R_NPCM_GMAC_MAC0_ADDR_LO]= 0x,
@@ -125,12 +126,12 @@ static const uint16_t phy_reg_init[] = {
[MII_EXTSTAT] = 0x3000, /* 1000BASTE_T full-duplex capable */
};
-static void npcm_gmac_soft_reset(NPCMGMACState *s)
+static void npcm_gmac_soft_reset(NPCMGMACState *gmac)
{
-memcpy(s->regs, npcm_gmac_cold_reset_values,
+memcpy(gmac->regs, npcm_gmac_cold_reset_values,
NPCM_GMAC_NR_REGS * sizeof(uint32_t));
/* Clear reset bits */
-s->regs[R_NPCM_DMA_BUS_MODE] &= ~NPCM_DMA_BUS_MODE_SWR;
+gmac->regs[R_NPCM_DMA_BUS_MODE] &= ~NPCM_DMA_BUS_MODE_SWR;
}
static void gmac_phy_set_link(NPCMGMACState *s, bool active) @@ -148,11
+149,53 @@ static bool gmac_can_receive(NetClientState *nc)
return true;
}
-static ssize_t gmac_receive(NetClientState *nc, const uint8_t *buf, size_t
len1)
+/*
+ * Function that updates the GMAC IRQ
+ * It find the logical OR of the enabled bits for NIS (if enabled)
+ * It find the logical OR of the enabled bits for AIS (if enabled) */
+static void gmac_update_irq(NPCMGMACState *gmac)
{
-return 0;
+/*
+ * Check if the normal interrupts summery is enabled
+ * if so, add the bits for the summary that are enabled
+ */
+if (gmac->regs[R_NPCM_DMA_INTR_ENA] & gmac->regs[R_NPCM_DMA_STATUS] &
+(NPCM_DMA_INTR_ENAB_NIE_BITS))
+{
+gmac->regs[R_NPCM_DMA_STATUS] |= NPCM_DMA_STATUS_NIS;
+}
+/*
+ * Check if the abnormal interrupts summery is enabled
+ * if so, add the bits for the summary that are enabled
+ */
+if (gmac->regs[R_NPCM_DMA_INTR_ENA] & gmac->regs[R_NPCM_DMA_STATUS] &
+(NPCM_DMA_INTR_ENAB_AIE_BITS))
+{
+gmac->regs[R_NPCM_DMA_STATUS] |= NPCM_DMA_STATUS_AIS;
+}
+
+/* Get the logical OR of both normal and abnormal interrupts */
+int level = !!((gmac->regs[R_NPCM_DMA_STATUS] &
+gmac->regs[R_NPCM_DMA_INTR_ENA] &
+NPCM_DMA_STATUS_NIS) |
+ (gmac->regs[R_NPCM_DMA_STATUS] &
+ gmac->regs[R_NPCM_DMA_INTR_ENA] &
+ NPCM_DMA_STATUS_AIS));
+
+/* Set the IRQ */
+trace_npcm_gmac_update_irq(DEVICE(gmac)->canonical_path,
+ gmac->regs[R_NPCM_DMA_STATUS],
+ gmac->regs[R_NPCM_DMA_INTR_ENA],
+ level);
+qemu_set_irq(gmac->irq, level);
}
+static ssize_t gmac_receive(NetClientState *nc, const uint8_t *buf,
+size_t len) {
+/* Placeholder */
+return 0;
+}
static void gmac_cleanup(NetClientState *nc) {
/* Nothing to do yet. */
@@ -166,7 +209,7 @@ static void gmac_set_link(NetClientState *nc)
gmac_phy_set_link(s, !nc->link_down); }
-static void npcm_gmac_mdio_access(NPCMGMACState *s, uint16_t v)
+static void npcm_gmac_mdio_access(NPCMGMACState *gmac, uint16_t v)
{
bool busy = v & NPCM_GMAC_MII_ADDR_BUSY;
uint8_t is_write;
@@ -183,33 +226,38 @@ static void npcm_gmac_mdio_access(NPCMGMACState *s,
uint16_t v)
if (v & NPCM_GMAC_MII_ADDR_WRITE) {
-data = s->regs[R_NPCM_GMAC_MII_DATA];
+data = gmac->regs[R_NPCM_GMAC_MII_DATA];
/*
Re: [PATCH v2] migration: free 'saddr' since be no longer used
On 2023/11/16 22:19, Juan Quintela wrote:
Zongmin Zhou wrote:
Since socket_parse() will allocate memory for 'saddr',and its value
will pass to 'addr' that allocated by migrate_uri_parse(),
then 'saddr' will no longer used,need to free.
But due to 'saddr->u' is shallow copying the contents of the union,
the members of this union containing allocated strings,and will be used after
that.
So just free 'saddr' itself without doing a deep free on the contents of the
SocketAddress.
Fixes: 72a8192e225c ("migration: convert migration 'uri' into 'MigrateAddress'")
Signed-off-by: Zongmin Zhou
---
migration/migration.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/migration/migration.c b/migration/migration.c
index 28a34c9068..9bdbcdaf49 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -493,6 +493,7 @@ bool migrate_uri_parse(const char *uri, MigrationChannel
**channel,
}
addr->u.socket.type = saddr->type;
addr->u.socket.u = saddr->u;
+g_free(saddr);
} else if (strstart(uri, "file:", NULL)) {
addr->transport = MIGRATION_ADDRESS_TYPE_FILE;
addr->u.file.filename = g_strdup(uri + strlen("file:"));
Once that we are here, can we move the declaration of saddr to this
block, so we are sure that we don't use saddr anywhere?
do you mean to do the changes below at this block?
SocketAddress *saddr = socket_parse(uri, errp);
That sounds good and make it clear that 'saddr' is only used on this block.
As Peter said, putting a comment why we don't use
qapi_free_SocketAddress() will be a good idea.
I have put some comments on patch v2 to explain
why just free 'saddr' itself without doing a deep free on the contents
of the SocketAddress .
Maybe need to explicit clarify why g_free is used instead of
qapi_free_SocketAddress()?
Best regards!
Later, Juan.
[PATCH v2] hw/arm/virt: Allow additions to the generated device tree
At present qemu creates a device tree automatically with the 'virt' generic
virtual platform. This is very convenient in most cases but there is not
much control over what is generated.
Add a way to provide a device tree binary file with additional properties
to add before booting. This provides flexibility for situations where
Linux needs some tweak to operate correctly. It also allows configuration
information to be passed to U-Boot, supporting verified boot, for example.
The term 'merge' is used here to avoid confusion with device tree overlays,
which are a particular type of format.
[resending this as the original patch has gone stale]
Signed-off-by: Simon Glass
---
Changes in v2:
- Rebase to master
docs/system/arm/virt.rst | 13 +++-
hw/arm/virt.c| 135 +++
hw/core/machine.c| 20 ++
include/hw/boards.h | 1 +
qemu-options.hx | 8 +++
system/vl.c | 3 +
6 files changed, 178 insertions(+), 2 deletions(-)
diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index 7c4c80180c..0f63a773f2 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -186,8 +186,17 @@ Hardware configuration information for bare-metal
programming
The ``virt`` board automatically generates a device tree blob ("dtb")
which it passes to the guest. This provides information about the
addresses, interrupt lines and other configuration of the various devices
-in the system. Guest code can rely on and hard-code the following
-addresses:
+in the system.
+
+The optional ``-dtbi`` argument is used to specify a device tree blob to merge
+with this generated device tree, to add any properties required by the guest
but
+not included by qemu. Properties are merged after the generated device tree is
+created, so take precedence over generated properties. This can be useful for
+overriding the ``stdout-path`` for Linux, for example, or to add configuration
+information needed by U-Boot. This is intended for simple nodes and properties
+and does not support use of phandles or device tree overlays.
+
+Guest code can rely on and hard-code the following addresses:
- Flash memory starts at address 0x_
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index be2856c018..fb790a2e24 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -41,6 +41,7 @@
#include "hw/vfio/vfio-calxeda-xgmac.h"
#include "hw/vfio/vfio-amd-xgbe.h"
#include "hw/display/ramfb.h"
+#include
#include "net/net.h"
#include "sysemu/device_tree.h"
#include "sysemu/numa.h"
@@ -320,6 +321,135 @@ static void create_fdt(VirtMachineState *vms)
}
}
+
+/*
+ * From U-Boot v2021.07 (under BSD-2-Clause license)
+ *
+ * This does not use the qemu_fdt interface because that requires node names.
+ * Here we are using offsets.
+ *
+ * overlay_apply_node - Merges a node into the base device tree
+ * @fdt: Base Device Tree blob
+ * @target: Node offset in the base device tree to apply the fragment to
+ * @fdto: Device tree overlay blob
+ * @node: Node offset in the overlay holding the changes to merge
+ *
+ * overlay_apply_node() merges a node into a target base device tree
+ * node pointed.
+ *
+ * This is part of the final step in the device tree overlay
+ * application process, when all the phandles have been adjusted and
+ * resolved and you just have to merge overlay into the base device
+ * tree.
+ *
+ * returns:
+ * 0 on success
+ * Negative error code on failure
+ */
+static int overlay_apply_node(void *fdt, int target, void *fdto, int node)
+{
+int property;
+int subnode;
+
+fdt_for_each_property_offset(property, fdto, node) {
+const char *name;
+const void *prop;
+int prop_len;
+int ret;
+
+prop = fdt_getprop_by_offset(fdto, property, , _len);
+if (prop_len == -FDT_ERR_NOTFOUND) {
+return -FDT_ERR_INTERNAL;
+}
+if (prop_len < 0) {
+return prop_len;
+}
+
+ret = fdt_setprop(fdt, target, name, prop, prop_len);
+if (ret) {
+return ret;
+}
+}
+
+fdt_for_each_subnode(subnode, fdto, node) {
+const char *name = fdt_get_name(fdto, subnode, NULL);
+int nnode;
+int ret;
+
+nnode = fdt_add_subnode(fdt, target, name);
+if (nnode == -FDT_ERR_EXISTS) {
+nnode = fdt_subnode_offset(fdt, target, name);
+if (nnode == -FDT_ERR_NOTFOUND) {
+return -FDT_ERR_INTERNAL;
+}
+}
+
+if (nnode < 0) {
+return nnode;
+}
+
+ret = overlay_apply_node(fdt, nnode, fdto, subnode);
+if (ret) {
+return ret;
+}
+}
+
+return 0;
+}
+
+/* Merge nodes and properties into fdt from fdto */
+static int merge_fdt(void *fdt, void *fdto)
+{
+int err;
+
+err = overlay_apply_node(fdt, 0, fdto, 0);
+if (err) {
+fprintf(stderr, "Device tree error
Re: [PULL 0/2] Net patches
On Fri, Nov 17, 2023 at 12:49 AM David Woodhouse wrote: > > On Tue, 2023-11-14 at 11:09 +0800, Jason Wang wrote: > > The following changes since commit 69680740eafa1838527c90155a7432d51b8ff203: > > > > Merge tag 'qdev-array-prop' of https://repo.or.cz/qemu/kevin into staging > > (2023-11-11 11:23:25 +0800) > > > > are available in the git repository at: > > > > https://github.com/jasowang/qemu.git tags/net-pull-request > > > > for you to fetch changes up to d90014fc337ab77f37285b1a30fd4f545056be0a: > > > > igb: Add Function Level Reset to PF and VF (2023-11-13 15:33:37 +0800) > > Hi Jason, > > I note this doesn't include the net_cleanup() fix from > https://lore.kernel.org/qemu-devel/20231115172723.1161679-2-dw...@infradead.org/ > Yes, it's in the list of patches that need review and it seems fine. > Do you mind if I submit that in a pull request with the other fixes > from that series? I've queued this for rc1. Pull request will be sent no later than 21st. Thanks > > Thanks.
RE: [PATCH v5 06/11] tests/qtest: Creating qtest for GMAC Module
-Original Message-
From: Nabih Estefan
Sent: Saturday, October 28, 2023 1:55 AM
To: peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; CS20 KFTing
; wuhao...@google.com; jasonw...@redhat.com; IS20 Avi
Fishman ; nabiheste...@google.com; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: [PATCH v5 06/11] tests/qtest: Creating qtest for GMAC Module
From: Nabih Estefan Diaz
- Created qtest to check initialization of registers in GMAC Module.
- Implemented test into Build File.
Change-Id: Ib0e07f6dacc1266b62b4926873ccd912250cf89d
Signed-off-by: Nabih Estefan
---
tests/qtest/meson.build | 7 +-
tests/qtest/npcm_gmac-test.c | 209 +++
2 files changed, 211 insertions(+), 5 deletions(-) create mode 100644
tests/qtest/npcm_gmac-test.c
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build index
daec219a32..205c60aadc 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -205,9 +205,6 @@ qtests_arm = \
(config_all_devices.has_key('CONFIG_ASPEED_SOC') ? qtests_aspeed : []) + \
(config_all_devices.has_key('CONFIG_NPCM7XX') ? qtests_npcm7xx : []) + \
(config_all_devices.has_key('CONFIG_GENERIC_LOADER') ? ['hexloader-test'] :
[]) + \
- (config_all_devices.has_key('CONFIG_TPM_TIS_I2C') ? ['tpm-tis-i2c-test'] :
[]) + \
- (config_all_devices.has_key('CONFIG_VEXPRESS') ? ['test-arm-mptimer'] : [])
+ \
- (config_all_devices.has_key('CONFIG_MICROBIT') ? ['microbit-test'] : []) + \
['arm-cpu-features',
'boot-serial-test']
@@ -219,8 +216,8 @@ qtests_aarch64 = \
(config_all_devices.has_key('CONFIG_XLNX_ZYNQMP_ARM') ? ['xlnx-can-test',
'fuzz-xlnx-dp-test'] : []) + \
(config_all_devices.has_key('CONFIG_XLNX_VERSAL') ? ['xlnx-canfd-test'] :
[]) + \
(config_all_devices.has_key('CONFIG_RASPI') ? ['bcm2835-dma-test'] : []) + \
- (config_all.has_key('CONFIG_TCG') and
\
- config_all_devices.has_key('CONFIG_TPM_TIS_I2C') ? ['tpm-tis-i2c-test'] :
[]) + \
+ (config_all_devices.has_key('CONFIG_ASPEED_SOC') ? qtests_aspeed :
+ []) + \
+ (config_all_devices.has_key('CONFIG_NPCM7XX') ? qtests_npcm7xx : [])
+ + \
['arm-cpu-features',
'numa-test',
'boot-serial-test',
diff --git a/tests/qtest/npcm_gmac-test.c b/tests/qtest/npcm_gmac-test.c new
file mode 100644 index 00..77a83c4c58
--- /dev/null
+++ b/tests/qtest/npcm_gmac-test.c
@@ -0,0 +1,209 @@
+/*
+ * QTests for Nuvoton NPCM7xx/8xx GMAC Modules.
+ *
+ * Copyright 2023 Google LLC
+ *
+ * This program is free software; you can redistribute it and/or modify
+it
+ * under the terms of the GNU General Public License as published by
+the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include "qemu/osdep.h"
+#include "libqos/libqos.h"
+
+/* Name of the GMAC Device */
+#define TYPE_NPCM_GMAC "npcm-gmac"
+
+typedef struct GMACModule {
+int irq;
+uint64_t base_addr;
+} GMACModule;
+
+typedef struct TestData {
+const GMACModule *module;
+} TestData;
+
+/* Values extracted from hw/arm/npcm8xx.c */ static const GMACModule
+gmac_module_list[] = {
+{
+.irq= 14,
+.base_addr = 0xf0802000
+},
+{
+.irq= 15,
+.base_addr = 0xf0804000
+},
+{
+.irq= 16,
+.base_addr = 0xf0806000
+},
+{
+.irq= 17,
+.base_addr = 0xf0808000
+}
+};
+
+/* Returns the index of the GMAC module. */ static int
+gmac_module_index(const GMACModule *mod) {
+ptrdiff_t diff = mod - gmac_module_list;
+
+g_assert_true(diff >= 0 && diff < ARRAY_SIZE(gmac_module_list));
+
+return diff;
+}
+
+/* 32-bit register indices. Taken from npcm_gmac.c */ typedef enum
+NPCMRegister {
+/* DMA Registers */
+NPCM_DMA_BUS_MODE = 0x1000,
+NPCM_DMA_XMT_POLL_DEMAND = 0x1004,
+NPCM_DMA_RCV_POLL_DEMAND = 0x1008,
+NPCM_DMA_RCV_BASE_ADDR = 0x100c,
+NPCM_DMA_TX_BASE_ADDR = 0x1010,
+NPCM_DMA_STATUS = 0x1014,
+NPCM_DMA_CONTROL = 0x1018,
+NPCM_DMA_INTR_ENA = 0x101c,
+NPCM_DMA_MISSED_FRAME_CTR = 0x1020,
+NPCM_DMA_HOST_TX_DESC = 0x1048,
+NPCM_DMA_HOST_RX_DESC = 0x104c,
+NPCM_DMA_CUR_TX_BUF_ADDR = 0x1050,
+NPCM_DMA_CUR_RX_BUF_ADDR = 0x1054,
+NPCM_DMA_HW_FEATURE = 0x1058,
+
+/* GMAC Registers */
+NPCM_GMAC_MAC_CONFIG = 0x0,
+NPCM_GMAC_FRAME_FILTER = 0x4,
+NPCM_GMAC_HASH_HIGH = 0x8,
+NPCM_GMAC_HASH_LOW = 0xc,
+NPCM_GMAC_MII_ADDR = 0x10,
+NPCM_GMAC_MII_DATA = 0x14,
+NPCM_GMAC_FLOW_CTRL = 0x18,
+NPCM_GMAC_VLAN_FLAG = 0x1c,
+NPCM_GMAC_VERSION = 0x20,
+NPCM_GMAC_WAKEUP_FILTER = 0x28,
RE: [PATCH v5 05/11] hw/arm: Add GMAC devices to NPCM7XX SoC
-Original Message-
From: CS20 KFTing
Sent: Tuesday, November 14, 2023 4:56 PM
To: Nabih Estefan ; peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; wuhao...@google.com;
jasonw...@redhat.com; IS20 Avi Fishman ; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: RE: [PATCH v5 05/11] hw/arm: Add GMAC devices to NPCM7XX SoC
-Original Message-
From: Nabih Estefan
Sent: Saturday, October 28, 2023 1:55 AM
To: peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; CS20 KFTing
; wuhao...@google.com; jasonw...@redhat.com; IS20 Avi
Fishman ; nabiheste...@google.com; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: [PATCH v5 05/11] hw/arm: Add GMAC devices to NPCM7XX SoC
From: Hao Wu
Change-Id: Ibbb1d7221bb14e75173bf051271e758d640f40c8
Signed-off-by: Hao Wu
Signed-off-by: Nabih Estefan
---
hw/arm/npcm7xx.c | 36 ++--
include/hw/arm/npcm7xx.h | 2 ++
2 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/hw/arm/npcm7xx.c b/hw/arm/npcm7xx.c index c9e87162cb..12e11250e1
100644
--- a/hw/arm/npcm7xx.c
+++ b/hw/arm/npcm7xx.c
@@ -91,6 +91,7 @@ enum NPCM7xxInterrupt {
NPCM7XX_GMAC1_IRQ = 14,
NPCM7XX_EMC1RX_IRQ = 15,
NPCM7XX_EMC1TX_IRQ,
+NPCM7XX_GMAC2_IRQ,
NPCM7XX_MMC_IRQ = 26,
NPCM7XX_PSPI2_IRQ = 28,
NPCM7XX_PSPI1_IRQ = 31,
@@ -234,6 +235,12 @@ static const hwaddr npcm7xx_pspi_addr[] = {
0xf0201000,
};
+/* Register base address for each GMAC Module */ static const hwaddr
+npcm7xx_gmac_addr[] = {
+0xf0802000,
+0xf0804000,
+};
+
static const struct {
hwaddr regs_addr;
uint32_t unconnected_pins;
@@ -462,6 +469,10 @@ static void npcm7xx_init(Object *obj)
object_initialize_child(obj, "pspi[*]", >pspi[i], TYPE_NPCM_PSPI);
}
+for (i = 0; i < ARRAY_SIZE(s->gmac); i++) {
+object_initialize_child(obj, "gmac[*]", >gmac[i], TYPE_NPCM_GMAC);
+}
+
object_initialize_child(obj, "pci-mbox", >pci_mbox,
TYPE_NPCM7XX_PCI_MBOX);
object_initialize_child(obj, "mmc", >mmc, TYPE_NPCM7XX_SDHCI); @@
-695,6 +706,29 @@ static void npcm7xx_realize(DeviceState *dev, Error **errp)
sysbus_connect_irq(sbd, 1, npcm7xx_irq(s, rx_irq));
}
+/*
+ * GMAC Modules. Cannot fail.
+ */
+QEMU_BUILD_BUG_ON(ARRAY_SIZE(npcm7xx_gmac_addr) != ARRAY_SIZE(s->gmac));
+QEMU_BUILD_BUG_ON(ARRAY_SIZE(s->gmac) != 2);
+for (i = 0; i < ARRAY_SIZE(s->gmac); i++) {
+SysBusDevice *sbd = SYS_BUS_DEVICE(>gmac[i]);
+
+/*
+ * The device exists regardless of whether it's connected to a QEMU
+ * netdev backend. So always instantiate it even if there is no
+ * backend.
+ */
+sysbus_realize(sbd, _abort);
+sysbus_mmio_map(sbd, 0, npcm7xx_gmac_addr[i]);
+int irq = i == 0 ? NPCM7XX_GMAC1_IRQ : NPCM7XX_GMAC2_IRQ;
+/*
+ * N.B. The values for the second argument sysbus_connect_irq are
+ * chosen to match the registration order in npcm7xx_emc_realize.
+ */
+sysbus_connect_irq(sbd, 0, npcm7xx_irq(s, irq));
+}
+
/*
* Flash Interface Unit (FIU). Can fail if incorrect number of chip selects
* specified, but this is a programming error.
@@ -765,8 +799,6 @@ static void npcm7xx_realize(DeviceState *dev, Error **errp)
create_unimplemented_device("npcm7xx.siox[2]", 0xf0102000, 4 * KiB);
create_unimplemented_device("npcm7xx.ahbpci", 0xf040, 1 * MiB);
create_unimplemented_device("npcm7xx.mcphy",0xf05f, 64 * KiB);
-create_unimplemented_device("npcm7xx.gmac1",0xf0802000, 8 * KiB);
-create_unimplemented_device("npcm7xx.gmac2",0xf0804000, 8 * KiB);
create_unimplemented_device("npcm7xx.vcd", 0xf081, 64 * KiB);
create_unimplemented_device("npcm7xx.ece", 0xf082, 8 * KiB);
create_unimplemented_device("npcm7xx.vdma", 0xf0822000, 8 * KiB);
diff --git a/include/hw/arm/npcm7xx.h b/include/hw/arm/npcm7xx.h index
cec3792a2e..9e5cf639a2 100644
--- a/include/hw/arm/npcm7xx.h
+++ b/include/hw/arm/npcm7xx.h
@@ -30,6 +30,7 @@
#include "hw/misc/npcm7xx_pwm.h"
#include "hw/misc/npcm7xx_rng.h"
#include "hw/net/npcm7xx_emc.h"
+#include "hw/net/npcm_gmac.h"
#include "hw/nvram/npcm7xx_otp.h"
#include "hw/timer/npcm7xx_timer.h"
#include "hw/ssi/npcm7xx_fiu.h"
@@ -105,6 +106,7 @@ struct NPCM7xxState {
OHCISysBusState ohci;
NPCM7xxFIUState fiu[2];
NPCM7xxEMCState emc[2];
+NPCMGMACState gmac[2];
NPCM7xxPCIMBoxState pci_mbox;
NPCM7xxSDHCIState mmc;
NPCMPSPIState pspi[2];
--
2.42.0.820.g83a721a137-goog
Signed-off-by: Tyrone Ting
Reviewed-by: Tyrone Ting
The
RE: [PATCH v5 04/11] hw/net: Add NPCMXXX GMAC device
-Original Message-
From: CS20 KFTing
Sent: Tuesday, November 14, 2023 1:14 PM
To: Nabih Estefan ; peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; wuhao...@google.com;
jasonw...@redhat.com; IS20 Avi Fishman ; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: RE: [PATCH v5 04/11] hw/net: Add NPCMXXX GMAC device
-Original Message-
From: Nabih Estefan
Sent: Saturday, October 28, 2023 1:55 AM
To: peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; CS20 KFTing
; wuhao...@google.com; jasonw...@redhat.com; IS20 Avi
Fishman ; nabiheste...@google.com; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: [PATCH v5 04/11] hw/net: Add NPCMXXX GMAC device
CAUTION - External Email: Do not click links or open attachments unless you
acknowledge the sender and content.
From: Hao Wu
This patch implements the basic registers of GMAC device and sets registers for
networking functionalities.
Tested:
The following message shows up with the change:
Broadcom BCM54612E stmmac-0:00: attached PHY driver [Broadcom BCM54612E]
(mii_bus:phy_addr=stmmac-0:00, irq=POLL) stmmaceth f0802000.eth eth0: Link is
Up - 1Gbps/Full - flow control rx/tx
Change-Id: I9d9ad2533eb6b9bdc6979e6d823aea3a4dd052fa
Signed-off-by: Hao Wu
Signed-off-by: Nabih Estefan Diaz
---
hw/net/meson.build | 2 +-
hw/net/npcm_gmac.c | 395 +
hw/net/trace-events| 11 ++
include/hw/net/npcm_gmac.h | 170
4 files changed, 577 insertions(+), 1 deletion(-) create mode 100644
hw/net/npcm_gmac.c create mode 100644 include/hw/net/npcm_gmac.h
diff --git a/hw/net/meson.build b/hw/net/meson.build index
2632634df3..8389a134d5 100644
--- a/hw/net/meson.build
+++ b/hw/net/meson.build
@@ -38,7 +38,7 @@ system_ss.add(when: 'CONFIG_I82596_COMMON', if_true:
files('i82596.c'))
system_ss.add(when: 'CONFIG_SUNHME', if_true: files('sunhme.c'))
system_ss.add(when: 'CONFIG_FTGMAC100', if_true: files('ftgmac100.c'))
system_ss.add(when: 'CONFIG_SUNGEM', if_true: files('sungem.c'))
-system_ss.add(when: 'CONFIG_NPCM7XX', if_true: files('npcm7xx_emc.c'))
+system_ss.add(when: 'CONFIG_NPCM7XX', if_true: files('npcm7xx_emc.c',
+'npcm_gmac.c'))
system_ss.add(when: 'CONFIG_ETRAXFS', if_true: files('etraxfs_eth.c'))
system_ss.add(when: 'CONFIG_COLDFIRE', if_true: files('mcf_fec.c')) diff --git
a/hw/net/npcm_gmac.c b/hw/net/npcm_gmac.c new file mode 100644 index
00..5ce632858d
--- /dev/null
+++ b/hw/net/npcm_gmac.c
@@ -0,0 +1,395 @@
+/*
+ * Nuvoton NPCM7xx/8xx GMAC Module
+ *
+ * Copyright 2022 Google LLC
+ *
+ * This program is free software; you can redistribute it and/or modify
+it
+ * under the terms of the GNU General Public License as published by
+the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * Unsupported/unimplemented features:
+ * - MII is not implemented, MII_ADDR.BUSY and MII_DATA always return
+zero
+ * - Precision timestamp (PTP) is not implemented.
+ */
+
+#include "qemu/osdep.h"
+
+#include "hw/registerfields.h"
+#include "hw/net/mii.h"
+#include "hw/net/npcm_gmac.h"
+#include "migration/vmstate.h"
+#include "qemu/log.h"
+#include "qemu/units.h"
+#include "sysemu/dma.h"
+#include "trace.h"
+
+REG32(NPCM_DMA_BUS_MODE, 0x1000)
+REG32(NPCM_DMA_XMT_POLL_DEMAND, 0x1004) REG32(NPCM_DMA_RCV_POLL_DEMAND,
+0x1008) REG32(NPCM_DMA_RCV_BASE_ADDR, 0x100c)
+REG32(NPCM_DMA_TX_BASE_ADDR, 0x1010) REG32(NPCM_DMA_STATUS, 0x1014)
+REG32(NPCM_DMA_CONTROL, 0x1018) REG32(NPCM_DMA_INTR_ENA, 0x101c)
+REG32(NPCM_DMA_MISSED_FRAME_CTR, 0x1020) REG32(NPCM_DMA_HOST_TX_DESC,
+0x1048) REG32(NPCM_DMA_HOST_RX_DESC, 0x104c)
+REG32(NPCM_DMA_CUR_TX_BUF_ADDR, 0x1050) REG32(NPCM_DMA_CUR_RX_BUF_ADDR,
+0x1054) REG32(NPCM_DMA_HW_FEATURE, 0x1058)
+
+REG32(NPCM_GMAC_MAC_CONFIG, 0x0)
+REG32(NPCM_GMAC_FRAME_FILTER, 0x4)
+REG32(NPCM_GMAC_HASH_HIGH, 0x8)
+REG32(NPCM_GMAC_HASH_LOW, 0xc)
+REG32(NPCM_GMAC_MII_ADDR, 0x10)
+REG32(NPCM_GMAC_MII_DATA, 0x14)
+REG32(NPCM_GMAC_FLOW_CTRL, 0x18)
+REG32(NPCM_GMAC_VLAN_FLAG, 0x1c)
+REG32(NPCM_GMAC_VERSION, 0x20)
+REG32(NPCM_GMAC_WAKEUP_FILTER, 0x28)
+REG32(NPCM_GMAC_PMT, 0x2c)
+REG32(NPCM_GMAC_LPI_CTRL, 0x30)
+REG32(NPCM_GMAC_TIMER_CTRL, 0x34)
+REG32(NPCM_GMAC_INT_STATUS, 0x38)
+REG32(NPCM_GMAC_INT_MASK, 0x3c)
+REG32(NPCM_GMAC_MAC0_ADDR_HI, 0x40)
+REG32(NPCM_GMAC_MAC0_ADDR_LO, 0x44)
+REG32(NPCM_GMAC_MAC1_ADDR_HI, 0x48)
+REG32(NPCM_GMAC_MAC1_ADDR_LO, 0x4c)
+REG32(NPCM_GMAC_MAC2_ADDR_HI, 0x50)
+REG32(NPCM_GMAC_MAC2_ADDR_LO, 0x54)
+REG32(NPCM_GMAC_MAC3_ADDR_HI, 0x58)
+REG32(NPCM_GMAC_MAC3_ADDR_LO, 0x5c)
+REG32(NPCM_GMAC_RGMII_STATUS, 0xd8)
+REG32(NPCM_GMAC_WATCHDOG, 0xdc)
RE: [PATCH v5 03/11] hw/misc: Add qtest for NPCM7xx PCI Mailbox
-Original Message-
From: CS20 KFTing
Sent: Tuesday, November 14, 2023 9:24 AM
To: Nabih Estefan ; peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; wuhao...@google.com;
jasonw...@redhat.com; IS20 Avi Fishman ; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: RE: [PATCH v5 03/11] hw/misc: Add qtest for NPCM7xx PCI Mailbox
-Original Message-
From: Nabih Estefan
Sent: Saturday, October 28, 2023 1:55 AM
To: peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; CS20 KFTing
; wuhao...@google.com; jasonw...@redhat.com; IS20 Avi
Fishman ; nabiheste...@google.com; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: [PATCH v5 03/11] hw/misc: Add qtest for NPCM7xx PCI Mailbox
CAUTION - External Email: Do not click links or open attachments unless you
acknowledge the sender and content.
From: Hao Wu
This patches adds a qtest for NPCM7XX PCI Mailbox module.
It sends read and write requests to the module, and verifies that the module
contains the correct data after the requests.
Change-Id: Id7a4b3cbea564383b94d507552dfd16f6b5127d1
Signed-off-by: Hao Wu
Signed-off-by: Nabih Estefan
---
tests/qtest/meson.build | 1 +
tests/qtest/npcm7xx_pci_mbox-test.c | 238
2 files changed, 239 insertions(+)
create mode 100644 tests/qtest/npcm7xx_pci_mbox-test.c
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build index
d6022ebd64..daec219a32 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -183,6 +183,7 @@ qtests_sparc64 = \
qtests_npcm7xx = \
['npcm7xx_adc-test',
'npcm7xx_gpio-test',
+ 'npcm7xx_pci_mbox-test',
'npcm7xx_pwm-test',
'npcm7xx_rng-test',
'npcm7xx_sdhci-test',
diff --git a/tests/qtest/npcm7xx_pci_mbox-test.c
b/tests/qtest/npcm7xx_pci_mbox-test.c
new file mode 100644
index 00..24eec18e3c
--- /dev/null
+++ b/tests/qtest/npcm7xx_pci_mbox-test.c
@@ -0,0 +1,238 @@
+/*
+ * QTests for Nuvoton NPCM7xx PCI Mailbox Modules.
+ *
+ * Copyright 2021 Google LLC
+ *
+ * This program is free software; you can redistribute it and/or modify
+it
+ * under the terms of the GNU General Public License as published by
+the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/bitops.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp/qnum.h"
+#include "libqtest-single.h"
+
+#define PCI_MBOX_BA 0xf0848000
+#define PCI_MBOX_IRQ8
+
+/* register offset */
+#define PCI_MBOX_STAT 0x00
+#define PCI_MBOX_CTL0x04
+#define PCI_MBOX_CMD0x08
+
+#define CODE_OK 0x00
+#define CODE_INVALID_OP 0xa0
+#define CODE_INVALID_SIZE 0xa1
+#define CODE_ERROR 0xff
+
+#define OP_READ 0x01
+#define OP_WRITE0x02
+#define OP_INVALID 0x41
+
+
+static int sock;
+static int fd;
+
+/*
+ * Create a local TCP socket with any port, then save off the port we got.
+ */
+static in_port_t open_socket(void)
+{
+struct sockaddr_in myaddr;
+socklen_t addrlen;
+
+myaddr.sin_family = AF_INET;
+myaddr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
+myaddr.sin_port = 0;
+sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
+g_assert(sock != -1);
+g_assert(bind(sock, (struct sockaddr *) , sizeof(myaddr)) != -1);
+addrlen = sizeof(myaddr);
+g_assert(getsockname(sock, (struct sockaddr *) , ) != -1);
+g_assert(listen(sock, 1) != -1);
+return ntohs(myaddr.sin_port);
+}
+
+static void setup_fd(void)
+{
+fd_set readfds;
+
+FD_ZERO();
+FD_SET(sock, );
+g_assert(select(sock + 1, , NULL, NULL, NULL) == 1);
+
+fd = accept(sock, NULL, 0);
+g_assert(fd >= 0);
+}
+
+static uint8_t read_response(uint8_t *buf, size_t len) {
+uint8_t code;
+ssize_t ret = read(fd, , 1);
+
+if (ret == -1) {
+return CODE_ERROR;
+}
+if (code != CODE_OK) {
+return code;
+}
+g_test_message("response code: %x", code);
+if (len > 0) {
+ret = read(fd, buf, len);
+if (ret < len) {
+return CODE_ERROR;
+}
+}
+return CODE_OK;
+}
+
+static void receive_data(uint64_t offset, uint8_t *buf, size_t len) {
+uint8_t op = OP_READ;
+uint8_t code;
+ssize_t rv;
+
+while (len > 0) {
+uint8_t size;
+
+if (len >= 8) {
+size = 8;
+} else if (len >= 4) {
+size = 4;
+} else if (len >= 2) {
+size = 2;
+} else {
+size = 1;
+}
+
+g_test_message("receiving %u bytes", size);
+/* Write op */
+rv = write(fd, , 1);
RE: [PATCH v5 02/11] hw/arm: Add PCI mailbox module to Nuvoton SoC
-Original Message-
From: CS20 KFTing
Sent: Monday, November 13, 2023 11:49 AM
To: Nabih Estefan ; peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; wuhao...@google.com;
jasonw...@redhat.com; IS20 Avi Fishman ; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: RE: [PATCH v5 02/11] hw/arm: Add PCI mailbox module to Nuvoton SoC
-Original Message-
From: Nabih Estefan
Sent: Saturday, October 28, 2023 1:55 AM
To: peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; CS20 KFTing
; wuhao...@google.com; jasonw...@redhat.com; IS20 Avi
Fishman ; nabiheste...@google.com; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: [PATCH v5 02/11] hw/arm: Add PCI mailbox module to Nuvoton SoC
CAUTION - External Email: Do not click links or open attachments unless you
acknowledge the sender and content.
From: Hao Wu
This patch wires the PCI mailbox module to Nuvoton SoC.
Change-Id: I9421ff6bc7d365b0559c0a1f6b98cfd24b6f2d9f
Signed-off-by: Hao Wu
Signed-off-by: Nabih Estefan
---
docs/system/arm/nuvoton.rst | 2 ++
hw/arm/npcm7xx.c| 3 ++-
include/hw/arm/npcm7xx.h| 1 +
3 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/docs/system/arm/nuvoton.rst b/docs/system/arm/nuvoton.rst index
0424cae4b0..e611099545 100644
--- a/docs/system/arm/nuvoton.rst
+++ b/docs/system/arm/nuvoton.rst
@@ -50,6 +50,8 @@ Supported devices
* Ethernet controller (EMC)
* Tachometer
* Peripheral SPI controller (PSPI)
+ * BIOS POST code FIFO
+ * PCI Mailbox
Missing devices
---
diff --git a/hw/arm/npcm7xx.c b/hw/arm/npcm7xx.c index c69e936669..c9e87162cb
100644
--- a/hw/arm/npcm7xx.c
+++ b/hw/arm/npcm7xx.c
@@ -86,7 +86,6 @@ enum NPCM7xxInterrupt {
NPCM7XX_UART1_IRQ,
NPCM7XX_UART2_IRQ,
NPCM7XX_UART3_IRQ,
-NPCM7XX_PECI_IRQ= 6,
NPCM7XX_PCI_MBOX_IRQ= 8,
NPCM7XX_KCS_HIB_IRQ = 9,
NPCM7XX_GMAC1_IRQ = 14,
@@ -463,6 +462,8 @@ static void npcm7xx_init(Object *obj)
object_initialize_child(obj, "pspi[*]", >pspi[i], TYPE_NPCM_PSPI);
}
+object_initialize_child(obj, "pci-mbox", >pci_mbox,
+TYPE_NPCM7XX_PCI_MBOX);
object_initialize_child(obj, "mmc", >mmc, TYPE_NPCM7XX_SDHCI); }
diff --git a/include/hw/arm/npcm7xx.h b/include/hw/arm/npcm7xx.h index
273090ac60..cec3792a2e 100644
--- a/include/hw/arm/npcm7xx.h
+++ b/include/hw/arm/npcm7xx.h
@@ -105,6 +105,7 @@ struct NPCM7xxState {
OHCISysBusState ohci;
NPCM7xxFIUState fiu[2];
NPCM7xxEMCState emc[2];
+NPCM7xxPCIMBoxState pci_mbox;
NPCM7xxSDHCIState mmc;
NPCMPSPIState pspi[2];
};
--
2.42.0.820.g83a721a137-goog
Signed-off-by: Tyrone Ting
Reviewed-by: Tyrone Ting
The privileged confidential information contained in this email is intended
for use only by the addressees as indicated by the original sender of this
email. If you are not the addressee indicated in this email or are not
responsible for delivery of the email to such a person, please kindly reply to
the sender indicating this fact and delete all copies of it from your computer
and network server immediately. Your cooperation is highly appreciated. It is
advised that any unauthorized use of confidential information of Nuvoton is
strictly prohibited; and any information in this email irrelevant to the
official business of Nuvoton shall be deemed as neither given nor endorsed by
Nuvoton.
RE: [PATCH v5 01/11] hw/misc: Add Nuvoton's PCI Mailbox Module
-Original Message-
From: CS20 KFTing
Sent: Monday, November 13, 2023 10:23 AM
To: Nabih Estefan ; peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; wuhao...@google.com;
jasonw...@redhat.com; IS20 Avi Fishman ; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: RE: [PATCH v5 01/11] hw/misc: Add Nuvoton's PCI Mailbox Module
-Original Message-
From: Nabih Estefan
Sent: Saturday, October 28, 2023 1:55 AM
To: peter.mayd...@linaro.org
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; CS20 KFTing
; wuhao...@google.com; jasonw...@redhat.com; IS20 Avi
Fishman ; nabiheste...@google.com; CS20 KWLiu
; IS20 Tomer Maimon ; IN20 Hila
Miranda-Kuzi
Subject: [PATCH v5 01/11] hw/misc: Add Nuvoton's PCI Mailbox Module
CAUTION - External Email: Do not click links or open attachments unless you
acknowledge the sender and content.
From: Hao Wu
The PCI Mailbox Module is a high-bandwidth communcation module between a
Nuvoton BMC and CPU. It features 16KB RAM that are both accessible by the BMC
and core CPU. and supports interrupt for both sides.
This patch implements the BMC side of the PCI mailbox module.
Communication with the core CPU is emulated via a chardev and will be in a
follow-up patch.
Change-Id: I1eb823c07a0f84973c8b94b303a130b45c458471
Signed-off-by: Hao Wu
Signed-off-by: Nabih Estefan
---
hw/arm/npcm7xx.c | 16 +-
hw/misc/meson.build| 1 +
hw/misc/npcm7xx_pci_mbox.c | 324 +
hw/misc/trace-events | 5 +
include/hw/arm/npcm7xx.h | 1 +
include/hw/misc/npcm7xx_pci_mbox.h | 81
6 files changed, 427 insertions(+), 1 deletion(-) create mode 100644
hw/misc/npcm7xx_pci_mbox.c create mode 100644
include/hw/misc/npcm7xx_pci_mbox.h
diff --git a/hw/arm/npcm7xx.c b/hw/arm/npcm7xx.c index 15ff21d047..c69e936669
100644
--- a/hw/arm/npcm7xx.c
+++ b/hw/arm/npcm7xx.c
@@ -53,6 +53,9 @@
/* ADC Module */
#define NPCM7XX_ADC_BA (0xf000c000)
+/* PCI Mailbox Module */
+#define NPCM7XX_PCI_MBOX_BA (0xf0848000)
+
/* Internal AHB SRAM */
#define NPCM7XX_RAM3_BA (0xc0008000)
#define NPCM7XX_RAM3_SZ (4 * KiB)
@@ -83,6 +86,10 @@ enum NPCM7xxInterrupt {
NPCM7XX_UART1_IRQ,
NPCM7XX_UART2_IRQ,
NPCM7XX_UART3_IRQ,
+NPCM7XX_PECI_IRQ= 6,
+NPCM7XX_PCI_MBOX_IRQ= 8,
+NPCM7XX_KCS_HIB_IRQ = 9,
+NPCM7XX_GMAC1_IRQ = 14,
NPCM7XX_EMC1RX_IRQ = 15,
NPCM7XX_EMC1TX_IRQ,
NPCM7XX_MMC_IRQ = 26,
@@ -706,6 +713,14 @@ static void npcm7xx_realize(DeviceState *dev, Error **errp)
}
}
+/* PCI Mailbox. Cannot fail */
+sysbus_realize(SYS_BUS_DEVICE(>pci_mbox), _abort);
+sysbus_mmio_map(SYS_BUS_DEVICE(>pci_mbox), 0, NPCM7XX_PCI_MBOX_BA);
+sysbus_mmio_map(SYS_BUS_DEVICE(>pci_mbox), 1,
+NPCM7XX_PCI_MBOX_BA + NPCM7XX_PCI_MBOX_RAM_SIZE);
+sysbus_connect_irq(SYS_BUS_DEVICE(>pci_mbox), 0,
+ npcm7xx_irq(s, NPCM7XX_PCI_MBOX_IRQ));
+
/* RAM2 (SRAM) */
memory_region_init_ram(>sram, OBJECT(dev), "ram2",
NPCM7XX_RAM2_SZ, _abort); @@ -765,7 +780,6 @@
static void npcm7xx_realize(DeviceState *dev, Error **errp)
create_unimplemented_device("npcm7xx.usbd[8]", 0xf0838000, 4 * KiB);
create_unimplemented_device("npcm7xx.usbd[9]", 0xf0839000, 4 * KiB);
create_unimplemented_device("npcm7xx.sd", 0xf084, 8 * KiB);
-create_unimplemented_device("npcm7xx.pcimbx", 0xf0848000, 512 * KiB);
create_unimplemented_device("npcm7xx.aes", 0xf0858000, 4 * KiB);
create_unimplemented_device("npcm7xx.des", 0xf0859000, 4 * KiB);
create_unimplemented_device("npcm7xx.sha", 0xf085a000, 4 * KiB);
diff --git a/hw/misc/meson.build b/hw/misc/meson.build index
f60de33f9a..3ee3f2226f 100644
--- a/hw/misc/meson.build
+++ b/hw/misc/meson.build
@@ -73,6 +73,7 @@ system_ss.add(when: 'CONFIG_NPCM7XX', if_true: files(
'npcm7xx_clk.c',
'npcm7xx_gcr.c',
'npcm7xx_mft.c',
+ 'npcm7xx_pci_mbox.c',
'npcm7xx_pwm.c',
'npcm7xx_rng.c',
))
diff --git a/hw/misc/npcm7xx_pci_mbox.c b/hw/misc/npcm7xx_pci_mbox.c new file
mode 100644 index 00..c770ad6fcf
--- /dev/null
+++ b/hw/misc/npcm7xx_pci_mbox.c
@@ -0,0 +1,324 @@
+/*
+ * Nuvoton NPCM7xx PCI Mailbox Module
+ *
+ * Copyright 2021 Google LLC
+ *
+ * This program is free software; you can redistribute it and/or modify
+it
+ * under the terms of the GNU General Public License as published by
+the
+ * Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more
RE: [PATCH v5 03/11] hw/misc: Add qtest for NPCM7xx PCI Mailbox
-Original Message- From: Peter Maydell Sent: Friday, November 17, 2023 12:25 AM To: CS20 KFTing Cc: Nabih Estefan ; qemu-...@nongnu.org; qemu-devel@nongnu.org; wuhao...@google.com; IS20 Avi Fishman ; CS20 KWLiu ; IS20 Tomer Maimon ; IN20 Hila Miranda-Kuzi Subject: Re: [PATCH v5 03/11] hw/misc: Add qtest for NPCM7xx PCI Mailbox On Wed, 15 Nov 2023 at 01:35, kft...@nuvoton.com wrote: > Peter Maydell wrote: > On Tue, 14 Nov 2023 at 01:24, kft...@nuvoton.com wrote: > > Signed-off-by: Tyrone Ting > > Hi; can you clarify what you mean with this Signed-off-by: tag? > Generally we use those where either you're the author of the code or else > when you're taking somebody else's patch and including it in work you are > sending to the list, and it doesn't seem like either of those are the case > here. > Thank you for your comments. In the email thread " [PATCH v4 00/11] > Implementation of NPI Mailbox and GMAC Networking Module", it says " Hi; I'm > afraid this is going to miss the 8.2 release, because it is still missing any > review from Google or Nuvoton people." > > Is it okay to post "Acked by:" or "Reviewed by:" by someone from Nuvoton? If you've reviewed the code and believe it to be good (i.e., it doesn't need any changes), then, yes, by all means please post your Reviewed-by tag. Anybody who has done the work of code review on a patch can send in a Reviewed-by tag to say they've done it. If you've reviewed the code and think there's something that needs to be changed or that you have a question about that, you can reply to the patch to say so. We basically follow the same process here that the Linux kernel does; you can read about the various tags here: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes The meaning of "Acked-by:" is a little more disputed; personally I use that for "I haven't reviewed this code, but as a maintainer of the subsystem I don't object to it". thanks -- PMM Hi: Understood and I'll use the Reviewed-by tag then. Thank you for your advice. Regards, Tyrone The privileged confidential information contained in this email is intended for use only by the addressees as indicated by the original sender of this email. If you are not the addressee indicated in this email or are not responsible for delivery of the email to such a person, please kindly reply to the sender indicating this fact and delete all copies of it from your computer and network server immediately. Your cooperation is highly appreciated. It is advised that any unauthorized use of confidential information of Nuvoton is strictly prohibited; and any information in this email irrelevant to the official business of Nuvoton shall be deemed as neither given nor endorsed by Nuvoton.
Re: [PATCH] linux-headers: Synchronize linux headers from linux v6.7.0-rc1
Thomas, Linux 6.7-rc1 has already released, LoongArch KVM is supported in this version. LoongArch qemu KVM function depends on linux-headers and I do not know whether LoongArch qemu KVM can be merged in 8.2 cycle. Regards Bibo Mao On 2023/11/16 下午9:19, Thomas Huth wrote: On 15/11/2023 11.07, gaosong wrote: Hi, Can this patch be merged in during the 8.2 cycle? Hi! We normally do linux-headers updates along with the patches that need the new definitions ... so is there an urgent reason to push this stand-alone patch into 8.2 without any patches that require these new definitions? Thomas
Re: [PULL v3 09/25] ui/console: allow to override the default VC
On 11/16/23 09:52, Peter Maydell wrote: On Tue, 7 Nov 2023 at 10:24, wrote: From: Marc-André Lureau If a display is backed by a specialized VC, allow to override the default "vc:80Cx24C". As suggested by Paolo, if the display doesn't implement a VC (get_vc() returns NULL), use a fallback that will use a muxed console on stdio. This changes the behaviour of "qemu -display none", to create a muxed serial/monitor by default (on TTY & not daemonized). This breaks existing command line setups -- if I say "-display none" I just mean "don't do a display", not "please also give me a monitor". We already have a "do what I mean" option for "no graphics", which is "-nographic". The advantage of -display none is that it does only and exactly what it says it does. Setups using semihosting for output now get a spurious load of output from the monitor on their terminal. I think we should revert this; I'll send a patch. Yes indeed. I think this may be why I've seen my xterm go into strange i/o modes during "make check-tcg" of the semihosting tests. r~
Re: [PATCH v3 0/9] Enabling DCD emulation support in Qemu
nifan.cxl@ wrote: > From: Fan Ni > > > The patch series are based on Jonathan's branch cxl-2023-09-26. Finally getting around to trying this new series and the patch series does not seem to apply on top of this branch? Just to verify is this the top commit this work was based on? d4edf131bbac [jonathan/cxl-2023-09-26] cxl/vendor: SK hynix Niagara Multi-Headed SLD Device I seem to have found some issue with CDAT checksumming[1] which I'm not quite sure about. I went ahead and pulled your latest work from: https://github.com/moking/qemu-jic-clone.git dcd-dev abe893944bb3 hw/mem/cxl_type3: Add dpa range validation for accesses to dc regions It still has this same problem. Before I dig into this, is this the latest dcd branch? Has anything changed in how you specify DCD devices on the qemu command line with this latest work? Here is what I have: ... -device cxl-type3,bus=hb0rp0,memdev=cxl-mem0,num-dc-regions=2,nonvolatile-dc-memdev=cxl-dc-mem0,id=cxl-dev0,lsa=cxl-lsa0,sn=0 -device cxl-type3,bus=hb0rp1,memdev=cxl-mem1,num-dc-regions=2,nonvolatile-dc-memdev=cxl-dc-mem1,id=cxl-dev1,lsa=cxl-lsa1,sn=1 -device cxl-type3,bus=hb1rp0,memdev=cxl-mem2,num-dc-regions=2,nonvolatile-dc-memdev=cxl-dc-mem2,id=cxl-dev2,lsa=cxl-lsa2,sn=2 -device cxl-type3,bus=hb1rp1,memdev=cxl-mem3,num-dc-regions=2,nonvolatile-dc-memdev=cxl-dc-mem3,id=cxl-dev3,lsa=cxl-lsa3,sn=3 ... Ira [1] https://lore.kernel.org/all/20231116-fix-cdat-devm-free-v1-1-b148b4070...@intel.com/ > The main changes include, > 1. Update cxl_find_dc_region to detect the case the range of the extent cross > multiple DC regions. > 2. Add comments to explain the checks performed in function > cxl_detect_malformed_extent_list. (Jonathan) > 3. Minimize the checks in cmd_dcd_add_dyn_cap_rsp.(Jonathan) > 4. Update total_extent_count in add/release dynamic capacity response > function. > (Ira and Jorgen Hansen). > 5. Fix the logic issue in test_bits and renamed it to > test_any_bits_set to clear its function. > 6. Add pending extent list for dc extent add event. > 7. When add extent response is received, use the pending-to-add list to > verify the extents are valid. > 8. Add test_any_bits_set and cxl_insert_extent_to_extent_list declaration to > cxl_device.h so it can be used in different files. > 9. Updated ct3d_qmp_cxl_event_log_enc to include dynamic capacity event > log type. > 10. Extract the functionality to delete extent from extent list to a helper > function. > 11. Move the update of the bitmap which reflects which blocks are backed with > dc extents from the moment when a dc extent is offered to the moment when it > is accepted from the host. > 12. Free dc_name after calling address_space_init to avoid memory leak when > returning early. (Nathan) > 13. Add code to detect and reject QMP requests without any extents. (Jonathan) > 14. Add code to detect and reject QMP requests where the extent len is 0. > 15. Change the QMP interface and move the region-id out of extents and now > each command only takes care of extent add/release request in a single > region. (Jonathan) > 16. Change the region bitmap length from decode_len to len. > 17. Rename "dpa" to "offset" in the add/release dc extent qmp interface. > (Jonathan) > 18. Block any dc extent release command if the exact extent is not already in > the extent list of the device. > > The code is tested together with Ira's kernel DCD support: > https://github.com/weiny2/linux-kernel/tree/dcd-v3-2023-10-30 > > Cover letter from v2 is here: > https://lore.kernel.org/linux-cxl/20230724162313.34196-1-fan...@samsung.com/T/#m63039621087023691c9749a0af1212deb5549ddf > > Last version (v2) is here: > https://lore.kernel.org/linux-cxl/20230725183939.2741025-1-fan...@samsung.com/ > > More DCD related discussions are here: > https://lore.kernel.org/linux-cxl/650cc29ab3f64_50d07294e7@iweiny-mobl.notmuch/ > > > > Fan Ni (9): > hw/cxl/cxl-mailbox-utils: Add dc_event_log_size field to output > payload of identify memory device command > hw/cxl/cxl-mailbox-utils: Add dynamic capacity region representative > and mailbox command support > include/hw/cxl/cxl_device: Rename mem_size as static_mem_size for > type3 memory devices > hw/mem/cxl_type3: Add support to create DC regions to type3 memory > devices > hw/mem/cxl_type3: Add host backend and address space handling for DC > regions > hw/mem/cxl_type3: Add DC extent list representative and get DC extent > list mailbox support > hw/cxl/cxl-mailbox-utils: Add mailbox commands to support add/release > dynamic capacity response > hw/cxl/events: Add qmp interfaces to add/release dynamic capacity > extents > hw/mem
Re: [PATCH v5 00/31] Unified CPU type check
Hi Phil, On 11/17/23 02:20, Philippe Mathieu-Daudé wrote: On 16/11/23 14:35, Philippe Mathieu-Daudé wrote: I'm queuing patches 1-3 & 5-23 to my cpus-next tree. No need to repost them, please base them on my tree. I'll follow up with the branch link when I finish my testing and push it. Here are these patches queued: https://github.com/philmd/qemu.git branches/cpus-next I might queue more patches before the 9.0 merge window opens. Thanks for queuing these patches, but I don't see 'cpus-next' branch in the repository. Please let me know if I checked out the code properly. $ git clone https://github.com/philmd/qemu.git philmd $ cd philmd $ git branch * staging $ git branch -a | grep cpus-next $ echo $? 1 Thanks, Gavin
Re: [PATCH v5 03/31] cpu: Call object_class_dynamic_cast() once in cpu_class_by_name()
Hi Phil, On 11/17/23 02:08, Philippe Mathieu-Daudé wrote: On 15/11/23 00:56, Gavin Shan wrote: From: Philippe Mathieu-Daudé For all targets, the CPU class returned from CPUClass::class_by_name() and object_class_dynamic_cast(oc, CPU_RESOLVING_TYPE) need to be compatible. Lets apply the check in cpu_class_by_name() for once, instead of having the check in CPUClass::class_by_name() for individual target. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Gavin Shan Reviewed-by: Igor Mammedov Gavin, this patch is missing your S-o-b tag. Do you mind responding to this email with it? Thanks! Yes, please add my s-o-b if you need: Signed-off-by: Gavin Shan Thanks, Gavin --- hw/core/cpu-common.c | 8 +--- target/alpha/cpu.c | 3 --- target/arm/cpu.c | 4 +--- target/avr/cpu.c | 8 +--- target/cris/cpu.c | 4 +--- target/hexagon/cpu.c | 4 +--- target/hppa/cpu.c | 7 +-- target/loongarch/cpu.c | 8 +--- target/m68k/cpu.c | 4 +--- target/openrisc/cpu.c | 4 +--- target/riscv/cpu.c | 4 +--- target/tricore/cpu.c | 4 +--- target/xtensa/cpu.c | 4 +--- 13 files changed, 16 insertions(+), 50 deletions(-)
Re: [PATCH v3 1/8] ppc/pnv: Add pca9552 to powernv10 for PCIe hotplug power control
On Wed, 2023-11-15 at 23:34 +0100, Cédric Le Goater wrote: > On 11/15/23 17:37, Miles Glenn wrote: > > On Wed, 2023-11-15 at 08:28 +0100, Cédric Le Goater wrote: > > > On 11/14/23 20:56, Glenn Miles wrote: > > > > The Power Hypervisor code expects to see a pca9552 device > > > > connected > > > > to the 3rd PNV I2C engine on port 1 at I2C address 0x63 (or > > > > left- > > > > justified address of 0xC6). This is used by hypervisor code to > > > > control PCIe slot power during hotplug events. > > > > > > > > Signed-off-by: Glenn Miles > > > > --- > > > > Based-on: <20231024181144.4045056-3-mil...@linux.vnet.ibm.com> > > > > [PATCH v3 2/2] misc/pca9552: Let external devices set pca9552 > > > > inputs > > > > > > > > No changes from v2 > > > > > > > >hw/ppc/Kconfig | 1 + > > > >hw/ppc/pnv.c | 7 +++ > > > >2 files changed, 8 insertions(+) > > > > > > > > diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig > > > > index 56f0475a8e..f77ca773cf 100644 > > > > --- a/hw/ppc/Kconfig > > > > +++ b/hw/ppc/Kconfig > > > > @@ -32,6 +32,7 @@ config POWERNV > > > >select XIVE > > > >select FDT_PPC > > > >select PCI_POWERNV > > > > +select PCA9552 > > > > > > > >config PPC405 > > > >bool > > > > diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c > > > > index 9c29727337..7afaf1008f 100644 > > > > --- a/hw/ppc/pnv.c > > > > +++ b/hw/ppc/pnv.c > > > > @@ -1877,6 +1877,13 @@ static void > > > > pnv_chip_power10_realize(DeviceState *dev, Error **errp) > > > > qdev_get_gpio_in(DEVICE( > > > > 0- > > > > > psi), > > > > PSIHB9_IRQ_SB > > > > E_I2C > > > > )); > > > >} > > > > + > > > > +/* > > > > + * Add a PCA9552 I2C device for PCIe hotplug control > > > > + * to engine 2, bus 1, address 0x63 > > > > + */ > > > > +i2c_slave_create_simple(chip10->i2c[2].busses[1], > > > > "pca9552", > > > > 0x63); > > > > > > You didn't answer my question in v2. Is this a P10 chip device or > > > a > > > board/machine device ? > > > > > > Thanks, > > > > > > C. > > > > > > > > > > Sorry, you're right, I did miss that one, and after looking at the > > Denali spec, I see that the topology is indeed different from > > Rainier > > (which is what I have been modeling). For the Denali, the PCA9552 > > has a different I2C address (0x62 instead of 0x63) and the GPIO > > connections are also different. Also, there is no PCA9554 chip > > because > > it looks like they were able to cover all of the functionality with > > just the GPIO's of the PCA9552. So, good catch! > > > > I'll look at what they did on the Aspeed machines like you > > suggested. > > It should be a machine class extension with an i2c_setup handler and > a new "powernv10-rainier" machine modeling the board layout. The rest > looks good. > > Please include the pca9552 series in the respin. The pca9554 model > will > need a MAINTAINER (you?) I would be happy to let you take over > pca9552 > if you agree. > > First, let's get patch 3 and 4 in QEMU 8.2. > > Thanks, > > C. > > Well, I was hoping to sweep the pca9554 model under the PowerNV maintainership (like pca9552 is under the BMC aspeed maintainership). I did update the PowerNV list to include it, but perhaps that was presumptuous of me. :-) I would be ok with being added as a reviewer under the PowerNV list, but I wonder if I shouldn't have more opensource experience before becoming a maintainer? TBH, I have no idea what that would entail. As for patches 3 and 4, it sounds like I should split those changes out from the current patch series so that they can make it into QEMU 8.2. Correct? Thanks, Glenn > > > > Thanks, > > > > Glenn > > > > > >} > > > > > > > >static uint32_t pnv_chip_power10_xscom_pcba(PnvChip *chip, > > > > uint64_t addr)
Re: [PATCH v3 0/4] ide: implement simple legacy/native mode switching for PCI IDE controllers
On Thu, 16 Nov 2023, Kevin Wolf wrote: Am 16.11.2023 um 11:33 hat Mark Cave-Ayland geschrieben: This series adds a simple implementation of legacy/native mode switching for PCI IDE controllers and updates the via-ide device to use it. The approach I take here is to add a new pci_ide_update_mode() function which handles management of the PCI BARs and legacy IDE ioports for each mode to avoid exposing details of the internal logic to individual PCI IDE controllers. As noted in [1] this is extracted from a local WIP branch I have which contains further work in this area. However for the moment I've kept it simple (and restricted it to the via-ide device) which is good enough for Zoltan's PPC images whilst paving the way for future improvements after 8.2. Signed-off-by: Mark Cave-Ayland [1] https://lists.gnu.org/archive/html/qemu-devel/2023-10/msg05403.html v3: - Rebase onto master - Move ide_portio_list[] and ide_portio_list2[] to IDE core to prevent duplication in hw/ide/pci.c - Don't zero BARs when switching from native mode to legacy mode, instead always force them to read zero as suggested in the PCI IDE specification (note: this also appears to fix the fuloong2e machine booting from IDE) - Add comments in pci_ide_update_mode() suggested by Kevin - Drop the existing R-B and T-B tags: whilst this passes my local tests, the behaviour around zero BARs feels different enough here Thanks, applied to the block branch. I feel a bit left out of this conversation... Did Google or some other spam filter decide again to filter my messages so you did not see them at all? Could you confitm that you've got my previous two replies in this thread so I know I'm not sending comments to /dev/null please? Regards, BALATON Zoltan
RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: Brian Cain
> Sent: Thursday, November 16, 2023 10:25 AM
> To: ltaylorsimp...@gmail.com; qemu-devel@nongnu.org
> Cc: Matheus Bernardino (QUIC) ; Sid
> Manning ; richard.hender...@linaro.org;
> phi...@linaro.org; a...@rev.ng; a...@rev.ng
> Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> oriented
>
>
>
> > -Original Message-
> > From: ltaylorsimp...@gmail.com
> > Sent: Wednesday, November 15, 2023 4:03 PM
> > To: Brian Cain ; qemu-devel@nongnu.org
> > Cc: Matheus Bernardino (QUIC) ; Sid
> Manning
> > ; richard.hender...@linaro.org;
> > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > object oriented
> >
> > > -Original Message-
> > > From: Brian Cain
> > > Sent: Wednesday, November 15, 2023 1:51 PM
> > > To: Taylor Simpson ; qemu-
> de...@nongnu.org
> > > Cc: Matheus Bernardino (QUIC) ; Sid
> > > Manning ; richard.hender...@linaro.org;
> > > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > object oriented
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Taylor Simpson
> > > > Sent: Thursday, November 9, 2023 3:26 PM
> > > > To: qemu-devel@nongnu.org
> > > > Cc: Brian Cain ; Matheus Bernardino (QUIC)
> > > > ; Sid Manning ;
> > > > richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng;
> > > a...@rev.ng;
> > > > ltaylorsimp...@gmail.com
> > > > Subject: [RFC PATCH] Hexagon (target/hexagon) Make generators
> > > > object oriented
> > > >
> > > > RFC - This patch handles gen_tcg_funcs.py. I'd like to get
> > > > comments on the general approach before working on the other
> Python scripts.
> > > >
> > > > The generators are generally a bunch of Python if-then-else
> > > > statements based on the regtype and regid. Encapsulate
> > > > regtype/regid into a class hierarchy. Clients lookup the register
> > > > and invoke methods.
> > > >
> > > > This has several advantages for making the code easier to read,
> > > > understand, and maintain
> > > > - The class name makes it more clear what the operand does
> > > > - All the methods for a given type of operand are together
> > > > - Don't need as many calls to hex_common.bad_register
> > > > - We can remove the functions in hex_common that use regtype/regid
> > > > (e.g., is_read)
> > > >
> > > > Signed-off-by: Taylor Simpson
> > > > ---
> > > > diff --git a/target/hexagon/hex_common.py
> > > b/target/hexagon/hex_common.py
> > > > index 0da65d6dd6..13ee55b6b2 100755
> > > > --- a/target/hexagon/hex_common.py
> > > > +++ b/target/hexagon/hex_common.py
> > > > +class PredReadWrite(ReadWrite):
> > > > +def genptr_decl(self, f, tag, regno):
> > > > +f.write(f"const int {self.regN} = insn->regno[{regno}];\n")
> > > > +f.write(f"TCGv {self.regV} = tcg_temp_new();\n")
> > > > +f.write(f"tcg_gen_mov_tl({self.regV},
> hex_pred[{self.regN}]);\n")
> > >
> > > Instead of successive calls to f.write(), each passing their own
> > > string with a newline, use triple quotes:
> > >
> > > f.write(f"""const int {self.regN} = insn->regno[{regno}];
> > > TCGv {self.regV} = tcg_temp_new();
> > > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n""")
> > >
> > > If necessary/appropriate, you can also use textwrap.dedent() to make
> > > the leading whitespace look appropriate:
> > > https://docs.python.org/3/library/textwrap.html#textwrap.dedent
> > >
> > > import textwrap
> > > ...
> > > f.write(textwrap.dedent(f"""const int {self.regN} = insn-
> >regno[{regno}];
> > > TCGv {self.regV} = tcg_temp_new();
> > > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n"""))
> > >
> >
> > The indenting is for the readability of the output. We could dedent
> > everything and run the result through the indent utility as
> > idef-parser does. Not sure it's worth it though.
>
> Regardless of textwrap.dedent(), I think the output is most readable with
> triple-quotes. It's more readable than it is with multiple f.write("this
> line\n")
> invocations.
>
> The intent of calling textwrap.dedent is to allow you to not out-dent the text
> in the python program. Since the indentation of the other lines next to the
> string literal are significant to the program, it might be odd/confusing to
> see
> the python program have out-dented text lines.
>
> Consider the readability of the python program:
>
> if foo:
> f.write(textwrap.dedent(f"""\
> const int {self.regN} = insn->regno[{regno}];
> TCGv {self.regV} = tcg_temp_new();
> tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);
> """))
> if bar:
> f.write(textwrap.dedent(f"""\
> int x = {bar.reg};
> """)
> vs
>
> if foo:
> f.write(f"""\
> const int {self.regN} = insn->regno[{regno}]; TCGv {self.regV} =
> tcg_temp_new();
Re: [PATCH for-8.2] Revert "ui/console: allow to override the default VC"
On 16 November 2023 13:22:28 GMT-05:00, Peter Maydell
wrote:
>This reverts commit 1bec1cc0da497e55c16e2a7b50f94cdb2a02197f. This
>commit changed the behaviour of the "-display none" option, so that
>it now creates a QEMU monitor on the terminal. "-display none"
>should not be tangled up with whether we create a monitor or a serial
>terminal; it should purely and only disable the graphical window.
>Changing its behaviour like this breaks command lines which, for
>example, use semihosting for their output and don't want a graphical
>window, as they now get a monitor they never asked for.
>
>It also breaks the command line we document for Xen in
>docs/system/i386/xen.html:
>
> $ ./qemu-system-x86_64 --accel kvm,xen-version=0x40011,kernel-irqchip=split \
>-display none -chardev stdio,mux=on,id=char0,signal=off -mon char0 \
>-device xen-console,chardev=char0 -drive file=${GUEST_IMAGE},if=xen
>
>qemu-system-x86_64: cannot use stdio by multiple character devices
>qemu-system-x86_64: could not connect serial device to character backend
>'stdio'
>
>Revert the commit to restore the previous handling of "-display
>none".
>
>Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1974
>Signed-off-by: Peter Maydell
Reviewed-by:
Re: [PATCH] Fix SiFive E CLINT clock frequency (#1978)
I believe you forgot to add your Signed-off-by tag. Without it we can't accept the patch hehe Since you'll need to send another version with the S-o-b, please change the commit title to "riscv: Fix SiFive E CLINT clock frequency" That way other people will quickly identify which sub-tree this patch belongs. The Gitlab bug number you put it in the end of the commit msg in a tag: On 11/16/23 09:07, Román Cárdenas wrote: If you check the manual of SiFive E310 (https://cdn.sparkfun.com/assets/7/f/0/2/7/fe310-g002-manual-v19p05.pdf?_gl=1*w2ieef*_ga*MTcyNDI2MjM0Ny4xNjk2ODcwNTM3*_ga_T369JS7J9N*MTY5Njg3MDUzNy4xLjAuMTY5Njg3MDUzNy42MC4wLjA.), you can see in Figure 1 that the CLINT is connected to the real time clock, which also feeds the AON peripheral (they share the same clock). In page 43, the docs also say that the timer registers of the CLINT count ticks from the rtcclk. I am currently playing with bare metal applications both in QEMU and a physical SiFive E310 board and I confirm that the CLINT clock in the physical board runs at 32.768 kHz. In QEMU, the same app produces a completely different outcome, as sometimes a new CLINT interrupt is triggered before finishing other tasks. You can check issue #1978 on GitLab for more information. Like this: Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1978 The rest of the commit msg and the code looks good to me. Thanks, Daniel --- hw/riscv/sifive_e.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/riscv/sifive_e.c b/hw/riscv/sifive_e.c index 0d37adc542..87d9602383 100644 --- a/hw/riscv/sifive_e.c +++ b/hw/riscv/sifive_e.c @@ -225,7 +225,7 @@ static void sifive_e_soc_realize(DeviceState *dev, Error **errp) RISCV_ACLINT_SWI_SIZE, RISCV_ACLINT_DEFAULT_MTIMER_SIZE, 0, ms->smp.cpus, RISCV_ACLINT_DEFAULT_MTIMECMP, RISCV_ACLINT_DEFAULT_MTIME, -RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ, false); +SIFIVE_E_LFCLK_DEFAULT_FREQ, false); sifive_e_prci_create(memmap[SIFIVE_E_DEV_PRCI].base); /* AON */
Re: [PATCH v5 2/4] qcow2: add configurations for zoned format extension
Hi Eric,
Eric Blake 于2023年10月30日周一 22:53写道：
>
> On Mon, Oct 30, 2023 at 08:18:45PM +0800, Sam Li wrote:
> > To configure the zoned format feature on the qcow2 driver, it
> > requires settings as: the device size, zone model, zone size,
> > zone capacity, number of conventional zones, limits on zone
> > resources (max append bytes, max open zones, and max_active_zones).
> >
> > To create a qcow2 file with zoned format, use command like this:
> > $ qemu-img create -f qcow2 test.qcow2 -o size=768M -o
> > zone_size=64M -o zone_capacity=64M -o conventional_zones=0 -o
> > max_append_bytes=4096 -o max_open_zones=0 -o max_active_zones=0
> > -o zone_model=host-managed
> >
> > Signed-off-by: Sam Li
> >
> > fix config?
>
> Is this comment supposed to be part of the commit message? If not,...
>
> > ---
>
> ...place it here under the divider, so 'git am' won't include it, if there is
> nothing further to change on this patch.
>
> > block/qcow2.c| 205 ++-
> > block/qcow2.h| 37 +-
> > docs/interop/qcow2.txt | 67 +-
> > include/block/block_int-common.h | 13 ++
> > qapi/block-core.json | 45 ++-
> > 5 files changed, 362 insertions(+), 5 deletions(-)
> >
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index aa01d9e7b5..cd53268ca7 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -73,6 +73,7 @@ typedef struct {
> > #define QCOW2_EXT_MAGIC_CRYPTO_HEADER 0x0537be77
> > #define QCOW2_EXT_MAGIC_BITMAPS 0x23852875
> > #define QCOW2_EXT_MAGIC_DATA_FILE 0x44415441
> > +#define QCOW2_EXT_MAGIC_ZONED_FORMAT 0x007a6264
> >
> > static int coroutine_fn
> > qcow2_co_preadv_compressed(BlockDriverState *bs,
> > @@ -210,6 +211,7 @@ qcow2_read_extensions(BlockDriverState *bs, uint64_t
> > start_offset,
> > uint64_t offset;
> > int ret;
> > Qcow2BitmapHeaderExt bitmaps_ext;
> > +Qcow2ZonedHeaderExtension zoned_ext;
> >
> > if (need_update_header != NULL) {
> > *need_update_header = false;
> > @@ -431,6 +433,63 @@ qcow2_read_extensions(BlockDriverState *bs, uint64_t
> > start_offset,
> > break;
> > }
> >
> > +case QCOW2_EXT_MAGIC_ZONED_FORMAT:
> > +{
> > +if (ext.len != sizeof(zoned_ext)) {
> > +error_setg(errp, "zoned_ext: Invalid extension length");
> > +return -EINVAL;
> > +}
>
> Do we ever anticipate the struct growing in size in the future to add
> further features? Forcing the size to be constant, rather than a
> minimum, may get in the way of clean upgrades to a future version of
> the extension header.
>
> > +ret = bdrv_pread(bs->file, offset, ext.len, _ext, 0);
> > +if (ret < 0) {
> > +error_setg_errno(errp, -ret, "zoned_ext: "
> > + "Could not read ext header");
> > +return ret;
> > +}
> > +
> > +if (s->incompatible_features & QCOW2_INCOMPAT_ZONED_FORMAT) {
> > +warn_report("A program lacking zoned format support "
> > + "may modify this file and zoned metadata are "
> > + "now considered inconsistent");
> > +error_printf("The zoned metadata is corrupted.\n");
>
> Why is this mixing warn_report and error_printf at the same time.
> Also, grammar is inconsistent from the similar
> QCOW2_AUTOCLEAR_BITMAPS, which used:
>
> if (s->qcow_version < 3) {
> /* Let's be a bit more specific */
> warn_report("This qcow2 v2 image contains bitmaps, but "
> "they may have been modified by a program "
> "without persistent bitmap support; so now "
> "they must all be considered inconsistent");
> } else {
> warn_report("a program lacking bitmap support "
> "modified this file, so all bitmaps are now "
> "considered inconsistent");
>
> This also raises the question whether we want to ever allow zoned
> support with a v2 image, or whether it should just be a hard error if
> it is not a v3 image (my preference would be the latter).
>
> > +}
> > +
> > +zoned_ext.zone_size = be32_to_cpu(zoned_ext.zone_size);
> > +zoned_ext.zone_capacity = be32_to_cpu(zoned_ext.zone_capacity);
> > +zoned_ext.conventional_zones =
> > +be32_to_cpu(zoned_ext.conventional_zones);
> > +zoned_ext.nr_zones = be32_to_cpu(zoned_ext.nr_zones);
> > +zoned_ext.max_open_zones =
> > be32_to_cpu(zoned_ext.max_open_zones);
> > +zoned_ext.max_active_zones =
> > +be32_to_cpu(zoned_ext.max_active_zones);
> > +zoned_ext.max_append_bytes =
> > +
[PATCH for-8.2] Revert "ui/console: allow to override the default VC"
This reverts commit 1bec1cc0da497e55c16e2a7b50f94cdb2a02197f. This
commit changed the behaviour of the "-display none" option, so that
it now creates a QEMU monitor on the terminal. "-display none"
should not be tangled up with whether we create a monitor or a serial
terminal; it should purely and only disable the graphical window.
Changing its behaviour like this breaks command lines which, for
example, use semihosting for their output and don't want a graphical
window, as they now get a monitor they never asked for.
It also breaks the command line we document for Xen in
docs/system/i386/xen.html:
$ ./qemu-system-x86_64 --accel kvm,xen-version=0x40011,kernel-irqchip=split \
-display none -chardev stdio,mux=on,id=char0,signal=off -mon char0 \
-device xen-console,chardev=char0 -drive file=${GUEST_IMAGE},if=xen
qemu-system-x86_64: cannot use stdio by multiple character devices
qemu-system-x86_64: could not connect serial device to character backend 'stdio'
Revert the commit to restore the previous handling of "-display
none".
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1974
Signed-off-by: Peter Maydell
---
include/ui/console.h | 2 --
system/vl.c | 27 ++-
ui/console.c | 17 -
3 files changed, 10 insertions(+), 36 deletions(-)
diff --git a/include/ui/console.h b/include/ui/console.h
index a4a49ffc640..acb61a7f152 100644
--- a/include/ui/console.h
+++ b/include/ui/console.h
@@ -462,14 +462,12 @@ struct QemuDisplay {
DisplayType type;
void (*early_init)(DisplayOptions *opts);
void (*init)(DisplayState *ds, DisplayOptions *opts);
-const char *vc;
};
void qemu_display_register(QemuDisplay *ui);
bool qemu_display_find_default(DisplayOptions *opts);
void qemu_display_early_init(DisplayOptions *opts);
void qemu_display_init(DisplayState *ds, DisplayOptions *opts);
-const char *qemu_display_get_vc(DisplayOptions *opts);
void qemu_display_help(void);
/* vnc.c */
diff --git a/system/vl.c b/system/vl.c
index 5af7ced2a16..3d64a90f253 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -1372,7 +1372,6 @@ static void qemu_setup_display(void)
static void qemu_create_default_devices(void)
{
MachineClass *machine_class = MACHINE_GET_CLASS(current_machine);
-const char *vc = qemu_display_get_vc();
if (is_daemonized()) {
/* According to documentation and historically, -nographic redirects
@@ -1391,30 +1390,24 @@ static void qemu_create_default_devices(void)
}
}
-if (nographic || (!vc && !is_daemonized() && isatty(STDOUT_FILENO))) {
-if (default_parallel) {
+if (nographic) {
+if (default_parallel)
add_device_config(DEV_PARALLEL, "null");
-}
if (default_serial && default_monitor) {
add_device_config(DEV_SERIAL, "mon:stdio");
} else {
-if (default_serial) {
+if (default_serial)
add_device_config(DEV_SERIAL, "stdio");
-}
-if (default_monitor) {
+if (default_monitor)
monitor_parse("stdio", "readline", false);
-}
}
} else {
-if (default_serial) {
-add_device_config(DEV_SERIAL, vc ?: "null");
-}
-if (default_parallel) {
-add_device_config(DEV_PARALLEL, vc ?: "null");
-}
-if (default_monitor && vc) {
-monitor_parse(vc, "readline", false);
-}
+if (default_serial)
+add_device_config(DEV_SERIAL, "vc:80Cx24C");
+if (default_parallel)
+add_device_config(DEV_PARALLEL, "vc:80Cx24C");
+if (default_monitor)
+monitor_parse("vc:80Cx24C", "readline", false);
}
if (default_net) {
diff --git a/ui/console.c b/ui/console.c
index 8e688d35695..676d0cbaba2 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1677,23 +1677,6 @@ void qemu_display_init(DisplayState *ds, DisplayOptions
*opts)
dpys[opts->type]->init(ds, opts);
}
-const char *qemu_display_get_vc(DisplayOptions *opts)
-{
-assert(opts->type < DISPLAY_TYPE__MAX);
-if (opts->type == DISPLAY_TYPE_NONE) {
-return NULL;
-}
-assert(dpys[opts->type] != NULL);
-if (dpys[opts->type]->vc) {
-return dpys[opts->type]->vc;
-} else {
-#ifdef CONFIG_PIXMAN
-return "vc:80Cx24C";
-#endif
-}
-return NULL;
-}
-
void qemu_display_help(void)
{
int idx;
--
2.34.1
Re: [RFC PATCH 2/2] migration/multifd: Move semaphore release into main thread
Juan Quintela writes:
> Peter Xu wrote:
>> On Thu, Nov 09, 2023 at 01:58:56PM -0300, Fabiano Rosas wrote:
>>> We cannot operate on the multifd semaphores outside of the multifd
>>> channel thread
>>> because multifd_save_cleanup() can run in parallel and
>>> attempt to destroy the mutexes, which causes an assert.
>>>
>>> Looking at the places where we use the semaphores aside from the
>>> migration thread, there's only the TLS handshake thread and the
>>> initial multifd_channel_connect() in the main thread. These are places
>>> where creating the multifd channel cannot fail, so releasing the
>>> semaphores at these places only serves the purpose of avoiding a
>>> deadlock when an error happens before the channel(s) have started, but
>>> after the migration thread has already called
>>> multifd_send_sync_main().
>>>
>>> Instead of attempting to release the semaphores at those places, move
>>> the release into multifd_save_cleanup(). This puts the semaphore usage
>>> in the same thread that does the cleanup, eliminating the race.
>>>
>>> Move the call to multifd_save_cleanup() before joining for the
>>> migration thread so we release the semaphores before.
>>>
>>> Signed-off-by: Fabiano Rosas
>>> ---
>>> migration/migration.c | 4 +++-
>>> migration/multifd.c | 29 +++--
>>> 2 files changed, 14 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/migration/migration.c b/migration/migration.c
>>> index cca32c553c..52be20561b 100644
>>> --- a/migration/migration.c
>>> +++ b/migration/migration.c
>>> @@ -1300,6 +1300,9 @@ static void migrate_fd_cleanup(MigrationState *s)
>>> QEMUFile *tmp;
>>>
>>> trace_migrate_fd_cleanup();
>>> +
>>> +multifd_save_cleanup();
>>> +
>>> qemu_mutex_unlock_iothread();
>>> if (s->migration_thread_running) {
>>> qemu_thread_join(>thread);
>>> @@ -1307,7 +1310,6 @@ static void migrate_fd_cleanup(MigrationState *s)
>>> }
>>> qemu_mutex_lock_iothread();
>>>
>>> -multifd_save_cleanup();
>>> qemu_mutex_lock(>qemu_file_lock);
>>> tmp = s->to_dst_file;
>>> s->to_dst_file = NULL;
>>> diff --git a/migration/multifd.c b/migration/multifd.c
>>> index ec58c58082..9ca482cfbe 100644
>>> --- a/migration/multifd.c
>>> +++ b/migration/multifd.c
>>> @@ -527,6 +527,9 @@ void multifd_save_cleanup(void)
>>>
>>> if (p->running) {
>>> qemu_thread_join(>thread);
>>> +} else {
>>> +qemu_sem_post(>sem_sync);
>>> +qemu_sem_post(_send_state->channels_ready);
>>
>> I think relying on p->running to join the thread is already problematic.
>
> Why?
The channel holds resources that need to be freed by
multifd_save_cleanup(). We cannot reliably do so while the channel
itself is the one responsible for telling the main thread whether it is
done with those resources.
p->running works fine for knowing "has the thread been created", so we
can use it to avoid joining if it was never created. But it is bad for
knowing "is the thread still running" because as soon as the channel
sets p->running=false, multifd_save_cleanup() could attempt to destroy
the p->mutex and the semaphores.
The bug reported in the other series was about this already:
[PATCH] migrate/multifd: fix coredump when the multifd thread cleanup
https://lore.kernel.org/r/20230621081826.3203053-1-zhangjiangu...@huawei.com
>> Now all threads are created with JOINABLE, so we must join them to release
>> the thread resources. Clearing "running" at the end of the thread is
>> already wrong to me, because it means if the thread quits before the main
>> thread reaching here, we will not join the thread, and the thread resource
>> will be leaked.
>
> The bug is that the thread quits from other place.
> It is not different that forgetting to do a mutex_unlock(). It is an
> error that needs fixing.
>
>> Here IMHO we should set p->running=true right before thread created,
>
> (that is basically what is done)
>
> Meaning of ->running is that multifd thread has started running. it a
> false is that it is not running normally anymore.
The issue is that multifd_save_cleanup looks at p->running = false and
continues with the cleanup that destroys the mutex while the TLS thread
might be using it.
>
> thread function:
>
>> and never clear it.
>
> static void *multifd_send_thread(void *opaque)
> {
> // No error can happens here
>
> while (true) {
> // No return command here, just breaks
> }
>
> out:
> // This can fail
>
> qemu_mutex_lock(>mutex);
> p->running = false;
> qemu_mutex_unlock(>mutex);
>
> /* this can't fail */
>
> return NULL;
> }
>
>
> What running here means is that we don't need to "stop" this thread
> anymore. That happens as soon as we get out of the loop.
>
>> We may even want to rename it to p->thread_created?
>
> We can rename it, but I am not sure if it buys it too much. Notice that
> we also mean
Re: [PATCH 3/3] tests/avocado: Enable reverse_debugging.py tests in gitlab CI
On 16/11/2023 12.53, Nicholas Piggin wrote: Let's try enable reverse_debugging.py in gitlab CI. Signed-off-by: Nicholas Piggin --- Maybe we could try this again at some point? The bug might have been noticed sooner. They only take a couple of seconds to run so should not take too much overhead. But my gitlab CI pipeline doesn't run the avocado tests for some reason, so I can't see if it's still causing problems. Thanks, Nick --- tests/avocado/reverse_debugging.py | 7 --- 1 file changed, 7 deletions(-) FYI, I gave it a try, and it survived my CI run: https://gitlab.com/thuth/qemu/-/jobs/5552213972#L403 So I went ahead and put it (together with the first patch) in my current pull request, let's see how it goes... (for the second patch, I hope our chardev maintainer Marc-André could comment on that first) Thomas
[PULL 07/10] tests/avocado/replay_kernel: Mark the test_x86_64_pc as flaky
It's failing very often, so don't run this by default anymore
until it gets fixed.
Message-ID: <20231114153019.295131-1-th...@redhat.com>
Reviewed-by: Peter Maydell
Signed-off-by: Thomas Huth
---
tests/avocado/replay_kernel.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/avocado/replay_kernel.py b/tests/avocado/replay_kernel.py
index a18610542e..53cb7e5091 100644
--- a/tests/avocado/replay_kernel.py
+++ b/tests/avocado/replay_kernel.py
@@ -81,7 +81,8 @@ def run_rr(self, kernel_path, kernel_command_line,
console_pattern,
logger.info('replay overhead {:.2%}'.format(t2 / t1 - 1))
class ReplayKernelNormal(ReplayKernelBase):
-@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
+
+@skipUnless(os.getenv('QEMU_TEST_FLAKY_TESTS'), 'Test sometimes gets
stuck')
def test_x86_64_pc(self):
"""
:avocado: tags=arch:x86_64
--
2.41.0
[PULL 06/10] tests/avocado: Make fetch_asset() unconditionally require a crypto hash
From: Philippe Mathieu-Daudé
In a perfect world we'd have reproducible tests,
but then we'd be sure we run the same binaries.
If a binary artifact isn't hashed, we have no idea
what we are running. Therefore enforce hashing for
all our artifacts.
With this change, unhashed artifacts produce:
$ avocado run tests/avocado/multiprocess.py
(1/2) tests/avocado/multiprocess.py:Multiprocess.test_multiprocess_x86_64:
ERROR: QemuBaseTest.fetch_asset() missing 1 required positional argument:
'asset_hash' (0.19 s)
Inspired-by: Thomas Huth
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Thomas Huth
Reviewed-by: Alex Bennée
Message-ID: <20231115205149.90765-1-phi...@linaro.org>
Signed-off-by: Thomas Huth
---
tests/avocado/avocado_qemu/__init__.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/avocado/avocado_qemu/__init__.py
b/tests/avocado/avocado_qemu/__init__.py
index d71e989db6..304c428168 100644
--- a/tests/avocado/avocado_qemu/__init__.py
+++ b/tests/avocado/avocado_qemu/__init__.py
@@ -254,7 +254,7 @@ def setUp(self, bin_prefix):
self.cancel("No QEMU binary defined or found in the build tree")
def fetch_asset(self, name,
-asset_hash=None, algorithm=None,
+asset_hash, algorithm=None,
locations=None, expire=None,
find_only=False, cancel_on_missing=True):
return super().fetch_asset(name,
--
2.41.0
[PULL 10/10] tests/avocado: Enable reverse_debugging.py tests in gitlab CI
From: Nicholas Piggin
Let's try enable reverse_debugging.py in gitlab CI.
Signed-off-by: Nicholas Piggin
Message-ID: <20231116115354.228678-3-npig...@gmail.com>
Signed-off-by: Thomas Huth
---
tests/avocado/reverse_debugging.py | 7 ---
1 file changed, 7 deletions(-)
diff --git a/tests/avocado/reverse_debugging.py
b/tests/avocado/reverse_debugging.py
index 128d85bc0e..b1410e7a69 100644
--- a/tests/avocado/reverse_debugging.py
+++ b/tests/avocado/reverse_debugging.py
@@ -205,8 +205,6 @@ def get_pc(self, g):
return self.get_reg_le(g, self.REG_PC) \
+ self.get_reg_le(g, self.REG_CS) * 0x10
-# unidentified gitlab timeout problem
-@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
def test_x86_64_pc(self):
"""
:avocado: tags=arch:x86_64
@@ -222,8 +220,6 @@ class ReverseDebugging_AArch64(ReverseDebugging):
REG_PC = 32
-# unidentified gitlab timeout problem
-@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
def test_aarch64_virt(self):
"""
:avocado: tags=arch:aarch64
@@ -246,8 +242,6 @@ class ReverseDebugging_ppc64(ReverseDebugging):
REG_PC = 0x40
-# unidentified gitlab timeout problem
-@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
def test_ppc64_pseries(self):
"""
:avocado: tags=arch:ppc64
@@ -259,7 +253,6 @@ def test_ppc64_pseries(self):
self.endian_is_le = False
self.reverse_debugging()
-@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
def test_ppc64_powernv(self):
"""
:avocado: tags=arch:ppc64
--
2.41.0
[PULL 01/10] tests/avocado: Replace assertEquals() for Python 3.12 compatibility
assertEquals() has been removed in Python 3.12 and should be replaced by
assertEqual(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3
Message-ID: <20231114134326.287242-1-th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Thomas Huth
---
docs/devel/testing.rst | 2 +-
tests/avocado/cpu_queries.py| 2 +-
tests/avocado/empty_cpu_model.py| 2 +-
tests/avocado/pc_cpu_hotplug_props.py | 2 +-
tests/avocado/x86_cpu_model_versions.py | 97 +
5 files changed, 53 insertions(+), 52 deletions(-)
diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index fef64accc1..87ed30af22 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -1077,7 +1077,7 @@ and hypothetical example follows:
'human-monitor-command',
command_line='info version')
- self.assertEquals(first_res, second_res, third_res)
+ self.assertEqual(first_res, second_res, third_res)
At test "tear down", ``avocado_qemu.Test`` handles all the QEMUMachines
shutdown.
diff --git a/tests/avocado/cpu_queries.py b/tests/avocado/cpu_queries.py
index 86c2d5c92d..d3faa14720 100644
--- a/tests/avocado/cpu_queries.py
+++ b/tests/avocado/cpu_queries.py
@@ -32,4 +32,4 @@ def test(self):
model = {'name': c['name']}
e = self.vm.cmd('query-cpu-model-expansion', model=model,
type='full')
-self.assertEquals(e['model']['name'], c['name'])
+self.assertEqual(e['model']['name'], c['name'])
diff --git a/tests/avocado/empty_cpu_model.py b/tests/avocado/empty_cpu_model.py
index 22f504418d..d906ef3d3c 100644
--- a/tests/avocado/empty_cpu_model.py
+++ b/tests/avocado/empty_cpu_model.py
@@ -15,5 +15,5 @@ def test(self):
self.vm.set_qmp_monitor(enabled=False)
self.vm.launch()
self.vm.wait()
-self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1")
+self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1")
self.assertRegex(self.vm.get_log(), r'-cpu option cannot be empty')
diff --git a/tests/avocado/pc_cpu_hotplug_props.py
b/tests/avocado/pc_cpu_hotplug_props.py
index b56f51d02a..4bd3e02665 100644
--- a/tests/avocado/pc_cpu_hotplug_props.py
+++ b/tests/avocado/pc_cpu_hotplug_props.py
@@ -32,4 +32,4 @@ def test_no_die_id(self):
self.vm.add_args('-smp', '1,sockets=2,cores=2,threads=2,maxcpus=8')
self.vm.add_args('-device',
'qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0')
self.vm.launch()
-self.assertEquals(len(self.vm.cmd('query-cpus-fast')), 2)
+self.assertEqual(len(self.vm.cmd('query-cpus-fast')), 2)
diff --git a/tests/avocado/x86_cpu_model_versions.py
b/tests/avocado/x86_cpu_model_versions.py
index 9e07b8a55d..11101e02b9 100644
--- a/tests/avocado/x86_cpu_model_versions.py
+++ b/tests/avocado/x86_cpu_model_versions.py
@@ -121,94 +121,95 @@ def test_4_1_alias(self):
self.assertFalse(cpus['Cascadelake-Server']['static'],
'unversioned Cascadelake-Server CPU model must not be
static')
-self.assertEquals(cpus['Cascadelake-Server'].get('alias-of'),
'Cascadelake-Server-v1',
- 'Cascadelake-Server must be an alias of
Cascadelake-Server-v1')
+self.assertEqual(cpus['Cascadelake-Server'].get('alias-of'),
+ 'Cascadelake-Server-v1',
+ 'Cascadelake-Server must be an alias of
Cascadelake-Server-v1')
self.assertNotIn('alias-of', cpus['Cascadelake-Server-v1'],
'Cascadelake-Server-v1 must not be an alias')
self.assertFalse(cpus['qemu64']['static'],
'unversioned qemu64 CPU model must not be static')
-self.assertEquals(cpus['qemu64'].get('alias-of'), 'qemu64-v1',
- 'qemu64 must be an alias of qemu64-v1')
+self.assertEqual(cpus['qemu64'].get('alias-of'), 'qemu64-v1',
+ 'qemu64 must be an alias of qemu64-v1')
self.assertNotIn('alias-of', cpus['qemu64-v1'],
'qemu64-v1 must not be an alias')
self.validate_variant_aliases(cpus)
# On pc-*-4.1, -noTSX and -IBRS models should be aliases:
-self.assertEquals(cpus["Haswell"].get('alias-of'),
- "Haswell-v1",
+self.assertEqual(cpus["Haswell"].get('alias-of'),
+ "Haswell-v1",
"Haswell must be an alias")
-self.assertEquals(cpus["Haswell-noTSX"].get('alias-of'),
- "Haswell-v2",
+self.assertEqual(cpus["Haswell-noTSX"].get('alias-of'),
+ "Haswell-v2",
"Haswell-noTSX must be an alias")
-self.assertEquals(cpus["Haswell-IBRS"].get('alias-of'),
- "Haswell-v3",
+
[PULL 03/10] tests/avocado/virtio-gpu: Fix test_vhost_user_vga_virgl for edid support
The "edid" feature has been added to vhost-user-gpu in commit
c06444261e20 ("contrib/vhost-user-gpu: implement get_edid feature"),
so waiting for "features: +virgl -edid" in the test does not work
anymore, it's "+edid" instead of "-edid" now!
While we're at it, move the expected string to the preceeding
exec_command_and_wait_for_pattern() instead (since waiting for
empty string here does not make too much sense).
Message-ID: <20231114203456.319093-1-th...@redhat.com>
Reviewed-by: Antonio Caggiano
Signed-off-by: Thomas Huth
---
tests/avocado/virtio-gpu.py | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/tests/avocado/virtio-gpu.py b/tests/avocado/virtio-gpu.py
index 89bfecc715..6091f614a4 100644
--- a/tests/avocado/virtio-gpu.py
+++ b/tests/avocado/virtio-gpu.py
@@ -149,10 +149,8 @@ def test_vhost_user_vga_virgl(self):
# TODO: probably fails because we are missing the VirGL features
self.cancel("VirGL not enabled?")
self.wait_for_console_pattern("as init process")
-exec_command_and_wait_for_pattern(
-self, "/usr/sbin/modprobe virtio_gpu", ""
-)
-self.wait_for_console_pattern("features: +virgl -edid")
+exec_command_and_wait_for_pattern(self, "/usr/sbin/modprobe
virtio_gpu",
+ "features: +virgl +edid")
self.vm.shutdown()
qemu_sock.close()
vugp.terminate()
--
2.41.0
[PULL 04/10] tests/avocado/intel_iommu: Add asset hashes to avoid warnings
The intel_iommu test is currently succeeding with annoying warnings. Add the proper asset hashes to avoid those. Message-ID: <20231114143531.291820-1-th...@redhat.com> Reviewed-by: Eric Auger Signed-off-by: Thomas Huth --- tests/avocado/intel_iommu.py | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/avocado/intel_iommu.py b/tests/avocado/intel_iommu.py index 474d62f6bf..77635ab56c 100644 --- a/tests/avocado/intel_iommu.py +++ b/tests/avocado/intel_iommu.py @@ -54,9 +54,11 @@ def common_vm_setup(self, custom_kernel=None): return kernel_url = self.distro.pxeboot_url + 'vmlinuz' +kernel_hash = '5b6f6876e1b5bda314f93893271da0d5777b1f3c' initrd_url = self.distro.pxeboot_url + 'initrd.img' -self.kernel_path = self.fetch_asset(kernel_url) -self.initrd_path = self.fetch_asset(initrd_url) +initrd_hash = 'dd0340a1b39bd28f88532babd4581c67649ec5b1' +self.kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash) +self.initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash) def run_and_check(self): if self.kernel_path: -- 2.41.0
[PULL 09/10] tests/avocado: reverse_debugging drain console to prevent hang
From: Nicholas Piggin
Like replay_linux.py, reverse_debugging.py starts the vm with console
set but does not interact with it (e.g., with wait_for_console_pattern).
In this situation, the console should have a drainer attached so the
socket does not fill. replay_linux.py has a drainer, but it is missing
from reverse_debugging.py.
Per analysis in Link: this can cause the console socket/pipe to fill and
QEMU get stuck in qemu_chr_write_buffer, leading to strange test case
failures (ppc64 fails because it prints a lot to console in early bios).
Attaching a drainer prevents this.
Note, this commit does not fix bugs introduced by the commits referenced
in the first two Fixes: tags, but together those commits conspire to
irritate the problem and cause test case failure, which this commit
fixes.
Link: https://lore.kernel.org/qemu-devel/zvt-by9yor69q...@redhat.com/
Fixes: 1d4796cd0083 ("python/machine: use socketpair() for console connections")
Fixes: 761a13b23946 ("tests/avocado: ppc64 reverse debugging tests for pseries
and powernv")
Fixes: be52eca30978 ("tests/acceptance: add reverse debugging test")
Tested-by: Thomas Huth
Signed-off-by: Nicholas Piggin
Message-ID: <20231116115354.228678-1-npig...@gmail.com>
Signed-off-by: Thomas Huth
---
tests/avocado/reverse_debugging.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/avocado/reverse_debugging.py
b/tests/avocado/reverse_debugging.py
index fc47874eda..128d85bc0e 100644
--- a/tests/avocado/reverse_debugging.py
+++ b/tests/avocado/reverse_debugging.py
@@ -12,6 +12,7 @@
from avocado import skipIf
from avocado_qemu import BUILD_DIR
+from avocado.utils import datadrainer
from avocado.utils import gdb
from avocado.utils import process
from avocado.utils.network.ports import find_free_port
@@ -52,6 +53,10 @@ def run_vm(self, record, shift, args, replay_path,
image_path, port):
if args:
vm.add_args(*args)
vm.launch()
+console_drainer = datadrainer.LineLogger(vm.console_socket.fileno(),
+logger=self.log.getChild('console'),
+stop_check=(lambda : not vm.is_running()))
+console_drainer.start()
return vm
@staticmethod
--
2.41.0
[PULL 08/10] tests/avocado/mem-addr-space-check: Replace assertEquals() for Python 3.12
assertEquals() has been removed in Python 3.12 and should be replaced by assertEqual(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3 Message-ID: <20231116061956.14676-1-th...@redhat.com> Reviewed-by: Philippe Mathieu-Daudé Acked-by: Ani Sinha Signed-off-by: Thomas Huth --- tests/avocado/mem-addr-space-check.py | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/tests/avocado/mem-addr-space-check.py b/tests/avocado/mem-addr-space-check.py index be949222a4..363c3f12a6 100644 --- a/tests/avocado/mem-addr-space-check.py +++ b/tests/avocado/mem-addr-space-check.py @@ -49,7 +49,7 @@ def test_phybits_low_pse36(self): self.vm.set_qmp_monitor(enabled=False) self.vm.launch() self.vm.wait() -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1") +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1") self.assertRegex(self.vm.get_log(), r'phys-bits too low') def test_phybits_low_pae(self): @@ -69,7 +69,7 @@ def test_phybits_low_pae(self): self.vm.set_qmp_monitor(enabled=False) self.vm.launch() self.vm.wait() -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1") +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1") self.assertRegex(self.vm.get_log(), r'phys-bits too low') def test_phybits_ok_pentium_pse36(self): @@ -149,7 +149,7 @@ def test_phybits_low_nonpse36(self): self.vm.set_qmp_monitor(enabled=False) self.vm.launch() self.vm.wait() -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1") +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1") self.assertRegex(self.vm.get_log(), r'phys-bits too low') # now lets test some 64-bit CPU cases. @@ -179,7 +179,7 @@ def test_phybits_low_tcg_q35_70_amd(self): self.vm.set_qmp_monitor(enabled=False) self.vm.launch() self.vm.wait() -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1") +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1") self.assertRegex(self.vm.get_log(), r'phys-bits too low') def test_phybits_low_tcg_q35_71_amd(self): @@ -202,7 +202,7 @@ def test_phybits_low_tcg_q35_71_amd(self): self.vm.set_qmp_monitor(enabled=False) self.vm.launch() self.vm.wait() -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1") +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1") self.assertRegex(self.vm.get_log(), r'phys-bits too low') def test_phybits_ok_tcg_q35_70_amd(self): @@ -288,7 +288,7 @@ def test_phybits_low_tcg_q35_71_amd_41bits(self): self.vm.set_qmp_monitor(enabled=False) self.vm.launch() self.vm.wait() -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1") +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1") self.assertRegex(self.vm.get_log(), r'phys-bits too low') def test_phybits_ok_tcg_q35_71_amd_41bits(self): @@ -332,7 +332,7 @@ def test_phybits_low_tcg_q35_intel_cxl(self): self.vm.set_qmp_monitor(enabled=False) self.vm.launch() self.vm.wait() -self.assertEquals(self.vm.exitcode(), 1, "QEMU exit code should be 1") +self.assertEqual(self.vm.exitcode(), 1, "QEMU exit code should be 1") self.assertRegex(self.vm.get_log(), r'phys-bits too low') def test_phybits_ok_tcg_q35_intel_cxl(self): -- 2.41.0
[PULL 05/10] tests/avocado/multiprocess: Add asset hashes to silence warnings
The multiprocess test is currently succeeding with an annoying warning:
(1/2) tests/avocado/multiprocess.py:Multiprocess.test_multiprocess_x86_64:
WARN: Test passed but there were warnings during execution. Check
the log for details
In the log, you can find an entry like:
WARNI| No hash provided. Cannot check the asset file integrity.
Add the proper asset hashes to avoid those warnings.
Message-ID: <20231115145852.494052-1-th...@redhat.com>
Signed-off-by: Thomas Huth
---
tests/avocado/multiprocess.py | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tests/avocado/multiprocess.py b/tests/avocado/multiprocess.py
index 9112a4cacc..ee7490ae08 100644
--- a/tests/avocado/multiprocess.py
+++ b/tests/avocado/multiprocess.py
@@ -18,8 +18,8 @@ class Multiprocess(QemuSystemTest):
"""
KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
-def do_test(self, kernel_url, initrd_url, kernel_command_line,
-machine_type):
+def do_test(self, kernel_url, kernel_hash, initrd_url, initrd_hash,
+kernel_command_line, machine_type):
"""Main test method"""
self.require_accelerator('kvm')
self.require_multiprocess()
@@ -30,8 +30,8 @@ def do_test(self, kernel_url, initrd_url, kernel_command_line,
os.set_inheritable(proxy_sock.fileno(), True)
os.set_inheritable(remote_sock.fileno(), True)
-kernel_path = self.fetch_asset(kernel_url)
-initrd_path = self.fetch_asset(initrd_url)
+kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
+initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
# Create remote process
remote_vm = self.get_vm()
@@ -72,13 +72,16 @@ def test_multiprocess_x86_64(self):
kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
'/linux/releases/31/Everything/x86_64/os/images'
'/pxeboot/vmlinuz')
+kernel_hash = '5b6f6876e1b5bda314f93893271da0d5777b1f3c'
initrd_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
'/linux/releases/31/Everything/x86_64/os/images'
'/pxeboot/initrd.img')
+initrd_hash = 'dd0340a1b39bd28f88532babd4581c67649ec5b1'
kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
'console=ttyS0 rdinit=/bin/bash')
machine_type = 'pc'
-self.do_test(kernel_url, initrd_url, kernel_command_line, machine_type)
+self.do_test(kernel_url, kernel_hash, initrd_url, initrd_hash,
+ kernel_command_line, machine_type)
def test_multiprocess_aarch64(self):
"""
@@ -87,10 +90,13 @@ def test_multiprocess_aarch64(self):
kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
'/linux/releases/31/Everything/aarch64/os/images'
'/pxeboot/vmlinuz')
+kernel_hash = '3505f2751e2833c681de78cee8dda1e49cabd2e8'
initrd_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
'/linux/releases/31/Everything/aarch64/os/images'
'/pxeboot/initrd.img')
+initrd_hash = '519a1962daf17d67fc3a9c89d45affcb399607db'
kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
'rdinit=/bin/bash console=ttyAMA0')
machine_type = 'virt,gic-version=3'
-self.do_test(kernel_url, initrd_url, kernel_command_line, machine_type)
+self.do_test(kernel_url, kernel_hash, initrd_url, initrd_hash,
+ kernel_command_line, machine_type)
--
2.41.0
[PULL 02/10] tests/avocado: Replace assertRegexpMatches() for Python 3.12 compatibility
From: Philippe Mathieu-Daudé
assertRegexpMatches() has been removed in Python 3.12 and should be replaced by
assertRegex(). See: https://docs.python.org/3.12/whatsnew/3.12.html#id3
Inspired-by: Thomas Huth
Signed-off-by: Philippe Mathieu-Daudé
Message-ID: <20231114144832.71612-1-phi...@linaro.org>
Reviewed-by: Thomas Huth
Signed-off-by: Thomas Huth
---
docs/devel/testing.rst | 2 +-
tests/avocado/version.py | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 87ed30af22..22218dbedb 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -1016,7 +1016,7 @@ class. Here's a simple usage example:
self.vm.launch()
res = self.vm.cmd('human-monitor-command',
command_line='info version')
- self.assertRegexpMatches(res, r'^(\d+\.\d+\.\d)')
+ self.assertRegex(res, r'^(\d+\.\d+\.\d)')
To execute your test, run:
diff --git a/tests/avocado/version.py b/tests/avocado/version.py
index 93ffdf3d97..c6139568a1 100644
--- a/tests/avocado/version.py
+++ b/tests/avocado/version.py
@@ -22,4 +22,4 @@ def test_qmp_human_info_version(self):
self.vm.launch()
res = self.vm.cmd('human-monitor-command',
command_line='info version')
-self.assertRegexpMatches(res, r'^(\d+\.\d+\.\d)')
+self.assertRegex(res, r'^(\d+\.\d+\.\d)')
--
2.41.0
[PULL 00/10] Avocado test fixes
The following changes since commit 34a5cb6d8434303c170230644b2a7c1d5781d197: Merge tag 'pull-tcg-20231114' of https://gitlab.com/rth7680/qemu into staging (2023-11-15 08:05:25 -0500) are available in the Git repository at: https://gitlab.com/thuth/qemu.git tags/pull-request-2023-11-16 for you to fetch changes up to c4d74ab24a02c90b7a3240510b3dd4e1bec536dd: tests/avocado: Enable reverse_debugging.py tests in gitlab CI (2023-11-16 14:22:56 +0100) * Fix the avocado tests for running with Python 3.12 * Add some asset hashes to silence warnings * Fix the broken reverse_debugging test Nicholas Piggin (2): tests/avocado: reverse_debugging drain console to prevent hang tests/avocado: Enable reverse_debugging.py tests in gitlab CI Philippe Mathieu-Daudé (2): tests/avocado: Replace assertRegexpMatches() for Python 3.12 compatibility tests/avocado: Make fetch_asset() unconditionally require a crypto hash Thomas Huth (6): tests/avocado: Replace assertEquals() for Python 3.12 compatibility tests/avocado/virtio-gpu: Fix test_vhost_user_vga_virgl for edid support tests/avocado/intel_iommu: Add asset hashes to avoid warnings tests/avocado/multiprocess: Add asset hashes to silence warnings tests/avocado/replay_kernel: Mark the test_x86_64_pc as flaky tests/avocado/mem-addr-space-check: Replace assertEquals() for Python 3.12 docs/devel/testing.rst | 4 +- tests/avocado/avocado_qemu/__init__.py | 2 +- tests/avocado/cpu_queries.py| 2 +- tests/avocado/empty_cpu_model.py| 2 +- tests/avocado/intel_iommu.py| 6 +- tests/avocado/mem-addr-space-check.py | 14 ++--- tests/avocado/multiprocess.py | 18 -- tests/avocado/pc_cpu_hotplug_props.py | 2 +- tests/avocado/replay_kernel.py | 3 +- tests/avocado/reverse_debugging.py | 12 ++-- tests/avocado/version.py| 2 +- tests/avocado/virtio-gpu.py | 6 +- tests/avocado/x86_cpu_model_versions.py | 97 + 13 files changed, 88 insertions(+), 82 deletions(-)
Re: [PATCH v5 2/4] qcow2: add configurations for zoned format extension
Markus Armbruster 于2023年11月3日周五 17:08写道：
>
> Eric Blake writes:
>
> > On Mon, Oct 30, 2023 at 08:18:45PM +0800, Sam Li wrote:
> >> To configure the zoned format feature on the qcow2 driver, it
> >> requires settings as: the device size, zone model, zone size,
> >> zone capacity, number of conventional zones, limits on zone
> >> resources (max append bytes, max open zones, and max_active_zones).
> >>
> >> To create a qcow2 file with zoned format, use command like this:
> >> $ qemu-img create -f qcow2 test.qcow2 -o size=768M -o
> >> zone_size=64M -o zone_capacity=64M -o conventional_zones=0 -o
> >> max_append_bytes=4096 -o max_open_zones=0 -o max_active_zones=0
> >> -o zone_model=host-managed
> >>
> >> Signed-off-by: Sam Li
> >>
> >> fix config?
> >
> > Is this comment supposed to be part of the commit message? If not,...
> >
> >> ---
> >
> > ...place it here under the divider, so 'git am' won't include it, if there
> > is nothing further to change on this patch.
>
> [...]
>
> >> +++ b/qapi/block-core.json
> >> @@ -4981,6 +4981,21 @@
> >> { 'enum': 'Qcow2CompressionType',
> >>'data': [ 'zlib', { 'name': 'zstd', 'if': 'CONFIG_ZSTD' } ] }
> >>
> >> +##
> >> +# @Qcow2ZoneModel:
> >> +#
> >> +# Zoned device model used in qcow2 image file
> >> +#
> >> +# @non-zoned: non-zoned model is for regular block devices
> >> +#
> >> +# @host-managed: host-managed model only allows sequential write over the
> >> +# device zones
> >> +#
> >> +# Since 8.2
> >> +##
> >> +{ 'enum': 'Qcow2ZoneModel',
> >> + 'data': ['non-zoned', 'host-managed'] }
> >> +
> >> ##
> >> # @BlockdevCreateOptionsQcow2:
> >> #
> >> @@ -5023,6 +5038,27 @@
> >> # @compression-type: The image cluster compression method
> >> # (default: zlib, since 5.1)
> >> #
> >> +# @zone-model: @Qcow2ZoneModel. The zone device model.
> >> +# (default: non-zoned, since 8.2)
> >> +#
> >> +# @zone-size: Total number of bytes within zones (since 8.2)
> >
> > If @zone-model is "non-zoned", does it make sense to even allow
> > @zone-size and friends? Should this use a QMP union, where you can
> > pass in the remaining zone-* fields only when zone-model is set to
> > host-managed?
>
> Valid question; needs an answer.
Yes, it should use a QMP union. It's better to separate those fields
for zoned and non-zoned.
>
> >> +#
> >> +# @zone-capacity: The number of usable logical blocks within zones
> >> +# in bytes. A zone capacity is always smaller or equal to the
> >> +# zone size (since 8.2)
> >> +#
> >> +# @conventional-zones: The number of conventional zones of the
> >> +# zoned device (since 8.2)
> >> +#
> >> +# @max-open-zones: The maximal number of open zones (since 8.2)
> >> +#
> >> +# @max-active-zones: The maximal number of zones in the implicit
> >> +# open, explicit open or closed state (since 8.2)
> >> +#
> >> +# @max-append-bytes: The maximal number of bytes of a zone
> >> +# append request that can be issued to the device. It must be
> >> +# 512-byte aligned (since 8.2)
> >> +#
> >> # Since: 2.12
> >> ##
> >> { 'struct': 'BlockdevCreateOptionsQcow2',
> >> @@ -5039,7 +5075,14 @@
> >> '*preallocation': 'PreallocMode',
> >> '*lazy-refcounts': 'bool',
> >> '*refcount-bits': 'int',
> >> -'*compression-type':'Qcow2CompressionType' } }
> >> +'*compression-type':'Qcow2CompressionType',
> >> +'*zone-model': 'Qcow2ZoneModel',
> >> +'*zone-size': 'size',
> >> +'*zone-capacity': 'size',
> >> +'*conventional-zones': 'uint32',
> >> +'*max-open-zones': 'uint32',
> >> +'*max-active-zones': 'uint32',
> >> +'*max-append-bytes': 'uint32' } }
> >
> > In other words, I'm envisioning something like an optional
> > '*zone':'ZoneStruct', where:
> >
> > { 'struct': 'ZoneHostManaged',
> > 'data': { 'size': 'size', '*capacity': 'size', ..., '*max-append-bytes':
> > 'uint32' } }
> > { 'union': 'ZoneStruct',
> > 'base': { 'model': 'Qcow2ZoneModel' },
> > 'discriminator': 'model',
> > 'data': { 'non-zoned': {},
> > 'host-managed': 'ZoneHostManaged' } }
> >
> > then over the wire, QMP can use the existing:
> > { ..., "compression-type":"zstd" }
> >
> > as a synonym for the new but explicit non-zoned:
> > { ..., "compression-type":"zstd", "zone":{"mode":"non-zoned"} }
>
> I.e. @zone is optional, and defaults to {"mode": "non-zoned"}.
>
> > and when we want to use zones, we pass:
> > { ..., "compression-type":"zstd", "zone":{"mode":"host-managed",
> > "size":16777216} }
> >
> > where you don't have to have zone- prefixing everywhere because it is
> > instead contained in the smart union object where it is obvious from
> > the 'mode' field what other fields should be present.
>
Yes, it's better. Thanks!
Sam
Re: [PATCH v5 2/4] qcow2: add configurations for zoned format extension
Stefan Hajnoczi 于2023年11月3日周五 11:24写道：
>
> On Mon, Oct 30, 2023 at 08:18:45PM +0800, Sam Li wrote:
> > +typedef struct Qcow2ZoneListEntry {
> > +QLIST_ENTRY(Qcow2ZoneListEntry) exp_open_zone_entry;
> > +QLIST_ENTRY(Qcow2ZoneListEntry) imp_open_zone_entry;
> > +QLIST_ENTRY(Qcow2ZoneListEntry) closed_zone_entry;
>
> Where is closed_zone_entry used?
When the number of implicitly open zones are reaching the max
implicitly open zone and one implicitly open zone is closed, it will
add one closed zone to closed_zone_entry. (Will be in the next
version)
Re: [PATCH v2 5/5] qom/object: Limit type names to alphanumerical and some few special characters
On 16/11/2023 14.24, Daniel P. Berrangé wrote:
On Thu, Nov 16, 2023 at 02:14:54PM +0100, Thomas Huth wrote:
QOM names currently don't have any enforced naming rules. This
can be problematic, e.g. when they are used on the command line
for the "-device" option (where the comma is used to separate
properties). To avoid that such problematic type names come in
again, let's restrict the set of acceptable characters during the
type registration.
Ideally, we'd apply here the same rules as for QAPI, i.e. all type
names should begin with a letter, and contain only ASCII letters,
digits, hyphen, and underscore. However, we already have so many
pre-existing types like:
486-x86_64-cpu
cfi.pflash01
power5+_v2.1-spapr-cpu-core
virt-2.6-machine
pc-i440fx-3.0-machine
... so that we have to allow "." and "+" for now, too. While the
dot is used in a lot of places, the "+" can fortunately be limited
to two classes of legacy names ("power" and "Sun-UltraSparc" CPUs).
We also cannot enforce the rule that names must start with a letter
yet, since there are lot of types that start with a digit. Still,
at least limiting the first characters to the alphanumerical range
should be way better than nothing.
Signed-off-by: Thomas Huth
---
qom/object.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/qom/object.c b/qom/object.c
index 95c0dc8285..571ef68950 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -138,9 +138,50 @@ static TypeImpl *type_new(const TypeInfo *info)
return ti;
}
+static bool type_name_is_valid(const char *name)
+{
+const int slen = strlen(name);
+
+g_assert(slen > 1);
+
+/*
+ * Ideally, the name should start with a letter - however, we've got
+ * too many names starting with a digit already, so allow digits here,
+ * too (except '0' which is not used yet)
+ */
+if (!g_ascii_isalnum(name[0]) || name[0] == '0') {
+return false;
+}
+
+for (int i = 1; i < slen; i++) {
+if (name[i] != '-' && name[i] != '_' && name[i] != '.' &&
+!g_ascii_isalnum(name[i])) {
+if (name[i] == '+') {
+if (i == 6 && !strncmp(name, "power", 5)) {
+/* It's a legacy name like "power5+" */
+continue;
+}
+if (i >= 17 && !strncmp(name, "Sun-UltraSparc", 14)) {
+/* It's a legacy name like "Sun-UltraSparc-IV+" */
+continue;
+}
+}
+return false;
+}
+}
Replace this big loop with strspn, which has an asm optimized impl
in glibc
ALPHA_LC "abcdefghijklmnopqrstuvwxyz"
ALPHA_UC "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
OTHER "0123456789-_."
return (strspn(name, ALPHA_UC ALPHA_LC OTHER) == slen) ||
(g_str_has_prefix(name, "power") && slen > 6 && name[6] == '+') ||
(g_str_has_prefix(name, "Sun-UltraSparc") && slen > 17 && name[17] ==
'+');
It's quite hard to believe that a function that has to check each and every
character in a string of acceptable characters is faster than a function
that uses something like g_ascii_asalnum which can check range of characters
in one go...
So I gave it a try, wrote two test programs, one with my implementation and
one with yours, and looped on the function 10 times. And indeed, for
short strings (less than 30 characters), my function is about three times
faster than the one with strspn() (mine takes ~ 13 seconds, the strspn() one
takes ~ 39 seconds).
Interestingly, for larger strings (more than 140 characters), the strspn()
impementation starts to perform better. They indeed must have an
optimization that kicks in for larger strings.
Now while my implementation seems to be a little bit faster for the strings
that we are using in QEMU, we certainly don't have 10 different
types in QEMU, but rather only 1300 or so, so the performance shouldn't
really matter that much here. And I have to admit that your code is indeed
more compact to read, so I'll give it a try.
Thomas
Re: [PULL v3 09/25] ui/console: allow to override the default VC
On Tue, 7 Nov 2023 at 10:24, wrote: > > From: Marc-André Lureau > > If a display is backed by a specialized VC, allow to override the > default "vc:80Cx24C". > > As suggested by Paolo, if the display doesn't implement a VC (get_vc() > returns NULL), use a fallback that will use a muxed console on stdio. > > This changes the behaviour of "qemu -display none", to create a muxed > serial/monitor by default (on TTY & not daemonized). This breaks existing command line setups -- if I say "-display none" I just mean "don't do a display", not "please also give me a monitor". We already have a "do what I mean" option for "no graphics", which is "-nographic". The advantage of -display none is that it does only and exactly what it says it does. Setups using semihosting for output now get a spurious load of output from the monitor on their terminal. I think we should revert this; I'll send a patch. thanks -- PMM
Re: [RFC PATCH] configure: don't try a "native" cross for i386
On Thu, Nov 16, 2023 at 05:28:20PM +, Alex Bennée wrote:
> As 32 bit x86 become rarer we are starting to run into problems with
> search paths. Although we switched to a Debian container we still
> favour the native CC on a Bookworm host. As a result we have a broken
> cross compile setup which then fails to build with:
>
> BUILD i386-linux-user guest-tests
> In file included from /usr/include/linux/stat.h:5,
>from /usr/include/bits/statx.h:31,
>from /usr/include/sys/stat.h:465,
>from
> /home/alex/lsrc/qemu.git/tests/tcg/multiarch/linux/linux-test.c:28:
> /usr/include/linux/types.h:5:10: fatal error: asm/types.h: No such file or
> directory
> 5 | #include
> | ^
> compilation terminated.
> make[1]: *** [Makefile:119: linux-test] Error 1
> make: *** [/home/alex/lsrc/qemu.git/tests/Makefile.include:50:
> build-tcg-tests-i386-linux-user] Error 2
>
> So lets stop trying to be cute and honour cross_prefix_i386 when
> searching locally. We also need to ensure we are using the correct
> prefix if we do end up using the container version. We can also drop
> the extra CFLAGS while we are at it.
>
> Fixes: 791e6fedc5 (tests/docker: replace fedora-i386 with debian-i686)
> Signed-off-by: Alex Bennée
> ---
> configure | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Reviewed-by: Daniel P. Berrangé
>
> diff --git a/configure b/configure
> index 5e7b76e3a1..2343d629ec 100755
> --- a/configure
> +++ b/configure
> @@ -1190,7 +1190,6 @@ fi
> : ${cross_cc_cflags_armeb="-mbig-endian"}
> : ${cross_cc_hexagon="hexagon-unknown-linux-musl-clang"}
> : ${cross_cc_cflags_hexagon="-mv73 -O2 -static"}
> -: ${cross_cc_cflags_i386="-m32"}
> : ${cross_cc_cflags_ppc="-m32 -mbig-endian"}
> : ${cross_cc_cflags_ppc64="-m64 -mbig-endian"}
> : ${cross_cc_ppc64le="$cross_cc_ppc64"}
> @@ -1308,7 +1307,7 @@ probe_target_compiler() {
> ;;
>i386)
> container_image=debian-i686-cross
> -container_cross_prefix=
> +container_cross_prefix=i686-linux-gnu-
> ;;
>loongarch64)
> container_image=debian-loongarch-cross
> @@ -1394,7 +1393,6 @@ probe_target_compiler() {
>case "$target_arch:$cpu" in
> aarch64_be:aarch64 | \
> armeb:arm | \
> -i386:x86_64 | \
> mips*:mips64 | \
> ppc*:ppc64 | \
> sparc:sparc64 | \
I kinda wonder if we have people using the rest of this arch compat
stuff too ? With debian making it easy to parallel install the full
cross-arch toolchains + matching libraries, it shouldn't be needed in
general for any arch ? Getting rid of QEMU specific special cases
like this in configure would be nice.
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Converting images to stdout
Hi, I haven't written here in a while :) but I have something small that I would like to discuss. Using qemu-img to convert an image and writing the result directly to stdout is a question that has already been raised in the past (see [1] for an example) and it's clear that it's generally not possible because the images need to be seekable. While I think that there's almost certainly no generic way to do something like that for every combination of input and output formats, I do think that it should be relatively easy to produce a qcow2 file directly to stdout as long as the input file is on disk. I'm interested in this use case, and I think that the method would be as simple as this: 1. Decide a cluster size for the output qcow2 file. 2. Read the input file once to determine which clusters need to be allocated in the output file and which ones don't. 3. That infomation is enough to determine the number and contents of the refcount table, refcount blocks, and L1/L2 tables. 4. Write the qcow2 header + metadata + allocated data to stdout. Since this would be qcow2-specific I would probably implement this as a separate tool instead of adding it directly to qemu-img. This could go to the scripts/ directory because I can imagine that such a tool could be useful for other people. Because this would be an external tool it would only support a qcow2 file with the default options. Other features like compression would be out of scope. For the same reason the input would be a raw file for simplicity, other input files could be presented in raw format using qemu-storage-daemon. And that's the general idea, comments and questions are welcome. Thanks! Berto [1] https://lists.nongnu.org/archive/html/qemu-discuss/2020-01/msg00014.html
[RFC PATCH] tests/tcg: finesse the registers check for "hidden" regs
The reason the ppc64 and s390x test where failing was because gdb
hides them although they are still accessible via regnum. We can
re-arrange the test a little bit and include these two arches in our
test.
We still don't explicitly fail for registers that just disappear like
in the ARM case:
xml-tdesc has 228 registers
remote-registers has 219 registers
of which 0 are hidden
{'name': 'CNTP_CVAL', 'regnum': 96} wasn't seen in remote-registers
{'name': 'CNTV_CVAL', 'regnum': 101} wasn't seen in remote-registers
{'name': 'PAR', 'regnum': 113} wasn't seen in remote-registers
{'name': 'CPUACTLR', 'regnum': 114} wasn't seen in remote-registers
{'name': 'CPUECTLR', 'regnum': 127} wasn't seen in remote-registers
{'name': 'CPUMERRSR', 'regnum': 140} wasn't seen in remote-registers
{'name': 'TTBR1', 'regnum': 148} wasn't seen in remote-registers
{'name': 'L2MERRSR', 'regnum': 161} wasn't seen in remote-registers
{'name': 'TTBR0', 'regnum': 168} wasn't seen in remote-registers
Signed-off-by: Alex Bennée
Cc: Ilya Leoshkevich
Cc: qemu-s3...@nongnu.org
Cc: Nicholas Piggin
Cc: Daniel Henrique Barboza
Cc: qemu-...@nongnu.org
Cc: Luis Machado
---
tests/tcg/multiarch/gdbstub/registers.py | 80 ++--
tests/tcg/ppc64/Makefile.target | 7 ---
tests/tcg/s390x/Makefile.target | 4 --
3 files changed, 61 insertions(+), 30 deletions(-)
diff --git a/tests/tcg/multiarch/gdbstub/registers.py
b/tests/tcg/multiarch/gdbstub/registers.py
index ff6076b09e..342d6fd78f 100644
--- a/tests/tcg/multiarch/gdbstub/registers.py
+++ b/tests/tcg/multiarch/gdbstub/registers.py
@@ -44,7 +44,6 @@ def fetch_xml_regmap():
total_regs = 0
reg_map = {}
-frame = gdb.selected_frame()
tree = ET.fromstring(xml)
for f in tree.findall("feature"):
@@ -61,12 +60,8 @@ def fetch_xml_regmap():
for r in regs:
name = r.attrib["name"]
regnum = int(r.attrib["regnum"])
-try:
-value = frame.read_register(name)
-except ValueError:
-report(False, f"failed to read reg: {name}")
-entry = { "name": name, "initial": value, "regnum": regnum }
+entry = { "name": name, "regnum": regnum }
if name in reg_map:
report(False, f"duplicate register {entry} vs {reg_map[name]}")
@@ -80,6 +75,15 @@ def fetch_xml_regmap():
return reg_map
+def get_register_by_regnum(reg_map, regnum):
+"""
+Helper to find a register from the map via its XML regnum
+"""
+for regname, entry in reg_map.items():
+if entry['regnum'] == regnum:
+return entry
+return None
+
def crosscheck_remote_xml(reg_map):
"""
Cross-check the list of remote-registers with the XML info.
@@ -90,6 +94,7 @@ def crosscheck_remote_xml(reg_map):
total_regs = len(reg_map.keys())
total_r_regs = 0
+total_r_elided_regs = 0
for r in r_regs:
fields = r.split()
@@ -100,6 +105,15 @@ def crosscheck_remote_xml(reg_map):
r_name = fields[0]
r_regnum = int(fields[6])
+# Some registers are "hidden" so don't have a name
+# although they still should have a register number
+if r_name == "''":
+total_r_elided_regs += 1
+x_reg = get_register_by_regnum(reg_map, r_regnum)
+if x_reg is not None:
+x_reg["hidden"] = True
+continue
+
# check in the XML
try:
x_reg = reg_map[r_name]
@@ -118,14 +132,40 @@ def crosscheck_remote_xml(reg_map):
# registers on a 32 bit machine. Also print what is missing to
# help with debug.
if total_regs != total_r_regs:
-print(f"xml-tdesc has ({total_regs}) registers")
-print(f"remote-registers has ({total_r_regs}) registers")
+print(f"xml-tdesc has {total_regs} registers")
+print(f"remote-registers has {total_r_regs} registers")
+print(f"of which {total_r_elided_regs} are hidden")
for x_key in reg_map.keys():
x_reg = reg_map[x_key]
-if "seen" not in x_reg:
+if "hidden" in x_reg:
+print(f"{x_reg} elided by gdb")
+elif "seen" not in x_reg:
print(f"{x_reg} wasn't seen in remote-registers")
+def initial_register_read(reg_map):
+"""
+Do an initial read of all registers that we know gdb cares about
+(so ignore the elided ones).
+"""
+frame = gdb.selected_frame()
+
+for e in reg_map.values():
+name = e["name"]
+regnum = e["regnum"]
+
+try:
+if "hidden" in e:
+value = frame.read_register(regnum)
+e["initial"] = value
+elif "seen" in e:
+value = frame.read_register(name)
+e["initial"] = value
+
+except ValueError:
+
[RFC PATCH] configure: don't try a "native" cross for i386
As 32 bit x86 become rarer we are starting to run into problems with
search paths. Although we switched to a Debian container we still
favour the native CC on a Bookworm host. As a result we have a broken
cross compile setup which then fails to build with:
BUILD i386-linux-user guest-tests
In file included from /usr/include/linux/stat.h:5,
from /usr/include/bits/statx.h:31,
from /usr/include/sys/stat.h:465,
from
/home/alex/lsrc/qemu.git/tests/tcg/multiarch/linux/linux-test.c:28:
/usr/include/linux/types.h:5:10: fatal error: asm/types.h: No such file or
directory
5 | #include
| ^
compilation terminated.
make[1]: *** [Makefile:119: linux-test] Error 1
make: *** [/home/alex/lsrc/qemu.git/tests/Makefile.include:50:
build-tcg-tests-i386-linux-user] Error 2
So lets stop trying to be cute and honour cross_prefix_i386 when
searching locally. We also need to ensure we are using the correct
prefix if we do end up using the container version. We can also drop
the extra CFLAGS while we are at it.
Fixes: 791e6fedc5 (tests/docker: replace fedora-i386 with debian-i686)
Signed-off-by: Alex Bennée
---
configure | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/configure b/configure
index 5e7b76e3a1..2343d629ec 100755
--- a/configure
+++ b/configure
@@ -1190,7 +1190,6 @@ fi
: ${cross_cc_cflags_armeb="-mbig-endian"}
: ${cross_cc_hexagon="hexagon-unknown-linux-musl-clang"}
: ${cross_cc_cflags_hexagon="-mv73 -O2 -static"}
-: ${cross_cc_cflags_i386="-m32"}
: ${cross_cc_cflags_ppc="-m32 -mbig-endian"}
: ${cross_cc_cflags_ppc64="-m64 -mbig-endian"}
: ${cross_cc_ppc64le="$cross_cc_ppc64"}
@@ -1308,7 +1307,7 @@ probe_target_compiler() {
;;
i386)
container_image=debian-i686-cross
-container_cross_prefix=
+container_cross_prefix=i686-linux-gnu-
;;
loongarch64)
container_image=debian-loongarch-cross
@@ -1394,7 +1393,6 @@ probe_target_compiler() {
case "$target_arch:$cpu" in
aarch64_be:aarch64 | \
armeb:arm | \
-i386:x86_64 | \
mips*:mips64 | \
ppc*:ppc64 | \
sparc:sparc64 | \
--
2.39.2
[PATCH v2] hw/intc/arm_gicv3: ICC_PMR_EL1 high bits should be RAZ
The ICC_PMR_ELx and ICV_PMR_ELx bit masks returned from
ic{c,v}_fullprio_mask should technically also remove any
bit above 7 as these are marked reserved (read 0) and should
therefore should not be written as anything other than 0.
This was noted during a run of a proprietary test system and
discused on the mailing list [1] and initially thought not to
be an issue due to RES0 being technically allowed to be
written to and read back as long as the implementation does
not use the RES0 bits. It is very possible that the values
are used in comparison without masking, as pointed out by
Peter in [2], if (cs->hppi.prio >= cs->icc_pmr_el1) may well
do the wrong thing.
Masking these values in ic{c,v}_fullprio_mask() should fix
this and prevent any future problems with playing with the
values.
[1]: https://lists.nongnu.org/archive/html/qemu-arm/2023-11/msg00607.html
[2]: https://lists.nongnu.org/archive/html/qemu-arm/2023-11/msg00737.html
Signed-off-by: Ben Dooks
Suggested-by: Peter Maydell
---
v2:
- fixes as suggested by Peter Maydell to include icv_fullprio_mask()
---
hw/intc/arm_gicv3_cpuif.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
index d07b13eb27..ab1a00508e 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/intc/arm_gicv3_cpuif.c
@@ -146,7 +146,7 @@ static uint32_t icv_fullprio_mask(GICv3CPUState *cs)
* with the group priority, whose mask depends on the value of VBPR
* for the interrupt group.)
*/
-return ~0U << (8 - cs->vpribits);
+return (~0U << (8 - cs->vpribits)) & 0xff;
}
static int ich_highest_active_virt_prio(GICv3CPUState *cs)
@@ -803,7 +803,7 @@ static uint32_t icc_fullprio_mask(GICv3CPUState *cs)
* with the group priority, whose mask depends on the value of BPR
* for the interrupt group.)
*/
-return ~0U << (8 - cs->pribits);
+return (~0U << (8 - cs->pribits)) & 0xff;
}
static inline int icc_min_bpr(GICv3CPUState *cs)
--
2.37.2.352.g3c44437643
Re: [PATCH-for-8.2] hw/net/can/xlnx-zynqmp: Avoid underflow while popping TX FIFO
Hi Philippe,
On 2023-11-16 16:44, Philippe Mathieu-Daudé wrote:
Hi Francisco,
On 16/11/23 15:17, Francisco Iglesias wrote:
Hi Philippe, good catch!
Well this was fuzzed by Qiang Liu.
On 2023-11-15 16:17, Philippe Mathieu-Daudé wrote:
Per
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Message-Format
Message Format
The same message format is used for RXFIFO, TXFIFO, and TXHPB.
Each message includes four words (16 bytes). Software must read
and write all four words regardless of the actual number of data
bytes and valid fields in the message.
There is no mention in this reference manual about what the
hardware does when not all four words are written. To fix the
reported underflow behavior when DATA2 register is written,
I choose to fill the data with the previous content of the
ID / DLC / DATA1 registers, which is how I expect hardware
would do.
Note there is no hardware flag raised under such condition.
Reported-by: Qiang Liu
Fixes: 98e5d7a2b7 ("hw/net/can: Introduce Xilinx ZynqMP CAN controller")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1425
Signed-off-by: Philippe Mathieu-Daudé
---
Tested with the CAN tests from 'make check-qtest-aarch64'
---
hw/net/can/xlnx-zynqmp-can.c | 49 +---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/hw/net/can/xlnx-zynqmp-can.c b/hw/net/can/xlnx-zynqmp-can.c
index e93e6c5e19..58938b574e 100644
--- a/hw/net/can/xlnx-zynqmp-can.c
+++ b/hw/net/can/xlnx-zynqmp-can.c
@@ -434,6 +434,51 @@ static bool tx_ready_check(XlnxZynqMPCANState *s)
return true;
}
+static void read_tx_frame(XlnxZynqMPCANState *s, Fifo32 *fifo,
uint32_t *data)
+{
+ unsigned used = fifo32_num_used(fifo);
For the case when there are multiple frames in the fifo we need to
swap above to:
unsigned used = fifo32_num_used(fifo) > CAN_FRAME_SIZE ? 0 :
fifo32_num_used(fifo);
Isn't this ...
With above minor modification:
Reviewed-by: Francisco Iglesias
Best regards,
Francisco
+ bool is_txhpb = fifo == >txhpb_fifo;
+
+ assert(used > 0);
+ used %= CAN_FRAME_SIZE;
... done here?
Ah yes, I was thinking that the first frame would be correct if for
example used == 6, but yes that is not possible to know (can be the
second frame that is ok). Feel free to add my reviewed-by to patch.
Thanks,
Best regards,
Francisco
+ /*
+ * Frame Message Format
+ *
+ * Each frame includes four words (16 bytes). Software must read
and write
+ * all four words regardless of the actual number of data bytes
and valid
+ * fields in the message.
+ * If software misbehave (not writting all four words), we use
the previous
+ * registers content to initialize each missing word.
+ */
+ if (used > 0) {
+ /* ID, DLC, DATA1 missing */
+ data[0] = s->regs[is_txhpb ? R_TXHPB_ID : R_TXFIFO_ID];
+ } else {
+ data[0] = fifo32_pop(fifo);
+ }
+ if (used == 1 || used == 2) {
+ /* DLC, DATA1 missing */
+ data[1] = s->regs[is_txhpb ? R_TXHPB_DLC : R_TXFIFO_DLC];
+ } else {
+ data[1] = fifo32_pop(fifo);
+ }
+ if (used == 1) {
+ /* DATA1 missing */
+ data[2] = s->regs[is_txhpb ? R_TXHPB_DATA1 : R_TXFIFO_DATA1];
+ } else {
+ data[2] = fifo32_pop(fifo);
+ }
+ /* DATA2 triggered the transfer thus is always available */
+ data[3] = fifo32_pop(fifo);
+
+ if (used) {
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Incomplete CAN frame (only %u/%u slots
used)\n",
+ TYPE_XLNX_ZYNQMP_CAN, used, CAN_FRAME_SIZE);
+ }
+}
Re: [PATCH] monitor: flush messages on abort
On 11/16/2023 10:14 AM, Markus Armbruster wrote:
> Steven Sistare writes:
>> On 11/15/2023 11:15 AM, Markus Armbruster wrote:
>>> Steven Sistare writes:
On 11/15/2023 3:41 AM, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
>> On Fri, Nov 03, 2023 at 03:51:00PM -0400, Steven Sistare wrote:
>>> On 11/3/2023 1:33 PM, Daniel P. Berrangé wrote:
On Fri, Nov 03, 2023 at 09:01:29AM -0700, Steve Sistare wrote:
> Buffered monitor output is lost when abort() is called. The pattern
> error_report() followed by abort() occurs about 60 times, so valuable
> information is being lost when the abort is called in the context of a
> monitor command.
I'm curious, was there a particular abort() scenario that you hit ?
>>>
>>> Yes, while tweaking the suspended state, and forgetting to add
>>> transitions:
>>>
>>> error_report("invalid runstate transition: '%s' -> '%s'",
>>> abort();
>>>
>>> But I have previously hit this for other errors.
>
> Can you provide a reproducer?
I sometimes hit this when developing new code. I do not have a reproducer
for upstream
branches. The patch is aimed at helping developers, not users.
>>>
>>> I'm asking because I can't see how the error message could be lost. A
>>> reproducer would let me find out. "Apply this set of broken patches,
>>> then do that" would serve.
>>
>> $ patch -p1 << EOF
>> diff --git a/monitor/qmp-cmds.c b/monitor/qmp-cmds.c
>> index b0f948d..c9a3aee 100644
>> --- a/monitor/qmp-cmds.c
>> +++ b/monitor/qmp-cmds.c
>> @@ -47,8 +47,12 @@ void qmp_quit(Error **errp)
>> qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_QMP_QUIT);
>> }
>>
>> +#include "qemu/error-report.h"
>> +
>> void qmp_stop(Error **errp)
>> {
>> +error_report("injected failure");
>> +abort();
>> /* if there is a dump in background, we should wait until the dump
>> * finished */
>> if (qemu_system_dump_in_progress()) {
>> EOF
>>
>> # This example loses the error message:
>>
>> $ args='-display none -chardev
>> socket,id=mon1,server=on,path=mon1.sock,wait=off -mon mon1,mode=control'
>> $ qemu-system-x86_64 $args < /dev/null &
>> [1] 18048
>> $ echo '{"execute":"qmp_capabilities"}
>> {"execute":"human-monitor-command","arguments":{"command-line":"stop"}}' |
>> ncat -U mon1.sock
>> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 8},
>> "package": "v8.1.0-2976-g4025fde-dirty"}, "capabilities": ["oob"]}}
>> {"return": {}}
>> Ncat: Connection reset by peer.
>> $
>> [1]+ Aborted qemu-system-x86_64 $args < /dev/null
>>
>>
>> # This example preserves the error message. I include it to show the
>> ncat-based test is valid.
>>
>> $ qemu-system-x86_64 $args < /dev/null &
>> [1] 18060
>> $ echo '{"execute":"qmp_capabilities"} {"execute":"stop"}' | ncat -U
>> mon1.sock
>> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 8},
>> "package": "v8.1.0-2976-g4025fde-dirty"}, "capabilities": ["oob"]}}
>> {"return": {}}
>> injected failure<= qemu stderr
>> Ncat: Connection reset by peer.
>> $
>> [1]+ Aborted qemu-system-x86_64 $args < /dev/null
>>
>> - Steve
>
> Reproduced, thanks!
>
> Confirms my reading of the code. Two cases:
>
> 1. Normal monitor output
>
>Flushed on newline. A partial last line can be lost on crash or
>exit().
>
>Works as intended.
>
> 2. Output being captured for QMP command human-monitor-command
>
>Never flushed. Instead, the entire buffer is included in the
>command's success response. Naturally there is no response on crash.
>
>Works as intended.
>
> Here's how to fish unflushed output out of a core dump:
>
> (gdb) bt
> #0 0x7efeba52fecc in __pthread_kill_implementation () at
> /lib64/libc.so.6
> #1 0x7efeba4dfab6 in raise () at /lib64/libc.so.6
> #2 0x7efeba4c97fc in abort () at /lib64/libc.so.6
> #3 0x55588dcc848c in qmp_stop (errp=0x0) at ../monitor/qmp-cmds.c:53
> #4 0x55588dcc36ab in hmp_stop (mon=0x7ffc01d47cc0,
> qdict=0x555891d19200)
> at ../monitor/hmp-cmds.c:119
> #5 0x55588dcc714e in handle_hmp_command_exec
> (mon=0x7ffc01d47cc0, cmd=0x55588f0689d0 ,
> qdict=0x555891d19200) at ../monitor/hmp.c:1106
> #6 0x55588dcc737b in handle_hmp_command
> (mon=0x7ffc01d47cc0, cmdline=0x7efea80036f4 "") at
> ../monitor/hmp.c:1158
> #7 0x55588dcc8922 in qmp_human_monitor_command
> (command_line=0x7efea80036f0 "stop", has_cpu_index=false,
> cpu_index=0, errp=0x7ffc01d47dd0) at ../monitor/qmp-cmds.c:184
>
> [...]
>
> (gdb) up 4
> #4 0x55588dcc36ab in hmp_stop (mon=0x7ffc01d47cc0,
> qdict=0x555891d19200)
> at ../monitor/hmp-cmds.c:119
> 119 qmp_stop(NULL);
> (gdb) p mon->outbuf
> $1 = (GString *) 0x555890a65260
>
Re: [PULL v3 09/25] ui/console: allow to override the default VC
On Thu, 2023-11-09 at 11:45 +, David Woodhouse wrote:
> On Thu, 2023-11-09 at 19:34 +0800, Stefan Hajnoczi wrote:
> > On Thu, 9 Nov 2023 at 19:10, David Woodhouse wrote:
> > >
> > > On Tue, 2023-11-07 at 14:15 +0400, marcandre.lur...@redhat.com wrote:
> > > > From: Marc-André Lureau
> > > >
> > > > If a display is backed by a specialized VC, allow to override the
> > > > default "vc:80Cx24C".
> > > >
> > > > As suggested by Paolo, if the display doesn't implement a VC (get_vc()
> > > > returns NULL), use a fallback that will use a muxed console on stdio.
> > > >
> > > > This changes the behaviour of "qemu -display none", to create a muxed
> > > > serial/monitor by default (on TTY & not daemonized).
> > > >
> > > > Signed-off-by: Marc-André Lureau
> > > > Reviewed-by: Thomas Huth
> > >
> > > Hrm. This breaks the command line documented at
> > > https://qemu-project.gitlab.io/qemu/system/i386/xen.html
> > >
> > > $ ./qemu-system-x86_64 --accel
> > > kvm,xen-version=0x40011,kernel-irqchip=split \
> > > -display none -chardev stdio,mux=on,id=char0,signal=off -mon char0 \
> > > -device xen-console,chardev=char0 -drive file=${GUEST_IMAGE},if=xen
> > >
> > > qemu-system-x86_64: cannot use stdio by multiple character devices
> > > qemu-system-x86_64: could not connect serial device to character backend
> > > 'stdio'
> > >
> > > Can we make it create a Xen console by default, instead of a serial
> > > port? And/or make it *not* use stdio if something else on the command
> > > line already does?
> >
> > I have filed this in QEMU's bug tracker so it's not forgotten:
> > https://gitlab.com/qemu-project/qemu/-/issues/1974
> >
> > Here is the list of open 8.2 bugs:
> > https://gitlab.com/qemu-project/qemu/-/milestones/10
> >
> > Stefan
>
> Thanks. Added a link there to the patch I just sent, along with a note
> suggesting that perhaps we should go a bit further.
>
> We're changing the QEMU behaviour in 8.2 to add these new devices using
> stdio, and *failing* if something else on the command line already used
> stdio.
>
> My patch avoids adding a serial port if there's already a xen-console,
> which is all well and good. But surely we shouldn't *fail* if something
> else is already using stdio; we should just *not* add the new default
> serial port? This might break other command lines which use stdio but
> *not* for a serial port? This breaks too:
>
> $ ./qemu-system-x86_64 -display none -chardev stdio,id=char0
> qemu-system-x86_64: cannot use stdio by multiple character devices
> qemu-system-x86_64: could not connect serial device to character backend
> 'mon:stdio'
Regardless of possible further improvements, please could I have a
review for the patch at
https://lore.kernel.org/qemu-devel/20231115172723.1161679-3-dw...@infradead.org/
which at least makes the documented command line work again.
Thanks.
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH-for-9.0] hw/core: Add machine_class_default_cpu_type()
On 11/16/23 08:37, Philippe Mathieu-Daudé wrote: Add a helper to return a machine default CPU type. If this machine is restricted to a single CPU type, use it as default, obviously. Signed-off-by: Philippe Mathieu-Daudé --- include/hw/boards.h | 6 ++ hw/core/machine.c | 8 system/vl.c | 2 +- 3 files changed, 15 insertions(+), 1 deletion(-) Reviewed-by: Richard Henderson r~
Re: [PULL 0/2] Net patches
On Tue, 2023-11-14 at 11:09 +0800, Jason Wang wrote: > The following changes since commit 69680740eafa1838527c90155a7432d51b8ff203: > > Merge tag 'qdev-array-prop' of https://repo.or.cz/qemu/kevin into staging > (2023-11-11 11:23:25 +0800) > > are available in the git repository at: > > https://github.com/jasowang/qemu.git tags/net-pull-request > > for you to fetch changes up to d90014fc337ab77f37285b1a30fd4f545056be0a: > > igb: Add Function Level Reset to PF and VF (2023-11-13 15:33:37 +0800) Hi Jason, I note this doesn't include the net_cleanup() fix from https://lore.kernel.org/qemu-devel/20231115172723.1161679-2-dw...@infradead.org/ Do you mind if I submit that in a pull request with the other fixes from that series? Thanks. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH-for-8.2? 0/6] hw/arm/stm32xxx: Report error when incorrect CPU is used
On 11/15/23 15:21, Philippe Mathieu-Daudé wrote: Philippe Mathieu-Daudé (6): hw/arm/stm32f405: Report error when incorrect CPU is used hw/arm/stm32f205: Report error when incorrect CPU is used hw/arm/stm32f100: Report error when incorrect CPU is used hw/arm/msf2: Simplify setting MachineClass::valid_cpu_types[] hw/arm/npcm7xx_boards: Simplify setting MachineClass::valid_cpu_types[] hw/arm/musca: Simplify setting MachineClass::valid_cpu_types[] With the const fix, Series Reviewed-by: Richard Henderson r~
Re: [PATCH] hw/intc/arm_gicv3: ICC_PMR_EL1 high bits should be RAZ
On Tue, 14 Nov 2023 at 17:23, Ben Dooks wrote:
>
> On 14/11/2023 17:14, Peter Maydell wrote:
> > On Tue, 14 Nov 2023 at 16:54, Ben Dooks wrote:
> >>
> >> The ICC_PMR_ELx bit msak returned from icc_fullprio_mask
> >> should technically also remove any bit above 7 as these
> >> are marked reserved (read 0) and should therefore should
> >> not be written as anything other than 0.
> >>
> >> Signed-off-by: Ben Dooks
> >> ---
> >> hw/intc/arm_gicv3_cpuif.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
> >> index d07b13eb27..986044df79 100644
> >> --- a/hw/intc/arm_gicv3_cpuif.c
> >> +++ b/hw/intc/arm_gicv3_cpuif.c
> >> @@ -803,7 +803,7 @@ static uint32_t icc_fullprio_mask(GICv3CPUState *cs)
> >>* with the group priority, whose mask depends on the value of BPR
> >>* for the interrupt group.)
> >>*/
> >> -return ~0U << (8 - cs->pribits);
> >> +return (~0U << (8 - cs->pribits)) & 0xff;
> >> }
> >
> > The upper bits of ICC_PMR_ELx are defined as RES0, which has a
> > complicated technical definition which you can find in the GIC
> > architecture specification glossary. It's valid for RES0 bits to
> > be implemented as reads-as-written, which is the way our current
> > implementation works. Valid guest code should never be writing
> > any non-zero value into those bits.
>
> Yeah, got some proprietary test code that is trying write-1 and
> then assuming read-0.
>
> > What problem are you running into that you're trying to fix
> > with this patch? If our implementation misbehaves as a result
> > of letting these high bits through into cs->icc_pmr_el1 that
> > would be a good reason for making the change.
>
> See above, local test code issue.
Ah, right. That is technically bogus, but it wouldn't be
the first time test case code explored the UNPREDICTABLE
and IMPDEF reaches of the architecture :-)
Looking at our GIC code, we *will* do something wrong if the guest
writes to these high bits, because later on we do checks like
if (cs->hppi.prio >= cs->icc_pmr_el1) {
that will do the wrong thing. So I think we do want to mask
out these high bits (being easier than trying to ignore them
later). But I think we should be consistent between the
icc and icv code paths.
So if you want to write a patch that either:
* masks out the high bits in both icc_fullprio_mask() and
icv_fullprio_mask()
* clears out those high bits directly in icc_pmr_write()
(whichever you think looks nicer) I'd be happy to take that upstream.
(Currently icv_pmr_write() happens to be written in a way that
it discards those high bits as part of the deposit64() into
ich_vmcr_el2.)
thanks
-- PMM
[PATCH-for-9.0] hw/core: Add machine_class_default_cpu_type()
Add a helper to return a machine default CPU type.
If this machine is restricted to a single CPU type,
use it as default, obviously.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/boards.h | 6 ++
hw/core/machine.c | 8
system/vl.c | 2 +-
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/include/hw/boards.h b/include/hw/boards.h
index da85f86efb..160a10036e 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -24,6 +24,12 @@ OBJECT_DECLARE_TYPE(MachineState, MachineClass, MACHINE)
extern MachineState *current_machine;
+/**
+ * machine_class_default_cpu_type: Return the machine default CPU type.
+ * @mc: Machine class
+ */
+const char *machine_class_default_cpu_type(MachineClass *mc);
+
void machine_add_audiodev_property(MachineClass *mc);
void machine_run_board_init(MachineState *machine, const char *mem_path, Error
**errp);
bool machine_usb(MachineState *machine);
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 0c17398141..baf25c3fc5 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -1387,6 +1387,14 @@ out:
return r;
}
+const char *machine_class_default_cpu_type(MachineClass *mc)
+{
+if (mc->valid_cpu_types && !mc->valid_cpu_types[1]) {
+/* Only a single CPU type allowed: use it as default. */
+return mc->valid_cpu_types[0];
+}
+return mc->default_cpu_type;
+}
void machine_run_board_init(MachineState *machine, const char *mem_path, Error
**errp)
{
diff --git a/system/vl.c b/system/vl.c
index 5af7ced2a1..1c28162b21 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -3730,7 +3730,7 @@ void qemu_init(int argc, char **argv)
migration_object_init();
/* parse features once if machine provides default cpu_type */
-current_machine->cpu_type = machine_class->default_cpu_type;
+current_machine->cpu_type = machine_class_default_cpu_type(machine_class);
if (cpu_option) {
current_machine->cpu_type = parse_cpu_option(cpu_option);
}
--
2.41.0
[PATCH v2] system/memory: use ldn_he_p/stn_he_p
Using direct pointer dereferencing can allow for unaligned accesses,
which was seen during execution with sanitizers enabled.
Reviewed-by: Chris Rauer
Reviewed-by: Peter Foley
Signed-off-by: Patrick Venture
Cc: qemu-sta...@nongnu.org
---
v2: changed commit mesage to be more accurate and switched from using
memcpy to using the endian appropriate assignment load and store.
---
system/memory.c | 32 ++--
1 file changed, 2 insertions(+), 30 deletions(-)
diff --git a/system/memory.c b/system/memory.c
index 304fa843ea..affc7ea83c 100644
--- a/system/memory.c
+++ b/system/memory.c
@@ -1339,22 +1339,7 @@ static uint64_t memory_region_ram_device_read(void
*opaque,
hwaddr addr, unsigned size)
{
MemoryRegion *mr = opaque;
-uint64_t data = (uint64_t)~0;
-
-switch (size) {
-case 1:
-data = *(uint8_t *)(mr->ram_block->host + addr);
-break;
-case 2:
-data = *(uint16_t *)(mr->ram_block->host + addr);
-break;
-case 4:
-data = *(uint32_t *)(mr->ram_block->host + addr);
-break;
-case 8:
-data = *(uint64_t *)(mr->ram_block->host + addr);
-break;
-}
+uint64_t data = ldn_he_p(mr->ram_block->host + addr, size);
trace_memory_region_ram_device_read(get_cpu_index(), mr, addr, data, size);
@@ -1368,20 +1353,7 @@ static void memory_region_ram_device_write(void *opaque,
hwaddr addr,
trace_memory_region_ram_device_write(get_cpu_index(), mr, addr, data,
size);
-switch (size) {
-case 1:
-*(uint8_t *)(mr->ram_block->host + addr) = (uint8_t)data;
-break;
-case 2:
-*(uint16_t *)(mr->ram_block->host + addr) = (uint16_t)data;
-break;
-case 4:
-*(uint32_t *)(mr->ram_block->host + addr) = (uint32_t)data;
-break;
-case 8:
-*(uint64_t *)(mr->ram_block->host + addr) = data;
-break;
-}
+stn_he_p(mr->ram_block->host + addr, size, data);
}
static const MemoryRegionOps ram_device_mem_ops = {
--
2.43.0.rc0.421.g78406f8d94-goog
Re: [PATCH v5 03/11] hw/misc: Add qtest for NPCM7xx PCI Mailbox
On Wed, 15 Nov 2023 at 01:35, kft...@nuvoton.com wrote: > Peter Maydell wrote: > On Tue, 14 Nov 2023 at 01:24, kft...@nuvoton.com wrote: > > Signed-off-by: Tyrone Ting > > Hi; can you clarify what you mean with this Signed-off-by: tag? > Generally we use those where either you're the author of the code or else > when you're taking somebody else's patch and including it in work you are > sending to the list, and it doesn't seem like either of those are the case > here. > Thank you for your comments. In the email thread " [PATCH v4 00/11] > Implementation of NPI Mailbox and GMAC Networking Module", > it says " Hi; I'm afraid this is going to miss the 8.2 release, because it is > still missing any review from Google or Nuvoton people." > > Is it okay to post "Acked by:" or "Reviewed by:" by someone from Nuvoton? If you've reviewed the code and believe it to be good (i.e., it doesn't need any changes), then, yes, by all means please post your Reviewed-by tag. Anybody who has done the work of code review on a patch can send in a Reviewed-by tag to say they've done it. If you've reviewed the code and think there's something that needs to be changed or that you have a question about that, you can reply to the patch to say so. We basically follow the same process here that the Linux kernel does; you can read about the various tags here: https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes The meaning of "Acked-by:" is a little more disputed; personally I use that for "I haven't reviewed this code, but as a maintainer of the subsystem I don't object to it". thanks -- PMM
RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object oriented
> -Original Message-
> From: ltaylorsimp...@gmail.com
> Sent: Wednesday, November 15, 2023 4:03 PM
> To: Brian Cain ; qemu-devel@nongnu.org
> Cc: Matheus Bernardino (QUIC) ; Sid Manning
> ; richard.hender...@linaro.org; phi...@linaro.org;
> a...@rev.ng; a...@rev.ng
> Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> oriented
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of
> any links or attachments, and do not enable macros.
>
> > -Original Message-
> > From: Brian Cain
> > Sent: Wednesday, November 15, 2023 1:51 PM
> > To: Taylor Simpson ; qemu-devel@nongnu.org
> > Cc: Matheus Bernardino (QUIC) ; Sid
> > Manning ; richard.hender...@linaro.org;
> > phi...@linaro.org; a...@rev.ng; a...@rev.ng
> > Subject: RE: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> > oriented
> >
> >
> >
> > > -Original Message-
> > > From: Taylor Simpson
> > > Sent: Thursday, November 9, 2023 3:26 PM
> > > To: qemu-devel@nongnu.org
> > > Cc: Brian Cain ; Matheus Bernardino (QUIC)
> > > ; Sid Manning ;
> > > richard.hender...@linaro.org; phi...@linaro.org; a...@rev.ng;
> > a...@rev.ng;
> > > ltaylorsimp...@gmail.com
> > > Subject: [RFC PATCH] Hexagon (target/hexagon) Make generators object
> > > oriented
> > >
> > > RFC - This patch handles gen_tcg_funcs.py. I'd like to get comments
> > > on the general approach before working on the other Python scripts.
> > >
> > > The generators are generally a bunch of Python if-then-else
> > > statements based on the regtype and regid. Encapsulate regtype/regid
> > > into a class hierarchy. Clients lookup the register and invoke
> > > methods.
> > >
> > > This has several advantages for making the code easier to read,
> > > understand, and maintain
> > > - The class name makes it more clear what the operand does
> > > - All the methods for a given type of operand are together
> > > - Don't need as many calls to hex_common.bad_register
> > > - We can remove the functions in hex_common that use regtype/regid
> > > (e.g., is_read)
> > >
> > > Signed-off-by: Taylor Simpson
> > > ---
> > > diff --git a/target/hexagon/hex_common.py
> > b/target/hexagon/hex_common.py
> > > index 0da65d6dd6..13ee55b6b2 100755
> > > --- a/target/hexagon/hex_common.py
> > > +++ b/target/hexagon/hex_common.py
> > > +class ModifierSource(Source):
> > > +def genptr_decl(self, f, tag, regno):
> > > +f.write(f"const int {self.regN} = insn->regno[{regno}];\n")
> > > +f.write(f"TCGv {self.regV} = hex_gpr[{self.regN} +
> > HEX_REG_M0];\n")
> > > +def idef_arg(self, declared):
> > > +declared.append(self.regV)
> > > +declared.append(self.regN)
> > > +
> >
> > IMO it's easier to reason about a function if it doesn't modify its inputs
> > and
> > instead it returns the transformed input. If idef_arg instead returned a
> > new
> > list or returned an iterable for the caller to catenate, it would be
> > clearer.
>
> We should figure out a better way to handle the special case of modifier
> registers. For every other register type,
> Idef_arg simply returns self.regV. For circular addressing, we also need the
> value of the corresponding CS register. Currently,
> we solve this by passing the register number so that idef-parser can get the
> value (i.e., hex_gpr[HEX_REG_CS0 + self.regN]).
>
> We could have idef-parser skip the circular addressing instructions (it
> already
> skips the bit-reverse instructions). That seems
> like a big hammer though. Any other thoughts?
>
>
> > > +class PredReadWrite(ReadWrite):
> > > +def genptr_decl(self, f, tag, regno):
> > > +f.write(f"const int {self.regN} = insn->regno[{regno}];\n")
> > > +f.write(f"TCGv {self.regV} = tcg_temp_new();\n")
> > > +f.write(f"tcg_gen_mov_tl({self.regV},
> > > hex_pred[{self.regN}]);\n")
> >
> > Instead of successive calls to f.write(), each passing their own string
> > with a
> > newline, use triple quotes:
> >
> > f.write(f"""const int {self.regN} = insn->regno[{regno}];
> > TCGv {self.regV} = tcg_temp_new();
> > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n""")
> >
> > If necessary/appropriate, you can also use textwrap.dedent() to make the
> > leading whitespace look appropriate:
> > https://docs.python.org/3/library/textwrap.html#textwrap.dedent
> >
> > import textwrap
> > ...
> > f.write(textwrap.dedent(f"""const int {self.regN} =
> > insn->regno[{regno}];
> > TCGv {self.regV} = tcg_temp_new();
> > tcg_gen_mov_tl({self.regV}, hex_pred[{self.regN}]);\n"""))
> >
>
> The indenting is for the readability of the output. We could dedent
> everything
> and run the result through the indent utility
> as idef-parser does. Not sure it's worth it though.
Regardless of textwrap.dedent(), I think the output is most readable with
triple-quotes. It's more readable than it is with multiple f.write("this
line\n") invocations.
The
Re: [PATCH v5 00/31] Unified CPU type check
On 16/11/23 14:35, Philippe Mathieu-Daudé wrote: Hi Gavin, On 15/11/23 00:55, Gavin Shan wrote: There are two places where the user specified CPU type is checked to see if it's supported or allowed by the board: machine_run_board_init() and mc->init(). We don't have to maintain two duplicate sets of logic. This series intends to move the check to machine_run_board_init() so that we have unified CPU type check. Gavin Shan (30): target/alpha: Remove 'ev67' CPU class target/hppa: Remove object_class_is_abstract() target: Remove 'oc == NULL' check cpu: Add helper cpu_model_from_type() cpu: Add generic cpu_list() target/alpha: Use generic cpu_list() target/arm: Use generic cpu_list() target/avr: Use generic cpu_list() target/cris: Use generic cpu_list() target/hexagon: Use generic cpu_list() target/hppa: Use generic cpu_list() target/loongarch: Use generic cpu_list() target/m68k: Use generic cpu_list() target/mips: Use generic cpu_list() target/openrisc: Use generic cpu_list() target/riscv: Use generic cpu_list() target/rx: Use generic cpu_list() target/sh4: Use generic cpu_list() target/tricore: Use generic cpu_list() target/xtensa: Use generic cpu_list() target: Use generic cpu_model_from_type() machine: Constify MachineClass::valid_cpu_types[i] I'm queuing patches 1-3 & 5-23 to my cpus-next tree. No need to repost them, please base them on my tree. I'll follow up with the branch link when I finish my testing and push it. Here are these patches queued: https://github.com/philmd/qemu.git branches/cpus-next I might queue more patches before the 9.0 merge window opens. Regards, Phil.
Re: [PATCH v5 03/31] cpu: Call object_class_dynamic_cast() once in cpu_class_by_name()
On 15/11/23 00:56, Gavin Shan wrote: From: Philippe Mathieu-Daudé For all targets, the CPU class returned from CPUClass::class_by_name() and object_class_dynamic_cast(oc, CPU_RESOLVING_TYPE) need to be compatible. Lets apply the check in cpu_class_by_name() for once, instead of having the check in CPUClass::class_by_name() for individual target. Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Gavin Shan Reviewed-by: Igor Mammedov Gavin, this patch is missing your S-o-b tag. Do you mind responding to this email with it? Thanks! --- hw/core/cpu-common.c | 8 +--- target/alpha/cpu.c | 3 --- target/arm/cpu.c | 4 +--- target/avr/cpu.c | 8 +--- target/cris/cpu.c | 4 +--- target/hexagon/cpu.c | 4 +--- target/hppa/cpu.c | 7 +-- target/loongarch/cpu.c | 8 +--- target/m68k/cpu.c | 4 +--- target/openrisc/cpu.c | 4 +--- target/riscv/cpu.c | 4 +--- target/tricore/cpu.c | 4 +--- target/xtensa/cpu.c| 4 +--- 13 files changed, 16 insertions(+), 50 deletions(-)
Re: [RFC PATCH v2 1/4] migration/multifd: Stop setting p->ioc before connecting
Fabiano Rosas wrote: > This is being shadowed but the assignments at > multifd_channel_connect() and multifd_tls_channel_connect() . > > Signed-off-by: Fabiano Rosas Reviewed-by: Juan Quintela
Re: [RFC PATCH 2/2] migration/multifd: Move semaphore release into main thread
Fabiano Rosas wrote: > Fabiano Rosas writes: > >> Peter Xu writes: >> >>> On Thu, Nov 09, 2023 at 01:58:56PM -0300, Fabiano Rosas wrote: >> I think we historically stumbled upon the fact that qemu_thread_join() >> is not the same as pthread_join(). The former takes a pointer and is not >> safe to call with a NULL QemuThread. That seems to be the reason for the >> p->running check before it. > > Scratch this part, the QemuThread is not a pointer. > > ...should it be? Because then we can test p->thread instead of > p->running, which would be more precise and would dispense the > thread_created flag. You still need to make sure that you don't join the thread twice. And we do the qemu_pthread_join() without any lock. Later, Juan.
Re: [PATCH-for-8.2 v4 09/10] hw/char/pl011: Add transmit FIFO to PL011State
Richard Henderson wrote:
> On 11/9/23 11:28, Philippe Mathieu-Daudé wrote:
>> @@ -436,6 +438,24 @@ static const VMStateDescription vmstate_pl011_clock = {
>> }
>> };
>> +static bool pl011_xmit_fifo_state_needed(void *opaque)
>> +{
>> +PL011State* s = opaque;
>> +
>> +return !fifo8_is_empty(>xmit_fifo);
>> +}
>> +
>> +static const VMStateDescription vmstate_pl011_xmit_fifo = {
>> +.name = "pl011/xmit_fifo",
>> +.version_id = 1,
>> +.minimum_version_id = 1,
>> +.needed = pl011_xmit_fifo_state_needed,
>> +.fields = (VMStateField[]) {
>> +VMSTATE_FIFO8(xmit_fifo, PL011State),
>> +VMSTATE_END_OF_LIST()
>> +}
>> +};
>> +
>> static int pl011_post_load(void *opaque, int version_id)
>> {
>> PL011State* s = opaque;
>> @@ -487,7 +507,11 @@ static const VMStateDescription vmstate_pl011 = {
>> .subsections = (const VMStateDescription * []) {
>> _pl011_clock,
>> NULL
>> -}
>> +},
>> +.subsections = (const VMStateDescription * []) {
>> +_pl011_xmit_fifo,
>> +NULL
>> +},
>> };
>
> It just occurred to me that you may need a vmstate_pl011 pre_load() to
> empty the FIFO, which will then be filled if and only if the saved
> vmstate_pl011_xmit_fifo subsection is present.
>
> Juan, have I got this correct about how migration would or should handle a
> missing subsection?
I hav'nt looked about how the device is created. But if it is created
with the fifo empty you don't need the pre_load().
I have no idea about this device, but sometimes it just happens that if
the fifo has data, you need to put an irq somewhere or mark it some
place that there is pending job on this device.
Later, Juan.
Re: [PATCH v2 4/5] tests/unit/test-io-task: Rename "qemu:dummy" to avoid colon in the name
On 16/11/23 14:14, Thomas Huth wrote: Type names should not contain special characters like ":" (so that they are easier to use with QAPI and other parts). We are going to forbid such names in an upcoming patch. Thus let's replace the ":" here with a "-". Signed-off-by: Thomas Huth --- tests/unit/test-io-task.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v2 3/5] memory: Remove "qemu:" prefix from the "qemu:ram-discard-manager" type name
On 16/11/23 14:14, Thomas Huth wrote: Type names should not contain special characters like ":". Let's remove the whole prefix here since it does not really seem to be helpful to have such a prefix here. The type name is only used internally for an interface, so the renaming should not affect the user interface or migration. Signed-off-by: Thomas Huth --- include/exec/memory.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [RFC PATCH 2/2] migration/multifd: Move semaphore release into main thread
Fabiano Rosas wrote:
> Peter Xu writes:
>
>> On Thu, Nov 09, 2023 at 01:58:56PM -0300, Fabiano Rosas wrote:
>>> We cannot operate on the multifd semaphores outside of the multifd
>>> channel thread
>>> because multifd_save_cleanup() can run in parallel and
>>> attempt to destroy the mutexes, which causes an assert.
>>>
>>> Looking at the places where we use the semaphores aside from the
>>> migration thread, there's only the TLS handshake thread and the
>>> initial multifd_channel_connect() in the main thread. These are places
>>> where creating the multifd channel cannot fail, so releasing the
>>> semaphores at these places only serves the purpose of avoiding a
>>> deadlock when an error happens before the channel(s) have started, but
>>> after the migration thread has already called
>>> multifd_send_sync_main().
>>>
>>> Instead of attempting to release the semaphores at those places, move
>>> the release into multifd_save_cleanup(). This puts the semaphore usage
>>> in the same thread that does the cleanup, eliminating the race.
>>>
>>> Move the call to multifd_save_cleanup() before joining for the
>>> migration thread so we release the semaphores before.
>>>
>>> Signed-off-by: Fabiano Rosas
>>> ---
>>> migration/migration.c | 4 +++-
>>> migration/multifd.c | 29 +++--
>>> 2 files changed, 14 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/migration/migration.c b/migration/migration.c
>>> index cca32c553c..52be20561b 100644
>>> --- a/migration/migration.c
>>> +++ b/migration/migration.c
>>> @@ -1300,6 +1300,9 @@ static void migrate_fd_cleanup(MigrationState *s)
>>> QEMUFile *tmp;
>>>
>>> trace_migrate_fd_cleanup();
>>> +
>>> +multifd_save_cleanup();
>>> +
>>> qemu_mutex_unlock_iothread();
>>> if (s->migration_thread_running) {
>>> qemu_thread_join(>thread);
>>> @@ -1307,7 +1310,6 @@ static void migrate_fd_cleanup(MigrationState *s)
>>> }
>>> qemu_mutex_lock_iothread();
>>>
>>> -multifd_save_cleanup();
>>> qemu_mutex_lock(>qemu_file_lock);
>>> tmp = s->to_dst_file;
>>> s->to_dst_file = NULL;
>>> diff --git a/migration/multifd.c b/migration/multifd.c
>>> index ec58c58082..9ca482cfbe 100644
>>> --- a/migration/multifd.c
>>> +++ b/migration/multifd.c
>>> @@ -527,6 +527,9 @@ void multifd_save_cleanup(void)
>>>
>>> if (p->running) {
>>> qemu_thread_join(>thread);
>>> +} else {
>>> +qemu_sem_post(>sem_sync);
>>> +qemu_sem_post(_send_state->channels_ready);
>>
>> I think relying on p->running to join the thread is already problematic.
>>
>
> Absolutely. I've already complained about this in another thread.
I haven't seen that yet.
But if there is a bug, of course that we need to fix it.
>> Now all threads are created with JOINABLE, so we must join them to release
>> the thread resources. Clearing "running" at the end of the thread is
>> already wrong to me, because it means if the thread quits before the main
>> thread reaching here, we will not join the thread, and the thread resource
>> will be leaked.
>>
>> Here IMHO we should set p->running=true right before thread created, and
>> never clear it. We may even want to rename it to p->thread_created?
>>
>
> Ok, let me do that. I already have some patches touching
> multifd_new_send_channel_async() due to fixed-ram.
I still think this is a bad idea. What that value means is if we have
to send a post/whatever or not.
What I could agree is that when we put ->running to false, we ceauld
also shutdown the QIO channel.
>>> }
>>> }
>>> for (i = 0; i < migrate_multifd_channels(); i++) {
>>> @@ -751,8 +754,6 @@ out:
>>> assert(local_err);
>>> trace_multifd_send_error(p->id);
>>> multifd_send_terminate_threads(local_err);
>>> -qemu_sem_post(>sem_sync);
>>> -qemu_sem_post(_send_state->channels_ready);
>>> error_free(local_err);
>>> }
>>>
>>> @@ -780,20 +781,15 @@ static void multifd_tls_outgoing_handshake(QIOTask
>>> *task,
>>>
>>> if (!qio_task_propagate_error(task, )) {
>>> trace_multifd_tls_outgoing_handshake_complete(ioc);
>>> -if (multifd_channel_connect(p, ioc, )) {
>>> -return;
>>> -}
>>> +multifd_channel_connect(p, ioc, NULL);
>>
>> Ignoring Error** is not good..
>>
>> I think you meant to say "it should never fail", then we should put
>> _abort. Another cleaner way to do this is split the current
>> multifd_channel_connect() into tls and non-tls helpers, then we can call
>> the non-tls helpers here (which may not need an Error**).
>
> I attempted the split and it looked awkward, so I let go. But I agree
> about the Error.
As said, that code is really weird because tcp+tls is basically two
listen(). I never understood that part of the code, I think it was
daniel who wrote it.
>> I may still need some more time to
Re: [PATCH-for-8.2] hw/net/can/xlnx-zynqmp: Avoid underflow while popping TX FIFO
Hi Francisco,
On 16/11/23 15:17, Francisco Iglesias wrote:
Hi Philippe, good catch!
Well this was fuzzed by Qiang Liu.
On 2023-11-15 16:17, Philippe Mathieu-Daudé wrote:
Per
https://docs.xilinx.com/r/en-US/ug1085-zynq-ultrascale-trm/Message-Format
Message Format
The same message format is used for RXFIFO, TXFIFO, and TXHPB.
Each message includes four words (16 bytes). Software must read
and write all four words regardless of the actual number of data
bytes and valid fields in the message.
There is no mention in this reference manual about what the
hardware does when not all four words are written. To fix the
reported underflow behavior when DATA2 register is written,
I choose to fill the data with the previous content of the
ID / DLC / DATA1 registers, which is how I expect hardware
would do.
Note there is no hardware flag raised under such condition.
Reported-by: Qiang Liu
Fixes: 98e5d7a2b7 ("hw/net/can: Introduce Xilinx ZynqMP CAN controller")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1425
Signed-off-by: Philippe Mathieu-Daudé
---
Tested with the CAN tests from 'make check-qtest-aarch64'
---
hw/net/can/xlnx-zynqmp-can.c | 49 +---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/hw/net/can/xlnx-zynqmp-can.c b/hw/net/can/xlnx-zynqmp-can.c
index e93e6c5e19..58938b574e 100644
--- a/hw/net/can/xlnx-zynqmp-can.c
+++ b/hw/net/can/xlnx-zynqmp-can.c
@@ -434,6 +434,51 @@ static bool tx_ready_check(XlnxZynqMPCANState *s)
return true;
}
+static void read_tx_frame(XlnxZynqMPCANState *s, Fifo32 *fifo,
uint32_t *data)
+{
+ unsigned used = fifo32_num_used(fifo);
For the case when there are multiple frames in the fifo we need to swap
above to:
unsigned used = fifo32_num_used(fifo) > CAN_FRAME_SIZE ? 0 :
fifo32_num_used(fifo);
Isn't this ...
With above minor modification:
Reviewed-by: Francisco Iglesias
Best regards,
Francisco
+ bool is_txhpb = fifo == >txhpb_fifo;
+
+ assert(used > 0);
+ used %= CAN_FRAME_SIZE;
... done here?
+ /*
+ * Frame Message Format
+ *
+ * Each frame includes four words (16 bytes). Software must read
and write
+ * all four words regardless of the actual number of data bytes
and valid
+ * fields in the message.
+ * If software misbehave (not writting all four words), we use
the previous
+ * registers content to initialize each missing word.
+ */
+ if (used > 0) {
+ /* ID, DLC, DATA1 missing */
+ data[0] = s->regs[is_txhpb ? R_TXHPB_ID : R_TXFIFO_ID];
+ } else {
+ data[0] = fifo32_pop(fifo);
+ }
+ if (used == 1 || used == 2) {
+ /* DLC, DATA1 missing */
+ data[1] = s->regs[is_txhpb ? R_TXHPB_DLC : R_TXFIFO_DLC];
+ } else {
+ data[1] = fifo32_pop(fifo);
+ }
+ if (used == 1) {
+ /* DATA1 missing */
+ data[2] = s->regs[is_txhpb ? R_TXHPB_DATA1 : R_TXFIFO_DATA1];
+ } else {
+ data[2] = fifo32_pop(fifo);
+ }
+ /* DATA2 triggered the transfer thus is always available */
+ data[3] = fifo32_pop(fifo);
+
+ if (used) {
+ qemu_log_mask(LOG_GUEST_ERROR,
+ "%s: Incomplete CAN frame (only %u/%u slots
used)\n",
+ TYPE_XLNX_ZYNQMP_CAN, used, CAN_FRAME_SIZE);
+ }
+}
