Re: [PULL 0/1] loongarch patch queue
On 8/8/22 19:50, Richard Henderson wrote: Hopefully the last such last minute bug for this new target. r~ The following changes since commit 7b06148df8a22d984e77e796322aeb5901dc653c: Merge tag 'mips-20220809' of https://github.com/philmd/qemu into staging (2022-08-08 17:59:27 -0700) are available in the Git repository at: https://gitlab.com/rth7680/qemu.git tags/pull-la-20220808 for you to fetch changes up to 10dcb08b03863221faa41f4f1aa835cdca441b96: target/loongarch: Remove cpu_fcsr0 (2022-08-08 19:42:53 -0700) loongarch: fix emulation of fcsr register Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/7.1 as appropriate. r~ Richard Henderson (1): target/loongarch: Remove cpu_fcsr0 target/loongarch/helper.h| 2 +- target/loongarch/fpu_helper.c| 4 ++-- target/loongarch/translate.c | 3 --- tests/tcg/loongarch64/test_fcsr.c| 15 + target/loongarch/insn_trans/trans_fmov.c.inc | 33 ++-- tests/tcg/loongarch64/Makefile.target| 1 + 6 files changed, 36 insertions(+), 22 deletions(-) create mode 100644 tests/tcg/loongarch64/test_fcsr.c
[PATCH v8 3/4] target/riscv: smstateen check for fcsr
If smstateen is implemented and sstateen0.fcsr is clear then the floating point
operations must return illegal instruction exception or virtual instruction
trap, if relevant.
Signed-off-by: Mayuresh Chitale
---
target/riscv/csr.c| 23 +
target/riscv/insn_trans/trans_rvf.c.inc | 40 +--
target/riscv/insn_trans/trans_rvzfh.c.inc | 12 +++
3 files changed, 72 insertions(+), 3 deletions(-)
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index d8383c7307..a62081ab2d 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -83,6 +83,10 @@ static RISCVException fs(CPURISCVState *env, int csrno)
!RISCV_CPU(env_cpu(env))->cfg.ext_zfinx) {
return RISCV_EXCP_ILLEGAL_INST;
}
+
+if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
+return smstateen_acc_ok(env, 0, SMSTATEEN0_FCSR);
+}
#endif
return RISCV_EXCP_NONE;
}
@@ -1874,6 +1878,9 @@ static RISCVException write_mstateen0(CPURISCVState *env,
int csrno,
target_ulong new_val)
{
uint64_t wr_mask = SMSTATEEN_STATEEN | SMSTATEEN0_HSENVCFG;
+if (!riscv_has_ext(env, RVF)) {
+wr_mask |= SMSTATEEN0_FCSR;
+}
return write_mstateen(env, csrno, wr_mask, new_val);
}
@@ -1922,6 +1929,10 @@ static RISCVException write_mstateen0h(CPURISCVState
*env, int csrno,
{
uint64_t wr_mask = SMSTATEEN_STATEEN | SMSTATEEN0_HSENVCFG;
+if (!riscv_has_ext(env, RVF)) {
+wr_mask |= SMSTATEEN0_FCSR;
+}
+
return write_mstateenh(env, csrno, wr_mask, new_val);
}
@@ -1971,6 +1982,10 @@ static RISCVException write_hstateen0(CPURISCVState
*env, int csrno,
{
uint64_t wr_mask = SMSTATEEN_STATEEN | SMSTATEEN0_HSENVCFG;
+if (!riscv_has_ext(env, RVF)) {
+wr_mask |= SMSTATEEN0_FCSR;
+}
+
return write_hstateen(env, csrno, wr_mask, new_val);
}
@@ -2022,6 +2037,10 @@ static RISCVException write_hstateen0h(CPURISCVState
*env, int csrno,
{
uint64_t wr_mask = SMSTATEEN_STATEEN | SMSTATEEN0_HSENVCFG;
+if (!riscv_has_ext(env, RVF)) {
+wr_mask |= SMSTATEEN0_FCSR;
+}
+
return write_hstateenh(env, csrno, wr_mask, new_val);
}
@@ -2081,6 +2100,10 @@ static RISCVException write_sstateen0(CPURISCVState
*env, int csrno,
{
uint64_t wr_mask = SMSTATEEN_STATEEN | SMSTATEEN0_HSENVCFG;
+if (!riscv_has_ext(env, RVF)) {
+wr_mask |= SMSTATEEN0_FCSR;
+}
+
return write_sstateen(env, csrno, wr_mask, new_val);
}
diff --git a/target/riscv/insn_trans/trans_rvf.c.inc
b/target/riscv/insn_trans/trans_rvf.c.inc
index a1d3eb52ad..ce8a0cc34b 100644
--- a/target/riscv/insn_trans/trans_rvf.c.inc
+++ b/target/riscv/insn_trans/trans_rvf.c.inc
@@ -24,9 +24,43 @@
return false; \
} while (0)
-#define REQUIRE_ZFINX_OR_F(ctx) do {\
-if (!ctx->cfg_ptr->ext_zfinx) { \
-REQUIRE_EXT(ctx, RVF); \
+#ifndef CONFIG_USER_ONLY
+static inline bool smstateen_check(DisasContext *ctx, int index)
+{
+CPUState *cpu = ctx->cs;
+CPURISCVState *env = cpu->env_ptr;
+uint64_t stateen = env->mstateen[index];
+
+if (!ctx->cfg_ptr->ext_smstateen || env->priv == PRV_M) {
+return true;
+}
+
+if (ctx->virt_enabled) {
+stateen &= env->hstateen[index];
+}
+
+if (env->priv == PRV_U && has_ext(ctx, RVS)) {
+stateen &= env->sstateen[index];
+}
+
+if (!(stateen & SMSTATEEN0_FCSR)) {
+return false;
+}
+
+return true;
+}
+#else
+#define smstateen_check(ctx, index) (true)
+#endif
+
+#define REQUIRE_ZFINX_OR_F(ctx) do { \
+if (!has_ext(ctx, RVF)) { \
+if (!ctx->cfg_ptr->ext_zfinx) { \
+return false; \
+} \
+if (!smstateen_check(ctx, 0)) { \
+return false; \
+} \
} \
} while (0)
diff --git a/target/riscv/insn_trans/trans_rvzfh.c.inc
b/target/riscv/insn_trans/trans_rvzfh.c.inc
index 5d07150cd0..44d962c920 100644
--- a/target/riscv/insn_trans/trans_rvzfh.c.inc
+++ b/target/riscv/insn_trans/trans_rvzfh.c.inc
@@ -20,18 +20,27 @@
if (!ctx->cfg_ptr->ext_zfh) { \
return false; \
} \
+if (!smstateen_check(ctx, 0)) { \
+return false; \
+} \
} while (0)
#define REQUIRE_ZHINX_OR_ZFH(ctx) do { \
if (!ctx->cfg_ptr->ext_zhinx && !ctx->cfg_ptr->ext_zfh) { \
return false; \
} \
+if (!smstateen_check(ctx, 0)) { \
+return false; \
+} \
} while (0)
#define REQUIRE_ZFH_OR_ZFHMIN(ctx) do { \
if (!(ctx->cfg_ptr->ext_zfh || ctx->cfg_ptr->ext_zfhmin)) { \
return false; \
} \
+if (!smstateen_check(ctx, 0)) { \
+return false; \
+} \
} while (0)
#define REQUIRE_ZFH_OR_ZFHMIN_OR_ZHINX_OR_ZHINXMIN(ctx) do { \
@@ -39,6 +48,9 @@
ctx->cfg_ptr->ext_zhinx
[PATCH v8 4/4] target/riscv: smstateen knobs
Add knobs to allow users to enable smstateen and also export it via the
ISA extension string.
Signed-off-by: Mayuresh Chitale
---
target/riscv/cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index d4635c7df4..d8a0f4e700 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -99,6 +99,7 @@ static const struct isa_ext_data isa_edata_arr[] = {
ISA_EXT_DATA_ENTRY(zve64f, true, PRIV_VERSION_1_12_0, ext_zve64f),
ISA_EXT_DATA_ENTRY(zhinx, true, PRIV_VERSION_1_12_0, ext_zhinx),
ISA_EXT_DATA_ENTRY(zhinxmin, true, PRIV_VERSION_1_12_0, ext_zhinxmin),
+ISA_EXT_DATA_ENTRY(smstateen, true, PRIV_VERSION_1_12_0, ext_smstateen),
ISA_EXT_DATA_ENTRY(svinval, true, PRIV_VERSION_1_12_0, ext_svinval),
ISA_EXT_DATA_ENTRY(svnapot, true, PRIV_VERSION_1_12_0, ext_svnapot),
ISA_EXT_DATA_ENTRY(svpbmt, true, PRIV_VERSION_1_12_0, ext_svpbmt),
@@ -1001,6 +1002,7 @@ static Property riscv_cpu_extensions[] = {
DEFINE_PROP_UINT16("vlen", RISCVCPU, cfg.vlen, 128),
DEFINE_PROP_UINT16("elen", RISCVCPU, cfg.elen, 64),
+DEFINE_PROP_BOOL("smstateen", RISCVCPU, cfg.ext_smstateen, false),
DEFINE_PROP_BOOL("svinval", RISCVCPU, cfg.ext_svinval, false),
DEFINE_PROP_BOOL("svnapot", RISCVCPU, cfg.ext_svnapot, false),
DEFINE_PROP_BOOL("svpbmt", RISCVCPU, cfg.ext_svpbmt, false),
--
2.25.1
[PATCH v8 2/4] target/riscv: smstateen check for h/s/envcfg
Accesses to henvcfg, henvcfgh and senvcfg are allowed only if the corresponding
bit in mstateen0/hstateen0 is enabled. Otherwise an illegal instruction trap is
generated.
Signed-off-by: Mayuresh Chitale
---
target/riscv/csr.c | 87 ++
1 file changed, 80 insertions(+), 7 deletions(-)
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index d5761996ba..d8383c7307 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -40,6 +40,42 @@ void riscv_set_csr_ops(int csrno, riscv_csr_operations *ops)
}
/* Predicates */
+#if !defined(CONFIG_USER_ONLY)
+static RISCVException smstateen_acc_ok(CPURISCVState *env, int index,
+ uint64_t bit)
+{
+bool virt = riscv_cpu_virt_enabled(env);
+CPUState *cs = env_cpu(env);
+RISCVCPU *cpu = RISCV_CPU(cs);
+
+if (env->priv == PRV_M || !cpu->cfg.ext_smstateen) {
+return RISCV_EXCP_NONE;
+}
+
+if (!(env->mstateen[index] & bit)) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+if (virt) {
+if (!(env->hstateen[index] & bit)) {
+return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
+}
+
+if (env->priv == PRV_U && !(env->sstateen[index] & bit)) {
+return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
+}
+}
+
+if (env->priv == PRV_U && riscv_has_ext(env, RVS)) {
+if (!(env->sstateen[index] & bit)) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+}
+
+return RISCV_EXCP_NONE;
+}
+#endif
+
static RISCVException fs(CPURISCVState *env, int csrno)
{
#if !defined(CONFIG_USER_ONLY)
@@ -1719,6 +1755,13 @@ static RISCVException write_menvcfgh(CPURISCVState *env,
int csrno,
static RISCVException read_senvcfg(CPURISCVState *env, int csrno,
target_ulong *val)
{
+RISCVException ret;
+
+ret = smstateen_acc_ok(env, 0, SMSTATEEN0_HSENVCFG);
+if (ret != RISCV_EXCP_NONE) {
+return ret;
+}
+
*val = env->senvcfg;
return RISCV_EXCP_NONE;
}
@@ -1727,15 +1770,27 @@ static RISCVException write_senvcfg(CPURISCVState *env,
int csrno,
target_ulong val)
{
uint64_t mask = SENVCFG_FIOM | SENVCFG_CBIE | SENVCFG_CBCFE | SENVCFG_CBZE;
+RISCVException ret;
-env->senvcfg = (env->senvcfg & ~mask) | (val & mask);
+ret = smstateen_acc_ok(env, 0, SMSTATEEN0_HSENVCFG);
+if (ret != RISCV_EXCP_NONE) {
+return ret;
+}
+env->senvcfg = (env->senvcfg & ~mask) | (val & mask);
return RISCV_EXCP_NONE;
}
static RISCVException read_henvcfg(CPURISCVState *env, int csrno,
target_ulong *val)
{
+RISCVException ret;
+
+ret = smstateen_acc_ok(env, 0, SMSTATEEN0_HSENVCFG);
+if (ret != RISCV_EXCP_NONE) {
+return ret;
+}
+
*val = env->henvcfg;
return RISCV_EXCP_NONE;
}
@@ -1744,6 +1799,12 @@ static RISCVException write_henvcfg(CPURISCVState *env,
int csrno,
target_ulong val)
{
uint64_t mask = HENVCFG_FIOM | HENVCFG_CBIE | HENVCFG_CBCFE | HENVCFG_CBZE;
+RISCVException ret;
+
+ret = smstateen_acc_ok(env, 0, SMSTATEEN0_HSENVCFG);
+if (ret != RISCV_EXCP_NONE) {
+return ret;
+}
if (riscv_cpu_mxl(env) == MXL_RV64) {
mask |= HENVCFG_PBMTE | HENVCFG_STCE;
@@ -1757,6 +1818,13 @@ static RISCVException write_henvcfg(CPURISCVState *env,
int csrno,
static RISCVException read_henvcfgh(CPURISCVState *env, int csrno,
target_ulong *val)
{
+RISCVException ret;
+
+ret = smstateen_acc_ok(env, 0, SMSTATEEN0_HSENVCFG);
+if (ret != RISCV_EXCP_NONE) {
+return ret;
+}
+
*val = env->henvcfg >> 32;
return RISCV_EXCP_NONE;
}
@@ -1766,9 +1834,14 @@ static RISCVException write_henvcfgh(CPURISCVState *env,
int csrno,
{
uint64_t mask = HENVCFG_PBMTE | HENVCFG_STCE;
uint64_t valh = (uint64_t)val << 32;
+RISCVException ret;
-env->henvcfg = (env->henvcfg & ~mask) | (valh & mask);
+ret = smstateen_acc_ok(env, 0, SMSTATEEN0_HSENVCFG);
+if (ret != RISCV_EXCP_NONE) {
+return ret;
+}
+env->henvcfg = (env->henvcfg & ~mask) | (valh & mask);
return RISCV_EXCP_NONE;
}
@@ -1800,7 +1873,7 @@ static RISCVException write_mstateen(CPURISCVState *env,
int csrno,
static RISCVException write_mstateen0(CPURISCVState *env, int csrno,
target_ulong new_val)
{
-uint64_t wr_mask = SMSTATEEN_STATEEN;
+uint64_t wr_mask = SMSTATEEN_STATEEN | SMSTATEEN0_HSENVCFG;
return write_mstateen(env, csrno, wr_mask, new_val);
}
@@ -1847,7 +1920,7 @@ static RISCVException write_mstateenh(CPURISCVState *env,
int csrno,
static RISCVException write_mstateen0h(CPURISCVState *env, int csrno,
target_ulong new_val)
{
-uint64_t wr_mask = SMSTATEEN_STATEEN;
+uint64_t wr_mask =
[PATCH v8 1/4] target/riscv: Add smstateen support
Smstateen extension specifies a mechanism to close
the potential covert channels that could cause security issues.
This patch adds the CSRs defined in the specification and
the corresponding predicates and read/write functions.
Signed-off-by: Mayuresh Chitale
---
target/riscv/cpu.h | 4 +
target/riscv/cpu_bits.h | 37
target/riscv/csr.c | 373
target/riscv/machine.c | 21 +++
4 files changed, 435 insertions(+)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 4be4b82a83..6bff935c57 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -354,6 +354,9 @@ struct CPUArchState {
/* CSRs for execution enviornment configuration */
uint64_t menvcfg;
+uint64_t mstateen[SMSTATEEN_MAX_COUNT];
+uint64_t hstateen[SMSTATEEN_MAX_COUNT];
+uint64_t sstateen[SMSTATEEN_MAX_COUNT];
target_ulong senvcfg;
uint64_t henvcfg;
#endif
@@ -427,6 +430,7 @@ struct RISCVCPUConfig {
bool ext_ifencei;
bool ext_icsr;
bool ext_zihintpause;
+bool ext_smstateen;
bool ext_svinval;
bool ext_svnapot;
bool ext_svpbmt;
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 6be5a9e9f0..c773e0d310 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -199,6 +199,12 @@
/* Supervisor Configuration CSRs */
#define CSR_SENVCFG 0x10A
+/* Supervisor state CSRs */
+#define CSR_SSTATEEN0 0x10C
+#define CSR_SSTATEEN1 0x10D
+#define CSR_SSTATEEN2 0x10E
+#define CSR_SSTATEEN3 0x10F
+
/* Supervisor Trap Handling */
#define CSR_SSCRATCH0x140
#define CSR_SEPC0x141
@@ -242,6 +248,16 @@
#define CSR_HENVCFG 0x60A
#define CSR_HENVCFGH0x61A
+/* Hypervisor state CSRs */
+#define CSR_HSTATEEN0 0x60C
+#define CSR_HSTATEEN0H 0x61C
+#define CSR_HSTATEEN1 0x60D
+#define CSR_HSTATEEN1H 0x61D
+#define CSR_HSTATEEN2 0x60E
+#define CSR_HSTATEEN2H 0x61E
+#define CSR_HSTATEEN3 0x60F
+#define CSR_HSTATEEN3H 0x61F
+
/* Virtual CSRs */
#define CSR_VSSTATUS0x200
#define CSR_VSIE0x204
@@ -283,6 +299,27 @@
#define CSR_MENVCFG 0x30A
#define CSR_MENVCFGH0x31A
+/* Machine state CSRs */
+#define CSR_MSTATEEN0 0x30C
+#define CSR_MSTATEEN0H 0x31C
+#define CSR_MSTATEEN1 0x30D
+#define CSR_MSTATEEN1H 0x31D
+#define CSR_MSTATEEN2 0x30E
+#define CSR_MSTATEEN2H 0x31E
+#define CSR_MSTATEEN3 0x30F
+#define CSR_MSTATEEN3H 0x31F
+
+/* Common defines for all smstateen */
+#define SMSTATEEN_MAX_COUNT 4
+#define SMSTATEEN0_CS (1ULL << 0)
+#define SMSTATEEN0_FCSR (1ULL << 1)
+#define SMSTATEEN0_HSCONTXT (1ULL << 57)
+#define SMSTATEEN0_IMSIC(1ULL << 58)
+#define SMSTATEEN0_AIA (1ULL << 59)
+#define SMSTATEEN0_SVSLCT (1ULL << 60)
+#define SMSTATEEN0_HSENVCFG (1ULL << 62)
+#define SMSTATEEN_STATEEN (1ULL << 63)
+
/* Enhanced Physical Memory Protection (ePMP) */
#define CSR_MSECCFG 0x747
#define CSR_MSECCFGH0x757
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index d81f466c80..d5761996ba 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -346,6 +346,72 @@ static RISCVException umode32(CPURISCVState *env, int
csrno)
return umode(env, csrno);
}
+static RISCVException mstateen(CPURISCVState *env, int csrno)
+{
+CPUState *cs = env_cpu(env);
+RISCVCPU *cpu = RISCV_CPU(cs);
+
+if (!cpu->cfg.ext_smstateen) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+return any(env, csrno);
+}
+
+static RISCVException hstateen_pred(CPURISCVState *env, int csrno, int base)
+{
+CPUState *cs = env_cpu(env);
+RISCVCPU *cpu = RISCV_CPU(cs);
+
+if (!cpu->cfg.ext_smstateen) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+if (env->priv < PRV_M) {
+if (!(env->mstateen[csrno - base] & SMSTATEEN_STATEEN)) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+}
+
+return hmode(env, csrno);
+}
+
+static RISCVException hstateen(CPURISCVState *env, int csrno)
+{
+return hstateen_pred(env, csrno, CSR_HSTATEEN0);
+}
+
+static RISCVException hstateenh(CPURISCVState *env, int csrno)
+{
+return hstateen_pred(env, csrno, CSR_HSTATEEN0H);
+}
+
+static RISCVException sstateen(CPURISCVState *env, int csrno)
+{
+bool virt = riscv_cpu_virt_enabled(env);
+int index = csrno - CSR_SSTATEEN0;
+CPUState *cs = env_cpu(env);
+RISCVCPU *cpu = RISCV_CPU(cs);
+
+if (!cpu->cfg.ext_smstateen) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+if (env->priv < PRV_M) {
+if (!(env->mstateen[index] & SMSTATEEN_STATEEN)) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+if (virt) {
+if (!(env->hstateen[index] & SMSTATEEN_STATEEN)) {
+return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
+}
+}
+}
+
+return smode(env, csrno);
+}
+
/* Checks if PointerMasking
[PATCH v8 0/4] RISC-V Smstateen support
This series adds support for the Smstateen specification which provides a mechanism to plug the potential covert channels which are opened by extensions that add to processor state that may not get context-switched. Currently access to *envcfg registers and floating point(fcsr) is controlled via smstateen. These patches can also be found on riscv_smstateen_v8 branch at: https://github.com/mdchitale/qemu.git Changes in v8: - Rebase to latest riscv-to-apply.next - Fix m-mode check for hstateen - Fix return exception type for VU mode - Improve commit description for patch3 Changes in v7: - Update smstateen check as per discussion on the following issue: https://github.com/riscv/riscv-state-enable/issues/9 - Drop the smstateen AIA patch for now. - Indentation and other fixes Changes in v6: - Sync with latest riscv-to-apply.next - Make separate read/write ops for m/h/s/stateen1/2/3 regs - Add check for mstateen.staten when reading or using h/s/stateen regs - Add smstateen fcsr check for all floating point operations - Move knobs to enable smstateen in a separate patch. Changes in v5: - Fix the order in which smstateen extension is added to the isa_edata_arr as described in rule #3 the comment. Changes in v4: - Fix build issue with riscv32/riscv64-linux-user targets Changes in v3: - Fix coding style issues - Fix *stateen0h index calculation Changes in v2: - Make h/s/envcfg bits in m/h/stateen registers as writeable by default. Mayuresh Chitale (4): target/riscv: Add smstateen support target/riscv: smstateen check for h/s/envcfg target/riscv: smstateen check for fcsr target/riscv: smstateen knobs target/riscv/cpu.c| 2 + target/riscv/cpu.h| 4 + target/riscv/cpu_bits.h | 37 ++ target/riscv/csr.c| 471 +- target/riscv/insn_trans/trans_rvf.c.inc | 40 +- target/riscv/insn_trans/trans_rvzfh.c.inc | 12 + target/riscv/machine.c| 21 + 7 files changed, 583 insertions(+), 4 deletions(-) -- 2.25.1
[PATCH V3] net/colo.c: Fix the pointer issue reported by Coverity.
When enable the virtio-net-pci, guest network packet will
load the vnet_hdr. In COLO status, the primary VM's network
packet maybe redirect to another VM, it need filter-redirect
enable the vnet_hdr flag at the same time, COLO-proxy will
correctly parse the original network packet. If have any
misconfiguration here, the vnet_hdr_len is wrong for parse
the packet, the data+offset will point to wrong place.
Signed-off-by: Zhang Chen
---
net/colo.c | 18 ++
net/colo.h | 1 +
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/net/colo.c b/net/colo.c
index 6b0ff562ad..4f1b4a61f6 100644
--- a/net/colo.c
+++ b/net/colo.c
@@ -44,21 +44,23 @@ int parse_packet_early(Packet *pkt)
{
int network_length;
static const uint8_t vlan[] = {0x81, 0x00};
-uint8_t *data = pkt->data + pkt->vnet_hdr_len;
+uint8_t *data = pkt->data;
uint16_t l3_proto;
ssize_t l2hdr_len;
-if (data == NULL) {
-trace_colo_proxy_main_vnet_info("This packet is not parsed correctly, "
+assert(data);
+
+/* Check the received vnet_hdr_len then add the offset */
+if ((pkt->vnet_hdr_len > sizeof(struct virtio_net_hdr)) ||
+(pkt->size < sizeof(struct eth_header) + sizeof(struct vlan_header)
++ pkt->vnet_hdr_len)) {
+trace_colo_proxy_main_vnet_info("This packet may be load wrong "
"pkt->vnet_hdr_len",
pkt->vnet_hdr_len);
return 1;
}
-l2hdr_len = eth_get_l2_hdr_length(data);
+data += pkt->vnet_hdr_len;
-if (pkt->size < ETH_HLEN + pkt->vnet_hdr_len) {
-trace_colo_proxy_main("pkt->size < ETH_HLEN");
-return 1;
-}
+l2hdr_len = eth_get_l2_hdr_length(data);
/*
* TODO: support vlan.
diff --git a/net/colo.h b/net/colo.h
index 8b3e8d5a83..22fc3031f7 100644
--- a/net/colo.h
+++ b/net/colo.h
@@ -18,6 +18,7 @@
#include "qemu/jhash.h"
#include "qemu/timer.h"
#include "net/eth.h"
+#include "standard-headers/linux/virtio_net.h"
#define HASHTABLE_MAX_SIZE 16384
--
2.25.1
RE: [PATCH V2] net/colo.c: Fix the pointer issuse reported by Coverity.
> -Original Message-
> From: Peter Maydell
> Sent: Friday, August 5, 2022 5:57 PM
> To: Zhang, Chen
> Cc: Jason Wang ; Li Zhijian ;
> qemu-dev
> Subject: Re: [PATCH V2] net/colo.c: Fix the pointer issuse reported by
> Coverity.
>
> On Fri, 5 Aug 2022 at 10:53, Zhang Chen wrote:
> >
> > When enable the virtio-net-pci, guest network packet will load the
> > vnet_hdr. In COLO status, the primary VM's network packet maybe
> > redirect to another VM, it need filter-redirect enable the vnet_hdr
> > flag at the same time, COLO-proxy will correctly parse the original
> > network packet. If have any misconfiguration here, the vnet_hdr_len is
> > wrong for parse the packet, the data+offset will point to wrong place.
> >
> > Signed-off-by: Zhang Chen
> > ---
> > net/colo.c | 17 +
> > 1 file changed, 9 insertions(+), 8 deletions(-)
> >
> > diff --git a/net/colo.c b/net/colo.c
> > index 6b0ff562ad..524afa3d9b 100644
> > --- a/net/colo.c
> > +++ b/net/colo.c
> > @@ -44,21 +44,22 @@ int parse_packet_early(Packet *pkt) {
> > int network_length;
> > static const uint8_t vlan[] = {0x81, 0x00};
> > -uint8_t *data = pkt->data + pkt->vnet_hdr_len;
> > +uint8_t *data = pkt->data;
> > uint16_t l3_proto;
> > ssize_t l2hdr_len;
> >
> > -if (data == NULL) {
> > -trace_colo_proxy_main_vnet_info("This packet is not parsed
> > correctly,
> "
> > +assert(data);
> > +
> > +/* Check the received vnet_hdr_len then add the offset */
> > +if (pkt->size < sizeof(struct eth_header) + sizeof(struct vlan_header)
> > ++ pkt->vnet_hdr_len) {
>
> I think this expression needs more care to avoid overflow with a maliciously
> over-large vnet_hdr_len value.
>
> Casting pkt->vnet_hdr_len to int64_t would be one way to do that; there
> may be better approaches.
Yes, you are right. And I found better to use this check to avoid overflow:
"pkt->vnet_hdr_len < sizeof(struct virtio_net_hdr)"
I will fix it in next version.
Thanks
Chen
>
> thanks
> -- PMM
[PULL 0/1] loongarch patch queue
Hopefully the last such last minute bug for this new target. r~ The following changes since commit 7b06148df8a22d984e77e796322aeb5901dc653c: Merge tag 'mips-20220809' of https://github.com/philmd/qemu into staging (2022-08-08 17:59:27 -0700) are available in the Git repository at: https://gitlab.com/rth7680/qemu.git tags/pull-la-20220808 for you to fetch changes up to 10dcb08b03863221faa41f4f1aa835cdca441b96: target/loongarch: Remove cpu_fcsr0 (2022-08-08 19:42:53 -0700) loongarch: fix emulation of fcsr register Richard Henderson (1): target/loongarch: Remove cpu_fcsr0 target/loongarch/helper.h| 2 +- target/loongarch/fpu_helper.c| 4 ++-- target/loongarch/translate.c | 3 --- tests/tcg/loongarch64/test_fcsr.c| 15 + target/loongarch/insn_trans/trans_fmov.c.inc | 33 ++-- tests/tcg/loongarch64/Makefile.target| 1 + 6 files changed, 36 insertions(+), 22 deletions(-) create mode 100644 tests/tcg/loongarch64/test_fcsr.c
[PULL 1/1] target/loongarch: Remove cpu_fcsr0
All of the fpu operations are defined with TCG_CALL_NO_WG, but they
all modify FCSR0. The most efficient way to fix this is to remove
cpu_fcsr0, and instead use explicit load and store operations for the
two instructions that manipulate that value.
Acked-by: Qi Hu
Reviewed-by: Song Gao
Reported-by: Feiyang Chen
Signed-off-by: Richard Henderson
---
target/loongarch/helper.h| 2 +-
target/loongarch/fpu_helper.c| 4 +--
target/loongarch/translate.c | 3 --
tests/tcg/loongarch64/test_fcsr.c| 15 +
target/loongarch/insn_trans/trans_fmov.c.inc | 33 ++--
tests/tcg/loongarch64/Makefile.target| 1 +
6 files changed, 36 insertions(+), 22 deletions(-)
create mode 100644 tests/tcg/loongarch64/test_fcsr.c
diff --git a/target/loongarch/helper.h b/target/loongarch/helper.h
index cbbe008f32..9c01823a26 100644
--- a/target/loongarch/helper.h
+++ b/target/loongarch/helper.h
@@ -91,7 +91,7 @@ DEF_HELPER_2(ftint_w_d, i64, env, i64)
DEF_HELPER_2(frint_s, i64, env, i64)
DEF_HELPER_2(frint_d, i64, env, i64)
-DEF_HELPER_FLAGS_2(set_rounding_mode, TCG_CALL_NO_RWG, void, env, i32)
+DEF_HELPER_FLAGS_1(set_rounding_mode, TCG_CALL_NO_RWG, void, env)
DEF_HELPER_1(rdtime_d, i64, env)
diff --git a/target/loongarch/fpu_helper.c b/target/loongarch/fpu_helper.c
index bd76529219..4b9637210a 100644
--- a/target/loongarch/fpu_helper.c
+++ b/target/loongarch/fpu_helper.c
@@ -872,8 +872,8 @@ uint64_t helper_ftint_w_d(CPULoongArchState *env, uint64_t
fj)
return fd;
}
-void helper_set_rounding_mode(CPULoongArchState *env, uint32_t fcsr0)
+void helper_set_rounding_mode(CPULoongArchState *env)
{
-set_float_rounding_mode(ieee_rm[(fcsr0 >> FCSR0_RM) & 0x3],
+set_float_rounding_mode(ieee_rm[(env->fcsr0 >> FCSR0_RM) & 0x3],
>fp_status);
}
diff --git a/target/loongarch/translate.c b/target/loongarch/translate.c
index c9afd11420..51ba291430 100644
--- a/target/loongarch/translate.c
+++ b/target/loongarch/translate.c
@@ -22,7 +22,6 @@
/* Global register indices */
TCGv cpu_gpr[32], cpu_pc;
static TCGv cpu_lladdr, cpu_llval;
-TCGv_i32 cpu_fcsr0;
TCGv_i64 cpu_fpr[32];
#include "exec/gen-icount.h"
@@ -266,8 +265,6 @@ void loongarch_translate_init(void)
}
cpu_pc = tcg_global_mem_new(cpu_env, offsetof(CPULoongArchState, pc),
"pc");
-cpu_fcsr0 = tcg_global_mem_new_i32(cpu_env,
-offsetof(CPULoongArchState, fcsr0), "fcsr0");
cpu_lladdr = tcg_global_mem_new(cpu_env,
offsetof(CPULoongArchState, lladdr), "lladdr");
cpu_llval = tcg_global_mem_new(cpu_env,
diff --git a/tests/tcg/loongarch64/test_fcsr.c
b/tests/tcg/loongarch64/test_fcsr.c
new file mode 100644
index 00..ad3609eb99
--- /dev/null
+++ b/tests/tcg/loongarch64/test_fcsr.c
@@ -0,0 +1,15 @@
+#include
+
+int main()
+{
+unsigned fcsr;
+
+asm("movgr2fcsr $r0,$r0\n\t"
+"movgr2fr.d $f0,$r0\n\t"
+"fdiv.d $f0,$f0,$f0\n\t"
+"movfcsr2gr %0,$r0"
+: "=r"(fcsr) : : "f0");
+
+assert(fcsr & (16 << 16)); /* Invalid */
+return 0;
+}
diff --git a/target/loongarch/insn_trans/trans_fmov.c.inc
b/target/loongarch/insn_trans/trans_fmov.c.inc
index 24753d4568..5537e3dd35 100644
--- a/target/loongarch/insn_trans/trans_fmov.c.inc
+++ b/target/loongarch/insn_trans/trans_fmov.c.inc
@@ -60,38 +60,39 @@ static bool trans_movgr2fcsr(DisasContext *ctx,
arg_movgr2fcsr *a)
TCGv Rj = gpr_src(ctx, a->rj, EXT_NONE);
if (mask == UINT32_MAX) {
-tcg_gen_extrl_i64_i32(cpu_fcsr0, Rj);
+tcg_gen_st32_i64(Rj, cpu_env, offsetof(CPULoongArchState, fcsr0));
} else {
+TCGv_i32 fcsr0 = tcg_temp_new_i32();
TCGv_i32 temp = tcg_temp_new_i32();
+tcg_gen_ld_i32(fcsr0, cpu_env, offsetof(CPULoongArchState, fcsr0));
tcg_gen_extrl_i64_i32(temp, Rj);
tcg_gen_andi_i32(temp, temp, mask);
-tcg_gen_andi_i32(cpu_fcsr0, cpu_fcsr0, ~mask);
-tcg_gen_or_i32(cpu_fcsr0, cpu_fcsr0, temp);
+tcg_gen_andi_i32(fcsr0, fcsr0, ~mask);
+tcg_gen_or_i32(fcsr0, fcsr0, temp);
+tcg_gen_st_i32(fcsr0, cpu_env, offsetof(CPULoongArchState, fcsr0));
+
tcg_temp_free_i32(temp);
-
-/*
- * Install the new rounding mode to fpu_status, if changed.
- * Note that FCSR3 is exactly the rounding mode field.
- */
-if (mask != FCSR0_M3) {
-return true;
-}
+tcg_temp_free_i32(fcsr0);
}
-gen_helper_set_rounding_mode(cpu_env, cpu_fcsr0);
+/*
+ * Install the new rounding mode to fpu_status, if changed.
+ * Note that FCSR3 is exactly the rounding mode field.
+ */
+if (mask & FCSR0_M3) {
+gen_helper_set_rounding_mode(cpu_env);
+}
return true;
}
static bool trans_movfcsr2gr(DisasContext *ctx, arg_movfcsr2gr *a)
{
-TCGv_i32 temp = tcg_temp_new_i32();
TCGv dest =
Re: [PULL 0/3] MIPS/SPARC patches for 2022-08-09
On 8/8/22 15:33, Philippe Mathieu-Daudé via wrote: The following changes since commit 8a1337e60400ef54432e063164faf5043a5d: Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging (2022-08-08 09:57:37 -0700) are available in the Git repository at: https://github.com/philmd/qemu.git tags/mips-20220809 for you to fetch changes up to 09d12c81ec5d8dc9208e5739d17a56c34be96247: hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses (2022-08-08 23:43:11 +0200) MIPS/SPARC patches queue - target/mips: Handle lock_user failure in UHI_plog semihosting (Peter Maydell) - hw/mips/malta: Turn off x86 specific features of PIIX4 PM (Igor Mammedov) - hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses (Peter Maydell) Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/7.1 as appropriate. r~ Igor Mammedov (1): hw/mips/malta: turn off x86 specific features of PIIX4_PM Peter Maydell (2): target/mips: Handle lock_user() failure in UHI_plog semihosting call hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses hw/mips/malta.c| 9 + hw/misc/grlib_ahb_apb_pnp.c| 10 ++ hw/misc/trace-events | 4 ++-- target/mips/tcg/sysemu/mips-semi.c | 3 +++ 4 files changed, 20 insertions(+), 6 deletions(-)
RE: [PATCH v3 0/2] This patch updates runtime check of AVX512
Hi, Juan, You are right, this v3 and previous v3 are identical except the link to previous discussion. The previous [patch v3 0/2] was sent failed as shown in my mail, so I resend this patch. Sorry for the ambiguity of resending same patch, and thanks for your time ~ Best Regards Ling -Original Message- From: Juan Quintela Sent: Monday, August 8, 2022 7:54 PM To: Xu, Ling1 Cc: qemu-devel@nongnu.org; dgilb...@redhat.com Subject: Re: [PATCH v3 0/2] This patch updates runtime check of AVX512 ling xu wrote: > This patch updates runtime check of AVX512 and update avx512 support > for xbzrle_encode_buffer function to accelerate xbzrle encoding speed. > > The runtime check is updated in meson.build and meson_options.txt. > > The updated AVX512 algorithm is provided in ram.c, xbzrle.c and > xbzrle.h. > > The test code is provided in test-xbzrle.c. > > Previous discussion is refered below: > https://www.mail-archive.com/qemu-devel@nongnu.org/msg903520.html > > ling xu (2): > Update AVX512 support for xbzrle_encode_buffer function > Test code for AVX512 support for xbzrle_encode_buffer I think this v3 and previous v3 are identical except for mthe link to the previous discussion. Later, Juan.
[PATCH 1/2] tests/migration: add sysprof-capture-4 as dependency for stress binary
`make tests/migration/stress` fails with:
FAILED: tests/migration/stress
cc -m64 -mlittle-endian -o tests/migration/stress
tests/migration/stress.p/stress.c.o -Wl,--as-needed -Wl,--no-undefined -pie
-Wl,--warn-common -Wl,-z,relro -Wl,-z,now -fstack-protector-strong -static
-pthread -Wl,--start-group -lgthread-2.0 -lglib-2.0 -Wl,--end-group
/usr/bin/ld:
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../lib64/libglib-2.0.a(gutils.c.o):
in function `.annobin_gutils.c':
(.text+0x3b4): warning: Using 'getpwuid' in statically linked applications
requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: (.text+0x178): warning: Using 'getpwnam_r' in statically
linked applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/bin/ld: (.text+0x1bc): warning: Using 'getpwuid_r' in statically
linked applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/bin/ld:
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../lib64/libglib-2.0.a(gthread.c.o):(.toc+0x0):
undefined reference to `sysprof_clock'
/usr/bin/ld:
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../lib64/libglib-2.0.a(gtrace.c.o):
in function `.annobin_gtrace.c':
(.text+0x24): undefined reference to `sysprof_collector_mark_vprintf'
/usr/bin/ld:
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../lib64/libglib-2.0.a(gtrace.c.o):
in function `g_trace_define_int64_counter':
(.text+0x8c): undefined reference to `sysprof_collector_request_counters'
/usr/bin/ld: (.text+0x108): undefined reference to
`sysprof_collector_define_counters'
/usr/bin/ld:
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../lib64/libglib-2.0.a(gtrace.c.o):
in function `g_trace_set_int64_counter':
(.text+0x23c): undefined reference to `sysprof_collector_set_counters'
/usr/bin/ld:
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../lib64/libglib-2.0.a(gspawn.c.o):(.toc+0x0):
undefined reference to `sysprof_clock'
/usr/bin/ld:
/usr/lib/gcc/ppc64le-redhat-linux/11/../../../../lib64/libglib-2.0.a(gmain.c.o):(.toc+0x0):
undefined reference to `sysprof_clock'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
make: *** [Makefile:162: run-ninja] Error 1
Add sysprof-capture-4 as dependency for stress binary.
Tested on:
- CentOS Stream 9 ppc64le
- Fedora 36 x86_64
Signed-off-by: Murilo Opsfelder Araujo
---
tests/migration/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/migration/meson.build b/tests/migration/meson.build
index f215ee7d3a..3fd87f7849 100644
--- a/tests/migration/meson.build
+++ b/tests/migration/meson.build
@@ -1,7 +1,9 @@
+sysprof = dependency('sysprof-capture-4')
+
stress = executable(
'stress',
files('stress.c'),
- dependencies: [glib],
+ dependencies: [glib, sysprof],
link_args: ['-static'],
build_by_default: false,
)
--
2.37.1
[PATCH 0/2] tests/migration: add support for ppc64le in guestperf.py
The first patch adds sysprof-capture-4 dependency when building stress binary in order to fix a build error. The second patch adds support for ppc64le in guestperf.py. Murilo Opsfelder Araujo (2): tests/migration: add sysprof-capture-4 as dependency for stress binary tests/migration: add support for ppc64le for guestperf.py tests/migration/guestperf/engine.py | 28 +--- tests/migration/meson.build | 4 +++- 2 files changed, 28 insertions(+), 4 deletions(-) -- 2.37.1
[PATCH 2/2] tests/migration: add support for ppc64le for guestperf.py
Add support for ppc64le for guestperf.py. On ppc, console is usually
hvc0 and serial device for pseries machine is spapr-vty.
Signed-off-by: Murilo Opsfelder Araujo
---
tests/migration/guestperf/engine.py | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/tests/migration/guestperf/engine.py
b/tests/migration/guestperf/engine.py
index 87a6ab2009..88da516899 100644
--- a/tests/migration/guestperf/engine.py
+++ b/tests/migration/guestperf/engine.py
@@ -282,6 +282,26 @@ def _migrate(self, hardware, scenario, src, dst,
connect_uri):
resp = src.command("stop")
paused = True
+def _is_ppc64le(self):
+_, _, _, _, machine = os.uname()
+if machine == "ppc64le":
+return True
+return False
+
+def _get_guest_console_args(self):
+if self._is_ppc64le():
+return "console=hvc0"
+else:
+return "console=ttyS0"
+
+def _get_qemu_serial_args(self):
+if self._is_ppc64le():
+return ["-chardev", "stdio,id=cdev0",
+"-device", "spapr-vty,chardev=cdev0"]
+else:
+return ["-chardev", "stdio,id=cdev0",
+"-device", "isa-serial,chardev=cdev0"]
+
def _get_common_args(self, hardware, tunnelled=False):
args = [
"noapic",
@@ -290,8 +310,10 @@ def _get_common_args(self, hardware, tunnelled=False):
"noreplace-smp",
"cgroup_disable=memory",
"pci=noearly",
-"console=ttyS0",
]
+
+args.append(self._get_guest_console_args())
+
if self._debug:
args.append("debug")
else:
@@ -309,12 +331,12 @@ def _get_common_args(self, hardware, tunnelled=False):
"-kernel", self._kernel,
"-initrd", self._initrd,
"-append", cmdline,
-"-chardev", "stdio,id=cdev0",
-"-device", "isa-serial,chardev=cdev0",
"-m", str((hardware._mem * 1024) + 512),
"-smp", str(hardware._cpus),
]
+argv.extend(self._get_qemu_serial_args())
+
if self._debug:
argv.extend(["-device", "sga"])
--
2.37.1
Re: [PATCH for-7.2 06/10] ppc/pnv: enable user created pnv-phb for powernv8
On 8/8/22 13:50, Daniel Henrique Barboza wrote:
On 8/5/22 07:50, Frederic Barrat wrote:
diff --git a/hw/pci-host/pnv_phb.c b/hw/pci-host/pnv_phb.c
index 077f391d59..953c384bf6 100644
--- a/hw/pci-host/pnv_phb.c
+++ b/hw/pci-host/pnv_phb.c
@@ -17,6 +17,7 @@
#include "hw/ppc/pnv.h"
#include "hw/qdev-properties.h"
#include "qom/object.h"
+#include "sysemu/sysemu.h"
/*
@@ -171,6 +172,10 @@ static void pnv_phb_realize(DeviceState *dev, Error **errp)
pnv_phb4_bus_init(dev, PNV_PHB4(phb->backend));
}
+ if (phb->version == 3 && !defaults_enabled()) {
+ return;
+ }
+
pnv_phb_attach_root_port(pci);
}
So we skip the call to pnv_phb_attach_root_port() for the user created PHBs.
I seem to remember that when the user creates a PHB on the command line, they
also need to create the root port and we can't just create one by default with
the PHB. It seems heavy when just using the qemu CLI but that was a requirement
from libvirt. Did I get that right?
libvirt requires all pci devices to be declared in the XML. If we create the
root ports automatically by just adding PHBs I would need to reflect that
in the domain XML by either automatically add root ports with each PHB, which
is easier said than done, or tell the user to do so.
libvirt also allows for custom naming of the buses, e.g the PHB can be named
'phb-root0' and its root port 'my-rootport.1'. There's no way we can name
root ports buses by adding them automatically with each PHB like we do
for default PHBs.
In any case, I can see a problem. pnv_phb_attach_root_port() creates the root port
object, so if the above is correct, we want to skip that. But it also creates the
PHB->root port relationship in QOM. That we don't do anywhere for the
user-created case.
Calling qemu with "-nodefaults -device pnv-phb -device pnv-phb-root-port", here
is what I see in QOM, which shows the wrong parenting of the root port:
/peripheral-anon (container)
/device[1] (pnv-phb-root-port)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/pci_bridge_io[0] (memory-region)
/pci_bridge_io[1] (memory-region)
/pci_bridge_mem[0] (memory-region)
/pci_bridge_pci[0] (memory-region)
/pci_bridge_pref_mem[0] (memory-region)
/pci_bridge_vga_io_hi[0] (memory-region)
/pci_bridge_vga_io_lo[0] (memory-region)
/pci_bridge_vga_mem[0] (memory-region)
/pcie.0 (PCIE)
With the full series, same problem on P8/P9/P10
I forgot to mention it in the cover letter. This is intended. The reason
is that we can't access the PHB from the root-port due to QOM best
practices, i.e. we can't do qdev_get_parent_bus()->parent to parent
the root port with the PHB. The reason why we're able to do that for
default devices is because we have access to the PHB regardless of QOM
when creating the root port.
This is not correct. The default phb is parented by the root-bus, not the
PHB. E.g:
/pnv-phb4-root.9 (pnv-phb4-root)
/pnv-phb-root-port[3] (pnv-phb-root-port)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
(...)
Both default and user created cases have access to the phb-root-bus.
The reasoning behind the current QOM hierarchy is the existing design in place
for what it is called "dynamically created sysbus devices", which means all the
devices that are created via command line. If the device has an 'id' it'll be
inserted in a 'peripheral' container, if no 'id' is provided the device goes
into a 'peripheral-anon' container.
I managed to amend the root_port_realize() function to place the root-port
in the same place as the default root port appears. What I need to do now
before re-sending is verify whether I broke something else during the
process :)
Thanks,
Daniel
If we want QOM consistency between user created devices and default
devices, one alternative is to make the root-port a child of the
root bus. That can be achievable in both cases.
Thanks,
Daniel
Fred
Re: [PATCH v2 3/4] hw/riscv: virt: fix syscon subnode paths
On Mon, Aug 8, 2022 at 4:10 PM wrote:
>
> On 08/08/2022 22:28, Jessica Clarke wrote:
> > On 8 Aug 2022, at 22:06, Conor Dooley wrote:
> >>
> >> From: Conor Dooley
> >>
> >> The subnodes of the syscon have been added to the incorrect paths.
> >> Rather than add them as subnodes, they were originally added to "/foo"
> >> and a later patch moved them to "/soc/foo". Both are incorrect & they
> >> should have been added as "/soc/test@###/foo" as "/soc/test" is the
> >> syscon node. Fix both the reboot and poweroff subnodes to avoid errors
> >> such as:
> >>
> >> /stuff/qemu/qemu.dtb: soc: poweroff: {'value': [[21845]], 'offset': [[0]],
> >> 'regmap': [[4]], 'compatible': ['syscon-poweroff']} should not be valid
> >> under {'type': 'object'}
> >>From schema:
> >> /home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
> >> /stuff/qemu/qemu.dtb: soc: reboot: {'value': [[30583]], 'offset': [[0]],
> >> 'regmap': [[4]], 'compatible': ['syscon-reboot']} should not be valid
> >> under {'type': 'object'}
> >>From schema:
> >> /home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
> >>
> >> Reported-by: Rob Herring
> >> Link:
> >> https://lore.kernel.org/linux-riscv/20220803170552.ga2250266-r...@kernel.org/
> >> Fixes: 18df0b4695 ("hw/riscv: virt: Allow creating multiple NUMA sockets")
> >> Fixes: 0e404da007 ("riscv/virt: Add syscon reboot and poweroff DT nodes")
> >> Reviewed-by: Alistair Francis
> >> Signed-off-by: Conor Dooley
> >
> > This breaks FreeBSD’s driver (well, it just won’t probe/attach), which
> > is written to handle syscon-poweroff/reboot existing as a child of a
> > simplebus not a syscon.
It probably breaks Linux, too.
> I know next to nothing about FreeBSD unfortunately or how it handles
> buses. My understanding of simple-bus was that it is supposed to
> represent a bus with "things" mapped to addresses, relying on the "reg"
> property. And then syscon is used when there is some multifunction
> register region that controls multiple features of the hardware.
> Since simple-bus defines a reg property and the function nodes do not
> define one, I'd like to know how FreeBSD's driver handles that.
>
> > Moreover, what is the point of regmap in this
> > case? Its existence suggests the point is for them to *not* be children
> > of the syscon, otherwise you wouldn’t need an explicit phandle, you’d
> > just look at the parent. Moving the nodes whilst keeping the property
> > doesn’t make sense to me.
>
> That's how syscon bindings are constructed, makes it easier to follow
> I suppose if they functions are children of the syscon node. Strictly
> I think they don't need to be under the syscon itself, I think they can
> also go at the top level - they just aren't valid under the /soc node
> as it has been defined as a "simple-bus".
>
> It would appear that the original patch 0e404da007 ("riscv/virt: Add
> syscon reboot and poweroff DT nodes") that added them put them at the
> top level and it was in the refactor that they got moved to the soc bus.*
> Maybe the solution would be to put them back at the top level?
Perhaps.
The other option is adding 'simple-mfd' to the 'test' node compatible.
That would work for Linux. Not sure for FreeBSD.
Rob
Re: [PATCH for-7.2 v2 01/20] hw/arm: do not free machine->fdt in arm_load_dtb()
On 8/8/22 00:23, David Gibson wrote:
On Fri, Aug 05, 2022 at 06:39:29AM -0300, Daniel Henrique Barboza wrote:
At this moment, arm_load_dtb() can free machine->fdt when
binfo->dtb_filename is NULL. If there's no 'dtb_filename', 'fdt' will be
retrieved by binfo->get_dtb(). If get_dtb() returns machine->fdt, as is
the case of machvirt_dtb() from hw/arm/virt.c, fdt now has a pointer to
machine->fdt. And, in that case, the existing g_free(fdt) at the end of
arm_load_dtb() will make machine->fdt point to an invalid memory region.
This is not an issue right now because there's no code that access
machine->fdt after arm_load_dtb(), but we're going to add a couple do
FDT HMP commands that will rely on machine->fdt being valid.
Instead of freeing 'fdt' at the end of arm_load_dtb(), assign it to
machine->fdt. This will allow the FDT of ARM machines that relies on
arm_load_dtb() to be accessed later on.
Since all ARM machines allocates the FDT only once, we don't need to
worry about leaking the existing FDT during a machine reset (which is
something that other machines have to look after, e.g. the ppc64 pSeries
machine).
Cc: Peter Maydell
Cc: qemu-...@nongnu.org
Signed-off-by: Daniel Henrique Barboza
---
hw/arm/boot.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index ada2717f76..9f5ceb62d2 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -684,7 +684,13 @@ int arm_load_dtb(hwaddr addr, const struct arm_boot_info
*binfo,
*/
rom_add_blob_fixed_as("dtb", fdt, size, addr, as);
-g_free(fdt);
+/*
+ * Update the ms->fdt pointer to enable support for 'dumpdtb'
+ * and 'info fdt' commands. Use fdt_pack() to shrink the blob
+ * size we're going to store.
+ */
+fdt_pack(fdt);
+ms->fdt = fdt;
return size;
fdt_pack() could change (reduce) the effective size of the dtb blob,
so returning a 'size' value from above rather than the new value of
fdt_totalsize(fdt) doesn't see right.
I believe some of the other patches in the series have similar concerns.
Ok! I'll revisit those patches and be sure to return the updated value
of the fdt.
Thanks,
Daniel
Re: Deadlock between bdrv_drain_all_begin and prepare_mmio_access
On 8/2/22 08:35, Kevin Wolf wrote:
Am 24.07.2022 um 23:41 hat Liang Yan geschrieben:
Hello All,
I am facing a lock situation between main-loop thread 1 and vcpu thread 4
when doing a qmp snapshot. QEMU is running on 6.0.x, checked the upstream
code and did not see any big change since between. Guest is a Windows 10 VM.
Unfortunately, I could not get into the windows vm or reproduce the issue by
myself. No iothread is used here, native aio only.
From the code,
-> AIO_WAIT_WHILE(NULL, bdrv_drain_all_poll());
--> aio_poll(qemu_get_aio_context(), true);
Mainloop mutex is locked when start snapshot in thread 1, vcpu released
thread lock when address_space_rw and try to get thread lock again in
prepare_mmio_access.
It seems main loop thread is stuck at aio_poll with blocking, but I can not
figure out what the addr=4275044592 belongs to from mmio read.
I do not quite understand what really happens here, either block jobs never
drained out or maybe a block io read from vcpu and cause a deadlock? I hope
domain experts here could help figure out the root cause, thanks in advance
and let me know if need any further information.
This does not look like a deadlock to me: Thread 4 is indeed waiting for
thread 1 to release the lock, but I don't think thread 1 is waiting in
any way for thread 4.
In thread 1, bdrv_drain_all_begin() waits for all in-flight I/O requests
to complete. So it looks a bit like some I/O request got stuck. If you
want to debug this a bit further, try to check what it is that makes
bdrv_drain_poll() still return true.
Thanks for the reply.
I agree it is not a pure deadlock. thread 1 seems have more
responsibility here.
Do you know if there is a way to check in-flight I/O requests here? Is
it possible that the i/o request is the mmio_read from thread 4?
I could only see the addr=4275044592, but could not identify which
address space it is belonged.
I am also pretty curious why bdrv_drain_poll() always return true. Any
chance that it is blocked in aio_poll(qemu_get_aio_context(), true)?
while((cond)) { \
if(ctx_) { \
aio_context_release(ctx_); \
} \
aio_poll(qemu_get_aio_context(), true);
As mentioned, I only have a dump file, could not reproduce it in my
local environment.
Though, I have been working on a log patch to print all fd/aio-handlers
that main-loop is dispatched.
Please also add the QEMU command line you're using, especially the
configuration of the block device backends (for example, does this use
Linux AIO, the thread pool or io_uring?).
it uses native linux aio, and no extra io-thread is assigned here.
-blockdev
{"driver":"file","filename":".raw","aio":"native","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"}
-device
virtio-blk-pci,bus=pci.0,addr=0x6,drive=libvirt-2-format,id=virtio-disk0,bootindex=1,write-cache=on
Let me now if you need more information and thanks for looking into this
issue.
~Liang
Kevin
[PULL 2/3] hw/mips/malta: turn off x86 specific features of PIIX4_PM
From: Igor Mammedov
QEMU crashes trying to save VMSTATE when only MIPS target are compiled in
$ qemu-system-mips -monitor stdio
(qemu) migrate "exec:gzip -c > STATEFILE.gz"
Segmentation fault (core dumped)
It happens due to PIIX4_PM trying to parse hotplug vmstate structures
which are valid only for x86 and not for MIPS (as it requires ACPI
tables support which is not existent for ithe later)
Issue was probably exposed by trying to cleanup/compile out unused
ACPI bits from MIPS target (but forgetting about migration bits).
Disable compiled out features using compat properties as the least
risky way to deal with issue.
Signed-off-by: Igor Mammedov
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/995
Reviewed-by: Ani Sinha
Acked-by: Michael S. Tsirkin
Message-Id: <20220728115034.1327988-1-imamm...@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé
---
hw/mips/malta.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/mips/malta.c b/hw/mips/malta.c
index 7a0ec513b0..0e932988e0 100644
--- a/hw/mips/malta.c
+++ b/hw/mips/malta.c
@@ -1442,6 +1442,14 @@ static const TypeInfo mips_malta_device = {
.instance_init = mips_malta_instance_init,
};
+GlobalProperty malta_compat[] = {
+{ "PIIX4_PM", "memory-hotplug-support", "off" },
+{ "PIIX4_PM", "acpi-pci-hotplug-with-bridge-support", "off" },
+{ "PIIX4_PM", "acpi-root-pci-hotplug", "off" },
+{ "PIIX4_PM", "x-not-migrate-acpi-index", "true" },
+};
+const size_t malta_compat_len = G_N_ELEMENTS(malta_compat);
+
static void mips_malta_machine_init(MachineClass *mc)
{
mc->desc = "MIPS Malta Core LV";
@@ -1455,6 +1463,7 @@ static void mips_malta_machine_init(MachineClass *mc)
mc->default_cpu_type = MIPS_CPU_TYPE_NAME("24Kf");
#endif
mc->default_ram_id = "mips_malta.ram";
+compat_props_add(mc->compat_props, malta_compat, malta_compat_len);
}
DEFINE_MACHINE("malta", mips_malta_machine_init)
--
2.36.1
[PULL 3/3] hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses
From: Peter Maydell
In real hardware, the APB and AHB PNP data tables can be accessed
with byte and halfword reads as well as word reads. Our
implementation currently only handles word reads. Add support for
the 8 and 16 bit accesses. Note that we only need to handle aligned
accesses -- unaligned accesses should continue to trap, as happens on
hardware.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1132
Signed-off-by: Peter Maydell
Reviewed-by: Frederic Konrad
Message-Id: <20220802131925.3380923-1-peter.mayd...@linaro.org>
Tested-by: Tomasz Martyniak
Signed-off-by: Philippe Mathieu-Daudé
---
hw/misc/grlib_ahb_apb_pnp.c | 10 ++
hw/misc/trace-events| 4 ++--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index 43e001c3c7..5b05f15859 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -136,7 +136,8 @@ static uint64_t grlib_ahb_pnp_read(void *opaque, hwaddr
offset, unsigned size)
uint32_t val;
val = ahb_pnp->regs[offset >> 2];
-trace_grlib_ahb_pnp_read(offset, val);
+val = extract32(val, (4 - (offset & 3) - size) * 8, size * 8);
+trace_grlib_ahb_pnp_read(offset, size, val);
return val;
}
@@ -152,7 +153,7 @@ static const MemoryRegionOps grlib_ahb_pnp_ops = {
.write = grlib_ahb_pnp_write,
.endianness = DEVICE_BIG_ENDIAN,
.impl = {
-.min_access_size = 4,
+.min_access_size = 1,
.max_access_size = 4,
},
};
@@ -247,7 +248,8 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr
offset, unsigned size)
uint32_t val;
val = apb_pnp->regs[offset >> 2];
-trace_grlib_apb_pnp_read(offset, val);
+val = extract32(val, (4 - (offset & 3) - size) * 8, size * 8);
+trace_grlib_apb_pnp_read(offset, size, val);
return val;
}
@@ -263,7 +265,7 @@ static const MemoryRegionOps grlib_apb_pnp_ops = {
.write = grlib_apb_pnp_write,
.endianness = DEVICE_BIG_ENDIAN,
.impl = {
-.min_access_size = 4,
+.min_access_size = 1,
.max_access_size = 4,
},
};
diff --git a/hw/misc/trace-events b/hw/misc/trace-events
index 4d51a80de1..c18bc0605e 100644
--- a/hw/misc/trace-events
+++ b/hw/misc/trace-events
@@ -247,8 +247,8 @@ via1_adb_poll(uint8_t data, const char *vadbint, int
status, int index, int size
via1_auxmode(int mode) "setting auxmode to %d"
# grlib_ahb_apb_pnp.c
-grlib_ahb_pnp_read(uint64_t addr, uint32_t value) "AHB PnP read
addr:0x%03"PRIx64" data:0x%08x"
-grlib_apb_pnp_read(uint64_t addr, uint32_t value) "APB PnP read
addr:0x%03"PRIx64" data:0x%08x"
+grlib_ahb_pnp_read(uint64_t addr, unsigned size, uint32_t value) "AHB PnP read
addr:0x%03"PRIx64" size:%u data:0x%08x"
+grlib_apb_pnp_read(uint64_t addr, unsigned size, uint32_t value) "APB PnP read
addr:0x%03"PRIx64" size:%u data:0x%08x"
# led.c
led_set_intensity(const char *color, const char *desc, uint8_t
intensity_percent) "LED desc:'%s' color:%s intensity: %u%%"
--
2.36.1
[PULL 1/3] target/mips: Handle lock_user() failure in UHI_plog semihosting call
From: Peter Maydell
Coverity notes that we forgot to check the error return from
lock_user() in one place in the handling of the UHI_plog semihosting
call. Add the missing error handling.
report_fault() is rather brutal in that it will call abort(), but
this is the same error-handling used in the rest of this file.
Resolves: Coverity CID 1490684
Fixes: ea4210600db3c5 ("target/mips: Avoid qemu_semihosting_log_out for
UHI_plog")
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20220719191737.384744-1-peter.mayd...@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé
---
target/mips/tcg/sysemu/mips-semi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/target/mips/tcg/sysemu/mips-semi.c
b/target/mips/tcg/sysemu/mips-semi.c
index 5fb1ad9092..85f0567a7f 100644
--- a/target/mips/tcg/sysemu/mips-semi.c
+++ b/target/mips/tcg/sysemu/mips-semi.c
@@ -321,6 +321,9 @@ void mips_semihosting(CPUMIPSState *env)
if (use_gdb_syscalls()) {
addr = gpr[29] - str->len;
p = lock_user(VERIFY_WRITE, addr, str->len, 0);
+if (!p) {
+report_fault(env);
+}
memcpy(p, str->str, str->len);
unlock_user(p, addr, str->len);
semihost_sys_write(cs, uhi_cb, 2, addr, str->len);
--
2.36.1
[PULL 0/3] MIPS/SPARC patches for 2022-08-09
The following changes since commit 8a1337e60400ef54432e063164faf5043a5d: Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging (2022-08-08 09:57:37 -0700) are available in the Git repository at: https://github.com/philmd/qemu.git tags/mips-20220809 for you to fetch changes up to 09d12c81ec5d8dc9208e5739d17a56c34be96247: hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses (2022-08-08 23:43:11 +0200) MIPS/SPARC patches queue - target/mips: Handle lock_user failure in UHI_plog semihosting (Peter Maydell) - hw/mips/malta: Turn off x86 specific features of PIIX4 PM (Igor Mammedov) - hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses (Peter Maydell) Igor Mammedov (1): hw/mips/malta: turn off x86 specific features of PIIX4_PM Peter Maydell (2): target/mips: Handle lock_user() failure in UHI_plog semihosting call hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses hw/mips/malta.c| 9 + hw/misc/grlib_ahb_apb_pnp.c| 10 ++ hw/misc/trace-events | 4 ++-- target/mips/tcg/sysemu/mips-semi.c | 3 +++ 4 files changed, 20 insertions(+), 6 deletions(-) -- 2.36.1
Re: [PATCH v2 3/4] hw/riscv: virt: fix syscon subnode paths
On 08/08/2022 22:28, Jessica Clarke wrote:
> On 8 Aug 2022, at 22:06, Conor Dooley wrote:
>>
>> From: Conor Dooley
>>
>> The subnodes of the syscon have been added to the incorrect paths.
>> Rather than add them as subnodes, they were originally added to "/foo"
>> and a later patch moved them to "/soc/foo". Both are incorrect & they
>> should have been added as "/soc/test@###/foo" as "/soc/test" is the
>> syscon node. Fix both the reboot and poweroff subnodes to avoid errors
>> such as:
>>
>> /stuff/qemu/qemu.dtb: soc: poweroff: {'value': [[21845]], 'offset': [[0]],
>> 'regmap': [[4]], 'compatible': ['syscon-poweroff']} should not be valid
>> under {'type': 'object'}
>>From schema:
>> /home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
>> /stuff/qemu/qemu.dtb: soc: reboot: {'value': [[30583]], 'offset': [[0]],
>> 'regmap': [[4]], 'compatible': ['syscon-reboot']} should not be valid under
>> {'type': 'object'}
>>From schema:
>> /home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
>>
>> Reported-by: Rob Herring
>> Link:
>> https://lore.kernel.org/linux-riscv/20220803170552.ga2250266-r...@kernel.org/
>> Fixes: 18df0b4695 ("hw/riscv: virt: Allow creating multiple NUMA sockets")
>> Fixes: 0e404da007 ("riscv/virt: Add syscon reboot and poweroff DT nodes")
>> Reviewed-by: Alistair Francis
>> Signed-off-by: Conor Dooley
>
> This breaks FreeBSD’s driver (well, it just won’t probe/attach), which
> is written to handle syscon-poweroff/reboot existing as a child of a
> simplebus not a syscon.
I know next to nothing about FreeBSD unfortunately or how it handles
buses. My understanding of simple-bus was that it is supposed to
represent a bus with "things" mapped to addresses, relying on the "reg"
property. And then syscon is used when there is some multifunction
register region that controls multiple features of the hardware.
Since simple-bus defines a reg property and the function nodes do not
define one, I'd like to know how FreeBSD's driver handles that.
> Moreover, what is the point of regmap in this
> case? Its existence suggests the point is for them to *not* be children
> of the syscon, otherwise you wouldn’t need an explicit phandle, you’d
> just look at the parent. Moving the nodes whilst keeping the property
> doesn’t make sense to me.
That's how syscon bindings are constructed, makes it easier to follow
I suppose if they functions are children of the syscon node. Strictly
I think they don't need to be under the syscon itself, I think they can
also go at the top level - they just aren't valid under the /soc node
as it has been defined as a "simple-bus".
It would appear that the original patch 0e404da007 ("riscv/virt: Add
syscon reboot and poweroff DT nodes") that added them put them at the
top level and it was in the refactor that they got moved to the soc bus.*
Maybe the solution would be to put them back at the top level?
dt-validate will consider it valid, but what does the FreeBSD driver
think of that?
Thanks for your input Jess,
Conor.
* On reflection it looks like my fixes tags are not correct and that
0e404da007 was actually correct but the refactor broke things.
>
> Jess
>
>> ---
>> hw/riscv/virt.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
>> index 8b2978076e..a98b054545 100644
>> --- a/hw/riscv/virt.c
>> +++ b/hw/riscv/virt.c
>> @@ -896,7 +896,8 @@ static void create_fdt_reset(RISCVVirtState *s, const
>> MemMapEntry *memmap,
>> test_phandle = qemu_fdt_get_phandle(mc->fdt, name);
>> g_free(name);
>>
>> -name = g_strdup_printf("/soc/reboot");
>> +name = g_strdup_printf("/soc/test@%lx/reboot",
>> +(long)memmap[VIRT_TEST].base);
>> qemu_fdt_add_subnode(mc->fdt, name);
>> qemu_fdt_setprop_string(mc->fdt, name, "compatible", "syscon-reboot");
>> qemu_fdt_setprop_cell(mc->fdt, name, "regmap", test_phandle);
>> @@ -904,7 +905,8 @@ static void create_fdt_reset(RISCVVirtState *s, const
>> MemMapEntry *memmap,
>> qemu_fdt_setprop_cell(mc->fdt, name, "value", FINISHER_RESET);
>> g_free(name);
>>
>> -name = g_strdup_printf("/soc/poweroff");
>> +name = g_strdup_printf("/soc/test@%lx/poweroff",
>> +(long)memmap[VIRT_TEST].base);
>> qemu_fdt_add_subnode(mc->fdt, name);
>> qemu_fdt_setprop_string(mc->fdt, name, "compatible", "syscon-poweroff");
>> qemu_fdt_setprop_cell(mc->fdt, name, "regmap", test_phandle);
>> --
>> 2.37.1
>>
>>
>> ___
>> linux-riscv mailing list
>> linux-ri...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
Re: [PATCH 1/2] util/main-loop: Fix maximum number of wait objects for win32
On Mon, Aug 8, 2022 at 5:56 PM Bin Meng wrote: > On Fri, Aug 5, 2022 at 10:56 PM Bin Meng wrote: > > > > From: Bin Meng > > > > The maximum number of wait objects for win32 should be > > MAXIMUM_WAIT_OBJECTS, not MAXIMUM_WAIT_OBJECTS + 1. > > > > Signed-off-by: Bin Meng > > --- > > > > util/main-loop.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > Ping? Reviewed-by: Philippe Mathieu-Daudé NB: qemu_del_wait_object() seems dubious in case the same handle is added more than once with qemu_add_wait_object().
Re: [PATCH v2] virtio-scsi: fix race in virtio_scsi_dataplane_start()
On Mon, Aug 08, 2022 at 12:21:34PM -0400, Stefan Hajnoczi wrote:
> As soon as virtio_scsi_data_plane_start() attaches host notifiers the
> IOThread may start virtqueue processing. There is a race between
> IOThread virtqueue processing and virtio_scsi_data_plane_start() because
> it only assigns s->dataplane_started after attaching host notifiers.
>
> When a virtqueue handler function in the IOThread calls
> virtio_scsi_defer_to_dataplane() it may see !s->dataplane_started and
> attempt to start dataplane even though we're already in the IOThread:
>
> #0 0x7f67b360857c __pthread_kill_implementation (libc.so.6 + 0xa257c)
> #1 0x7f67b35bbd56 raise (libc.so.6 + 0x55d56)
> #2 0x7f67b358e833 abort (libc.so.6 + 0x28833)
> #3 0x7f67b358e75b __assert_fail_base.cold (libc.so.6 + 0x2875b)
> #4 0x7f67b35b4cd6 __assert_fail (libc.so.6 + 0x4ecd6)
> #5 0x55ca87fd411b memory_region_transaction_commit (qemu-kvm +
> 0x67511b)
> #6 0x55ca87e17811 virtio_pci_ioeventfd_assign (qemu-kvm + 0x4b8811)
> #7 0x55ca87e14836 virtio_bus_set_host_notifier (qemu-kvm + 0x4b5836)
> #8 0x55ca87f8e14e virtio_scsi_set_host_notifier (qemu-kvm + 0x62f14e)
> #9 0x55ca87f8dd62 virtio_scsi_dataplane_start (qemu-kvm + 0x62ed62)
> #10 0x55ca87e14610 virtio_bus_start_ioeventfd (qemu-kvm + 0x4b5610)
> #11 0x55ca87f8c29a virtio_scsi_handle_ctrl (qemu-kvm + 0x62d29a)
> #12 0x55ca87fa5902 virtio_queue_host_notifier_read (qemu-kvm + 0x646902)
> #13 0x55ca882c099e aio_dispatch_handler (qemu-kvm + 0x96199e)
> #14 0x55ca882c1761 aio_poll (qemu-kvm + 0x962761)
> #15 0x55ca880e1052 iothread_run (qemu-kvm + 0x782052)
> #16 0x55ca882c562a qemu_thread_start (qemu-kvm + 0x96662a)
>
> This patch assigns s->dataplane_started before attaching host notifiers
> so that virtqueue handler functions that run in the IOThread before
> virtio_scsi_data_plane_start() returns correctly identify that dataplane
> does not need to be started. This fix is taken from the virtio-blk
> dataplane code and it's worth adding a comment in virtio-blk as well to
> explain why it works.
>
> Note that s->dataplane_started does not need the AioContext lock because
> it is set before attaching host notifiers and cleared after detaching
> host notifiers. In other words, the IOThread always sees the value true
> and the main loop thread does not modify it while the IOThread is
> active.
>
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2099541
> Reported-by: Qing Wang
> Signed-off-by: Stefan Hajnoczi
Reviewed-by: Michael S. Tsirkin
> ---
> v2:
> - Switch to a smaller fix inspired by virtio-blk and document why
> virtio-blk works [Paolo]
>
> hw/block/dataplane/virtio-blk.c | 5 +
> hw/scsi/virtio-scsi-dataplane.c | 11 ---
> 2 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
> index 49276e46f2..26f965cabc 100644
> --- a/hw/block/dataplane/virtio-blk.c
> +++ b/hw/block/dataplane/virtio-blk.c
> @@ -219,6 +219,11 @@ int virtio_blk_data_plane_start(VirtIODevice *vdev)
>
> memory_region_transaction_commit();
>
> +/*
> + * These fields are visible to the IOThread so we rely on implicit
> barriers
> + * in aio_context_acquire() on the write side and aio_notify_accept() on
> + * the read side.
> + */
> s->starting = false;
> vblk->dataplane_started = true;
> trace_virtio_blk_data_plane_start(s);
> diff --git a/hw/scsi/virtio-scsi-dataplane.c b/hw/scsi/virtio-scsi-dataplane.c
> index 8bb6e6acfc..20bb91766e 100644
> --- a/hw/scsi/virtio-scsi-dataplane.c
> +++ b/hw/scsi/virtio-scsi-dataplane.c
> @@ -136,6 +136,14 @@ int virtio_scsi_dataplane_start(VirtIODevice *vdev)
>
> memory_region_transaction_commit();
>
> +/*
> + * These fields are visible to the IOThread so we rely on implicit
> barriers
> + * in aio_context_acquire() on the write side and aio_notify_accept() on
> + * the read side.
> + */
> +s->dataplane_starting = false;
> +s->dataplane_started = true;
> +
> aio_context_acquire(s->ctx);
> virtio_queue_aio_attach_host_notifier(vs->ctrl_vq, s->ctx);
> virtio_queue_aio_attach_host_notifier_no_poll(vs->event_vq, s->ctx);
> @@ -143,9 +151,6 @@ int virtio_scsi_dataplane_start(VirtIODevice *vdev)
> for (i = 0; i < vs->conf.num_queues; i++) {
> virtio_queue_aio_attach_host_notifier(vs->cmd_vqs[i], s->ctx);
> }
> -
> -s->dataplane_starting = false;
> -s->dataplane_started = true;
> aio_context_release(s->ctx);
> return 0;
>
> --
> 2.37.1
Re: [PATCH for-7.1] hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 bit accesses
On Mon, Aug 8, 2022 at 11:15 AM Konrad, Frederic wrote: > > -Original Message- > > From: Peter Maydell > > Sent: 02 August 2022 15:34 > > To: Konrad, Frederic > > Cc: qemu-devel@nongnu.org; Fabien Chouteau ; > > Frederic Konrad ; f4...@amsat.org > > Subject: Re: [PATCH for-7.1] hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 > > bit accesses > > > > On Tue, 2 Aug 2022 at 15:20, Konrad, Frederic > > wrote: > > > > > > Hi Peter, > > > > > > CC'ing Philippe. > > > > > > > -Original Message- > > > > From: Qemu-devel > > > bounces+fkonrad=amd@nongnu.org> On Behalf Of Peter Maydell > > > > Sent: 02 August 2022 14:19 > > > > To: qemu-devel@nongnu.org > > > > Cc: Fabien Chouteau ; Frederic Konrad > > > > > > > > Subject: [PATCH for-7.1] hw/misc/grlib_ahb_apb_pnp: Support 8 and 16 > > bit > > > > accesses > > > > > > > > In real hardware, the APB and AHB PNP data tables can be accessed > > > > with byte and halfword reads as well as word reads. Our > > > > implementation currently only handles word reads. Add support for > > > > the 8 and 16 bit accesses. Note that we only need to handle aligned > > > > accesses -- unaligned accesses should continue to trap, as happens on > > > > hardware. > > > > > > > > Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1132 > > > > Signed-off-by: Peter Maydell > > > > --- > > > > It would be nice if we could just set the .valid.min_access_size in > > > > the MemoryRegionOps to 1 and have the memory system core > > synthesize > > > > the 1 and 2 byte accesses from a 4 byte read, but currently that > > > > doesn't work (see various past mailing list threads). > > > > > > That looks good to me but I thought this was fixed by 1a5a5570 and > > 0fbe394a > > > because RTEMS do bytes accesses? > > > > > > Did that break at some point? > > > > I definitely tried letting the .impl vs .valid settings handle this, > > but the access_with_adjusted_size() code doesn't do the right thing. > > (In particular, the test case ELF in the bug report works with > > this patch, and doesn't work without it...) > > > > I'm pretty sure the problem with access_with_adjusted_size() is a > > long-standing bug -- I found a couple of mailing list threads about > > it. We really ought to fix that properly, but that's definitely not > > for-7.1 material. > > Ok got it, thanks. > > Reviewed-by: Frederic Konrad Thanks Frederic. Mark, Peter, since I'm preparing a pull request for MIPS, I'll queue this single SPARC patch. Per https://gitlab.com/qemu-project/qemu/-/issues/1132#note_1048558340 I'll also add: Tested-by: Tomasz Martyniak Regards, Phil.
Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM
Am 8. August 2022 20:02:50 MESZ schrieb Peter Maydell : >On Mon, 8 Aug 2022 at 18:57, BB wrote: >> Am 8. August 2022 14:15:40 MESZ schrieb Igor Mammedov : >> >On Wed, 3 Aug 2022 19:26:30 +0200 >> >While refactoring we should keep migration stream compatible with older >> >QEMU versions (we must not regress widely x86 code path). Which might be >> >tricky in this case. >> >> Does this particular fix make future compatibility harder or easier or is it >> that hard already? IIUC it omits the hotplug bits in the vm state for Malta >> which is what one would expect there, right? > >This patch's fix only affects Malta. It is (I suspect but have >not tested) a migration compat break on Malta, but we don't >care about cross-version migration compat for that board anyway. >Migration compat matters (to a first approximation) only for >those boards which have versioned machine types (eg pc-7.0, >pc-7.1, etc). For all other machine types we retain compat >only if it's easy. I see. Thanks for the clarification! Best regards, Bernhard > >thanks >-- PMM
Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM
On Thu, Jul 28, 2022 at 1:50 PM Igor Mammedov wrote: > > QEMU crashes trying to save VMSTATE when only MIPS target are compiled in > $ qemu-system-mips -monitor stdio > (qemu) migrate "exec:gzip -c > STATEFILE.gz" > Segmentation fault (core dumped) > > It happens due to PIIX4_PM trying to parse hotplug vmstate structures > which are valid only for x86 and not for MIPS (as it requires ACPI > tables support which is not existent for ithe later) > > Issue was probably exposed by trying to cleanup/compile out unused > ACPI bits from MIPS target (but forgetting about migration bits). > > Disable compiled out features using compat properties as the least > risky way to deal with issue. > > Signed-off-by: Igor Mammedov > --- > PS: > another approach could be setting defaults to disabled state and > enabling them using compat props on PC machines (which is more > code to deal with => more risky) or continue with PIIX4_PM > refactoring to split x86-shism out (which I'm not really > interested in due to risk of regressions for not much of > benefit) > --- > hw/mips/malta.c | 9 + > 1 file changed, 9 insertions(+) Thanks, queued to mips-fixes.
Re: [PATCH v2 3/4] hw/riscv: virt: fix syscon subnode paths
On 8 Aug 2022, at 22:06, Conor Dooley wrote:
>
> From: Conor Dooley
>
> The subnodes of the syscon have been added to the incorrect paths.
> Rather than add them as subnodes, they were originally added to "/foo"
> and a later patch moved them to "/soc/foo". Both are incorrect & they
> should have been added as "/soc/test@###/foo" as "/soc/test" is the
> syscon node. Fix both the reboot and poweroff subnodes to avoid errors
> such as:
>
> /stuff/qemu/qemu.dtb: soc: poweroff: {'value': [[21845]], 'offset': [[0]],
> 'regmap': [[4]], 'compatible': ['syscon-poweroff']} should not be valid under
> {'type': 'object'}
>From schema:
> /home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
> /stuff/qemu/qemu.dtb: soc: reboot: {'value': [[30583]], 'offset': [[0]],
> 'regmap': [[4]], 'compatible': ['syscon-reboot']} should not be valid under
> {'type': 'object'}
>From schema:
> /home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
>
> Reported-by: Rob Herring
> Link:
> https://lore.kernel.org/linux-riscv/20220803170552.ga2250266-r...@kernel.org/
> Fixes: 18df0b4695 ("hw/riscv: virt: Allow creating multiple NUMA sockets")
> Fixes: 0e404da007 ("riscv/virt: Add syscon reboot and poweroff DT nodes")
> Reviewed-by: Alistair Francis
> Signed-off-by: Conor Dooley
This breaks FreeBSD’s driver (well, it just won’t probe/attach), which
is written to handle syscon-poweroff/reboot existing as a child of a
simplebus not a syscon. Moreover, what is the point of regmap in this
case? Its existence suggests the point is for them to *not* be children
of the syscon, otherwise you wouldn’t need an explicit phandle, you’d
just look at the parent. Moving the nodes whilst keeping the property
doesn’t make sense to me.
Jess
> ---
> hw/riscv/virt.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index 8b2978076e..a98b054545 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -896,7 +896,8 @@ static void create_fdt_reset(RISCVVirtState *s, const
> MemMapEntry *memmap,
> test_phandle = qemu_fdt_get_phandle(mc->fdt, name);
> g_free(name);
>
> -name = g_strdup_printf("/soc/reboot");
> +name = g_strdup_printf("/soc/test@%lx/reboot",
> +(long)memmap[VIRT_TEST].base);
> qemu_fdt_add_subnode(mc->fdt, name);
> qemu_fdt_setprop_string(mc->fdt, name, "compatible", "syscon-reboot");
> qemu_fdt_setprop_cell(mc->fdt, name, "regmap", test_phandle);
> @@ -904,7 +905,8 @@ static void create_fdt_reset(RISCVVirtState *s, const
> MemMapEntry *memmap,
> qemu_fdt_setprop_cell(mc->fdt, name, "value", FINISHER_RESET);
> g_free(name);
>
> -name = g_strdup_printf("/soc/poweroff");
> +name = g_strdup_printf("/soc/test@%lx/poweroff",
> +(long)memmap[VIRT_TEST].base);
> qemu_fdt_add_subnode(mc->fdt, name);
> qemu_fdt_setprop_string(mc->fdt, name, "compatible", "syscon-poweroff");
> qemu_fdt_setprop_cell(mc->fdt, name, "regmap", test_phandle);
> --
> 2.37.1
>
>
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [PATCH] target/mips: Handle lock_user() failure in UHI_plog semihosting call
On Tue, Jul 19, 2022 at 9:17 PM Peter Maydell wrote:
>
> Coverity notes that we forgot to check the error return from
> lock_user() in one place in the handling of the UHI_plog semihosting
> call. Add the missing error handling.
>
> report_fault() is rather brutal in that it will call abort(), but
> this is the same error-handling used in the rest of this file.
>
> Resolves: Coverity CID 1490684
> Fixes: ea4210600db3c5 ("target/mips: Avoid qemu_semihosting_log_out for
> UHI_plog")
> Signed-off-by: Peter Maydell
> ---
> NB: only tested with 'make check' and 'make check-tcg', which
> almost certainly don't actually exercise this codepath.
> ---
> target/mips/tcg/sysemu/mips-semi.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Philippe Mathieu-Daudé
Queued to mips-fixes, thanks!
[PATCH v2 3/4] hw/riscv: virt: fix syscon subnode paths
From: Conor Dooley
The subnodes of the syscon have been added to the incorrect paths.
Rather than add them as subnodes, they were originally added to "/foo"
and a later patch moved them to "/soc/foo". Both are incorrect & they
should have been added as "/soc/test@###/foo" as "/soc/test" is the
syscon node. Fix both the reboot and poweroff subnodes to avoid errors
such as:
/stuff/qemu/qemu.dtb: soc: poweroff: {'value': [[21845]], 'offset': [[0]],
'regmap': [[4]], 'compatible': ['syscon-poweroff']} should not be valid under
{'type': 'object'}
From schema:
/home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
/stuff/qemu/qemu.dtb: soc: reboot: {'value': [[30583]], 'offset': [[0]],
'regmap': [[4]], 'compatible': ['syscon-reboot']} should not be valid under
{'type': 'object'}
From schema:
/home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
Reported-by: Rob Herring
Link:
https://lore.kernel.org/linux-riscv/20220803170552.ga2250266-r...@kernel.org/
Fixes: 18df0b4695 ("hw/riscv: virt: Allow creating multiple NUMA sockets")
Fixes: 0e404da007 ("riscv/virt: Add syscon reboot and poweroff DT nodes")
Reviewed-by: Alistair Francis
Signed-off-by: Conor Dooley
---
hw/riscv/virt.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 8b2978076e..a98b054545 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -896,7 +896,8 @@ static void create_fdt_reset(RISCVVirtState *s, const
MemMapEntry *memmap,
test_phandle = qemu_fdt_get_phandle(mc->fdt, name);
g_free(name);
-name = g_strdup_printf("/soc/reboot");
+name = g_strdup_printf("/soc/test@%lx/reboot",
+(long)memmap[VIRT_TEST].base);
qemu_fdt_add_subnode(mc->fdt, name);
qemu_fdt_setprop_string(mc->fdt, name, "compatible", "syscon-reboot");
qemu_fdt_setprop_cell(mc->fdt, name, "regmap", test_phandle);
@@ -904,7 +905,8 @@ static void create_fdt_reset(RISCVVirtState *s, const
MemMapEntry *memmap,
qemu_fdt_setprop_cell(mc->fdt, name, "value", FINISHER_RESET);
g_free(name);
-name = g_strdup_printf("/soc/poweroff");
+name = g_strdup_printf("/soc/test@%lx/poweroff",
+(long)memmap[VIRT_TEST].base);
qemu_fdt_add_subnode(mc->fdt, name);
qemu_fdt_setprop_string(mc->fdt, name, "compatible", "syscon-poweroff");
qemu_fdt_setprop_cell(mc->fdt, name, "regmap", test_phandle);
--
2.37.1
[PATCH v2 1/4] hw/riscv: virt: fix uart node name
From: Conor Dooley
"uart" is not a node name that complies with the dt-schema.
Change the node name to "serial" to ix warnings seen during
dt-validate on a dtbdump of the virt machine such as:
/stuff/qemu/qemu.dtb: uart@1000: $nodename:0: 'uart@1000' does not
match '^serial(@.*)?$'
From schema:
/stuff/linux/Documentation/devicetree/bindings/serial/8250.yaml
Reported-by: Rob Herring
Link:
https://lore.kernel.org/linux-riscv/20220803170552.ga2250266-r...@kernel.org/
Fixes: 04331d0b56 ("RISC-V VirtIO Machine")
Reviewed-by: Alistair Francis
Signed-off-by: Conor Dooley
---
hw/riscv/virt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index bc424dd2f5..6c61a406c4 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -917,7 +917,7 @@ static void create_fdt_uart(RISCVVirtState *s, const
MemMapEntry *memmap,
char *name;
MachineState *mc = MACHINE(s);
-name = g_strdup_printf("/soc/uart@%lx", (long)memmap[VIRT_UART0].base);
+name = g_strdup_printf("/soc/serial@%lx", (long)memmap[VIRT_UART0].base);
qemu_fdt_add_subnode(mc->fdt, name);
qemu_fdt_setprop_string(mc->fdt, name, "compatible", "ns16550a");
qemu_fdt_setprop_cells(mc->fdt, name, "reg",
--
2.37.1
[PATCH v2 2/4] hw/riscv: virt: Fix the plic's address cells
From: Conor Dooley
When optional AIA PLIC support was added the to the virt machine, the
address cells property was removed leading the issues with dt-validate
on a dump from the virt machine:
/stuff/qemu/qemu.dtb: plic@c00: '#address-cells' is a required property
From schema:
/stuff/linux/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
Add back the property to suppress the warning.
Reported-by: Rob Herring
Link:
https://lore.kernel.org/linux-riscv/20220803170552.ga2250266-r...@kernel.org/
Fixes: e6faee6585 ("hw/riscv: virt: Add optional AIA APLIC support to virt
machine")
Reviewed-by: Alistair Francis
Signed-off-by: Conor Dooley
---
hw/riscv/virt.c | 2 ++
include/hw/riscv/virt.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 6c61a406c4..8b2978076e 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -465,6 +465,8 @@ static void create_fdt_socket_plic(RISCVVirtState *s,
qemu_fdt_add_subnode(mc->fdt, plic_name);
qemu_fdt_setprop_cell(mc->fdt, plic_name,
"#interrupt-cells", FDT_PLIC_INT_CELLS);
+qemu_fdt_setprop_cell(mc->fdt, plic_name,
+"#address-cells", FDT_PLIC_ADDR_CELLS);
qemu_fdt_setprop_string_array(mc->fdt, plic_name, "compatible",
(char **)_compat,
ARRAY_SIZE(plic_compat));
diff --git a/include/hw/riscv/virt.h b/include/hw/riscv/virt.h
index 984e55c77f..be4ab8fe7f 100644
--- a/include/hw/riscv/virt.h
+++ b/include/hw/riscv/virt.h
@@ -111,6 +111,7 @@ enum {
#define FDT_PCI_ADDR_CELLS3
#define FDT_PCI_INT_CELLS 1
+#define FDT_PLIC_ADDR_CELLS 0
#define FDT_PLIC_INT_CELLS1
#define FDT_APLIC_INT_CELLS 2
#define FDT_IMSIC_INT_CELLS 0
--
2.37.1
[PATCH v2 0/4] QEMU: Fix RISC-V virt & spike machines' dtbs
From: Conor Dooley The device trees produced automatically for the virt and spike machines fail dt-validate on several grounds. Some of these need to be fixed in the linux kernel's dt-bindings, but others are caused by bugs in QEMU. I mostly opted for what appeared to be the smallest change that would fix the warnings, partly due to my inexperience with the QEMU codebase. A "sister" patchset for the kernel will clear the remaining warnings [0]. Thanks to Rob Herring for reporting these issues [1], Conor. Changes since v1: - drop patch 1 To reproduce the errors: ./build/qemu-system-riscv64 -nographic -machine virt,dumpdtb=qemu.dtb dt-validate -p /path/to/linux/kernel/Documentation/devicetree/bindings/processed-schema.json qemu.dtb (The processed schema needs to be generated first) 0 - https://lore.kernel.org/linux-riscv/20220805162844.1554247-1-m...@conchuod.ie 1 - https://lore.kernel.org/linux-riscv/20220803170552.ga2250266-r...@kernel.org Conor Dooley (4): hw/riscv: virt: fix uart node name hw/riscv: virt: Fix the plic's address cells hw/riscv: virt: fix syscon subnode paths hw/core: fix platform bus node name hw/core/sysbus-fdt.c| 2 +- hw/riscv/virt.c | 10 +++--- include/hw/riscv/virt.h | 1 + 3 files changed, 9 insertions(+), 4 deletions(-) base-commit: 2480f3bbd03814b0651a1f74959f5c6631ee5819 -- 2.37.1
[PATCH v2 4/4] hw/core: fix platform bus node name
From: Conor Dooley
"platform" is not a valid name for a bus node in dt-schema, so warnings
can be see in dt-validate on a dump of the riscv virt dtb:
/stuff/qemu/qemu.dtb: platform@400: $nodename:0: 'platform@400' does
not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
From schema:
/home/conor/.local/lib/python3.9/site-packages/dtschema/schemas/simple-bus.yaml
"platform-bus" is a valid name, so use that instead.
CC: Rob Herring
Fixes: 11d306b9df ("hw/arm/sysbus-fdt: helpers for platform bus nodes addition")
Reviewed-by: Alistair Francis
Signed-off-by: Conor Dooley
---
hw/core/sysbus-fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/core/sysbus-fdt.c b/hw/core/sysbus-fdt.c
index 19d22cbe73..edb0c49b19 100644
--- a/hw/core/sysbus-fdt.c
+++ b/hw/core/sysbus-fdt.c
@@ -539,7 +539,7 @@ void platform_bus_add_all_fdt_nodes(void *fdt, const char
*intc, hwaddr addr,
assert(fdt);
-node = g_strdup_printf("/platform@%"PRIx64, addr);
+node = g_strdup_printf("/platform-bus@%"PRIx64, addr);
/* Create a /platform node that we can put all devices into */
qemu_fdt_add_subnode(fdt, node);
--
2.37.1
Re: VGA hardware cursor query
On Mon, 8 Aug 2022, BALATON Zoltan wrote: On Sun, 7 Aug 2022, BALATON Zoltan wrote: On Sun, 7 Aug 2022, Mark Cave-Ayland wrote: On 07/08/2022 12:47, Elliot Nunn wrote: I want to give Mac OS 9 clients access to hardware cursor support, to improve responsiveness in absolute-cursor mode. Would it be acceptable to add a hardware cursor interface to the VGA device? And if so, can anyone advise on an appropriate register layout? This is an example of such a patch. Because it alters the Bochs VBE interface it is ONLY an example, NOT fit for acceptance. I have omitted the changes to the binary driver qemu_vga.ndrv. Kind regards, Elliot Nunn Nice work! Have you been in contact with the Bochs developers to see what their thoughts are to your proposed changes? Generally QEMU prefers to implement documented specifications, so this would be the best route to go. Thanks! I don't think it would be appropriate to update the Bochs standard with a feature that they don't use. And on reflection, perhaps the compatibility-oriented VGA device is big enough already. Sure, no worries. My plan is to write a Mac OS 9/X "ndrv" targeting virtio-gpu. All going this well, this might become the default mac99 GPU until ati-vga is ready. That sounds really interesting. Is there a forum/mailing list somewhere where it is possible to follow the Mac side of your work? I can certainly advise on the qemu-system-ppc side. But virtio-gpu is not compiled into qemu-system-ppc by default. What is the difference between CONFIG_VIRTIO_(GPU|PCI|VGA)? And is configs/devices/ppc-softmmu/default.mak the correct place to declare them? You probably want to add a "select VIRTIO_GPU_PCI" and/or "select VIRTIO_GPU_VGA" in the "config MAC_NEWWORLD" section of hw/ppc/Kconfig to enable the virtio devices for the mac99 machine. Not sure how this works but pc and pseries machines seem to have imply VIRTIO_VGA so probably that's what you need to add to config MAC_NEWWORLD or just try qemu-system-ppc64 -machine mac99,via=pmu -cpu G4 which should already have it due so pseries but may otherwise be equivalent to the one in qemu-system-ppc. I've tried this: qemu-system-ppc64 -M mac99,via=pmu -cpu G4 -m 512 \ -vga none -device virtio-vga,romfile=qemu_vga.ndrv \ -cdrom "Mac OS 9.2.2 Universal Install.iso" -boot d \ -serial stdio to see if it recognised the card in vga mode but it does not work. (Without the second line disabling stdvga and adding virtio-vgs this does boot for me.) The problem seems to be that openbios does not recognise the rom, maybe because it expects the rom to be at BAR 6 and only tries to map that but virtio-vga seems to have rombar=1 by default (see info qtree in monitor). I did not try if it's settable though so maybe adding virtio-vga,rombar=6 could get it further? I've tried with rombar=6 but it made no change. I don't fully get how this should work. Even by default when rombar=1 the virtio-vga device does not seem to have BAR 1 but has a BAR 6. Openbios seems to look for that but maybe only for vga devices it knows about. I thought it would also look for device class but maybe it needs to be added to openbios's pci database for it to recognise and try to detect an NDRV in ROM? Maybe Mark could look at it and advise. I think I gave up here, don't want to debug this further but getting MacOS 9 boot with virtio-vga in vga mode would give Elliot a good start to experiment with ndrv and not fight with QEMU and OpenBIOS instead just to get started. Regards, BALATON Zoltan
Re: [PATCH 1/5] target/riscv: Ignore the S and U letters when formatting ISA strings
On 08/08/2022 21:51, Alistair Francis wrote: > On Tue, Aug 9, 2022 at 2:14 AM wrote: >> I guess this patch can then be safely ignored :) >> Glad to have cleared this up as I was rather confused by what I saw. > > Great! Do you mind resending the series then with this patch dropped? > It just makes it easier for me to track and manage Aye, willdo.
Re: [PATCH 1/5] target/riscv: Ignore the S and U letters when formatting ISA strings
On Tue, Aug 9, 2022 at 2:14 AM wrote: > > On 08/08/2022 16:03, Tsukasa OI wrote: > > I agree with Alistair. **I** removed 'S' and 'U' from the ISA string > > and it should be working in the latest development branch (I tested). > > Yeah, I saw what you as I looked at the commit log while trying to > understand why there were invalid strings appearing when the code > looked like it was impossible. Certainly I found it very very odd. > I didn't just revive a 2 year old patch without taking a look at > the code. > > > > Besides, this function alone generates the ISA string for DTB and > > there's no way such ISA strings with invalid 'S' and 'U' can be > > generated. It's definitely a behavior of QEMU 7.0 or before. > > Hmm, it would seem that you're right - I have retested on a fresh > clone. I did checkout v7.1.0-rc1 before running the first build that > I saw the invalid string on as I'd been on some hacked up & fossilised > version prior to that. Perhaps some build artifacts were not correctly > removed, consider me quite confused! I do recall the configure script > saying something about my build directory when I kicked it off, so > it is likely down to that. > > Unfortunately my bash history is out of order so I will not be able to > replicate the conditions, having many terminals open does have it's > downsides. > > > Please. Please make sure that you are testing the right version of QEMU. > > Heh. Please, please give me some allowance for reasonably believing I > was in fact on the latest qemu/master after checking it out and building! No worries! Glad we cleared that up > > I guess this patch can then be safely ignored :) > Glad to have cleared this up as I was rather confused by what I saw. Great! Do you mind resending the series then with this patch dropped? It just makes it easier for me to track and manage Alistair > Thanks Tsukasa/Alistair. >
RE: [PATCH v11 12/15] target/hexagon: prepare frontend for parser
> -Original Message-
> From: Anton Johansson
> Sent: Thursday, August 4, 2022 5:56 AM
> To: qemu-devel@nongnu.org
> Cc: a...@rev.ng; a...@rev.ng; bab...@rev.ng; ni...@rev.ng; Taylor Simpson
> ; Brian Cain ; Michael Lambert
> ; richard.hender...@linaro.org;
> alex.ben...@linaro.org
> Subject: [PATCH v11 12/15] target/hexagon: prepare frontend for parser
>
> This patch adds the necessary changes to the Hexagon frontend, required by
> idef-parser to deal with a :mem_noshuf packet with a store in slot 1 and
> predicated load in slot 0.
>
> Signed-off-by: Anton Johansson
> ---
> target/hexagon/cpu.h | 8
> target/hexagon/translate.c | 22 ++
> target/hexagon/translate.h | 2 ++
> 3 files changed, 32 insertions(+)
>
> -git a/target/hexagon/translate.c b/target/hexagon/translate.c index
> e3e250fd4f..72bf8d591b 100644
> 494,6 +498,22 @@ void process_store(DisasContext *ctx, Packet *pkt, int
> slot_num)
>
> static void process_store_log(DisasContext *ctx, Packet *pkt) {
> +/*
> + * Here we deal with the special case of a :mem_noshuf packet with a
> + * predicated load in slot 0 with a store in slot 1. If the predicated
> + * branch wasn't taken during packet execution, then store in slot 1
> + * will not have been executed, corresponding to hex_did_store_s1 being
> 0.
> + * If this is the case, process the store here.
> + */
> +if (ctx->insn_is_noshuf_pload) {
> +TCGLabel *l = gen_new_label();
> +/* Reset s1_store_processed so process_store actually emits a store
> */
> +ctx->s1_store_processed = false;
> +tcg_gen_brcondi_tl(TCG_COND_EQ, hex_did_s1_store, 1, l);
> +process_store(ctx, pkt, 1);
> +gen_set_label(l);
> +}
> +
Let's follow the convention in CHECK_NOSHUF_PRED where we branch around the
probe of the load when the predicate is false and always call process_store.
Then, the mem_noshuf store will always have been processed - so we don't need
the runtime state to tell us.
Thanks,
Taylor
Re: [PULL 0/5] Misc QEMU 7.1 fixes for 2002-08-08
On 8/8/22 07:23, Thomas Huth wrote:
On 08/08/2022 14.57, Paolo Bonzini wrote:
The following changes since commit 3916603e0c1d909e14e09d5ebcbdaa9c9e21adf3:
Merge tag 'pull-la-20220729' of https://gitlab.com/rth7680/qemu into staging
(2022-07-29 17:39:17 -0700)
are available in the Git repository at:
https://gitlab.com/bonzini/qemu.git tags/for-upstream
for you to fetch changes up to f6a5f380627ab2af384bf2f2940d29386dea11ff:
tests/qtest: add scenario for -readconfig handling (2022-08-08 14:54:56
+0200)
* Fix and tests for -readconfig
* Fixes for changeable block size
Daniel P. Berrangé (1):
tests/qtest: add scenario for -readconfig handling
I still had some questions wrt to Daniel's patch, especially there seems to be a bug
("spcie" instead of "spice"), see:
https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg01153.html
I doubt that this test is working if spice is enabled...
(which leads us to the next question: if the CI did not fail for you, are we missing a
build with spice enabled there?)
Arg. I didn't notice this until after I'd done the push to master.
I see from Daniel's reply that the string with the typo doesn't seem to be used, but
please do let's fix this asap.
r~
Re: [PULL 0/5] Misc QEMU 7.1 fixes for 2002-08-08
On 8/8/22 05:57, Paolo Bonzini wrote: The following changes since commit 3916603e0c1d909e14e09d5ebcbdaa9c9e21adf3: Merge tag 'pull-la-20220729' of https://gitlab.com/rth7680/qemu into staging (2022-07-29 17:39:17 -0700) are available in the Git repository at: https://gitlab.com/bonzini/qemu.git tags/for-upstream for you to fetch changes up to f6a5f380627ab2af384bf2f2940d29386dea11ff: tests/qtest: add scenario for -readconfig handling (2022-08-08 14:54:56 +0200) * Fix and tests for -readconfig * Fixes for changeable block size Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/7.1 as appropriate. r~ Daniel P. Berrangé (1): tests/qtest: add scenario for -readconfig handling Mark Cave-Ayland (2): scsi-disk: fix overflow when block size is not a multiple of BDRV_SECTOR_SIZE scsi-disk: ensure block size is non-zero and changes limited to bits 8-15 Paolo Bonzini (2): vl: fix [memory] section with -readconfig vl: remove dead code in parse_memory_options() hw/scsi/scsi-disk.c | 25 -- softmmu/vl.c | 32 --- tests/qtest/meson.build | 1 + tests/qtest/readconfig-test.c | 195 ++ 4 files changed, 229 insertions(+), 24 deletions(-) create mode 100644 tests/qtest/readconfig-test.c
Re: how long do we need to retain gitlab CI job stdout logs?
On 08/08/2022 19.47, Peter Maydell wrote: Hi; I just reduced QEMU's storage usage on gitlab by 130GB (no typo!) using https://gitlab.com/eskultety/gitlab_cleaner, which Dan helpfully pointed me at. This script removes old pipelines, which take up a lot of storage space for QEMU because they include the stdout logs for all the CI jobs in the pipeline. (Gitlab doesn't expire these, either by default or configurably -- you have to either manually delete the pipeline in the UI or else use the API, as this script does.) I somewhat conservatively only blew away pipelines from before the 1st January 2022. I feel like we don't really even need 6 months worth of CI job logs, though -- any views on whether we should be pruning them more aggressively ? I'd say we should at least keep the logs of the last 4 to 5 months, i.e. the logs for one release cycle, so we can check these logs in case we introduced a new bug in the current release cycle. Thomas
Re: [PATCH] error handling: Use TFR() macro where applicable
And summing up the discussion about TEMP_FAILURE_RETRY() usage examples,
I've come up with a new patch for TFR() to TEMP_FAILURE_RETRY()
refactoring. I've decided to stick to expression realisation.
>From 94217dfacf12b3211cfab6e19d750e57d679e851 Mon Sep 17 00:00:00 2001
From: Nikita Ivanov
Date: Mon, 8 Aug 2022 20:43:45 +0300
Subject: [PATCH] Refactoring: rename TFR() to TEMP_FAILURE_RETRY()
glibc's unistd.h header provides the same macro with the
subtle difference in type casting. Adjust macro name to the
common standard and define conditionally.
Signed-off-by: Nikita Ivanov
---
block/file-posix.c| 14 +++---
chardev/char-fd.c | 2 +-
chardev/char-pipe.c | 12 +---
chardev/char-pty.c| 2 +-
hw/9pfs/9p-local.c| 6 --
include/qemu/osdep.h | 11 +--
net/l2tpv3.c | 8 +---
net/socket.c | 4 ++--
net/tap-bsd.c | 6 +++---
net/tap-linux.c | 2 +-
net/tap-solaris.c | 8
net/tap.c | 10 ++
os-posix.c| 2 +-
qga/commands-posix.c | 2 +-
semihosting/syscalls.c| 2 +-
tests/qtest/libqtest.c| 10 +-
tests/vhost-user-bridge.c | 4 +++-
util/main-loop.c | 2 +-
util/osdep.c | 2 +-
util/vfio-helpers.c | 8
20 files changed, 69 insertions(+), 48 deletions(-)
diff --git a/block/file-posix.c b/block/file-posix.c
index 0786cb76f9..28ce649ab9 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1238,8 +1238,8 @@ static int hdev_get_max_segments(int fd, struct stat
*st)
ret = -errno;
goto out;
}
-TFR(
-ret = read(sysfd, buf, sizeof(buf) - 1)
+ret = TEMP_FAILURE_RETRY(
+read(sysfd, buf, sizeof(buf) - 1)
);
if (ret < 0) {
ret = -errno;
@@ -1388,8 +1388,8 @@ static int handle_aiocb_ioctl(void *opaque)
RawPosixAIOData *aiocb = opaque;
int ret;
-TFR(
-ret = ioctl(aiocb->aio_fildes, aiocb->ioctl.cmd, aiocb->ioctl.buf)
+ret = TEMP_FAILURE_RETRY(
+ioctl(aiocb->aio_fildes, aiocb->ioctl.cmd, aiocb->ioctl.buf)
);
if (ret == -1) {
return -errno;
@@ -1472,8 +1472,8 @@ static ssize_t handle_aiocb_rw_vector(RawPosixAIOData
*aiocb)
{
ssize_t len;
-TFR(
-len = (aiocb->aio_type & QEMU_AIO_WRITE) ?
+len = TEMP_FAILURE_RETRY(
+(aiocb->aio_type & QEMU_AIO_WRITE) ?
qemu_pwritev(aiocb->aio_fildes,
aiocb->io.iov,
aiocb->io.niov,
@@ -1907,7 +1907,7 @@ static int allocate_first_block(int fd, size_t
max_size)
buf = qemu_memalign(max_align, write_size);
memset(buf, 0, write_size);
-TFR(n = pwrite(fd, buf, write_size, 0));
+n = TEMP_FAILURE_RETRY(pwrite(fd, buf, write_size, 0));
ret = (n == -1) ? -errno : 0;
diff --git a/chardev/char-fd.c b/chardev/char-fd.c
index cf78454841..1250a63236 100644
--- a/chardev/char-fd.c
+++ b/chardev/char-fd.c
@@ -198,7 +198,7 @@ int qmp_chardev_open_file_source(char *src, int flags,
Error **errp)
{
int fd = -1;
-TFR(fd = qemu_open_old(src, flags, 0666));
+fd = TEMP_FAILURE_RETRY(qemu_open_old(src, flags, 0666));
if (fd == -1) {
error_setg_file_open(errp, errno, src);
}
diff --git a/chardev/char-pipe.c b/chardev/char-pipe.c
index 66d3b85091..a59a055c87 100644
--- a/chardev/char-pipe.c
+++ b/chardev/char-pipe.c
@@ -131,8 +131,12 @@ static void qemu_chr_open_pipe(Chardev *chr,
filename_in = g_strdup_printf("%s.in", filename);
filename_out = g_strdup_printf("%s.out", filename);
-TFR(fd_in = qemu_open_old(filename_in, O_RDWR | O_BINARY));
-TFR(fd_out = qemu_open_old(filename_out, O_RDWR | O_BINARY));
+fd_in = TEMP_FAILURE_RETRY(
+qemu_open_old(filename_in, O_RDWR | O_BINARY)
+);
+fd_out = TEMP_FAILURE_RETRY(
+qemu_open_old(filename_out, O_RDWR | O_BINARY)
+);
g_free(filename_in);
g_free(filename_out);
if (fd_in < 0 || fd_out < 0) {
@@ -142,7 +146,9 @@ static void qemu_chr_open_pipe(Chardev *chr,
if (fd_out >= 0) {
close(fd_out);
}
-TFR(fd_in = fd_out = qemu_open_old(filename, O_RDWR | O_BINARY));
+fd_in = fd_out = TEMP_FAILURE_RETRY(
+qemu_open_old(filename, O_RDWR | O_BINARY)
+);
if (fd_in < 0) {
error_setg_file_open(errp, errno, filename);
return;
diff --git a/chardev/char-pty.c b/chardev/char-pty.c
index b2f490bacf..913a98250b 100644
--- a/chardev/char-pty.c
+++ b/chardev/char-pty.c
@@ -93,7 +93,7 @@ static void pty_chr_update_read_handler(Chardev *chr)
pfd.fd = fioc->fd;
pfd.events = G_IO_OUT;
pfd.revents = 0;
-TFR(rc = g_poll(, 1, 0));
+rc = TEMP_FAILURE_RETRY(g_poll(, 1, 0));
assert(rc >= 0);
if (pfd.revents & G_IO_HUP) {
diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index
Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM
On Mon, 8 Aug 2022 at 18:57, BB wrote: > Am 8. August 2022 14:15:40 MESZ schrieb Igor Mammedov : > >On Wed, 3 Aug 2022 19:26:30 +0200 > >While refactoring we should keep migration stream compatible with older > >QEMU versions (we must not regress widely x86 code path). Which might be > >tricky in this case. > > Does this particular fix make future compatibility harder or easier or is it > that hard already? IIUC it omits the hotplug bits in the vm state for Malta > which is what one would expect there, right? This patch's fix only affects Malta. It is (I suspect but have not tested) a migration compat break on Malta, but we don't care about cross-version migration compat for that board anyway. Migration compat matters (to a first approximation) only for those boards which have versioned machine types (eg pc-7.0, pc-7.1, etc). For all other machine types we retain compat only if it's easy. thanks -- PMM
Re: how long do we need to retain gitlab CI job stdout logs?
On Mon, Aug 8, 2022, 11:49 AM Peter Maydell wrote: > Hi; I just reduced QEMU's storage usage on gitlab by 130GB (no typo!) > using https://gitlab.com/eskultety/gitlab_cleaner, which Dan helpfully > pointed me at. This script removes old pipelines, which take up a > lot of storage space for QEMU because they include the stdout logs > for all the CI jobs in the pipeline. (Gitlab doesn't expire these, > either by default or configurably -- you have to either manually delete > the pipeline in the UI or else use the API, as this script does.) > > I somewhat conservatively only blew away pipelines from before the > 1st January 2022. I feel like we don't really even need 6 months worth > of CI job logs, though -- any views on whether we should be pruning > them more aggressively ? > My finger in the air says "more than a month, less than a year." It can often take a while to notice problems, especially non fatal ones. If we had a one month retention we'd likely find we'd need older logs fairly often. If we expire after a year, we'd never wish we hadn't. Nearly all problems CI would be helpful to address are found in that time. Usually, in other project, almost all issues like this are fixed within a couple months (often much sooner). That suggests that 4-6 months likely is the right balance with my personal bias to 6 months unless there is significant financial or other savings from 4 months. Warner thanks > -- PMM > >
Re: [PATCH] error handling: Use TFR() macro where applicable
Hi!
During our discussion, I found that I've missed a couple of places where
TFR() macro could be applied. Here is an updated first patch:
>From 8a68f50aac4a8549f416b9350cf339cf0501a712 Mon Sep 17 00:00:00 2001
From: Nikita Ivanov
Date: Wed, 3 Aug 2022 12:54:00 +0300
Subject: [PATCH] error handling: Use TFR() macro where applicable
There is a defined TFR() macro in qemu/osdep.h which
handles the same while loop.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/415
Signed-off-by: Nikita Ivanov
---
block/file-posix.c| 39 ++-
chardev/char-pty.c| 4 +---
hw/9pfs/9p-local.c| 8 ++--
net/l2tpv3.c | 15 +++
net/socket.c | 16 +++-
net/tap.c | 8 ++--
qga/commands-posix.c | 4 +---
semihosting/syscalls.c| 4 +---
tests/qtest/libqtest.c| 14 +++---
tests/vhost-user-bridge.c | 4 +---
util/main-loop.c | 4 +---
util/osdep.c | 4 +---
util/vfio-helpers.c | 12 ++--
13 files changed, 51 insertions(+), 85 deletions(-)
diff --git a/block/file-posix.c b/block/file-posix.c
index 48cd096624..0786cb76f9 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1238,9 +1238,9 @@ static int hdev_get_max_segments(int fd, struct stat
*st)
ret = -errno;
goto out;
}
-do {
-ret = read(sysfd, buf, sizeof(buf) - 1);
-} while (ret == -1 && errno == EINTR);
+TFR(
+ret = read(sysfd, buf, sizeof(buf) - 1)
+);
if (ret < 0) {
ret = -errno;
goto out;
@@ -1388,9 +1388,9 @@ static int handle_aiocb_ioctl(void *opaque)
RawPosixAIOData *aiocb = opaque;
int ret;
-do {
-ret = ioctl(aiocb->aio_fildes, aiocb->ioctl.cmd, aiocb->ioctl.buf);
-} while (ret == -1 && errno == EINTR);
+TFR(
+ret = ioctl(aiocb->aio_fildes, aiocb->ioctl.cmd, aiocb->ioctl.buf)
+);
if (ret == -1) {
return -errno;
}
@@ -1472,18 +1472,17 @@ static ssize_t
handle_aiocb_rw_vector(RawPosixAIOData *aiocb)
{
ssize_t len;
-do {
-if (aiocb->aio_type & QEMU_AIO_WRITE)
-len = qemu_pwritev(aiocb->aio_fildes,
- aiocb->io.iov,
- aiocb->io.niov,
- aiocb->aio_offset);
- else
-len = qemu_preadv(aiocb->aio_fildes,
- aiocb->io.iov,
- aiocb->io.niov,
- aiocb->aio_offset);
-} while (len == -1 && errno == EINTR);
+TFR(
+len = (aiocb->aio_type & QEMU_AIO_WRITE) ?
+qemu_pwritev(aiocb->aio_fildes,
+ aiocb->io.iov,
+ aiocb->io.niov,
+ aiocb->aio_offset) :
+qemu_preadv(aiocb->aio_fildes,
+ aiocb->io.iov,
+ aiocb->io.niov,
+ aiocb->aio_offset)
+);
if (len == -1) {
return -errno;
@@ -1908,9 +1907,7 @@ static int allocate_first_block(int fd, size_t
max_size)
buf = qemu_memalign(max_align, write_size);
memset(buf, 0, write_size);
-do {
-n = pwrite(fd, buf, write_size, 0);
-} while (n == -1 && errno == EINTR);
+TFR(n = pwrite(fd, buf, write_size, 0));
ret = (n == -1) ? -errno : 0;
diff --git a/chardev/char-pty.c b/chardev/char-pty.c
index 53f25c6bbd..b2f490bacf 100644
--- a/chardev/char-pty.c
+++ b/chardev/char-pty.c
@@ -93,9 +93,7 @@ static void pty_chr_update_read_handler(Chardev *chr)
pfd.fd = fioc->fd;
pfd.events = G_IO_OUT;
pfd.revents = 0;
-do {
-rc = g_poll(, 1, 0);
-} while (rc == -1 && errno == EINTR);
+TFR(rc = g_poll(, 1, 0));
assert(rc >= 0);
if (pfd.revents & G_IO_HUP) {
diff --git a/hw/9pfs/9p-local.c b/hw/9pfs/9p-local.c
index d42ce6d8b8..c90ab947ba 100644
--- a/hw/9pfs/9p-local.c
+++ b/hw/9pfs/9p-local.c
@@ -470,9 +470,7 @@ static ssize_t local_readlink(FsContext *fs_ctx,
V9fsPath *fs_path,
if (fd == -1) {
return -1;
}
-do {
-tsize = read(fd, (void *)buf, bufsz);
-} while (tsize == -1 && errno == EINTR);
+TFR(tsize = read(fd, (void *)buf, bufsz));
close_preserve_errno(fd);
} else if ((fs_ctx->export_flags & V9FS_SM_PASSTHROUGH) ||
(fs_ctx->export_flags & V9FS_SM_NONE)) {
@@ -908,9 +906,7 @@ static int local_symlink(FsContext *fs_ctx, const char
*oldpath,
}
/* Write the oldpath (target) to the file. */
oldpath_size = strlen(oldpath);
-do {
-write_size = write(fd, (void *)oldpath, oldpath_size);
-} while (write_size == -1 && errno == EINTR);
+TFR(write_size = write(fd, (void *)oldpath, oldpath_size));
close_preserve_errno(fd);
if (write_size !=
Re: [PATCH for-7.1] hw/mips/malta: turn off x86 specific features of PIIX4_PM
Am 8. August 2022 14:15:40 MESZ schrieb Igor Mammedov :
>On Wed, 3 Aug 2022 19:26:30 +0200
>Bernhard Beschow wrote:
>
>> On Tue, Aug 2, 2022 at 8:37 AM Philippe Mathieu-Daudé via <
>> qemu-devel@nongnu.org> wrote:
>>
>> > On 28/7/22 15:16, Igor Mammedov wrote:
>> > > On Thu, 28 Jul 2022 13:29:07 +0100
>> > > Peter Maydell wrote:
>> > >
>> > >> On Thu, 28 Jul 2022 at 12:50, Igor Mammedov
>> > wrote:
>> > >>>
>> > >>> QEMU crashes trying to save VMSTATE when only MIPS target are compiled
>> > >>>
>> > in
>> > >>>$ qemu-system-mips -monitor stdio
>> > >>>(qemu) migrate "exec:gzip -c > STATEFILE.gz"
>> > >>>Segmentation fault (core dumped)
>> > >>>
>> > >>> It happens due to PIIX4_PM trying to parse hotplug vmstate structures
>> > >>> which are valid only for x86 and not for MIPS (as it requires ACPI
>> > >>> tables support which is not existent for ithe later)
>> >
>> > We already discussed this Frankenstein PIIX4 problem 2 and 4 years ago:
>> >
>> > https://lore.kernel.org/qemu-devel/4d42697e-ba84-e5af-3a17-a2cc52cf0...@redhat.com/
>> >
>> > https://lore.kernel.org/qemu-devel/20190304210359-mutt-send-email-...@kernel.org/
>> >
>>
>>
>> Interesting reads!
>>
>>
>> > >>> Issue was probably exposed by trying to cleanup/compile out unused
>> > >>> ACPI bits from MIPS target (but forgetting about migration bits).
>> > >>>
>> > >>> Disable compiled out features using compat properties as the least
>> > >>> risky way to deal with issue.
>> >
>> > So now MIPS is forced to use meaningless compat[] to satisfy X86.
>> >
>> > Am I wrong seeing this as a dirty hack creeping in, yet another
>> > technical debt that will hit (me...) back in a close future?
>> >
>> > Are we sure there are no better solution (probably more time consuming
>> > and involving refactors) we could do instead?
>> >
>>
>> Working on the consolidation of piix3 and -4 soutbridges [1] I've stumbled
>> over certain design decisions where board/platform specific assumptions are
>> baked into the piix device models. I figure that's the core of the issue.
>>
>> In our case the ACPI functionality is implemented by inheritance while
>> perhaps it should be implemented using composition. With composition, the
>> ACPI functionality could be injected by the caller: The pc board would
>> inject it while the Malta board wouldn't. This would solve both the crash
>> and above design problem.
>
>While refactoring we should keep migration stream compatible with older
>QEMU versions (we must not regress widely x86 code path). Which might be
>tricky in this case.
Does this particular fix make future compatibility harder or easier or is it
that hard already? IIUC it omits the hotplug bits in the vm state for Malta
which is what one would expect there, right?
>Perhaps the best we could do is follow up on Philippe's idea to make
>PIIX4_PM frankenstein x86-specific (the least chance for regressions)
>and create/use clean version for anything else.
Having two implementations of the same device means that we'll end up having
duplicate code with board/platform-specific assumptions baked in. I guess what
Phil cares about is a sustainable solution without hacks that doesn't cause
bloat and/or regressions for MIPS, especially for features where MIPS doesn't
benefit from. I believe that composition could be such a solution.
My consolidation work could actually make PIIX4 an option for the PC machine.
This means that PIIX4_PM wouldn't be Frankenstein any more. This works already
on my branch - for both PC and Malta. Furthermore, it looks like it allowed
Malta to benefit more from KVM virtualization, but that's off-topic in this
discussion.
>> I'd be willing to implement it but can't make any promises about the time
>> frame since I'm currently doing this in my free time. Any hints regarding
>> the implementation would be welcome, though.
>>
>> Best regards,
>> Bernhard
>>
>> [1] https://github.com/shentok/qemu/commits/piix-consolidate
>>
>>
>> > Thanks,
>> >
>> > Phil.
>> >
>> > >>> Signed-off-by: Igor Mammedov
>> > >>
>> > >> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/995
>> > >>
>> > >>> ---
>> > >>> PS:
>> > >>> another approach could be setting defaults to disabled state and
>> > >>> enabling them using compat props on PC machines (which is more
>> > >>> code to deal with => more risky) or continue with PIIX4_PM
>> > >>> refactoring to split x86-shism out (which I'm not really
>> > >>> interested in due to risk of regressions for not much of
>> > >>> benefit)
>> > >>> ---
>> > >>> hw/mips/malta.c | 9 +
>> > >>> 1 file changed, 9 insertions(+)
>> > >>>
>> > >>> diff --git a/hw/mips/malta.c b/hw/mips/malta.c
>> > >>> index 7a0ec513b0..0e932988e0 100644
>> > >>> --- a/hw/mips/malta.c
>> > >>> +++ b/hw/mips/malta.c
>> > >>> @@ -1442,6 +1442,14 @@ static const TypeInfo mips_malta_device = {
>> > >>> .instance_init = mips_malta_instance_init,
>> > >>> };
>> > >>>
>> > >>>
Re: [PATCH] tpm_emulator: Avoid double initialization during migration
On 8/1/22 10:27, Ross Lagerwall via wrote:
When resuming after a migration, the backend sends CMD_INIT to the
emulator from the startup callback, then it sends the migration state
This startup hook is called upon TIS/CRB device reset, so this is likely
called before the device state has been received.
from the vmstate to the emulator, then it sends CMD_INIT again. Skip the
first CMD_INIT during a migration to avoid initializing the TPM twice.
Ok, that's sufficient to start it up once all the state has been received.
Signed-off-by: Ross Lagerwall
Tested-by: Stefan Berger
---
backends/tpm/tpm_emulator.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/backends/tpm/tpm_emulator.c b/backends/tpm/tpm_emulator.c
index 87d061e9bb..9b50c5b3e2 100644
--- a/backends/tpm/tpm_emulator.c
+++ b/backends/tpm/tpm_emulator.c
@@ -32,6 +32,7 @@
#include "qemu/sockets.h"
#include "qemu/lockable.h"
#include "io/channel-socket.h"
+#include "sysemu/runstate.h"
#include "sysemu/tpm_backend.h"
#include "sysemu/tpm_util.h"
#include "tpm_int.h"
@@ -383,6 +384,15 @@ err_exit:
static int tpm_emulator_startup_tpm(TPMBackend *tb, size_t buffersize)
{
+/* TPM startup will be done from post_load hook */
+if (runstate_check(RUN_STATE_INMIGRATE)) {
+if (buffersize != 0) {
+return tpm_emulator_set_buffer_size(tb, buffersize, NULL);
+}
+
+return 0;
+}
+
return tpm_emulator_startup_tpm_resume(tb, buffersize, false);
}
how long do we need to retain gitlab CI job stdout logs?
Hi; I just reduced QEMU's storage usage on gitlab by 130GB (no typo!) using https://gitlab.com/eskultety/gitlab_cleaner, which Dan helpfully pointed me at. This script removes old pipelines, which take up a lot of storage space for QEMU because they include the stdout logs for all the CI jobs in the pipeline. (Gitlab doesn't expire these, either by default or configurably -- you have to either manually delete the pipeline in the UI or else use the API, as this script does.) I somewhat conservatively only blew away pipelines from before the 1st January 2022. I feel like we don't really even need 6 months worth of CI job logs, though -- any views on whether we should be pruning them more aggressively ? thanks -- PMM
Re: [PATCH v3 07/22] ppc/ppc405: QOM'ify CPU
On Mon, 8 Aug 2022, Peter Maydell wrote: On Mon, 8 Aug 2022 at 18:05, BALATON Zoltan wrote: But the handler we register here just calls cpu_reset which seems to just call the reset method of the CPU object. If we have nothing else to do here do we need to explicitly call cpi_reset like this? Wouldn't the CPU object be reset by qdev when resetting the machine or the soc its in? If we have our own reset method we may call cpu_reset from there to make sure the CPU is in a known state but is this needed when we don't want to do anything else? I don't know how reset handling works but some machines seems to do this and others don't. You do unfortunately need to manually reset the CPU object. This is because the 'automatic' qdev reset only works for devices that hang off a bus (including sysbus devices). This is because it works by having qdev_machine_creation_done() register a reset function which does "reset the sysbus". Resetting a bus resets every device on it. Resetting a device resets every bus it owns. (This means that for instance PCI devices get reset because the PCI controller is on the sysbus, so it gets reset, and it owns the PCI bus, so the PCI bus resets when the controller is reset, and when the PCI bus resets then all the devices on it are reset.) So reset propagates down the bus tree, but it won't reach devices which aren't on that bus tree at all. The most common case of "device which isn't on a bus" is the CPU objects. This is, clearly, a complete mess. I would strongly like to sort it out, but to do that we need (a) a plan for what reset handling ought to look like and (b) a transition plan for getting from here to there without breaking everything in the process. I haven't had the time to focus on that, though it's been nominally on my todo list for years. In the meantime, it's the responsibility of something in architecture specific code to arrange for the CPU objects to be reset -- whether that's done directly by the board, or hidden in some other layer of code, depends on the target arch. For instance for arm it's hidden inside arm_load_kernel() and board models must therefore call that function even if they have no intention of supporting loading Linux kernels. For sparc it's done directly in the board code. OK thanks for the clarification. Both bamboo and sam460ex has a main_cpu_reset function that is registered from the machine init func which calls cpu_reset. Maybe 405 boards could do the same for consistency? It could also be added to the soc object's reset method as that owns the cpu so maybe it may make more sense that way. This is probably also OK as 440 machines don't have soc object yet so it wouldn't cause any problems. I think the ppc4xx_reset func was kept around because ppc4xx_init was also kept but nothing else seems to use it so maybe these should become the soc object's realize and reset methods and drop the current ppc4xx_init and reset funcs? Regards, BALATON Zoltan
Re: [PATCH v8 3/3] target/riscv: Add vstimecmp support
On Sun, Aug 7, 2022 at 6:50 PM Weiwei Li wrote:
>
> 在 2022/8/4 上午9:42, Atish Patra 写道:
> > vstimecmp CSR allows the guest OS or to program the next guest timer
> > interrupt directly. Thus, hypervisor no longer need to inject the
> > timer interrupt to the guest if vstimecmp is used. This was ratified
> > as a part of the Sstc extension.
> >
> > Signed-off-by: Atish Patra
> > ---
> > target/riscv/cpu.h | 4 ++
> > target/riscv/cpu_bits.h| 4 ++
> > target/riscv/cpu_helper.c | 11 ++--
> > target/riscv/csr.c | 102 -
> > target/riscv/machine.c | 1 +
> > target/riscv/time_helper.c | 16 ++
> > 6 files changed, 133 insertions(+), 5 deletions(-)
> >
> > diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> > index 4cda2905661e..1fd382b2717f 100644
> > --- a/target/riscv/cpu.h
> > +++ b/target/riscv/cpu.h
> > @@ -312,6 +312,8 @@ struct CPUArchState {
> > /* Sstc CSRs */
> > uint64_t stimecmp;
> >
> > +uint64_t vstimecmp;
> > +
> > /* physical memory protection */
> > pmp_table_t pmp_state;
> > target_ulong mseccfg;
> > @@ -366,6 +368,8 @@ struct CPUArchState {
> >
> > /* Fields from here on are preserved across CPU reset. */
> > QEMUTimer *stimer; /* Internal timer for S-mode interrupt */
> > +QEMUTimer *vstimer; /* Internal timer for VS-mode interrupt */
> > +bool vstime_irq;
> >
> > hwaddr kernel_addr;
> > hwaddr fdt_addr;
> > diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
> > index ac17cf1515c0..095dab19f512 100644
> > --- a/target/riscv/cpu_bits.h
> > +++ b/target/riscv/cpu_bits.h
> > @@ -257,6 +257,10 @@
> > #define CSR_VSIP0x244
> > #define CSR_VSATP 0x280
> >
> > +/* Sstc virtual CSRs */
> > +#define CSR_VSTIMECMP 0x24D
> > +#define CSR_VSTIMECMPH 0x25D
> > +
> > #define CSR_MTINST 0x34a
> > #define CSR_MTVAL2 0x34b
> >
> > diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> > index 650574accf0a..1e4faa84e839 100644
> > --- a/target/riscv/cpu_helper.c
> > +++ b/target/riscv/cpu_helper.c
> > @@ -345,8 +345,9 @@ uint64_t riscv_cpu_all_pending(CPURISCVState *env)
> > {
> > uint32_t gein = get_field(env->hstatus, HSTATUS_VGEIN);
> > uint64_t vsgein = (env->hgeip & (1ULL << gein)) ? MIP_VSEIP : 0;
> > +uint64_t vstip = (env->vstime_irq) ? MIP_VSTIP : 0;
> >
> > -return (env->mip | vsgein) & env->mie;
> > +return (env->mip | vsgein | vstip) & env->mie;
> > }
> >
> > int riscv_cpu_mirq_pending(CPURISCVState *env)
> > @@ -605,7 +606,7 @@ uint64_t riscv_cpu_update_mip(RISCVCPU *cpu,
> uint64_t mask, uint64_t value)
> > {
> > CPURISCVState *env = >env;
> > CPUState *cs = CPU(cpu);
> > -uint64_t gein, vsgein = 0, old = env->mip;
> > +uint64_t gein, vsgein = 0, vstip = 0, old = env->mip;
> > bool locked = false;
> >
> > if (riscv_cpu_virt_enabled(env)) {
> > @@ -613,6 +614,10 @@ uint64_t riscv_cpu_update_mip(RISCVCPU *cpu,
> uint64_t mask, uint64_t value)
> > vsgein = (env->hgeip & (1ULL << gein)) ? MIP_VSEIP : 0;
> > }
> >
> > +/* No need to update mip for VSTIP */
> > +mask = ((mask == MIP_VSTIP) && env->vstime_irq) ? 0 : mask;
> > +vstip = env->vstime_irq ? MIP_VSTIP : 0;
> > +
> > if (!qemu_mutex_iothread_locked()) {
> > locked = true;
> > qemu_mutex_lock_iothread();
> > @@ -620,7 +625,7 @@ uint64_t riscv_cpu_update_mip(RISCVCPU *cpu,
> uint64_t mask, uint64_t value)
> >
> > env->mip = (env->mip & ~mask) | (value & mask);
> >
> > -if (env->mip | vsgein) {
> > +if (env->mip | vsgein | vstip) {
> > cpu_interrupt(cs, CPU_INTERRUPT_HARD);
> > } else {
> > cpu_reset_interrupt(cs, CPU_INTERRUPT_HARD);
> > diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> > index e18b000700e4..9da4d6515e7b 100644
> > --- a/target/riscv/csr.c
> > +++ b/target/riscv/csr.c
> > @@ -829,17 +829,100 @@ static RISCVException sstc(CPURISCVState *env,
> int csrno)
> > return smode(env, csrno);
> > }
> >
> > +static RISCVException sstc_hmode(CPURISCVState *env, int csrno)
> > +{
> > +CPUState *cs = env_cpu(env);
> > +RISCVCPU *cpu = RISCV_CPU(cs);
> > +
> > +if (!cpu->cfg.ext_sstc || !env->rdtime_fn) {
> > +return RISCV_EXCP_ILLEGAL_INST;
> > +}
> > +
> > +if (env->priv == PRV_M) {
> > +return RISCV_EXCP_NONE;
> > +}
> > +
> > +if (!(get_field(env->mcounteren, COUNTEREN_TM) &
> > + get_field(env->menvcfg, MENVCFG_STCE))) {
> > +return RISCV_EXCP_ILLEGAL_INST;
> > +}
> > +
> > +if (riscv_cpu_virt_enabled(env)) {
> > +if (!(get_field(env->hcounteren, COUNTEREN_TM) &
> > + get_field(env->henvcfg, HENVCFG_STCE))) {
> > +return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
> > +}
> > +}
> > +
>
> I think this check on hcounteren and henvcfg
Re: [PATCH v3 07/22] ppc/ppc405: QOM'ify CPU
On Mon, 8 Aug 2022 at 18:05, BALATON Zoltan wrote: > But the handler we register here just calls cpu_reset which seems to just > call the reset method of the CPU object. If we have nothing else to do > here do we need to explicitly call cpi_reset like this? Wouldn't the CPU > object be reset by qdev when resetting the machine or the soc its in? If > we have our own reset method we may call cpu_reset from there to make sure > the CPU is in a known state but is this needed when we don't want to do > anything else? I don't know how reset handling works but some machines > seems to do this and others don't. You do unfortunately need to manually reset the CPU object. This is because the 'automatic' qdev reset only works for devices that hang off a bus (including sysbus devices). This is because it works by having qdev_machine_creation_done() register a reset function which does "reset the sysbus". Resetting a bus resets every device on it. Resetting a device resets every bus it owns. (This means that for instance PCI devices get reset because the PCI controller is on the sysbus, so it gets reset, and it owns the PCI bus, so the PCI bus resets when the controller is reset, and when the PCI bus resets then all the devices on it are reset.) So reset propagates down the bus tree, but it won't reach devices which aren't on that bus tree at all. The most common case of "device which isn't on a bus" is the CPU objects. This is, clearly, a complete mess. I would strongly like to sort it out, but to do that we need (a) a plan for what reset handling ought to look like and (b) a transition plan for getting from here to there without breaking everything in the process. I haven't had the time to focus on that, though it's been nominally on my todo list for years. In the meantime, it's the responsibility of something in architecture specific code to arrange for the CPU objects to be reset -- whether that's done directly by the board, or hidden in some other layer of code, depends on the target arch. For instance for arm it's hidden inside arm_load_kernel() and board models must therefore call that function even if they have no intention of supporting loading Linux kernels. For sparc it's done directly in the board code. thanks -- PMM
[PATCH v3 3/4] target/i386: Make translator stop before the end of a page
Right now translator stops right *after* the end of a page, which
breaks reporting of fault locations when the last instruction of a
multi-insn translation block crosses a page boundary.
An implementation, like the one arm and s390x have, would require an
i386 length disassembler, which is burdensome to maintain. Another
alternative would be to single-step at the end of a guest page, but
this may come with a performance impact.
Fix by snapshotting disassembly state and restoring it after we figure
out we crossed a page boundary. This includes rolling back cc_op
updates and emitted ops. Even though i386 is the only architecture that
does rollback, split it into common and architecture-dependent parts to
improve readability.
Signed-off-by: Ilya Leoshkevich
---
accel/tcg/translator.c | 8
include/exec/translator.h | 3 +++
target/i386/tcg/translate.c | 21 -
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/accel/tcg/translator.c b/accel/tcg/translator.c
index fe7af9b943..2c4dd09df8 100644
--- a/accel/tcg/translator.c
+++ b/accel/tcg/translator.c
@@ -56,6 +56,7 @@ void translator_loop(const TranslatorOps *ops,
DisasContextBase *db,
{
uint32_t cflags = tb_cflags(tb);
bool plugin_enabled;
+TCGOp *last_op;
/* Initialize DisasContext */
db->tb = tb;
@@ -82,6 +83,7 @@ void translator_loop(const TranslatorOps *ops,
DisasContextBase *db,
while (true) {
db->num_insns++;
+last_op = tcg_last_op();
ops->insn_start(db, cpu);
tcg_debug_assert(db->is_jmp == DISAS_NEXT); /* no early exit */
@@ -103,6 +105,12 @@ void translator_loop(const TranslatorOps *ops,
DisasContextBase *db,
ops->translate_insn(db, cpu);
}
+if (db->is_jmp == DISAS_TOO_MANY_UNDO) {
+db->num_insns--;
+tcg_remove_ops_after(last_op);
+db->is_jmp = DISAS_TOO_MANY;
+}
+
/* Stop translation if translate_insn so indicated. */
if (db->is_jmp != DISAS_NEXT) {
break;
diff --git a/include/exec/translator.h b/include/exec/translator.h
index d27f8c33b6..e1533aee87 100644
--- a/include/exec/translator.h
+++ b/include/exec/translator.h
@@ -31,6 +31,8 @@
* DisasJumpType:
* @DISAS_NEXT: Next instruction in program order.
* @DISAS_TOO_MANY: Too many instructions translated.
+ * @DISAS_TOO_MANY_UNDO: Too many instructions translated. Everything that was
+ * done for the current instruction must be undone.
* @DISAS_NORETURN: Following code is dead.
* @DISAS_TARGET_*: Start of target-specific conditions.
*
@@ -39,6 +41,7 @@
typedef enum DisasJumpType {
DISAS_NEXT,
DISAS_TOO_MANY,
+DISAS_TOO_MANY_UNDO,
DISAS_NORETURN,
DISAS_TARGET_0,
DISAS_TARGET_1,
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index b7972f0ff5..14d4ed1412 100644
--- a/target/i386/tcg/translate.c
+++ b/target/i386/tcg/translate.c
@@ -2008,6 +2008,12 @@ static uint64_t advance_pc(CPUX86State *env,
DisasContext *s, int num_bytes)
{
uint64_t pc = s->pc;
+/* This is a subsequent insn that crosses a page boundary. */
+if (s->base.num_insns > 1 &&
+!is_same_page(>base, s->pc + num_bytes - 1)) {
+siglongjmp(s->jmpbuf, 2);
+}
+
s->pc += num_bytes;
if (unlikely(s->pc - s->pc_start > X86_MAX_INSN_LENGTH)) {
/* If the instruction's 16th byte is on a different page than the 1st,
a
@@ -4556,6 +4562,8 @@ static target_ulong disas_insn(DisasContext *s, CPUState
*cpu)
int modrm, reg, rm, mod, op, opreg, val;
target_ulong next_eip, tval;
target_ulong pc_start = s->base.pc_next;
+bool orig_cc_op_dirty = s->cc_op_dirty;
+CCOp orig_cc_op = s->cc_op;
s->pc_start = s->pc = pc_start;
s->override = -1;
@@ -4568,9 +4576,20 @@ static target_ulong disas_insn(DisasContext *s, CPUState
*cpu)
s->rip_offset = 0; /* for relative ip address */
s->vex_l = 0;
s->vex_v = 0;
-if (sigsetjmp(s->jmpbuf, 0) != 0) {
+switch (sigsetjmp(s->jmpbuf, 0)) {
+case 0:
+break;
+case 1:
gen_exception_gpf(s);
return s->pc;
+case 2:
+/* Restore state that may affect the next instruction. */
+s->cc_op_dirty = orig_cc_op_dirty;
+s->cc_op = orig_cc_op;
+s->base.is_jmp = DISAS_TOO_MANY_UNDO;
+return pc_start;
+default:
+g_assert_not_reached();
}
prefixes = 0;
--
2.37.1
[PATCH v3 2/4] target/s390x: Make translator stop before the end of a page
Right now translator stops right *after* the end of a page, which
breaks reporting of fault locations when the last instruction of a
multi-insn translation block crosses a page boundary.
Signed-off-by: Ilya Leoshkevich
---
include/exec/translator.h| 10 ++
target/s390x/tcg/translate.c | 15 +++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/include/exec/translator.h b/include/exec/translator.h
index 7db6845535..d27f8c33b6 100644
--- a/include/exec/translator.h
+++ b/include/exec/translator.h
@@ -187,4 +187,14 @@ FOR_EACH_TRANSLATOR_LD(GEN_TRANSLATOR_LD)
#undef GEN_TRANSLATOR_LD
+/*
+ * Return whether addr is on the same page as where disassembly started.
+ * Translators can use this to enforce the rule that only single-insn
+ * translation blocks are allowed to cross page boundaries.
+ */
+static inline bool is_same_page(DisasContextBase *db, target_ulong addr)
+{
+return ((addr ^ db->pc_first) & TARGET_PAGE_MASK) == 0;
+}
+
#endif /* EXEC__TRANSLATOR_H */
diff --git a/target/s390x/tcg/translate.c b/target/s390x/tcg/translate.c
index e2ee005671..8e45a0e0d3 100644
--- a/target/s390x/tcg/translate.c
+++ b/target/s390x/tcg/translate.c
@@ -6609,6 +6609,14 @@ static void s390x_tr_insn_start(DisasContextBase
*dcbase, CPUState *cs)
dc->insn_start = tcg_last_op();
}
+static target_ulong get_next_pc(CPUS390XState *env, DisasContext *s,
+uint64_t pc)
+{
+uint64_t insn = ld_code2(env, s, pc);
+
+return pc + get_ilen((insn >> 8) & 0xff);
+}
+
static void s390x_tr_translate_insn(DisasContextBase *dcbase, CPUState *cs)
{
CPUS390XState *env = cs->env_ptr;
@@ -6616,10 +6624,9 @@ static void s390x_tr_translate_insn(DisasContextBase
*dcbase, CPUState *cs)
dc->base.is_jmp = translate_one(env, dc);
if (dc->base.is_jmp == DISAS_NEXT) {
-uint64_t page_start;
-
-page_start = dc->base.pc_first & TARGET_PAGE_MASK;
-if (dc->base.pc_next - page_start >= TARGET_PAGE_SIZE || dc->ex_value)
{
+if (!is_same_page(dcbase, dc->base.pc_next) ||
+!is_same_page(dcbase, get_next_pc(env, dc, dc->base.pc_next)) ||
+dc->ex_value) {
dc->base.is_jmp = DISAS_TOO_MANY;
}
}
--
2.37.1
[PATCH v3 4/4] tests/tcg: Test siginfo_t contents when jumping to non-readable pages
Add x86_64 and s390x tests to prevent regressions.
Signed-off-by: Ilya Leoshkevich
---
tests/tcg/multiarch/noexec.h | 114
tests/tcg/s390x/Makefile.target | 1 +
tests/tcg/s390x/noexec.c | 145 +++
tests/tcg/x86_64/Makefile.target | 3 +-
tests/tcg/x86_64/noexec.c| 116 +
5 files changed, 378 insertions(+), 1 deletion(-)
create mode 100644 tests/tcg/multiarch/noexec.h
create mode 100644 tests/tcg/s390x/noexec.c
create mode 100644 tests/tcg/x86_64/noexec.c
diff --git a/tests/tcg/multiarch/noexec.h b/tests/tcg/multiarch/noexec.h
new file mode 100644
index 00..a76e0aa9ea
--- /dev/null
+++ b/tests/tcg/multiarch/noexec.h
@@ -0,0 +1,114 @@
+/*
+ * Common code for arch-specific MMU_INST_FETCH fault testing.
+ *
+ * Declare struct arch_noexec_test before including this file and define
+ * arch_check_mcontext() after that.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Forward declarations. */
+
+static void arch_check_mcontext(const struct arch_noexec_test *test,
+const mcontext_t *ctx);
+
+/* Utility functions. */
+
+static void safe_print(const char *s)
+{
+write(0, s, strlen(s));
+}
+
+static void safe_puts(const char *s)
+{
+safe_print(s);
+safe_print("\n");
+}
+
+#define PAGE_ALIGN(p) (void *)((unsigned long)(p) & ~0xfffUL)
+
+/* Testing infrastructure. */
+
+struct noexec_test {
+const char *name;
+void (*func)(int);
+void *page;
+void *expected_si_addr;
+struct arch_noexec_test arch;
+};
+
+static const struct noexec_test *current_noexec_test;
+
+static void handle_segv(int sig, siginfo_t *info, void *ucontext)
+{
+int err;
+
+if (current_noexec_test == NULL) {
+safe_puts("[ FAILED ] unexpected SEGV");
+_exit(1);
+}
+
+if (info->si_addr != current_noexec_test->expected_si_addr) {
+safe_puts("[ FAILED ] wrong si_addr");
+_exit(1);
+}
+
+arch_check_mcontext(_noexec_test->arch,
+&((ucontext_t *)ucontext)->uc_mcontext);
+
+err = mprotect(current_noexec_test->page, 0x1000, PROT_READ | PROT_EXEC);
+if (err != 0) {
+safe_puts("[ FAILED ] mprotect() failed");
+_exit(1);
+}
+
+current_noexec_test = NULL;
+}
+
+static void test_noexec_1(const struct noexec_test *test)
+{
+int ret;
+
+/* Trigger TB creation in order to test invalidation. */
+test->func(0);
+
+ret = mprotect(test->page, 0x1000, PROT_NONE);
+assert(ret == 0);
+
+/* Trigger SEGV and check that handle_segv() ran. */
+current_noexec_test = test;
+test->func(0);
+assert(current_noexec_test == NULL);
+}
+
+static int test_noexec(struct noexec_test *tests, size_t n_tests)
+{
+struct sigaction act;
+size_t i;
+int err;
+
+memset(, 0, sizeof(act));
+act.sa_sigaction = handle_segv;
+act.sa_flags = SA_SIGINFO;
+err = sigaction(SIGSEGV, , NULL);
+assert(err == 0);
+
+for (i = 0; i < n_tests; i++) {
+struct noexec_test *test = [i];
+
+safe_print("[ RUN ] ");
+safe_puts(test->name);
+test_noexec_1(test);
+safe_puts("[ OK ]");
+}
+
+safe_puts("[ PASSED ]");
+
+return EXIT_SUCCESS;
+}
diff --git a/tests/tcg/s390x/Makefile.target b/tests/tcg/s390x/Makefile.target
index 1a7a4a2f59..5e13a41c3f 100644
--- a/tests/tcg/s390x/Makefile.target
+++ b/tests/tcg/s390x/Makefile.target
@@ -16,6 +16,7 @@ TESTS+=shift
TESTS+=trap
TESTS+=signals-s390x
TESTS+=branch-relative-long
+TESTS+=noexec
Z14_TESTS=vfminmax
vfminmax: LDFLAGS+=-lm
diff --git a/tests/tcg/s390x/noexec.c b/tests/tcg/s390x/noexec.c
new file mode 100644
index 00..2dfc9ee817
--- /dev/null
+++ b/tests/tcg/s390x/noexec.c
@@ -0,0 +1,145 @@
+#define _GNU_SOURCE
+
+struct arch_noexec_test {
+void *expected_pswa;
+unsigned long expected_r2;
+};
+
+#include "../multiarch/noexec.h"
+
+static void arch_check_mcontext(const struct arch_noexec_test *test,
+const mcontext_t *ctx) {
+if (ctx->psw.addr != (unsigned long)test->expected_pswa) {
+safe_puts("[ FAILED ] wrong psw.addr");
+_exit(1);
+}
+
+if (ctx->gregs[2] != test->expected_r2) {
+safe_puts("[ FAILED ] wrong r2");
+_exit(1);
+}
+}
+
+#define DEFINE_NX(name, offset) \
+void name ## _1(int); \
+void name ## _2(int); \
+void name ## _exrl(int); \
+extern const short name ## _end[]; \
+asm(/* Go to the specified page offset. */ \
+".align 0x1000\n" \
+".org .+" #offset "\n" \
+/* %r2 is 0 on entry, overwrite it with 1. */ \
+".globl " #name "_1\n" \
+#name "_1:\n" \
+".cfi_startproc\n" \
+"lgfi %r2,1\n" \
+/* Overwrite %2 with 2. */ \
+".globl " #name "_2\n" \
+#name "_2:\n" \
+"lgfi %r2,2\n" \
[PATCH v3 0/4] linux-user: Fix siginfo_t contents when jumping to non-readable pages
Hi, I noticed that when we get a SEGV due to jumping to non-readable memory, sometimes si_addr and program counter in siginfo_t are slightly off. I tracked this down to the assumption that translators stop before the end of a page, while in reality they may stop right after it. Patch 1 fixes a minor invalidation issue, which may prevent SEGV from happening altogether. Patches 2-3 fix the main issue on x86_64 and s390x. Many other architectures have fixed-size instructions and are not affected. Patch 4 adds tests. Best regards, Ilya v1: https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg00822.html v1 -> v2: Fix individual translators instead of translator_loop (Peter). v2: https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg01079.html v2 -> v3: Peek at the next instruction on s390x (Richard). Undo more on i386 (Richard). Check PAGE_EXEC, not PAGE_READ (Peter, Richard). Ilya Leoshkevich (4): accel/tcg: Invalidate translations when clearing PAGE_EXEC target/s390x: Make translator stop before the end of a page target/i386: Make translator stop before the end of a page tests/tcg: Test siginfo_t contents when jumping to non-readable pages accel/tcg/translate-all.c| 17 ++-- accel/tcg/translator.c | 8 ++ include/exec/translator.h| 13 +++ target/i386/tcg/translate.c | 21 - target/s390x/tcg/translate.c | 15 +++- tests/tcg/multiarch/noexec.h | 114 tests/tcg/s390x/Makefile.target | 1 + tests/tcg/s390x/noexec.c | 145 +++ tests/tcg/x86_64/Makefile.target | 3 +- tests/tcg/x86_64/noexec.c| 116 + 10 files changed, 442 insertions(+), 11 deletions(-) create mode 100644 tests/tcg/multiarch/noexec.h create mode 100644 tests/tcg/s390x/noexec.c create mode 100644 tests/tcg/x86_64/noexec.c -- 2.37.1
[PATCH v3 1/4] accel/tcg: Invalidate translations when clearing PAGE_EXEC
After mprotect(addr, PROT_NONE), addr can still be executed if there
are cached translations. Drop them.
Signed-off-by: Ilya Leoshkevich
---
accel/tcg/translate-all.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index ef62a199c7..32ea5f0adf 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -2295,12 +2295,19 @@ void page_set_flags(target_ulong start, target_ulong
end, int flags)
len != 0;
len -= TARGET_PAGE_SIZE, addr += TARGET_PAGE_SIZE) {
PageDesc *p = page_find_alloc(addr >> TARGET_PAGE_BITS, 1);
+bool write_set, exec_cleared;
-/* If the write protection bit is set, then we invalidate
- the code inside. */
-if (!(p->flags & PAGE_WRITE) &&
-(flags & PAGE_WRITE) &&
-p->first_tb) {
+/*
+ * If the write protection bit is set, then we invalidate the code
+ * inside.
+ */
+write_set = !(p->flags & PAGE_WRITE) && (flags & PAGE_WRITE);
+/*
+ * If PAGE_EXEC is cleared, we also need to invalidate the code in
+ * order to force a fault when trying to run it.
+ */
+exec_cleared = (p->flags & PAGE_EXEC) && !(flags & PAGE_EXEC);
+if ((write_set || exec_cleared) && p->first_tb) {
tb_invalidate_phys_page(addr, 0);
}
if (reset_target_data) {
--
2.37.1
Re: [PATCH 1/1] tests/qtest: add scenario for -readconfig handling
On Mon, Aug 08, 2022 at 07:55:50AM +0200, Thomas Huth wrote:
> On 05/08/2022 13.55, Daniel P. Berrangé wrote:
> > This test of -readconfig validates the last three regressions we
> > have fixed with -readconfig:
> >
> > * Interpretation of memory size units as MiB not bytes
> > * Allow use of [spice]
> > * Allow use of [object]
>
> Good idea!
>
> > Signed-off-by: Daniel P. Berrangé
> > ---
> > tests/qtest/meson.build | 1 +
> > tests/qtest/readconfig-test.c | 195 ++
> > 2 files changed, 196 insertions(+)
> > create mode 100644 tests/qtest/readconfig-test.c
> >
> > diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
> > index 3a474010e4..be4b30dea2 100644
> > --- a/tests/qtest/meson.build
> > +++ b/tests/qtest/meson.build
> > @@ -26,6 +26,7 @@ qtests_generic = [
> > 'qom-test',
> > 'test-hmp',
> > 'qos-test',
> > + 'readconfig-test',
> > ]
> > if config_host.has_key('CONFIG_MODULES')
> > qtests_generic += [ 'modules-test' ]
> > diff --git a/tests/qtest/readconfig-test.c b/tests/qtest/readconfig-test.c
> > new file mode 100644
> > index 00..2e604d7c2d
> > --- /dev/null
> > +++ b/tests/qtest/readconfig-test.c
> > @@ -0,0 +1,195 @@
> > +/*
> > + * Validate -readconfig
> > + *
> > + * Copyright (c) 2022 Red Hat, Inc.
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or
> > later.
> > + * See the COPYING file in the top-level directory.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "libqtest.h"
> > +#include "qapi/error.h"
> > +#include "qapi/qapi-visit-machine.h"
> > +#include "qapi/qapi-visit-qom.h"
> > +#include "qapi/qapi-visit-ui.h"
> > +#include "qapi/qmp/qdict.h"
> > +#include "qapi/qmp/qlist.h"
> > +#include "qapi/qobject-input-visitor.h"
> > +#include "qapi/qmp/qstring.h"
> > +#include "qemu/units.h"
> > +
> > +static QTestState *qtest_init_with_config(const char *cfgdata)
> > +{
> > +GError *error = NULL;
> > +g_autofree char *args = NULL;
> > +int cfgfd = -1;
> > +g_autofree char *cfgpath = NULL;
> > +QTestState *qts;
> > +ssize_t ret;
> > +
> > +cfgfd = g_file_open_tmp("readconfig-test-XX", , );
> > +g_assert_no_error(error);
> > +g_assert_cmpint(cfgfd, >=, 0);
> > +
> > +ret = qemu_write_full(cfgfd, cfgdata, strlen(cfgdata));
> > +if (ret < 0) {
> > +unlink(cfgpath);
> > +}
> > +g_assert_cmpint(ret, ==, strlen(cfgdata));
> > +
> > +close(cfgfd);
>
> Maybe move the close() before the "if (ret < 0)"
>
> > +args = g_strdup_printf("-nodefaults -machine none -readconfig %s",
> > cfgpath);
> > +
> > +qts = qtest_init(args);
> > +
> > +unlink(cfgpath);
> > +
> > +return qts;
> > +}
> > +
> > +static void test_x86_memdev_resp(QObject *res)
> > +{
> > +Visitor *v;
> > +g_autoptr(MemdevList) memdevs = NULL;
> > +Memdev *memdev;
> > +
> > +g_assert(res);
> > +v = qobject_input_visitor_new(res);
> > +visit_type_MemdevList(v, NULL, , _abort);
> > +
> > +g_assert(memdevs);
> > +g_assert(memdevs->value);
> > +g_assert(!memdevs->next);
> > +
> > +memdev = memdevs->value;
> > +g_assert_cmpstr(memdev->id, ==, "ram");
> > +g_assert_cmpint(memdev->size, ==, 200 * MiB);
> > +
> > +visit_free(v);
> > +}
> > +
> > +static void test_x86_memdev(void)
> > +{
> > +QDict *resp;
> > +QTestState *qts;
> > +const char *cfgdata =
> > +"[memory]\n"
> > +"size = \"200\"";
> > +
> > +qts = qtest_init_with_config(cfgdata);
> > + /* Test valid command */
>
> Comment has bad indentation.
>
> > +resp = qtest_qmp(qts, "{ 'execute': 'query-memdev' }");
> > +test_x86_memdev_resp(qdict_get(resp, "return"));
> > +qobject_unref(resp);
> > +
> > +qtest_quit(qts);
> > +}
> > +
> > +
> > +#ifdef CONFIG_SPICE
> > +static void test_spice_resp(QObject *res)
> > +{
> > +Visitor *v;
> > +g_autoptr(SpiceInfo) spice = NULL;
> > +
> > +g_assert(res);
> > +v = qobject_input_visitor_new(res);
> > +visit_type_SpiceInfo(v, "spcie", , _abort);
>
> That "spcie" looks like a typo?
Yes, but I believe this argument is ignored by the visitor in this
scenario - it didn't fail for me at least.
Regardless, sHould be fixed of course
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 :|
Re: [PATCH v3 07/22] ppc/ppc405: QOM'ify CPU
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
On 8/8/22 15:17, BALATON Zoltan wrote:
Patch title is wrong. It should be Embed CPU object in SoC as it's not
QOMifies the CPU just moves it from dinamically allocated to embedded.
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
Drop the use of ppc4xx_init() and duplicate a bit of code related to
clocks in the SoC realize routine. We will clean that up in the
following patches.
Could this be split off into a separate patch? Maybe it would be clearer
that way what's related to stop using ppc4xx_init() (which is needed
because it dinamically allocates CPU) and what's the embedding it in the
soc object.
I'd rather not. It has been painful enough to untangle. Let's keep it that
way. And, this part is further changed in the CPC patch.
OK, if nobody else thinks this should be split I'm OK with it.
ppc_dcr_init() simply allocates default DCR handlers for the CPU. Maybe
this could be done in model initializer of the CPU families needing it.
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h | 2 +-
include/hw/ppc/ppc4xx.h | 1 +
hw/ppc/ppc405_boards.c | 2 +-
hw/ppc/ppc405_uc.c | 35 +--
hw/ppc/ppc4xx_devs.c | 2 +-
5 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index dc862bc8614c..8cc76cc8b3fe 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -79,7 +79,7 @@ struct Ppc405SoCState {
hwaddr ram_size;
uint32_t sysclk;
- PowerPCCPU *cpu;
+ PowerPCCPU cpu;
DeviceState *uic;
};
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 980f964b5a91..021376c2d260 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -29,6 +29,7 @@
#include "exec/memory.h"
/* PowerPC 4xx core initialization */
+void ppc4xx_reset(void *opaque);
PowerPCCPU *ppc4xx_init(const char *cpu_model,
clk_setup_t *cpu_clk, clk_setup_t *tb_clk,
uint32_t sysclk);
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 0b39ff08bd65..5ba12d60bc00 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -313,7 +313,7 @@ static void ppc405_init(MachineState *machine)
/* Load ELF kernel and rootfs.cpio */
} else if (kernel_filename && !machine->firmware) {
- boot_from_kernel(machine, ppc405->soc.cpu);
+ boot_from_kernel(machine, >soc.cpu);
}
}
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index abcc2537140c..fa3853df2233 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1432,22 +1432,36 @@ static void ppc405ep_cpc_init (CPUPPCState *env,
clk_setup_t clk_setup[8],
#endif
}
+static void ppc405_soc_instance_init(Object *obj)
+{
+ Ppc405SoCState *s = PPC405_SOC(obj);
+
+ object_initialize_child(obj, "cpu", >cpu,
+ POWERPC_CPU_TYPE_NAME("405ep"));
+}
+
static void ppc405_soc_realize(DeviceState *dev, Error **errp)
{
Ppc405SoCState *s = PPC405_SOC(dev);
- clk_setup_t clk_setup[PPC405EP_CLK_NB], tlb_clk_setup;
+ clk_setup_t clk_setup[PPC405EP_CLK_NB];
qemu_irq dma_irqs[4], gpt_irqs[5], mal_irqs[4];
CPUPPCState *env;
memset(clk_setup, 0, sizeof(clk_setup));
/* init CPUs */
- s->cpu = ppc4xx_init(POWERPC_CPU_TYPE_NAME("405ep"),
- _setup[PPC405EP_CPU_CLK],
- _clk_setup, s->sysclk);
- env = >cpu->env;
- clk_setup[PPC405EP_CPU_CLK].cb = tlb_clk_setup.cb;
- clk_setup[PPC405EP_CPU_CLK].opaque = tlb_clk_setup.opaque;
+ if (!qdev_realize(DEVICE(>cpu), NULL, errp)) {
+ return;
+ }
+ qemu_register_reset(ppc4xx_reset, >cpu);
+
+ env = >cpu.env;
+
+ clk_setup[PPC405EP_CPU_CLK].cb =
+ ppc_40x_timers_init(env, s->sysclk, PPC_INTERRUPT_PIT);
+ clk_setup[PPC405EP_CPU_CLK].opaque = env;
+
+ ppc_dcr_init(env, NULL, NULL);
/* CPU control */
ppc405ep_cpc_init(env, clk_setup, s->sysclk);
@@ -1464,16 +1478,16 @@ static void ppc405_soc_realize(DeviceState *dev,
Error **errp)
/* Universal interrupt controller */
s->uic = qdev_new(TYPE_PPC_UIC);
- object_property_set_link(OBJECT(s->uic), "cpu", OBJECT(s->cpu),
+ object_property_set_link(OBJECT(s->uic), "cpu", OBJECT(>cpu),
_fatal);
if (!sysbus_realize(SYS_BUS_DEVICE(s->uic), errp)) {
return;
}
sysbus_connect_irq(SYS_BUS_DEVICE(s->uic), PPCUIC_OUTPUT_INT,
- qdev_get_gpio_in(DEVICE(s->cpu),
PPC40x_INPUT_INT));
+ qdev_get_gpio_in(DEVICE(>cpu),
PPC40x_INPUT_INT));
sysbus_connect_irq(SYS_BUS_DEVICE(s->uic), PPCUIC_OUTPUT_CINT,
- qdev_get_gpio_in(DEVICE(s->cpu),
PPC40x_INPUT_CINT));
+ qdev_get_gpio_in(DEVICE(>cpu),
PPC40x_INPUT_CINT));
/* SDRAM controller */
/* XXX 405EP has no ECC interrupt */
@@ -1562,6 +1576,7 @@ static const TypeInfo
Re: Migration tests are very slow in the CI
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Mon, Aug 08, 2022 at 02:43:49PM +0200, Thomas Huth wrote:
> > On 08/08/2022 14.14, Daniel P. Berrangé wrote:
> > > On Mon, Aug 08, 2022 at 01:57:17PM +0200, Thomas Huth wrote:
> > > >
> > > > Hi!
> > > >
> > > > Seems like we're getting more timeouts in the CI pipelines since commit
> > > > 2649a72555e ("Allow test to run without uffd") enabled the migration
> > > > tests
> > > > in more scenarios.
> > > >
> > > > For example:
> > > >
> > > > https://gitlab.com/qemu-project/qemu/-/jobs/2821578332#L49
> > > >
> > > > You can see that the migration-test ran for more than 20 minutes for
> > > > each
> > > > target (x86 and aarch64)! I think that's way too much by default.
> > >
> > > Definitely too much.
> > >
> > > > I had a check whether there is one subtest taking a lot of time, but it
> > > > rather seems like each of the migration test is taking 40 to 50 seconds
> > > > in
> > > > the CI:
> > > >
> > > > https://gitlab.com/thuth/qemu/-/jobs/2825365836#L44
> > >
> > > Normally with CI we expect a constant slowdown factor, eg x2.
> > >
> > > I expect with migration though, we're triggering behaviour whereby
> > > the guest workload is generating dirty pages quicker than we can
> > > migrate them over localhost. The balance in this can quickly tip
> > > to create an exponential slowdown.
> >
> > If I run the aarch64 migration-test on my otherwise idle x86 laptop, it also
> > takes already ca. 460 seconds to finish, which is IMHO also already too much
> > for a normal "make check" run (without SPEED=slow).
> >
> > > I'm not sure if 'g_test_slow' gives us enough granularity though, as
> > > if we enable that, it'll impact the whole test suite, not just
> > > migration tests.
> >
> > We could also check for the GITLAB_CI environment variable, just like we
> > already do it in some of the avocado-based tests ... but given the fact that
> > the migration test is already very slow on my normal x86 laptop, I think I'd
> > prefer if we added some checks with g_test_slow() in there ...
> >
> > Are there any tests in migration-test.c that are rather redundant and could
> > be easily skipped in quick mode?
>
> The trouble with migration is that there are alot of subtle permutations
> that interact in wierd ways, so we've got alot of test scenarios, includuing
> many with TLS:
>
> /x86_64/migration/bad_dest
> /x86_64/migration/fd_proto
> /x86_64/migration/validate_uuid
> /x86_64/migration/validate_uuid_error
> /x86_64/migration/validate_uuid_src_not_set
> /x86_64/migration/validate_uuid_dst_not_set
> /x86_64/migration/auto_converge
> /x86_64/migration/dirty_ring
> /x86_64/migration/vcpu_dirty_limit
> /x86_64/migration/postcopy/unix
> /x86_64/migration/postcopy/plain
> /x86_64/migration/postcopy/recovery/plain
> /x86_64/migration/postcopy/recovery/tls/psk
> /x86_64/migration/postcopy/preempt/plain
> /x86_64/migration/postcopy/preempt/recovery/plain
> /x86_64/migration/postcopy/preempt/recovery/tls/psk
> /x86_64/migration/postcopy/preempt/tls/psk
> /x86_64/migration/postcopy/tls/psk
> /x86_64/migration/precopy/unix/plain
> /x86_64/migration/precopy/unix/xbzrle
> /x86_64/migration/precopy/unix/tls/psk
> /x86_64/migration/precopy/unix/tls/x509/default-host
> /x86_64/migration/precopy/unix/tls/x509/override-host
> /x86_64/migration/precopy/tcp/plain
> /x86_64/migration/precopy/tcp/tls/psk/match
> /x86_64/migration/precopy/tcp/tls/psk/mismatch
> /x86_64/migration/precopy/tcp/tls/x509/default-host
> /x86_64/migration/precopy/tcp/tls/x509/override-host
> /x86_64/migration/precopy/tcp/tls/x509/mismatch-host
> /x86_64/migration/precopy/tcp/tls/x509/friendly-client
> /x86_64/migration/precopy/tcp/tls/x509/hostile-client
> /x86_64/migration/precopy/tcp/tls/x509/allow-anon-client
> /x86_64/migration/precopy/tcp/tls/x509/reject-anon-client
> /x86_64/migration/multifd/tcp/plain/none
> /x86_64/migration/multifd/tcp/plain/cancel
> /x86_64/migration/multifd/tcp/plain/zlib
> /x86_64/migration/multifd/tcp/plain/zstd
> /x86_64/migration/multifd/tcp/tls/psk/match
> /x86_64/migration/multifd/tcp/tls/psk/mismatch
> /x86_64/migration/multifd/tcp/tls/x509/default-host
> /x86_64/migration/multifd/tcp/tls/x509/override-host
> /x86_64/migration/multifd/tcp/tls/x509/mismatch-host
> /x86_64/migration/multifd/tcp/tls/x509/allow-anon-client
> /x86_64/migration/multifd/tcp/tls/x509/reject-anon-client
>
> Each takes about 4 seconds, except for the xbzrle, autoconverge and
> vcpu-dirty-rate tests which take 8-12 seconds.
>
> We could short-circuit most of the tls tests, because 90% of what
> they're validating is the initial connection setup phase. We don't
> really need to run the full migration to completion, we can just
> abort once we're running. Just keep 3 doing the full migration
> to completion - one precopy, one postcopy and one multifd.
I'd rather we combined some than cutting stuff off; I was about to
suggest doing zlib with some of the TLS but then that
Re: [PULL 0/4] Fixes for QEMU 7.1
On 8/7/22 22:05, Thomas Huth wrote: Hi! The following changes since commit c669f22f1a47897e8d1d595d6b8a59a572f9158c: Merge tag 'pull-la-20220805' of https://gitlab.com/rth7680/qemu into staging (2022-08-05 12:55:53 -0700) are available in the Git repository at: https://gitlab.com/thuth/qemu.git tags/pull-request-2022-08-08 for you to fetch changes up to 407634970dc5dba9330c360cfdc4e69e7aea3b37: tests/qemu-iotests/264: Allow up to 5s for the BLOCK_JOB_CANCEL event to arrive (2022-08-07 18:51:35 +0200) * Fix booting in the s390-ccw bios when physical and logical block sizes differ * Fix the replay-linux avocado test * Relax a time constraint in iotest 264 Applied, thanks. Please update https://wiki.qemu.org/ChangeLog/7.1 as appropriate. r~ Pavel Dovgalyuk (1): tests/avocado: fix replay-linux test Thomas Huth (3): pc-bios/s390-ccw: Fix booting with logical block size < physical block size pc-bios/s390-ccw: Update the s390-ccw.img with the block size fix tests/qemu-iotests/264: Allow up to 5s for the BLOCK_JOB_CANCEL event to arrive pc-bios/s390-ccw/virtio-blkdev.c | 2 +- pc-bios/s390-ccw.img | Bin 42608 -> 42608 bytes tests/avocado/replay_linux.py| 1 + tests/qemu-iotests/264 | 2 +- 4 files changed, 3 insertions(+), 2 deletions(-)
Re: [PATCH for-7.2 06/10] ppc/pnv: enable user created pnv-phb for powernv8
On 8/5/22 07:50, Frederic Barrat wrote:
diff --git a/hw/pci-host/pnv_phb.c b/hw/pci-host/pnv_phb.c
index 077f391d59..953c384bf6 100644
--- a/hw/pci-host/pnv_phb.c
+++ b/hw/pci-host/pnv_phb.c
@@ -17,6 +17,7 @@
#include "hw/ppc/pnv.h"
#include "hw/qdev-properties.h"
#include "qom/object.h"
+#include "sysemu/sysemu.h"
/*
@@ -171,6 +172,10 @@ static void pnv_phb_realize(DeviceState *dev, Error **errp)
pnv_phb4_bus_init(dev, PNV_PHB4(phb->backend));
}
+ if (phb->version == 3 && !defaults_enabled()) {
+ return;
+ }
+
pnv_phb_attach_root_port(pci);
}
So we skip the call to pnv_phb_attach_root_port() for the user created PHBs.
I seem to remember that when the user creates a PHB on the command line, they
also need to create the root port and we can't just create one by default with
the PHB. It seems heavy when just using the qemu CLI but that was a requirement
from libvirt. Did I get that right?
libvirt requires all pci devices to be declared in the XML. If we create the
root ports automatically by just adding PHBs I would need to reflect that
in the domain XML by either automatically add root ports with each PHB, which
is easier said than done, or tell the user to do so.
libvirt also allows for custom naming of the buses, e.g the PHB can be named
'phb-root0' and its root port 'my-rootport.1'. There's no way we can name
root ports buses by adding them automatically with each PHB like we do
for default PHBs.
In any case, I can see a problem. pnv_phb_attach_root_port() creates the root port
object, so if the above is correct, we want to skip that. But it also creates the
PHB->root port relationship in QOM. That we don't do anywhere for the
user-created case.
Calling qemu with "-nodefaults -device pnv-phb -device pnv-phb-root-port", here
is what I see in QOM, which shows the wrong parenting of the root port:
/peripheral-anon (container)
/device[1] (pnv-phb-root-port)
/bus master container[0] (memory-region)
/bus master[0] (memory-region)
/pci_bridge_io[0] (memory-region)
/pci_bridge_io[1] (memory-region)
/pci_bridge_mem[0] (memory-region)
/pci_bridge_pci[0] (memory-region)
/pci_bridge_pref_mem[0] (memory-region)
/pci_bridge_vga_io_hi[0] (memory-region)
/pci_bridge_vga_io_lo[0] (memory-region)
/pci_bridge_vga_mem[0] (memory-region)
/pcie.0 (PCIE)
With the full series, same problem on P8/P9/P10
I forgot to mention it in the cover letter. This is intended. The reason
is that we can't access the PHB from the root-port due to QOM best
practices, i.e. we can't do qdev_get_parent_bus()->parent to parent
the root port with the PHB. The reason why we're able to do that for
default devices is because we have access to the PHB regardless of QOM
when creating the root port.
If we want QOM consistency between user created devices and default
devices, one alternative is to make the root-port a child of the
root bus. That can be achievable in both cases.
Thanks,
Daniel
Fred
Re: [PATCH 0/2] virtio-blk and scsi: replace dataplane_{start/stopping/started}
On Mon, Aug 08, 2022 at 05:41:45AM -0400, Emanuele Giuseppe Esposito wrote:
> The way the dataplane stages at startup and stop are monitored is unnecessary
> complicated. In virtio-scsi we have dataplane_started, dataplane_starting and
> dataplane_stopping in VirtIOSCSI.
> In virtio-blk we have dataplene_started in VirtIOBlock, and starting and
> stopping
> in VirtIOBlockDataPlane.
>
> Just replace all these flags with an atomic enum.
>
> Based-on: 20220803162824.948023-1-stefa...@redhat.com
Hi Emanuele,
I posted a v2 of my virtio-scsi dataplane startup race condition fix
that's related to this patch. This time it's based on how virtio-blk
does it.
We can merge both our patch series or just one of them in order to fix
the race condition.
Stefan
>
> Emanuele Giuseppe Esposito (2):
> virtio-scsi: replace VirtIOBlock dataplane_{start/starting/stopped}
> with enum
> virtio-blk: replace dataplane_start/stopping/started with enum
>
> hw/block/dataplane/virtio-blk.c | 24 +---
> hw/block/virtio-blk.c | 9 +
> hw/scsi/virtio-scsi-dataplane.c | 21 +
> hw/scsi/virtio-scsi.c | 10 ++
> include/hw/virtio/virtio-blk.h | 2 +-
> include/hw/virtio/virtio-scsi.h | 5 ++---
> include/hw/virtio/virtio.h | 7 +++
> 7 files changed, 39 insertions(+), 39 deletions(-)
>
> --
> 2.31.1
>
signature.asc
Description: PGP signature
[PATCH v2] virtio-scsi: fix race in virtio_scsi_dataplane_start()
As soon as virtio_scsi_data_plane_start() attaches host notifiers the
IOThread may start virtqueue processing. There is a race between
IOThread virtqueue processing and virtio_scsi_data_plane_start() because
it only assigns s->dataplane_started after attaching host notifiers.
When a virtqueue handler function in the IOThread calls
virtio_scsi_defer_to_dataplane() it may see !s->dataplane_started and
attempt to start dataplane even though we're already in the IOThread:
#0 0x7f67b360857c __pthread_kill_implementation (libc.so.6 + 0xa257c)
#1 0x7f67b35bbd56 raise (libc.so.6 + 0x55d56)
#2 0x7f67b358e833 abort (libc.so.6 + 0x28833)
#3 0x7f67b358e75b __assert_fail_base.cold (libc.so.6 + 0x2875b)
#4 0x7f67b35b4cd6 __assert_fail (libc.so.6 + 0x4ecd6)
#5 0x55ca87fd411b memory_region_transaction_commit (qemu-kvm + 0x67511b)
#6 0x55ca87e17811 virtio_pci_ioeventfd_assign (qemu-kvm + 0x4b8811)
#7 0x55ca87e14836 virtio_bus_set_host_notifier (qemu-kvm + 0x4b5836)
#8 0x55ca87f8e14e virtio_scsi_set_host_notifier (qemu-kvm + 0x62f14e)
#9 0x55ca87f8dd62 virtio_scsi_dataplane_start (qemu-kvm + 0x62ed62)
#10 0x55ca87e14610 virtio_bus_start_ioeventfd (qemu-kvm + 0x4b5610)
#11 0x55ca87f8c29a virtio_scsi_handle_ctrl (qemu-kvm + 0x62d29a)
#12 0x55ca87fa5902 virtio_queue_host_notifier_read (qemu-kvm + 0x646902)
#13 0x55ca882c099e aio_dispatch_handler (qemu-kvm + 0x96199e)
#14 0x55ca882c1761 aio_poll (qemu-kvm + 0x962761)
#15 0x55ca880e1052 iothread_run (qemu-kvm + 0x782052)
#16 0x55ca882c562a qemu_thread_start (qemu-kvm + 0x96662a)
This patch assigns s->dataplane_started before attaching host notifiers
so that virtqueue handler functions that run in the IOThread before
virtio_scsi_data_plane_start() returns correctly identify that dataplane
does not need to be started. This fix is taken from the virtio-blk
dataplane code and it's worth adding a comment in virtio-blk as well to
explain why it works.
Note that s->dataplane_started does not need the AioContext lock because
it is set before attaching host notifiers and cleared after detaching
host notifiers. In other words, the IOThread always sees the value true
and the main loop thread does not modify it while the IOThread is
active.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2099541
Reported-by: Qing Wang
Signed-off-by: Stefan Hajnoczi
---
v2:
- Switch to a smaller fix inspired by virtio-blk and document why
virtio-blk works [Paolo]
hw/block/dataplane/virtio-blk.c | 5 +
hw/scsi/virtio-scsi-dataplane.c | 11 ---
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
index 49276e46f2..26f965cabc 100644
--- a/hw/block/dataplane/virtio-blk.c
+++ b/hw/block/dataplane/virtio-blk.c
@@ -219,6 +219,11 @@ int virtio_blk_data_plane_start(VirtIODevice *vdev)
memory_region_transaction_commit();
+/*
+ * These fields are visible to the IOThread so we rely on implicit barriers
+ * in aio_context_acquire() on the write side and aio_notify_accept() on
+ * the read side.
+ */
s->starting = false;
vblk->dataplane_started = true;
trace_virtio_blk_data_plane_start(s);
diff --git a/hw/scsi/virtio-scsi-dataplane.c b/hw/scsi/virtio-scsi-dataplane.c
index 8bb6e6acfc..20bb91766e 100644
--- a/hw/scsi/virtio-scsi-dataplane.c
+++ b/hw/scsi/virtio-scsi-dataplane.c
@@ -136,6 +136,14 @@ int virtio_scsi_dataplane_start(VirtIODevice *vdev)
memory_region_transaction_commit();
+/*
+ * These fields are visible to the IOThread so we rely on implicit barriers
+ * in aio_context_acquire() on the write side and aio_notify_accept() on
+ * the read side.
+ */
+s->dataplane_starting = false;
+s->dataplane_started = true;
+
aio_context_acquire(s->ctx);
virtio_queue_aio_attach_host_notifier(vs->ctrl_vq, s->ctx);
virtio_queue_aio_attach_host_notifier_no_poll(vs->event_vq, s->ctx);
@@ -143,9 +151,6 @@ int virtio_scsi_dataplane_start(VirtIODevice *vdev)
for (i = 0; i < vs->conf.num_queues; i++) {
virtio_queue_aio_attach_host_notifier(vs->cmd_vqs[i], s->ctx);
}
-
-s->dataplane_starting = false;
-s->dataplane_started = true;
aio_context_release(s->ctx);
return 0;
--
2.37.1
Re: [PATCH 1/5] target/riscv: Ignore the S and U letters when formatting ISA strings
On 08/08/2022 16:03, Tsukasa OI wrote: > I agree with Alistair. **I** removed 'S' and 'U' from the ISA string > and it should be working in the latest development branch (I tested). Yeah, I saw what you as I looked at the commit log while trying to understand why there were invalid strings appearing when the code looked like it was impossible. Certainly I found it very very odd. I didn't just revive a 2 year old patch without taking a look at the code. > Besides, this function alone generates the ISA string for DTB and > there's no way such ISA strings with invalid 'S' and 'U' can be > generated. It's definitely a behavior of QEMU 7.0 or before. Hmm, it would seem that you're right - I have retested on a fresh clone. I did checkout v7.1.0-rc1 before running the first build that I saw the invalid string on as I'd been on some hacked up & fossilised version prior to that. Perhaps some build artifacts were not correctly removed, consider me quite confused! I do recall the configure script saying something about my build directory when I kicked it off, so it is likely down to that. Unfortunately my bash history is out of order so I will not be able to replicate the conditions, having many terminals open does have it's downsides. > Please. Please make sure that you are testing the right version of QEMU. Heh. Please, please give me some allowance for reasonably believing I was in fact on the latest qemu/master after checking it out and building! I guess this patch can then be safely ignored :) Glad to have cleared this up as I was rather confused by what I saw. Thanks Tsukasa/Alistair.
Re: [PATCH v3 07/22] ppc/ppc405: QOM'ify CPU
On 8/8/22 15:17, BALATON Zoltan wrote:
Patch title is wrong. It should be Embed CPU object in SoC as it's not QOMifies
the CPU just moves it from dinamically allocated to embedded.
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
Drop the use of ppc4xx_init() and duplicate a bit of code related to
clocks in the SoC realize routine. We will clean that up in the
following patches.
Could this be split off into a separate patch? Maybe it would be clearer that
way what's related to stop using ppc4xx_init() (which is needed because it
dinamically allocates CPU) and what's the embedding it in the soc object.
I'd rather not. It has been painful enough to untangle. Let's keep it that
way. And, this part is further changed in the CPC patch.
ppc_dcr_init() simply allocates default DCR handlers for the CPU. Maybe
this could be done in model initializer of the CPU families needing it.
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h | 2 +-
include/hw/ppc/ppc4xx.h | 1 +
hw/ppc/ppc405_boards.c | 2 +-
hw/ppc/ppc405_uc.c | 35 +--
hw/ppc/ppc4xx_devs.c | 2 +-
5 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index dc862bc8614c..8cc76cc8b3fe 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -79,7 +79,7 @@ struct Ppc405SoCState {
hwaddr ram_size;
uint32_t sysclk;
- PowerPCCPU *cpu;
+ PowerPCCPU cpu;
DeviceState *uic;
};
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 980f964b5a91..021376c2d260 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -29,6 +29,7 @@
#include "exec/memory.h"
/* PowerPC 4xx core initialization */
+void ppc4xx_reset(void *opaque);
PowerPCCPU *ppc4xx_init(const char *cpu_model,
clk_setup_t *cpu_clk, clk_setup_t *tb_clk,
uint32_t sysclk);
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 0b39ff08bd65..5ba12d60bc00 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -313,7 +313,7 @@ static void ppc405_init(MachineState *machine)
/* Load ELF kernel and rootfs.cpio */
} else if (kernel_filename && !machine->firmware) {
- boot_from_kernel(machine, ppc405->soc.cpu);
+ boot_from_kernel(machine, >soc.cpu);
}
}
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index abcc2537140c..fa3853df2233 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1432,22 +1432,36 @@ static void ppc405ep_cpc_init (CPUPPCState *env,
clk_setup_t clk_setup[8],
#endif
}
+static void ppc405_soc_instance_init(Object *obj)
+{
+ Ppc405SoCState *s = PPC405_SOC(obj);
+
+ object_initialize_child(obj, "cpu", >cpu,
+ POWERPC_CPU_TYPE_NAME("405ep"));
+}
+
static void ppc405_soc_realize(DeviceState *dev, Error **errp)
{
Ppc405SoCState *s = PPC405_SOC(dev);
- clk_setup_t clk_setup[PPC405EP_CLK_NB], tlb_clk_setup;
+ clk_setup_t clk_setup[PPC405EP_CLK_NB];
qemu_irq dma_irqs[4], gpt_irqs[5], mal_irqs[4];
CPUPPCState *env;
memset(clk_setup, 0, sizeof(clk_setup));
/* init CPUs */
- s->cpu = ppc4xx_init(POWERPC_CPU_TYPE_NAME("405ep"),
- _setup[PPC405EP_CPU_CLK],
- _clk_setup, s->sysclk);
- env = >cpu->env;
- clk_setup[PPC405EP_CPU_CLK].cb = tlb_clk_setup.cb;
- clk_setup[PPC405EP_CPU_CLK].opaque = tlb_clk_setup.opaque;
+ if (!qdev_realize(DEVICE(>cpu), NULL, errp)) {
+ return;
+ }
+ qemu_register_reset(ppc4xx_reset, >cpu);
+
+ env = >cpu.env;
+
+ clk_setup[PPC405EP_CPU_CLK].cb =
+ ppc_40x_timers_init(env, s->sysclk, PPC_INTERRUPT_PIT);
+ clk_setup[PPC405EP_CPU_CLK].opaque = env;
+
+ ppc_dcr_init(env, NULL, NULL);
/* CPU control */
ppc405ep_cpc_init(env, clk_setup, s->sysclk);
@@ -1464,16 +1478,16 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
/* Universal interrupt controller */
s->uic = qdev_new(TYPE_PPC_UIC);
- object_property_set_link(OBJECT(s->uic), "cpu", OBJECT(s->cpu),
+ object_property_set_link(OBJECT(s->uic), "cpu", OBJECT(>cpu),
_fatal);
if (!sysbus_realize(SYS_BUS_DEVICE(s->uic), errp)) {
return;
}
sysbus_connect_irq(SYS_BUS_DEVICE(s->uic), PPCUIC_OUTPUT_INT,
- qdev_get_gpio_in(DEVICE(s->cpu), PPC40x_INPUT_INT));
+ qdev_get_gpio_in(DEVICE(>cpu), PPC40x_INPUT_INT));
sysbus_connect_irq(SYS_BUS_DEVICE(s->uic), PPCUIC_OUTPUT_CINT,
- qdev_get_gpio_in(DEVICE(s->cpu), PPC40x_INPUT_CINT));
+ qdev_get_gpio_in(DEVICE(>cpu), PPC40x_INPUT_CINT));
/* SDRAM controller */
/* XXX 405EP has no ECC interrupt */
@@ -1562,6 +1576,7 @@ static const TypeInfo ppc405_types[] = {
.name = TYPE_PPC405_SOC,
.parent = TYPE_DEVICE,
.instance_size =
Re: [PATCH] virtio-scsi: fix race in virtio_scsi_dataplane_start()
On Fri, Aug 05, 2022 at 11:41:27AM +0200, Paolo Bonzini wrote:
> On 8/5/22 09:04, Michael S. Tsirkin wrote:
> > >
> > > Buglink:https://bugzilla.redhat.com/show_bug.cgi?id=2099541
> > > Reported-by: Qing Wang
> > > Signed-off-by: Stefan Hajnoczi
> > A scsi thing that tree seems more appropriate.
> >
> > Reviewed-by: Michael S. Tsirkin
> >
> >
> >
>
> Since the same thing has to be done in virtio-blk, any of the
> block/misc/virtio tree will do.
I don't think virtio-blk changes are required because it's already safe.
On the store side:
s->starting = false;
vblk->dataplane_started = true;
trace_virtio_blk_data_plane_start(s);
...
/* Get this show started by hooking up our callbacks */
aio_context_acquire(s->ctx);
^^^ implicit memory barrier ^^^
for (i = 0; i < nvqs; i++) {
VirtQueue *vq = virtio_get_queue(s->vdev, i);
virtio_queue_aio_attach_host_notifier(vq, s->ctx);
}
aio_context_release(s->ctx);
On the load side:
void aio_notify_accept(AioContext *ctx)
{
qatomic_set(>notified, false);
/*
* Write ctx->notified before reading e.g. bh->flags. Pairs with smp_wmb
* in aio_notify.
*/
smp_mb();
^
}
vblk->dataplane_started will be visible to the IOThread.
Stefan
signature.asc
Description: PGP signature
RE: [BUG] cxl can not create region
Bobo WL wrote: > Hi list > > I want to test cxl functions in arm64, and found some problems I can't > figure out. > > My test environment: > > 1. build latest bios from https://github.com/tianocore/edk2.git master > branch(cc2db6ebfb6d9d85ba4c7b35fba1fa37fffc0bc2) > 2. build latest qemu-system-aarch64 from git://git.qemu.org/qemu.git > master branch(846dcf0ba4eff824c295f06550b8673ff3f31314). With cxl arm > support patch: > https://patchwork.kernel.org/project/cxl/cover/20220616141950.23374-1-jonathan.came...@huawei.com/ > 3. build Linux kernel from > https://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl.git preview > branch(65fc1c3d26b96002a5aa1f4012fae4dc98fd5683) > 4. build latest ndctl tools from https://github.com/pmem/ndctl > create_region branch(8558b394e449779e3a4f3ae90fae77ede0bca159) > > And my qemu test commands: > sudo $QEMU_BIN -M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 \ > -cpu max -smp 8 -nographic -no-reboot \ > -kernel $KERNEL -bios $BIOS_BIN \ > -drive if=none,file=$ROOTFS,format=qcow2,id=hd \ > -device virtio-blk-pci,drive=hd -append 'root=/dev/vda1 > nokaslr dyndbg="module cxl* +p"' \ > -object memory-backend-ram,size=4G,id=mem0 \ > -numa node,nodeid=0,cpus=0-7,memdev=mem0 \ > -net nic -net user,hostfwd=tcp::-:22 -enable-kvm \ > -object > memory-backend-file,id=cxl-mem0,share=on,mem-path=/tmp/cxltest.raw,size=256M > \ > -object > memory-backend-file,id=cxl-mem1,share=on,mem-path=/tmp/cxltest1.raw,size=256M > \ > -object > memory-backend-file,id=cxl-mem2,share=on,mem-path=/tmp/cxltest2.raw,size=256M > \ > -object > memory-backend-file,id=cxl-mem3,share=on,mem-path=/tmp/cxltest3.raw,size=256M > \ > -object > memory-backend-file,id=cxl-lsa0,share=on,mem-path=/tmp/lsa0.raw,size=256M > \ > -object > memory-backend-file,id=cxl-lsa1,share=on,mem-path=/tmp/lsa1.raw,size=256M > \ > -object > memory-backend-file,id=cxl-lsa2,share=on,mem-path=/tmp/lsa2.raw,size=256M > \ > -object > memory-backend-file,id=cxl-lsa3,share=on,mem-path=/tmp/lsa3.raw,size=256M > \ > -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ > -device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \ > -device cxl-upstream,bus=root_port0,id=us0 \ > -device cxl-downstream,port=0,bus=us0,id=swport0,chassis=0,slot=4 \ > -device > cxl-type3,bus=swport0,memdev=cxl-mem0,lsa=cxl-lsa0,id=cxl-pmem0 \ > -device cxl-downstream,port=1,bus=us0,id=swport1,chassis=0,slot=5 \ > -device > cxl-type3,bus=swport1,memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem1 \ > -device cxl-downstream,port=2,bus=us0,id=swport2,chassis=0,slot=6 \ > -device > cxl-type3,bus=swport2,memdev=cxl-mem2,lsa=cxl-lsa2,id=cxl-pmem2 \ > -device cxl-downstream,port=3,bus=us0,id=swport3,chassis=0,slot=7 \ > -device > cxl-type3,bus=swport3,memdev=cxl-mem3,lsa=cxl-lsa3,id=cxl-pmem3 \ > -M > cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k > > And I have got two problems. > 1. When I want to create x1 region with command: "cxl create-region -d > decoder0.0 -w 1 -g 4096 mem0", kernel crashed with null pointer > reference. Crash log: > > [ 534.697324] cxl_region region0: config state: 0 > [ 534.697346] cxl_region region0: probe: -6 > [ 534.697368] cxl_acpi ACPI0017:00: decoder0.0: created region0 > [ 534.699115] cxl region0: mem0:endpoint3 decoder3.0 add: > mem0:decoder3.0 @ 0 next: none nr_eps: 1 nr_targets: 1 > [ 534.699149] cxl region0: :0d:00.0:port2 decoder2.0 add: > mem0:decoder3.0 @ 0 next: mem0 nr_eps: 1 nr_targets: 1 > [ 534.699167] cxl region0: ACPI0016:00:port1 decoder1.0 add: > mem0:decoder3.0 @ 0 next: :0d:00.0 nr_eps: 1 nr_targets: 1 > [ 534.699176] cxl region0: ACPI0016:00:port1 iw: 1 ig: 256 > [ 534.699182] cxl region0: ACPI0016:00:port1 target[0] = :0c:00.0 > for mem0:decoder3.0 @ 0 > [ 534.699189] cxl region0: :0d:00.0:port2 iw: 1 ig: 256 > [ 534.699193] cxl region0: :0d:00.0:port2 target[0] = > :0e:00.0 for mem0:decoder3.0 @ 0 > [ 534.699405] Unable to handle kernel NULL pointer dereference at > virtual address > [ 534.701474] Mem abort info: > [ 534.701994] ESR = 0x8604 > [ 534.702653] EC = 0x21: IABT (current EL), IL = 32 bits > [ 534.703616] SET = 0, FnV = 0 > [ 534.704174] EA = 0, S1PTW = 0 > [ 534.704803] FSC = 0x04: level 0 translation fault > [ 534.705694] user pgtable: 4k pages, 48-bit VAs, pgdp=00010144a000 > [ 534.706875] [] pgd=, p4d= > [ 534.709855] Internal error: Oops: 8604 [#1] PREEMPT SMP > [ 534.710301] Modules linked in: > [ 534.710546] CPU: 7 PID: 331 Comm: cxl Not tainted > 5.19.0-rc3-00064-g65fc1c3d26b9-dirty #11 > [ 534.715393] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 > [ 534.717179] pstate: 6045 (nZCv daif +PAN
Re: [PATCH v3 19/22] ppc/ppc405: QOM'ify FPGA
On 8/8/22 16:55, BALATON Zoltan wrote:
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405_boards.c | 55 +-
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 5ba12d60bc00..195aa58c35ad 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -71,18 +71,23 @@ struct Ppc405MachineState {
* - NVRAM (0xF000)
* - FPGA (0xF030)
*/
-typedef struct ref405ep_fpga_t ref405ep_fpga_t;
-struct ref405ep_fpga_t {
+
+#define TYPE_PPC405_FPGA "ppc405-fpga"
If this is specific to ref405ep maybe it should be named accordingly.
done.
Thanks,
C.
Regards,
BALATON Zoltan
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405FpgaState, PPC405_FPGA);
+struct Ppc405FpgaState {
+ SysBusDevice parent_obj;
+
+ MemoryRegion iomem;
+
uint8_t reg0;
uint8_t reg1;
};
static uint64_t ref405ep_fpga_readb(void *opaque, hwaddr addr, unsigned size)
{
- ref405ep_fpga_t *fpga;
+ Ppc405FpgaState *fpga = PPC405_FPGA(opaque);
uint32_t ret;
- fpga = opaque;
switch (addr) {
case 0x0:
ret = fpga->reg0;
@@ -101,9 +106,8 @@ static uint64_t ref405ep_fpga_readb(void *opaque, hwaddr
addr, unsigned size)
static void ref405ep_fpga_writeb(void *opaque, hwaddr addr, uint64_t value,
unsigned size)
{
- ref405ep_fpga_t *fpga;
+ Ppc405FpgaState *fpga = PPC405_FPGA(opaque);
- fpga = opaque;
switch (addr) {
case 0x0:
/* Read only */
@@ -126,27 +130,39 @@ static const MemoryRegionOps ref405ep_fpga_ops = {
.endianness = DEVICE_BIG_ENDIAN,
};
-static void ref405ep_fpga_reset (void *opaque)
+static void ref405ep_fpga_reset(DeviceState *dev)
{
- ref405ep_fpga_t *fpga;
+ Ppc405FpgaState *fpga = PPC405_FPGA(dev);
- fpga = opaque;
fpga->reg0 = 0x00;
fpga->reg1 = 0x0F;
}
-static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base)
+static void ref405ep_fpga_realize(DeviceState *dev, Error **errp)
{
- ref405ep_fpga_t *fpga;
- MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
+ Ppc405FpgaState *s = PPC405_FPGA(dev);
- fpga = g_new0(ref405ep_fpga_t, 1);
- memory_region_init_io(fpga_memory, NULL, _fpga_ops, fpga,
+ memory_region_init_io(>iomem, OBJECT(s), _fpga_ops, s,
"fpga", 0x0100);
- memory_region_add_subregion(sysmem, base, fpga_memory);
- qemu_register_reset(_fpga_reset, fpga);
+ sysbus_init_mmio(SYS_BUS_DEVICE(s), >iomem);
+}
+
+static void ref405ep_fpga_class_init(ObjectClass *oc, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(oc);
+
+ dc->realize = ref405ep_fpga_realize;
+ dc->user_creatable = false;
+ dc->reset = ref405ep_fpga_reset;
}
+static const TypeInfo ref405ep_fpga_type = {
+ .name = TYPE_PPC405_FPGA,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(Ppc405FpgaState),
+ .class_init = ref405ep_fpga_class_init,
+};
+
/*
* CPU reset handler when booting directly from a loaded kernel
*/
@@ -332,7 +348,11 @@ static void ref405ep_init(MachineState *machine)
memory_region_add_subregion(sysmem, PPC405EP_SRAM_BASE, sram);
/* Register FPGA */
- ref405ep_fpga_init(get_system_memory(), PPC405EP_FPGA_BASE);
+ dev = qdev_new(TYPE_PPC405_FPGA);
+ object_property_add_child(OBJECT(machine), "fpga", OBJECT(dev));
+ sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+ sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, PPC405EP_FPGA_BASE);
+
/* Register NVRAM */
dev = qdev_new("sysbus-m48t08");
qdev_prop_set_int32(dev, "base-year", 1968);
@@ -377,6 +397,7 @@ static void ppc405_machine_init(void)
{
type_register_static(_machine_type);
type_register_static(_type);
+ type_register_static(_fpga_type);
}
type_init(ppc405_machine_init)
Re: [PATCH 1/2] util/main-loop: Fix maximum number of wait objects for win32
On Fri, Aug 5, 2022 at 10:56 PM Bin Meng wrote: > > From: Bin Meng > > The maximum number of wait objects for win32 should be > MAXIMUM_WAIT_OBJECTS, not MAXIMUM_WAIT_OBJECTS + 1. > > Signed-off-by: Bin Meng > --- > > util/main-loop.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > Ping?
Re: [PATCH 0/2] virtio-blk and scsi: replace dataplane_{start/stopping/started}
On Mon, Aug 08, 2022 at 05:41:45AM -0400, Emanuele Giuseppe Esposito wrote: > The way the dataplane stages at startup and stop are monitored is unnecessary > complicated. In virtio-scsi we have dataplane_started, dataplane_starting and > dataplane_stopping in VirtIOSCSI. > In virtio-blk we have dataplene_started in VirtIOBlock, and starting and > stopping > in VirtIOBlockDataPlane. > > Just replace all these flags with an atomic enum. > > Based-on: 20220803162824.948023-1-stefa...@redhat.com As mentioned on IRC, I don't think it's useful to combine these fields into a state machine because they serve different purposes (starting/stopping prevents re-entrancy, started/stopped tracks whether dataplane is enabled, and fenced tracks whether dataplane is broken). Combining them all makes it harder to refactor those separate concerns. In the future it would be nice to refactor away all this state and have stateless IOThread support (I haven't figured out whether that's possible yet). I'm not against merging this, but I don't think using an enum is an improvement - it's just different. Regarding thread-safety, we need to guarantee that the state stored by a QEMU thread is visible to the IOThread. This patch series doesn't really do this: relaxed loads/stores aren't guaranteed to be visible to the other thread. I comment on this in the patch: there needs to be at least a comment or maybe something extra, like a memory barrier or stronger atomic operation, to make the change to atomics worthwhile. signature.asc Description: PGP signature
Re: [PATCH 2/2] virtio-blk: replace dataplane_start/stopping/started with enum
On Mon, Aug 08, 2022 at 05:41:47AM -0400, Emanuele Giuseppe Esposito wrote: > Virtio-blk uses VirtIOBlockDataPlane and VirtIOBlock to keep track of > the dataplane flags. This is completely unnecessary, as both structures > are always accessed together and we can simplify the sages with an enum. s/sages/stages/ signature.asc Description: PGP signature
Re: [PATCH 1/2] virtio-scsi: replace VirtIOBlock dataplane_{start/starting/stopped} with enum
On Mon, Aug 08, 2022 at 05:41:46AM -0400, Emanuele Giuseppe Esposito wrote: > Simplify the various dataplane stages in dataplane_start/stop by using > a single enum instead of having multiple flags. > > Read/write the enum atomically, as it can be read also by iothread > callbacks. What guarantees that these relaxed loads/stores always produce DATAPLANE_STARTING/STARTED in virtio_scsi_defer_to_dataplane() and not an older value? Are there implicit memory barriers? > > Signed-off-by: Emanuele Giuseppe Esposito > --- > hw/scsi/virtio-scsi-dataplane.c | 21 + > hw/scsi/virtio-scsi.c | 10 ++ > include/hw/virtio/virtio-scsi.h | 5 ++--- > include/hw/virtio/virtio.h | 7 +++ > 4 files changed, 24 insertions(+), 19 deletions(-) > > diff --git a/hw/scsi/virtio-scsi-dataplane.c b/hw/scsi/virtio-scsi-dataplane.c > index a575c3f0cd..9ad73e3e19 100644 > --- a/hw/scsi/virtio-scsi-dataplane.c > +++ b/hw/scsi/virtio-scsi-dataplane.c > @@ -106,13 +106,12 @@ int virtio_scsi_dataplane_start(VirtIODevice *vdev) > VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev); > VirtIOSCSI *s = VIRTIO_SCSI(vdev); > > -if (s->dataplane_started || > -s->dataplane_starting || > +if (qatomic_read(>dataplane_state) <= DATAPLANE_STARTED || It's not obvious that the STOPPING and STOPPED constants have a value greater than STARTING and STARTED. It could be other way around too. It would be safer to write the code so there are no assumptions about the constants: VirtIODataplaneStates state = qatomic_read(>dataplane_state); if (state == DATAPLANE_STARTING || state == DATAPLANE_STARTED || ...) signature.asc Description: PGP signature
Re: [PATCH v3 08/22] ppc/ppc4xx: Introduce a DCR device model
On 8/8/22 15:29, BALATON Zoltan wrote:
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
The Device Control Registers (DCR) of on-SoC devices are accessed by
software through the use of the mtdcr and mfdcr instructions. These
are converted in transactions on a side band bus, the DCR bus, which
connects the on-SoC devices to the CPU.
Ideally, we should model these accesses with a DCR namespace and DCR
memory regions but today the DCR handlers are installed in a DCR table
under the CPU. Instead introduce a little device model wrapper to hold
a CPU link and handle registration of DCR handlers.
The DCR device inherits from SysBus because most of these devices also
have a MMIO regions and/or IRQs. Being a SysBusDevice makes things
Drop "a", just "MMIO regions" due to plural. Also "makes it easier to install" or
"makes things easier".
easier to install the device model in the overall SoC.
The "cpu" link should be considered as modeling the piece of HW logic
connecting the device to the DCR bus.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/ppc4xx.h | 17 +++
hw/ppc/ppc4xx_devs.c | 46 +
2 files changed, 63 insertions(+)
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 021376c2d260..bb373db0ba10 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -27,6 +27,7 @@
#include "hw/ppc/ppc.h"
#include "exec/memory.h"
+#include "hw/sysbus.h"
/* PowerPC 4xx core initialization */
void ppc4xx_reset(void *opaque);
@@ -50,4 +51,20 @@ void ppc4xx_mal_init(CPUPPCState *env, uint8_t txcnum,
uint8_t rxcnum,
#define TYPE_PPC4xx_PCI_HOST_BRIDGE "ppc4xx-pcihost"
+/*
+ * Generic DCR device
+ */
+#define TYPE_PPC4xx_DCR_DEVICE "ppc4xx-dcr"
Should it be named ppc4xx-dcr-device for clarity? This probably won't appear
anywhere where users have to type it.
ok.
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc4xxDcrDeviceState, PPC4xx_DCR_DEVICE);
+struct Ppc4xxDcrDeviceState {
+ SysBusDevice parent_obj;
+
+ PowerPCCPU *cpu;
+};
+
+void ppc4xx_dcr_register(Ppc4xxDcrDeviceState *dev, int dcrn,
+ dcr_read_cb dcr_read, dcr_write_cb dcr_write);
+bool ppc4xx_dcr_realize(Ppc4xxDcrDeviceState *dev, PowerPCCPU *cpu,
+ Error **errp);
+
#endif /* PPC4XX_H */
diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index f20098cf417c..e07bdba0f912 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -696,3 +696,49 @@ void ppc4xx_mal_init(CPUPPCState *env, uint8_t txcnum,
uint8_t rxcnum,
mal, _read_mal, _write_mal);
}
}
+
+void ppc4xx_dcr_register(Ppc4xxDcrDeviceState *dev, int dcrn,
+ dcr_read_cb dcr_read, dcr_write_cb dcr_write)
+{
+ CPUPPCState *env;
+
+ assert(dev->cpu);
+
+ env = >cpu->env;
+
+ ppc_dcr_register(env, dcrn, dev, dcr_read, dcr_write);
+}
+
+bool ppc4xx_dcr_realize(Ppc4xxDcrDeviceState *dev, PowerPCCPU *cpu,
+ Error **errp)
+{
+ object_property_set_link(OBJECT(dev), "cpu", OBJECT(cpu), _abort);
+ return sysbus_realize(SYS_BUS_DEVICE(dev), errp);
+}
+
+
+static Property ppc4xx_dcr_properties[] = {
+ DEFINE_PROP_LINK("cpu", Ppc4xxDcrDeviceState, cpu, TYPE_POWERPC_CPU,
+ PowerPCCPU *),
+ DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ppc4xx_dcr_class_init(ObjectClass *oc, void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(oc);
+
+ dc->user_creatable = false;
Should this be .abstract instead? We expect this to not be used directly but
only via SoC devices which is what abstract is for AFAIK.
+ device_class_set_props(dc, ppc4xx_dcr_properties);
+}
+
+static const TypeInfo ppc4xx_types[] = {
+ {
+ .name = TYPE_PPC4xx_DCR_DEVICE,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(Ppc4xxDcrDeviceState),
+ .class_init = ppc4xx_dcr_class_init,
+ .abstract = true,
Oh, it's abstract already. So does it also need user_creatable for an abstract
class then? Maybe you can drop the user_creatable.
Indeed.
Thanks,
C.
Regards,
BALATON Zoltan
+ }
+};
+
+DEFINE_TYPES(ppc4xx_types)
Re: [PATCH v3 06/22] ppc/ppc405: Start QOMification of the SoC
On 8/8/22 14:59, BALATON Zoltan wrote:
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
This moves all the code previously done in the ppc405ep_init() routine
under ppc405_soc_realize(). We can also adjust the number of banks now
that we have control on ppc4xx_sdram_init().
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h | 12 ++--
hw/ppc/ppc405_boards.c | 12 ++--
hw/ppc/ppc405_uc.c | 123 -
3 files changed, 70 insertions(+), 77 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 66dc21cdfed8..dc862bc8614c 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -73,9 +73,14 @@ struct Ppc405SoCState {
/* Public */
MemoryRegion ram_banks[2];
hwaddr ram_bases[2], ram_sizes[2];
+ bool do_dram_init;
MemoryRegion *dram_mr;
hwaddr ram_size;
+
+ uint32_t sysclk;
Putting this together with dram_init would keep properties set from outside
together which is clearer than here with others set by to object itself but
this is just a small thing, not really important.
Makes sense but I am removing SoC::sysclk in the following patches.
+ PowerPCCPU *cpu;
+ DeviceState *uic;
};
/* PowerPC 405 core */
@@ -84,11 +89,4 @@ ram_addr_t ppc405_set_bootinfo(CPUPPCState *env, ram_addr_t
ram_size);
void ppc4xx_plb_init(CPUPPCState *env);
void ppc405_ebc_init(CPUPPCState *env);
-PowerPCCPU *ppc405ep_init(MemoryRegion *address_space_mem,
- MemoryRegion ram_memories[2],
- hwaddr ram_bases[2],
- hwaddr ram_sizes[2],
- uint32_t sysclk, DeviceState **uicdev,
- int do_init);
-
#endif /* PPC405_H */
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 1dc5065fcc1d..0b39ff08bd65 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -237,9 +237,7 @@ static void ppc405_init(MachineState *machine)
Ppc405MachineState *ppc405 = PPC405_MACHINE(machine);
MachineClass *mc = MACHINE_GET_CLASS(machine);
const char *kernel_filename = machine->kernel_filename;
- PowerPCCPU *cpu;
MemoryRegion *sysmem = get_system_memory();
- DeviceState *uicdev;
if (machine->ram_size != mc->default_ram_size) {
char *sz = size_to_str(mc->default_ram_size);
@@ -254,12 +252,12 @@ static void ppc405_init(MachineState *machine)
machine->ram_size, _fatal);
object_property_set_link(OBJECT(>soc), "dram",
OBJECT(machine->ram), _abort);
+ object_property_set_bool(OBJECT(>soc), "dram-init",
+ !(kernel_filename == NULL), _abort);
Maybe clearer as kernel_filename != NULL
ok.
Is there a problem with indentation in this patch? Does it pass checkpatch.pl?
No. All is fine.
Thanks,
C.
Regards,
BALATON Zoltan
+ object_property_set_uint(OBJECT(>soc), "sys-clk", ,
+ _abort);
qdev_realize(DEVICE(>soc), NULL, _abort);
- cpu = ppc405ep_init(sysmem, ppc405->soc.ram_banks, ppc405->soc.ram_bases,
- ppc405->soc.ram_sizes,
- , , kernel_filename == NULL ? 0 : 1);
-
/* allocate and load BIOS */
if (machine->firmware) {
MemoryRegion *bios = g_new(MemoryRegion, 1);
@@ -315,7 +313,7 @@ static void ppc405_init(MachineState *machine)
/* Load ELF kernel and rootfs.cpio */
} else if (kernel_filename && !machine->firmware) {
- boot_from_kernel(machine, cpu);
+ boot_from_kernel(machine, ppc405->soc.cpu);
}
}
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index adadb3a0ae08..abcc2537140c 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1432,121 +1432,118 @@ static void ppc405ep_cpc_init (CPUPPCState *env,
clk_setup_t clk_setup[8],
#endif
}
-PowerPCCPU *ppc405ep_init(MemoryRegion *address_space_mem,
- MemoryRegion ram_memories[2],
- hwaddr ram_bases[2],
- hwaddr ram_sizes[2],
- uint32_t sysclk, DeviceState **uicdevp,
- int do_init)
+static void ppc405_soc_realize(DeviceState *dev, Error **errp)
{
+ Ppc405SoCState *s = PPC405_SOC(dev);
clk_setup_t clk_setup[PPC405EP_CLK_NB], tlb_clk_setup;
qemu_irq dma_irqs[4], gpt_irqs[5], mal_irqs[4];
- PowerPCCPU *cpu;
CPUPPCState *env;
- DeviceState *uicdev;
- SysBusDevice *uicsbd;
memset(clk_setup, 0, sizeof(clk_setup));
+
/* init CPUs */
- cpu = ppc4xx_init(POWERPC_CPU_TYPE_NAME("405ep"),
+ s->cpu = ppc4xx_init(POWERPC_CPU_TYPE_NAME("405ep"),
_setup[PPC405EP_CPU_CLK],
- _clk_setup, sysclk);
- env = >env;
+ _clk_setup, s->sysclk);
+ env = >cpu->env;
clk_setup[PPC405EP_CPU_CLK].cb = tlb_clk_setup.cb;
clk_setup[PPC405EP_CPU_CLK].opaque = tlb_clk_setup.opaque;
- /* Internal devices init */
-
Re: [PATCH 1/5] target/riscv: Ignore the S and U letters when formatting ISA strings
On 2022/08/06 0:54, Conor Dooley wrote:
> From: Palmer Dabbelt
>
> The ISA strings we're providing from QEMU aren't actually legal RISC-V
> ISA strings, as both S and U cannot exist as single-letter extensions
> and must instead be multi-letter strings. We're still using the ISA
> strings inside QEMU to track the availiable extensions, so just strip
> out the S and U extensions when formatting ISA strings.
>
> Signed-off-by: Palmer Dabbelt
> [Conor: rebased on 7.1.0-rc1 & slightly tweaked the commit message]
> Signed-off-by: Conor Dooley
> ---
> target/riscv/cpu.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index ac6f82ebd0..95fdc03b3d 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -1122,7 +1122,23 @@ char *riscv_isa_string(RISCVCPU *cpu)
> char *p = isa_str + snprintf(isa_str, maxlen, "rv%d", TARGET_LONG_BITS);
> for (i = 0; i < sizeof(riscv_single_letter_exts) - 1; i++) {
> if (cpu->env.misa_ext & RV(riscv_single_letter_exts[i])) {
> -*p++ = qemu_tolower(riscv_single_letter_exts[i]);
> +char lower = qemu_tolower(riscv_single_letter_exts[i]);
> +switch (lower) {
> +case 's':
> +case 'u':
> +/*
> +* The 's' and 'u' letters shouldn't show up in ISA
> strings as
> +* they're not extensions, but they should show up in
> MISA.
> +* Since we use these letters interally as a pseudo ISA
> string
> +* to set MISA it's easier to just strip them out when
> +* formatting the ISA string.
> +*/
> +break;
> +
> +default:
> +*p++ = lower;
> +break;
> +}
> }
> }
> *p = '\0';
I agree with Alistair. **I** removed 'S' and 'U' from the ISA string
and it should be working in the latest development branch (I tested).
I tested it on master and QEMU 7.1-rc1 (tag: v7.1-rc1).
Example:
/opt/riscv/bin/qemu-system-riscv64
-machine virt
-nographic
-cpu rv64
-smp 1
-kernel images/linux.bin
-initrd images/busybox.cpio.gz
-append 'console=hvc0 earlycon=sbi'
-bios images/opensbi-fw_jump.elf
-gdb tcp::9000
Replacing -machine virt with -machine virt,dumpdtb=sample.dtb dumps the
binary DeviceTree as sample.dtb and generated CPU-related parts like...
cpu@0 {
phandle = <0x01>;
device_type = "cpu";
reg = <0x00>;
status = "okay";
compatible = "riscv";
riscv,isa =
"rv64imafdch_zicsr_zifencei_zba_zbb_zbc_zbs";
mmu-type = "riscv,sv48";
interrupt-controller {
#interrupt-cells = <0x01>;
interrupt-controller;
compatible = "riscv,cpu-intc";
phandle = <0x02>;
};
};
Besides, this function alone generates the ISA string for DTB and
there's no way such ISA strings with invalid 'S' and 'U' can be
generated. It's definitely a behavior of QEMU 7.0 or before.
Please. Please make sure that you are testing the right version of QEMU.
Thanks,
Tsukasa
Re: [PATCH v3 20/22] ppc/ppc405: Use an explicit PPCUIC object
It's not that it's now explicitly typed as PPCUIC but more that it's now
embedded in soc state instead of dynamically allocated. So Embed UIC in
soc state may be a better patch title.
Regards,
BALATON Zoltan
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h| 3 ++-
hw/ppc/ppc405_uc.c | 26 +-
2 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 31c94e474209..8e67ad0b72c3 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -27,6 +27,7 @@
#include "qom/object.h"
#include "hw/ppc/ppc4xx.h"
+#include "hw/intc/ppc-uic.h"
#define PPC405EP_SDRAM_BASE 0x
#define PPC405EP_NVRAM_BASE 0xF000
@@ -234,7 +235,7 @@ struct Ppc405SoCState {
hwaddr ram_size;
PowerPCCPU cpu;
-DeviceState *uic;
+PPCUIC uic;
Ppc405CpcState cpc;
Ppc405GptState gpt;
Ppc405OcmState ocm;
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index 73b9e60881fd..d80e22d265c8 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1341,6 +1341,8 @@ static void ppc405_soc_instance_init(Object *obj)
object_initialize_child(obj, "cpu", >cpu,
POWERPC_CPU_TYPE_NAME("405ep"));
+object_initialize_child(obj, "uic", >uic, TYPE_PPC_UIC);
+
object_initialize_child(obj, "cpc", >cpc, TYPE_PPC405_CPC);
object_property_add_alias(obj, "sys-clk", OBJECT(>cpc), "sys-clk");
@@ -1401,17 +1403,15 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
sysbus_mmio_map(SYS_BUS_DEVICE(>opba), 0, 0xef600600);
/* Universal interrupt controller */
-s->uic = qdev_new(TYPE_PPC_UIC);
-
-object_property_set_link(OBJECT(s->uic), "cpu", OBJECT(>cpu),
+object_property_set_link(OBJECT(>uic), "cpu", OBJECT(>cpu),
_fatal);
-if (!sysbus_realize(SYS_BUS_DEVICE(s->uic), errp)) {
+if (!sysbus_realize(SYS_BUS_DEVICE(>uic), errp)) {
return;
}
-sysbus_connect_irq(SYS_BUS_DEVICE(s->uic), PPCUIC_OUTPUT_INT,
+sysbus_connect_irq(SYS_BUS_DEVICE(>uic), PPCUIC_OUTPUT_INT,
qdev_get_gpio_in(DEVICE(>cpu), PPC40x_INPUT_INT));
-sysbus_connect_irq(SYS_BUS_DEVICE(s->uic), PPCUIC_OUTPUT_CINT,
+sysbus_connect_irq(SYS_BUS_DEVICE(>uic), PPCUIC_OUTPUT_CINT,
qdev_get_gpio_in(DEVICE(>cpu), PPC40x_INPUT_CINT));
/* SDRAM controller */
@@ -1422,7 +1422,7 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
"ppc405.sdram0", s->dram_mr,
s->ram_bases[0], s->ram_sizes[0]);
-ppc4xx_sdram_init(env, qdev_get_gpio_in(s->uic, 17), 1,
+ppc4xx_sdram_init(env, qdev_get_gpio_in(DEVICE(>uic), 17), 1,
s->ram_banks, s->ram_bases, s->ram_sizes,
s->do_dram_init);
@@ -1438,12 +1438,12 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
for (i = 0; i < ARRAY_SIZE(s->dma.irqs); i++) {
sysbus_connect_irq(SYS_BUS_DEVICE(>dma), i,
- qdev_get_gpio_in(s->uic, 5 + i));
+ qdev_get_gpio_in(DEVICE(>uic), 5 + i));
}
/* I2C controller */
sysbus_create_simple(TYPE_PPC4xx_I2C, 0xef600500,
- qdev_get_gpio_in(s->uic, 2));
+ qdev_get_gpio_in(DEVICE(>uic), 2));
/* GPIO */
if (!sysbus_realize(SYS_BUS_DEVICE(>gpio), errp)) {
@@ -1454,13 +1454,13 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
/* Serial ports */
if (serial_hd(0) != NULL) {
serial_mm_init(get_system_memory(), 0xef600300, 0,
- qdev_get_gpio_in(s->uic, 0),
+ qdev_get_gpio_in(DEVICE(>uic), 0),
PPC_SERIAL_MM_BAUDBASE, serial_hd(0),
DEVICE_BIG_ENDIAN);
}
if (serial_hd(1) != NULL) {
serial_mm_init(get_system_memory(), 0xef600400, 0,
- qdev_get_gpio_in(s->uic, 1),
+ qdev_get_gpio_in(DEVICE(>uic), 1),
PPC_SERIAL_MM_BAUDBASE, serial_hd(1),
DEVICE_BIG_ENDIAN);
}
@@ -1478,7 +1478,7 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
for (i = 0; i < ARRAY_SIZE(s->gpt.irqs); i++) {
sysbus_connect_irq(SYS_BUS_DEVICE(>gpt), i,
- qdev_get_gpio_in(s->uic, 19 + i));
+ qdev_get_gpio_in(DEVICE(>uic), 19 + i));
}
/* MAL */
@@ -1490,7 +1490,7 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
for (i = 0; i < ARRAY_SIZE(s->mal.irqs); i++) {
sysbus_connect_irq(SYS_BUS_DEVICE(>mal), i,
- qdev_get_gpio_in(s->uic, 11 + i));
+ qdev_get_gpio_in(DEVICE(>uic), 11 + i));
}
/* Ethernet */
Re: [PATCH v3 19/22] ppc/ppc405: QOM'ify FPGA
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405_boards.c | 55 +-
1 file changed, 38 insertions(+), 17 deletions(-)
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index 5ba12d60bc00..195aa58c35ad 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -71,18 +71,23 @@ struct Ppc405MachineState {
* - NVRAM (0xF000)
* - FPGA (0xF030)
*/
-typedef struct ref405ep_fpga_t ref405ep_fpga_t;
-struct ref405ep_fpga_t {
+
+#define TYPE_PPC405_FPGA "ppc405-fpga"
If this is specific to ref405ep maybe it should be named accordingly.
Regards,
BALATON Zoltan
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405FpgaState, PPC405_FPGA);
+struct Ppc405FpgaState {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+
uint8_t reg0;
uint8_t reg1;
};
static uint64_t ref405ep_fpga_readb(void *opaque, hwaddr addr, unsigned size)
{
-ref405ep_fpga_t *fpga;
+Ppc405FpgaState *fpga = PPC405_FPGA(opaque);
uint32_t ret;
-fpga = opaque;
switch (addr) {
case 0x0:
ret = fpga->reg0;
@@ -101,9 +106,8 @@ static uint64_t ref405ep_fpga_readb(void *opaque, hwaddr
addr, unsigned size)
static void ref405ep_fpga_writeb(void *opaque, hwaddr addr, uint64_t value,
unsigned size)
{
-ref405ep_fpga_t *fpga;
+Ppc405FpgaState *fpga = PPC405_FPGA(opaque);
-fpga = opaque;
switch (addr) {
case 0x0:
/* Read only */
@@ -126,27 +130,39 @@ static const MemoryRegionOps ref405ep_fpga_ops = {
.endianness = DEVICE_BIG_ENDIAN,
};
-static void ref405ep_fpga_reset (void *opaque)
+static void ref405ep_fpga_reset(DeviceState *dev)
{
-ref405ep_fpga_t *fpga;
+Ppc405FpgaState *fpga = PPC405_FPGA(dev);
-fpga = opaque;
fpga->reg0 = 0x00;
fpga->reg1 = 0x0F;
}
-static void ref405ep_fpga_init(MemoryRegion *sysmem, uint32_t base)
+static void ref405ep_fpga_realize(DeviceState *dev, Error **errp)
{
-ref405ep_fpga_t *fpga;
-MemoryRegion *fpga_memory = g_new(MemoryRegion, 1);
+Ppc405FpgaState *s = PPC405_FPGA(dev);
-fpga = g_new0(ref405ep_fpga_t, 1);
-memory_region_init_io(fpga_memory, NULL, _fpga_ops, fpga,
+memory_region_init_io(>iomem, OBJECT(s), _fpga_ops, s,
"fpga", 0x0100);
-memory_region_add_subregion(sysmem, base, fpga_memory);
-qemu_register_reset(_fpga_reset, fpga);
+sysbus_init_mmio(SYS_BUS_DEVICE(s), >iomem);
+}
+
+static void ref405ep_fpga_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc->realize = ref405ep_fpga_realize;
+dc->user_creatable = false;
+dc->reset = ref405ep_fpga_reset;
}
+static const TypeInfo ref405ep_fpga_type = {
+.name = TYPE_PPC405_FPGA,
+.parent = TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(Ppc405FpgaState),
+.class_init = ref405ep_fpga_class_init,
+};
+
/*
* CPU reset handler when booting directly from a loaded kernel
*/
@@ -332,7 +348,11 @@ static void ref405ep_init(MachineState *machine)
memory_region_add_subregion(sysmem, PPC405EP_SRAM_BASE, sram);
/* Register FPGA */
-ref405ep_fpga_init(get_system_memory(), PPC405EP_FPGA_BASE);
+dev = qdev_new(TYPE_PPC405_FPGA);
+object_property_add_child(OBJECT(machine), "fpga", OBJECT(dev));
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, PPC405EP_FPGA_BASE);
+
/* Register NVRAM */
dev = qdev_new("sysbus-m48t08");
qdev_prop_set_int32(dev, "base-year", 1968);
@@ -377,6 +397,7 @@ static void ppc405_machine_init(void)
{
type_register_static(_machine_type);
type_register_static(_type);
+type_register_static(_fpga_type);
}
type_init(ppc405_machine_init)
Re: [PATCH v3 12/22] ppc/ppc405: QOM'ify GPIO
On 8/8/22 16:32, BALATON Zoltan wrote:
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
The GPIO controller is currently modeled as a simple SysBus device
with a unique memory region.
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h | 21 +++
hw/ppc/ppc405_uc.c | 50 +-
2 files changed, 44 insertions(+), 27 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index a5b493d3e7bf..21f6cb358501 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -63,6 +63,26 @@ struct ppc4xx_bd_info_t {
uint32_t bi_iic_fast[2];
};
+/* GPIO */
+#define TYPE_PPC405_GPIO "ppc405-gpio"
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405GpioState, PPC405_GPIO);
+struct Ppc405GpioState {
+ SysBusDevice parent_obj;
+
+ MemoryRegion io;
+ uint32_t or;
+ uint32_t tcr;
+ uint32_t osrh;
+ uint32_t osrl;
+ uint32_t tsrh;
+ uint32_t tsrl;
+ uint32_t odr;
+ uint32_t ir;
+ uint32_t rr1;
+ uint32_t isr1h;
+ uint32_t isr1l;
+};
+
/* On Chip Memory */
#define TYPE_PPC405_OCM "ppc405-ocm"
OBJECT_DECLARE_SIMPLE_TYPE(Ppc405OcmState, PPC405_OCM);
@@ -152,6 +172,7 @@ struct Ppc405SoCState {
Ppc405CpcState cpc;
Ppc405GptState gpt;
Ppc405OcmState ocm;
+ Ppc405GpioState gpio;
};
/* PowerPC 405 core */
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index 961a7c851d4a..768e6909a831 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -713,23 +713,6 @@ static void ppc405_dma_init(CPUPPCState *env, qemu_irq
irqs[4])
}
/*/
-/* GPIO */
-typedef struct ppc405_gpio_t ppc405_gpio_t;
-struct ppc405_gpio_t {
- MemoryRegion io;
- uint32_t or;
- uint32_t tcr;
- uint32_t osrh;
- uint32_t osrl;
- uint32_t tsrh;
- uint32_t tsrl;
- uint32_t odr;
- uint32_t ir;
- uint32_t rr1;
- uint32_t isr1h;
- uint32_t isr1l;
-};
-
static uint64_t ppc405_gpio_read(void *opaque, hwaddr addr, unsigned size)
{
trace_ppc405_gpio_read(addr, size);
@@ -748,20 +731,22 @@ static const MemoryRegionOps ppc405_gpio_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
-static void ppc405_gpio_reset (void *opaque)
+static void ppc405_gpio_realize(DeviceState *dev, Error **errp)
{
+ Ppc405GpioState *s = PPC405_GPIO(dev);
+ SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+
+ memory_region_init_io(>io, OBJECT(s), _gpio_ops, s, "gpio",
+ 0x038);
+ sysbus_init_mmio(sbd, >io);
}
-static void ppc405_gpio_init(hwaddr base)
+static void ppc405_gpio_class_init(ObjectClass *oc, void *data)
{
- ppc405_gpio_t *gpio;
-
- trace_ppc405_gpio_init(base);
Trace gone, update trace-events too.
Yes. I have checked the others.
Thanks,
C.
+ DeviceClass *dc = DEVICE_CLASS(oc);
- gpio = g_new0(ppc405_gpio_t, 1);
- memory_region_init_io(>io, NULL, _gpio_ops, gpio, "pgio",
0x038);
- memory_region_add_subregion(get_system_memory(), base, >io);
- qemu_register_reset(_gpio_reset, gpio);
+ dc->realize = ppc405_gpio_realize;
+ dc->user_creatable = false;
}
/*/
@@ -1405,6 +1390,8 @@ static void ppc405_soc_instance_init(Object *obj)
object_initialize_child(obj, "gpt", >gpt, TYPE_PPC405_GPT);
object_initialize_child(obj, "ocm", >ocm, TYPE_PPC405_OCM);
+
+ object_initialize_child(obj, "gpio", >gpio, TYPE_PPC405_GPIO);
}
static void ppc405_soc_realize(DeviceState *dev, Error **errp)
@@ -1477,8 +1464,12 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
/* I2C controller */
sysbus_create_simple(TYPE_PPC4xx_I2C, 0xef600500,
qdev_get_gpio_in(s->uic, 2));
+
/* GPIO */
- ppc405_gpio_init(0xef600700);
+ if (!sysbus_realize(SYS_BUS_DEVICE(>gpio), errp)) {
+ return;
+ }
+ sysbus_mmio_map(SYS_BUS_DEVICE(>gpio), 0, 0xef600700);
/* Serial ports */
if (serial_hd(0) != NULL) {
@@ -1540,6 +1531,11 @@ static void ppc405_soc_class_init(ObjectClass *oc, void
*data)
static const TypeInfo ppc405_types[] = {
{
+ .name = TYPE_PPC405_GPIO,
+ .parent = TYPE_SYS_BUS_DEVICE,
+ .instance_size = sizeof(Ppc405GpioState),
+ .class_init = ppc405_gpio_class_init,
+ }, {
.name = TYPE_PPC405_OCM,
.parent = TYPE_PPC4xx_DCR_DEVICE,
.instance_size = sizeof(Ppc405OcmState),
Re: [PATCH] contrib/vhost-user-blk: Clean up deallocation of VuVirtqElement
Peter Maydell writes: > On Wed, 27 Jul 2022 at 18:28, Raphael Norwitz > wrote: >> >> On Tue, Jul 26, 2022 at 03:57:42PM +0100, Peter Maydell wrote: >> > On Fri, 1 Jul 2022 at 06:41, Markus Armbruster wrote: >> > > Could we use a contrib/README with an explanation what "contrib" means, >> > > and how to build and use the stuff there? >> > >> > I would rather we got rid of contrib/ entirely. Our git repo >> > should contain things we care about enough to really support >> > and believe in, in which case they should be in top level >> > directories matching what they are (eg tools/). If we don't >> > believe in these things enough to really support them, then >> > we should drop them, and let those who do care maintain them >> > as out-of-tree tools if they like. >> > >> >> I can't speak for a lot of stuff in contrib/ but I find the vhost-user >> backends like vhost-user-blk and vhost-user-scsi helpful for testing and >> development. I would like to keep maintaining those two at least. > > Right, I don't mean we should just delete contrib/, but for the > things currently in it that we do care about, we should define > what their relationship to QEMU is and put them in a part of > the source tree that says what they actually are. contrib/ > just means "nobody thought about it". I split plugins a while ago between: tests/plugin contrib/plugins where the former are really basic plugins that show usage, exercise the API and are included in the check-tcg tests. The contrib plugins are slightly more random mix of useful (e.g. cache, execlog), downright experimental (lockstep) and stuff I can't actually test (e.g. drcov). I'll quite happily continue to process patches that update and enhance contrib/plugins but at a push a few could be promoted to less of a dumping ground (tools/tcg-plugins?). I guess it would only really matter if we were installing plugins as part of "make install"? -- Alex Bennée
Re: [PATCH v3 12/22] ppc/ppc405: QOM'ify GPIO
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
The GPIO controller is currently modeled as a simple SysBus device
with a unique memory region.
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h| 21 +++
hw/ppc/ppc405_uc.c | 50 +-
2 files changed, 44 insertions(+), 27 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index a5b493d3e7bf..21f6cb358501 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -63,6 +63,26 @@ struct ppc4xx_bd_info_t {
uint32_t bi_iic_fast[2];
};
+/* GPIO */
+#define TYPE_PPC405_GPIO "ppc405-gpio"
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405GpioState, PPC405_GPIO);
+struct Ppc405GpioState {
+SysBusDevice parent_obj;
+
+MemoryRegion io;
+uint32_t or;
+uint32_t tcr;
+uint32_t osrh;
+uint32_t osrl;
+uint32_t tsrh;
+uint32_t tsrl;
+uint32_t odr;
+uint32_t ir;
+uint32_t rr1;
+uint32_t isr1h;
+uint32_t isr1l;
+};
+
/* On Chip Memory */
#define TYPE_PPC405_OCM "ppc405-ocm"
OBJECT_DECLARE_SIMPLE_TYPE(Ppc405OcmState, PPC405_OCM);
@@ -152,6 +172,7 @@ struct Ppc405SoCState {
Ppc405CpcState cpc;
Ppc405GptState gpt;
Ppc405OcmState ocm;
+Ppc405GpioState gpio;
};
/* PowerPC 405 core */
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index 961a7c851d4a..768e6909a831 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -713,23 +713,6 @@ static void ppc405_dma_init(CPUPPCState *env, qemu_irq
irqs[4])
}
/*/
-/* GPIO */
-typedef struct ppc405_gpio_t ppc405_gpio_t;
-struct ppc405_gpio_t {
-MemoryRegion io;
-uint32_t or;
-uint32_t tcr;
-uint32_t osrh;
-uint32_t osrl;
-uint32_t tsrh;
-uint32_t tsrl;
-uint32_t odr;
-uint32_t ir;
-uint32_t rr1;
-uint32_t isr1h;
-uint32_t isr1l;
-};
-
static uint64_t ppc405_gpio_read(void *opaque, hwaddr addr, unsigned size)
{
trace_ppc405_gpio_read(addr, size);
@@ -748,20 +731,22 @@ static const MemoryRegionOps ppc405_gpio_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
-static void ppc405_gpio_reset (void *opaque)
+static void ppc405_gpio_realize(DeviceState *dev, Error **errp)
{
+Ppc405GpioState *s = PPC405_GPIO(dev);
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+
+memory_region_init_io(>io, OBJECT(s), _gpio_ops, s, "gpio",
+ 0x038);
+sysbus_init_mmio(sbd, >io);
}
-static void ppc405_gpio_init(hwaddr base)
+static void ppc405_gpio_class_init(ObjectClass *oc, void *data)
{
-ppc405_gpio_t *gpio;
-
-trace_ppc405_gpio_init(base);
Trace gone, update trace-events too.
+DeviceClass *dc = DEVICE_CLASS(oc);
-gpio = g_new0(ppc405_gpio_t, 1);
-memory_region_init_io(>io, NULL, _gpio_ops, gpio, "pgio",
0x038);
-memory_region_add_subregion(get_system_memory(), base, >io);
-qemu_register_reset(_gpio_reset, gpio);
+dc->realize = ppc405_gpio_realize;
+dc->user_creatable = false;
}
/*/
@@ -1405,6 +1390,8 @@ static void ppc405_soc_instance_init(Object *obj)
object_initialize_child(obj, "gpt", >gpt, TYPE_PPC405_GPT);
object_initialize_child(obj, "ocm", >ocm, TYPE_PPC405_OCM);
+
+object_initialize_child(obj, "gpio", >gpio, TYPE_PPC405_GPIO);
}
static void ppc405_soc_realize(DeviceState *dev, Error **errp)
@@ -1477,8 +1464,12 @@ static void ppc405_soc_realize(DeviceState *dev, Error
**errp)
/* I2C controller */
sysbus_create_simple(TYPE_PPC4xx_I2C, 0xef600500,
qdev_get_gpio_in(s->uic, 2));
+
/* GPIO */
-ppc405_gpio_init(0xef600700);
+if (!sysbus_realize(SYS_BUS_DEVICE(>gpio), errp)) {
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(>gpio), 0, 0xef600700);
/* Serial ports */
if (serial_hd(0) != NULL) {
@@ -1540,6 +1531,11 @@ static void ppc405_soc_class_init(ObjectClass *oc, void
*data)
static const TypeInfo ppc405_types[] = {
{
+.name = TYPE_PPC405_GPIO,
+.parent = TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(Ppc405GpioState),
+.class_init = ppc405_gpio_class_init,
+}, {
.name = TYPE_PPC405_OCM,
.parent = TYPE_PPC4xx_DCR_DEVICE,
.instance_size = sizeof(Ppc405OcmState),
Re: [PATCH v3 13/22] ppc/ppc405: QOM'ify DMA
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
The GPIO controller is currently modeled as a DCR device with a couple
It's the DMA already not the GPIU.
Regards,
BALATON Zoltan
of IRQs.
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h| 19 ++
hw/ppc/ppc405_uc.c | 141 -
2 files changed, 81 insertions(+), 79 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 21f6cb358501..c75e4c7cb50a 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -63,6 +63,24 @@ struct ppc4xx_bd_info_t {
uint32_t bi_iic_fast[2];
};
+/* DMA controller */
+#define TYPE_PPC405_DMA "ppc405-dma"
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405DmaState, PPC405_DMA);
+struct Ppc405DmaState {
+Ppc4xxDcrDeviceState parent_obj;
+
+qemu_irq irqs[4];
+uint32_t cr[4];
+uint32_t ct[4];
+uint32_t da[4];
+uint32_t sa[4];
+uint32_t sg[4];
+uint32_t sr;
+uint32_t sgc;
+uint32_t slp;
+uint32_t pol;
+};
+
/* GPIO */
#define TYPE_PPC405_GPIO "ppc405-gpio"
OBJECT_DECLARE_SIMPLE_TYPE(Ppc405GpioState, PPC405_GPIO);
@@ -173,6 +191,7 @@ struct Ppc405SoCState {
Ppc405GptState gpt;
Ppc405OcmState ocm;
Ppc405GpioState gpio;
+Ppc405DmaState dma;
};
/* PowerPC 405 core */
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index 768e6909a831..49405e610dc1 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -613,35 +613,20 @@ enum {
DMA0_POL = 0x126,
};
-typedef struct ppc405_dma_t ppc405_dma_t;
-struct ppc405_dma_t {
-qemu_irq irqs[4];
-uint32_t cr[4];
-uint32_t ct[4];
-uint32_t da[4];
-uint32_t sa[4];
-uint32_t sg[4];
-uint32_t sr;
-uint32_t sgc;
-uint32_t slp;
-uint32_t pol;
-};
-
-static uint32_t dcr_read_dma (void *opaque, int dcrn)
+static uint32_t dcr_read_dma(void *opaque, int dcrn)
{
return 0;
}
-static void dcr_write_dma (void *opaque, int dcrn, uint32_t val)
+static void dcr_write_dma(void *opaque, int dcrn, uint32_t val)
{
}
-static void ppc405_dma_reset (void *opaque)
+static void ppc405_dma_reset(DeviceState *dev)
{
-ppc405_dma_t *dma;
+Ppc405DmaState *dma = PPC405_DMA(dev);
int i;
-dma = opaque;
for (i = 0; i < 4; i++) {
dma->cr[i] = 0x;
dma->ct[i] = 0x;
@@ -655,61 +640,49 @@ static void ppc405_dma_reset (void *opaque)
dma->pol = 0x;
}
-static void ppc405_dma_init(CPUPPCState *env, qemu_irq irqs[4])
+static void ppc405_dma_realize(DeviceState *dev, Error **errp)
+{
+Ppc405DmaState *dma = PPC405_DMA(dev);
+Ppc4xxDcrDeviceState *dcr = PPC4xx_DCR_DEVICE(dev);
+int i;
+
+for (i = 0; i < ARRAY_SIZE(dma->irqs); i++) {
+sysbus_init_irq(SYS_BUS_DEVICE(dma), >irqs[i]);
+}
+
+ppc4xx_dcr_register(dcr, DMA0_CR0, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_CT0, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_DA0, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SA0, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SG0, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_CR1, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_CT1, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_DA1, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SA1, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SG1, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_CR2, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_CT2, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_DA2, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SA2, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SG2, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_CR3, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_CT3, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_DA3, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SA3, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SG3, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SR, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SGC, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_SLP, _read_dma, _write_dma);
+ppc4xx_dcr_register(dcr, DMA0_POL, _read_dma, _write_dma);
+}
+
+static void ppc405_dma_class_init(ObjectClass *oc, void *data)
{
-ppc405_dma_t *dma;
-
-dma = g_new0(ppc405_dma_t, 1);
-memcpy(dma->irqs, irqs, 4 * sizeof(qemu_irq));
-qemu_register_reset(_dma_reset, dma);
-ppc_dcr_register(env, DMA0_CR0,
- dma, _read_dma, _write_dma);
-ppc_dcr_register(env, DMA0_CT0,
- dma, _read_dma, _write_dma);
-ppc_dcr_register(env, DMA0_DA0,
- dma, _read_dma, _write_dma);
-ppc_dcr_register(env, DMA0_SA0,
- dma, _read_dma, _write_dma);
-ppc_dcr_register(env, DMA0_SG0,
- dma, _read_dma, _write_dma);
-
Re: [PATCH 1/5] target/riscv: Ignore the S and U letters when formatting ISA strings
On 07/08/2022 23:53, Alistair Francis wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On Sat, Aug 6, 2022 at 2:08 AM Conor Dooley wrote:
>>
>> From: Palmer Dabbelt
>>
>> The ISA strings we're providing from QEMU aren't actually legal RISC-V
>> ISA strings, as both S and U cannot exist as single-letter extensions
>> and must instead be multi-letter strings. We're still using the ISA
>> strings inside QEMU to track the availiable extensions, so just strip
>> out the S and U extensions when formatting ISA strings.
>>
>> Signed-off-by: Palmer Dabbelt
>> [Conor: rebased on 7.1.0-rc1 & slightly tweaked the commit message]
>> Signed-off-by: Conor Dooley
>> ---
>> target/riscv/cpu.c | 18 +-
>> 1 file changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>> index ac6f82ebd0..95fdc03b3d 100644
>> --- a/target/riscv/cpu.c
>> +++ b/target/riscv/cpu.c
>> @@ -1122,7 +1122,23 @@ char *riscv_isa_string(RISCVCPU *cpu)
>> char *p = isa_str + snprintf(isa_str, maxlen, "rv%d",
>> TARGET_LONG_BITS);
>> for (i = 0; i < sizeof(riscv_single_letter_exts) - 1; i++) {
>> if (cpu->env.misa_ext & RV(riscv_single_letter_exts[i])) {
>> -*p++ = qemu_tolower(riscv_single_letter_exts[i]);
>
> riscv_single_letter_exts doesn't contain S or U, is this patch still required?
Seemingly, yes. This is what ends up in the dtb:
/home/rob/riscv-virt.dtb: cpu@0: riscv,isa:0: 'rv64imafdcsuh' is not one of
['rv64imac', 'rv64imafdc']
From schema:
/home/rob/proj/git/linux-dt/Documentation/devicetree/bindings/riscv/cpus.yaml
With Palmer's patch applied, the dtb's isa string becomes
rv64imafdch_zicsr_zifencei_zba_zbb_zbc_zbs
while in n /proc/cpuinfo it is rv64imafdch
The short_isa_string flag (I think that's it's name) is not
set for the dtb creation. meant to note this under the ---
for this patch but obviously I forgot.
Thanks,
Conor.
>
> Alistair
>
>> +char lower = qemu_tolower(riscv_single_letter_exts[i]);
>> +switch (lower) {
>> +case 's':
>> +case 'u':
>> +/*
>> +* The 's' and 'u' letters shouldn't show up in ISA
>> strings as
>> +* they're not extensions, but they should show up in
>> MISA.
>> +* Since we use these letters interally as a pseudo ISA
>> string
>> +* to set MISA it's easier to just strip them out when
>> +* formatting the ISA string.
>> +*/
>> +break;
>> +
>> +default:
>> +*p++ = lower;
>> +break;
>> +}
>> }
>> }
>> *p = '\0';
>> --
>> 2.37.1
>>
>>
Re: [PATCH v3 10/22] ppc/ppc405: QOM'ify GPT
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
The GPT controller is currently modeled as a SysBus device with a
unique memory region, a couple of IRQs and a timer.
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h| 22
hw/ppc/ppc405_uc.c | 90 +++---
2 files changed, 67 insertions(+), 45 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 2ba829988de2..bcf55e4f6b2e 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -63,6 +63,27 @@ struct ppc4xx_bd_info_t {
uint32_t bi_iic_fast[2];
};
+/* General purpose timers */
+#define TYPE_PPC405_GPT "ppc405-gpt"
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405GptState, PPC405_GPT);
+struct Ppc405GptState {
+SysBusDevice parent_obj;
+
+MemoryRegion iomem;
+
+int64_t tb_offset;
+uint32_t tb_freq;
+QEMUTimer *timer;
+qemu_irq irqs[5];
+uint32_t oe;
+uint32_t ol;
+uint32_t im;
+uint32_t is;
+uint32_t ie;
+uint32_t comp[5];
+uint32_t mask[5];
+};
+
#define TYPE_PPC405_CPC "ppc405-cpc"
OBJECT_DECLARE_SIMPLE_TYPE(Ppc405CpcState, PPC405_CPC);
@@ -114,6 +135,7 @@ struct Ppc405SoCState {
PowerPCCPU cpu;
DeviceState *uic;
Ppc405CpcState cpc;
+Ppc405GptState gpt;
};
/* PowerPC 405 core */
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index e45535b8e52a..f64e661eef6c 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -926,34 +926,18 @@ static void ppc405_ocm_init(CPUPPCState *env)
/*/
/* General purpose timers */
-typedef struct ppc4xx_gpt_t ppc4xx_gpt_t;
-struct ppc4xx_gpt_t {
-MemoryRegion iomem;
-int64_t tb_offset;
-uint32_t tb_freq;
-QEMUTimer *timer;
-qemu_irq irqs[5];
-uint32_t oe;
-uint32_t ol;
-uint32_t im;
-uint32_t is;
-uint32_t ie;
-uint32_t comp[5];
-uint32_t mask[5];
-};
-
-static int ppc4xx_gpt_compare (ppc4xx_gpt_t *gpt, int n)
+static int ppc4xx_gpt_compare(Ppc405GptState *gpt, int n)
{
/* XXX: TODO */
return 0;
}
-static void ppc4xx_gpt_set_output (ppc4xx_gpt_t *gpt, int n, int level)
+static void ppc4xx_gpt_set_output(Ppc405GptState *gpt, int n, int level)
{
/* XXX: TODO */
}
-static void ppc4xx_gpt_set_outputs (ppc4xx_gpt_t *gpt)
+static void ppc4xx_gpt_set_outputs(Ppc405GptState *gpt)
{
uint32_t mask;
int i;
@@ -974,7 +958,7 @@ static void ppc4xx_gpt_set_outputs (ppc4xx_gpt_t *gpt)
}
}
-static void ppc4xx_gpt_set_irqs (ppc4xx_gpt_t *gpt)
+static void ppc4xx_gpt_set_irqs(Ppc405GptState *gpt)
{
uint32_t mask;
int i;
@@ -989,14 +973,14 @@ static void ppc4xx_gpt_set_irqs (ppc4xx_gpt_t *gpt)
}
}
-static void ppc4xx_gpt_compute_timer (ppc4xx_gpt_t *gpt)
+static void ppc4xx_gpt_compute_timer(Ppc405GptState *gpt)
{
/* XXX: TODO */
}
static uint64_t ppc4xx_gpt_read(void *opaque, hwaddr addr, unsigned size)
{
-ppc4xx_gpt_t *gpt = opaque;
+Ppc405GptState *gpt = PPC405_GPT(opaque);
uint32_t ret;
int idx;
@@ -1050,7 +1034,7 @@ static uint64_t ppc4xx_gpt_read(void *opaque, hwaddr
addr, unsigned size)
static void ppc4xx_gpt_write(void *opaque, hwaddr addr, uint64_t value,
unsigned size)
{
-ppc4xx_gpt_t *gpt = opaque;
+Ppc405GptState *gpt = PPC405_GPT(opaque);
int idx;
trace_ppc4xx_gpt_write(addr, size, value);
@@ -1116,20 +1100,18 @@ static const MemoryRegionOps gpt_ops = {
static void ppc4xx_gpt_cb (void *opaque)
{
-ppc4xx_gpt_t *gpt;
+Ppc405GptState *gpt = PPC405_GPT(opaque);
-gpt = opaque;
ppc4xx_gpt_set_irqs(gpt);
ppc4xx_gpt_set_outputs(gpt);
ppc4xx_gpt_compute_timer(gpt);
}
-static void ppc4xx_gpt_reset (void *opaque)
+static void ppc405_gpt_reset(DeviceState *dev)
{
-ppc4xx_gpt_t *gpt;
+Ppc405GptState *gpt = PPC405_GPT(dev);
int i;
-gpt = opaque;
timer_del(gpt->timer);
gpt->oe = 0x;
gpt->ol = 0x;
@@ -1142,21 +1124,28 @@ static void ppc4xx_gpt_reset (void *opaque)
}
}
-static void ppc4xx_gpt_init(hwaddr base, qemu_irq irqs[5])
+static void ppc405_gpt_realize(DeviceState *dev, Error **errp)
{
-ppc4xx_gpt_t *gpt;
+Ppc405GptState *s = PPC405_GPT(dev);
+SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
int i;
-trace_ppc4xx_gpt_init(base);
Where has this trace gone? If you've dropped it then you should also drop
it from trace-events.
+s->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, _gpt_cb, s);
+memory_region_init_io(>iomem, OBJECT(s), _ops, s, "gpt", 0x0d4);
+sysbus_init_mmio(sbd, >iomem);
-gpt = g_new0(ppc4xx_gpt_t, 1);
-for (i = 0; i < 5; i++) {
-gpt->irqs[i] = irqs[i];
+for (i = 0; i < ARRAY_SIZE(s->irqs); i++) {
+sysbus_init_irq(sbd, >irqs[i]);
}
-gpt->timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, _gpt_cb, gpt);
-memory_region_init_io(>iomem, NULL, _ops, gpt, "gpt", 0x0d4);
-
Re: [PULL 0/5] Misc QEMU 7.1 fixes for 2002-08-08
On 08/08/2022 14.57, Paolo Bonzini wrote:
The following changes since commit 3916603e0c1d909e14e09d5ebcbdaa9c9e21adf3:
Merge tag 'pull-la-20220729' of https://gitlab.com/rth7680/qemu into staging
(2022-07-29 17:39:17 -0700)
are available in the Git repository at:
https://gitlab.com/bonzini/qemu.git tags/for-upstream
for you to fetch changes up to f6a5f380627ab2af384bf2f2940d29386dea11ff:
tests/qtest: add scenario for -readconfig handling (2022-08-08 14:54:56
+0200)
* Fix and tests for -readconfig
* Fixes for changeable block size
Daniel P. Berrangé (1):
tests/qtest: add scenario for -readconfig handling
I still had some questions wrt to Daniel's patch, especially there seems to
be a bug ("spcie" instead of "spice"), see:
https://lists.gnu.org/archive/html/qemu-devel/2022-08/msg01153.html
I doubt that this test is working if spice is enabled...
(which leads us to the next question: if the CI did not fail for you, are we
missing a build with spice enabled there?)
Thomas
Re: [PATCH] error handling: Use TFR() macro where applicable
Christian Schoenebeck writes:
> On Montag, 8. August 2022 14:52:28 CEST Christian Schoenebeck wrote:
>> On Montag, 8. August 2022 10:05:56 CEST Markus Armbruster wrote:
>> > Nikita Ivanov writes:
>> > > Summing up the discussion above, I suggest the following patch for TFR()
>> > > macro refactoring. (The patch is sequential to the first one I
>> > > introduced
>> > > in the start of the discussion).
>> > >
>> > >>From 6318bee052900aa93bba6620b53c7cb2290e5001 Mon Sep 17 00:00:00 2001
>> > >>
>> > > From: Nikita Ivanov
>> > > Date: Mon, 8 Aug 2022 09:30:34 +0300
>> > > Subject: [PATCH] Refactoring: rename TFR() to TEMP_FAILURE_RETRY()
>> > >
>> > > glibc's unistd.h header provides the same macro with the
>> > > subtle difference in type casting. Adjust macro name to the
>> > > common standard and define conditionally.
>> > >
>> > > Signed-off-by: Nikita Ivanov
[...]
>> > > diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
>> > > index b1c161c035..55f2927d8b 100644
>> > > --- a/include/qemu/osdep.h
>> > > +++ b/include/qemu/osdep.h
>> > > @@ -242,8 +242,10 @@ void QEMU_ERROR("code path is reachable")
>> > >
>> > > #if !defined(ESHUTDOWN)
>> > > #define ESHUTDOWN 4099
>> > > #endif
>> > >
>> > > -
>> > > -#define TFR(expr) do { if ((expr) != -1) break; } while (errno ==
>> > > EINTR)
>> > > +#if !defined(TEMP_FAILURE_RETRY)
>> > > +#define TEMP_FAILURE_RETRY(expr) \
>> > > +do { if ((expr) != -1) break; } while (errno == EINTR)
To avoid / reduce confusion: this macro expands into a statement, and ...
>> > > +#endif
>> >
>> > GLibc's version is
>> >
>> ># define TEMP_FAILURE_RETRY(expression) \
>> > (__extension__
>> > \
>> >({ long int __result;
>> > \
>> > do __result = (long int) (expression);
>> > \
>> > while (__result == -1L && errno == EINTR);
>> > \
>> > __result; }))
... this one expands into an expression. It uses GCC's "a compound
statement enclosed in parentheses may appear as an expression" extension.
>> >
>> > The difference isn't just "type casting", it's also statement
>> > vs. expression.
>> >
>> > Is it a good idea to have the macro expand into a statement on some
>> > hosts, and into an expression on others? Sure, CI should catch any uses
>> > as expression, but delaying compile errors to CI wastes developer time.
>>
>> For consistency and simplicity, I would define exactly one version (no
>> ifdefs) of the macro with a different macro name than glibc's
>> TEMP_FAILURE_RETRY(), and use that QEMU specific macro name in QEMU code
>> everywhere.
TFR()? Can't resist closing the circle...
>> As for statement vs. expression: The only advantage of the statement version
>> is if you'd need __result as an rvalue, which is not needed ATM, right? So
>> I would go for the expression version (with cast) for now.
The expression-like macro is nicer where the return value matters.
Example (stolen from "The GNU C Library Reference Manual"):
nbytes = TEMP_FAILURE_RETRY (write (desc, buffer, count));
With the statement-like macro, you have to write
TEMP_FAILURE_RETRY (nbytes = write (desc, buffer, count));
>> The glibc history does not reveal why they chose the statement version.
The expression version, actually.
>> Best regards,
>> Christian Schoenebeck
>
> Sorry: s/rvalue/lvalue/ i.e. if you need the memory address of result or if
> you need to take the result value of the last iteration in 'expression' into
> account.
Re: [PATCH v3 09/22] ppc/ppc405: QOM'ify CPC
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
The OCM controller is currently modeled as a DCR device.
What's OCM? Did you mean CPC?
Now that all clock settings are handled at the CPC level, change the
SoC "sys-clk" property to be an alias on the same property in the CPC
model.
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h| 35 -
hw/ppc/ppc405_uc.c | 122 +++--
2 files changed, 86 insertions(+), 71 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 8cc76cc8b3fe..2ba829988de2 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -63,6 +63,39 @@ struct ppc4xx_bd_info_t {
uint32_t bi_iic_fast[2];
};
+#define TYPE_PPC405_CPC "ppc405-cpc"
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405CpcState, PPC405_CPC);
+
+enum {
+PPC405EP_CPU_CLK = 0,
+PPC405EP_PLB_CLK = 1,
+PPC405EP_OPB_CLK = 2,
+PPC405EP_EBC_CLK = 3,
+PPC405EP_MAL_CLK = 4,
+PPC405EP_PCI_CLK = 5,
+PPC405EP_UART0_CLK = 6,
+PPC405EP_UART1_CLK = 7,
+PPC405EP_CLK_NB= 8,
+};
+
+struct Ppc405CpcState {
+Ppc4xxDcrDeviceState parent_obj;
+
+uint32_t sysclk;
+clk_setup_t clk_setup[PPC405EP_CLK_NB];
+uint32_t boot;
+uint32_t epctl;
+uint32_t pllmr[2];
+uint32_t ucr;
+uint32_t srr;
+uint32_t jtagid;
+uint32_t pci;
+/* Clock and power management */
+uint32_t er;
+uint32_t fr;
+uint32_t sr;
+};
+
#define TYPE_PPC405_SOC "ppc405-soc"
OBJECT_DECLARE_SIMPLE_TYPE(Ppc405SoCState, PPC405_SOC);
@@ -78,9 +111,9 @@ struct Ppc405SoCState {
MemoryRegion *dram_mr;
hwaddr ram_size;
-uint32_t sysclk;
PowerPCCPU cpu;
DeviceState *uic;
+Ppc405CpcState cpc;
};
/* PowerPC 405 core */
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index fa3853df2233..e45535b8e52a 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -1178,36 +1178,7 @@ enum {
#endif
};
-enum {
-PPC405EP_CPU_CLK = 0,
-PPC405EP_PLB_CLK = 1,
-PPC405EP_OPB_CLK = 2,
-PPC405EP_EBC_CLK = 3,
-PPC405EP_MAL_CLK = 4,
-PPC405EP_PCI_CLK = 5,
-PPC405EP_UART0_CLK = 6,
-PPC405EP_UART1_CLK = 7,
-PPC405EP_CLK_NB= 8,
-};
-
-typedef struct ppc405ep_cpc_t ppc405ep_cpc_t;
-struct ppc405ep_cpc_t {
-uint32_t sysclk;
-clk_setup_t clk_setup[PPC405EP_CLK_NB];
-uint32_t boot;
-uint32_t epctl;
-uint32_t pllmr[2];
-uint32_t ucr;
-uint32_t srr;
-uint32_t jtagid;
-uint32_t pci;
-/* Clock and power management */
-uint32_t er;
-uint32_t fr;
-uint32_t sr;
-};
-
-static void ppc405ep_compute_clocks (ppc405ep_cpc_t *cpc)
+static void ppc405ep_compute_clocks(Ppc405CpcState *cpc)
{
uint32_t CPU_clk, PLB_clk, OPB_clk, EBC_clk, MAL_clk, PCI_clk;
uint32_t UART0_clk, UART1_clk;
@@ -1302,10 +1273,9 @@ static void ppc405ep_compute_clocks (ppc405ep_cpc_t *cpc)
static uint32_t dcr_read_epcpc (void *opaque, int dcrn)
{
-ppc405ep_cpc_t *cpc;
+Ppc405CpcState *cpc = PPC405_CPC(opaque);
I still think that these callbacks that are registered by the realize
method with an already checked opaque pointer don't need to check it again
here so I'd drop the QOM casts from all these callbacks and assign opaque
directly. Only cast where needed (you're passed a DeviceState, wtc.). But
now that you've introduced ppc4xx_dcr_register it is passed a DcrDevice as
it registers the callbacks with itself. That's wrong, the scr callbacks
could have any opaque data so ppc4xx_dcr_register() should have an opaque
argument (where you pass cpc uin this patch) then drop these casts. Same
for all later patches.
uint32_t ret;
-cpc = opaque;
switch (dcrn) {
case PPC405EP_CPC0_BOOT:
ret = cpc->boot;
@@ -1342,9 +1312,8 @@ static uint32_t dcr_read_epcpc (void *opaque, int dcrn)
static void dcr_write_epcpc (void *opaque, int dcrn, uint32_t val)
{
-ppc405ep_cpc_t *cpc;
+Ppc405CpcState *cpc = PPC405_CPC(opaque);
-cpc = opaque;
switch (dcrn) {
case PPC405EP_CPC0_BOOT:
/* Read-only register */
@@ -1377,9 +1346,9 @@ static void dcr_write_epcpc (void *opaque, int dcrn,
uint32_t val)
}
}
-static void ppc405ep_cpc_reset (void *opaque)
+static void ppc405_cpc_reset(DeviceState *opaque)
{
-ppc405ep_cpc_t *cpc = opaque;
+Ppc405CpcState *cpc = PPC405_CPC(opaque);
cpc->boot = 0x0010; /* Boot from PCI - IIC EEPROM disabled */
cpc->epctl = 0x;
@@ -1391,45 +1360,56 @@ static void ppc405ep_cpc_reset (void *opaque)
cpc->er = 0x;
cpc->fr = 0x;
cpc->sr = 0x;
+cpc->jtagid = 0x20267049;
ppc405ep_compute_clocks(cpc);
}
/* XXX: sysclk should be between 25 and 100 MHz */
-static void ppc405ep_cpc_init (CPUPPCState *env, clk_setup_t clk_setup[8],
- uint32_t sysclk)
+static void ppc405_cpc_realize(DeviceState *dev, Error **errp)
{
-ppc405ep_cpc_t *cpc;
+Ppc405CpcState
Re: [PATCH v3 00/22] ppc: QOM'ify 405 board
On Mon, 8 Aug 2022, Cédric Le Goater wrote: On 8/8/22 14:16, BALATON Zoltan wrote: On Mon, 8 Aug 2022, Cédric Le Goater wrote: Hello, Here is large series QOM'ifying the PPC405 board. It introduces a new generic machine and SoC models, converts the current device models to QOM and populates the SoC. The process is quite mechanical without too much issues to handle. The noisy part is the initial patch introducing the SoC realize routine. What's left ? * the SDRAM mappings are very baroque and certainly could be simplified. I think we should QOMify the ppc440 machines before addressing this part. The issue with SDRAM controller and the likely reason why its model looks so complex is that it can't handle any RAM size because of how the bank sizes are encoded in the registers so it only really supports real RAM modules which are predefined sizes. Also the firmware discovers RAM by looking at SPD data and may only check the slots that the real hardware has which may not be the first one. Previously I had code to round down the memory size specified on the command line to an acceptable size and issue a warning to let the user know but this was dropped because of some changes in code elsewhere which now allocates memory before the machine could check and ajust it so we can only adjust it by wasting some. I don't think we should care adjusting the values. the machine init routine should check that the RAM size is valid or fail. The machine should also have a sane RAM size value by default. See how the aspeed machine deals with similar constraints of its SDRAM controller in aspeed_machine_init(). If the sdram controller does not validate the RAM size, aspeed_sdmc_set_ram_size() fails with an error. Even then we need to check if the specified memory matches one of the allowed sized and distribute it to the allowed banks by the soc. This code is more complex than the 405ep has currently and should not be reprated in each board. That's why we have the ppc4xx_memory_banks and sdram_init functions so while it may be possible to simmplify it a bit maybe not much. I've spent quite some time with it so if you change it check that at least sam360ex -m 2G still works. Regards, BALATON Zoltan
Re: [PATCH v3 05/22] ppc/ppc405: Introduce a PPC405 SoC
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
On 8/8/22 14:43, BALATON Zoltan wrote:
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
It is an initial model to start QOMification of the PPC405 board.
QOM'ified devices will be reintroduced one by one. Start with the
memory regions, which name prefix is changed to "ppc405".
Also, initialize only one RAM bank. The second bank is a dummy one
(zero size) which is here to match the hard coded number of banks in
ppc405ep_init().
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h | 16
hw/ppc/ppc405_boards.c | 23 ---
hw/ppc/ppc405_uc.c | 40
3 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 83f156f585c8..66dc21cdfed8 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -25,6 +25,7 @@
#ifndef PPC405_H
#define PPC405_H
+#include "qom/object.h"
#include "hw/ppc/ppc4xx.h"
#define PPC405EP_SDRAM_BASE 0x
@@ -62,6 +63,21 @@ struct ppc4xx_bd_info_t {
uint32_t bi_iic_fast[2];
};
+#define TYPE_PPC405_SOC "ppc405-soc"
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405SoCState, PPC405_SOC);
+
+struct Ppc405SoCState {
+ /* Private */
+ DeviceState parent_obj;
+
+ /* Public */
+ MemoryRegion ram_banks[2];
+ hwaddr ram_bases[2], ram_sizes[2];
+
+ MemoryRegion *dram_mr;
+ hwaddr ram_size;
+};
+
/* PowerPC 405 core */
ram_addr_t ppc405_set_bootinfo(CPUPPCState *env, ram_addr_t ram_size);
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index c6fa559b03d9..1dc5065fcc1d 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -57,6 +57,8 @@ struct Ppc405MachineState {
/* Private */
MachineState parent_obj;
/* Public */
+
+ Ppc405SoCState soc;
};
/*/
@@ -232,11 +234,10 @@ static void boot_from_kernel(MachineState *machine,
PowerPCCPU *cpu)
static void ppc405_init(MachineState *machine)
{
+ Ppc405MachineState *ppc405 = PPC405_MACHINE(machine);
MachineClass *mc = MACHINE_GET_CLASS(machine);
const char *kernel_filename = machine->kernel_filename;
PowerPCCPU *cpu;
- MemoryRegion *ram_memories = g_new(MemoryRegion, 2);
- hwaddr ram_bases[2], ram_sizes[2];
MemoryRegion *sysmem = get_system_memory();
DeviceState *uicdev;
@@ -247,16 +248,16 @@ static void ppc405_init(MachineState *machine)
exit(EXIT_FAILURE);
}
- /* XXX: fix this */
- memory_region_init_alias(_memories[0], NULL, "ef405ep.ram.alias",
- machine->ram, 0, machine->ram_size);
- ram_bases[0] = 0;
- ram_sizes[0] = machine->ram_size;
- memory_region_init(_memories[1], NULL, "ef405ep.ram1", 0);
- ram_bases[1] = 0x;
- ram_sizes[1] = 0x;
+ object_initialize_child(OBJECT(machine), "soc", >soc,
+ TYPE_PPC405_SOC);
+ object_property_set_uint(OBJECT(>soc), "ram-size",
+ machine->ram_size, _fatal);
+ object_property_set_link(OBJECT(>soc), "dram",
+ OBJECT(machine->ram), _abort);
+ qdev_realize(DEVICE(>soc), NULL, _abort);
- cpu = ppc405ep_init(sysmem, ram_memories, ram_bases, ram_sizes,
+ cpu = ppc405ep_init(sysmem, ppc405->soc.ram_banks,
ppc405->soc.ram_bases,
+ ppc405->soc.ram_sizes,
, , kernel_filename == NULL ? 0 :
1);
/* allocate and load BIOS */
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index d6420c88d3a6..adadb3a0ae08 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -30,6 +30,7 @@
#include "hw/ppc/ppc.h"
#include "hw/i2c/ppc4xx_i2c.h"
#include "hw/irq.h"
+#include "hw/qdev-properties.h"
#include "ppc405.h"
#include "hw/char/serial.h"
#include "qemu/timer.h"
@@ -1530,3 +1531,42 @@ PowerPCCPU *ppc405ep_init(MemoryRegion
*address_space_mem,
return cpu;
}
+
+static void ppc405_soc_realize(DeviceState *dev, Error **errp)
+{
+ Ppc405SoCState *s = PPC405_SOC(dev);
+
+ /* Initialize only one bank */
+ s->ram_bases[0] = 0;
+ s->ram_sizes[0] = s->ram_size;
+ memory_region_init_alias(>ram_banks[0], OBJECT(s),
+ "ppc405.sdram0", s->dram_mr,
+ s->ram_bases[0], s->ram_sizes[0]);
+}
+
+static Property ppc405_soc_properties[] = {
+ DEFINE_PROP_LINK("dram", Ppc405SoCState, dram_mr, TYPE_MEMORY_REGION,
+ MemoryRegion *),
+ DEFINE_PROP_UINT64("ram-size", Ppc405SoCState, ram_size, 0),
+ DEFINE_PROP_END_OF_LIST(),
+};
I'm not sure why we need to duplicate these in the soc if they are always
the same as machine->ram and machine->ram_size.
There are machines with multi SoCs. PowerNV can have 16.
But that's not the reason here, we pass the dram memory region to the SoC
for controllers that might need it for memory transactions, typically
Re: [PATCH v6 3/8] file-posix: introduce get_sysfs_str_val for device zoned model
Stefan Hajnoczi 于2022年8月8日周一 21:52写道：
>
> On Fri, Aug 05, 2022 at 03:57:46PM +0800, Sam Li wrote:
> > Use sysfs attribute files to get the string value of device
> > zoned model. Then get_sysfs_zoned_model can convert it to
> > BlockZoneModel type in QEMU.
> >
> > Signed-off-by: Sam Li
> > Reviewed-by: Hannes Reinecke
> > ---
> > block/file-posix.c | 70
> > include/block/block_int-common.h | 3 ++
> > 2 files changed, 73 insertions(+)
> >
> > diff --git a/block/file-posix.c b/block/file-posix.c
> > index a40eab64a2..4785203eea 100644
> > --- a/block/file-posix.c
> > +++ b/block/file-posix.c
> > @@ -1264,6 +1264,68 @@ out:
> > #endif
> > }
> >
> > +/*
> > + * Convert the zoned attribute file in sysfs to internal value.
> > + */
> > +static int get_sysfs_str_val(int fd, struct stat *st,
> > + const char *attribute,
> > + char **val) {
>
> The fd argument is unused and can be dropped.
>
> > +#ifdef CONFIG_LINUX
> > +char *buf = NULL;
> > +g_autofree char *sysfspath = NULL;
> > +int ret;
> > +size_t len;
> > +
> > +if (!S_ISBLK(st->st_mode)) {
> > +return -ENOTSUP;
> > +}
> > +
> > +sysfspath = g_strdup_printf("/sys/dev/block/%u:%u/queue/%s",
> > +major(st->st_rdev), minor(st->st_rdev),
> > +attribute);
> > +ret = g_file_get_contents(sysfspath, , , NULL);
> > +if (ret == -1) {
> > +ret = -errno;
>
> g_file_get_contents() does not set errno. You can either pass in a
> GError and report the message string by converting it into a QEMU Error
> object (grep for g_file_get_contents() to see example), or you can
> return a fixed error code like -ENOENT.
>
> > +return ret;
> > +}
> > +
> > +/* The file is ended with '\n' */
> > +if (buf[len - 1] == '\n') {
> > +buf[len - 1] = '\0';
> > +}
> > +
> > +if (!strncpy(*val, buf, len)) {
> > +ret = -errno;
> > +return ret;
> > +}
> > +g_free(buf);
>
> buf is not necessary. val can be passed directly to g_file_get_contents().
>
> > +return 0;
> > +#else
> > +return -ENOTSUP;
> > +#endif
> > +}
>
> Now get_sysfs_long_val() can be written using get_sysfs_str_val():
>
> static long get_sysfs_long_val(struct stat *st, const char *attribute)
> {
> g_autofree char *str = NULL;
> const char *end;
> long val;
> int ret;
>
> ret = get_sysfs_str_val(st, attribute, );
> if (ret < 0) {
> return ret;
> }
>
> ret = qemu_strtol(str, , 10, );
> if (ret == 0 && end && *end == '\0') {
> ret = val;
> }
> return ret;
> }
>
> The get_sysfs_long_val() patch can be moved after the
> get_sysfs_str_val() patch.
Cool! Will change it.
> > +
> > +static int get_sysfs_zoned_model(int fd, struct stat *st,
> > + BlockZoneModel *zoned) {
> > +g_autofree char *val = NULL;
> > +val = g_malloc(32);
> > +get_sysfs_str_val(fd, st, "zoned", );
>
> Once get_sysfs_str_val() passes val through to g_get_file_contents() the
> caller will no longer have to g_malloc() val themselves.
Re: [PATCH v6 2/8] file-posix: introduce get_sysfs_long_val for the long sysfs attribute
Stefan Hajnoczi 于2022年8月8日周一 21:52写道：
>
> On Fri, Aug 05, 2022 at 03:57:45PM +0800, Sam Li wrote:
> > Use sysfs attribute files to get the long value of zoned device
> > information.
> >
> > Signed-off-by: Sam Li
> > Reviewed-by: Hannes Reinecke
> > ---
> > block/file-posix.c | 37 +++--
> > 1 file changed, 23 insertions(+), 14 deletions(-)
> >
> > diff --git a/block/file-posix.c b/block/file-posix.c
> > index 48cd096624..a40eab64a2 100644
> > --- a/block/file-posix.c
> > +++ b/block/file-posix.c
> > @@ -1210,29 +1210,27 @@ static int hdev_get_max_hw_transfer(int fd, struct
> > stat *st)
> > #endif
> > }
> >
> > -static int hdev_get_max_segments(int fd, struct stat *st)
> > -{
> > +/*
> > + * Get zoned device information (chunk_sectors, zoned_append_max_bytes,
> > + * max_open_zones, max_active_zones) through sysfs attribute files.
> > + */
> > +static long get_sysfs_long_val(int fd, struct stat *st,
> > + const char *attribute) {
>
> Is the fd argument used or can it be removed?
Yes, it can be removed.
Re: [PATCH v6 8/8] docs/zoned-storage: add zoned device documentation
On Fri, Aug 05, 2022 at 03:57:51PM +0800, Sam Li wrote: > Add the documentation about the zoned device support to virtio-blk > emulation. > > Signed-off-by: Sam Li > --- > docs/devel/zoned-storage.rst | 41 ++ > docs/system/qemu-block-drivers.rst.inc | 6 > 2 files changed, 47 insertions(+) > create mode 100644 docs/devel/zoned-storage.rst > > diff --git a/docs/devel/zoned-storage.rst b/docs/devel/zoned-storage.rst > new file mode 100644 > index 00..c3f1e477ac > --- /dev/null > +++ b/docs/devel/zoned-storage.rst > @@ -0,0 +1,41 @@ > += > +zoned-storage > += > + > +Zoned Block Devices (ZBDs) devide the LBA space into block regions called > zones > +that are larger than the LBA size. It can only allow sequential writes, which > +reduces write amplification in SSDs, leading to higher throughput and > increased > +capacity. More details about ZBDs can be found at: > + > +https://zonedstorage.io/docs/introduction/zoned-storage > + > +1. Block layer APIs for zoned storage > +- > +QEMU block layer has three zoned storage model: > +- BLK_Z_HM: This model only allows sequential writes access. It supports a > set > +of ZBD-specific I/O request that used by the host to manage device zones. > +- BLK_Z_HA: It deals with both sequential writes and random writes access. > +- BLK_Z_NONE: Regular block devices and drive-managed ZBDs are treated as > +non-zoned devices. > + > +The block device information is resided inside BlockDriverState. QEMU uses s/is resided/resides/ > +BlockLimits struct(BlockDriverState::bl) that is continuously accessed by the > +block layer while processing I/O requests. A BlockBackend has a root pointer > to > +a BlockDriverState graph(for example, raw format on top of file-posix). The > +zoned storage information can be propagated from the leaf BlockDriverState > all > +the way up to the BlockBackend. If the zoned storage model in file-posix is > +set to BLK_Z_HM, then block drivers will declare support for zoned host > device. > + > +The block layer APIs support commands needed for zoned storage devices, > +including report zones, four zone operations, and zone append. > + > +2. Emulating zoned storage controllers > +-- > +When the BlockBackend's BlockLimits model reports a zoned storage device, > users > +like the virtio-blk emulation or the qemu-io-cmds.c utility can use block > layer > +APIs for zoned storage emulation or testing. > + > +For example, the command line for zone report testing a null_blk device of > +qemu-io-cmds.c is: > +$ path/to/qemu-io --image-opts driver=zoned_host_device,filename=/dev/nullb0 > -c > +"zrp offset nr_zones" > diff --git a/docs/system/qemu-block-drivers.rst.inc > b/docs/system/qemu-block-drivers.rst.inc > index dfe5d2293d..0b97227fd9 100644 > --- a/docs/system/qemu-block-drivers.rst.inc > +++ b/docs/system/qemu-block-drivers.rst.inc > @@ -430,6 +430,12 @@ Hard disks >you may corrupt your host data (use the ``-snapshot`` command >line option or modify the device permissions accordingly). > > +Zoned block devices > + Zoned block devices can be passed through to the guest if the emulated > storage > + controller supports zoned storage. Use ``--blockdev zoned_host_device, > + node-name=drive0,filename=/dev/nullb0`` to pass through ``/dev/nullb0`` > + as ``drive0``. > + > Windows > ^^^ Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature
Re: [PATCH v6 4/8] block: add block layer APIs resembling Linux ZonedBlockDevice ioctls
On Fri, Aug 05, 2022 at 03:57:47PM +0800, Sam Li wrote:
> By adding zone management operations in BlockDriver, storage controller
> emulation can use the new block layer APIs including Report Zone and
> four zone management operations (open, close, finish, reset).
>
> Add zoned storage commands of the device: zone_report(zrp), zone_open(zo),
> zone_close(zc), zone_reset(zrs), zone_finish(zf).
>
> For example, to test zone_report, use following command:
> $ ./build/qemu-io --image-opts driver=zoned_host_device, filename=/dev/nullb0
> -c "zrp offset nr_zones"
>
> Signed-off-by: Sam Li
> Reviewed-by: Hannes Reinecke
> ---
> block/block-backend.c| 50 +
> block/coroutines.h | 6 +
> block/file-posix.c | 315 ++-
> block/io.c | 41
> include/block/block-common.h | 1 -
> include/block/block-io.h | 13 ++
> include/block/block_int-common.h | 22 ++-
> include/block/raw-aio.h | 6 +-
> meson.build | 1 +
> qapi/block-core.json | 8 +-
> qemu-io-cmds.c | 144 ++
> 11 files changed, 601 insertions(+), 6 deletions(-)
>
> diff --git a/block/block-backend.c b/block/block-backend.c
> index d4a5df2ac2..fc639b0cd7 100644
> --- a/block/block-backend.c
> +++ b/block/block-backend.c
> @@ -1775,6 +1775,56 @@ int coroutine_fn blk_co_flush(BlockBackend *blk)
> return ret;
> }
>
> +/*
> + * Send a zone_report command.
> + * offset is a byte offset from the start of the device. No alignment
> + * required for offset.
> + * nr_zones represents IN maximum and OUT actual.
> + */
> +int coroutine_fn blk_co_zone_report(BlockBackend *blk, int64_t offset,
> +unsigned int *nr_zones,
> +BlockZoneDescriptor *zones)
> +{
> +int ret;
> +IO_CODE();
> +
> +blk_inc_in_flight(blk); /* increase before waiting */
> +blk_wait_while_drained(blk);
> +if (!blk_is_available(blk)) {
> +blk_dec_in_flight(blk);
> +return -ENOMEDIUM;
> +}
> +ret = bdrv_co_zone_report(blk_bs(blk), offset, nr_zones, zones);
> +blk_dec_in_flight(blk);
> +return ret;
> +}
> +
> +/*
> + * Send a zone_management command.
> + * offset is the starting zone specified as a sector offset.
> + * len is the maximum number of sectors the command should operate on.
> + */
> +int coroutine_fn blk_co_zone_mgmt(BlockBackend *blk, BlockZoneOp op,
> +int64_t offset, int64_t len)
> +{
> +int ret;
> +IO_CODE();
> +
> +ret = blk_check_byte_request(blk, offset, len);
> +if (ret < 0) {
> +return ret;
> +}
> +blk_inc_in_flight(blk);
> +blk_wait_while_drained(blk);
> +if (!blk_is_available(blk)) {
> +blk_dec_in_flight(blk);
> +return -ENOMEDIUM;
> +}
> +ret = bdrv_co_zone_mgmt(blk_bs(blk), op, offset, len);
> +blk_dec_in_flight(blk);
> +return ret;
> +}
> +
> void blk_drain(BlockBackend *blk)
> {
> BlockDriverState *bs = blk_bs(blk);
> diff --git a/block/coroutines.h b/block/coroutines.h
> index 3a2bad564f..e3f62d94e5 100644
> --- a/block/coroutines.h
> +++ b/block/coroutines.h
> @@ -63,6 +63,12 @@ nbd_co_do_establish_connection(BlockDriverState *bs, bool
> blocking,
> Error **errp);
>
>
> +int coroutine_fn blk_co_zone_report(BlockBackend *blk, int64_t offset,
> +unsigned int *nr_zones,
> +BlockZoneDescriptor *zones);
> +int coroutine_fn blk_co_zone_mgmt(BlockBackend *blk, BlockZoneOp op,
> + int64_t offset, int64_t len);
> +
> /*
> * "I/O or GS" API functions. These functions can run without
> * the BQL, but only in one specific iothread/main loop.
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 4785203eea..2627431581 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -67,6 +67,9 @@
> #include
> #include
> #include
> +#if defined(CONFIG_BLKZONED)
> +#include
> +#endif
> #include
> #include
> #include
> @@ -216,6 +219,13 @@ typedef struct RawPosixAIOData {
> PreallocMode prealloc;
> Error **errp;
> } truncate;
> +struct {
> +unsigned int *nr_zones;
> +BlockZoneDescriptor *zones;
> +} zone_report;
> +struct {
> +BlockZoneOp op;
> +} zone_mgmt;
> };
> } RawPosixAIOData;
>
> @@ -1369,7 +1379,7 @@ static void raw_refresh_limits(BlockDriverState *bs,
> Error **errp)
> #endif
>
> if (bs->sg || S_ISBLK(st.st_mode)) {
> -int ret = hdev_get_max_hw_transfer(s->fd, );
> +ret = hdev_get_max_hw_transfer(s->fd, );
>
> if (ret > 0 && ret <= BDRV_REQUEST_MAX_BYTES) {
> bs->bl.max_hw_transfer = ret;
> @@ -1386,6 +1396,27 @@ static void
Re: [PATCH v6 6/8] config: add check to block layer
On Fri, Aug 05, 2022 at 03:57:49PM +0800, Sam Li wrote:
> Putting zoned/non-zoned BlockDrivers on top of each other is not
> allowed.
>
> Signed-off-by: Sam Li
> Reviewed-by: Stefan Hajnoczi
> ---
> block.c | 13 +
> block/file-posix.c | 1 +
> block/raw-format.c | 1 +
> include/block/block_int-common.h | 10 ++
> 4 files changed, 25 insertions(+)
>
> diff --git a/block.c b/block.c
> index bc85f46eed..8a259b158c 100644
> --- a/block.c
> +++ b/block.c
> @@ -7947,6 +7947,19 @@ void bdrv_add_child(BlockDriverState *parent_bs,
> BlockDriverState *child_bs,
> return;
> }
>
> +/*
> + * Non-zoned block drivers do not follow zoned storage constraints
> + * (i.e. sequential writes to zones). Refuse mixing zoned and non-zoned
> + * drivers in a graph.
> + */
> +if (!parent_bs->drv->supports_zoned_children && child_bs->drv->is_zoned)
> {
> +error_setg(errp, "Cannot add a %s child to a %s parent",
> + child_bs->drv->is_zoned ? "zoned" : "non-zoned",
> + parent_bs->drv->supports_zoned_children ?
> + "support zoned children" : "not support zoned children");
> +return;
> +}
This doesn't handle the case where a filter node (like I/O throttling)
is inserted above a raw block driver with a zoned_host_device child.
Can we replace child_bs->drv->is_zoned with child_bs->bl.zoned ==
BLK_Z_HM? I think the is_zoned field is unnecessary.
That way the block/raw-format.c .bdrv_refresh_limits() function can
propagate its child's zone block limits (including the zone model) and
this check will work correctly.
Stefan
signature.asc
Description: PGP signature
Re: [PATCH v6 3/8] file-posix: introduce get_sysfs_str_val for device zoned model
On Fri, Aug 05, 2022 at 03:57:46PM +0800, Sam Li wrote:
> Use sysfs attribute files to get the string value of device
> zoned model. Then get_sysfs_zoned_model can convert it to
> BlockZoneModel type in QEMU.
>
> Signed-off-by: Sam Li
> Reviewed-by: Hannes Reinecke
> ---
> block/file-posix.c | 70
> include/block/block_int-common.h | 3 ++
> 2 files changed, 73 insertions(+)
>
> diff --git a/block/file-posix.c b/block/file-posix.c
> index a40eab64a2..4785203eea 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -1264,6 +1264,68 @@ out:
> #endif
> }
>
> +/*
> + * Convert the zoned attribute file in sysfs to internal value.
> + */
> +static int get_sysfs_str_val(int fd, struct stat *st,
> + const char *attribute,
> + char **val) {
The fd argument is unused and can be dropped.
> +#ifdef CONFIG_LINUX
> +char *buf = NULL;
> +g_autofree char *sysfspath = NULL;
> +int ret;
> +size_t len;
> +
> +if (!S_ISBLK(st->st_mode)) {
> +return -ENOTSUP;
> +}
> +
> +sysfspath = g_strdup_printf("/sys/dev/block/%u:%u/queue/%s",
> +major(st->st_rdev), minor(st->st_rdev),
> +attribute);
> +ret = g_file_get_contents(sysfspath, , , NULL);
> +if (ret == -1) {
> +ret = -errno;
g_file_get_contents() does not set errno. You can either pass in a
GError and report the message string by converting it into a QEMU Error
object (grep for g_file_get_contents() to see example), or you can
return a fixed error code like -ENOENT.
> +return ret;
> +}
> +
> +/* The file is ended with '\n' */
> +if (buf[len - 1] == '\n') {
> +buf[len - 1] = '\0';
> +}
> +
> +if (!strncpy(*val, buf, len)) {
> +ret = -errno;
> +return ret;
> +}
> +g_free(buf);
buf is not necessary. val can be passed directly to g_file_get_contents().
> +return 0;
> +#else
> +return -ENOTSUP;
> +#endif
> +}
Now get_sysfs_long_val() can be written using get_sysfs_str_val():
static long get_sysfs_long_val(struct stat *st, const char *attribute)
{
g_autofree char *str = NULL;
const char *end;
long val;
int ret;
ret = get_sysfs_str_val(st, attribute, );
if (ret < 0) {
return ret;
}
ret = qemu_strtol(str, , 10, );
if (ret == 0 && end && *end == '\0') {
ret = val;
}
return ret;
}
The get_sysfs_long_val() patch can be moved after the
get_sysfs_str_val() patch.
> +
> +static int get_sysfs_zoned_model(int fd, struct stat *st,
> + BlockZoneModel *zoned) {
> +g_autofree char *val = NULL;
> +val = g_malloc(32);
> +get_sysfs_str_val(fd, st, "zoned", );
Once get_sysfs_str_val() passes val through to g_get_file_contents() the
caller will no longer have to g_malloc() val themselves.
signature.asc
Description: PGP signature
Re: [PATCH v6 2/8] file-posix: introduce get_sysfs_long_val for the long sysfs attribute
On Fri, Aug 05, 2022 at 03:57:45PM +0800, Sam Li wrote:
> Use sysfs attribute files to get the long value of zoned device
> information.
>
> Signed-off-by: Sam Li
> Reviewed-by: Hannes Reinecke
> ---
> block/file-posix.c | 37 +++--
> 1 file changed, 23 insertions(+), 14 deletions(-)
>
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 48cd096624..a40eab64a2 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -1210,29 +1210,27 @@ static int hdev_get_max_hw_transfer(int fd, struct
> stat *st)
> #endif
> }
>
> -static int hdev_get_max_segments(int fd, struct stat *st)
> -{
> +/*
> + * Get zoned device information (chunk_sectors, zoned_append_max_bytes,
> + * max_open_zones, max_active_zones) through sysfs attribute files.
> + */
> +static long get_sysfs_long_val(int fd, struct stat *st,
> + const char *attribute) {
Is the fd argument used or can it be removed?
Other than that:
Reviewed-by: Stefan Hajnoczi
signature.asc
Description: PGP signature
Re: [PATCH v3 05/22] ppc/ppc405: Introduce a PPC405 SoC
On 8/8/22 14:43, BALATON Zoltan wrote:
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
It is an initial model to start QOMification of the PPC405 board.
QOM'ified devices will be reintroduced one by one. Start with the
memory regions, which name prefix is changed to "ppc405".
Also, initialize only one RAM bank. The second bank is a dummy one
(zero size) which is here to match the hard coded number of banks in
ppc405ep_init().
Reviewed-by: Daniel Henrique Barboza
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405.h | 16
hw/ppc/ppc405_boards.c | 23 ---
hw/ppc/ppc405_uc.c | 40
3 files changed, 68 insertions(+), 11 deletions(-)
diff --git a/hw/ppc/ppc405.h b/hw/ppc/ppc405.h
index 83f156f585c8..66dc21cdfed8 100644
--- a/hw/ppc/ppc405.h
+++ b/hw/ppc/ppc405.h
@@ -25,6 +25,7 @@
#ifndef PPC405_H
#define PPC405_H
+#include "qom/object.h"
#include "hw/ppc/ppc4xx.h"
#define PPC405EP_SDRAM_BASE 0x
@@ -62,6 +63,21 @@ struct ppc4xx_bd_info_t {
uint32_t bi_iic_fast[2];
};
+#define TYPE_PPC405_SOC "ppc405-soc"
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc405SoCState, PPC405_SOC);
+
+struct Ppc405SoCState {
+ /* Private */
+ DeviceState parent_obj;
+
+ /* Public */
+ MemoryRegion ram_banks[2];
+ hwaddr ram_bases[2], ram_sizes[2];
+
+ MemoryRegion *dram_mr;
+ hwaddr ram_size;
+};
+
/* PowerPC 405 core */
ram_addr_t ppc405_set_bootinfo(CPUPPCState *env, ram_addr_t ram_size);
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index c6fa559b03d9..1dc5065fcc1d 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -57,6 +57,8 @@ struct Ppc405MachineState {
/* Private */
MachineState parent_obj;
/* Public */
+
+ Ppc405SoCState soc;
};
/*/
@@ -232,11 +234,10 @@ static void boot_from_kernel(MachineState *machine,
PowerPCCPU *cpu)
static void ppc405_init(MachineState *machine)
{
+ Ppc405MachineState *ppc405 = PPC405_MACHINE(machine);
MachineClass *mc = MACHINE_GET_CLASS(machine);
const char *kernel_filename = machine->kernel_filename;
PowerPCCPU *cpu;
- MemoryRegion *ram_memories = g_new(MemoryRegion, 2);
- hwaddr ram_bases[2], ram_sizes[2];
MemoryRegion *sysmem = get_system_memory();
DeviceState *uicdev;
@@ -247,16 +248,16 @@ static void ppc405_init(MachineState *machine)
exit(EXIT_FAILURE);
}
- /* XXX: fix this */
- memory_region_init_alias(_memories[0], NULL, "ef405ep.ram.alias",
- machine->ram, 0, machine->ram_size);
- ram_bases[0] = 0;
- ram_sizes[0] = machine->ram_size;
- memory_region_init(_memories[1], NULL, "ef405ep.ram1", 0);
- ram_bases[1] = 0x;
- ram_sizes[1] = 0x;
+ object_initialize_child(OBJECT(machine), "soc", >soc,
+ TYPE_PPC405_SOC);
+ object_property_set_uint(OBJECT(>soc), "ram-size",
+ machine->ram_size, _fatal);
+ object_property_set_link(OBJECT(>soc), "dram",
+ OBJECT(machine->ram), _abort);
+ qdev_realize(DEVICE(>soc), NULL, _abort);
- cpu = ppc405ep_init(sysmem, ram_memories, ram_bases, ram_sizes,
+ cpu = ppc405ep_init(sysmem, ppc405->soc.ram_banks, ppc405->soc.ram_bases,
+ ppc405->soc.ram_sizes,
, , kernel_filename == NULL ? 0 : 1);
/* allocate and load BIOS */
diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index d6420c88d3a6..adadb3a0ae08 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -30,6 +30,7 @@
#include "hw/ppc/ppc.h"
#include "hw/i2c/ppc4xx_i2c.h"
#include "hw/irq.h"
+#include "hw/qdev-properties.h"
#include "ppc405.h"
#include "hw/char/serial.h"
#include "qemu/timer.h"
@@ -1530,3 +1531,42 @@ PowerPCCPU *ppc405ep_init(MemoryRegion
*address_space_mem,
return cpu;
}
+
+static void ppc405_soc_realize(DeviceState *dev, Error **errp)
+{
+ Ppc405SoCState *s = PPC405_SOC(dev);
+
+ /* Initialize only one bank */
+ s->ram_bases[0] = 0;
+ s->ram_sizes[0] = s->ram_size;
+ memory_region_init_alias(>ram_banks[0], OBJECT(s),
+ "ppc405.sdram0", s->dram_mr,
+ s->ram_bases[0], s->ram_sizes[0]);
+}
+
+static Property ppc405_soc_properties[] = {
+ DEFINE_PROP_LINK("dram", Ppc405SoCState, dram_mr, TYPE_MEMORY_REGION,
+ MemoryRegion *),
+ DEFINE_PROP_UINT64("ram-size", Ppc405SoCState, ram_size, 0),
+ DEFINE_PROP_END_OF_LIST(),
+};
I'm not sure why we need to duplicate these in the soc if they are always the same as machine->ram and machine->ram_size.
There are machines with multi SoCs. PowerNV can have 16.
But that's not the reason here, we pass the dram memory region to the SoC
for controllers that might need it for memory transactions, typically DMAs.
In this case, it's the SDRAM controller which
Re: [PATCH v3 04/22] ppc/ppc405: Move SRAM under the ref405ep machine
On 8/8/22 14:25, BALATON Zoltan wrote:
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
It doesn't belong to the generic machine nor the SoC.
Signed-off-by: Cédric Le Goater
---
hw/ppc/ppc405_boards.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/ppc405_boards.c b/hw/ppc/ppc405_boards.c
index f4794ba40ce6..c6fa559b03d9 100644
--- a/hw/ppc/ppc405_boards.c
+++ b/hw/ppc/ppc405_boards.c
@@ -235,7 +235,6 @@ static void ppc405_init(MachineState *machine)
MachineClass *mc = MACHINE_GET_CLASS(machine);
const char *kernel_filename = machine->kernel_filename;
PowerPCCPU *cpu;
- MemoryRegion *sram = g_new(MemoryRegion, 1);
MemoryRegion *ram_memories = g_new(MemoryRegion, 2);
hwaddr ram_bases[2], ram_sizes[2];
MemoryRegion *sysmem = get_system_memory();
@@ -260,11 +259,6 @@ static void ppc405_init(MachineState *machine)
cpu = ppc405ep_init(sysmem, ram_memories, ram_bases, ram_sizes,
, , kernel_filename == NULL ? 0 : 1);
- /* allocate SRAM */
- memory_region_init_ram(sram, NULL, "ef405ep.sram", PPC405EP_SRAM_SIZE,
- _fatal);
- memory_region_add_subregion(sysmem, PPC405EP_SRAM_BASE, sram);
-
/* allocate and load BIOS */
if (machine->firmware) {
MemoryRegion *bios = g_new(MemoryRegion, 1);
@@ -328,9 +322,16 @@ static void ref405ep_init(MachineState *machine)
{
DeviceState *dev;
SysBusDevice *s;
+ MemoryRegion *sram = g_new(MemoryRegion, 1);
+ MemoryRegion *sysmem = get_system_memory();
You could drop thi "system" local and just use get_system_memory() in
add_subregion
Yes. Let's drop it.
Thanks,
C.
ppc405_init(machine);
+ /* allocate SRAM */
+ memory_region_init_ram(sram, NULL, "ef405ep.sram", PPC405EP_SRAM_SIZE,
+ _fatal);
+ memory_region_add_subregion(sysmem, PPC405EP_SRAM_BASE, sram);
+
/* Register FPGA */
ref405ep_fpga_init(get_system_memory(), PPC405EP_FPGA_BASE);
or use it everywhere consistently.
Regards,
BALATON Zoltan
/* Register NVRAM */
Re: [PATCH v3 08/22] ppc/ppc4xx: Introduce a DCR device model
On Mon, 8 Aug 2022, Cédric Le Goater wrote:
The Device Control Registers (DCR) of on-SoC devices are accessed by
software through the use of the mtdcr and mfdcr instructions. These
are converted in transactions on a side band bus, the DCR bus, which
connects the on-SoC devices to the CPU.
Ideally, we should model these accesses with a DCR namespace and DCR
memory regions but today the DCR handlers are installed in a DCR table
under the CPU. Instead introduce a little device model wrapper to hold
a CPU link and handle registration of DCR handlers.
The DCR device inherits from SysBus because most of these devices also
have a MMIO regions and/or IRQs. Being a SysBusDevice makes things
Drop "a", just "MMIO regions" due to plural. Also "makes it easier to
install" or "makes things easier".
easier to install the device model in the overall SoC.
The "cpu" link should be considered as modeling the piece of HW logic
connecting the device to the DCR bus.
Signed-off-by: Cédric Le Goater
---
include/hw/ppc/ppc4xx.h | 17 +++
hw/ppc/ppc4xx_devs.c| 46 +
2 files changed, 63 insertions(+)
diff --git a/include/hw/ppc/ppc4xx.h b/include/hw/ppc/ppc4xx.h
index 021376c2d260..bb373db0ba10 100644
--- a/include/hw/ppc/ppc4xx.h
+++ b/include/hw/ppc/ppc4xx.h
@@ -27,6 +27,7 @@
#include "hw/ppc/ppc.h"
#include "exec/memory.h"
+#include "hw/sysbus.h"
/* PowerPC 4xx core initialization */
void ppc4xx_reset(void *opaque);
@@ -50,4 +51,20 @@ void ppc4xx_mal_init(CPUPPCState *env, uint8_t txcnum,
uint8_t rxcnum,
#define TYPE_PPC4xx_PCI_HOST_BRIDGE "ppc4xx-pcihost"
+/*
+ * Generic DCR device
+ */
+#define TYPE_PPC4xx_DCR_DEVICE "ppc4xx-dcr"
Should it be named ppc4xx-dcr-device for clarity? This probably won't
appear anywhere where users have to type it.
+OBJECT_DECLARE_SIMPLE_TYPE(Ppc4xxDcrDeviceState, PPC4xx_DCR_DEVICE);
+struct Ppc4xxDcrDeviceState {
+SysBusDevice parent_obj;
+
+PowerPCCPU *cpu;
+};
+
+void ppc4xx_dcr_register(Ppc4xxDcrDeviceState *dev, int dcrn,
+ dcr_read_cb dcr_read, dcr_write_cb dcr_write);
+bool ppc4xx_dcr_realize(Ppc4xxDcrDeviceState *dev, PowerPCCPU *cpu,
+Error **errp);
+
#endif /* PPC4XX_H */
diff --git a/hw/ppc/ppc4xx_devs.c b/hw/ppc/ppc4xx_devs.c
index f20098cf417c..e07bdba0f912 100644
--- a/hw/ppc/ppc4xx_devs.c
+++ b/hw/ppc/ppc4xx_devs.c
@@ -696,3 +696,49 @@ void ppc4xx_mal_init(CPUPPCState *env, uint8_t txcnum,
uint8_t rxcnum,
mal, _read_mal, _write_mal);
}
}
+
+void ppc4xx_dcr_register(Ppc4xxDcrDeviceState *dev, int dcrn,
+ dcr_read_cb dcr_read, dcr_write_cb dcr_write)
+{
+CPUPPCState *env;
+
+assert(dev->cpu);
+
+env = >cpu->env;
+
+ppc_dcr_register(env, dcrn, dev, dcr_read, dcr_write);
+}
+
+bool ppc4xx_dcr_realize(Ppc4xxDcrDeviceState *dev, PowerPCCPU *cpu,
+Error **errp)
+{
+object_property_set_link(OBJECT(dev), "cpu", OBJECT(cpu), _abort);
+return sysbus_realize(SYS_BUS_DEVICE(dev), errp);
+}
+
+
+static Property ppc4xx_dcr_properties[] = {
+DEFINE_PROP_LINK("cpu", Ppc4xxDcrDeviceState, cpu, TYPE_POWERPC_CPU,
+ PowerPCCPU *),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void ppc4xx_dcr_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc->user_creatable = false;
Should this be .abstract instead? We expect this to not be used directly
but only via SoC devices which is what abstract is for AFAIK.
+device_class_set_props(dc, ppc4xx_dcr_properties);
+}
+
+static const TypeInfo ppc4xx_types[] = {
+{
+.name = TYPE_PPC4xx_DCR_DEVICE,
+.parent = TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(Ppc4xxDcrDeviceState),
+.class_init = ppc4xx_dcr_class_init,
+.abstract = true,
Oh, it's abstract already. So does it also need user_creatable for an
abstract class then? Maybe you can drop the user_creatable.
Regards,
BALATON Zoltan
+}
+};
+
+DEFINE_TYPES(ppc4xx_types)
