[PULL 2/3] Reduce the PVM stop time during Checkpoint
From: "Rao, Lei"
When flushing memory from ram cache to ram during every checkpoint
on secondary VM, we can copy continuous chunks of memory instead of
4096 bytes per time to reduce the time of VM stop during checkpoint.
Signed-off-by: Lei Rao
Reviewed-by: Dr. David Alan Gilbert
Reviewed-by: Lukas Straub
Reviewed-by: Juan Quintela
Tested-by: Lukas Straub
Signed-off-by: Juan Quintela
---
migration/ram.c | 48 +---
1 file changed, 45 insertions(+), 3 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 847af461f2..f48cf4b0a5 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -836,6 +836,41 @@ migration_clear_memory_region_dirty_bitmap_range(RAMBlock
*rb,
}
}
+/*
+ * colo_bitmap_find_diry:find contiguous dirty pages from start
+ *
+ * Returns the page offset within memory region of the start of the contiguout
+ * dirty page
+ *
+ * @rs: current RAM state
+ * @rb: RAMBlock where to search for dirty pages
+ * @start: page where we start the search
+ * @num: the number of contiguous dirty pages
+ */
+static inline
+unsigned long colo_bitmap_find_dirty(RAMState *rs, RAMBlock *rb,
+ unsigned long start, unsigned long *num)
+{
+unsigned long size = rb->used_length >> TARGET_PAGE_BITS;
+unsigned long *bitmap = rb->bmap;
+unsigned long first, next;
+
+*num = 0;
+
+if (ramblock_is_ignored(rb)) {
+return size;
+}
+
+first = find_next_bit(bitmap, size, start);
+if (first >= size) {
+return first;
+}
+next = find_next_zero_bit(bitmap, size, first + 1);
+assert(next >= first);
+*num = next - first;
+return first;
+}
+
static inline bool migration_bitmap_clear_dirty(RAMState *rs,
RAMBlock *rb,
unsigned long page)
@@ -3886,19 +3921,26 @@ void colo_flush_ram_cache(void)
block = QLIST_FIRST_RCU(&ram_list.blocks);
while (block) {
-offset = migration_bitmap_find_dirty(ram_state, block, offset);
+unsigned long num = 0;
+offset = colo_bitmap_find_dirty(ram_state, block, offset, &num);
if (!offset_in_ramblock(block,
((ram_addr_t)offset) << TARGET_PAGE_BITS))
{
offset = 0;
+num = 0;
block = QLIST_NEXT_RCU(block, next);
} else {
-migration_bitmap_clear_dirty(ram_state, block, offset);
+unsigned long i = 0;
+
+for (i = 0; i < num; i++) {
+migration_bitmap_clear_dirty(ram_state, block, offset + i);
+}
dst_host = block->host
+ (((ram_addr_t)offset) << TARGET_PAGE_BITS);
src_host = block->colo_cache
+ (((ram_addr_t)offset) << TARGET_PAGE_BITS);
-memcpy(dst_host, src_host, TARGET_PAGE_SIZE);
+memcpy(dst_host, src_host, TARGET_PAGE_SIZE * num);
+offset += num;
}
}
}
--
2.33.1
[PULL 0/3] Migration 20211109 patches
The following changes since commit 114f3c8cc427333dbae331dfd2ecae64676b087e: Merge remote-tracking branch 'remotes/philmd/tags/avocado-20211108' into staging (2021-11-08 18:50:09 +0100) are available in the Git repository at: https://github.com/juanquintela/qemu.git tags/migration-20211109-pull-request for you to fetch changes up to 91fe9a8dbd449a2f333aefb82ec8adb1f6424408: Reset the auto-converge counter at every checkpoint. (2021-11-09 08:48:36 +0100) Migration Pull request Hi This pull request includes: - fix sample-pages doc by hyman - cleanup colo pages by contiguous blocks by Rao - reset auto-converge by checkpoint by Rao. Please, apply. Hyman Huang(黄勇) (1): docs: fix 'sample-pages' option tag Rao, Lei (2): Reduce the PVM stop time during Checkpoint Reset the auto-converge counter at every checkpoint. qapi/migration.json | 2 +- migration/ram.h | 1 + migration/colo.c| 4 migration/ram.c | 57 ++--- 4 files changed, 60 insertions(+), 4 deletions(-) -- 2.33.1
[PULL 3/3] Reset the auto-converge counter at every checkpoint.
From: "Rao, Lei"
if we don't reset the auto-converge counter,
it will continue to run with COLO running,
and eventually the system will hang due to the
CPU throttle reaching DEFAULT_MIGRATE_MAX_CPU_THROTTLE.
Signed-off-by: Lei Rao
Reviewed-by: Dr. David Alan Gilbert
Reviewed-by: Lukas Straub
Tested-by: Lukas Straub
Reviewed-by: Juan Quintela
Signed-off-by: Juan Quintela
---
migration/ram.h | 1 +
migration/colo.c | 4
migration/ram.c | 9 +
3 files changed, 14 insertions(+)
diff --git a/migration/ram.h b/migration/ram.h
index dda1988f3d..c515396a9a 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -50,6 +50,7 @@ bool ramblock_is_ignored(RAMBlock *block);
int xbzrle_cache_resize(uint64_t new_size, Error **errp);
uint64_t ram_bytes_remaining(void);
uint64_t ram_bytes_total(void);
+void mig_throttle_counter_reset(void);
uint64_t ram_pagesize_summary(void);
int ram_save_queue_pages(const char *rbname, ram_addr_t start, ram_addr_t len);
diff --git a/migration/colo.c b/migration/colo.c
index e3b1f136f4..2415325262 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -459,6 +459,10 @@ static int colo_do_checkpoint_transaction(MigrationState
*s,
if (ret < 0) {
goto out;
}
+
+if (migrate_auto_converge()) {
+mig_throttle_counter_reset();
+}
/*
* Only save VM's live state, which not including device state.
* TODO: We may need a timeout mechanism to prevent COLO process
diff --git a/migration/ram.c b/migration/ram.c
index f48cf4b0a5..863035d235 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -641,6 +641,15 @@ static void mig_throttle_guest_down(uint64_t
bytes_dirty_period,
}
}
+void mig_throttle_counter_reset(void)
+{
+RAMState *rs = ram_state;
+
+rs->time_last_bitmap_sync = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
+rs->num_dirty_pages_period = 0;
+rs->bytes_xfer_prev = ram_counters.transferred;
+}
+
/**
* xbzrle_cache_zero_page: insert a zero page in the XBZRLE cache
*
--
2.33.1
[PULL 1/3] docs: fix 'sample-pages' option tag
From: Hyman Huang(黄勇) commit f78d4ed701 has fixed qemu tag, making 'sample-pages' option tag involved by accident, which introduced since 6.1 in commit 7afa08cd8fd. revert this line. Signed-off-by: Hyman Huang(黄勇) Reviewed-by: Markus Armbruster Reviewed-by: Juan Quintela Signed-off-by: Juan Quintela --- qapi/migration.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/qapi/migration.json b/qapi/migration.json index f0aefdab64..bbfd48cf0b 100644 --- a/qapi/migration.json +++ b/qapi/migration.json @@ -1796,7 +1796,7 @@ # @calc-time: time in units of second for sample dirty pages # # @sample-pages: page count per GB for sample dirty pages -#the default value is 512 (since 6.2) +#the default value is 512 (since 6.1) # # @mode: mode containing method of calculate dirtyrate includes #'page-sampling' and 'dirty-ring' (Since 6.2) -- 2.33.1
Re: [PATCH 09/13] target/riscv: Adjust vector address with ol
On 2021/11/9 下午2:37, Richard Henderson wrote:
On 11/8/21 10:28 AM, LIU Zhiwei wrote:
On 2021/11/1 下午7:35, Richard Henderson wrote:
On 11/1/21 6:01 AM, LIU Zhiwei wrote:
Signed-off-by: LIU Zhiwei
---
target/riscv/insn_trans/trans_rvv.c.inc | 8
target/riscv/internals.h | 1 +
target/riscv/vector_helper.c | 54
+
3 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/target/riscv/insn_trans/trans_rvv.c.inc
b/target/riscv/insn_trans/trans_rvv.c.inc
index ed042f7bb9..5cd9b802df 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -233,6 +233,7 @@ static bool ld_us_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_us_trans(a->rd, a->rs1, data, fn, s);
}
@@ -286,6 +287,7 @@ static bool st_us_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_us_trans(a->rd, a->rs1, data, fn, s);
}
@@ -365,6 +367,7 @@ static bool ld_stride_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_stride_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -404,6 +407,7 @@ static bool st_stride_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
fn = fns[seq][s->sew];
if (fn == NULL) {
return false;
@@ -490,6 +494,7 @@ static bool ld_index_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_index_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -542,6 +547,7 @@ static bool st_index_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_index_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -617,6 +623,7 @@ static bool ldff_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldff_trans(a->rd, a->rs1, data, fn, s);
}
@@ -724,6 +731,7 @@ static bool amo_op(DisasContext *s, arg_rwdvm
*a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, WD, a->wd);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return amo_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
/*
diff --git a/target/riscv/internals.h b/target/riscv/internals.h
index b15ad394bb..f74b8291e4 100644
--- a/target/riscv/internals.h
+++ b/target/riscv/internals.h
@@ -27,6 +27,7 @@ FIELD(VDATA, VM, 8, 1)
FIELD(VDATA, LMUL, 9, 2)
FIELD(VDATA, NF, 11, 4)
FIELD(VDATA, WD, 11, 1)
+FIELD(VDATA, OL, 15, 2)
/* float point classify helpers */
target_ulong fclass_h(uint64_t frs1);
diff --git a/target/riscv/vector_helper.c
b/target/riscv/vector_helper.c
index 535420ee66..451688c328 100644
--- a/target/riscv/vector_helper.c
+++ b/target/riscv/vector_helper.c
@@ -112,6 +112,11 @@ static uint32_t vext_wd(uint32_t desc)
return (simd_data(desc) >> 11) & 0x1;
}
+static inline uint32_t vext_ol(uint32_t desc)
+{
+ return FIELD_EX32(simd_data(desc), VDATA, OL);
+}
XLEN not OLEN.
OK.
@@ -123,6 +128,14 @@ static inline uint32_t vext_maxsz(uint32_t desc)
return simd_maxsz(desc) << vext_lmul(desc);
}
+static inline target_ulong adjust_addr(target_ulong addr,
uint32_t olen)
+{
+ if (olen < TARGET_LONG_BITS) {
+ addr &= UINT32_MAX;
+ }
+ return addr;
+}
Here's where I'm unsure. This looks a lot like the changes that are
required to support pointer-masking in vectors, which Alexey said he
was going to look at.
(1) Do we need to pass anything in VEXT at all?
We do have CPURISCVState, so we could just use cpu_get_ml,
Yes, we should use cpu_get_xl.
which we would also need for env->mmte etc for pointer masking.
Do
Re: [RFC 4/4] common-user: Allow return codes to be adjusted after sytsem call
On 11/8/21 7:49 PM, Warner Losh wrote: > /* code path for having successfully executed the syscall */ > + ADJUST_SYSCALL_RETCODE > ret > > 0: Not sure about this, really. Is it really that much cleaner to insert this than create separate 10-line files, with the adjustment included? ... The adjustments have all been 3 lines (gmail seems to hate my formatting): +#define ADJUST_SYSCALL_RETCODE \ + jnb 2f; \ + neg %rax; \ + 2: which is significantly easier to maintain than having to monitor these files for changes and copying over the changes that happen. ... The other alternative I considered was having a #ifdef __FreeBSD__ .. #endif in all those files, but I thought that even more intrusive. Actually, the ifdef sounds surprisingly attractive to me. Is it ENOCOFFEE? What I find awkward about ADJUST_SYSCALL_RETCODE is that when you're looking at the definition, you have no reference to the context, and vice versa. Not that it can't be worked out, but it seems like the same amount of code either way, and clearer when it's together. We've already split the host cpu apart, which is the major point of ifdeffery, so it doesn't seem like we'll wind up with a large amount of ifdefs here; we're not likely to see mynewos-user wanting to share this code any time soon. I feel sufficiently fuzzy on this to solicit other opinions though. r~
Re: [PATCH 09/13] target/riscv: Adjust vector address with ol
On 11/9/21 9:04 AM, LIU Zhiwei wrote:
On 2021/11/9 下午2:37, Richard Henderson wrote:
On 11/8/21 10:28 AM, LIU Zhiwei wrote:
On 2021/11/1 下午7:35, Richard Henderson wrote:
On 11/1/21 6:01 AM, LIU Zhiwei wrote:
Signed-off-by: LIU Zhiwei
---
target/riscv/insn_trans/trans_rvv.c.inc | 8
target/riscv/internals.h | 1 +
target/riscv/vector_helper.c | 54 +
3 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/target/riscv/insn_trans/trans_rvv.c.inc
b/target/riscv/insn_trans/trans_rvv.c.inc
index ed042f7bb9..5cd9b802df 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -233,6 +233,7 @@ static bool ld_us_op(DisasContext *s, arg_r2nfvm *a,
uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_us_trans(a->rd, a->rs1, data, fn, s);
}
@@ -286,6 +287,7 @@ static bool st_us_op(DisasContext *s, arg_r2nfvm *a,
uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_us_trans(a->rd, a->rs1, data, fn, s);
}
@@ -365,6 +367,7 @@ static bool ld_stride_op(DisasContext *s, arg_rnfvm *a, uint8_t
seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_stride_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -404,6 +407,7 @@ static bool st_stride_op(DisasContext *s, arg_rnfvm *a, uint8_t
seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
fn = fns[seq][s->sew];
if (fn == NULL) {
return false;
@@ -490,6 +494,7 @@ static bool ld_index_op(DisasContext *s, arg_rnfvm *a,
uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_index_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -542,6 +547,7 @@ static bool st_index_op(DisasContext *s, arg_rnfvm *a, uint8_t
seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_index_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -617,6 +623,7 @@ static bool ldff_op(DisasContext *s, arg_r2nfvm *a,
uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldff_trans(a->rd, a->rs1, data, fn, s);
}
@@ -724,6 +731,7 @@ static bool amo_op(DisasContext *s, arg_rwdvm *a, uint8_t
seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, WD, a->wd);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return amo_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
/*
diff --git a/target/riscv/internals.h b/target/riscv/internals.h
index b15ad394bb..f74b8291e4 100644
--- a/target/riscv/internals.h
+++ b/target/riscv/internals.h
@@ -27,6 +27,7 @@ FIELD(VDATA, VM, 8, 1)
FIELD(VDATA, LMUL, 9, 2)
FIELD(VDATA, NF, 11, 4)
FIELD(VDATA, WD, 11, 1)
+FIELD(VDATA, OL, 15, 2)
/* float point classify helpers */
target_ulong fclass_h(uint64_t frs1);
diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
index 535420ee66..451688c328 100644
--- a/target/riscv/vector_helper.c
+++ b/target/riscv/vector_helper.c
@@ -112,6 +112,11 @@ static uint32_t vext_wd(uint32_t desc)
return (simd_data(desc) >> 11) & 0x1;
}
+static inline uint32_t vext_ol(uint32_t desc)
+{
+ return FIELD_EX32(simd_data(desc), VDATA, OL);
+}
XLEN not OLEN.
OK.
@@ -123,6 +128,14 @@ static inline uint32_t vext_maxsz(uint32_t desc)
return simd_maxsz(desc) << vext_lmul(desc);
}
+static inline target_ulong adjust_addr(target_ulong addr, uint32_t olen)
+{
+ if (olen < TARGET_LONG_BITS) {
+ addr &= UINT32_MAX;
+ }
+ return addr;
+}
Here's where I'm unsure. This looks a lot like the changes that are required to
support pointer-masking in vectors, which Alexey said he was going to look at.
(1) Do we need to pass anything in VEXT at all?
We do have CPURISCVState, so we could just use cpu_get_ml,
Yes, we should use cpu_get_xl.
which we would also need for env->mmte etc
Re: [PATCH v3 2/2] accel/tcg: Register a force_rcu notifier
On 11/9/21 8:54 AM, Richard Henderson wrote:
On 11/8/21 12:33 PM, Greg Kurz wrote:
+static void rr_force_rcu(Notifier *notify, void *data)
+{
+ /*
+ * Called with rcu_registry_lock held, using async_run_on_cpu() ensures
+ * that there are no deadlocks.
+ */
+ async_run_on_cpu(first_cpu, do_nothing, RUN_ON_CPU_NULL);
+}
Should first_cpu really be rr_current_cpu?
It's not clear to me that this will work for -smp 2 -cpu thread=single.
Alternately, no async_run_on_cpu at all, just rr_kick_next_cpu().
r~
Re: [PATCH] device_tree: Fix compiler error
On 11/8/21 9:07 PM, Stefan Weil wrote:
A build with gcc (Debian 10.2.1-6) 10.2.1 20210110 fails:
../../../softmmu/device_tree.c: In function ‘qemu_fdt_add_path’:
../../../softmmu/device_tree.c:560:18: error: ‘retval’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
560 | int namelen, retval;
| ^~
This is not a real error, but the compiler can be satisfied with a small change.
Fixes: b863f0b75852 ("device_tree: Add qemu_fdt_add_path")
Signed-off-by: Stefan Weil
Reviewed-by: Richard Henderson
Though I think there's a good deal that could be cleaned up about this function:
(1a) Remove the unused return value?
The single use does not check the return.
(1b) Don't attempt to return a node, merely a success/failure code.
Certainly the local documentation here could be improved...
(1c) Return parent; make retval local to the loop.
(2) Merge p and path; there's no point retaining the unmodified parameter.
(3) Move name and namelen inside the loop.
r~
Re: [PATCH 09/13] target/riscv: Adjust vector address with ol
On 2021/11/9 下午4:18, Richard Henderson wrote:
On 11/9/21 9:04 AM, LIU Zhiwei wrote:
On 2021/11/9 下午2:37, Richard Henderson wrote:
On 11/8/21 10:28 AM, LIU Zhiwei wrote:
On 2021/11/1 下午7:35, Richard Henderson wrote:
On 11/1/21 6:01 AM, LIU Zhiwei wrote:
Signed-off-by: LIU Zhiwei
---
target/riscv/insn_trans/trans_rvv.c.inc | 8
target/riscv/internals.h | 1 +
target/riscv/vector_helper.c | 54
+
3 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/target/riscv/insn_trans/trans_rvv.c.inc
b/target/riscv/insn_trans/trans_rvv.c.inc
index ed042f7bb9..5cd9b802df 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -233,6 +233,7 @@ static bool ld_us_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_us_trans(a->rd, a->rs1, data, fn, s);
}
@@ -286,6 +287,7 @@ static bool st_us_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_us_trans(a->rd, a->rs1, data, fn, s);
}
@@ -365,6 +367,7 @@ static bool ld_stride_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_stride_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -404,6 +407,7 @@ static bool st_stride_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
fn = fns[seq][s->sew];
if (fn == NULL) {
return false;
@@ -490,6 +494,7 @@ static bool ld_index_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_index_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -542,6 +547,7 @@ static bool st_index_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_index_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -617,6 +623,7 @@ static bool ldff_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldff_trans(a->rd, a->rs1, data, fn, s);
}
@@ -724,6 +731,7 @@ static bool amo_op(DisasContext *s,
arg_rwdvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, WD, a->wd);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return amo_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
/*
diff --git a/target/riscv/internals.h b/target/riscv/internals.h
index b15ad394bb..f74b8291e4 100644
--- a/target/riscv/internals.h
+++ b/target/riscv/internals.h
@@ -27,6 +27,7 @@ FIELD(VDATA, VM, 8, 1)
FIELD(VDATA, LMUL, 9, 2)
FIELD(VDATA, NF, 11, 4)
FIELD(VDATA, WD, 11, 1)
+FIELD(VDATA, OL, 15, 2)
/* float point classify helpers */
target_ulong fclass_h(uint64_t frs1);
diff --git a/target/riscv/vector_helper.c
b/target/riscv/vector_helper.c
index 535420ee66..451688c328 100644
--- a/target/riscv/vector_helper.c
+++ b/target/riscv/vector_helper.c
@@ -112,6 +112,11 @@ static uint32_t vext_wd(uint32_t desc)
return (simd_data(desc) >> 11) & 0x1;
}
+static inline uint32_t vext_ol(uint32_t desc)
+{
+ return FIELD_EX32(simd_data(desc), VDATA, OL);
+}
XLEN not OLEN.
OK.
@@ -123,6 +128,14 @@ static inline uint32_t vext_maxsz(uint32_t
desc)
return simd_maxsz(desc) << vext_lmul(desc);
}
+static inline target_ulong adjust_addr(target_ulong addr,
uint32_t olen)
+{
+ if (olen < TARGET_LONG_BITS) {
+ addr &= UINT32_MAX;
+ }
+ return addr;
+}
Here's where I'm unsure. This looks a lot like the changes that
are required to support pointer-masking in vectors, which Alexey
said he was going to look at.
(1) Do we need to pass anything in VEXT at all?
We do have CPURISCVState, so we could just use cpu_get_ml,
Yes, we shoul
Re: [PULL 00/54] ppc-for-6.2 queue 20211109
On 11/9/21 6:51 AM, David Gibson wrote:
The following changes since commit 114f3c8cc427333dbae331dfd2ecae64676b087e:
Merge remote-tracking branch 'remotes/philmd/tags/avocado-20211108' into
staging (2021-11-08 18:50:09 +0100)
are available in the Git repository at:
https://gitlab.com/dgibson/qemu.git tags/ppc-for-6.2-20211109
for you to fetch changes up to 71e6fae3a994ab5c69e37d6a52a30c840883fbfb:
spapr_numa.c: FORM2 table handle nodes with no distance info (2021-11-09
10:32:53 +1100)
ppc patch queue for 2021-11-09
Here's the latest set of ppc related patches for qemu-6.2, which I
hope will squeeze in just barely before the hard freeze.
This set includes a change to MAINTAINERS moving maintainership of ppc
from myself and Greg Kurz to Cédric le Goater and Daniel Henrique
Barboza. So, I expect this to be my last pull request as ppc
maintainer. It's been great, but it's time I moved onto other things.
Apart from that, this patchset is mostly a lot of updates to TCG
implementations of ISA 3.1 (POWER10) instructions from the El Dorado
team. There are also a handful of other fixes.
BALATON Zoltan (1):
ppc/pegasos2: Suppress warning when qtest enabled
Bruno Larsen (1):
target/ppc: Move REQUIRE_ALTIVEC/VECTOR to translate.c
Bruno Larsen (billionai) (6):
target/ppc: Introduce REQUIRE_VSX macro
target/ppc: moved XXSPLTW to using decodetree
target/ppc: moved XXSPLTIB to using decodetree
target/ppc: implemented XXSPLTI32DX
target/ppc: Implemented XXSPLTIW using decodetree
target/ppc: implemented XXSPLTIDP instruction
Cédric Le Goater (1):
ppc/pnv: Fix check on block device before updating drive contents
David Gibson (1):
target/ppc, hw/ppc: Change maintainers
Fernando Eckhardt Valle (4):
target/ppc: introduce do_ea_calc
target/ppc: move resolve_PLS_D to translate.c
target/ppc: Move load and store floating point instructions to decodetree
target/ppc: Implement PLFS, PLFD, PSTFS and PSTFD instructions
Fernando Valle (1):
target/ppc: Introduce REQUIRE_FPU
Lucas Mateus Castro (alqotel) (6):
target/ppc: moved stxv and lxv from legacy to decodtree
target/ppc: moved stxvx and lxvx from legacy to decodtree
target/ppc: added the instructions LXVP and STXVP
target/ppc: added the instructions LXVPX and STXVPX
target/ppc: added the instructions PLXV and PSTXV
target/ppc: added the instructions PLXVP and PSTXVP
Luis Pires (15):
target/ppc: Implement cntlzdm
target/ppc: Implement cnttzdm
libdecnumber: introduce decNumberFrom[U]Int128
target/ppc: Implement DCFFIXQQ
host-utils: Introduce mulu128
libdecnumber: Introduce decNumberIntegralToInt128
target/ppc: Implement DCTFIXQQ
target/ppc: Do not update nip on DFP instructions
target/ppc: Move dtstdc[q]/dtstdg[q] to decodetree
target/ppc: Move d{add,sub,mul,div,iex}[q] to decodetree
target/ppc: Move dcmp{u,o}[q],dts{tex,tsf,tsfi}[q] to decodetree
target/ppc: Move dquai[q], drint{x,n}[q] to decodetree
target/ppc: Move dqua[q], drrnd[q] to decodetree
target/ppc: Move dct{dp,qpq},dr{sp,dpq},dc{f,t}fix[q],dxex[q] to
decodetree
target/ppc: Move ddedpd[q],denbcd[q],dscli[q],dscri[q] to decodetree
Matheus Ferst (17):
target/ppc: Move LQ and STQ to decodetree
target/ppc: Implement PLQ and PSTQ
target/ppc: Implement pdepd instruction
target/ppc: Implement pextd instruction
target/ppc: Move vcfuged to vmx-impl.c.inc
target/ppc: Implement vclzdm/vctzdm instructions
target/ppc: Implement vpdepd/vpextd instruction
target/ppc: Implement vsldbi/vsrdbi instructions
target/ppc: Implement Vector Insert from GPR using GPR index insns
target/ppc: Implement Vector Insert Word from GPR using Immediate insns
target/ppc: Implement Vector Insert from VSR using GPR index insns
target/ppc: Move vinsertb/vinserth/vinsertw/vinsertd to decodetree
target/ppc: Implement Vector Extract Double to VSR using GPR index insns
target/ppc: receive high/low as argument in get/set_cpu_vsr
target/ppc: Implement xxblendvb/xxblendvh/xxblendvw/xxblendvd
instructions
target/ppc: Implement lxvkq instruction
target/ppc: cntlzdm/cnttzdm implementation without brcond
Nicholas Piggin (1):
spapr_numa.c: FORM2 table handle nodes with no distance info
MAINTAINERS| 20 +-
hw/ppc/pegasos2.c | 3 +-
hw/ppc/pnv_pnor.c | 2 +-
hw/ppc/spapr_numa.c| 22 +-
include/libdecnumber/decNumber.h | 4 +
include/libdecnumber/decNumberLocal.h | 2 +-
Re: [PATCH] device_tree: Fix compiler error
On 11/9/21 9:38 AM, Richard Henderson wrote:
> On 11/8/21 9:07 PM, Stefan Weil wrote:
>> A build with gcc (Debian 10.2.1-6) 10.2.1 20210110 fails:
>>
>> ../../../softmmu/device_tree.c: In function ‘qemu_fdt_add_path’:
>> ../../../softmmu/device_tree.c:560:18: error: ‘retval’ may be used
>> uninitialized in this function [-Werror=maybe-uninitialized]
>> 560 | int namelen, retval;
>> | ^~
>>
>> This is not a real error, but the compiler can be satisfied with a
>> small change.
>>
>> Fixes: b863f0b75852 ("device_tree: Add qemu_fdt_add_path")
>> Signed-off-by: Stefan Weil
>
> Reviewed-by: Richard Henderson
>
> Though I think there's a good deal that could be cleaned up about this
> function:
>
> (1a) Remove the unused return value?
> The single use does not check the return.
>
> (1b) Don't attempt to return a node, merely a success/failure code.
> Certainly the local documentation here could be improved...
>
> (1c) Return parent; make retval local to the loop.
>
> (2) Merge p and path; there's no point retaining the unmodified parameter.
>
> (3) Move name and namelen inside the loop.
(4) swap if() bodies?
if (retval == -FDT_ERR_NOTFOUND) {
} else if (retval < 0) {
}
Michal
Re: [PATCH 09/13] target/riscv: Adjust vector address with ol
On 2021/11/9 下午4:39, LIU Zhiwei wrote:
On 2021/11/9 下午4:18, Richard Henderson wrote:
On 11/9/21 9:04 AM, LIU Zhiwei wrote:
On 2021/11/9 下午2:37, Richard Henderson wrote:
On 11/8/21 10:28 AM, LIU Zhiwei wrote:
On 2021/11/1 下午7:35, Richard Henderson wrote:
On 11/1/21 6:01 AM, LIU Zhiwei wrote:
Signed-off-by: LIU Zhiwei
---
target/riscv/insn_trans/trans_rvv.c.inc | 8
target/riscv/internals.h | 1 +
target/riscv/vector_helper.c | 54
+
3 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/target/riscv/insn_trans/trans_rvv.c.inc
b/target/riscv/insn_trans/trans_rvv.c.inc
index ed042f7bb9..5cd9b802df 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -233,6 +233,7 @@ static bool ld_us_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_us_trans(a->rd, a->rs1, data, fn, s);
}
@@ -286,6 +287,7 @@ static bool st_us_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_us_trans(a->rd, a->rs1, data, fn, s);
}
@@ -365,6 +367,7 @@ static bool ld_stride_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_stride_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -404,6 +407,7 @@ static bool st_stride_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
fn = fns[seq][s->sew];
if (fn == NULL) {
return false;
@@ -490,6 +494,7 @@ static bool ld_index_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_index_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -542,6 +547,7 @@ static bool st_index_op(DisasContext *s,
arg_rnfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldst_index_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
@@ -617,6 +623,7 @@ static bool ldff_op(DisasContext *s,
arg_r2nfvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, NF, a->nf);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return ldff_trans(a->rd, a->rs1, data, fn, s);
}
@@ -724,6 +731,7 @@ static bool amo_op(DisasContext *s,
arg_rwdvm *a, uint8_t seq)
data = FIELD_DP32(data, VDATA, VM, a->vm);
data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
data = FIELD_DP32(data, VDATA, WD, a->wd);
+ data = FIELD_DP32(data, VDATA, OL, s->ol);
return amo_trans(a->rd, a->rs1, a->rs2, data, fn, s);
}
/*
diff --git a/target/riscv/internals.h b/target/riscv/internals.h
index b15ad394bb..f74b8291e4 100644
--- a/target/riscv/internals.h
+++ b/target/riscv/internals.h
@@ -27,6 +27,7 @@ FIELD(VDATA, VM, 8, 1)
FIELD(VDATA, LMUL, 9, 2)
FIELD(VDATA, NF, 11, 4)
FIELD(VDATA, WD, 11, 1)
+FIELD(VDATA, OL, 15, 2)
/* float point classify helpers */
target_ulong fclass_h(uint64_t frs1);
diff --git a/target/riscv/vector_helper.c
b/target/riscv/vector_helper.c
index 535420ee66..451688c328 100644
--- a/target/riscv/vector_helper.c
+++ b/target/riscv/vector_helper.c
@@ -112,6 +112,11 @@ static uint32_t vext_wd(uint32_t desc)
return (simd_data(desc) >> 11) & 0x1;
}
+static inline uint32_t vext_ol(uint32_t desc)
+{
+ return FIELD_EX32(simd_data(desc), VDATA, OL);
+}
XLEN not OLEN.
OK.
@@ -123,6 +128,14 @@ static inline uint32_t vext_maxsz(uint32_t
desc)
return simd_maxsz(desc) << vext_lmul(desc);
}
+static inline target_ulong adjust_addr(target_ulong addr,
uint32_t olen)
+{
+ if (olen < TARGET_LONG_BITS) {
+ addr &= UINT32_MAX;
+ }
+ return addr;
+}
Here's where I'm unsure. This looks a lot like the changes that
are required to support pointer-masking in vectors, which Alexey
said he was going to look at.
(1) Do we need to pass anything in VEXT at all?
We do have CPURISCVState, so we
Re: [PATCH] linux-user: Replace __u64 with uint64_t
On 11/8/21 20:42, Khem Raj wrote:
> uint64_t is available in all userspaces via compiler include stdint.h
> therefore use it instead of __u64 which is linux internal type, it fixes
> build on some platforms eg. aarch64 systems using musl C library
>
> Signed-off-by: Khem Raj
> ---
> linux-user/host/aarch64/hostdep.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/linux-user/host/aarch64/hostdep.h
> b/linux-user/host/aarch64/hostdep.h
> index a8d41a21ad..34d934f665 100644
> --- a/linux-user/host/aarch64/hostdep.h
> +++ b/linux-user/host/aarch64/hostdep.h
> @@ -25,7 +25,7 @@ extern char safe_syscall_end[];
> static inline void rewind_if_in_safe_syscall(void *puc)
> {
> ucontext_t *uc = puc;
> -__u64 *pcreg = &uc->uc_mcontext.pc;
> +uint64_t *pcreg = &uc->uc_mcontext.pc;
>
> if (*pcreg > (uintptr_t)safe_syscall_start
> && *pcreg < (uintptr_t)safe_syscall_end) {
>
Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH] acpi: tpm: Add missing device identification objects
On 11/9/21 01:46, Stefan Berger wrote:
> From: Stefan Berger
>
> Add missing device identification objects _STR and _UID. They will appear
> as files 'description' and 'uid' under Linux sysfs.
>
> Cc: Shannon Zhao
> Cc: Michael S. Tsirkin
> Cc: Igor Mammedov
> Cc: Ani Sinha
> Fixes: #708
https://gitlab.com/qemu-project/qemu/-/issues/708
> Signed-off-by: Stefan Berger
> ---
> hw/arm/virt-acpi-build.c | 1 +
> hw/i386/acpi-build.c | 4
> 2 files changed, 5 insertions(+)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 674f902652..09456424aa 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -228,6 +228,7 @@ static void acpi_dsdt_add_tpm(Aml *scope,
> VirtMachineState *vms)
>
> Aml *dev = aml_device("TPM0");
> aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
> +aml_append(dev, aml_name_decl("_STR", aml_string("TPM 2.0 Device")));
> aml_append(dev, aml_name_decl("_UID", aml_int(0)));
>
> Aml *crs = aml_resource_template();
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index a3ad6abd33..d6d3541407 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -1808,6 +1808,10 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> dev = aml_device("TPM");
> aml_append(dev, aml_name_decl("_HID",
>aml_string("MSFT0101")));
> +aml_append(dev,
> + aml_name_decl("_STR",
> + aml_string("TPM 2.0 Device")));
> +aml_append(dev, aml_name_decl("_UID", aml_int(0)));
> } else {
> dev = aml_device("ISA.TPM");
> aml_append(dev, aml_name_decl("_HID",
>
[PULL 1/6] hmp: Add shortcut to stop command to match cont
From: BALATON Zoltan
Some commands such as quit or cont have one letter alternatives but
stop is missing that. Add stop|s to match cont|c for consistency and
convenience.
Signed-off-by: BALATON Zoltan
Reviewed-by: Daniel P. Berrangé
Message-Id: <20211030095225.513d4748...@zero.eik.bme.hu>
Signed-off-by: Laurent Vivier
---
hmp-commands.hx | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 3a5aeba3fe8a..70a9136ac293 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -382,7 +382,7 @@ SRST
ERST
{
-.name = "stop",
+.name = "stop|s",
.args_type = "",
.params = "",
.help = "stop emulation",
@@ -390,7 +390,7 @@ ERST
},
SRST
-``stop``
+``stop`` or ``s``
Stop emulation.
ERST
--
2.31.1
[PULL 2/6] hw/m68k: Fix typo in SPDX tag
From: Philippe Mathieu-Daudé
Fix 'Identifer' -> 'Identifier' typo.
Cc: Laurent Vivier
Fixes: 8c6df16ff60 ("hw/char: add goldfish-tty")
Fixes: 87855593903 ("hw/intc: add goldfish-pic")
Fixes: 2fde99ee312 ("m68k: add an interrupt controller")
Fixes: 0791bc02b8f ("m68k: add a system controller")
Fixes: e1cecdca559 ("m68k: add Virtual M68k Machine")
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Richard Henderson
Reviewed-by: Laurent Vivier
Message-Id: <20211103105311.3399293-1-f4...@amsat.org>
Signed-off-by: Laurent Vivier
---
hw/char/goldfish_tty.c | 2 +-
hw/intc/goldfish_pic.c | 2 +-
hw/intc/m68k_irqc.c| 2 +-
hw/m68k/virt.c | 2 +-
hw/misc/virt_ctrl.c| 2 +-
include/hw/char/goldfish_tty.h | 2 +-
include/hw/intc/goldfish_pic.h | 2 +-
include/hw/intc/m68k_irqc.h| 2 +-
include/hw/misc/virt_ctrl.h| 2 +-
9 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/hw/char/goldfish_tty.c b/hw/char/goldfish_tty.c
index 8365a1876145..20b77885c180 100644
--- a/hw/char/goldfish_tty.c
+++ b/hw/char/goldfish_tty.c
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* Goldfish TTY
*
diff --git a/hw/intc/goldfish_pic.c b/hw/intc/goldfish_pic.c
index e3b43a69f163..dfd53275f692 100644
--- a/hw/intc/goldfish_pic.c
+++ b/hw/intc/goldfish_pic.c
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* Goldfish PIC
*
diff --git a/hw/intc/m68k_irqc.c b/hw/intc/m68k_irqc.c
index 2133d2a698ab..0c515e4ecb79 100644
--- a/hw/intc/m68k_irqc.c
+++ b/hw/intc/m68k_irqc.c
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* QEMU Motorola 680x0 IRQ Controller
*
diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 4e8bce5aa6f7..edc58fbddae4 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* QEMU Vitual M68K Machine
*
diff --git a/hw/misc/virt_ctrl.c b/hw/misc/virt_ctrl.c
index 3552d7a09abd..e75d1e7e17b3 100644
--- a/hw/misc/virt_ctrl.c
+++ b/hw/misc/virt_ctrl.c
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* Virt system Controller
*/
diff --git a/include/hw/char/goldfish_tty.h b/include/hw/char/goldfish_tty.h
index b9dd67362a68..7503d2fa1e15 100644
--- a/include/hw/char/goldfish_tty.h
+++ b/include/hw/char/goldfish_tty.h
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* Goldfish TTY
*
diff --git a/include/hw/intc/goldfish_pic.h b/include/hw/intc/goldfish_pic.h
index ad13ab37fc3e..e9d552f79682 100644
--- a/include/hw/intc/goldfish_pic.h
+++ b/include/hw/intc/goldfish_pic.h
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* Goldfish PIC
*
diff --git a/include/hw/intc/m68k_irqc.h b/include/hw/intc/m68k_irqc.h
index dbcfcfc2e000..ef91f218122e 100644
--- a/include/hw/intc/m68k_irqc.h
+++ b/include/hw/intc/m68k_irqc.h
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* QEMU Motorola 680x0 IRQ Controller
*
diff --git a/include/hw/misc/virt_ctrl.h b/include/hw/misc/virt_ctrl.h
index edfadc469505..25a237e51874 100644
--- a/include/hw/misc/virt_ctrl.h
+++ b/include/hw/misc/virt_ctrl.h
@@ -1,5 +1,5 @@
/*
- * SPDX-License-Identifer: GPL-2.0-or-later
+ * SPDX-License-Identifier: GPL-2.0-or-later
*
* Virt system Controller
*/
--
2.31.1
[PULL 5/6] tests/qtest/virtio-net: fix hotplug test case
From: Laurent Vivier
virtio-net-test has an hotplug testcase that is never executed.
This is because the testcase is attached to virtio-pci interface
rather than to virtio-net-pci.
$ QTEST_QEMU_BINARY=./qemu-system-x86_64 tests/qtest/qos-test -l | grep
hotplug
/x86_64/.../pci-ohci-tests/ohci_pci-test-hotplug
/x86_64/.../e1000e/e1000e-tests/hotplug
/x86_64/.../virtio-blk-pci/virtio-blk-pci-tests/hotplug
/x86_64/.../vhost-user-blk-pci/vhost-user-blk-pci-tests/hotplug
/x86_64/.../virtio-rng-pci/virtio-rng-pci-tests/hotplug
/x86_64/.../virtio-scsi/virtio-scsi-tests/hotplug
/x86_64/.../virtio-serial/virtio-serial-tests/hotplug
With this fix:
$ QTEST_QEMU_BINARY=./qemu-system-x86_64 tests/qtest/qos-test -l | grep
hotplug
...
/x86_64/.../vhost-user-blk-pci/vhost-user-blk-pci-tests/hotplug
/x86_64/.../virtio-net-pci/virtio-net-pci-tests/hotplug
/x86_64/.../virtio-rng-pci/virtio-rng-pci-tests/hotplug
...
$ QTEST_QEMU_BINARY=./qemu-system-x86_64 tests/qtest/qos-test -p
/x86_64/.../virtio-net-pci-tests/hotplug
/x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-net-pci/virtio-net-pci-tests/hotplug:
OK
Fixes: 6ae333f91b99 ("qos-test: virtio-net test node")
Signed-off-by: Laurent Vivier
Acked-by: Thomas Huth
Message-Id: <20211028173014.139692-1-lviv...@redhat.com>
Signed-off-by: Laurent Vivier
---
tests/qtest/virtio-net-test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/qtest/virtio-net-test.c b/tests/qtest/virtio-net-test.c
index a08e2ffe123f..8bf74e516cce 100644
--- a/tests/qtest/virtio-net-test.c
+++ b/tests/qtest/virtio-net-test.c
@@ -319,7 +319,7 @@ static void register_virtio_net_test(void)
.before = virtio_net_test_setup,
};
-qos_add_test("hotplug", "virtio-pci", hotplug, &opts);
+qos_add_test("hotplug", "virtio-net-pci", hotplug, &opts);
#ifndef _WIN32
qos_add_test("basic", "virtio-net", send_recv_test, &opts);
qos_add_test("rx_stop_cont", "virtio-net", stop_cont_test, &opts);
--
2.31.1
[PULL 0/6] Trivial branch for 6.2 patches
The following changes since commit f10e7b9f6fc18be390b3bc189e04b5147eb8dbf8: Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-6.2-20211109' into staging (2021-11-09 07:18:33 +0100) are available in the Git repository at: git://github.com/vivier/qemu.git tags/trivial-branch-for-6.2-pull-request for you to fetch changes up to 66d96a1901b7d9cfdbc454d407710ca8bfb90947: docs/about/deprecated: Remove empty 'related binaries' section (2021-11-09 10:11:27 +0100) Trivial branch patches pull request 20211109 BALATON Zoltan (1): hmp: Add shortcut to stop command to match cont Laurent Vivier (1): tests/qtest/virtio-net: fix hotplug test case Philippe Mathieu-Daudé (4): hw/m68k: Fix typo in SPDX tag .mailmap: Fix more contributor entries meson: Fix 'interpretor' typo docs/about/deprecated: Remove empty 'related binaries' section .mailmap | 4 docs/about/deprecated.rst | 3 --- hmp-commands.hx| 4 ++-- hw/char/goldfish_tty.c | 2 +- hw/intc/goldfish_pic.c | 2 +- hw/intc/m68k_irqc.c| 2 +- hw/m68k/virt.c | 2 +- hw/misc/virt_ctrl.c| 2 +- include/hw/char/goldfish_tty.h | 2 +- include/hw/intc/goldfish_pic.h | 2 +- include/hw/intc/m68k_irqc.h| 2 +- include/hw/misc/virt_ctrl.h| 2 +- meson.build| 2 +- tests/qtest/virtio-net-test.c | 2 +- 14 files changed, 17 insertions(+), 16 deletions(-) -- 2.31.1
[PULL 6/6] docs/about/deprecated: Remove empty 'related binaries' section
From: Philippe Mathieu-Daudé
Commit 497a30dbb06 ("qemu-img: Require -F with -b backing image")
removed the content of the "Related binaries" section but forgot
to remove the section title. Since it is now empty, remove it too.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Willian Rampazzo
Reviewed-by: Yanan Wang
Reviewed-by: Joaquin de Andres
Message-Id: <20211105142656.145791-1-phi...@redhat.com>
Signed-off-by: Laurent Vivier
---
docs/about/deprecated.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 56f9ad15ab54..5e514fb443da 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -370,9 +370,6 @@ The ``I7200`` guest CPU relies on the nanoMIPS ISA, which
is deprecated
(the ISA has never been upstreamed to a compiler toolchain). Therefore
this CPU is also deprecated.
-Related binaries
-
-
Backwards compatibility
---
--
2.31.1
[PULL 4/6] meson: Fix 'interpretor' typo
From: Philippe Mathieu-Daudé
Fix a typo from commit fa2f7b0b9b7 ("meson: Warn when TCI is
selected but TCG backend is available").
Reported-by: Peter Maydell
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Laurent Vivier
Message-Id: <20210521103423.2780345-1-phi...@redhat.com>
Signed-off-by: Laurent Vivier
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index 6bfed294d07b..9702fdce6d03 100644
--- a/meson.build
+++ b/meson.build
@@ -340,7 +340,7 @@ if not get_option('tcg').disabled()
error('Unsupported CPU @0@, try --enable-tcg-interpreter'.format(cpu))
endif
elif get_option('tcg_interpreter')
-warning('Use of the TCG interpretor is not recommended on this host')
+warning('Use of the TCG interpreter is not recommended on this host')
warning('architecture. There is a native TCG execution backend available')
warning('which provides substantially better performance and reliability.')
warning('It is strongly recommended to remove the
--enable-tcg-interpreter')
--
2.31.1
[PULL 3/6] .mailmap: Fix more contributor entries
From: Philippe Mathieu-Daudé These authors have some incorrect author email field. Acked-by: Pan Nengyuan Reviewed-by: Alex Chen Reviewed-by: Hyman Huang Reviewed-by: Haibin Zhang Signed-off-by: Philippe Mathieu-Daudé Message-Id: <20211027043254.1248097-1-f4...@amsat.org> Signed-off-by: Laurent Vivier --- .mailmap | 4 1 file changed, 4 insertions(+) diff --git a/.mailmap b/.mailmap index f029d1c21fe8..8beb2f95ae28 100644 --- a/.mailmap +++ b/.mailmap @@ -69,6 +69,7 @@ Yongbok Kim # git author config, or had utf8/latin1 encoding issues. Aaron Lindsay Alexey Gerasimenko +Alex Chen Alex Ivanov Andreas Färber Bandan Das @@ -99,9 +100,11 @@ Gautham R. Shenoy Gautham R. Shenoy Gonglei (Arei) Guang Wang +Haibin Zhang Hailiang Zhang Hanna Reitz Hervé Poussineau +Hyman Huang Jakub Jermář Jakub Jermář Jean-Christophe Dubois @@ -135,6 +138,7 @@ Nicholas Thomas Nikunj A Dadhania Orit Wasserman Paolo Bonzini +Pan Nengyuan Pavel Dovgaluk Pavel Dovgaluk Pavel Dovgaluk -- 2.31.1
Re: Poking around bdrv_is_inserted()
Am 09.11.2021 um 07:44 hat Markus Armbruster geschrieben:
> Screwed up qemu-devel@nongnu.org, sorry for the inconvenience.
>
> Markus Armbruster writes:
>
> > bdrv_is_inserted() returns false when:
> >
> > /**
> > * Return TRUE if the media is present
> > */
> > bool bdrv_is_inserted(BlockDriverState *bs)
> > {
> > BlockDriver *drv = bs->drv;
> > BdrvChild *child;
> >
> > if (!drv) {
> > return false;
> >
> > 1. @bs has no driver (this is how we represent "no medium").
Not really any more. "No medium" is blk->root == NULL. These days
bs->drv == NULL basically means "the backend is broken". This happens
after qcow2_signal_corruption(), and I'm not sure if we have more
circumstances like it.
> > }
> > if (drv->bdrv_is_inserted) {
> > return drv->bdrv_is_inserted(bs);
> >
> > 2. Its driver's ->bdrv_is_inserted() returns false. This is how
> > passthrough block backends signal "host device has no medium". Right
> > now, the only user is "host_cdrom".
> >
> > }
> > QLIST_FOREACH(child, &bs->children, next) {
> > if (!bdrv_is_inserted(child->bs)) {
> > return false;
> >
> > 3. Any of its children has no medium. Common use looking through
> > filters, which have a single child.
> >
> > }
> > }
> > return true;
> > }
> >
> > Makes sense.
> >
> > Now look at the uses of QERR_DEVICE_HAS_NO_MEDIUM.
> >
> > * external_snapshot_prepare() in blockdev.c:
> >
> > if (!bdrv_is_inserted(state->old_bs)) {
> > error_setg(errp, QERR_DEVICE_HAS_NO_MEDIUM, device);
> > goto out;
> > }
> >
> > where @device is the device name, i.e. BlockdevSnapshot member @node
> > or BlockdevSnapshotSync member @device. Uh-oh: the latter can be
> > null. If we can reach the error_setg() then, we crash on some
> > systems.
Sounds like we should write a test case and then fix it.
> > * bdrv_snapshot_delete() and bdrv_snapshot_load_tmp() in
> > block/snaphot.c:
> >
> > if (!drv) {
> > error_setg(errp, QERR_DEVICE_HAS_NO_MEDIUM,
> > bdrv_get_device_name(bs));
> > return -ENOMEDIUM;
> > }
> >
> > where @drv is bs->drv.
> >
> > Why do we check only for 1. here instead of calling
> > bdrv_is_inserted()?
I guess we could philosophise about the theoretically right thing to do,
but last time I checked, host_cdrom didn't support snapshots, so it
probably doesn't matter either way.
Kevin
Re: [PATCH 09/13] target/riscv: Adjust vector address with ol
On 11/9/21 10:05 AM, LIU Zhiwei wrote:
Do you mean we should add this code to riscv_tr_init_disas_context
if (ctx->pm_enabled) {
switch (priv) {
case PRV_M:
env->mask = env->mpmmask;
env->base = env->mpmbase;
break;
case PRV_S:
env->mask = env->spmmask;
env->base = env->spmbase;
break;
case PRV_U:
env->mask = env->upmmask;
env->base = env->upmbase;
break;
default:
g_assert_not_reached();
}
ctx->pm_mask = pm_mask[priv];
ctx->pm_base = pm_base[priv];
ctx->need_mask = true; /* new flag for mask */
} else if (get_xlen(ctx) < TARGET_LONG_BITS) {
env->mask = UINT32_MAX;
env->base = 0;
Certainly we cannot modify env in riscv_tr_init_disas_context.
ctx->pm_mask = tcg_constant_tl(UINT32_MAX);
ctx->pm_base = tcg_constant_tl(0);
ctx->need_mask = true;
} else {
env->mask = UINT64_MAX;
env->base = 0;
}
I think the code is wrong, perhaps we should modify the write_mpmmask
env->mask = env->mpmmask = value;
Something like that, yes. However, env->mask must be set based on env->priv, etc; you
can't just assign the same as mpmmask.
Then you also need to update env->mask in a hook like you created in patch 11 to switch
context (though I would call it from helper_mret and helper_sret directly, and not create
a new call from tcg). Then you need to call the hook as well on exception entry, reset,
and vmstate_riscv_cpu.post_load.
r~
Re: [PATCH v4 2/2] tests/unit: Add an unit test for smp parsing
Hi,
On 10/28/21 17:09, Philippe Mathieu-Daudé wrote:
> From: Yanan Wang
>
> Now that we have a generic parser smp_parse(), let's add an unit
> test for the code. All possible valid/invalid SMP configurations
> that the user can specify are covered.
>
> Signed-off-by: Yanan Wang
> Reviewed-by: Andrew Jones
> Tested-by: Philippe Mathieu-Daudé
> Message-Id: <20211026034659.22040-3-wangyana...@huawei.com>
> Signed-off-by: Philippe Mathieu-Daudé
> ---
> tests/unit/test-smp-parse.c | 594
> MAINTAINERS | 1 +
> tests/unit/meson.build | 1 +
> 3 files changed, 596 insertions(+)
> create mode 100644 tests/unit/test-smp-parse.c
Could you have a look at this test failure please?
https://cirrus-ci.com/task/5823855357853696
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
G_TEST_SRCDIR=C:/Users/ContainerAdministrator/AppData/Local/Temp/cirrus-ci-build/tests/unit
G_TEST_BUILDDIR=C:/Users/ContainerAdministrator/AppData/Local/Temp/cirrus-ci-build/build/tests/unit
tests/unit/test-smp-parse.exe --tap -k
Test smp_parse failed!
Input configuration: (SMPConfiguration) {
.has_cpus= true, cpus= 1,
.has_sockets = false, sockets = 0,
.has_dies= false, dies= 0,
.has_cores = false, cores = 0,
.has_threads = false, threads = 0,
.has_maxcpus = false, maxcpus = 0,
}
Should be valid: no
Expected error report: Invalid SMP CPUs 1. The min CPUs supported by
machine '(null)' is 2
Result is valid: no
Output error report: Invalid SMP CPUs 1. The min CPUs supported by
machine '(NULL)' is 2
ERROR test-smp-parse - too few tests run (expected 2, got 0)
make: *** [Makefile.mtest:576: run-test-70] Error 1
Cirrus-CI all red
FYI, as of today, the latest merge history is red (last 10 days): https://cirrus-ci.com/github/qemu/qemu If we want to keep using this, we should somehow plug it to GitLab-CI (i.e. Travis-CI is run as an external job there) so the project maintainer can notice job failures. Alternatively the windows job could be passed to GitLab: https://docs.gitlab.com/ee/ci/runners/runner_cloud/windows_runner_cloud.html Regards, Phil.
Re: Cirrus-CI all red
On 09/11/2021 10.39, Philippe Mathieu-Daudé wrote: FYI, as of today, the latest merge history is red (last 10 days): https://cirrus-ci.com/github/qemu/qemu If we want to keep using this, we should somehow plug it to GitLab-CI (i.e. Travis-CI is run as an external job there) so the project maintainer can notice job failures. Well, considering that all the cirrus-run based jobs are currently failing due to the non-working API token, that does not seem to work very well either. Alternatively the windows job could be passed to GitLab: https://docs.gitlab.com/ee/ci/runners/runner_cloud/windows_runner_cloud.html See: https://lists.gnu.org/archive/html/qemu-devel/2021-07/msg02474.html ... the problem is again that the shared runners are only single-threaded, so it's incredibly slow, especially if you have to re-install MSYS2 each time. I once tried to improve the patch by caching the MSYS2 installation, but it did not work that well either... (but if somebody wants to continue my work, I can rebase and send it out again, just let me know). Thomas
Re: [PATCH v3 03/19] docs/devel: document expectations for QAPI data modelling for QMP
On Tue, Nov 09, 2021 at 07:39:29AM +0100, Markus Armbruster wrote: > Daniel P. Berrangé writes: > > > On Thu, Nov 04, 2021 at 06:43:23AM +0100, Markus Armbruster wrote: > >> Daniel P. Berrangé writes: > >> > >> > On Thu, Oct 28, 2021 at 04:24:31PM +0100, Daniel P. Berrangé wrote: > >> >> On Thu, Oct 28, 2021 at 04:31:40PM +0200, Markus Armbruster wrote: > >> >> > This clashes with my "[PATCH v2 0/9] Configurable policy for handling > >> >> > unstable interfaces", which replaces "you must give unstable stuff > >> >> > names > >> >> > starting with 'x-'" by "you must give unstable stuff feature flag > >> >> > 'unstable' (and may give it a name starting with 'x-')". > >> >> > >> >> If your series goes in first, I'll update this to take account of it, > >> >> but for now I'll leave it as is. > >> > > >> > This patch has now merged to git master. > >> > >> Merge commit e86e00a2493, Nov 3. > >> > >> > If you re-post your series feel free to update the new docs, or let > >> > me know if you want me to do it afterwards. > >> > >> The latter, because my series went in before yours, in merge commit > >> dd61b91c080, Oct 29 :) > > > > Sigh, I'm blind ! Dunno how i missed that. > > I can do it for you (it's such a simple patch), but I'd rather not do it > in addition to you :) I've not started yet, so I'll let you do it since you probably have a better idea of the preferred language to describe it. I'll promise my review services in return. 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: Failure of hot plugging secondary virtio_blk into q35 Windows 2019
On Tue, Nov 09, 2021 at 12:41:39PM +0530, Ani Sinha wrote: > > +gerd > > On Mon, 8 Nov 2021, Annie.li wrote: > > > Update: > > > > I've tested q35 guest w/o OVMF, the APCI PCI hot-plugging works well in q35 > > guest. Seems this issue only happens in q35 guest w/ OVMF. > > > > Looks that there is already a bug filed against this hotplug issue in q35 > > guest w/ OVMF, > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2004829 > > > > In this bug, it is recommended to add "-global > > ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off \" on qemu command for > > 6.1. > > However, with this option for 6.1(PCIe native hotplug), there still are > > kinds > > of issues. For example, one of them is the deleted virtio_blk device still > > shows in the Device Manager in Windows q35 guest, the operation of > > re-scanning > > new hardware takes forever there. This means both PCIe native hotplug and > > ACPI > > hotplug all have issues in q35 guests. > > This is sad. > > > > > Per comments in this bug, changes in both OVMF and QEMU are necessary to > > support ACPI hot plug in q35 guest. The fixes may likely be available in > > QEMU > > 6.2.0. > > So we are in soft code freeze for 6.2: > https://wiki.qemu.org/Planning/6.2 > > I am curious about Gerd's comment #10: > "The 6.2 rebase should make hotplug work > again with the default configuration." > > Sadly I have not seen any public discussion on what we want to do > for the issues with acpi hotplug for bridges in q35. I've raised one of the problems a week ago and there's a promised fix https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg00558.html but we're now a week after freeze and still no patch has been posted AFAIK. IMHO it is pretty much time to revert to native hotplug, otherwise we're going to risk getting too late into freeze to do anything, and end up shipping with broken PCI hotplug again in 6.2 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: Cirrus-CI all red
On Tue, Nov 09, 2021 at 10:45:18AM +0100, Thomas Huth wrote: > On 09/11/2021 10.39, Philippe Mathieu-Daudé wrote: > > FYI, as of today, the latest merge history is red (last 10 days): > > https://cirrus-ci.com/github/qemu/qemu > > > > If we want to keep using this, we should somehow plug it to > > GitLab-CI (i.e. Travis-CI is run as an external job there) so > > the project maintainer can notice job failures. > > Well, considering that all the cirrus-run based jobs are currently failing > due to the non-working API token, that does not seem to work very well > either. Who owns the API token ? For other projects, this was addressed a while ago by refreshing the token. I would have tried this myself for QEMU but I don't have privileges on the QEMU projects in github/gitlab. > > Alternatively the windows job could be passed to GitLab: > > https://docs.gitlab.com/ee/ci/runners/runner_cloud/windows_runner_cloud.html > > See: > > https://lists.gnu.org/archive/html/qemu-devel/2021-07/msg02474.html > > ... the problem is again that the shared runners are only single-threaded, > so it's incredibly slow, especially if you have to re-install MSYS2 each > time. I once tried to improve the patch by caching the MSYS2 installation, > but it did not work that well either... (but if somebody wants to continue > my work, I can rebase and send it out again, just let me know). Potentially this is something where we can make sure of the Azure credits QEMU is getting, though it would require someone to figure out shared runner integration and maintain it... 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: [RFC PATCH v1 0/3] virtio: early detect 'modern' virtio
On Fri, 5 Nov 2021 03:42:33 -0400 "Michael S. Tsirkin" wrote: > > This series was only lightly tested. > > I think it's a good enough approach, and we are getting close > to release. For vhost - a new callback just for that? Would be ok. > Or just invoke set features - if this works. As of today I'm back from vacation. I intend to handle this problem/series with priority. Regards, Halil
Re: [PULL 0/3] Migration 20211109 patches
On 11/9/21 9:02 AM, Juan Quintela wrote: The following changes since commit 114f3c8cc427333dbae331dfd2ecae64676b087e: Merge remote-tracking branch 'remotes/philmd/tags/avocado-20211108' into staging (2021-11-08 18:50:09 +0100) are available in the Git repository at: https://github.com/juanquintela/qemu.git tags/migration-20211109-pull-request for you to fetch changes up to 91fe9a8dbd449a2f333aefb82ec8adb1f6424408: Reset the auto-converge counter at every checkpoint. (2021-11-09 08:48:36 +0100) Migration Pull request Hi This pull request includes: - fix sample-pages doc by hyman - cleanup colo pages by contiguous blocks by Rao - reset auto-converge by checkpoint by Rao. Please, apply. Hyman Huang(黄勇) (1): docs: fix 'sample-pages' option tag Rao, Lei (2): Reduce the PVM stop time during Checkpoint Reset the auto-converge counter at every checkpoint. qapi/migration.json | 2 +- migration/ram.h | 1 + migration/colo.c| 4 migration/ram.c | 57 ++--- 4 files changed, 60 insertions(+), 4 deletions(-) Applied, thanks. r~
Re: [PATCH v2] s390x: kvm: adjust diag318 resets to retain data
On 11/9/21 08:32, Christian Borntraeger wrote:
Am 08.11.21 um 22:13 schrieb Collin Walling:
The CPNC portion of the diag 318 data is erroneously reset during an
initial CPU reset caused by SIGP. Let's go ahead and relocate the
diag318_info field within the CPUS390XState struct such that it is
only zeroed during a clear reset. This way, the CPNC will be retained
for each VCPU in the configuration after the diag 318 instruction
has been invoked.
Additionally, the diag 318 data reset is handled via the CPU reset
code during a clear reset. This means some of the diag 318-specific
reset code can now be removed.
Signed-off-by: Collin Walling
Fixes: fabdada9357b ("s390: guest support for diagnose 0x318")
Reported-by: Christian Borntraeger
It would be good to add at least a comment in the diag308 handlers
where the value of cpnc is resetted during the resets that Janosch
mentioned.
---
Changelog:
v2
- handler uses run_on_cpu again
- reworded commit message slightly
- added fixes and reported-by tags
---
hw/s390x/s390-virtio-ccw.c | 3 ---
target/s390x/cpu-sysemu.c| 7 ---
target/s390x/cpu.h | 5 ++---
target/s390x/kvm/kvm.c | 14 +-
target/s390x/kvm/kvm_s390x.h | 1 -
5 files changed, 7 insertions(+), 23 deletions(-)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 653587ea62..51dcb83b0c 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -489,9 +489,6 @@ static void s390_machine_reset(MachineState *machine)
g_assert_not_reached();
}
-CPU_FOREACH(t) {
-run_on_cpu(t, s390_do_cpu_set_diag318, RUN_ON_CPU_HOST_ULONG(0));
-}
This needs to stay for the move to the clear reset area to work on other
diag308 subcodes. The reset will then be done twice for the clear reset
but that's fine.
Moving the diag318 data into the clear area means we only reset it on a
full cpu reset which is only done for diagnose 308 subcode 0 and maybe a
QEMU reset, I didn't fully follow the code there.
The other subcodes do an initial reset on the calling cpu and normal
resets on the others or just normal resets which don't touch the 318
data if we move it into the clear reset area.
Or did I miss something fundamental here?
s390_ipl_clear_reset_request();
}
diff --git a/target/s390x/cpu-sysemu.c b/target/s390x/cpu-sysemu.c
index 5471e01ee8..6d9f6d4402 100644
--- a/target/s390x/cpu-sysemu.c
+++ b/target/s390x/cpu-sysemu.c
@@ -299,10 +299,3 @@ void s390_enable_css_support(S390CPU *cpu)
kvm_s390_enable_css_support(cpu);
}
}
-
-void s390_do_cpu_set_diag318(CPUState *cs, run_on_cpu_data arg)
-{
-if (kvm_enabled()) {
-kvm_s390_set_diag318(cs, arg.host_ulong);
-}
-}
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 3153d053e9..1b94b91d87 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -63,6 +63,8 @@ struct CPUS390XState {
uint64_t etoken; /* etoken */
uint64_t etoken_extension; /* etoken extension */
+uint64_t diag318_info;
+
/* Fields up to this point are not cleared by initial CPU reset */
struct {} start_initial_reset_fields;
@@ -118,8 +120,6 @@ struct CPUS390XState {
uint16_t external_call_addr;
DECLARE_BITMAP(emergency_signals, S390_MAX_CPUS);
-uint64_t diag318_info;
-
#if !defined(CONFIG_USER_ONLY)
uint64_t tlb_fill_tec; /* translation exception code during tlb_fill */
int tlb_fill_exc;/* exception number seen during tlb_fill */
@@ -780,7 +780,6 @@ int s390_set_memory_limit(uint64_t new_limit, uint64_t
*hw_limit);
void s390_set_max_pagesize(uint64_t pagesize, Error **errp);
void s390_cmma_reset(void);
void s390_enable_css_support(S390CPU *cpu);
-void s390_do_cpu_set_diag318(CPUState *cs, run_on_cpu_data arg);
int s390_assign_subch_ioeventfd(EventNotifier *notifier, uint32_t sch_id,
int vq, bool assign);
#ifndef CONFIG_USER_ONLY
diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
index 5b1fdb55c4..8970d9ca55 100644
--- a/target/s390x/kvm/kvm.c
+++ b/target/s390x/kvm/kvm.c
@@ -1576,16 +1576,13 @@ static int handle_sw_breakpoint(S390CPU *cpu, struct
kvm_run *run)
return -ENOENT;
}
-void kvm_s390_set_diag318(CPUState *cs, uint64_t diag318_info)
+static void set_diag_318(CPUState *cs, run_on_cpu_data arg)
{
CPUS390XState *env = &S390_CPU(cs)->env;
-/* Feat bit is set only if KVM supports sync for diag318 */
-if (s390_has_feat(S390_FEAT_DIAG_318)) {
-env->diag318_info = diag318_info;
-cs->kvm_run->s.regs.diag318 = diag318_info;
-cs->kvm_run->kvm_dirty_regs |= KVM_SYNC_DIAG318;
-}
+env->diag318_info = arg.host_ulong;
+cs->kvm_run->s.regs.diag318 = arg.host_ulong;
+cs->kvm_run->kvm_dirty_regs |= KVM_SYNC_DIAG318;
}
static void handle_d
Re: Qemu and ARM secure state.
On Mon, 8 Nov 2021 at 22:09, Jean-Christophe DUBOIS wrote: > OK, so one problem seems to be that PSCI-via-SMC is enabled on i.MX6UL > when there is no built in PSCI related function on this processor. > > According the Linux DTS, i.MX7 (solo and dual) processors have a > somewhat PSCI related "entry-method" > (https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/imx7s.dtsi). > But it is not clear to me how this is used and this seems a bit strange > as "entry-method" seems to be mostly used on arm64 and there is no other > PSCI related information in the i.MX7 DTS files. Yeah, PSCI was an interface introduced mostly with aarch64. In the 32-bit world bringing up multiple CPUs was complete anarchy -- the way the kernel told the secure firmware that it should start up a secondary core was entirely determined by the firmware, and the kernel had to have board-specific code to do this. (For the 32-bit imx boards I think this is in arch/arm/mach-imx/src.c.) For aarch64 we had a clean slate and took the opportunity to insist that all boards did it the same way, ie using PSCI. (There are other useful things PSCI allows, but standardising secondary boot is the one that matters for this discussion.) So if a platform's firmware implements PSCI, all the dts file has to do is say so, and then there's no need for board-specific "start secondary CPUs" code. PSCI does define an aarch32 interface, but there are a lot of legacy older boards (and new flavours of boards in long-standing design families) which still do things the old way in aarch32 land. Typically the top-level "PSCI is available" node is added by the firmware. (QEMU will do this too when it's emulating PSCI firmware) -- if the board code enables the psci-conduit it will add an appropriate psci node in the hw/arm/boot.c code.) > As a matter of fact > previous quad or dual i.MX6 were not supporting PSCI. Instead they were > using a proprietary method through the internal SRC device (and i.MX7 > also has a similar internal SRC device). But let's assume Linux on i.mx7 > is actually using PSCI to handle processors. > > Thinking about it, I guess this might be u-boot that sets an EL3 monitor > software that is able to handle PSCI requests for the Linux kernel. If > this is the case, it make sense that Qemu emulates the PSCI services > normally provided by u-boot to be able to boot linux directly (without > booting a real u-boot prior to linux). All is well and nice. Yes, that's the way it works. The EL3 firmware is supposed to provide PSCI. For aarch64 the kernel is never entered in EL3 -- it will always run at EL2 or EL1. (This is unlike aarch32, where in some cases you might run the kernel in secure-SVC, although even there starting the kernel in NS-SVC or NS-Hyp is more common.) > But then if I want to boot and test the u-boot binary (or any trusted OS > for the matter) on a Qemu emulated i.MX7 (to later boot an hypervisor or > an OS), it would be rather strange that any PSCI related service > requested by the hypervisor/OS would be handled by Qemu directly and > not by the u-boot code (or any other EL3 code) running on the processor. Exactly. This is why the board code is supposed to set things up so that if we are starting the guest code in EL1 or EL2 then we enable the PSCI-via-SMC support, and if we're starting the guest code in EL3 then we do not. > How is it supposed to work? How can I tell Qemu (dynamically?) if I want > it to provide (or not) the PSCI services (and more generally SMC/HVC > services). If you want PSCI via SMC or HVC, then set the psci-conduit property on the CPUs to QEMU_PSCI_CONDUIT_SMC or QEMU_PSCI_CONDUIT_HVC. If you do not want QEMU to provide PSCI, then leave psci-conduit at its default (which is QEMU_PSCI_CONDUIT_DISABLED). How can I tell it that I want to handle all SMC/EL3 services > by myself even if the "psci-conduit" is already set to SMC in Qemu? It's the imx7 code that's setting psci-conduit, so it should not do that if it doesn't want that (and also should either start or not start the secondary cpus powered off, depending on what the hardware-to-firmware interface is supposed to be.) This is a bit awkward, because the boards we initially wanted PSCI for (notably virt) don't have an SoC object, so the code creating CPUs is in the same source file as the code that knows whether it's booting a kernel directly or not, and so it just open-codes the decision logic. With the imx, the CPU creation is in the source code for the SoC object which is abstracted away from the board model code. So we'd need to sort out how to plumb that information into the SoC object (or have the SoC object's code that creates the CPUs call some function to find out). -- PMM
Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k
On Thu, Nov 04, 2021 at 03:41:23PM +0100, Christian Schoenebeck wrote: > On Mittwoch, 3. November 2021 12:33:33 CET Stefan Hajnoczi wrote: > > On Mon, Nov 01, 2021 at 09:29:26PM +0100, Christian Schoenebeck wrote: > > > On Donnerstag, 28. Oktober 2021 11:00:48 CET Stefan Hajnoczi wrote: > > > > On Mon, Oct 25, 2021 at 05:03:25PM +0200, Christian Schoenebeck wrote: > > > > > On Montag, 25. Oktober 2021 12:30:41 CEST Stefan Hajnoczi wrote: > > > > > > On Thu, Oct 21, 2021 at 05:39:28PM +0200, Christian Schoenebeck > > > > > > wrote: > > > > > > > On Freitag, 8. Oktober 2021 18:08:48 CEST Christian Schoenebeck > > > > > > > wrote: > > > > > > > > On Freitag, 8. Oktober 2021 16:24:42 CEST Christian Schoenebeck > > > > > > > > wrote: > > > > > > > > > On Freitag, 8. Oktober 2021 09:25:33 CEST Greg Kurz wrote: > > > > > > > > > > On Thu, 7 Oct 2021 16:42:49 +0100 > > > > > > > > > > > > > > > > > > > > Stefan Hajnoczi wrote: > > > > > > > > > > > On Thu, Oct 07, 2021 at 02:51:55PM +0200, Christian > > > > > > > > > > > Schoenebeck wrote: > > > > > > > > > > > > On Donnerstag, 7. Oktober 2021 07:23:59 CEST Stefan > > > > > > > > > > > > Hajnoczi wrote: > > > > > > > > > > > > > On Mon, Oct 04, 2021 at 09:38:00PM +0200, Christian > > > > > > > > > > > > > Schoenebeck > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > At the moment the maximum transfer size with virtio > > > > > > > > > > > > > > is > > > > > > > > > > > > > > limited > > > > > > > > > > > > > > to > > > > > > > > > > > > > > 4M > > > > > > > > > > > > > > (1024 * PAGE_SIZE). This series raises this limit to > > > > > > > > > > > > > > its > > > > > > > > > > > > > > maximum > > > > > > > > > > > > > > theoretical possible transfer size of 128M (32k > > > > > > > > > > > > > > pages) > > > > > > > > > > > > > > according > > > > > > > > > > > > > > to > > > > > > > > > > > > > > the > > > > > > > > > > > > > > virtio specs: > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/ > > > > > > > > > > > > > > virt > > > > > > > > > > > > > > io-v > > > > > > > > > > > > > > 1.1- > > > > > > > > > > > > > > cs > > > > > > > > > > > > > > 01 > > > > > > > > > > > > > > .html# > > > > > > > > > > > > > > x1-240006 > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christian, > > > > > > > > > > > > > > > > > > > > > > > I took a quick look at the code: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Thanks Stefan for sharing virtio expertise and helping > > > > > > > > > > Christian > > > > > > > > > > ! > > > > > > > > > > > > > > > > > > > > > > > - The Linux 9p driver restricts descriptor chains to > > > > > > > > > > > > > 128 > > > > > > > > > > > > > elements > > > > > > > > > > > > > > > > > > > > > > > > > > (net/9p/trans_virtio.c:VIRTQUEUE_NUM) > > > > > > > > > > > > > > > > > > > > > > > > Yes, that's the limitation that I am about to remove > > > > > > > > > > > > (WIP); > > > > > > > > > > > > current > > > > > > > > > > > > kernel > > > > > > > > > > > > patches: > > > > > > > > > > > > https://lore.kernel.org/netdev/cover.1632327421.git.linu > > > > > > > > > > > > x_os > > > > > > > > > > > > s@cr > > > > > > > > > > > > udeb > > > > > > > > > > > > yt > > > > > > > > > > > > e. > > > > > > > > > > > > com/> > > > > > > > > > > > > > > > > > > > > > > I haven't read the patches yet but I'm concerned that > > > > > > > > > > > today > > > > > > > > > > > the > > > > > > > > > > > driver > > > > > > > > > > > is pretty well-behaved and this new patch series > > > > > > > > > > > introduces a > > > > > > > > > > > spec > > > > > > > > > > > violation. Not fixing existing spec violations is okay, > > > > > > > > > > > but > > > > > > > > > > > adding > > > > > > > > > > > new > > > > > > > > > > > ones is a red flag. I think we need to figure out a clean > > > > > > > > > > > solution. > > > > > > > > > > > > > > > > > > Nobody has reviewed the kernel patches yet. My main concern > > > > > > > > > therefore > > > > > > > > > actually is that the kernel patches are already too complex, > > > > > > > > > because > > > > > > > > > the > > > > > > > > > current situation is that only Dominique is handling 9p > > > > > > > > > patches on > > > > > > > > > kernel > > > > > > > > > side, and he barely has time for 9p anymore. > > > > > > > > > > > > > > > > > > Another reason for me to catch up on reading current kernel > > > > > > > > > code > > > > > > > > > and > > > > > > > > > stepping in as reviewer of 9p on kernel side ASAP, independent > > > > > > > > > of > > > > > > > > > this > > > > > > > > > issue. > > > > > > > > > > > > > > > > > > As for current kernel patches' complexity: I can certainly > > > > > > > > > drop > > > > > > > > > patch > > > > > > > > > 7 > > > > > > > > > entirely as it is probably just overkill. Patch 4 is then the > > > > > > > > > biggest > > > > > > > > > chunk, I have to see if I can simplify it, and whe
[PULL 0/2] M68k for 6.2 patches
The following changes since commit 85549204552b624fe254831537e7a0f6450228b8: Merge remote-tracking branch 'remotes/juanquintela/tags/migration-20211109-pull-request' into staging (2021-11-09 09:41:31 +0100) are available in the Git repository at: git://github.com/vivier/qemu-m68k.git tags/m68k-for-6.2-pull-request for you to fetch changes up to 6ed25621f2890d8f1c3b9e6f7a0e91c841aea1f8: hw: m68k: virt: Add compat machine for 6.2 (2021-11-09 12:14:18 +0100) m68k pull request 20211109 Add virt machine types for 6.1 and 6.2 Laurent Vivier (2): hw: m68k: virt: Add compat machine for 6.1 hw: m68k: virt: Add compat machine for 6.2 hw/m68k/virt.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) -- 2.31.1
[PULL 1/2] hw: m68k: virt: Add compat machine for 6.1
Add the missing machine type for m68k/virt
Cc: qemu-sta...@nongnu.org
Signed-off-by: Laurent Vivier
Message-Id: <20211106194158.4068596-2-laur...@vivier.eu>
Signed-off-by: Laurent Vivier
---
hw/m68k/virt.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 4e8bce5aa6f7..0d9e3f83c169 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -304,7 +304,14 @@ type_init(virt_machine_register_types)
} \
type_init(machvirt_machine_##major##_##minor##_init);
+static void virt_machine_6_1_options(MachineClass *mc)
+{
+}
+DEFINE_VIRT_MACHINE(6, 1, true)
+
static void virt_machine_6_0_options(MachineClass *mc)
{
+virt_machine_6_1_options(mc);
+compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len);
}
-DEFINE_VIRT_MACHINE(6, 0, true)
+DEFINE_VIRT_MACHINE(6, 0, false)
--
2.31.1
Re: Failure of hot plugging secondary virtio_blk into q35 Windows 2019
On Tue, Nov 9, 2021 at 3:23 PM Daniel P. Berrangé wrote: > > On Tue, Nov 09, 2021 at 12:41:39PM +0530, Ani Sinha wrote: > > > > +gerd > > > > On Mon, 8 Nov 2021, Annie.li wrote: > > > > > Update: > > > > > > I've tested q35 guest w/o OVMF, the APCI PCI hot-plugging works well in > > > q35 > > > guest. Seems this issue only happens in q35 guest w/ OVMF. > > > > > > Looks that there is already a bug filed against this hotplug issue in q35 > > > guest w/ OVMF, > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2004829 > > > > > > In this bug, it is recommended to add "-global > > > ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off \" on qemu command for > > > 6.1. > > > However, with this option for 6.1(PCIe native hotplug), there still are > > > kinds > > > of issues. For example, one of them is the deleted virtio_blk device still > > > shows in the Device Manager in Windows q35 guest, the operation of > > > re-scanning > > > new hardware takes forever there. This means both PCIe native hotplug and > > > ACPI > > > hotplug all have issues in q35 guests. > > > > This is sad. > > > > > > > > Per comments in this bug, changes in both OVMF and QEMU are necessary to > > > support ACPI hot plug in q35 guest. The fixes may likely be available in > > > QEMU > > > 6.2.0. > > > > So we are in soft code freeze for 6.2: > > https://wiki.qemu.org/Planning/6.2 > > > > I am curious about Gerd's comment #10: > > "The 6.2 rebase should make hotplug work > > again with the default configuration." > > > > Sadly I have not seen any public discussion on what we want to do > > for the issues with acpi hotplug for bridges in q35. > > I've raised one of the problems a week ago and there's a promised > fix > > https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg00558.html So https://gitlab.com/qemu-project/qemu/-/issues/641 is the same as https://bugzilla.redhat.com/show_bug.cgi?id=2006409 isn't it? > > but we're now a week after freeze and still no patch has been posted > AFAIK. > > IMHO it is pretty much time to revert to native hotplug, otherwise > we're going to risk getting too late into freeze to do anything, and > end up shipping with broken PCI hotplug again in 6.2 > > 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 :| >
[PULL 2/2] hw: m68k: virt: Add compat machine for 6.2
Add the missing machine type for m68k/virt
Signed-off-by: Laurent Vivier
Message-Id: <20211106194158.4068596-3-laur...@vivier.eu>
Signed-off-by: Laurent Vivier
---
hw/m68k/virt.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 0d9e3f83c169..978c26e025a7 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -304,10 +304,17 @@ type_init(virt_machine_register_types)
} \
type_init(machvirt_machine_##major##_##minor##_init);
+static void virt_machine_6_2_options(MachineClass *mc)
+{
+}
+DEFINE_VIRT_MACHINE(6, 2, true)
+
static void virt_machine_6_1_options(MachineClass *mc)
{
+virt_machine_6_2_options(mc);
+compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len);
}
-DEFINE_VIRT_MACHINE(6, 1, true)
+DEFINE_VIRT_MACHINE(6, 1, false)
static void virt_machine_6_0_options(MachineClass *mc)
{
--
2.31.1
Re: Failure of hot plugging secondary virtio_blk into q35 Windows 2019
On Tue, Nov 09, 2021 at 04:40:10PM +0530, Ani Sinha wrote: > On Tue, Nov 9, 2021 at 3:23 PM Daniel P. Berrangé wrote: > > > > On Tue, Nov 09, 2021 at 12:41:39PM +0530, Ani Sinha wrote: > > > > > > +gerd > > > > > > On Mon, 8 Nov 2021, Annie.li wrote: > > > > > > > Update: > > > > > > > > I've tested q35 guest w/o OVMF, the APCI PCI hot-plugging works well in > > > > q35 > > > > guest. Seems this issue only happens in q35 guest w/ OVMF. > > > > > > > > Looks that there is already a bug filed against this hotplug issue in > > > > q35 > > > > guest w/ OVMF, > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2004829 > > > > > > > > In this bug, it is recommended to add "-global > > > > ICH9-LPC.acpi-pci-hotplug-with-bridge-support=off \" on qemu command > > > > for 6.1. > > > > However, with this option for 6.1(PCIe native hotplug), there still are > > > > kinds > > > > of issues. For example, one of them is the deleted virtio_blk device > > > > still > > > > shows in the Device Manager in Windows q35 guest, the operation of > > > > re-scanning > > > > new hardware takes forever there. This means both PCIe native hotplug > > > > and ACPI > > > > hotplug all have issues in q35 guests. > > > > > > This is sad. > > > > > > > > > > > Per comments in this bug, changes in both OVMF and QEMU are necessary to > > > > support ACPI hot plug in q35 guest. The fixes may likely be available > > > > in QEMU > > > > 6.2.0. > > > > > > So we are in soft code freeze for 6.2: > > > https://wiki.qemu.org/Planning/6.2 > > > > > > I am curious about Gerd's comment #10: > > > "The 6.2 rebase should make hotplug work > > > again with the default configuration." > > > > > > Sadly I have not seen any public discussion on what we want to do > > > for the issues with acpi hotplug for bridges in q35. > > > > I've raised one of the problems a week ago and there's a promised > > fix > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-11/msg00558.html > > So https://gitlab.com/qemu-project/qemu/-/issues/641 is the same as > https://bugzilla.redhat.com/show_bug.cgi?id=2006409 > > isn't it? Yes, one upstream, one downstream. 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: Cirrus-CI all red
Daniel P. Berrangé writes: > On Tue, Nov 09, 2021 at 10:45:18AM +0100, Thomas Huth wrote: >> On 09/11/2021 10.39, Philippe Mathieu-Daudé wrote: >> > FYI, as of today, the latest merge history is red (last 10 days): >> > https://cirrus-ci.com/github/qemu/qemu >> > >> > If we want to keep using this, we should somehow plug it to >> > GitLab-CI (i.e. Travis-CI is run as an external job there) so >> > the project maintainer can notice job failures. >> >> Well, considering that all the cirrus-run based jobs are currently failing >> due to the non-working API token, that does not seem to work very well >> either. > > Who owns the API token ? For other projects, this was addressed a while > ago by refreshing the token. I would have tried this myself for QEMU > but I don't have privileges on the QEMU projects in github/gitlab. OK I've updated the token (after I figured out the path to it): - top right, Settings - scroll to bottom "Your GitHub Organizations" - click gear icon - scroll to API settings, click Generate New Token It seems to be triggering the builds now although GitLab still reports failures for some other reason now. > >> > Alternatively the windows job could be passed to GitLab: >> > https://docs.gitlab.com/ee/ci/runners/runner_cloud/windows_runner_cloud.html >> >> See: >> >> https://lists.gnu.org/archive/html/qemu-devel/2021-07/msg02474.html >> >> ... the problem is again that the shared runners are only single-threaded, >> so it's incredibly slow, especially if you have to re-install MSYS2 each >> time. I once tried to improve the patch by caching the MSYS2 installation, >> but it did not work that well either... (but if somebody wants to continue >> my work, I can rebase and send it out again, just let me know). > > Potentially this is something where we can make sure of the Azure credits > QEMU is getting, though it would require someone to figure out shared > runner integration and maintain it... > > Regards, > Daniel -- Alex Bennée
Re: Cirrus-CI all red
On Tue, Nov 09, 2021 at 11:27:42AM +, Alex Bennée wrote: > > Daniel P. Berrangé writes: > > > On Tue, Nov 09, 2021 at 10:45:18AM +0100, Thomas Huth wrote: > >> On 09/11/2021 10.39, Philippe Mathieu-Daudé wrote: > >> > FYI, as of today, the latest merge history is red (last 10 days): > >> > https://cirrus-ci.com/github/qemu/qemu > >> > > >> > If we want to keep using this, we should somehow plug it to > >> > GitLab-CI (i.e. Travis-CI is run as an external job there) so > >> > the project maintainer can notice job failures. > >> > >> Well, considering that all the cirrus-run based jobs are currently failing > >> due to the non-working API token, that does not seem to work very well > >> either. > > > > Who owns the API token ? For other projects, this was addressed a while > > ago by refreshing the token. I would have tried this myself for QEMU > > but I don't have privileges on the QEMU projects in github/gitlab. > > OK I've updated the token (after I figured out the path to it): > > - top right, Settings > - scroll to bottom "Your GitHub Organizations" > - click gear icon > - scroll to API settings, click Generate New Token > > It seems to be triggering the builds now although GitLab still reports > failures for some other reason now. The cirrus-run image we're using is lockde to version 0.3.0. I'm testing an update to version 0.5.0 which has various reliability fixes, essentially around making it retry on transient errors. 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] acpi: tpm: Add missing device identification objects
On 11/9/21 02:30, Marc-André Lureau wrote:
Hi
On Tue, Nov 9, 2021 at 11:25 AM Marc-André Lureau
wrote:
On Tue, Nov 9, 2021 at 4:37 AM Stefan Berger wrote:
Add missing device identification objects _STR and _UID. They will appear
as files 'description' and 'uid' under Linux sysfs.
Cc: Shannon Zhao
Cc: Michael S. Tsirkin
Cc: Igor Mammedov
Cc: Ani Sinha
Fixes: #708
Signed-off-by: Stefan Berger
Reviewed-by: Marc-André Lureau
(on my host, for some reason the UID is 1, does this matter?)
Let's make it '1'. My TPM 1.2 machine shows also '1'.
specs:
"6.1.12 _UID (Unique ID)
This object provides OSPM with a logical device ID that does not change
across reboots. This object is
optional, but is required when the device has no other way to report a
persistent unique device ID. The
_UID must be unique across all devices with either a common _HID or
_CID. [...]"
And shouldn't this be done also for TIS device?
Fixed. It was missing for the CRB device.
Thanks.
Stefan
---
hw/arm/virt-acpi-build.c | 1 +
hw/i386/acpi-build.c | 4
2 files changed, 5 insertions(+)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 674f902652..09456424aa 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -228,6 +228,7 @@ static void acpi_dsdt_add_tpm(Aml *scope, VirtMachineState
*vms)
Aml *dev = aml_device("TPM0");
aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
+aml_append(dev, aml_name_decl("_STR", aml_string("TPM 2.0 Device")));
aml_append(dev, aml_name_decl("_UID", aml_int(0)));
Aml *crs = aml_resource_template();
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a3ad6abd33..d6d3541407 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1808,6 +1808,10 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
dev = aml_device("TPM");
aml_append(dev, aml_name_decl("_HID",
aml_string("MSFT0101")));
+aml_append(dev,
+ aml_name_decl("_STR",
+ aml_string("TPM 2.0 Device")));
+aml_append(dev, aml_name_decl("_UID", aml_int(0)));
} else {
dev = aml_device("ISA.TPM");
aml_append(dev, aml_name_decl("_HID",
--
2.31.1
Re: [RESEND PATCH v9 16/28] target/loongarch: Add disassembler
On 11/8/21 4:08 AM, Song Gao wrote:
+/* operand extractors */
+#define IM_12 12
+#define IM_14 14
+#define IM_15 15
+#define IM_16 16
+#define IM_20 20
+#define IM_21 21
+#define IM_26 26
+
+static uint32_t operand_r1(uint32_t insn)
+{
+return insn & 0x1f;
+}
+
+static uint32_t operand_r2(uint32_t insn)
+{
+return (insn >> 5) & 0x1f;
+}
+
+static uint32_t operand_r3(uint32_t insn)
+{
+return (insn >> 10) & 0x1f;
+}
+
+static uint32_t operand_r4(uint32_t insn)
+{
+return (insn >> 15) & 0x1f;
+}
+
+static uint32_t operand_u6(uint32_t insn)
+{
+return (insn >> 10) & 0x3f;
+}
+
+static uint32_t operand_bw1(uint32_t insn)
+{
+return (insn >> 10) & 0x1f;
+}
+
+static uint32_t operand_bw2(uint32_t insn)
+{
+return (insn >> 16) & 0x1f;
+}
+
+static uint32_t operand_bd1(uint32_t insn)
+{
+return (insn >> 10) & 0x3f;
+}
+
+static uint32_t operand_bd2(uint32_t insn)
+{
+return (insn >> 16) & 0x3f;
+}
+
+static uint32_t operand_sa(uint32_t insn)
+{
+return (insn >> 15) & 0x3;
+}
+
+static int32_t operand_im20(uint32_t insn)
+{
+int32_t imm = (int32_t)((insn >> 5) & 0xf);
+return imm > (1 << 19) ? imm - (1 << 20) : imm;
+}
+
+static int32_t operand_im16(uint32_t insn)
+{
+int32_t imm = (int32_t)((insn >> 10) & 0x);
+return imm > (1 << 15) ? imm - (1 << 16) : imm;
+}
+
+static int32_t operand_im14(uint32_t insn)
+{
+int32_t imm = (int32_t)((insn >> 10) & 0x3fff);
+return imm > (1 << 13) ? imm - (1 << 14) : imm;
+}
+
+static int32_t operand_im12(uint32_t insn)
+{
+int32_t imm = (int32_t)((insn >> 10) & 0xfff);
+return imm > (1 << 11) ? imm - (1 << 12) : imm;
+}
+
+static uint32_t operand_cd(uint32_t insn)
+{
+return insn & 0x7;
+}
+
+static uint32_t operand_cj(uint32_t insn)
+{
+return (insn >> 5) & 0x7;
+}
+
+static uint32_t operand_code(uint32_t insn)
+{
+return insn & 0x7fff;
+}
+
+static int32_t operand_whint(uint32_t insn)
+{
+int32_t imm = (int32_t)(insn & 0x7fff);
+return imm > (1 << 14) ? imm - (1 << 15) : imm;
+}
+
+static int32_t operand_ofs21(uint32_t insn)
+{
+int32_t imm = (((int32_t)insn & 0x1f) << 16) |
+((insn >> 10) & 0x);
+return imm > (1 << 20) ? imm - (1 << 21) : imm;
+}
+
+static int32_t operand_ofs26(uint32_t insn)
+{
+int32_t imm = (((int32_t)insn & 0x3ff) << 16) |
+((insn >> 10) & 0x);
+return imm > (1 << 25) ? imm - (1 << 26) : imm;
+}
+
+static uint32_t operand_fcond(uint32_t insn)
+{
+return (insn >> 15) & 0x1f;
+}
+
+static uint32_t operand_sel(uint32_t insn)
+{
+return (insn >> 15) & 0x7;
+}
+
+/* decode operands */
+static void decode_insn_operands(la_decode *dec)
+{
+uint32_t insn = dec->insn;
+switch (dec->codec) {
+case la_codec_2r:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+break;
+case la_codec_2r_u5:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->r3 = operand_r3(insn);
+break;
+case la_codec_2r_u6:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->r3 = operand_u6(insn);
+break;
+case la_codec_2r_2bw:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->r3 = operand_bw1(insn);
+dec->r4 = operand_bw2(insn);
+break;
+case la_codec_2r_2bd:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->r3 = operand_bd1(insn);
+dec->r4 = operand_bd2(insn);
+break;
+case la_codec_3r:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->r3 = operand_r3(insn);
+break;
+case la_codec_3r_rd0:
+dec->r1 = 0;
+dec->r2 = operand_r2(insn);
+dec->r3 = operand_r3(insn);
+break;
+case la_codec_3r_sa:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->r3 = operand_r3(insn);
+dec->r4 = operand_sa(insn);
+break;
+case la_codec_4r:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->r3 = operand_r3(insn);
+dec->r4 = operand_r4(insn);
+break;
+case la_codec_r_im20:
+dec->r1 = operand_r1(insn);
+dec->imm = operand_im20(insn);
+dec->bit = IM_20;
+break;
+case la_codec_2r_im16:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->imm = operand_im16(insn);
+dec->bit = IM_16;
+break;
+case la_codec_2r_im14:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->imm = operand_im14(insn);
+dec->bit = IM_14;
+break;
+case la_codec_2r_im12:
+dec->r1 = operand_r1(insn);
+dec->r2 = operand_r2(insn);
+dec->imm = operand_im12(insn);
+dec->bit = IM_12;
+break;
+case la_codec_r_cd:
+dec->r1 = operand_cd(insn);
+dec->r2 = operand_r
Re: [RESEND PATCH v9 16/28] target/loongarch: Add disassembler
On 11/8/21 4:08 AM, Song Gao wrote: This patch adds support for disassembling via option '-d in_asm'. Signed-off-by: Song Gao Signed-off-by: Xiaojuan Yang Acked-by: Richard Henderson BTW, I did not ack this patch. I had acked a previous patch in which you imported some other disassembler from elsewhere. This is not that patch. r~
Re: [PATCH v4 2/2] tests/unit: Add an unit test for smp parsing
On 2021/11/9 17:36, Philippe Mathieu-Daudé wrote:
Hi,
On 10/28/21 17:09, Philippe Mathieu-Daudé wrote:
From: Yanan Wang
Now that we have a generic parser smp_parse(), let's add an unit
test for the code. All possible valid/invalid SMP configurations
that the user can specify are covered.
Signed-off-by: Yanan Wang
Reviewed-by: Andrew Jones
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20211026034659.22040-3-wangyana...@huawei.com>
Signed-off-by: Philippe Mathieu-Daudé
---
tests/unit/test-smp-parse.c | 594
MAINTAINERS | 1 +
tests/unit/meson.build | 1 +
3 files changed, 596 insertions(+)
create mode 100644 tests/unit/test-smp-parse.c
Could you have a look at this test failure please?
https://cirrus-ci.com/task/5823855357853696
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
G_TEST_SRCDIR=C:/Users/ContainerAdministrator/AppData/Local/Temp/cirrus-ci-build/tests/unit
G_TEST_BUILDDIR=C:/Users/ContainerAdministrator/AppData/Local/Temp/cirrus-ci-build/build/tests/unit
tests/unit/test-smp-parse.exe --tap -k
Test smp_parse failed!
Input configuration: (SMPConfiguration) {
.has_cpus= true, cpus= 1,
.has_sockets = false, sockets = 0,
.has_dies= false, dies= 0,
.has_cores = false, cores = 0,
.has_threads = false, threads = 0,
.has_maxcpus = false, maxcpus = 0,
}
Should be valid: no
Expected error report: Invalid SMP CPUs 1. The min CPUs supported by
machine '(null)' is 2
Result is valid: no
Output error report: Invalid SMP CPUs 1. The min CPUs supported by
machine '(NULL)' is 2
ERROR test-smp-parse - too few tests run (expected 2, got 0)
make: *** [Makefile.mtest:576: run-test-70] Error 1
.
Re: [RESEND PATCH v9 00/28] Add LoongArch linux-user emulation support
On 11/8/21 4:07 AM, Song Gao wrote: Patches need review: * 0002-target-loongarch-Add-core-definition.patch Why are you listing a patch to which I have given review, and you have in fact picked up? * 0028-linux-user-host-loongarch64-Populate-host_signal.h.patch Likewise. That said, the final two patches belong to Wang Xuerui's tcg/loongarch64 patch set, and have no bearing on compiling target/loongarch64. Aside from the disassembler, I think the target/loongarch64 parts of this are in good shape. We cannot include the linux-user/loongarch64 parts until the kernel patches are upstream. I hope that can make progress during the next qemu development cycle so that this code can be included in qemu 7.0. r~
Re: [PULL 0/6] Trivial branch for 6.2 patches
On 11/9/21 10:12 AM, Laurent Vivier wrote: The following changes since commit f10e7b9f6fc18be390b3bc189e04b5147eb8dbf8: Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-6.2-20211109' into staging (2021-11-09 07:18:33 +0100) are available in the Git repository at: git://github.com/vivier/qemu.git tags/trivial-branch-for-6.2-pull-request for you to fetch changes up to 66d96a1901b7d9cfdbc454d407710ca8bfb90947: docs/about/deprecated: Remove empty 'related binaries' section (2021-11-09 10:11:27 +0100) Trivial branch patches pull request 20211109 BALATON Zoltan (1): hmp: Add shortcut to stop command to match cont Laurent Vivier (1): tests/qtest/virtio-net: fix hotplug test case Philippe Mathieu-Daudé (4): hw/m68k: Fix typo in SPDX tag .mailmap: Fix more contributor entries meson: Fix 'interpretor' typo docs/about/deprecated: Remove empty 'related binaries' section .mailmap | 4 docs/about/deprecated.rst | 3 --- hmp-commands.hx| 4 ++-- hw/char/goldfish_tty.c | 2 +- hw/intc/goldfish_pic.c | 2 +- hw/intc/m68k_irqc.c| 2 +- hw/m68k/virt.c | 2 +- hw/misc/virt_ctrl.c| 2 +- include/hw/char/goldfish_tty.h | 2 +- include/hw/intc/goldfish_pic.h | 2 +- include/hw/intc/m68k_irqc.h| 2 +- include/hw/misc/virt_ctrl.h| 2 +- meson.build| 2 +- tests/qtest/virtio-net-test.c | 2 +- 14 files changed, 17 insertions(+), 16 deletions(-) Applied, thanks. r~
Re: [PATCH v4 2/2] tests/unit: Add an unit test for smp parsing
Hi,
On 2021/11/9 17:36, Philippe Mathieu-Daudé wrote:
Hi,
On 10/28/21 17:09, Philippe Mathieu-Daudé wrote:
From: Yanan Wang
Now that we have a generic parser smp_parse(), let's add an unit
test for the code. All possible valid/invalid SMP configurations
that the user can specify are covered.
Signed-off-by: Yanan Wang
Reviewed-by: Andrew Jones
Tested-by: Philippe Mathieu-Daudé
Message-Id: <20211026034659.22040-3-wangyana...@huawei.com>
Signed-off-by: Philippe Mathieu-Daudé
---
tests/unit/test-smp-parse.c | 594
MAINTAINERS | 1 +
tests/unit/meson.build | 1 +
3 files changed, 596 insertions(+)
create mode 100644 tests/unit/test-smp-parse.c
Could you have a look at this test failure please?
https://cirrus-ci.com/task/5823855357853696
MALLOC_PERTURB_=${MALLOC_PERTURB_:-$(( ${RANDOM:-0} % 255 + 1))}
G_TEST_SRCDIR=C:/Users/ContainerAdministrator/AppData/Local/Temp/cirrus-ci-build/tests/unit
G_TEST_BUILDDIR=C:/Users/ContainerAdministrator/AppData/Local/Temp/cirrus-ci-build/build/tests/unit
tests/unit/test-smp-parse.exe --tap -k
Test smp_parse failed!
Input configuration: (SMPConfiguration) {
.has_cpus= true, cpus= 1,
.has_sockets = false, sockets = 0,
.has_dies= false, dies= 0,
.has_cores = false, cores = 0,
.has_threads = false, threads = 0,
.has_maxcpus = false, maxcpus = 0,
}
Should be valid: no
Expected error report: Invalid SMP CPUs 1. The min CPUs supported by
machine '(null)' is 2
Result is valid: no
Output error report: Invalid SMP CPUs 1. The min CPUs supported by
machine '(NULL)' is 2
ERROR test-smp-parse - too few tests run (expected 2, got 0)
make: *** [Makefile.mtest:576: run-test-70] Error 1
.
Obviously, the name string for the tested machine type in cirrus-ci is
"NULL",
while the expected name string is "null". It was also "null" when running on
my Arm64 platform locally.
Anyway, I shouldn't have hardcoded this expected error message. I can
send a fix patch to make it more flexible then more stable. :)
Thanks,
Yanan
Re: [PATCH 12/15] hw/nvme: Initialize capability structures for primary/secondary controllers
On Nov 8 14:57, Łukasz Gieryk wrote:
> On Mon, Nov 08, 2021 at 09:25:58AM +0100, Klaus Jensen wrote:
> > On Nov 5 15:04, Łukasz Gieryk wrote:
> > > On Fri, Nov 05, 2021 at 09:46:28AM +0100, Łukasz Gieryk wrote:
> > > > On Thu, Nov 04, 2021 at 04:48:43PM +0100, Łukasz Gieryk wrote:
> > > > > On Wed, Nov 03, 2021 at 01:07:31PM +0100, Klaus Jensen wrote:
> > > > > > On Oct 7 18:24, Lukasz Maniak wrote:
> > > > > > > From: Łukasz Gieryk
> > > > > > >
> > > > > > > With two new properties (sriov_max_vi_per_vf,
> > > > > > > sriov_max_vq_per_vf) one
> > > > > > > can configure the maximum number of virtual queues and interrupts
> > > > > > > assignable to a single virtual device. The primary and secondary
> > > > > > > controller capability structures are initialized accordingly.
> > > > > > >
> > > > > > > Since the number of available queues (interrupts) now varies
> > > > > > > between
> > > > > > > VF/PF, BAR size calculation is also adjusted.
> > > > > > >
> > > > > >
> > > > > > While this patch allows configuring the VQFRSM and VIFRSM fields, it
> > > > > > implicitly sets VQFRT and VIFRT (i.e. by setting them to the
> > > > > > product of
> > > > > > sriov_max_vi_pervf and max_vfs). Which is just setting it to an
> > > > > > upper
> > > > > > bound and this removes a testable case for host software (e.g.
> > > > > > requesting more flexible resources than what is currently
> > > > > > available).
> > > > > >
> > > > > > This patch also requires that these parameters are set if
> > > > > > sriov_max_vfs
> > > > > > is. I think we can provide better defaults.
> > > > > >
> > > > >
> > > > > Originally I considered more params, but ended up coding the simplest,
> > > > > user-friendly solution, because I did not like the mess with so many
> > > > > parameters, and the flexibility wasn't needed for my use cases. But I
> > > > > do
> > > > > agree: others may need the flexibility. Case (FRT < max_vfs * FRSM) is
> > > > > valid and resembles an actual device.
> > > > >
> > > > > > How about,
> > > > > >
> > > > > > 1. if only sriov_max_vfs is set, then all VFs get private resources
> > > > > >equal to max_ioqpairs. Like before this patch. This limits the
> > > > > > number
> > > > > >of parameters required to get a basic setup going.
> > > > > >
> > > > > > 2. if sriov_v{q,i}_private is set (I suggested this parameter in
> > > > > > patch
> > > > > >10), the difference between that and max_ioqpairs become flexible
> > > > > >resources. Also, I'd be just fine with having
> > > > > > sriov_v{q,i}_flexible
> > > > > >instead and just make the difference become private resources.
> > > > > >Potato/potato.
> > > > > >
> > > > > >a. in the absence of sriov_max_v{q,i}_per_vf, set them to the
> > > > > > number
> > > > > > of calculated flexible resources.
> > > > > >
> > > > > > This probably smells a bit like bikeshedding, but I think this gives
> > > > > > more flexibility and better defaults, which helps with verifying
> > > > > > host
> > > > > > software.
> > > > > >
> > > > > > If we can't agree on this now, I suggest we could go ahead and
> > > > > > merge the
> > > > > > base functionality (i.e. private resources only) and ruminate some
> > > > > > more
> > > > > > about these parameters.
> > > > >
> > > > > The problem is that the spec allows VFs to support either only
> > > > > private,
> > > > > or only flexible resources.
> > > > >
> > > > > At this point I have to admit, that since my use cases for
> > > > > QEMU/Nvme/SRIOV require flexible resources, I haven’t paid much
> > > > > attention to the case with VFs having private resources. So this
> > > > > SR/IOV
> > > > > implementation doesn’t even support such case (max_vX_per_vf != 0).
> > > > >
> > > > > Let me summarize the possible config space, and how the current
> > > > > parameters (could) map to these (interrupt-related ones omitted):
> > > > >
> > > > > Flexible resources not supported (not implemented):
> > > > > - Private resources for PF = max_ioqpairs
> > > > > - Private resources per VF = ?
> > > > > - (error if flexible resources are configured)
> > > > >
> > > > > With flexible resources:
> > > > > - VQPRT, private resources for PF = max_ioqpairs
> > > > > - VQFRT, total flexible resources = max_vq_per_vf * num_vfs
> > > > > - VQFRSM, maximum assignable per VF= max_vq_per_vf
> > > > > - VQGRAN, granularity = #define constant
> > > > > - (error if private resources per VF are configured)
> > > > >
> > > > > Since I don’t want to misunderstand your suggestion: could you
> > > > > provide a
> > > > > similar map with your parameters, formulas, and explain how to
> > > > > determine
> > > > > if flexible resources are active? I want to be sure we are on the
> > > > > same page.
> > > > >
> > > >
> > > > I’ve just re-read through my email and decided that some bits need
> > > > clarification.
> > > >
> > > > This imple
Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1
On Tue, 9 Nov 2021, Laurent Vivier wrote:
Add the missing machine type for m68k/virt
Cc: qemu-sta...@nongnu.org
Signed-off-by: Laurent Vivier
Message-Id: <20211106194158.4068596-2-laur...@vivier.eu>
Signed-off-by: Laurent Vivier
---
hw/m68k/virt.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 4e8bce5aa6f7..0d9e3f83c169 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -304,7 +304,14 @@ type_init(virt_machine_register_types)
} \
type_init(machvirt_machine_##major##_##minor##_init);
+static void virt_machine_6_1_options(MachineClass *mc)
+{
+}
+DEFINE_VIRT_MACHINE(6, 1, true)
+
static void virt_machine_6_0_options(MachineClass *mc)
{
+virt_machine_6_1_options(mc);
+compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len);
}
-DEFINE_VIRT_MACHINE(6, 0, true)
+DEFINE_VIRT_MACHINE(6, 0, false)
I don't understand how these compat machines work but if these are empty
and essentially the same as the previous version why do we add a new
version in every release? Wouldn't it be enough to add new version when
there was an incompatible change? I mean, instead of listing machine and
getting a lot of virt-6.1, virt-6.0, virt-5.2,... or so, we'd only get
versions that are actually different such as virt-7.0, virt-5.2, virt-5.0
(maybe they are called differently, just an example) with the versionless
alias always pointing to the latest. Then when QEMU is updated one can see
if there was any change so should update the VM or keep using the older
versions. Or does it work like that and I'm missing it completely?
Regards,
BALATON Zoltan
[PATCH v2 01/30] target/loongarch: Update README
Mainly introduce how to run the softmmu Signed-off-by: Xiaojuan Yang Signed-off-by: Song Gao --- target/loongarch/README | 20 1 file changed, 20 insertions(+) diff --git a/target/loongarch/README b/target/loongarch/README index 09f809cf80..b307bd4091 100644 --- a/target/loongarch/README +++ b/target/loongarch/README @@ -71,6 +71,26 @@ ./qemu-loongarch64 /opt/clfs/usr/bin/pwd ... +- Softmmu emulation + + Add support softmmu emulation support in the following series patches. + Mainly emulate a virt 3A5000 board that is not exactly the same as the host. + Kernel code is on the github and the uefi code will be opened in the near future. + All required binaries can get from github for test. + + 1.Download kernel and the cross-tools.(vmlinux) + + wget https://github.com/loongson/linux + wget https://github.com/loongson/build-tools/releases/latest/download/loongarch64-clfs-20210831-cross-tools.tar.xz + + 2.Download the clfs-system and made a ramdisk with busybox.(ramdisk) + + 3.Run with command,eg: + + ./build/qemu-system-loongarch64 -m 4G -smp 16 --cpu Loongson-3A5000 --machine loongson7a -kernel ./vmlinux -initrd ./ramdisk -append "root=/dev/ram console=ttyS0,115200 rdinit=/sbin/init loglevel=8" -monitor tcp::4000,server,nowait -nographic + +The vmlinux and ramdisk binary can get from : +git clone https://github.com/yangxiaojuan-loongson/qemu-binary - Note. We can get the latest LoongArch documents or LoongArch tools at https://github.com/loongson/ -- 2.27.0
[PATCH v2 03/30] target/loongarch: Add basic vmstate description of CPU.
Signed-off-by: Xiaojuan Yang
Signed-off-by: Song Gao
---
target/loongarch/cpu.c | 4 +
target/loongarch/internals.h | 4 +
target/loongarch/machine.c | 154 +++
target/loongarch/meson.build | 6 ++
4 files changed, 168 insertions(+)
create mode 100644 target/loongarch/machine.c
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index 01a17d8221..a53c8ebfb5 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -12,6 +12,7 @@
#include "sysemu/qtest.h"
#include "exec/exec-all.h"
#include "qapi/qapi-commands-machine-target.h"
+#include "migration/vmstate.h"
#include "cpu.h"
#include "internals.h"
#include "fpu/softfloat-helpers.h"
@@ -297,6 +298,9 @@ static void loongarch_cpu_class_init(ObjectClass *c, void
*data)
cc->has_work = loongarch_cpu_has_work;
cc->dump_state = loongarch_cpu_dump_state;
cc->set_pc = loongarch_cpu_set_pc;
+#ifndef CONFIG_USER_ONLY
+dc->vmsd = &vmstate_loongarch_cpu;
+#endif
cc->disas_set_info = loongarch_cpu_disas_set_info;
#ifdef CONFIG_TCG
cc->tcg_ops = &loongarch_tcg_ops;
diff --git a/target/loongarch/internals.h b/target/loongarch/internals.h
index e9e63742c4..49ed6829d7 100644
--- a/target/loongarch/internals.h
+++ b/target/loongarch/internals.h
@@ -25,4 +25,8 @@ const char *loongarch_exception_name(int32_t exception);
void restore_fp_status(CPULoongArchState *env);
+#ifndef CONFIG_USER_ONLY
+extern const VMStateDescription vmstate_loongarch_cpu;
+#endif
+
#endif
diff --git a/target/loongarch/machine.c b/target/loongarch/machine.c
new file mode 100644
index 00..b628374814
--- /dev/null
+++ b/target/loongarch/machine.c
@@ -0,0 +1,154 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * QEMU LoongArch machine State
+ *
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ */
+
+#include "qemu/osdep.h"
+#include "cpu.h"
+#include "migration/cpu.h"
+
+/* LoongArch CPU state */
+
+const VMStateDescription vmstate_loongarch_cpu = {
+.name = "cpu",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+
+VMSTATE_UINTTL_ARRAY(env.gpr, LoongArchCPU, 32),
+VMSTATE_UINTTL(env.pc, LoongArchCPU),
+VMSTATE_UINT64_ARRAY(env.fpr, LoongArchCPU, 32),
+VMSTATE_UINT32(env.fcsr0, LoongArchCPU),
+
+/* Remaining CSR registers */
+VMSTATE_UINT64(env.CSR_CRMD, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PRMD, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_EUEN, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_MISC, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_ECFG, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_ESTAT, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_ERA, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_BADV, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_BADI, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_EENTRY, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBIDX, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBEHI, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBELO0, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBELO1, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_ASID, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PGDL, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PGDH, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PGD, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PWCL, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PWCH, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_STLBPS, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_RVACFG, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_CPUID, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PRCFG1, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PRCFG2, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_PRCFG3, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_SAVE0, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_SAVE1, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_SAVE2, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_SAVE3, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_SAVE4, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_SAVE5, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_SAVE6, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_SAVE7, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TMID, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TCFG, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TVAL, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_CNTC, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TINTCLR, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_LLBCTL, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_IMPCTL1, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_IMPCTL2, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBRENTRY, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBRBADV, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBRERA, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBRSAVE, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBRELO0, LoongArchCPU),
+VMSTATE_UINT64(env.CSR_TLBRELO1, LoongArchCPU),
+
[PATCH v2 04/30] target/loongarch: Define exceptions for LoongArch.
This patch introduces all possible exceptions.
Signed-off-by: Xiaojuan Yang
Signed-off-by: Song Gao
---
target/loongarch/cpu.c | 13 +
target/loongarch/cpu.h | 17 +++--
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index a53c8ebfb5..16443159cc 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -37,6 +37,19 @@ static const char * const excp_names[EXCP_LAST + 1] = {
[EXCP_BREAK] = "Break",
[EXCP_INE] = "Instruction Non-existent",
[EXCP_FPE] = "Floating Point Exception",
+[EXCP_IPE] = "Error privilege level access",
+[EXCP_TLBL] = "TLB load",
+[EXCP_TLBS] = "TLB store",
+[EXCP_INST_NOTAVAIL] = "TLB inst not exist",
+[EXCP_TLBM] = "TLB modify",
+[EXCP_TLBPE] = "TLB priviledged error",
+[EXCP_TLBNX] = "TLB execute-inhibit",
+[EXCP_TLBNR] = "TLB read-inhibit",
+[EXCP_EXT_INTERRUPT] = "Interrupt",
+[EXCP_DBP] = "Debug breakpoint",
+[EXCP_IBE] = "Instruction bus error",
+[EXCP_DBE] = "Data bus error",
+[EXCP_DINT] = "Debug interrupt",
};
const char *loongarch_exception_name(int32_t exception)
diff --git a/target/loongarch/cpu.h b/target/loongarch/cpu.h
index 10fcd53104..399c4cb5e8 100644
--- a/target/loongarch/cpu.h
+++ b/target/loongarch/cpu.h
@@ -369,8 +369,21 @@ enum {
EXCP_BREAK,
EXCP_INE,
EXCP_FPE,
-
-EXCP_LAST = EXCP_FPE,
+EXCP_IPE,
+EXCP_TLBL,
+EXCP_TLBS,
+EXCP_INST_NOTAVAIL,
+EXCP_TLBM,
+EXCP_TLBPE,
+EXCP_TLBNX,
+EXCP_TLBNR,
+EXCP_EXT_INTERRUPT,
+EXCP_DBP,
+EXCP_IBE,
+EXCP_DBE,
+EXCP_DINT,
+
+EXCP_LAST = EXCP_DINT,
};
#define LOONGARCH_CPU_TYPE_SUFFIX "-" TYPE_LOONGARCH_CPU
--
2.27.0
[PATCH v2 05/30] target/loongarch: Implement qmp_query_cpu_definitions()
This patch introduces qmp_query_cpu_definitions interface.
Signed-off-by: Xiaojuan Yang
Signed-off-by: Song Gao
Reviewed-by: Richard Henderson
---
qapi/machine-target.json | 6 --
target/loongarch/cpu.c | 28
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/qapi/machine-target.json b/qapi/machine-target.json
index f5ec4bc172..682dc86b42 100644
--- a/qapi/machine-target.json
+++ b/qapi/machine-target.json
@@ -324,7 +324,8 @@
'TARGET_ARM',
'TARGET_I386',
'TARGET_S390X',
- 'TARGET_MIPS' ] } }
+ 'TARGET_MIPS',
+ 'TARGET_LOONGARCH64' ] } }
##
# @query-cpu-definitions:
@@ -340,4 +341,5 @@
'TARGET_ARM',
'TARGET_I386',
'TARGET_S390X',
- 'TARGET_MIPS' ] } }
+ 'TARGET_MIPS',
+ 'TARGET_LOONGARCH64' ] } }
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index 16443159cc..c3e7c5dc98 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -342,3 +342,31 @@ static const TypeInfo loongarch_cpu_type_infos[] = {
};
DEFINE_TYPES(loongarch_cpu_type_infos)
+
+static void loongarch_cpu_add_definition(gpointer data, gpointer user_data)
+{
+ObjectClass *oc = data;
+CpuDefinitionInfoList **cpu_list = user_data;
+CpuDefinitionInfo *info;
+const char *typename;
+
+typename = object_class_get_name(oc);
+info = g_malloc0(sizeof(*info));
+info->name = g_strndup(typename,
+ strlen(typename) - strlen("-" TYPE_LOONGARCH_CPU));
+info->q_typename = g_strdup(typename);
+
+QAPI_LIST_PREPEND(*cpu_list, info);
+}
+
+CpuDefinitionInfoList *qmp_query_cpu_definitions(Error **errp)
+{
+CpuDefinitionInfoList *cpu_list = NULL;
+GSList *list;
+
+list = object_class_get_list(TYPE_LOONGARCH_CPU, false);
+g_slist_foreach(list, loongarch_cpu_add_definition, &cpu_list);
+g_slist_free(list);
+
+return cpu_list;
+}
--
2.27.0
[PATCH v2 00/30] Add Loongarch softmmu support.
This series patch add softmmu support for LoongArch. Base on the linux-user emulation support V9 patch. * https://patchew.org/QEMU/1630586467-22463-1-git-send-email-gaos...@loongson.cn/diff/1636340895-5255-1-git-send-email-gaos...@loongson.cn/ The latest kernel: * https://github.com/loongson/linux/tree/loongarch-next The manual: * https://github.com/loongson/LoongArch-Documentation/releases/tag/2021.10.11 Changes for v2: 1.Combine patch 2 and 3 into one. 2.Adjust the order of the patch. 3.Modify some emulate errors when use the kernel from the github. 4.Adjust some format problem. 5.Others mainly follow Richard's code review comments. Please review! Thanks Xiaojuan Yang (30): target/loongarch: Update README target/loongarch: Add CSR registers definition target/loongarch: Add basic vmstate description of CPU. target/loongarch: Define exceptions for LoongArch. target/loongarch: Implement qmp_query_cpu_definitions() target/loongarch: Add stabletimer support target/loongarch: Add MMU support for LoongArch CPU. target/loongarch: Add LoongArch CSR/IOCSR instruction target/loongarch: Add TLB instruction support target/loongarch: Add other core instructions support target/loongarch: Add LoongArch interrupt and exception handle target/loongarch: Add timer related instructions support. target/loongarch: Add gdb support. target/loongarch: Implement privilege instructions disassembly hw/pci-host: Add ls7a1000 PCIe Host bridge support for Loongson Platform hw/loongarch: Add a virt LoongArch 3A5000 board support hw/loongarch: Add LoongArch cpu interrupt support(CPUINTC) hw/loongarch: Add LoongArch ipi interrupt support(IPI) hw/intc: Add LoongArch ls7a interrupt controller support(PCH-PIC) hw/intc: Add LoongArch ls7a msi interrupt controller support(PCH-MSI) hw/intc: Add LoongArch extioi interrupt controller(EIOINTC) hw/loongarch: Add irq hierarchy for the system hw/loongarch: Add some devices support for 3A5000. hw/loongarch: Add LoongArch ls7a rtc device support hw/loongarch: Add default bios startup support. hw/loongarch: Add -kernel and -initrd options support hw/loongarch: Add LoongArch smbios support hw/loongarch: Add LoongArch acpi support hw/loongarch: Add machine->possible_cpus hw/loongarch: Add Numa support. .../devices/loongarch64-softmmu/default.mak | 3 + configs/targets/loongarch64-softmmu.mak | 4 + gdb-xml/loongarch-base64.xml | 43 + gdb-xml/loongarch-fpu64.xml | 57 ++ hw/Kconfig| 1 + hw/acpi/Kconfig | 4 + hw/acpi/ls7a.c| 349 +++ hw/acpi/meson.build | 1 + hw/intc/Kconfig | 12 + hw/intc/loongarch_extioi.c| 588 hw/intc/loongarch_pch_msi.c | 73 ++ hw/intc/loongarch_pch_pic.c | 283 ++ hw/intc/meson.build | 3 + hw/loongarch/Kconfig | 22 + hw/loongarch/acpi-build.c | 653 + hw/loongarch/fw_cfg.c | 33 + hw/loongarch/fw_cfg.h | 15 + hw/loongarch/ipi.c| 146 +++ hw/loongarch/loongarch_int.c | 59 ++ hw/loongarch/ls3a5000_virt.c | 647 + hw/loongarch/meson.build | 7 + hw/meson.build| 1 + hw/pci-host/Kconfig | 4 + hw/pci-host/ls7a.c| 223 + hw/pci-host/meson.build | 1 + hw/rtc/Kconfig| 3 + hw/rtc/ls7a_rtc.c | 323 +++ hw/rtc/meson.build| 1 + include/exec/poison.h | 2 + include/hw/acpi/ls7a.h| 53 ++ include/hw/intc/loongarch_extioi.h| 101 ++ include/hw/intc/loongarch_pch_msi.h | 16 + include/hw/intc/loongarch_pch_pic.h | 49 + include/hw/loongarch/gipi.h | 37 + include/hw/loongarch/loongarch.h | 78 ++ include/hw/pci-host/ls7a.h| 66 ++ include/sysemu/arch_init.h| 1 + pc-bios/loongarch_bios.bin| Bin 0 -> 4128768 bytes qapi/machine-target.json | 6 +- qapi/machine.json | 2 +- softmmu/qdev-monitor.c| 3 +- target/Kconfig| 1 + target/loongarch/Kconfig | 2 + target/loongarch/README | 20 + target/loongarch/cpu-csr.h| 334 +++ target/loongarch/cpu-param.h | 3 + target/loongarch/cpu.c| 390 +
[PATCH v2 02/30] target/loongarch: Add CSR registers definition
1.Define All the CSR registers and its field. 2.Set some default csr values. Signed-off-by: Xiaojuan Yang Signed-off-by: Song Gao --- target/loongarch/cpu-csr.h | 334 + target/loongarch/cpu.c | 12 ++ target/loongarch/cpu.h | 127 ++ 3 files changed, 473 insertions(+) create mode 100644 target/loongarch/cpu-csr.h diff --git a/target/loongarch/cpu-csr.h b/target/loongarch/cpu-csr.h new file mode 100644 index 00..ef7511bf51 --- /dev/null +++ b/target/loongarch/cpu-csr.h @@ -0,0 +1,334 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * QEMU LoongArch CPU CSR registers + * + * Copyright (c) 2021 Loongson Technology Corporation Limited + */ + +#ifndef LOONGARCH_CPU_CSR_H +#define LOONGARCH_CPU_CSR_H + +/* Base on: kernal: arch/loongarch/include/asm/loongarch.h */ + +/* Basic CSR register */ +#define LOONGARCH_CSR_CRMD 0x0 /* Current mode info */ +FIELD(CSR_CRMD, PLV, 0, 2) +FIELD(CSR_CRMD, IE, 2, 1) +FIELD(CSR_CRMD, DA, 3, 1) +FIELD(CSR_CRMD, PG, 4, 1) +FIELD(CSR_CRMD, DATF, 5, 2) +FIELD(CSR_CRMD, DATM, 7, 2) +FIELD(CSR_CRMD, WE, 9, 1) + +#define LOONGARCH_CSR_PRMD 0x1 /* Prev-exception mode info */ +FIELD(CSR_PRMD, PPLV, 0, 2) +FIELD(CSR_PRMD, PIE, 2, 1) +FIELD(CSR_PRMD, PWE, 3, 1) + +#define LOONGARCH_CSR_EUEN 0x2 /* Extended unit enable */ +FIELD(CSR_EUEN, FPE, 0, 1) +FIELD(CSR_EUEN, SXE, 1, 1) +FIELD(CSR_EUEN, ASXE, 2, 1) +FIELD(CSR_EUEN, BTE, 3, 1) + +#define LOONGARCH_CSR_MISC 0x3 /* Misc config */ + +#define LOONGARCH_CSR_ECFG 0x4 /* Exception config */ +FIELD(CSR_ECFG, LIE, 0, 13) +FIELD(CSR_ECFG, VS, 16, 3) + +#define LOONGARCH_CSR_ESTAT 0x5 /* Exception status */ +FIELD(CSR_ESTAT, IS, 0, 13) +FIELD(CSR_ESTAT, ECODE, 16, 6) +FIELD(CSR_ESTAT, ESUBCODE, 22, 9) + +#define EXCODE_IP 64 +#define EXCCODE_INT 0 +#define EXCCODE_PIL 1 +#define EXCCODE_PIS 2 +#define EXCCODE_PIF 3 +#define EXCCODE_PME 4 +#define EXCCODE_PNR 5 +#define EXCCODE_PNX 6 +#define EXCCODE_PPI 7 +#define EXCCODE_ADE 8 +#define EXCCODE_ALE 9 +#define EXCCODE_BCE 10 +#define EXCCODE_SYS 11 +#define EXCCODE_BRK 12 +#define EXCCODE_INE 13 +#define EXCCODE_IPE 14 +#define EXCCODE_FPD 15 +#define EXCCODE_SXD 16 +#define EXCCODE_ASXD17 +#define EXCCODE_FPE 18 /* Have different expsubcode */ +#define EXCCODE_VFPE18 +#define EXCCODE_WPEF19 /* Have different expsubcode */ +#define EXCCODE_WPEM19 +#define EXCCODE_BTD 20 +#define EXCCODE_BTE 21 + +#define LOONGARCH_CSR_ERA0x6 /* ERA */ + +#define LOONGARCH_CSR_BADV 0x7 /* Bad virtual address */ + +#define LOONGARCH_CSR_BADI 0x8 /* Bad instruction */ + +#define LOONGARCH_CSR_EENTRY 0xc /* Exception enter base address */ + +/* TLB related CSR register */ +#define LOONGARCH_CSR_TLBIDX 0x10 /* TLB Index, EHINV, PageSize, NP */ +FIELD(CSR_TLBIDX, INDEX, 0, 12) +FIELD(CSR_TLBIDX, PS, 24, 6) +FIELD(CSR_TLBIDX, NE, 31, 1) + +#define LOONGARCH_CSR_TLBEHI 0x11 /* TLB EntryHi without ASID */ +FIELD(CSR_TLBEHI, VPPN, 13, 35) + +#define LOONGARCH_CSR_TLBELO00x12 /* TLB EntryLo0 */ +FIELD(CSR_TLBELO0, V, 0, 1) +FIELD(CSR_TLBELO0, D, 1, 1) +FIELD(CSR_TLBELO0, PLV, 2, 2) +FIELD(CSR_TLBELO0, MAT, 4, 2) +FIELD(CSR_TLBELO0, G, 6, 1) +FIELD(CSR_TLBELO0, PPN, 12, 36) +FIELD(CSR_TLBELO0, NR, 61, 1) +FIELD(CSR_TLBELO0, NX, 62, 1) +FIELD(CSR_TLBELO0, RPLV, 63, 1) + +#define LOONGARCH_CSR_TLBELO10x13 /* 64 TLB EntryLo1 */ +FIELD(CSR_TLBELO1, V, 0, 1) +FIELD(CSR_TLBELO1, D, 1, 1) +FIELD(CSR_TLBELO1, PLV, 2, 2) +FIELD(CSR_TLBELO1, MAT, 4, 2) +FIELD(CSR_TLBELO1, G, 6, 1) +FIELD(CSR_TLBELO1, PPN, 12, 36) +FIELD(CSR_TLBELO1, NR, 61, 1) +FIELD(CSR_TLBELO1, NX, 62, 1) +FIELD(CSR_TLBELO1, RPLV, 63, 1) + +#define LOONGARCH_CSR_ASID 0x18 /* ASID */ +FIELD(CSR_ASID, ASID, 0, 10) +FIELD(CSR_ASID, ASIDBITS, 16, 8) + +/* Page table base address when badv[47] = 0 */ +#define LOONGARCH_CSR_PGDL 0x19 +/* Page table base address when badv[47] = 1 */ +#define LOONGARCH_CSR_PGDH 0x1a + +#define LOONGARCH_CSR_PGD0x1b /* Page table base */ + +#define LOONGARCH_CSR_PWCL 0x1c /* PWCl */ +FIELD(CSR_PWCL, PTBASE, 0, 5) +FIELD(CSR_PWCL, PTWIDTH, 5, 5) +FIELD(CSR_PWCL, DIR1_BASE, 10, 5) +FIELD(CSR_PWCL, DIR1_WIDTH, 15, 5) +FIELD(CSR_PWCL, DIR2_BASE, 20, 5) +FIELD(CSR_PWCL, DIR2_WIDTH, 25, 5) +FIELD(CSR_PWCL, PTEWIDTH, 30, 2) + +#define LOONGARCH_CSR_PWCH 0x1d /* PWCh */ +FIELD(CSR_PWCH, DIR3_BASE, 0, 6) +FIELD(CSR_PWCH, DIR3_WIDTH, 6, 6) +FIELD(CSR_PWCH, DIR4_BA
[PATCH v2 12/30] target/loongarch: Add timer related instructions support.
This includes:
-RDTIME{L/H}.W
-RDTIME.D
Signed-off-by: Xiaojuan Yang
Signed-off-by: Song Gao
---
target/loongarch/helper.h | 1 +
target/loongarch/insn_trans/trans_extra.c.inc | 32 +++
target/loongarch/op_helper.c | 4 +++
target/loongarch/translate.c | 2 ++
4 files changed, 39 insertions(+)
diff --git a/target/loongarch/helper.h b/target/loongarch/helper.h
index afb362c9c7..fc4eaa1ce8 100644
--- a/target/loongarch/helper.h
+++ b/target/loongarch/helper.h
@@ -114,4 +114,5 @@ DEF_HELPER_4(lddir, tl, env, tl, tl, i32)
DEF_HELPER_4(ldpte, void, env, tl, tl, i32)
DEF_HELPER_1(ertn, void, env)
DEF_HELPER_1(idle, void, env)
+DEF_HELPER_1(rdtime_d, i64, env)
#endif /* !CONFIG_USER_ONLY */
diff --git a/target/loongarch/insn_trans/trans_extra.c.inc
b/target/loongarch/insn_trans/trans_extra.c.inc
index 76f0698da7..ab46331547 100644
--- a/target/loongarch/insn_trans/trans_extra.c.inc
+++ b/target/loongarch/insn_trans/trans_extra.c.inc
@@ -33,22 +33,54 @@ static bool trans_asrtgt_d(DisasContext *ctx, arg_asrtgt_d
* a)
return true;
}
+#ifndef CONFIG_USER_ONLY
+static bool gen_rdtime(DisasContext *ctx, arg_rdtimel_w *a,
+ bool word, bool high)
+{
+TCGv dst1 = gpr_dst(ctx, a->rd, EXT_NONE);
+TCGv dst2 = gpr_dst(ctx, a->rj, EXT_NONE);
+
+if (tb_cflags(ctx->base.tb) & CF_USE_ICOUNT) {
+gen_io_start();
+}
+gen_helper_rdtime_d(dst1, cpu_env);
+if (word) {
+tcg_gen_sextract_tl(dst1, dst1, high ? 32 : 0, 32);
+}
+tcg_gen_ld_i64(dst2, cpu_env, offsetof(CPULoongArchState, CSR_TMID));
+
+return true;
+}
+#endif
+
static bool trans_rdtimel_w(DisasContext *ctx, arg_rdtimel_w *a)
{
+#ifdef CONFIG_USER_ONLY
tcg_gen_movi_tl(cpu_gpr[a->rd], 0);
return true;
+#else
+return gen_rdtime(ctx, a, 1, 0);
+#endif
}
static bool trans_rdtimeh_w(DisasContext *ctx, arg_rdtimeh_w *a)
{
+#ifdef CONFIG_USER_ONLY
tcg_gen_movi_tl(cpu_gpr[a->rd], 0);
return true;
+#else
+return gen_rdtime(ctx, a, 1, 1);
+#endif
}
static bool trans_rdtime_d(DisasContext *ctx, arg_rdtime_d *a)
{
+#ifdef CONFIG_USER_ONLY
tcg_gen_movi_tl(cpu_gpr[a->rd], 0);
return true;
+#else
+return gen_rdtime(ctx, a, 0, 0);
+#endif
}
static bool trans_cpucfg(DisasContext *ctx, arg_cpucfg *a)
diff --git a/target/loongarch/op_helper.c b/target/loongarch/op_helper.c
index e2a9fd9ad0..fb47914c87 100644
--- a/target/loongarch/op_helper.c
+++ b/target/loongarch/op_helper.c
@@ -134,5 +134,9 @@ void helper_idle(CPULoongArchState *env)
do_raise_exception(env, EXCP_HLT, 0);
}
+uint64_t helper_rdtime_d(CPULoongArchState *env)
+{
+ return cpu_loongarch_get_stable_counter(env);
+}
#endif /* !CONFIG_USER_ONLY */
diff --git a/target/loongarch/translate.c b/target/loongarch/translate.c
index 3935b14163..15276a240f 100644
--- a/target/loongarch/translate.c
+++ b/target/loongarch/translate.c
@@ -25,6 +25,8 @@ static TCGv cpu_lladdr, cpu_llval;
TCGv_i32 cpu_fcsr0;
TCGv_i64 cpu_fpr[32];
+#include "exec/gen-icount.h"
+
#define DISAS_STOP DISAS_TARGET_0
#define DISAS_EXIT DISAS_TARGET_1
--
2.27.0
Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1
On Tue, Nov 09, 2021 at 01:34:49PM +0100, BALATON Zoltan wrote:
> On Tue, 9 Nov 2021, Laurent Vivier wrote:
> > Add the missing machine type for m68k/virt
> >
> > Cc: qemu-sta...@nongnu.org
> > Signed-off-by: Laurent Vivier
> > Message-Id: <20211106194158.4068596-2-laur...@vivier.eu>
> > Signed-off-by: Laurent Vivier
> > ---
> > hw/m68k/virt.c | 9 -
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
> > index 4e8bce5aa6f7..0d9e3f83c169 100644
> > --- a/hw/m68k/virt.c
> > +++ b/hw/m68k/virt.c
> > @@ -304,7 +304,14 @@ type_init(virt_machine_register_types)
> > } \
> > type_init(machvirt_machine_##major##_##minor##_init);
> >
> > +static void virt_machine_6_1_options(MachineClass *mc)
> > +{
> > +}
> > +DEFINE_VIRT_MACHINE(6, 1, true)
> > +
> > static void virt_machine_6_0_options(MachineClass *mc)
> > {
> > +virt_machine_6_1_options(mc);
> > +compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len);
> > }
> > -DEFINE_VIRT_MACHINE(6, 0, true)
> > +DEFINE_VIRT_MACHINE(6, 0, false)
>
> I don't understand how these compat machines work but if these are empty and
> essentially the same as the previous version why do we add a new version in
> every release? Wouldn't it be enough to add new version when there was an
> incompatible change? I mean, instead of listing machine and getting a lot of
> virt-6.1, virt-6.0, virt-5.2,... or so, we'd only get versions that are
> actually different such as virt-7.0, virt-5.2, virt-5.0 (maybe they are
> called differently, just an example) with the versionless alias always
> pointing to the latest. Then when QEMU is updated one can see if there was
> any change so should update the VM or keep using the older versions. Or does
> it work like that and I'm missing it completely?
It doesn't work like that, and that's a good thing.
The versioned machine types are for management applications that want
to guarantee an ABI across hosts. When a mgmt app wants to set a new
baseline for their QEMU machine types, it is way clearer if every
versioned machine type across all target arches supports the same
versions, regardless of whether there were any changes or not.
ie if an app wants to set QEMU 6.1.0 as the baseline, they want
to be able to set virt-6.1 for aarch64, for mips, for riscv,
instead of having to figure out which versions exists for each
arch
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 v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k
On Dienstag, 9. November 2021 11:56:35 CET Stefan Hajnoczi wrote: > On Thu, Nov 04, 2021 at 03:41:23PM +0100, Christian Schoenebeck wrote: > > On Mittwoch, 3. November 2021 12:33:33 CET Stefan Hajnoczi wrote: > > > On Mon, Nov 01, 2021 at 09:29:26PM +0100, Christian Schoenebeck wrote: > > > > On Donnerstag, 28. Oktober 2021 11:00:48 CET Stefan Hajnoczi wrote: > > > > > On Mon, Oct 25, 2021 at 05:03:25PM +0200, Christian Schoenebeck wrote: > > > > > > On Montag, 25. Oktober 2021 12:30:41 CEST Stefan Hajnoczi wrote: > > > > > > > On Thu, Oct 21, 2021 at 05:39:28PM +0200, Christian Schoenebeck wrote: > > > > > > > > On Freitag, 8. Oktober 2021 18:08:48 CEST Christian Schoenebeck wrote: > > > > > > > > > On Freitag, 8. Oktober 2021 16:24:42 CEST Christian Schoenebeck wrote: > > > > > > > > > > On Freitag, 8. Oktober 2021 09:25:33 CEST Greg Kurz wrote: > > > > > > > > > > > On Thu, 7 Oct 2021 16:42:49 +0100 > > > > > > > > > > > > > > > > > > > > > > Stefan Hajnoczi wrote: > > > > > > > > > > > > On Thu, Oct 07, 2021 at 02:51:55PM +0200, Christian Schoenebeck wrote: > > > > > > > > > > > > > On Donnerstag, 7. Oktober 2021 07:23:59 CEST Stefan Hajnoczi wrote: > > > > > > > > > > > > > > On Mon, Oct 04, 2021 at 09:38:00PM +0200, > > > > > > > > > > > > > > Christian > > > > > > > > > > > > > > Schoenebeck > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > At the moment the maximum transfer size with > > > > > > > > > > > > > > > virtio > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > limited > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > 4M > > > > > > > > > > > > > > > (1024 * PAGE_SIZE). This series raises this > > > > > > > > > > > > > > > limit to > > > > > > > > > > > > > > > its > > > > > > > > > > > > > > > maximum > > > > > > > > > > > > > > > theoretical possible transfer size of 128M (32k > > > > > > > > > > > > > > > pages) > > > > > > > > > > > > > > > according > > > > > > > > > > > > > > > to > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > virtio specs: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.oasis-open.org/virtio/virtio/v1.1/c > > > > > > > > > > > > > > > s01/ > > > > > > > > > > > > > > > virt > > > > > > > > > > > > > > > io-v > > > > > > > > > > > > > > > 1.1- > > > > > > > > > > > > > > > cs > > > > > > > > > > > > > > > 01 > > > > > > > > > > > > > > > .html# > > > > > > > > > > > > > > > x1-240006 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Christian, > > > > > > > > > > > > > > > > > > > > > > > > > I took a quick look at the code: > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Thanks Stefan for sharing virtio expertise and helping > > > > > > > > > > > Christian > > > > > > > > > > > ! > > > > > > > > > > > > > > > > > > > > > > > > > - The Linux 9p driver restricts descriptor chains > > > > > > > > > > > > > > to > > > > > > > > > > > > > > 128 > > > > > > > > > > > > > > elements > > > > > > > > > > > > > > > > > > > > > > > > > > > > (net/9p/trans_virtio.c:VIRTQUEUE_NUM) > > > > > > > > > > > > > > > > > > > > > > > > > > Yes, that's the limitation that I am about to remove > > > > > > > > > > > > > (WIP); > > > > > > > > > > > > > current > > > > > > > > > > > > > kernel > > > > > > > > > > > > > patches: > > > > > > > > > > > > > https://lore.kernel.org/netdev/cover.1632327421.git. > > > > > > > > > > > > > linu > > > > > > > > > > > > > x_os > > > > > > > > > > > > > s@cr > > > > > > > > > > > > > udeb > > > > > > > > > > > > > yt > > > > > > > > > > > > > e. > > > > > > > > > > > > > com/> > > > > > > > > > > > > > > > > > > > > > > > > I haven't read the patches yet but I'm concerned that > > > > > > > > > > > > today > > > > > > > > > > > > the > > > > > > > > > > > > driver > > > > > > > > > > > > is pretty well-behaved and this new patch series > > > > > > > > > > > > introduces a > > > > > > > > > > > > spec > > > > > > > > > > > > violation. Not fixing existing spec violations is > > > > > > > > > > > > okay, > > > > > > > > > > > > but > > > > > > > > > > > > adding > > > > > > > > > > > > new > > > > > > > > > > > > ones is a red flag. I think we need to figure out a > > > > > > > > > > > > clean > > > > > > > > > > > > solution. > > > > > > > > > > > > > > > > > > > > Nobody has reviewed the kernel patches yet. My main > > > > > > > > > > concern > > > > > > > > > > therefore > > > > > > > > > > actually is that the kernel patches are already too > > > > > > > > > > complex, > > > > > > > > > > because > > > > > > > > > > the > > > > > > > > > > current situation is that only Dominique is handling 9p > > > > > > > > > > patches on > > > > > > > > > > kernel > > > > > > > > > > side, and he barely has time for 9p anymore. > > > > > > > > > > > > > > > > > > > > Another reason for me to catch up on reading current > > > > > > > > > > kernel > > > > > > > > > > code > > > > > > > > > > and > > > > > > > > > > stepping i
Re: [PATCH v2 03/34] target/ppc: Move load and store floating point instructions to decodetree
On 29/10/2021 21:23, matheus.fe...@eldorado.org.br wrote:
From: Fernando Eckhardt Valle
Move load floating point instructions (lfs, lfsu, lfsx, lfsux, lfd, lfdu, lfdx,
lfdux)
and store floating point instructions(stfs, stfsu, stfsx, stfsux, stfd, stfdu,
stfdx,
stfdux) from legacy system to decodetree.
Reviewed-by: Richard Henderson
Signed-off-by: Fernando Eckhardt Valle
Signed-off-by: Matheus Ferst
---
v2:
- if instead of top-level ternary operator
---
target/ppc/insn32.decode | 24 +++
target/ppc/translate/fp-impl.c.inc | 247 +
target/ppc/translate/fp-ops.c.inc | 29
3 files changed, 95 insertions(+), 205 deletions(-)
diff --git a/target/ppc/insn32.decode b/target/ppc/insn32.decode
index 6aec1c0728..3837b799c8 100644
--- a/target/ppc/insn32.decode
+++ b/target/ppc/insn32.decode
@@ -193,6 +193,30 @@ ADDPCIS 010011 . . .. 00010 . @DX
CFUGED 01 . . . 0011011100 - @X
+### Float-Point Load Instructions
+
+LFS 11 . . @D
+LFSU110001 . . @D
+LFSX01 . . . 110111 - @X
+LFSUX 01 . . . 1000110111 - @X
+
+LFD 110010 . . @D
+LFDU110011 . . @D
+LFDX01 . . . 1001010111 - @X
+LFDUX 01 . . . 1001110111 - @X
+
+### Float-Point Store Instructions
+
+STFS110100 . .. ... @D
+STFSU 110101 . .. ... @D
+STFSX 01 . .. 1010010111 - @X
+STFSUX 01 . .. 1010110111 - @X
+
+STFD110110 . .. ... @D
+STFDU 110111 . .. ... @D
+STFDX 01 . .. 1011010111 - @X
+STFDUX 01 . .. 100111 - @X
+
### Move To/From System Register Instructions
SETBC 01 . . - 011000 - @X_bi
diff --git a/target/ppc/translate/fp-impl.c.inc
b/target/ppc/translate/fp-impl.c.inc
index 9f7868ee28..57a799db1c 100644
--- a/target/ppc/translate/fp-impl.c.inc
+++ b/target/ppc/translate/fp-impl.c.inc
@@ -854,99 +854,6 @@ static void gen_mtfsfi(DisasContext *ctx)
gen_helper_float_check_status(cpu_env);
}
-/*** Floating-point load ***/
-#define GEN_LDF(name, ldop, opc, type)\
-static void glue(gen_, name)(DisasContext *ctx) \
-{ \
-TCGv EA; \
-TCGv_i64 t0; \
-if (unlikely(!ctx->fpu_enabled)) {\
-gen_exception(ctx, POWERPC_EXCP_FPU); \
-return; \
-} \
-gen_set_access_type(ctx, ACCESS_FLOAT); \
-EA = tcg_temp_new(); \
-t0 = tcg_temp_new_i64(); \
-gen_addr_imm_index(ctx, EA, 0); \
-gen_qemu_##ldop(ctx, t0, EA); \
-set_fpr(rD(ctx->opcode), t0); \
-tcg_temp_free(EA);\
-tcg_temp_free_i64(t0);\
-}
-
-#define GEN_LDUF(name, ldop, opc, type) \
-static void glue(gen_, name##u)(DisasContext *ctx)\
-{ \
-TCGv EA; \
-TCGv_i64 t0; \
-if (unlikely(!ctx->fpu_enabled)) {\
-gen_exception(ctx, POWERPC_EXCP_FPU); \
-return; \
-} \
-if (unlikely(rA(ctx->opcode) == 0)) { \
-gen_inval_exception(ctx, POWERPC_EXCP_INVAL_INVAL); \
-return; \
-} \
Re: [PATCH v8 07/10] hw/arm/sbsa-ref: add ITS support in SBSA GIC
On Fri, 15 Oct 2021 at 13:23, Leif Lindholm wrote: > (Apologies for delay. Alex also tells me you are currently away, but > there is no strong urgency here.) (Thanks for the ping via Alex -- I missed this email when I was scanning through my qemu-devel mail backlog after my holiday...) > On Thu, Sep 23, 2021 at 17:00:35 +0100, Peter Maydell wrote: > > Leif, what's your plan/preferences here ? > > I discussed this with Alex/Shashi. > > One further complicating aspect is that the EDK2 GIC driver currently > relies on GIC addresses being known at compile-time. > > > Presumably somebody also needs to do the system-software side > > of things to handle the ITS being present and the redistributor > > frames moving... > > Since it *would* be useful to get this support in, I think the most > pragmatic plan would be: > - Add ITS in the location originally proposed by Shashi. > - Add information to DT: > - Platform version (1). > - GICD, GICR, and ITS base addresses. > - edk2: Convert GIC driver to support dynamic block addresses. > - TF-A: Parse the DT and add SIP SVC calls: > - to retrieve it (or return not supported if not found). > - to retrieve base addresses for GICD, GICR, and ITS. > - edk2-platforms: Query TF-A for platform version. > If platform version >= 1, request base addresses for GICD, GICR, and > ITS. > - Generate IORT if ITS present. > - Update GIC frame layout to match an ARM GIC-?00. (Platform version 2) > > Unrelated to the ITS question, and not requiring any intervention on > the QEMU side, we can then also transition the CPU and DRAM discovery > to SIP SVC calls, and stop sharing the DT with edk2 completely. > > And some way further down the line we could do the SCP thing, which > would let us support different GIC-layouts/configurations based on > platform command line options. (Platform version 3.) > (TF-A makes SCP calls if version >= 3) > This would then require no changes to edk2-platforms. This sounds good to me. > (Numeric values described as incrementing integer rather than trying > to guess at specific qemu release numbers.) This is kind of mixing up two separate things. The above describes three "versions" of this machine type, which you might consider as like revision A/B/C of hardware (and where firmware might for instance read a 'board revision' register or something to tell them apart). QEMU release numbers and versioned board types like virt-6.0 are a very specific thing that is taking on a guarantee about maintaining version compatibility of the same board type between different QEMU versions. We can make sbsa-ref a versioned machine type in that sense if you really want to do it, but it makes future changes to the machine rather more painful (everything new immediately needs flags and properties and so on so that it can be added only for newer versions of the machine type and not for the old one -- at a rough count at least 10% of hw/arm/virt.c is purely boilerplate and machinery for versioned machine types). So it's not something we should do for sbsa-ref unless we have a good reason I think. -- PMM
[PATCH v2 2/3] acpi: tpm: Add missing device identification objects
Add missing device identification objects _STR and _UID. They will appear
as files 'description' and 'uid' under Linux sysfs.
Cc: Shannon Zhao
Cc: Michael S. Tsirkin
Cc: Igor Mammedov
Cc: Ani Sinha
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/708
Signed-off-by: Stefan Berger
---
hw/arm/virt-acpi-build.c | 1 +
hw/i386/acpi-build.c | 8
2 files changed, 9 insertions(+)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 674f902652..09456424aa 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -228,6 +228,7 @@ static void acpi_dsdt_add_tpm(Aml *scope, VirtMachineState
*vms)
Aml *dev = aml_device("TPM0");
aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
+aml_append(dev, aml_name_decl("_STR", aml_string("TPM 2.0 Device")));
aml_append(dev, aml_name_decl("_UID", aml_int(0)));
Aml *crs = aml_resource_template();
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a3ad6abd33..5bd2160a89 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1808,11 +1808,15 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
dev = aml_device("TPM");
aml_append(dev, aml_name_decl("_HID",
aml_string("MSFT0101")));
+aml_append(dev,
+ aml_name_decl("_STR",
+ aml_string("TPM 2.0 Device")));
} else {
dev = aml_device("ISA.TPM");
aml_append(dev, aml_name_decl("_HID",
aml_eisaid("PNP0C31")));
}
+aml_append(dev, aml_name_decl("_UID", aml_int(1)));
aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
crs = aml_resource_template();
@@ -1840,6 +1844,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
if (TPM_IS_CRB(tpm)) {
dev = aml_device("TPM");
aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
+aml_append(dev, aml_name_decl("_STR",
+ aml_string("TPM 2.0 Device")));
crs = aml_resource_template();
aml_append(crs, aml_memory32_fixed(TPM_CRB_ADDR_BASE,
TPM_CRB_ADDR_SIZE, AML_READ_WRITE));
@@ -1847,6 +1853,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
aml_append(dev, aml_name_decl("_STA", aml_int(0xf)));
+aml_append(dev, aml_name_decl("_UID", aml_int(1)));
+
tpm_build_ppi_acpi(tpm, dev);
aml_append(sb_scope, dev);
--
2.31.1
[PATCH v2 3/3] tests: acpi: Add updated TPM related tables
The updated TPM related tables have the following additions:
Device (TPM)
{
Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */) // _HID: Hardware
ID
+ Name (_STR, "TPM 2.0 Device") // _STR: Description String
+ Name (_UID, One) // _UID: Unique ID
Name (_STA, 0x0F) // _STA: Status
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
Cc: Michael S. Tsirkin
Cc: Igor Mammedov
Cc: Ani Sinha
Signed-off-by: Stefan Berger
---
tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 0 -> 8900 bytes
tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 0 -> 8921 bytes
tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 0 -> 50 bytes
tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 0 -> 76 bytes
tests/qtest/bios-tables-test-allowed-diff.h | 11 ---
5 files changed, 11 deletions(-)
diff --git a/tests/data/acpi/q35/DSDT.tis.tpm12
b/tests/data/acpi/q35/DSDT.tis.tpm12
index
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..dc1c990496a8fb0fc268081a54c5af363bcd833f
100644
GIT binary patch
literal 8900
zcmb7KOKcm*8J^`sS}j-7lAgdtyH|sAj6j#pg_cDpPGPFu
z$hTWNuI0Oxtl2JCJUe&GGR?Lt&Z1^J=hd0nUaNR4y*%DtX}Ga#7n$pwS?Jc{oz3Ko
z<+Q4QUHWSN==VQ4^G5FGbD#h4+C?h{z#_g)d@qG`2rdWKe9(11?ra(F5S?FJ=+1oH
z;g?05Ls!CpT5i~)iMm?oU2N?<>(z5EALFE7^RsSt0poJ(jpV#_^!+);Y?>VU{APD|
z_jlryId3tiY6_JFv+Ng|Ql$ZHq^h-D_M25^Gj{84g2h@_9ExX77iwO{uY2uG`ssF~
znPVZf1R*u8za3ak(6vA61gsMzc6WQMJM~d#o&9XxW`F;0yvKUhv>02`ntE@7#&YW}
zi!p}LeB%U-hUUAqbGXvTwfPhy{XB-^SL&+~E3jP0wg7(~2LX8EWk;F8j>|*>_CbZ$ra6
z)?~?eGx}!KG>>ibo)_Jf>K-Q!G-h)I=T7ual$pmI&Uv`rboWM+=-)ryb;v?yn8%ob
zDXJy!&C#~+HkwA_rfr$HH59m*yR{4sUZ%C(D4fJ9_>*nn#w93l^Vz~lT*%j|bt7?0
z&?s>8wY6%-uXrzHT1I}^J;l-w`)=W6r1cO*ySw2gA;PzeEk=E`zDdnJmVPV;&L|Z1
z71AN-V}rCe=6j9mRCl?*G;Tff=YKYydb|43+?Ulue{icI_4Ue+gYH9}3#@ynvt>oF
z0^Z@zk&VZ8m-UiS;|d+vjk)fD&IM~cOvNK?lC6iq)pf>t>!x3Ei!5!o@oj{g6gfYA
z(V&OLalhmX*{?VK)T!6EQ;8U!PPSY-Rbb-WzbB*M5yYtG@X{F)6#V!RCOjaoe526Lf45<)rohZ
zazAZNr>*NmsOp^5bWUnICv}|&Rh?6s&M8gjl&%w@s&iV?Ij!lO)^#FObvl|(N7L!(
zIuWWmlbX(?rZcJQM5yXaX*yGy&Xlebp{jF6(>bH*oY8e6RCT5`ooP*HTGxqC)pN*jsI`K;aPoI1b&1pL4be#xQod-3Y2Q{4sb)5)RorgFx
z*MAcp;>>*iWp_w0-FqQ1y*~D^#yqSs59>^XD)WfOJfbm==uCtv^Qgu=sxgo1OoS@)
z0gd^9#(Y3$B2<|Va;9{d2RT!|;~x}E`Qk=MOnC?AwVd->&Urm2LXp#if#wtgEj21g
z&CS%nITH5`6amtTAc{aHg@FnjwAz;Y%GRDqI#3Mglifg+STVW0xbnJ`cVN(L&RoJj_X
zP~J}%sK9b23{-)VfeI*Rl7S+WI$@v!%b74x1xf}gpqxnticso=feI{V!ax-$8K{7A
zCK)I~sS^e&u$&14RiI>`0?L_Wpa`W-7^uKf}LawZulLa7r5DzKah16818paRO7WS|J8P8g`bawZH^
zfs%m=C})y^B9uB|paRR8Fi-_b1}dPONd}5g>V$y`EN8+%6(|{~fN~}oC_Az;Y%GRDqI#3Mglifg+STVW0xbnJ`cVN(L&RoJj_XQ0jz%
z3M^;BKouw%sDN@N87M-j69y`P&H75ih(Lj
z7^uP|167!0pb8TPsxV=o3X=>}VUmF=Ocw7C3>1-^TNo%JIk#k>2<6<8fg;3K(cv~Mly&V6
z|6{dBe~{i7qpw`+%6FcK(qE~xt3mr6hF@RJ!Esmfba3h5nGAa`s|7kQ(xF6$vYDQ#
ztYSByJ8{|C-oz%$M9)g3pRBC9^$7s#+2oX!_+X4p@SUKy*fnai;y6~q%bV6TqcaSm
zj;)vFar{Qe$t@2X+cmTqWMbHj|Ug&`94sOhJexJ(#f`0
zX|Q+b+}h?X)3hJOfN<+Po@+Pi4ddEoe+-nK+WXn_1KF{8^0l+)mF#(*J&*CJ+4Jeq
z+4HTPDrpy6Y1r=TYquizk=|9(yF9%+klx)Vz1vUk4T!g}q4l-ZdrEqbr}qZZd;6sK
z`soXU>0|eizM!Np@bra&^o4!W7y9XogX!bWRGb-%m8Wo#w&?(kb+1=2(N$cI=r^--wqHSb%L+jvx-W`6w40R{kMs_#!T+iy=;YZC-ccN`%cSFzV
zoZcON=?rxz+Vt+6Blq^RccvTFJW4GntJqQO`8zAmi|Rz#I(u)&->(-M@+q~jIN?o`
zuD_Nkzxqb_%B3G=UVHiVS1-M`@$&1eWw`$Gss7VCX;~%X3;PS(u(7KTPok~!FKo+h
zUHKLTIhJw#Ld|e1wT9u=tEUZYfM@AYG+5Mis~$GlQ-qAVjlyyUa4*-)V6VAStC%69
zMm+UPXSp5>NDOi^=lYdwb|Fi{5QU?7I_WlxFGjjnXOq3>X0zF?ba@QB_qmDILua3e
z$}YkKG=+8Aq%>PJA)TULTF86+kNQD@~K{suEt5${UtI6yFw2m`%f2V-G*B;
z_mN?`wZfTHWH)3Rp>h6GFV#73gzS811R-1hblLu}6BySw&=iClgDJV-!A9Ja?%egk
zR@|12&$<(xb!!)CJ_|=(?;anTIlAxR##I{QI=i%vQQdf^`_vGOKN+}v8&)(NniyOJ
z@6rYp77H;^S)>lnu?@QA(6-T97%gt7FO28XxzW>Hop4tgO?#hd9{sco^^eI5w?@oO
zXhjBF33_3$5z{lO=X{E>2CwOz-S`&DuSY7r8M|%jgM4A
zIF(tkQh8B`*Gh}F_4})nEP^cpe0J%8is2pmj%}D|H}Fov=PO*kWADY2s39@-A6{hT
z*Xd{R?k@c-rcZ=vO>{r^Ao2bj)6<2OPf9)}pZ2P^5HkvJ}fnnmb55*{=
z;_~gg%%@i_D%LSfl&DzqYH$t{C0>)%uDl;b5i=p&oWCD4W0^67S3OV0{IXvc(@iDi
zd!1myM!ai>`?_i0w2gx(Sw3Svd@YD
zch6uj=Ej1@P{72=qC8pRCu8)ufKqt)1pO7(^s9SCSsNwYp+c^xVyib`yXpIjD4MU{
zzH7bIx^kR{zF(=CIQSXguk*tyomDf-IHD#C&=Rv>0*C%-fg+>2a{9EHUTpfs+C+Ea
zQd<0H
z!Y}{#x95&L{o7ja_)i@37qg9S0%g};GHyk74LH*Uqc^#5Vu^JhN1Zi-e~`Gy@LHy^
z1nanbdELTZW6uZ!41YCbBn6fJ?*SY|X?Dv9sr@RA#9$azbrEG6mkdVdRe~(x
zK_JXh*91S-L*W-SU@IQd+;D&Z`@`U|9`Y69K#%V`M*OAChigR$?9kwpQPXHKF3|#+
zhSYKhotk>5J>CzmK*JgMKY0AB89X!dmrKPDkCsk<{_opAfbY;WMvZ8929qfH0o}|V
F`##Vk7uC2;O){P0roxg3FX2%t0QL~fx8qDmRu6iu9JlR=ky0Pn*nCrc;(5uJ08>v~#
zY1jU?^yQJm-~0H5H}bch`|JnTFIh1F7V&N3dnu$ta3!#g1U=`Y?xyh$(fPH7-t0$R
zep$3RbR`U^<)$r~sH=tkrS|r-UL)`FF(&=GpL25y7?;~YzrchZlD}J#hRT|Jns@hu>zg1&4W4G@mSgd{3p?LO8vF>I4hS$kvp6)bT
zc@|Pj5K`0H+kxc-J^RCMz`8+VXQ$74(;s%%*w5E&_K*L@`>b!xh_R)t>G!5+EVu8m
z7-JaCV<%`dG~ey*gVkof!>1VOk6*pFCCY02cQsiqT_K
zGR=N#U)cy)zzm~ooM-3peKdk>?d@Z=mD9VdnOTixTJfVaL+$OwWxur``;LkGZD?4>
zN|uc`qi;q{^XL}udC^^|?Q-HkV>ZWd?nduMnR(RVoJSiicXu?2!TsZ1hb&}Ni100AlTjb-uTgWKWsc{;8Hb|2
zLOKKkY>@FLe6LxX?kx|N#_ebR{Lki7Z`VGY|Dtx_k8UlbzFzrJ(0inNk@XIAH?0U(
zz&rdovhmpNuzo6PT%`lMIp5pYy=YB_>3D=C*;*J}TVt%hX8KjP#4>gV-$uAWk@K^c
z40>1`_Y1y|{YJ}ApL%^OorvM-WXttaMJCP-oR?VIrgkfWpe%zZf(lC~V;BcklE4ij
z
[PATCH v2 1/3] tests: acpi: prepare for updated TPM related tables
Replace existing TPM related tables, that are about to change, with
empty files.
Cc: Michael S. Tsirkin
Cc: Igor Mammedov
Cc: Ani Sinha
Signed-off-by: Stefan Berger
---
tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 8894 -> 0 bytes
tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 8894 -> 0 bytes
tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 50 -> 0 bytes
tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 76 -> 0 bytes
tests/qtest/bios-tables-test-allowed-diff.h | 11 +++
5 files changed, 11 insertions(+)
diff --git a/tests/data/acpi/q35/DSDT.tis.tpm12
b/tests/data/acpi/q35/DSDT.tis.tpm12
index
c96b5277a14ae98174408d690d6e0246bd932623..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
100644
GIT binary patch
literal 0
HcmV?d1
literal 8894
zcmb7KO>7&-8J*>iv|6sDB}GgAOGG$M+BAVfN%?Dwq$PLxXN%N|r0gVg!IkB-lAR)p
zBnFZg0b~V890LuKunu}DKnG0GTYKoaHQGxH^x%Vm1Sopwp_c%?v?yZqVD)`79C?PM
zfS8BnezWh*H*a=lA2px6hS&W4F~*EX@+)q+k;%W{yBT~8#u%N`w^NCoWvy*5UuqkP
zNX%$mN$_(V@@D#RFTYkYez6&R8U$~=9~kQ)JNKD${oH!^?$zKNBhaODp=HsDQnnGp4Ec=C~RB1pPscLPP{brTfjNQ7MV6oN}hvJ#jg_@V~>s~vPe!AUg
z=2%EAK}b#OZwHnWbnTBj0qX>b-Q6DRPJP^2XFp%J*+2dp@3EdWEyk9#rrw*NvD~`L
zVvJ!lkDQ><(0sRc4p$nvHlJdopT|)AN_{nA1(xlcntmcGfrM)9Jb5bb0W9uO6r;ze
zWSWE4fszrhfEh-~IM2@G`&b0oT06(9D{FhK=^2e>TJd8vL#>^~Wxu%~`;LkGZD?4>
znk*S_M&FE@=CN(w^P;;_-Q&c8#%zw@+=u{pcQ@Q5MEI7m#i)@WGe6LZR>Mr+}#;s@m^3TRoZ&yE_`>J~APi{4&zFzrh(0!&keD(H
z)|J5Weqx*{p)tXfgGZ?9jB7gMoGGDk!IXnXsOlWkbdGVRgpTPt5vn@JHJ#&{&T(BQ
zLRF`!=`=N+rmhpAsuOP@Wu_-IofEoFgsM(U(`jisEnO!thdV%)=V&*oY!+A6gf>8XihQEQlo;@
z+)NFeBXQqA5g@Gyq6lPC7^uK;OEMU-w|Fi_DgXTm@gC>bb1>562a2&GOK
zsK9b23{-)VfeI+kNd}5g>V$y`EN8+%6(|{~fN~}oC_`
z0?L_Wpa`W-7^uKf}LawZulLa7r5DzKah16818paRO7WS|J8P8g`bawZH^fs%m=C})y^B9uB|paRR8
zFi-_b1}dPONd}5g>V$y`EN8+%6(|{~fN~}oC_A
zz;Y%GRDqI#3Mglifg+STVW0xbnJ`cVN(L&RoJj_XQ0jz%B2o+#k!qj_RRcw+7^uR8
zfhtTgP=!ebsxV=o3KIsZFv&m_CK;&0gn=qd7^uP|167!0pb8TPsxV=o3X=>}VUmF=
zOc*F4d3Rx;h;YaFWRig*#BGovG3DICKoQBgg@GcHb4vz_P|htGC_-!%9d5%yS=a9H
zKURD62kDJ5`pUJgeD8@U{gq0)8noYG`1REs9CtNO2bT_>$*}jbTA=eH9ZGa4o9UU#
zDs}_96PK;+O>DAE^sGes$;zr*p8%kqO-@;f560L8-wAq)U86QDj$R99
z*m_wW$8Ut3-14xoT|=8eCWhTe&RR1cOtFb5+>PP=&G071?nQc^iP5V&{2)EATxpt%8Fs^O($3W?+y`MclkR6*R-#B|-$)4xg^BA9+J)a((
zJ>S}?l6J9`hV8z-b}Mop>0Kqg%hS69>D_(OyZ!XufOrcVTHjc`r=<6IdT$`Tw@-Sn
zpT01dK6W4J3rhL|PhS{FU)U#op`X4um_B|V>5EGGB2Ql&NMGD1eX*auG?;$uKGK(z
z^d+9YG?2cuPx?|neR(kb_s_7Y%ske(#w|zepX<)i~U=@
zEj`AUJicgM_q!Wh##U1A4!<>qx)W_9yBk`UDZM-V02%5|w2ka;Xq{mTnAVvThF>K^
z-HEo5-3_gqwB8+lstk1}+D3LavD}R%&QN!vP4CV*a&JF-XSz|%qtt@3iXFwCzq9hZs7{ovv-fuV{d%DxpHd5p6W%oG
z`fHi;t8av_T>44owU=Li_0nq_FTc)OhU+h%>OZZMmQ^yow7;|s8@u}OB-%Rv(zfi@
zm2Xp!V;R>k)C{*$YZz|5dfLDSc$N-DgGF7p>S2>TMaZbzC@g0H_j1h)_L?iTiWxF$
z#8ba?mg~WQ#2_bgu3yP!7qT=AQ8moGkAd{gw`~+-G{C$pXvqaYMf-Bb7E=9vi^#vg+$Mkvl63AeBt-kRQ73>{w}Z!j3#2QA}A_WN`vp#_((N`
zQ<)Vjl^2D0t+Z%cf4n-$BG@9pXO|AB7~Zk(*oKLA1Meh!zQ*M{_Fg=R8WLmw;YC({
zoqiVY?$Xa<`b3ykel=0X`i;24eyv@(iMs4vapmUo*B(R3w%?m*quHVw7$#2pP>dof
zF5kY(e0t@gVjaUoiHbF^2InwQ;x$R_%KK3iF%!bg`TH?5mKig6)$?S`FZ*>d-BeP(
z*9j(U#JhI5ubcKw+c=1l<)dejzOmF!jl~QM6z5O2Q)bMHSlG}*^b}noRnGVC-ICVM
ziQ*Yoc;Mt}p}K}gYLU<=?5ZPn;!d32=+4TcXL*^g^eElY)=r|4&5HUlrsO+~?6V@k
z-7^@Bxv}6e6fkkJC{LF7$rwE@psXA}L4Soc{pwy()<#K}@@w^Lb?Ud9zQ2fa`ReVv
z)=RA`$9d@cm70lzpYi=VKdjPOHM5K(s<8kqG5aNO=-(A6GO8=5Pn+q*reCa0bSFN!
zzKI>K9!v`t7uahy^KakXWPS94f!3ng<425kF%_d}#o1CSPR~%faIlTStKBW7#s4Jy
z>VJQK?#R=>tM!im%rSpC+vp}xaP1}IR%F+JCtWallM5%7Sod*MSR?q?h>Hv_WExAb
zj?0(VE$lM(j4;6PS3^cpP~-mrz)=)sw~Ub5uhK{ihEY`)QP4##cdvQLV02z3$Pyj_
z!Yp-7@MArcd{OGT)>zWpOO4ozd!h<0Z%iIN}C&Fr!N
E11ZdDc>n+a
diff --git a/tests/data/acpi/q35/DSDT.tis.tpm2
b/tests/data/acpi/q35/DSDT.tis.tpm2
index
c92d4d29c79352a60974ea9f665d0b9a410a4bac..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
100644
GIT binary patch
literal 0
HcmV?d1
literal 8894
zcmb7KO>7&-8J*>iv|28uB}GgAOH4RU+cZH!N%?Dwq$PLxXN%N|r0gVg!IkB-lAR)p
zBnFZg0b~V8TmvnVunu}DKnG0GTYKoaHQGxH^x%Vm1SopQp_c%?v?yZqVD)`79C?PM
zfS8BnezWh*H*a=lA2px6rq}wzamI`<3M+1
zIqlltm%ci7^amfGc_V-GxzB!d?V=R}U=iOYzL!Ee1eXKrSkQAm>TVhD5S?FJ=*@oA
z<(Ea9Ls!CpT5i~)iMm?oUu^F@>oxK&A7j$5`#CqafN{BvX6l%A^!<6pY?>VU{BC!5
z_mAR~Id3tiW(t)>v*H(9Ql$ZHq^iAL@mn=!Gj{84g2mcb9ExX87wcZuZ+M+-=IKte
zm1iNf1R*u8za3ak(6c}62CN$-c6a-%H~nFEo&93nW?%d_-e-MlMvN_GO}{rqW4U#g
z#TdhAzVSGXhUUAybGX{fclZ<|{V@#1uQpaAR$$rAshKCD5=f}_&XcDK9>C%rMKOAe
zN~Sqz9ViD
ztYq1EGx}!KG>>odo)_Jf+8!qkG-h)Q=T7ual$pmJ&Uv`ea`#4)7~DVJb;v?yn8%rc
zDXORL&C#~+Hd{vGrfr$HH59m*yR|G1Ubem6ES|(F_=|1f#w93l3%TM+Tqx9Q4I^<&
z&?s;V^|e~ouX-dEG;Tff*MByjdb{@F{Fk*ue|Bpj_4Ue6g5E>j3#@mjyJbbN
z0^Z@zk&VZ8m-SOo;|d+vjrrbz?geWyOvfWE$=1W*>N;cnb^E9|`qb;&=|l`qCtI$cDl&0y;Jn1rHnm$31Z5dS5mZ<@8N)cRk_2uL
z5evX+agFl;l_4?FKgUKm6WBpSObLxJ&IFV*5fT%l;n*l=$`M2vF(ouAn1FI7LSo7+
zSXTne`-yR;gvJC@4j!SZGp^~3bEbsG1yc?lp{jF2(>cMJ5;~#lM5yYV)O1d2Iwy6V
z2vwb?rqk4Pnz~Mes!qItl$oB=bWZ6y5vn>ZO{b;lv~-;aRhdy9
z+)rE6Y3n)>sydUJ&ZMR@sp~|j>YUbePHQ@+b)5)Roim!w8BOPmt`niE)6sM~nodX8
ziBQ#<(sZUYohe->LRDv4)0x(ErgfbNRh_e%&RI?8tgaKGsxzbM%xF3@x=w_u&I6jx
z1DehQx=w_u&N)rzoThV5*NIToiC+?U`s90PUeh_R>qMyPJgDhBsOdbY>qMyPJj9v#
z!JF_9XBGx8yF-HM-V2H84X}qb=3$L_SZ5+snMX9{5si67XChRYM>XbAj
[PATCH v2 0/3] tpm: Add missing ACPI device identification objects
This series of patches adds missing ACPI device identification objects _STR and _UID to TPM 1.2 and TPM 2 ACPI tables. Stefan Stefan Berger (3): tests: acpi: prepare for updated TPM related tables acpi: tpm: Add missing device identification objects tests: acpi: Add updated TPM related tables hw/arm/virt-acpi-build.c | 1 + hw/i386/acpi-build.c | 8 tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 8894 -> 8900 bytes tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 8894 -> 8921 bytes 4 files changed, 9 insertions(+) -- 2.31.1
Re: [PULL 22/22] python, iotests: replace qmp with aqmp
On 01/11/2021 18.30, John Snow wrote: Swap out the synchronous QEMUMonitorProtocol from qemu.qmp with the sync wrapper from qemu.aqmp instead. Add an escape hatch in the form of the environment variable QEMU_PYTHON_LEGACY_QMP which allows you to cajole QEMUMachine into using the old implementation, proving that both implementations work concurrently. Hi John, seems like this patch broke our device-crash-test script. If I now run "scripts/device-crash-test -q" I get lots of error messages... could you please have a look? Thomas
Re: [PATCH v2 1/3] tests: acpi: prepare for updated TPM related tables
On Tue, Nov 09, 2021 at 09:01:50AM -0500, Stefan Berger wrote:
> Replace existing TPM related tables, that are about to change, with
> empty files.
>
> Cc: Michael S. Tsirkin
> Cc: Igor Mammedov
> Cc: Ani Sinha
> Signed-off-by: Stefan Berger
Why do it though?
I don't think it's a good idea - will make it harder
to see what the changes are.
> ---
> tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 8894 -> 0 bytes
> tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 8894 -> 0 bytes
> tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 50 -> 0 bytes
> tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 76 -> 0 bytes
> tests/qtest/bios-tables-test-allowed-diff.h | 11 +++
> 5 files changed, 11 insertions(+)
>
> diff --git a/tests/data/acpi/q35/DSDT.tis.tpm12
> b/tests/data/acpi/q35/DSDT.tis.tpm12
> index
> c96b5277a14ae98174408d690d6e0246bd932623..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
> 100644
> GIT binary patch
> literal 0
> HcmV?d1
>
> literal 8894
> zcmb7KO>7&-8J*>iv|6sDB}GgAOGG$M+BAVfN%?Dwq$PLxXN%N|r0gVg!IkB-lAR)p
> zBnFZg0b~V890LuKunu}DKnG0GTYKoaHQGxH^x%Vm1Sopwp_c%?v?yZqVD)`79C?PM
> zfS8BnezWh*H*a=lA2px6hS&W4F~*EX@+)q+k;%W{yBT~8#u%N`w^NCoWvy*5UuqkP
> zNX%$mN$_(V@@D#RFTYkYez6&R8U$~=9~kQ)JNKD${oH!^?$zKNBhaODp=HsDQ z^6l1+Yx!;^YqrZ3&(7VlOtbBZv#8n5d39#C*D4-MFORoZ8gA^`Mdo^E7P_@~XEQlt
> zIj!p7mcE`p`omApypg;4+!sH-cF~Ffu!wIH-%BAKg3Ez5A9S5hI$Op&MCaEQx-*}2
> z_+`=N(3LQtmK(NcqOKNt7h5~edi9*k$2jTN{H&W@z_{FcBROv!eSeNIn z{ew7V&Rfi>nnGp4Ec=C~RB1pPscLPP{brTfjNQ7MV6oN}hvJ#jg_@V~>s~vPe!AUg
> z=2%EAK}b#OZwHnWbnTBj0qX>b-Q6DRPJP^2XFp%J*+2dp@3EdWEyk9#rrw*NvD~`L
> zVvJ!lkDQ><(0sRc4p$nvHlJdopT|)AN_{nA1(xlcntmcGfrM)9Jb5bb0W9uO6r;ze
> zWSWE4fszrhfEh-~IM2@G`&b0oT06(9D{FhK=^2e>TJd8vL#>^~Wxu%~`;LkGZD?4>
> znk*S_M&FE@=CN(w^P;;_-Q&c8#%zw@+= zMYZI;IokH!M$<^#v@H|2h5{FJx0b=d%e1x|g_BqXf3_{$xC8}mK3h163;9~LZX|9A
> z8U=2?wpPvf74L;i%g8Ugr&#)7-z}Vsv>u{pcQ@Q5MEI7m#i) zLOKL}Y>@WGe6LZR>Mr+}#;s@m^3TRoZ&yE_`>J~APi{4&zFzrh(0! zz&rdovhmpNvR*Q3T%iNIG1ooNxnPZlsd$7 z4SHA{_ba}T{d&_+oqBycm5AZ#WXrWv1t!i7oEKTjrgkfWpd^DRf-*}@#xM@7B!TNk
> z!~$?iT;n`IWk^i)&#@8C1hyX$Q$iz*GXdpHgv7*XI5x_eas*LEObLw&CZL>&keD(H
> z)|J5Weqx*{p)tXfgGZ?9jB7gMoGGDk!IXnXsOlWkbdGVRgpTPt5vn@JHJ#&{&T(BQ
> zLRF`!=`=N+rmhpAsuOP@Wu_-IofEoFgsM(U(`jisEnO! z_tVyN+PY4Js?JGG=cJ}{QrC%4)j6f z6QQazsp(8=I+MCigsRSzrZc7KOzAoisyb&hoim!w8C@qrRcBh$nbvfsb)5)Rod-0X
> z2Q-}rbe#xQowJ(GSxx7xt`niE6Tc+z^vU z{Wswu&dm2;c83Jhy%!SG>thdV%)=V z(3lTs%m;KPLY4U-XG)iOkTc~w{z1W%FK&dyly`7m%Q>&*oY!+A6gf>8XihQEQlo;@
> z+)NFeBXQqA5g@Gyq6lPC7^uK;OEMU- z0~OeQL^)Lh70^8cMTik`EDTg&`%zybhmwH`s0>w|Fi_DgXTm@gC>bb1>562a2&GOK
> zsK9b23{-)VfeI+kNd}5g>V$y`EN8+%6(|{~fN~}oC_ z<^6<#3M^;BKouw%sDN@N87M-j69y` zl7S+WI$@v!%b74x1xf}gpqxnticso=feI{V!ax-$8K{7ACK)I~sS^e&u$&14RiI>`
> z0?L_Wpa`W-7^uK zC>f}LawZulLa7r5DzKah16818paRO7WS|J8P8g`bawZH^fs%m=C})y^B9uB|paRR8
> zFi-_b1}dPONd}5g>V$y`EN8+%6(|{~fN~}oC_A
> zz;Y%GRDqI#3Mglifg+STVW0xbnJ`cVN(L&RoJj_XQ0jz%B2o+#k!qj_RRcw+7^uR8
> zfhtTgP=!ebsxV=o3KIsZFv&m_CK;&0gn=qd7^uP|167!0pb8TPsxV=o3X=>}VUmF=
> zOc*F4d3Rx;h;YaFWRig*#BGovG3DICKoQBgg@GcHb4vz_P|htGC_-!%9d5%yS=a9H
> zKURD62kDJ5`pUJgeD8@U{gq0)8noYG`1REs9CtNO2bT_>$*}jbTA=eH9ZGa4o9UU#
> zDs}_96PK;+O>DAE^sGes$;zr*p8%kqO-@;f560L8-wAq)U86QDj$R99
> z*m_wW$8Ut3-14xoT|=8eCWhTe&RR1cOtFb5+>PP=&G071?nQc z278Cjt!>^iP5V&{2)EATxpt%8Fs^O($3W?+y`MclkR6*R-#B|-$)4xg^BA9+J)a((
> zJ>S}?l6J9`hV8z-b}Mop>0Kqg%hS69>D_(OyZ!XufOrcVTHjc`r=<6IdT$`Tw@-Sn
> zpT01dK6W4J3rhL|PhS{FU)U#op`X4um_B|V>5EGGB2Ql&NMGD1eX*auG?;$uKGK(z
> z^d+9YG?2cuPx?|neR(kb_s_7Y%ske(#w|zepX<)i~U=@
> zEj`AUJicgM_q!Wh##U1A4!<>qx)W_9yBk`UDZM-V02%5|w2ka;Xq{mTnAVvThF>K^
> z-HEo5-3_gqwB8+lstk1}+D3Lav z>D}R%&QN!vP4CV*a&JF-XSz|%qtt@3iXFwCzq9hZs7{ovv-fuV{d%DxpHd5p6W%oG
> z`fHi;t8av_T>44owU=Li_0nq_FTc)OhU+h%>OZZMmQ^yow7;|s8@u}OB-%Rv(zfi@
> zm2Xp!V;R>k)C{*$YZz|5dfLDSc$N-DgGF7p>S2>TMaZbzC@g0H_j1h)_L?iTiWxF$
> z#8ba?mg~WQ#2_bgu3yP!7qT=AQ8 zENzfb5moGkAd{gw`~+-G{C$pXvqaYMf- z9~q`wE1XG1c0;xi8s|UrQl0Zg$j*mG5VG~pmhF!^fpL8UO+mOZn34+~Y{X6J&RrjD
> z#ckR6ygSiZw|0@{^KjJl?(w0Sqx&9iT%|FtvrFq3)s1JmPYuENlY!f}VMW8CiNQti
> zE^Sa@u@DoLMe6Vz+n`$xZ5yqH(c*^s!gwy78$Hd{33sK@wD+0j(ND`z|CqdRYsB1y
> zR%Ec1pce)kG0h`K*LwF^dZw}d@xk)Ib8YtM>Bb7E=9 zTNlztuy{&-pvi^#vg+$Mkvl63AeBt-kRQ73>{w}Z!j3#2QA}A_WN`vp#_((N`
> zQ<)Vjl^2D0t+Z%cf4n-$BG@9pXO|AB7~Zk(*oKLA1Meh!zQ*M{_Fg=R8WLmw;YC({
> zoqiVY?$Xa<`b3ykel=0X`i;24eyv@(iMs4vapmUo*B(R3w%?m*quHVw7$#2pP>dof
> zF5kY(e0t@gVjaUoiHbF^2InwQ;x$R_%KK3iF%!bg`TH?5mKig6)$?S`FZ*>d-BeP(
> z*9j(U#JhI5ubcKw+c=1l<)dejzOmF!jl~QM6z5O2Q)bMHSlG}*^b}noRnGVC-ICVM
> ziQ*Yoc;Mt}p}K}gYLU<=?5ZPn;!d32=+4TcXL*^g^eElY)=r|4&5HUlrsO+~?6V@k
> z-7^@Bxv}6e6fkkJC{LF7$rwE@psXA}L4Soc{pwy()<#K}@@w^Lb?Ud9zQ2fa`ReVv
> z)=RA`$9d@cm70lzpYi=VKdjPOHM5K(s<8kqG5aNO=-(A6GO8=5Pn+q*reCa0bSFN!
> zzKI>K9!v`t7uahy^KakXWPS94f!3ng<425kF%_d}#o1CSPR~%faIlTStKBW7#s4Jy
> z>VJQK?#R=>tM!im%rSpC+vp}xaP1}IR%F+JCtWallM5%7Sod*MSR?q?h>Hv_WExAb
> zj?0(VE$lM(j4;6PS3^cpP~-mrz)=)sw~Ub5uhK{ihEY`)QP4##cdvQLV02z3$Pyj_
> z!Yp-7@MArcd{O zEr-ylsdw7r{qWi|Jc0jf$G@7vGc$j^RQ%{@>GT)>zWpOO4ozd!h<0Z%iIN}C&Fr!N
> E11ZdDc>n+a
>
> diff --git a/tests/data/acpi/q35/DSDT.tis.tpm2
Re: [PATCH v2 3/3] tests: acpi: Add updated TPM related tables
On Tue, Nov 09, 2021 at 09:01:52AM -0500, Stefan Berger wrote:
> The updated TPM related tables have the following additions:
>
>Device (TPM)
>{
>Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */) // _HID:
> Hardware ID
> + Name (_STR, "TPM 2.0 Device") // _STR: Description String
> + Name (_UID, One) // _UID: Unique ID
>Name (_STA, 0x0F) // _STA: Status
>Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
>
> Cc: Michael S. Tsirkin
> Cc: Igor Mammedov
> Cc: Ani Sinha
> Signed-off-by: Stefan Berger
> ---
> tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 0 -> 8900 bytes
> tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 0 -> 8921 bytes
> tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 0 -> 50 bytes
> tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 0 -> 76 bytes
> tests/qtest/bios-tables-test-allowed-diff.h | 11 ---
> 5 files changed, 11 deletions(-)
A disadvantage to doing it like this is that git thinks
it's ok to replace any empty file with this, so if acpi
changed in any way git will happily resolve it
replacing it with this version.
> diff --git a/tests/data/acpi/q35/DSDT.tis.tpm12
> b/tests/data/acpi/q35/DSDT.tis.tpm12
> index
> e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..dc1c990496a8fb0fc268081a54c5af363bcd833f
> 100644
> GIT binary patch
> literal 8900
> zcmb7KOKcm*8J^`sS}j-7lA z7)W9SkQE?t475nXI_RYU9WX_2?V z5c9CyfA;(4pKo?&KWct?4X^pfV~iR9$gjBNMkfD)?`H5Z7-Mu!-%cfVmbJFMe5q|D
> zA~BgdtyH|sAj6j#pg_cDpPGPFu
> z$hTWNuI0Oxtl2JCJUe&GGR?Lt&Z1^J=hd0nUaNR4y*%DtX}Ga#7n$pwS?Jc{oz3Ko
> z<+Q4QUHWSN==VQ4^G5FGbD#h4+C?h{z#_g)d@qG`2rdWKe9(11?ra(F5S?FJ=+1oH
> z;g?05Ls!CpT5i~)iMm?oU2N?<>(z5EALFE7^RsSt0poJ(jpV#_^!+);Y?>VU{APD|
> z_jlryId3tiY6_JFv+Ng|Ql$ZHq^h-D_M25^Gj{84g2h@_9ExX77iwO{uY2uG`ssF~
> znPVZf1R*u8za3ak(6vA61gsMzc6WQMJM~d#o&9XxW`F;0yvKUhv>02`ntE@7#&YW}
> zi!p}LeB%U-hUUAqbGXvTwfPhy{XB-^SL&+~E3j zCDRP0wg7(~2LX8EWk;F8j>|*>_CbZ$ra6
> z)?~?eGx}!KG>>ibo)_Jf>K-Q!G-h)I=T7ual$pmI&Uv`rboWM+=-)ryb;v?yn8%ob
> zDXJy!&C#~+HkwA_rfr$HH59m*yR{4sUZ%C(D4fJ9_>*nn#w93l^Vz~lT*%j|bt7?0
> z&?s>8wY6%-uXrzHT1I}^J;l-w`)=W6r1cO*ySw2gA;PzeEk=E`zDdnJmVPV;&L|Z1
> z71AN-V}rCe=6j9mRCl?*G;Tff=YKYydb|43+?Ulue{icI_4Ue+gYH9}3#@ynvt>oF
> z0^Z@zk&VZ8m-UiS;|d+vjk)fD&IM~cOvNK?lC6iq)pf>t>!x3Ei!5!o@oj{g6gfYA
> z(V&OLalhmX*{?VK)T!6EQ;8U!PPSY-Rbb-Wz zL@WTO#5K+XREESv{~R0POkn#FF(ov@I1^CLL`Y1GhGV0gDMt`x#FWseU;@gS2#G1P
> zU|k6;? zB2;ynnod*GY3e!=syguoQf7KW(>bB*M5yYtG@X{F)6#V!RCOjaoe526Lf45<)rohZ
> zazAZNr>*NmsOp^5bWUnICv}|&Rh?6s&M8gjl&%w@s&iV?Ij!lO)^#FObvl|(N7L!(
> zIuWWmlbX(?rZcJQM5yXaX*yGy&Xlebp{jF6(>bH*oY8e6RCT5`ooP*HTGxqC)p zc|g;7K-Y;-)j6x_oYi#B>N*jsI`K;aPoI1b&1pL4be#xQod-3Y2Q{4sb)5)RorgFx
> z*MAcp;>>*iWp_w0-FqQ1y*~D^#yqSs59>^XD)WfOJfbm==uCtv^Qgu=sxgo1OoS@)
> z0gd^9#(Y3$B2<|Va;9{d2RT!|;~x}E`Qk=MOnC?AwVd->&Urm2LXp#if#wtgEj21g
> z&CS%nITH5`6amtTAc{aHg@Fnjw zG*E% zfeI{V!ax-$8K{8roMfN~rA`>Az;Y%GRDqI#3Mglifg+STVW0xbnJ`cVN(L&RoJj_X
> zP~J}%sK9b23{-)VfeI*Rl7S+WI$@v!%b74x1xf}gpqxnticso=feI{V!ax-$8K{7A
> zCK)I~sS^e&u$&14RiI>`0?L_Wpa`W-7^uK zDxjQ628vMXgnf}LawZulLa7r5DzKah16818paRO7WS|J8P8g`bawZH^
> zfs%m=C})y^B9uB|paRR8Fi-_b1}dPONd}5g>V$y`EN8+%6(|{~fN~}oC_ z2?JH2WS|1dnPi{{rA`>Az;Y%GRDqI#3Mglifg+STVW0xbnJ`cVN(L&RoJj_XQ0jz%
> z3M^;BKouw%sDN@N87M-j69y`P&H75ih(Lj
> z7^uP|167!0pb8TPsxV=o3X=>}VUmF=Oc z!i0e$l6MydiU@a%PbL{CLfi%!5>w7C3>1-^TNo%JIk#k>2<6<8fg;3K(cv~Mly&V6
> z|6{dBe~{i7qpw`+%6FcK(qE~xt3mr6hF@RJ!Esmfba3h5nGAa`s|7kQ(xF6$vYDQ#
> ztYSByJ8{|C-oz%$M9)g3pRBC9^$7s#+2oX!_+X4p@SUKy*fnai;y6~q%bV6TqcaSm
> zj;)vFar{Qe$t@2X+cmTqWMbHj|Ug&`94sOhJexJ(#f`0
> zX|Q+b+}h?X)3hJOfN<+Po@+Pi4ddEoe+-nK+WXn_1KF{8^0l+)mF#(*J&*CJ+4Jeq
> z+4HTPDrpy6Y1r=TYquizk=|9(yF9%+klx)Vz1vUk4T!g}q4l-ZdrEqbr}qZZd;6sK
> z`soXU>0|eizM!Np@bra&^o4!W7y9XogX!b zNnhgWO9Sak`=l@R)0YR+kKaf7vXZ{c)0YR*m-k6uM*0}N$_CRrBE5Wh;AaJvyV$?g
> z+tOov$>WRGb-%m8Wo#w&?(kb z)SYM>+1=2(N$cI=r^--wqHSb%L+jvx-W`6w40R{kMs_#!T+iy=;YZC-ccN`%cSFzV
> zoZcON=?rxz+Vt+6Blq^RccvTFJW4GntJqQO`8zAmi|Rz#I(u)&->(-M@+q~jIN?o`
> zuD_Nkzxqb_%B3G=UVHiVS1-M`@$&1eWw`$Gss7VCX;~%X3;PS(u(7KTPok~!FKo+h
> zUHKLTIhJw#Ld|e1wT9u=tEUZYfM@AYG+5Mis~$GlQ-qAVjlyyUa4*-)V6VAStC%69
> zMm+UPXSp5>NDOi^=lYdwb|Fi{5QU?7I_WlxFGjjnXOq3>X0zF?ba@QB_qmDILua3e
> z$}YkKG=+8Aq%>PJA)TULTF86+kNQD@~K{suEt5${UtI6yFw2m`%f2V-G*B;
> z_mN?`wZfTHWH)3Rp>h6GFV#73gzS811R-1hblLu}6BySw&=iClgDJV-!A9Ja?%egk
> zR@|12&$<(xb!!)CJ_|=(?;anTIlAxR##I{QI=i%vQQdf^`_vGOKN+}v8&)(NniyOJ
> z@6rYp77H;^S)>lnu?@QA(6-T97%gt7FO28XxzW>Hop4tgO?#hd9{sco^^eI5w?@oO
> zXhjBF33_3$5z{ zxpg6Z1dFHS7utpFBI~bsT1fOvIV&-`#20>lO=X{E>2CwOz-S`&DuSY7r8M|%jgM4A
> zIF(tkQh8B`*Gh}F_4})nEP^cpe0J%8is2pmj%}D|H}Fov=PO*kWADY2s39@-A6{hT
> z*Xd{R?k@c-rcZ=vO>{r^Ao2bj)6<2OPf9)}pZ2P^5HkvJ}fnnmb55*{=
> z;_~gg%%@i_D%LSfl&DzqYH$t{C0>)%uDl;b5i=p&oWCD4W0^67S3OV0{IXvc(@iDi
> zd!1myM!ai>`?_i0w2gx(Sw3 zoG6}gg$GWq7OHD_q!tN{!mc`EC+@`QjqVg4JSvd@YD
> zch6uj=Ej1@P{72=qC8pRCu8)ufKqt)1pO7(^s9SCSsNwYp+c^xVyib`yXpIjD4MU{
> zzH7bIx^kR{zF(=CIQSXguk*tyomDf-IHD#C&=Rv>0*C%-fg+>2a{9EHUTpfs+C+Ea
> zQd<0H
> z!Y}{#x95&L{o7ja_)i@37qg9S0%g};GHyk74LH*Uqc^#5Vu^JhN1Zi-e~`Gy@LHy^
> z1n
Re: [PATCH v2 2/3] acpi: tpm: Add missing device identification objects
On Tue, Nov 09, 2021 at 09:01:51AM -0500, Stefan Berger wrote:
> Add missing device identification objects _STR and _UID. They will appear
> as files 'description' and 'uid' under Linux sysfs.
>
> Cc: Shannon Zhao
> Cc: Michael S. Tsirkin
> Cc: Igor Mammedov
> Cc: Ani Sinha
> Fixes: https://gitlab.com/qemu-project/qemu/-/issues/708
> Signed-off-by: Stefan Berger
Do you want this in 6.2?
> ---
> hw/arm/virt-acpi-build.c | 1 +
> hw/i386/acpi-build.c | 8
> 2 files changed, 9 insertions(+)
>
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 674f902652..09456424aa 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -228,6 +228,7 @@ static void acpi_dsdt_add_tpm(Aml *scope,
> VirtMachineState *vms)
>
> Aml *dev = aml_device("TPM0");
> aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
> +aml_append(dev, aml_name_decl("_STR", aml_string("TPM 2.0 Device")));
> aml_append(dev, aml_name_decl("_UID", aml_int(0)));
>
> Aml *crs = aml_resource_template();
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index a3ad6abd33..5bd2160a89 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -1808,11 +1808,15 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> dev = aml_device("TPM");
> aml_append(dev, aml_name_decl("_HID",
>aml_string("MSFT0101")));
> +aml_append(dev,
> + aml_name_decl("_STR",
> + aml_string("TPM 2.0 Device")));
When we support more versions, won't this make us
do annoying tricks to say so in the string?
Why not just "TPM device" to future-proof it?
> } else {
> dev = aml_device("ISA.TPM");
> aml_append(dev, aml_name_decl("_HID",
>aml_eisaid("PNP0C31")));
> }
> +aml_append(dev, aml_name_decl("_UID", aml_int(1)));
>
The ACPI spec mentions also matching on _CID.
> aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
> crs = aml_resource_template();
> @@ -1840,6 +1844,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
> if (TPM_IS_CRB(tpm)) {
> dev = aml_device("TPM");
> aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
> +aml_append(dev, aml_name_decl("_STR",
> + aml_string("TPM 2.0 Device")));
> crs = aml_resource_template();
> aml_append(crs, aml_memory32_fixed(TPM_CRB_ADDR_BASE,
> TPM_CRB_ADDR_SIZE,
> AML_READ_WRITE));
> @@ -1847,6 +1853,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
>
> aml_append(dev, aml_name_decl("_STA", aml_int(0xf)));
>
> +aml_append(dev, aml_name_decl("_UID", aml_int(1)));
> +
> tpm_build_ppi_acpi(tpm, dev);
>
> aml_append(sb_scope, dev);
> --
> 2.31.1
Re: [PULL 05/33] i386: Add 'sgx-epc' device to expose EPC sections to guest
On 28/09/2021 14.50, Paolo Bonzini wrote:
From: Sean Christopherson
SGX EPC is enumerated through CPUID, i.e. EPC "devices" need to be
realized prior to realizing the vCPUs themselves, which occurs long
before generic devices are parsed and realized. Because of this,
do not allow 'sgx-epc' devices to be instantiated after vCPUS have
been created.
The 'sgx-epc' device is essentially a placholder at this time, it will
be fully implemented in a future patch along with a dedicated command
to create 'sgx-epc' devices.
Signed-off-by: Sean Christopherson
Signed-off-by: Yang Zhong
Message-Id: <20210719112136.57018-5-yang.zh...@intel.com>
Signed-off-by: Paolo Bonzini
---
hw/i386/meson.build | 1 +
hw/i386/sgx-epc.c | 167 ++
include/hw/i386/sgx-epc.h | 44 ++
3 files changed, 212 insertions(+)
create mode 100644 hw/i386/sgx-epc.c
create mode 100644 include/hw/i386/sgx-epc.h
...
+static void sgx_epc_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+MemoryDeviceClass *mdc = MEMORY_DEVICE_CLASS(oc);
+
+dc->hotpluggable = false;
+dc->realize = sgx_epc_realize;
+dc->unrealize = sgx_epc_unrealize;
+dc->desc = "SGX EPC section";
+device_class_set_props(dc, sgx_epc_properties);
+
+mdc->get_addr = sgx_epc_md_get_addr;
+mdc->set_addr = sgx_epc_md_set_addr;
+mdc->get_plugged_size = sgx_epc_md_get_plugged_size;
+mdc->get_memory_region = sgx_epc_md_get_memory_region;
+mdc->fill_device_info = sgx_epc_md_fill_device_info;
+}
Hi!
Our device-crash-test script reports that this new device can be used to
crash QEMU:
$ ./qemu-system-x86_64 -M none -device sgx-epc
/home/thuth/devel/qemu/include/hw/i386/pc.h:128:PC_MACHINE: Object
0x55c80d332290 is not an instance of type generic-pc-machine
Should it be marked with:
dc->user_creatable = false
?
Thomas
Re: [PATCH v2 2/3] acpi: tpm: Add missing device identification objects
On 11/9/21 09:20, Michael S. Tsirkin wrote:
On Tue, Nov 09, 2021 at 09:01:51AM -0500, Stefan Berger wrote:
Add missing device identification objects _STR and _UID. They will appear
as files 'description' and 'uid' under Linux sysfs.
Cc: Shannon Zhao
Cc: Michael S. Tsirkin
Cc: Igor Mammedov
Cc: Ani Sinha
Fixes: https://gitlab.com/qemu-project/qemu/-/issues/708
Signed-off-by: Stefan Berger
Do you want this in 6.2?
Yes.
---
hw/arm/virt-acpi-build.c | 1 +
hw/i386/acpi-build.c | 8
2 files changed, 9 insertions(+)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 674f902652..09456424aa 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -228,6 +228,7 @@ static void acpi_dsdt_add_tpm(Aml *scope, VirtMachineState
*vms)
Aml *dev = aml_device("TPM0");
aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
+aml_append(dev, aml_name_decl("_STR", aml_string("TPM 2.0 Device")));
aml_append(dev, aml_name_decl("_UID", aml_int(0)));
Aml *crs = aml_resource_template();
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a3ad6abd33..5bd2160a89 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -1808,11 +1808,15 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
dev = aml_device("TPM");
aml_append(dev, aml_name_decl("_HID",
aml_string("MSFT0101")));
+aml_append(dev,
+ aml_name_decl("_STR",
+ aml_string("TPM 2.0 Device")));
When we support more versions, won't this make us
do annoying tricks to say so in the string?
Why not just "TPM device" to future-proof it?
I am not sure what other version there will be and I haven't seen any
other descriptions than the one reported here:
https://gitlab.com/qemu-project/qemu/-/issues/708
That's why I took TPM 2.0 device. My TPM 1.2 machine doesn't report it
for a TPM 1.2.
haven } else {
dev = aml_device("ISA.TPM");
aml_append(dev, aml_name_decl("_HID",
aml_eisaid("PNP0C31")));
}
+aml_append(dev, aml_name_decl("_UID", aml_int(1)));
The ACPI spec mentions also matching on _CID.
"6.1.2 _CID (Compatible ID)
This optional object is used to supply OSPM with a device?s Plug and
Play-Compatible Device ID. Use _CID
objects when a device has no other defined hardware standard method to
report its compatible IDs"
6.1.12 _UID (Unique ID)
This object provides OSPM with a logical device ID that does not change
across reboots. This object is
optional, but is required when the device has no other way to report a
persistent unique device ID. The
_UID must be unique across all devices with either a common _HID or _CID.
Is _CID a must-have for TPM now? We have _HID.
aml_append(dev, aml_name_decl("_STA", aml_int(0xF)));
crs = aml_resource_template();
@@ -1840,6 +1844,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
if (TPM_IS_CRB(tpm)) {
dev = aml_device("TPM");
aml_append(dev, aml_name_decl("_HID", aml_string("MSFT0101")));
+aml_append(dev, aml_name_decl("_STR",
+ aml_string("TPM 2.0 Device")));
crs = aml_resource_template();
aml_append(crs, aml_memory32_fixed(TPM_CRB_ADDR_BASE,
TPM_CRB_ADDR_SIZE,
AML_READ_WRITE));
@@ -1847,6 +1853,8 @@ build_dsdt(GArray *table_data, BIOSLinker *linker,
aml_append(dev, aml_name_decl("_STA", aml_int(0xf)));
+aml_append(dev, aml_name_decl("_UID", aml_int(1)));
+
tpm_build_ppi_acpi(tpm, dev);
aml_append(sb_scope, dev);
--
2.31.1
Re: [PATCH v2 3/3] tests: acpi: Add updated TPM related tables
On Tue, Nov 09, 2021 at 09:14:25AM -0500, Michael S. Tsirkin wrote:
> On Tue, Nov 09, 2021 at 09:01:52AM -0500, Stefan Berger wrote:
> > The updated TPM related tables have the following additions:
> >
> >Device (TPM)
> >{
> >Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */) // _HID:
> > Hardware ID
> > + Name (_STR, "TPM 2.0 Device") // _STR: Description String
> > + Name (_UID, One) // _UID: Unique ID
> >Name (_STA, 0x0F) // _STA: Status
> >Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
> >
> > Cc: Michael S. Tsirkin
> > Cc: Igor Mammedov
> > Cc: Ani Sinha
> > Signed-off-by: Stefan Berger
> > ---
> > tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 0 -> 8900 bytes
> > tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 0 -> 8921 bytes
> > tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 0 -> 50 bytes
> > tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 0 -> 76 bytes
> > tests/qtest/bios-tables-test-allowed-diff.h | 11 ---
> > 5 files changed, 11 deletions(-)
>
> A disadvantage to doing it like this is that git thinks
> it's ok to replace any empty file with this, so if acpi
> changed in any way git will happily resolve it
> replacing it with this version.
Do we actually need to be storing these binary files in git
at all ?
IIUC, the test will do two things
- memcmp the expected binary we store, against the new binary
we generated.
- if they differ, then disassemble both and report the
differences in a user friendly-ish way
What if we only stored the sha256 checksum of the binary *and*
the dissasembled output in git, never the full binary.
IIUC, that would give us the same level of diagnostic output
from the test failures. The dissasembled output would then
give us meaningful patches for reviewers to look at. The
author wouldn't have to describe the difference in the
commit message as Stefan has (helpfully) done here.
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 v2 1/3] tests: acpi: prepare for updated TPM related tables
On 11/9/21 09:11, Michael S. Tsirkin wrote:
On Tue, Nov 09, 2021 at 09:01:50AM -0500, Stefan Berger wrote:
Replace existing TPM related tables, that are about to change, with
empty files.
Cc: Michael S. Tsirkin
Cc: Igor Mammedov
Cc: Ani Sinha
Signed-off-by: Stefan Berger
Why do it though?
With 'it' are you referring to the empty files? Should I just leave the
file untouched and just ignore them?
How many patches should it be? One for ignoring the about-to-change
tables, one that does the changes, and one that re-introduces the
tables? Or squash them together in less patches?
I don't think it's a good idea - will make it harder
to see what the changes are.
Stefan
---
tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 8894 -> 0 bytes
tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 8894 -> 0 bytes
tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 50 -> 0 bytes
tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 76 -> 0 bytes
tests/qtest/bios-tables-test-allowed-diff.h | 11 +++
5 files changed, 11 insertions(+)
diff --git a/tests/data/acpi/q35/DSDT.tis.tpm12
b/tests/data/acpi/q35/DSDT.tis.tpm12
index
c96b5277a14ae98174408d690d6e0246bd932623..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
100644
GIT binary patch
literal 0
HcmV?d1
literal 8894
zcmb7KO>7&-8J*>iv|6sDB}GgAOGG$M+BAVfN%?Dwq$PLxXN%N|r0gVg!IkB-lAR)p
zBnFZg0b~V890LuKunu}DKnG0GTYKoaHQGxH^x%Vm1Sopwp_c%?v?yZqVD)`79C?PM
zfS8BnezWh*H*a=lA2px6hS&W4F~*EX@+)q+k;%W{yBT~8#u%N`w^NCoWvy*5UuqkP
zNX%$mN$_(V@@D#RFTYkYez6&R8U$~=9~kQ)JNKD${oH!^?$zKNBhaODp=HsDQnnGp4Ec=C~RB1pPscLPP{brTfjNQ7MV6oN}hvJ#jg_@V~>s~vPe!AUg
z=2%EAK}b#OZwHnWbnTBj0qX>b-Q6DRPJP^2XFp%J*+2dp@3EdWEyk9#rrw*NvD~`L
zVvJ!lkDQ><(0sRc4p$nvHlJdopT|)AN_{nA1(xlcntmcGfrM)9Jb5bb0W9uO6r;ze
zWSWE4fszrhfEh-~IM2@G`&b0oT06(9D{FhK=^2e>TJd8vL#>^~Wxu%~`;LkGZD?4>
znk*S_M&FE@=CN(w^P;;_-Q&c8#%zw@+=u{pcQ@Q5MEI7m#i)@WGe6LZR>Mr+}#;s@m^3TRoZ&yE_`>J~APi{4&zFzrh(0!&keD(H
z)|J5Weqx*{p)tXfgGZ?9jB7gMoGGDk!IXnXsOlWkbdGVRgpTPt5vn@JHJ#&{&T(BQ
zLRF`!=`=N+rmhpAsuOP@Wu_-IofEoFgsM(U(`jisEnO!thdV%)=V&*oY!+A6gf>8XihQEQlo;@
z+)NFeBXQqA5g@Gyq6lPC7^uK;OEMU-w|Fi_DgXTm@gC>bb1>562a2&GOK
zsK9b23{-)VfeI+kNd}5g>V$y`EN8+%6(|{~fN~}oC_`
z0?L_Wpa`W-7^uKf}LawZulLa7r5DzKah16818paRO7WS|J8P8g`bawZH^fs%m=C})y^B9uB|paRR8
zFi-_b1}dPONd}5g>V$y`EN8+%6(|{~fN~}oC_A
zz;Y%GRDqI#3Mglifg+STVW0xbnJ`cVN(L&RoJj_XQ0jz%B2o+#k!qj_RRcw+7^uR8
zfhtTgP=!ebsxV=o3KIsZFv&m_CK;&0gn=qd7^uP|167!0pb8TPsxV=o3X=>}VUmF=
zOc*F4d3Rx;h;YaFWRig*#BGovG3DICKoQBgg@GcHb4vz_P|htGC_-!%9d5%yS=a9H
zKURD62kDJ5`pUJgeD8@U{gq0)8noYG`1REs9CtNO2bT_>$*}jbTA=eH9ZGa4o9UU#
zDs}_96PK;+O>DAE^sGes$;zr*p8%kqO-@;f560L8-wAq)U86QDj$R99
z*m_wW$8Ut3-14xoT|=8eCWhTe&RR1cOtFb5+>PP=&G071?nQc^iP5V&{2)EATxpt%8Fs^O($3W?+y`MclkR6*R-#B|-$)4xg^BA9+J)a((
zJ>S}?l6J9`hV8z-b}Mop>0Kqg%hS69>D_(OyZ!XufOrcVTHjc`r=<6IdT$`Tw@-Sn
zpT01dK6W4J3rhL|PhS{FU)U#op`X4um_B|V>5EGGB2Ql&NMGD1eX*auG?;$uKGK(z
z^d+9YG?2cuPx?|neR(kb_s_7Y%ske(#w|zepX<)i~U=@
zEj`AUJicgM_q!Wh##U1A4!<>qx)W_9yBk`UDZM-V02%5|w2ka;Xq{mTnAVvThF>K^
z-HEo5-3_gqwB8+lstk1}+D3LavD}R%&QN!vP4CV*a&JF-XSz|%qtt@3iXFwCzq9hZs7{ovv-fuV{d%DxpHd5p6W%oG
z`fHi;t8av_T>44owU=Li_0nq_FTc)OhU+h%>OZZMmQ^yow7;|s8@u}OB-%Rv(zfi@
zm2Xp!V;R>k)C{*$YZz|5dfLDSc$N-DgGF7p>S2>TMaZbzC@g0H_j1h)_L?iTiWxF$
z#8ba?mg~WQ#2_bgu3yP!7qT=AQ8moGkAd{gw`~+-G{C$pXvqaYMf-Bb7E=9vi^#vg+$Mkvl63AeBt-kRQ73>{w}Z!j3#2QA}A_WN`vp#_((N`
zQ<)Vjl^2D0t+Z%cf4n-$BG@9pXO|AB7~Zk(*oKLA1Meh!zQ*M{_Fg=R8WLmw;YC({
zoqiVY?$Xa<`b3ykel=0X`i;24eyv@(iMs4vapmUo*B(R3w%?m*quHVw7$#2pP>dof
zF5kY(e0t@gVjaUoiHbF^2InwQ;x$R_%KK3iF%!bg`TH?5mKig6)$?S`FZ*>d-BeP(
z*9j(U#JhI5ubcKw+c=1l<)dejzOmF!jl~QM6z5O2Q)bMHSlG}*^b}noRnGVC-ICVM
ziQ*Yoc;Mt}p}K}gYLU<=?5ZPn;!d32=+4TcXL*^g^eElY)=r|4&5HUlrsO+~?6V@k
z-7^@Bxv}6e6fkkJC{LF7$rwE@psXA}L4Soc{pwy()<#K}@@w^Lb?Ud9zQ2fa`ReVv
z)=RA`$9d@cm70lzpYi=VKdjPOHM5K(s<8kqG5aNO=-(A6GO8=5Pn+q*reCa0bSFN!
zzKI>K9!v`t7uahy^KakXWPS94f!3ng<425kF%_d}#o1CSPR~%faIlTStKBW7#s4Jy
z>VJQK?#R=>tM!im%rSpC+vp}xaP1}IR%F+JCtWallM5%7Sod*MSR?q?h>Hv_WExAb
zj?0(VE$lM(j4;6PS3^cpP~-mrz)=)sw~Ub5uhK{ihEY`)QP4##cdvQLV02z3$Pyj_
z!Yp-7@MArcd{OGT)>zWpOO4ozd!h<0Z%iIN}C&Fr!N
E11ZdDc>n+a
diff --git a/tests/data/acpi/q35/DSDT.tis.tpm2
b/tests/data/acpi/q35/DSDT.tis.tpm2
index
c92d4d29c79352a60974ea9f665d0b9a410a4bac..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
100644
GIT binary patch
literal 0
HcmV?d1
literal 8894
zcmb7KO>7&-8J*>iv|28uB}GgAOH4RU+cZH!N%?Dwq$PLxXN%N|r0gVg!IkB-lAR)p
zBnFZg0b~V8TmvnVunu}DKnG0GTYKoaHQGxH^x%Vm1SopQp_c%?v?yZqVD)`79C?PM
zfS8BnezWh*H*a=lA2px6rq}wzamI`<3M+1
zIqlltm%ci7^amfGc_V-GxzB!d?V=R}U=iOYzL!Ee1eXKrSkQAm>TVhD5S?FJ=*@oA
z<(Ea9Ls!CpT5i~)iMm?oUu^F@>oxK&A7j$5`#CqafN{BvX6l%A^!<6pY?>VU{BC!5
z_mAR~Id3tiW(t)>v*H(9Ql$ZHq^iAL@mn=!Gj{84g2mcb9ExX87wcZuZ+M+-=IKte
zm1iNf1R*u8za3ak(6c}62CN$-c6a-%H~nFEo&93nW?%d_-e-MlMvN_GO}{rqW4U#g
z#TdhAzVSGXhUUAybGX{fclZ<|{V@#1uQpaAR$$rAshKCD5=f}_&XcDK9>C%rMKOAe
zN~Sqz9ViD
ztYq1EGx}!KG>>odo)_Jf+8!qkG-h)Q=T7ual$pmJ&Uv`ea`#4)7~DVJb;v?yn8%rc
zDXORL&C#~+Hd{vGrfr$HH59m*yR|G1Ubem6ES|(F_=|1f#w93l3%TM+Tqx9Q4I^<&
z&?s;V^|e~ouX-dEG;Tff*MByjdb{@F{Fk*ue|Bpj_4Ue6g5E>j3#@mjyJbbN
z0^Z@zk&V
[PATCH] configure: Symlink binaries using .exe suffix with MinGW
When using the MinGW toolchain, we use the .exe suffix for the executable name. We also need to use it for the symlinks in the build directory. Signed-off-by: Philippe Mathieu-Daudé --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 48c21775f3a..31e8f586dc7 100755 --- a/configure +++ b/configure @@ -3786,7 +3786,7 @@ fi for target in $target_list; do target_dir="$target" -target_name=$(echo $target | cut -d '-' -f 1) +target_name=$(echo $target | cut -d '-' -f 1)$EXESUF mkdir -p $target_dir case $target in *-user) symlink "../qemu-$target_name" "$target_dir/qemu-$target_name" ;; -- 2.31.1
[PATCH] pci-host: Allow extended config space access for PowerNV PHB4 model
The PCIe extended configuration space on the device is not currently accessible to the host. if by default, it is still inaccessible for conventional for PCIe buses, add the current flag PCI_BUS_EXTENDED_CONFIG_SPACE on the root bus permits PCI-E extended config space access. Signed-off-by: Christophe Lombard --- hw/pci-host/pnv_phb4.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c index 5c375a9f28..40b793201a 100644 --- a/hw/pci-host/pnv_phb4.c +++ b/hw/pci-host/pnv_phb4.c @@ -1205,6 +1205,7 @@ static void pnv_phb4_realize(DeviceState *dev, Error **errp) &phb->pci_mmio, &phb->pci_io, 0, 4, TYPE_PNV_PHB4_ROOT_BUS); pci_setup_iommu(pci->bus, pnv_phb4_dma_iommu, phb); +pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE; /* Add a single Root port */ qdev_prop_set_uint8(DEVICE(&phb->root), "chassis", phb->chip_id); -- 2.33.1
[PATCH] qapi: Belatedly mark unstable QMP parts with feature 'unstable'
The work in merge commit e86e00a2493 lacks special feature flag
'unstable', because it raced with it. Add it where it's missing.
Signed-off-by: Markus Armbruster
---
qapi/machine.json | 54 +++
1 file changed, 45 insertions(+), 9 deletions(-)
diff --git a/qapi/machine.json b/qapi/machine.json
index 17794ef681..067e3f5378 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -1417,107 +1417,143 @@
#
# Query interrupt statistics
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: interrupt statistics
#
# Since: 6.2
##
{ 'command': 'x-query-irq',
- 'returns': 'HumanReadableText' }
+ 'returns': 'HumanReadableText',
+ 'features': [ 'unstable' ] }
##
# @x-query-jit:
#
# Query TCG compiler statistics
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: TCG compiler statistics
#
# Since: 6.2
##
{ 'command': 'x-query-jit',
'returns': 'HumanReadableText',
- 'if': 'CONFIG_TCG' }
+ 'if': 'CONFIG_TCG',
+ 'features': [ 'unstable' ] }
##
# @x-query-numa:
#
# Query NUMA topology information
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: topology information
#
# Since: 6.2
##
{ 'command': 'x-query-numa',
- 'returns': 'HumanReadableText' }
+ 'returns': 'HumanReadableText',
+ 'features': [ 'unstable' ] }
##
# @x-query-opcount:
#
# Query TCG opcode counters
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: TCG opcode counters
#
# Since: 6.2
##
{ 'command': 'x-query-opcount',
'returns': 'HumanReadableText',
- 'if': 'CONFIG_TCG' }
+ 'if': 'CONFIG_TCG',
+ 'features': [ 'unstable' ] }
##
# @x-query-profile:
#
# Query TCG profiling information
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: profile information
#
# Since: 6.2
##
{ 'command': 'x-query-profile',
- 'returns': 'HumanReadableText' }
+ 'returns': 'HumanReadableText',
+ 'features': [ 'unstable' ] }
##
# @x-query-ramblock:
#
# Query system ramblock information
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: system ramblock information
#
# Since: 6.2
##
{ 'command': 'x-query-ramblock',
- 'returns': 'HumanReadableText' }
+ 'returns': 'HumanReadableText',
+ 'features': [ 'unstable' ] }
##
# @x-query-rdma:
#
# Query RDMA state
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: RDMA state
#
# Since: 6.2
##
{ 'command': 'x-query-rdma',
- 'returns': 'HumanReadableText' }
+ 'returns': 'HumanReadableText',
+ 'features': [ 'unstable' ] }
##
# @x-query-roms:
#
# Query information on the registered ROMS
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: registered ROMs
#
# Since: 6.2
##
{ 'command': 'x-query-roms',
- 'returns': 'HumanReadableText' }
+ 'returns': 'HumanReadableText',
+ 'features': [ 'unstable' ] }
##
# @x-query-usb:
#
# Query information on the USB devices
#
+# Features:
+# @unstable: This command is meant for debugging.
+#
# Returns: USB device information
#
# Since: 6.2
##
{ 'command': 'x-query-usb',
- 'returns': 'HumanReadableText' }
+ 'returns': 'HumanReadableText',
+ 'features': [ 'unstable' ] }
--
2.31.1
Re: [PATCH v2 3/3] tests: acpi: Add updated TPM related tables
On Tue, Nov 9, 2021 at 8:00 PM Daniel P. Berrangé wrote:
>
> On Tue, Nov 09, 2021 at 09:14:25AM -0500, Michael S. Tsirkin wrote:
> > On Tue, Nov 09, 2021 at 09:01:52AM -0500, Stefan Berger wrote:
> > > The updated TPM related tables have the following additions:
> > >
> > >Device (TPM)
> > >{
> > >Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */) // _HID:
> > > Hardware ID
> > > + Name (_STR, "TPM 2.0 Device") // _STR: Description String
> > > + Name (_UID, One) // _UID: Unique ID
> > >Name (_STA, 0x0F) // _STA: Status
> > >Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
> > >
> > > Cc: Michael S. Tsirkin
> > > Cc: Igor Mammedov
> > > Cc: Ani Sinha
> > > Signed-off-by: Stefan Berger
> > > ---
> > > tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 0 -> 8900 bytes
> > > tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 0 -> 8921 bytes
> > > tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 0 -> 50 bytes
> > > tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 0 -> 76 bytes
> > > tests/qtest/bios-tables-test-allowed-diff.h | 11 ---
> > > 5 files changed, 11 deletions(-)
> >
> > A disadvantage to doing it like this is that git thinks
> > it's ok to replace any empty file with this, so if acpi
> > changed in any way git will happily resolve it
> > replacing it with this version.
>
> Do we actually need to be storing these binary files in git
> at all ?
>
> IIUC, the test will do two things
>
> - memcmp the expected binary we store, against the new binary
>we generated.
> - if they differ, then disassemble both and report the
>differences in a user friendly-ish way
>
> What if we only stored the sha256 checksum of the binary *and*
> the dissasembled output in git, never the full binary.
If you are going down that path, why need the sha256 at all? The test
can disassemble the tables from qemu and only compare the disassembled
ASL.
>
> IIUC, that would give us the same level of diagnostic output
> from the test failures. The dissasembled output would then
> give us meaningful patches for reviewers to look at. The
> author wouldn't have to describe the difference in the
> commit message as Stefan has (helpfully) done here.
>
>
>
> 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 03/19] docs/devel: document expectations for QAPI data modelling for QMP
Daniel P. Berrangé writes: > On Tue, Nov 09, 2021 at 07:39:29AM +0100, Markus Armbruster wrote: >> Daniel P. Berrangé writes: >> >> > On Thu, Nov 04, 2021 at 06:43:23AM +0100, Markus Armbruster wrote: >> >> Daniel P. Berrangé writes: >> >> >> >> > On Thu, Oct 28, 2021 at 04:24:31PM +0100, Daniel P. Berrangé wrote: >> >> >> On Thu, Oct 28, 2021 at 04:31:40PM +0200, Markus Armbruster wrote: >> >> >> > This clashes with my "[PATCH v2 0/9] Configurable policy for handling >> >> >> > unstable interfaces", which replaces "you must give unstable stuff >> >> >> > names >> >> >> > starting with 'x-'" by "you must give unstable stuff feature flag >> >> >> > 'unstable' (and may give it a name starting with 'x-')". >> >> >> >> >> >> If your series goes in first, I'll update this to take account of it, >> >> >> but for now I'll leave it as is. >> >> > >> >> > This patch has now merged to git master. >> >> >> >> Merge commit e86e00a2493, Nov 3. >> >> >> >> > If you re-post your series feel free to update the new docs, or let >> >> > me know if you want me to do it afterwards. >> >> >> >> The latter, because my series went in before yours, in merge commit >> >> dd61b91c080, Oct 29 :) >> > >> > Sigh, I'm blind ! Dunno how i missed that. >> >> I can do it for you (it's such a simple patch), but I'd rather not do it >> in addition to you :) > > I've not started yet, so I'll let you do it since you probably have a > better idea of the preferred language to describe it. I'll promise my > review services in return. [PATCH] qapi: Belatedly mark unstable QMP parts with feature 'unstable'
Re: [PATCH] qapi: Belatedly mark unstable QMP parts with feature 'unstable'
On 11/9/21 15:55, Markus Armbruster wrote: The work in merge commit e86e00a2493 lacks special feature flag 'unstable', because it raced with it. Add it where it's missing. Signed-off-by: Markus Armbruster Reviewed-by: Damien Hedde
Re: [PATCH v2 3/3] tests: acpi: Add updated TPM related tables
On Tue, Nov 09, 2021 at 08:26:11PM +0530, Ani Sinha wrote:
> On Tue, Nov 9, 2021 at 8:00 PM Daniel P. Berrangé wrote:
> >
> > On Tue, Nov 09, 2021 at 09:14:25AM -0500, Michael S. Tsirkin wrote:
> > > On Tue, Nov 09, 2021 at 09:01:52AM -0500, Stefan Berger wrote:
> > > > The updated TPM related tables have the following additions:
> > > >
> > > >Device (TPM)
> > > >{
> > > >Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */) // _HID:
> > > > Hardware ID
> > > > + Name (_STR, "TPM 2.0 Device") // _STR: Description String
> > > > + Name (_UID, One) // _UID: Unique ID
> > > >Name (_STA, 0x0F) // _STA: Status
> > > >Name (_CRS, ResourceTemplate () // _CRS: Current Resource
> > > > Settings
> > > >
> > > > Cc: Michael S. Tsirkin
> > > > Cc: Igor Mammedov
> > > > Cc: Ani Sinha
> > > > Signed-off-by: Stefan Berger
> > > > ---
> > > > tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 0 -> 8900 bytes
> > > > tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 0 -> 8921 bytes
> > > > tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 0 -> 50 bytes
> > > > tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 0 -> 76 bytes
> > > > tests/qtest/bios-tables-test-allowed-diff.h | 11 ---
> > > > 5 files changed, 11 deletions(-)
> > >
> > > A disadvantage to doing it like this is that git thinks
> > > it's ok to replace any empty file with this, so if acpi
> > > changed in any way git will happily resolve it
> > > replacing it with this version.
> >
> > Do we actually need to be storing these binary files in git
> > at all ?
> >
> > IIUC, the test will do two things
> >
> > - memcmp the expected binary we store, against the new binary
> >we generated.
> > - if they differ, then disassemble both and report the
> >differences in a user friendly-ish way
> >
> > What if we only stored the sha256 checksum of the binary *and*
> > the dissasembled output in git, never the full binary.
>
> If you are going down that path, why need the sha256 at all? The test
> can disassemble the tables from qemu and only compare the disassembled
> ASL.
We don't currently mandate 'iasl' as a dependancy. Currently we
still run the tests, but without the pretty error message details.
If we didn't have the sha256, we would either need iasl to be
mandatory, or not run the test at all.
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: [PULL 0/2] M68k for 6.2 patches
On 11/9/21 12:15 PM, Laurent Vivier wrote: The following changes since commit 85549204552b624fe254831537e7a0f6450228b8: Merge remote-tracking branch 'remotes/juanquintela/tags/migration-20211109-pull-request' into staging (2021-11-09 09:41:31 +0100) are available in the Git repository at: git://github.com/vivier/qemu-m68k.git tags/m68k-for-6.2-pull-request for you to fetch changes up to 6ed25621f2890d8f1c3b9e6f7a0e91c841aea1f8: hw: m68k: virt: Add compat machine for 6.2 (2021-11-09 12:14:18 +0100) m68k pull request 20211109 Add virt machine types for 6.1 and 6.2 Laurent Vivier (2): hw: m68k: virt: Add compat machine for 6.1 hw: m68k: virt: Add compat machine for 6.2 hw/m68k/virt.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) Applied, thanks. r~
Re: [PATCH] qapi: Belatedly mark unstable QMP parts with feature 'unstable'
On Tue, Nov 09, 2021 at 03:55:59PM +0100, Markus Armbruster wrote: > The work in merge commit e86e00a2493 lacks special feature flag > 'unstable', because it raced with it. Add it where it's missing. > > Signed-off-by: Markus Armbruster > --- > qapi/machine.json | 54 +++ > 1 file changed, 45 insertions(+), 9 deletions(-) Reviewed-by: Daniel P. Berrangé 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: Poking around bdrv_is_inserted()
Kevin Wolf writes:
> Am 09.11.2021 um 07:44 hat Markus Armbruster geschrieben:
>> Screwed up qemu-devel@nongnu.org, sorry for the inconvenience.
>>
>> Markus Armbruster writes:
>>
>> > bdrv_is_inserted() returns false when:
>> >
>> > /**
>> > * Return TRUE if the media is present
>> > */
>> > bool bdrv_is_inserted(BlockDriverState *bs)
>> > {
>> > BlockDriver *drv = bs->drv;
>> > BdrvChild *child;
>> >
>> > if (!drv) {
>> > return false;
>> >
>> > 1. @bs has no driver (this is how we represent "no medium").
>
> Not really any more. "No medium" is blk->root == NULL.
Uh, blk_is_inserted() does *not* check blk->root:
bool blk_is_inserted(BlockBackend *blk)
{
BlockDriverState *bs = blk_bs(blk);
return bs && bdrv_is_inserted(bs);
}
Now I'm confused.
>These days
> bs->drv == NULL basically means "the backend is broken". This happens
> after qcow2_signal_corruption(), and I'm not sure if we have more
> circumstances like it.
I'm not sure having bdrv_is_inserted() return true for "broken" backends
makes sense.
>> > }
>> > if (drv->bdrv_is_inserted) {
>> > return drv->bdrv_is_inserted(bs);
>> >
>> > 2. Its driver's ->bdrv_is_inserted() returns false. This is how
>> > passthrough block backends signal "host device has no medium". Right
>> > now, the only user is "host_cdrom".
>> >
>> > }
>> > QLIST_FOREACH(child, &bs->children, next) {
>> > if (!bdrv_is_inserted(child->bs)) {
>> > return false;
>> >
>> > 3. Any of its children has no medium. Common use looking through
>> > filters, which have a single child.
>> >
>> > }
>> > }
>> > return true;
>> > }
>> >
>> > Makes sense.
>> >
>> > Now look at the uses of QERR_DEVICE_HAS_NO_MEDIUM.
>> >
>> > * external_snapshot_prepare() in blockdev.c:
>> >
>> > if (!bdrv_is_inserted(state->old_bs)) {
>> > error_setg(errp, QERR_DEVICE_HAS_NO_MEDIUM, device);
>> > goto out;
>> > }
>> >
>> > where @device is the device name, i.e. BlockdevSnapshot member @node
>> > or BlockdevSnapshotSync member @device. Uh-oh: the latter can be
>> > null. If we can reach the error_setg() then, we crash on some
>> > systems.
>
> Sounds like we should write a test case and then fix it.
>
>> > * bdrv_snapshot_delete() and bdrv_snapshot_load_tmp() in
>> > block/snaphot.c:
>> >
>> > if (!drv) {
>> > error_setg(errp, QERR_DEVICE_HAS_NO_MEDIUM,
>> > bdrv_get_device_name(bs));
>> > return -ENOMEDIUM;
>> > }
>> >
>> > where @drv is bs->drv.
>> >
>> > Why do we check only for 1. here instead of calling
>> > bdrv_is_inserted()?
>
> I guess we could philosophise about the theoretically right thing to do,
> but last time I checked, host_cdrom didn't support snapshots, so it
> probably doesn't matter either way.
We could also philosophize about "any of its children has no medium".
As far as I know, nothing stops me from using a host_cdrom as a backing
file for a QCOW2, and that I *can* snapshot.
Functions (and methods) bdrv_is_inserted(), bdrv_eject(), and
bdrv_lock_medium() are related. block_int.h groups them under
/* removable device specific */, and block.c under /* removable device
support */. But only bdrv_is_inserted() recurses into children. Is
this how it should be?
[PULL 0/1] Q800 for 6.2 patches
The following changes since commit 2b22e7540d6ab4efe82d442363e3fc900cea6584: Merge tag 'm68k-for-6.2-pull-request' of git://github.com/vivier/qemu-m68k into staging (2021-11-09 13:16:56 +0100) are available in the Git repository at: git://github.com/vivier/qemu-m68k.git tags/q800-for-6.2-pull-request for you to fetch changes up to 5db83c7e90ec6c0b28995b537bb03942edcd4164: macfb: fix a memory leak (CID 1465231) (2021-11-09 16:42:49 +0100) Fix CID 1465231 Laurent Vivier (1): macfb: fix a memory leak (CID 1465231) hw/display/macfb.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) -- 2.31.1
[PULL 1/1] macfb: fix a memory leak (CID 1465231)
Rewrite the function using g_string_append_printf() rather than
g_strdup_printf()/g_strconcat().
Fixes: df8abbbadf74 ("macfb: add common monitor modes supported by the MacOS
toolbox ROM")
Cc: mark.cave-ayl...@ilande.co.uk
Reported-by: Peter Maydell
Suggested-by: Peter Maydell
Signed-off-by: Laurent Vivier
Reviewed-by: Peter Maydell
Reviewed-by: Mark Cave-Ayland
Message-Id: <20211105165254.3544369-1-laur...@vivier.eu>
Signed-off-by: Laurent Vivier
---
hw/display/macfb.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/hw/display/macfb.c b/hw/display/macfb.c
index 4b352eb89c3f..277d3e663331 100644
--- a/hw/display/macfb.c
+++ b/hw/display/macfb.c
@@ -440,21 +440,18 @@ static MacFbMode *macfb_find_mode(MacfbDisplayType
display_type,
static gchar *macfb_mode_list(void)
{
-gchar *list = NULL;
-gchar *mode;
+GString *list = g_string_new("");
MacFbMode *macfb_mode;
int i;
for (i = 0; i < ARRAY_SIZE(macfb_mode_table); i++) {
macfb_mode = &macfb_mode_table[i];
-mode = g_strdup_printf("%dx%dx%d\n", macfb_mode->width,
+g_string_append_printf(list, "%dx%dx%d\n", macfb_mode->width,
macfb_mode->height, macfb_mode->depth);
-list = g_strconcat(mode, list, NULL);
-g_free(mode);
}
-return list;
+return g_string_free(list, FALSE);
}
@@ -643,7 +640,7 @@ static bool macfb_common_realize(DeviceState *dev,
MacfbState *s, Error **errp)
gchar *list;
error_setg(errp, "unknown display mode: width %d, height %d, depth %d",
s->width, s->height, s->depth);
-list = macfb_mode_list();
+list = macfb_mode_list();
error_append_hint(errp, "Available modes:\n%s", list);
g_free(list);
--
2.31.1
Re: [PATCH] pci-host: Allow extended config space access for PowerNV PHB4 model
On 09/11/2021 15:50, Christophe Lombard wrote: The PCIe extended configuration space on the device is not currently accessible to the host. if by default, it is still inaccessible for conventional for PCIe buses, add the current flag PCI_BUS_EXTENDED_CONFIG_SPACE on the root bus permits PCI-E extended config space access. Signed-off-by: Christophe Lombard --- FWIW, looks good to me Reviewed-by: Frederic Barrat hw/pci-host/pnv_phb4.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c index 5c375a9f28..40b793201a 100644 --- a/hw/pci-host/pnv_phb4.c +++ b/hw/pci-host/pnv_phb4.c @@ -1205,6 +1205,7 @@ static void pnv_phb4_realize(DeviceState *dev, Error **errp) &phb->pci_mmio, &phb->pci_io, 0, 4, TYPE_PNV_PHB4_ROOT_BUS); pci_setup_iommu(pci->bus, pnv_phb4_dma_iommu, phb); +pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE; /* Add a single Root port */ qdev_prop_set_uint8(DEVICE(&phb->root), "chassis", phb->chip_id);
Re: [PATCH v2] s390x: kvm: adjust diag318 resets to retain data
On 11/9/21 05:48, Janosch Frank wrote:
> On 11/9/21 08:32, Christian Borntraeger wrote:
>>
>>
>> Am 08.11.21 um 22:13 schrieb Collin Walling:
>>> The CPNC portion of the diag 318 data is erroneously reset during an
>>> initial CPU reset caused by SIGP. Let's go ahead and relocate the
>>> diag318_info field within the CPUS390XState struct such that it is
>>> only zeroed during a clear reset. This way, the CPNC will be retained
>>> for each VCPU in the configuration after the diag 318 instruction
>>> has been invoked.
>>>
>>> Additionally, the diag 318 data reset is handled via the CPU reset
>>> code during a clear reset. This means some of the diag 318-specific
>>> reset code can now be removed.
>>>
>>> Signed-off-by: Collin Walling
>>> Fixes: fabdada9357b ("s390: guest support for diagnose 0x318")
>>> Reported-by: Christian Borntraeger
>>
>> It would be good to add at least a comment in the diag308 handlers
>> where the value of cpnc is resetted during the resets that Janosch
>> mentioned.
>>>
>>> ---
>>>
>>> Changelog:
>>>
>>> v2
>>> - handler uses run_on_cpu again
>>> - reworded commit message slightly
>>> - added fixes and reported-by tags
>>>
>>> ---
>>> hw/s390x/s390-virtio-ccw.c | 3 ---
>>> target/s390x/cpu-sysemu.c | 7 ---
>>> target/s390x/cpu.h | 5 ++---
>>> target/s390x/kvm/kvm.c | 14 +-
>>> target/s390x/kvm/kvm_s390x.h | 1 -
>>> 5 files changed, 7 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>> index 653587ea62..51dcb83b0c 100644
>>> --- a/hw/s390x/s390-virtio-ccw.c
>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>> @@ -489,9 +489,6 @@ static void s390_machine_reset(MachineState
>>> *machine)
>>> g_assert_not_reached();
>>> }
>>> - CPU_FOREACH(t) {
>>> - run_on_cpu(t, s390_do_cpu_set_diag318,
>>> RUN_ON_CPU_HOST_ULONG(0));
>>> - }
>
> This needs to stay for the move to the clear reset area to work on other
> diag308 subcodes. The reset will then be done twice for the clear reset
> but that's fine.
>
> Moving the diag318 data into the clear area means we only reset it on a
> full cpu reset which is only done for diagnose 308 subcode 0 and maybe a
> QEMU reset, I didn't fully follow the code there.
>
> The other subcodes do an initial reset on the calling cpu and normal
> resets on the others or just normal resets which don't touch the 318
> data if we move it into the clear reset area.
>> Or did I miss something fundamental here?
>
>
While the diag318 data will not be cleared during an initial and load
normal resets _directly_, the s390_machine_reset function ends with the
call below:
>>> s390_ipl_clear_reset_request();
>>> }
The clear reset request is invoked after each of the reset types at the
tail end of the function. Because of this, the diag318 data will be
reset during the 308 subcodes by way of the clear reset at the end.
>>> diff --git a/target/s390x/cpu-sysemu.c b/target/s390x/cpu-sysemu.c
>>> index 5471e01ee8..6d9f6d4402 100644
>>> --- a/target/s390x/cpu-sysemu.c
>>> +++ b/target/s390x/cpu-sysemu.c
>>> @@ -299,10 +299,3 @@ void s390_enable_css_support(S390CPU *cpu)
>>> kvm_s390_enable_css_support(cpu);
>>> }
>>> }
>>> -
>>> -void s390_do_cpu_set_diag318(CPUState *cs, run_on_cpu_data arg)
>>> -{
>>> - if (kvm_enabled()) {
>>> - kvm_s390_set_diag318(cs, arg.host_ulong);
>>> - }
>>> -}
>>> diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
>>> index 3153d053e9..1b94b91d87 100644
>>> --- a/target/s390x/cpu.h
>>> +++ b/target/s390x/cpu.h
>>> @@ -63,6 +63,8 @@ struct CPUS390XState {
>>> uint64_t etoken; /* etoken */
>>> uint64_t etoken_extension; /* etoken extension */
>>> + uint64_t diag318_info;
>>> +
>>> /* Fields up to this point are not cleared by initial CPU
>>> reset */
>>> struct {} start_initial_reset_fields;
>>> @@ -118,8 +120,6 @@ struct CPUS390XState {
>>> uint16_t external_call_addr;
>>> DECLARE_BITMAP(emergency_signals, S390_MAX_CPUS);
>>> - uint64_t diag318_info;
>>> -
>>> #if !defined(CONFIG_USER_ONLY)
>>> uint64_t tlb_fill_tec; /* translation exception code during
>>> tlb_fill */
>>> int tlb_fill_exc; /* exception number seen during
>>> tlb_fill */
>>> @@ -780,7 +780,6 @@ int s390_set_memory_limit(uint64_t new_limit,
>>> uint64_t *hw_limit);
>>> void s390_set_max_pagesize(uint64_t pagesize, Error **errp);
>>> void s390_cmma_reset(void);
>>> void s390_enable_css_support(S390CPU *cpu);
>>> -void s390_do_cpu_set_diag318(CPUState *cs, run_on_cpu_data arg);
>>> int s390_assign_subch_ioeventfd(EventNotifier *notifier, uint32_t
>>> sch_id,
>>> int vq, bool assign);
>>> #ifndef CONFIG_USER_ONLY
>>> diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
>>> index 5b1fdb55c4..8970d9ca55 100644
>>> --- a/target/s390x/kvm/kvm.c
Re: [PATCH] pci-host: Allow extended config space access for PowerNV PHB4 model
On 11/9/21 16:51, Frederic Barrat wrote: On 09/11/2021 15:50, Christophe Lombard wrote: The PCIe extended configuration space on the device is not currently accessible to the host. if by default, it is still inaccessible for conventional for PCIe buses, add the current flag PCI_BUS_EXTENDED_CONFIG_SPACE on the root bus permits PCI-E extended config space access. For the record, this is coming from an experiment of plugging a CXL device on a QEMU PowerNV POWER10 machine (baremetal). Only minor changes (64 bits ops) were required to get it working. I wonder where are with the CXL models ? Signed-off-by: Christophe Lombard --- FWIW, looks good to me Reviewed-by: Frederic Barrat Reviewed-by: Cédric Le Goater Thanks, C. hw/pci-host/pnv_phb4.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pci-host/pnv_phb4.c b/hw/pci-host/pnv_phb4.c index 5c375a9f28..40b793201a 100644 --- a/hw/pci-host/pnv_phb4.c +++ b/hw/pci-host/pnv_phb4.c @@ -1205,6 +1205,7 @@ static void pnv_phb4_realize(DeviceState *dev, Error **errp) &phb->pci_mmio, &phb->pci_io, 0, 4, TYPE_PNV_PHB4_ROOT_BUS); pci_setup_iommu(pci->bus, pnv_phb4_dma_iommu, phb); + pci->bus->flags |= PCI_BUS_EXTENDED_CONFIG_SPACE; /* Add a single Root port */ qdev_prop_set_uint8(DEVICE(&phb->root), "chassis", phb->chip_id);
Re: [PATCH v2 3/3] tests: acpi: Add updated TPM related tables
On Tue, Nov 09, 2021 at 02:29:26PM +, Daniel P. Berrangé wrote:
> On Tue, Nov 09, 2021 at 09:14:25AM -0500, Michael S. Tsirkin wrote:
> > On Tue, Nov 09, 2021 at 09:01:52AM -0500, Stefan Berger wrote:
> > > The updated TPM related tables have the following additions:
> > >
> > >Device (TPM)
> > >{
> > >Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */) // _HID:
> > > Hardware ID
> > > + Name (_STR, "TPM 2.0 Device") // _STR: Description String
> > > + Name (_UID, One) // _UID: Unique ID
> > >Name (_STA, 0x0F) // _STA: Status
> > >Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
> > >
> > > Cc: Michael S. Tsirkin
> > > Cc: Igor Mammedov
> > > Cc: Ani Sinha
> > > Signed-off-by: Stefan Berger
> > > ---
> > > tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 0 -> 8900 bytes
> > > tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 0 -> 8921 bytes
> > > tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 0 -> 50 bytes
> > > tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 0 -> 76 bytes
> > > tests/qtest/bios-tables-test-allowed-diff.h | 11 ---
> > > 5 files changed, 11 deletions(-)
> >
> > A disadvantage to doing it like this is that git thinks
> > it's ok to replace any empty file with this, so if acpi
> > changed in any way git will happily resolve it
> > replacing it with this version.
>
> Do we actually need to be storing these binary files in git
> at all ?
>
> IIUC, the test will do two things
>
> - memcmp the expected binary we store, against the new binary
>we generated.
> - if they differ, then disassemble both and report the
>differences in a user friendly-ish way
Second if iasl is installed.
> What if we only stored the sha256 checksum of the binary
Hmm, point being? Same some space?
> *and*
> the dissasembled output in git, never the full binary.
We used to. The issue is that dissasembled output depends
very much on the disassembler. Disassembling both
with the same tool is one way to address this.
> IIUC, that would give us the same level of diagnostic output
> from the test failures. The dissasembled output would then
> give us meaningful patches for reviewers to look at. The
> author wouldn't have to describe the difference in the
> commit message as Stefan has (helpfully) done here.
>
>
>
> 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] qapi: Belatedly mark unstable QMP parts with feature 'unstable'
On 11/9/21 15:55, Markus Armbruster wrote: > The work in merge commit e86e00a2493 lacks special feature flag > 'unstable', because it raced with it. Add it where it's missing. > > Signed-off-by: Markus Armbruster > --- > qapi/machine.json | 54 +++ > 1 file changed, 45 insertions(+), 9 deletions(-) Reviewed-by: Philippe Mathieu-Daudé
Re: [PATCH v2 3/3] tests: acpi: Add updated TPM related tables
On Tue, Nov 09, 2021 at 08:26:11PM +0530, Ani Sinha wrote:
> On Tue, Nov 9, 2021 at 8:00 PM Daniel P. Berrangé wrote:
> >
> > On Tue, Nov 09, 2021 at 09:14:25AM -0500, Michael S. Tsirkin wrote:
> > > On Tue, Nov 09, 2021 at 09:01:52AM -0500, Stefan Berger wrote:
> > > > The updated TPM related tables have the following additions:
> > > >
> > > >Device (TPM)
> > > >{
> > > >Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */) // _HID:
> > > > Hardware ID
> > > > + Name (_STR, "TPM 2.0 Device") // _STR: Description String
> > > > + Name (_UID, One) // _UID: Unique ID
> > > >Name (_STA, 0x0F) // _STA: Status
> > > >Name (_CRS, ResourceTemplate () // _CRS: Current Resource
> > > > Settings
> > > >
> > > > Cc: Michael S. Tsirkin
> > > > Cc: Igor Mammedov
> > > > Cc: Ani Sinha
> > > > Signed-off-by: Stefan Berger
> > > > ---
> > > > tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 0 -> 8900 bytes
> > > > tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 0 -> 8921 bytes
> > > > tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 0 -> 50 bytes
> > > > tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 0 -> 76 bytes
> > > > tests/qtest/bios-tables-test-allowed-diff.h | 11 ---
> > > > 5 files changed, 11 deletions(-)
> > >
> > > A disadvantage to doing it like this is that git thinks
> > > it's ok to replace any empty file with this, so if acpi
> > > changed in any way git will happily resolve it
> > > replacing it with this version.
> >
> > Do we actually need to be storing these binary files in git
> > at all ?
> >
> > IIUC, the test will do two things
> >
> > - memcmp the expected binary we store, against the new binary
> >we generated.
> > - if they differ, then disassemble both and report the
> >differences in a user friendly-ish way
> >
> > What if we only stored the sha256 checksum of the binary *and*
> > the dissasembled output in git, never the full binary.
>
> If you are going down that path, why need the sha256 at all? The test
> can disassemble the tables from qemu and only compare the disassembled
> ASL.
The output isn't stable unfortunately, so it can't replace the binary..
However, the process of documenting what changed is quite fiddly, so I
am open to including both the binary and the dis-assembled file.
An issue is that iasl does not support all platforms that qemu
supports, in particular the disassembler is broken on BE platforms.
Not sure how big a deal that is ...
> >
> > IIUC, that would give us the same level of diagnostic output
> > from the test failures. The dissasembled output would then
> > give us meaningful patches for reviewers to look at. The
> > author wouldn't have to describe the difference in the
> > commit message as Stefan has (helpfully) done here.
> >
> >
> >
> > 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 v2 3/3] tests: acpi: Add updated TPM related tables
On Tue, Nov 09, 2021 at 11:05:28AM -0500, Michael S. Tsirkin wrote:
> On Tue, Nov 09, 2021 at 02:29:26PM +, Daniel P. Berrangé wrote:
> > On Tue, Nov 09, 2021 at 09:14:25AM -0500, Michael S. Tsirkin wrote:
> > > On Tue, Nov 09, 2021 at 09:01:52AM -0500, Stefan Berger wrote:
> > > > The updated TPM related tables have the following additions:
> > > >
> > > >Device (TPM)
> > > >{
> > > >Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */) // _HID:
> > > > Hardware ID
> > > > + Name (_STR, "TPM 2.0 Device") // _STR: Description String
> > > > + Name (_UID, One) // _UID: Unique ID
> > > >Name (_STA, 0x0F) // _STA: Status
> > > >Name (_CRS, ResourceTemplate () // _CRS: Current Resource
> > > > Settings
> > > >
> > > > Cc: Michael S. Tsirkin
> > > > Cc: Igor Mammedov
> > > > Cc: Ani Sinha
> > > > Signed-off-by: Stefan Berger
> > > > ---
> > > > tests/data/acpi/q35/DSDT.tis.tpm12 | Bin 0 -> 8900 bytes
> > > > tests/data/acpi/q35/DSDT.tis.tpm2 | Bin 0 -> 8921 bytes
> > > > tests/data/acpi/q35/TCPA.tis.tpm12 | Bin 0 -> 50 bytes
> > > > tests/data/acpi/q35/TPM2.tis.tpm2 | Bin 0 -> 76 bytes
> > > > tests/qtest/bios-tables-test-allowed-diff.h | 11 ---
> > > > 5 files changed, 11 deletions(-)
> > >
> > > A disadvantage to doing it like this is that git thinks
> > > it's ok to replace any empty file with this, so if acpi
> > > changed in any way git will happily resolve it
> > > replacing it with this version.
> >
> > Do we actually need to be storing these binary files in git
> > at all ?
> >
> > IIUC, the test will do two things
> >
> > - memcmp the expected binary we store, against the new binary
> >we generated.
> > - if they differ, then disassemble both and report the
> >differences in a user friendly-ish way
>
> Second if iasl is installed.
>
> > What if we only stored the sha256 checksum of the binary
>
> Hmm, point being? Same some space?
>
> > *and*
> > the dissasembled output in git, never the full binary.
>
> We used to. The issue is that dissasembled output depends
> very much on the disassembler. Disassembling both
> with the same tool is one way to address this.
Oh, so new isal releases can change the format, that's
annoying :-(
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 1/2] target/ppc: Fixed call to deferred exception
On 10/20/21 09:57, Lucas Mateus Castro (alqotel) wrote:
From: "Lucas Mateus Castro (alqotel)"
mtfsf, mtfsfi and mtfsb1 instructions call helper_float_check_status
after updating the value of FPSCR, but helper_float_check_status
checks fp_status and fp_status isn't updated based on FPSCR and
since the value of fp_status is reset earlier in the instruction,
it's always 0.
Because of this helper_float_check_status would change the FI bit to 0
as this bit checks if the last operation was inexact and
float_flag_inexact is always 0.
These instructions also don't throw exceptions correctly since
helper_float_check_status throw exceptions based on fp_status.
This commit created a new helper, helper_fpscr_check_status that checks
FPSCR value instead of fp_status and checks for a larger variety of
exceptions than do_float_check_status.
The hardware used to compare QEMU's behavior to, was a Power9.
Extra comma before "was a Power9".
Aside from that, LGTM.
Thanks,
Daniel
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/266
Signed-off-by: Lucas Mateus Castro (alqotel)
---
target/ppc/fpu_helper.c| 41 ++
target/ppc/helper.h| 1 +
target/ppc/translate/fp-impl.c.inc | 6 ++---
3 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index c4896cecc8..f086cb503f 100644
--- a/target/ppc/fpu_helper.c
+++ b/target/ppc/fpu_helper.c
@@ -414,6 +414,47 @@ void helper_store_fpscr(CPUPPCState *env, uint64_t val,
uint32_t nibbles)
ppc_store_fpscr(env, val);
}
+void helper_fpscr_check_status(CPUPPCState *env)
+{
+CPUState *cs = env_cpu(env);
+target_ulong fpscr = env->fpscr;
+int error = 0;
+
+if ((fpscr & FP_VXSOFT) && (fpscr_ve != 0)) {
+error = POWERPC_EXCP_FP_VXSOFT;
+} else if ((fpscr & FP_OX) && (fpscr & FP_OE)) {
+error = POWERPC_EXCP_FP_OX;
+} else if ((fpscr & FP_UX) && (fpscr & FP_UE)) {
+error = POWERPC_EXCP_FP_UX;
+} else if ((fpscr & FP_XX) && (fpscr & FP_XE)) {
+error = POWERPC_EXCP_FP_XX;
+} else if ((fpscr & FP_ZX) && (fpscr & FP_ZE)) {
+error = POWERPC_EXCP_FP_ZX;
+} else if ((fpscr & FP_VXSNAN) && (fpscr_ve != 0)) {
+error = POWERPC_EXCP_FP_VXSNAN;
+} else if ((fpscr & FP_VXISI) && (fpscr_ve != 0)) {
+error = POWERPC_EXCP_FP_VXISI;
+} else if ((fpscr & FP_VXIDI) && (fpscr_ve != 0)) {
+error = POWERPC_EXCP_FP_VXIDI;
+} else if ((fpscr & FP_VXZDZ) && (fpscr_ve != 0)) {
+error = POWERPC_EXCP_FP_VXZDZ;
+} else if ((fpscr & FP_VXIMZ) && (fpscr_ve != 0)) {
+error = POWERPC_EXCP_FP_VXIMZ;
+} else if ((fpscr & FP_VXVC) && (fpscr_ve != 0)) {
+error = POWERPC_EXCP_FP_VXVC;
+}
+
+if (error) {
+cs->exception_index = POWERPC_EXCP_PROGRAM;
+env->error_code = error | POWERPC_EXCP_FP;
+/* Deferred floating-point exception after target FPSCR update */
+if (fp_exceptions_enabled(env)) {
+raise_exception_err_ra(env, cs->exception_index,
+ env->error_code, GETPC());
+}
+}
+}
+
static void do_float_check_status(CPUPPCState *env, uintptr_t raddr)
{
CPUState *cs = env_cpu(env);
diff --git a/target/ppc/helper.h b/target/ppc/helper.h
index 4076aa281e..baa3715e73 100644
--- a/target/ppc/helper.h
+++ b/target/ppc/helper.h
@@ -61,6 +61,7 @@ DEF_HELPER_FLAGS_1(cntlzw32, TCG_CALL_NO_RWG_SE, i32, i32)
DEF_HELPER_FLAGS_2(brinc, TCG_CALL_NO_RWG_SE, tl, tl, tl)
DEF_HELPER_1(float_check_status, void, env)
+DEF_HELPER_1(fpscr_check_status, void, env)
DEF_HELPER_1(reset_fpstatus, void, env)
DEF_HELPER_2(compute_fprf_float64, void, env, i64)
DEF_HELPER_3(store_fpscr, void, env, i64, i32)
diff --git a/target/ppc/translate/fp-impl.c.inc
b/target/ppc/translate/fp-impl.c.inc
index 9f7868ee28..0a9b1ecc60 100644
--- a/target/ppc/translate/fp-impl.c.inc
+++ b/target/ppc/translate/fp-impl.c.inc
@@ -782,7 +782,7 @@ static void gen_mtfsb1(DisasContext *ctx)
tcg_gen_shri_i32(cpu_crf[1], cpu_crf[1], FPSCR_OX);
}
/* We can raise a deferred exception */
-gen_helper_float_check_status(cpu_env);
+gen_helper_fpscr_check_status(cpu_env);
}
/* mtfsf */
@@ -818,7 +818,7 @@ static void gen_mtfsf(DisasContext *ctx)
tcg_gen_shri_i32(cpu_crf[1], cpu_crf[1], FPSCR_OX);
}
/* We can raise a deferred exception */
-gen_helper_float_check_status(cpu_env);
+gen_helper_fpscr_check_status(cpu_env);
tcg_temp_free_i64(t1);
}
@@ -851,7 +851,7 @@ static void gen_mtfsfi(DisasContext *ctx)
tcg_gen_shri_i32(cpu_crf[1], cpu_crf[1], FPSCR_OX);
}
/* We can raise a deferred exception */
-gen_helper_float_check_status(cpu_env);
+gen_helper_fpscr_check_status(cpu_env);
}
/*** Floating-point load ***/
Re: [PATCH] linux-user: Replace __u64 with uint64_t
> On Nov 8, 2021, at 12:42 PM, Khem Raj wrote:
>
> uint64_t is available in all userspaces via compiler include stdint.h
> therefore use it instead of __u64 which is linux internal type, it fixes
> build on some platforms eg. aarch64 systems using musl C library
>
> Signed-off-by: Khem Raj
> ---
> linux-user/host/aarch64/hostdep.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/linux-user/host/aarch64/hostdep.h
> b/linux-user/host/aarch64/hostdep.h
> index a8d41a21ad..34d934f665 100644
> --- a/linux-user/host/aarch64/hostdep.h
> +++ b/linux-user/host/aarch64/hostdep.h
> @@ -25,7 +25,7 @@ extern char safe_syscall_end[];
> static inline void rewind_if_in_safe_syscall(void *puc)
> {
> ucontext_t *uc = puc;
> -__u64 *pcreg = &uc->uc_mcontext.pc;
> +uint64_t *pcreg = &uc->uc_mcontext.pc;
>
> if (*pcreg > (uintptr_t)safe_syscall_start
> && *pcreg < (uintptr_t)safe_syscall_end) {
Reviewed-by: Warner Losh
I wonder why we don’t have a typedef like bed’s register_t though…
Re: [PATCH 2/4] linux-user: Always use flexible arrays for dirent d_name
> On Nov 7, 2021, at 5:48 AM, Richard Henderson
> wrote:
>
> We currently use a flexible array member for target_dirent,
> but use incorrectly fixed length arrays for target_dirent64,
> linux_dirent and linux_dirent64.
>
> This requires that we adjust the definition of the VFAT READDIR
> ioctls which hard-code the 256 namelen size into the ioctl constant.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/syscall_defs.h | 6 +++---
> linux-user/syscall.c | 6 --
> 2 files changed, 7 insertions(+), 5 deletions(-)
Reviewed by: Warner Losh
> diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
> index a5ce487dcc..98b09ee6d6 100644
> --- a/linux-user/syscall_defs.h
> +++ b/linux-user/syscall_defs.h
> @@ -441,7 +441,7 @@ struct target_dirent64 {
> int64_t d_off;
> unsigned short d_reclen;
> unsigned char d_type;
> - chard_name[256];
> + chard_name[];
> };
>
>
> @@ -2714,7 +2714,7 @@ struct linux_dirent {
> longd_ino;
> unsigned long d_off;
> unsigned short d_reclen;
> -chard_name[256]; /* We must not include limits.h! */
> +chard_name[];
> };
>
> struct linux_dirent64 {
> @@ -2722,7 +2722,7 @@ struct linux_dirent64 {
> int64_t d_off;
> unsigned short d_reclen;
> unsigned char d_type;
> -chard_name[256];
> +chard_name[];
> };
>
> struct target_mq_attr {
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index a2f605dec4..499415ad81 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -197,8 +197,10 @@
> //#define DEBUG_ERESTARTSYS
>
> //#include
> -#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct
> linux_dirent [2])
> -#define VFAT_IOCTL_READDIR_SHORT_IOR('r', 2, struct
> linux_dirent [2])
> +#define VFAT_IOCTL_READDIR_BOTH \
> +_IOC(_IOC_READ, 'r', 1, (sizeof(struct linux_dirent) + 256) * 2)
> +#define VFAT_IOCTL_READDIR_SHORT \
> +_IOC(_IOC_READ, 'r', 2, (sizeof(struct linux_dirent) + 256) * 2)
>
> #undef _syscall0
> #undef _syscall1
> --
> 2.25.1
>
>
Re: [PATCH 2/2] target/ppc: ppc_store_fpscr doesn't update bit 52
On 10/20/21 09:57, Lucas Mateus Castro (alqotel) wrote:
From: "Lucas Mateus Castro (alqotel)"
This commit fixes the difference reported in the bug in the reserved
bit 52, it does this by adding this bit to the mask of bits to not be
directly altered in the ppc_store_fpscr function (the hardware used to
compare to QEMU was a Power9).
IIUC, "bug" here is related to
https://gitlab.com/qemu-project/qemu/-/issues/266,
the bug mentioned in the commit msg of the first patch. In that case, you
should mention it again in this commit message explicitly.
In fact, I also believe that the "Resolves:" tag from the first patch should
be moved to this patch instead, given that the bug is only fully fixed after
both patches are applied.
Although this is a difference reported in the bug, since it's a reserved
bit it may be a "don't care" case, as put in the bug report. Looking at
the ISA it doesn't explicitly mentions this bit can't be set, like it
does for FEX and VX, so I'm unsure if this is necessary.
Signed-off-by: Lucas Mateus Castro (alqotel)
---
target/ppc/cpu.c | 2 +-
target/ppc/cpu.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/ppc/cpu.c b/target/ppc/cpu.c
index 7ad9bd6044..5c411b32ff 100644
--- a/target/ppc/cpu.c
+++ b/target/ppc/cpu.c
@@ -112,7 +112,7 @@ static inline void fpscr_set_rounding_mode(CPUPPCState *env)
void ppc_store_fpscr(CPUPPCState *env, target_ulong val)
{
-val &= ~(FP_VX | FP_FEX);
+val &= FPSCR_MTFS_MASK;
if (val & FPSCR_IX) {
val |= FP_VX;
}
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index baa4e7c34d..4b42b281ed 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -736,6 +736,9 @@ enum {
FP_VXZDZ | FP_VXIMZ | FP_VXVC | FP_VXSOFT | \
FP_VXSQRT | FP_VXCVI)
+/* FPSCR bits that can be set by mtfsf, mtfsfi and mtfsb1 */
+#define FPSCR_MTFS_MASK ~((1ull << 11) | FP_VX | FP_FEX)
./scripts/checkpatch.pl is not happy about this line:
ERROR: Macros with complex values should be enclosed in parenthesis
#44: FILE: target/ppc/cpu.h:763:
+#define FPSCR_MTFS_MASK ~((1ull << 11) | FP_VX | FP_FEX)
total: 1 errors, 0 warnings, 17 lines checked
Thanks,
Daniel
+
/*/
/* Vector status and control register */
#define VSCR_NJ 16 /* Vector non-java */
Re: [PATCH 3/4] linux-user: Fix member types of target_dirent64
> On Nov 7, 2021, at 5:48 AM, Richard Henderson
> wrote:
>
> The host uint64_t (etc) does not have the correct
> alignment constraint as the guest: use abi_* types.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/syscall_defs.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed by: Warner Losh
> diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
> index 98b09ee6d6..41aaafbac1 100644
> --- a/linux-user/syscall_defs.h
> +++ b/linux-user/syscall_defs.h
> @@ -437,9 +437,9 @@ struct target_dirent {
> };
>
> struct target_dirent64 {
> - uint64_td_ino;
> - int64_t d_off;
> - unsigned short d_reclen;
> + abi_ullong d_ino;
> + abi_llong d_off;
> + abi_ushort d_reclen;
> unsigned char d_type;
> chard_name[];
> };
> --
> 2.25.1
>
>
Re: [PATCH 0/4] linux-user: Fix getdents alignment issues (#704)
> On Nov 7, 2021, at 5:48 AM, Richard Henderson > wrote: > > There are a number of alignement issues flagged up by clang, > this attempts to fix only one of them: getdents. Does it make sense to have size asserts for these types? That would catch the alignment issues and are cheap to maintain since ABI sizes should never change… Warner > r~ > > Richard Henderson (4): > linux-user: Split out do_getdents, do_getdents64 > linux-user: Always use flexible arrays for dirent d_name > linux-user: Fix member types of target_dirent64 > linux-user: Rewrite do_getdents, do_getdents64 > > linux-user/syscall_defs.h | 12 +- > linux-user/syscall.c | 290 ++ > 2 files changed, 141 insertions(+), 161 deletions(-) > > -- > 2.25.1 > >
Re: [PATCH 1/4] linux-user: Split out do_getdents, do_getdents64
> On Nov 7, 2021, at 5:48 AM, Richard Henderson
> wrote:
>
> Retain all 3 implementations of getdents for now.
>
> Signed-off-by: Richard Henderson
> ---
> linux-user/syscall.c | 325 +++
> 1 file changed, 172 insertions(+), 153 deletions(-)
Reviewed by: Warner Losh
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 544f5b662f..a2f605dec4 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -8137,6 +8137,176 @@ static int host_to_target_cpu_mask(const unsigned
> long *host_mask,
> return 0;
> }
>
> +#ifdef TARGET_NR_getdents
> +static int do_getdents(abi_long arg1, abi_long arg2, abi_long arg3)
> +{
> +int ret;
> +
> +#ifdef EMULATE_GETDENTS_WITH_GETDENTS
> +# if TARGET_ABI_BITS == 32 && HOST_LONG_BITS == 64
> +struct target_dirent *target_dirp;
> +struct linux_dirent *dirp;
> +abi_long count = arg3;
> +
> +dirp = g_try_malloc(count);
> +if (!dirp) {
> +return -TARGET_ENOMEM;
> +}
> +
> +ret = get_errno(sys_getdents(arg1, dirp, count));
> +if (!is_error(ret)) {
> +struct linux_dirent *de;
> +struct target_dirent *tde;
> +int len = ret;
> +int reclen, treclen;
> +int count1, tnamelen;
> +
> +count1 = 0;
> +de = dirp;
> +target_dirp = lock_user(VERIFY_WRITE, arg2, count, 0);
> +if (!target_dirp) {
> +return -TARGET_EFAULT;
> +}
> +tde = target_dirp;
> +while (len > 0) {
> +reclen = de->d_reclen;
> +tnamelen = reclen - offsetof(struct linux_dirent, d_name);
> +assert(tnamelen >= 0);
> +treclen = tnamelen + offsetof(struct target_dirent, d_name);
> +assert(count1 + treclen <= count);
> +tde->d_reclen = tswap16(treclen);
> +tde->d_ino = tswapal(de->d_ino);
> +tde->d_off = tswapal(de->d_off);
> +memcpy(tde->d_name, de->d_name, tnamelen);
> +de = (struct linux_dirent *)((char *)de + reclen);
> +len -= reclen;
> +tde = (struct target_dirent *)((char *)tde + treclen);
> +count1 += treclen;
> +}
> +ret = count1;
> +unlock_user(target_dirp, arg2, ret);
> +}
> +g_free(dirp);
> +# else
> +struct linux_dirent *dirp;
> +abi_long count = arg3;
> +
> +dirp = lock_user(VERIFY_WRITE, arg2, count, 0);
> +if (!dirp) {
> +return -TARGET_EFAULT;
> +}
> +ret = get_errno(sys_getdents(arg1, dirp, count));
> +if (!is_error(ret)) {
> +struct linux_dirent *de;
> +int len = ret;
> +int reclen;
> +de = dirp;
> +while (len > 0) {
> +reclen = de->d_reclen;
> +if (reclen > len) {
> +break;
> +}
> +de->d_reclen = tswap16(reclen);
> +tswapls(&de->d_ino);
> +tswapls(&de->d_off);
> +de = (struct linux_dirent *)((char *)de + reclen);
> +len -= reclen;
> +}
> +}
> +unlock_user(dirp, arg2, ret);
> +# endif
> +#else
> +/* Implement getdents in terms of getdents64 */
> +struct linux_dirent64 *dirp;
> +abi_long count = arg3;
> +
> +dirp = lock_user(VERIFY_WRITE, arg2, count, 0);
> +if (!dirp) {
> +return -TARGET_EFAULT;
> +}
> +ret = get_errno(sys_getdents64(arg1, dirp, count));
> +if (!is_error(ret)) {
> +/*
> + * Convert the dirent64 structs to target dirent. We do this
> + * in-place, since we can guarantee that a target_dirent is no
> + * larger than a dirent64; however this means we have to be
> + * careful to read everything before writing in the new format.
> + */
> +struct linux_dirent64 *de;
> +struct target_dirent *tde;
> +int len = ret;
> +int tlen = 0;
> +
> +de = dirp;
> +tde = (struct target_dirent *)dirp;
> +while (len > 0) {
> +int namelen, treclen;
> +int reclen = de->d_reclen;
> +uint64_t ino = de->d_ino;
> +int64_t off = de->d_off;
> +uint8_t type = de->d_type;
> +
> +namelen = strlen(de->d_name);
> +treclen = offsetof(struct target_dirent, d_name) + namelen + 2;
> +treclen = QEMU_ALIGN_UP(treclen, sizeof(abi_long));
> +
> +memmove(tde->d_name, de->d_name, namelen + 1);
> +tde->d_ino = tswapal(ino);
> +tde->d_off = tswapal(off);
> +tde->d_reclen = tswap16(treclen);
> +/*
> + * The target_dirent type is in what was formerly a padding
> + * byte at the end of the structure:
> + */
> +*(((char *)tde) + treclen - 1) = type;
> +
> +de = (struct linux_dirent64 *)((char *)de + reclen);
> +tde = (struct target_dirent *)((char *)tde + treclen);
> +
