[PATCH v3 5/6] target/i386: enumerate VMX nested-exception support

2023-11-08 Thread Xin Li
Allow VMX nested-exception support to be exposed in KVM guests, thus
nested KVM guests can enumerate it.

Tested-by: Shan Kang 
Signed-off-by: Xin Li 
---
 scripts/kvm/vmxcap | 1 +
 target/i386/cpu.c  | 1 +
 target/i386/cpu.h  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap
index 44898d73c2..508be19c75 100755
--- a/scripts/kvm/vmxcap
+++ b/scripts/kvm/vmxcap
@@ -117,6 +117,7 @@ controls = [
 54: 'INS/OUTS instruction information',
 55: 'IA32_VMX_TRUE_*_CTLS support',
 56: 'Skip checks on event error code',
+58: 'VMX nested exception support',
 },
 msr = MSR_IA32_VMX_BASIC,
 ),
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index dcf914a7ec..f7556621a5 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1343,6 +1343,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 [54] = "vmx-ins-outs",
 [55] = "vmx-true-ctls",
 [56] = "vmx-any-errcode",
+[58] = "vmx-nested-exception",
 },
 .msr = {
 .index = MSR_IA32_VMX_BASIC,
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index a4d3702621..cc3b4fefb8 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1054,6 +1054,7 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
 #define MSR_VMX_BASIC_INS_OUTS   (1ULL << 54)
 #define MSR_VMX_BASIC_TRUE_CTLS  (1ULL << 55)
 #define MSR_VMX_BASIC_ANY_ERRCODE(1ULL << 56)
+#define MSR_VMX_BASIC_NESTED_EXCEPTION   (1ULL << 58)
 
 #define MSR_VMX_MISC_PREEMPTION_TIMER_SHIFT_MASK 0x1Full
 #define MSR_VMX_MISC_STORE_LMA   (1ULL << 5)
-- 
2.42.0




[PATCH v3 6/6] target/i386: Add get/set/migrate support for FRED MSRs

2023-11-08 Thread Xin Li
FRED CPU states are managed in 9 new FRED MSRs, in addtion to a few
existing CPU registers and MSRs, e.g., CR4.FRED and MSR_IA32_PL0_SSP.

Save/restore/migrate FRED MSRs if FRED is exposed to the guest.

Tested-by: Shan Kang 
Signed-off-by: Xin Li 
---
 target/i386/cpu.h | 22 +++
 target/i386/kvm/kvm.c | 49 +++
 target/i386/machine.c | 28 +
 3 files changed, 99 insertions(+)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index cc3b4fefb8..3b13eceffe 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -529,6 +529,17 @@ typedef enum X86Seg {
 #define MSR_IA32_XFD0x01c4
 #define MSR_IA32_XFD_ERR0x01c5
 
+/* FRED MSRs */
+#define MSR_IA32_FRED_RSP0  0x01cc   /* Stack level 0 
regular stack pointer */
+#define MSR_IA32_FRED_RSP1  0x01cd   /* Stack level 1 
regular stack pointer */
+#define MSR_IA32_FRED_RSP2  0x01ce   /* Stack level 2 
regular stack pointer */
+#define MSR_IA32_FRED_RSP3  0x01cf   /* Stack level 3 
regular stack pointer */
+#define MSR_IA32_FRED_STKLVLS   0x01d0   /* FRED exception 
stack levels */
+#define MSR_IA32_FRED_SSP1  0x01d1   /* Stack level 1 
shadow stack pointer in ring 0 */
+#define MSR_IA32_FRED_SSP2  0x01d2   /* Stack level 2 
shadow stack pointer in ring 0 */
+#define MSR_IA32_FRED_SSP3  0x01d3   /* Stack level 3 
shadow stack pointer in ring 0 */
+#define MSR_IA32_FRED_CONFIG0x01d4   /* FRED Entrypoint 
and interrupt stack level */
+
 #define MSR_IA32_BNDCFGS0x0d90
 #define MSR_IA32_XSS0x0da0
 #define MSR_IA32_UMWAIT_CONTROL 0xe1
@@ -1687,6 +1698,17 @@ typedef struct CPUArchState {
 target_ulong cstar;
 target_ulong fmask;
 target_ulong kernelgsbase;
+
+/* FRED MSRs */
+uint64_t fred_rsp0;
+uint64_t fred_rsp1;
+uint64_t fred_rsp2;
+uint64_t fred_rsp3;
+uint64_t fred_stklvls;
+uint64_t fred_ssp1;
+uint64_t fred_ssp2;
+uint64_t fred_ssp3;
+uint64_t fred_config;
 #endif
 
 uint64_t tsc_adjust;
diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
index 11b8177eff..101ff63805 100644
--- a/target/i386/kvm/kvm.c
+++ b/target/i386/kvm/kvm.c
@@ -3309,6 +3309,17 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 kvm_msr_entry_add(cpu, MSR_KERNELGSBASE, env->kernelgsbase);
 kvm_msr_entry_add(cpu, MSR_FMASK, env->fmask);
 kvm_msr_entry_add(cpu, MSR_LSTAR, env->lstar);
+if (env->features[FEAT_7_1_EAX] & CPUID_7_1_EAX_FRED) {
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_RSP0, env->fred_rsp0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_RSP1, env->fred_rsp1);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_RSP2, env->fred_rsp2);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_RSP3, env->fred_rsp3);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_STKLVLS, env->fred_stklvls);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_SSP1, env->fred_ssp1);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_SSP2, env->fred_ssp2);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_SSP3, env->fred_ssp3);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_CONFIG, env->fred_config);
+}
 }
 #endif
 
@@ -3773,6 +3784,17 @@ static int kvm_get_msrs(X86CPU *cpu)
 kvm_msr_entry_add(cpu, MSR_KERNELGSBASE, 0);
 kvm_msr_entry_add(cpu, MSR_FMASK, 0);
 kvm_msr_entry_add(cpu, MSR_LSTAR, 0);
+if (env->features[FEAT_7_1_EAX] & CPUID_7_1_EAX_FRED) {
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_RSP0, 0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_RSP1, 0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_RSP2, 0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_RSP3, 0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_STKLVLS, 0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_SSP1, 0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_SSP2, 0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_SSP3, 0);
+kvm_msr_entry_add(cpu, MSR_IA32_FRED_CONFIG, 0);
+}
 }
 #endif
 kvm_msr_entry_add(cpu, MSR_KVM_SYSTEM_TIME, 0);
@@ -3994,6 +4016,33 @@ static int kvm_get_msrs(X86CPU *cpu)
 case MSR_LSTAR:
 env->lstar = msrs[i].data;
 break;
+case MSR_IA32_FRED_RSP0:
+env->fred_rsp0 = msrs[i].data;
+break;
+case MSR_IA32_FRED_RSP1:
+env->fred_rsp1 = msrs[i].data;
+break;
+case MSR_IA32_FRED_RSP2:
+env->fred_rsp2 = msrs[i].data;
+break;
+case MSR_IA32_FRED_RSP3:
+env->fred_rsp3 = msrs[i].data;
+break;
+case MSR_IA32_FRED_STKLVLS:
+env->fred_stklvls = msrs[i].data;
+break;
+case 

[PATCH v3 3/6] target/i386: add the secondary VM exit controls MSR

2023-11-08 Thread Xin Li
Add the secondary VM exit controls MSR to prepare for KVM FRED enabling.

Tested-by: Shan Kang 
Signed-off-by: Xin Li 
---
 scripts/kvm/vmxcap | 9 +
 target/i386/cpu.c  | 2 +-
 target/i386/cpu.h  | 1 +
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap
index 3fb4d5b342..7da1e00ca8 100755
--- a/scripts/kvm/vmxcap
+++ b/scripts/kvm/vmxcap
@@ -24,6 +24,7 @@ MSR_IA32_VMX_TRUE_EXIT_CTLS = 0x48F
 MSR_IA32_VMX_TRUE_ENTRY_CTLS = 0x490
 MSR_IA32_VMX_VMFUNC = 0x491
 MSR_IA32_VMX_PROCBASED_CTLS3 = 0x492
+MSR_IA32_VMX_EXIT_CTLS2 = 0x493
 
 class msr(object):
 def __init__(self):
@@ -219,11 +220,19 @@ controls = [
 23: 'Clear IA32_BNDCFGS',
 24: 'Conceal VM exits from PT',
 25: 'Clear IA32_RTIT_CTL',
+31: 'Activate secondary VM-exit controls',
 },
 cap_msr = MSR_IA32_VMX_EXIT_CTLS,
 true_cap_msr = MSR_IA32_VMX_TRUE_EXIT_CTLS,
 ),
 
+Allowed1Control(
+name = 'secondary VM-Exit controls',
+bits = {
+},
+cap_msr = MSR_IA32_VMX_EXIT_CTLS2,
+),
+
 Control(
 name = 'VM-Entry controls',
 bits = {
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 403c84177a..227ee1c759 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1270,7 +1270,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 "vmx-exit-save-efer", "vmx-exit-load-efer",
 "vmx-exit-save-preemption-timer", "vmx-exit-clear-bndcfgs",
 NULL, "vmx-exit-clear-rtit-ctl", NULL, NULL,
-NULL, "vmx-exit-load-pkrs", NULL, NULL,
+NULL, "vmx-exit-load-pkrs", NULL, "vmx-exit-secondary-ctls",
 },
 .msr = {
 .index = MSR_IA32_VMX_TRUE_EXIT_CTLS,
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index e210957cba..a4d3702621 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -551,6 +551,7 @@ typedef enum X86Seg {
 #define MSR_IA32_VMX_TRUE_EXIT_CTLS  0x048f
 #define MSR_IA32_VMX_TRUE_ENTRY_CTLS 0x0490
 #define MSR_IA32_VMX_VMFUNC 0x0491
+#define MSR_IA32_VMX_EXIT_CTLS2 0x0493
 
 #define XSTATE_FP_BIT   0
 #define XSTATE_SSE_BIT  1
-- 
2.42.0




[PATCH v3 4/6] target/i386: add support for VMX FRED controls

2023-11-08 Thread Xin Li
Add VMX FRED controls used to enable save/load of FRED MSRs.

Tested-by: Shan Kang 
Signed-off-by: Xin Li 
---
 scripts/kvm/vmxcap | 3 +++
 target/i386/cpu.c  | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap
index 7da1e00ca8..44898d73c2 100755
--- a/scripts/kvm/vmxcap
+++ b/scripts/kvm/vmxcap
@@ -229,6 +229,8 @@ controls = [
 Allowed1Control(
 name = 'secondary VM-Exit controls',
 bits = {
+0: 'Save IA32 FRED MSRs',
+1: 'Load IA32 FRED MSRs',
 },
 cap_msr = MSR_IA32_VMX_EXIT_CTLS2,
 ),
@@ -246,6 +248,7 @@ controls = [
 16: 'Load IA32_BNDCFGS',
 17: 'Conceal VM entries from PT',
 18: 'Load IA32_RTIT_CTL',
+23: 'Load IA32 FRED MSRs',
 },
 cap_msr = MSR_IA32_VMX_ENTRY_CTLS,
 true_cap_msr = MSR_IA32_VMX_TRUE_ENTRY_CTLS,
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 227ee1c759..dcf914a7ec 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1285,7 +1285,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 NULL, "vmx-entry-ia32e-mode", NULL, NULL,
 NULL, "vmx-entry-load-perf-global-ctrl", "vmx-entry-load-pat", 
"vmx-entry-load-efer",
 "vmx-entry-load-bndcfgs", NULL, "vmx-entry-load-rtit-ctl", NULL,
-NULL, NULL, "vmx-entry-load-pkrs", NULL,
+NULL, NULL, "vmx-entry-load-pkrs", "vmx-entry-load-fred",
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
 },
-- 
2.42.0




[PATCH v3 0/6] target/i386: add support for FRED

2023-11-08 Thread Xin Li
This patch set adds support for the Intel flexible return and event delivery
(FRED) architecture to allow Qemu to run KVM guests with FRED enabled.

The FRED architecture defines simple new transitions that change privilege
level (ring transitions). The FRED architecture was designed with the
following goals:
1) Improve overall performance and response time by replacing event delivery
   through the interrupt descriptor table (IDT event delivery) and event
   return by the IRET instruction with lower latency transitions.
2) Improve software robustness by ensuring that event delivery establishes
   the full supervisor context and that event return establishes the full
   user context.

Intel VMX architecture is extended to run FRED guests, and the changes
are majorly:
1) New VMCS fields for FRED context management, which includes two new
   event data VMCS fields, eight new guest FRED context VMCS fields and
   eight new host FRED context VMCS fields.
2) VMX nested-Exception support for proper virtualization of stack
   levels introduced with FRED architecture.

Search for the latest FRED spec in most search engines with this search pattern:

  site:intel.com FRED (flexible return and event delivery) specification

The counterpart KVM patch set is at:
https://lore.kernel.org/kvm/20231108183003.5981-1-xin3...@intel.com/T/#m77876e22876f41c5ec677c0834a46113a4987d31


---
Changelog
v3:
- Add WRMSRNS as a baseline feature for FRED.
- Add the secondary VM exit controls MSR.
- Add FRED VMX controls to VM exit/entry feature words and
  scripts/kvm/vmxcap.
- Do not set/get FRED SSP0 MSR, i.e. PL0_SSP MSR, with FRED, leave it to
  KVM CET.

v2:
- Add VMX nested-exception support to scripts/kvm/vmxcap (Paolo Bonzini).
- Move FRED MSRs from basic x86_cpu part to .subsections part (Weijiang Yang).


Xin Li (6):
  target/i386: add support for FRED in CPUID enumeration
  target/i386: mark CR4.FRED not reserved
  target/i386: add the secondary VM exit controls MSR
  target/i386: add support for VMX FRED controls
  target/i386: enumerate VMX nested-exception support
  target/i386: Add get/set/migrate support for FRED MSRs

 scripts/kvm/vmxcap| 13 
 target/i386/cpu.c | 15 ++---
 target/i386/cpu.h | 42 -
 target/i386/kvm/kvm.c | 49 +++
 target/i386/machine.c | 28 +
 5 files changed, 143 insertions(+), 4 deletions(-)


base-commit: a3c3aaa846ad61b801e7196482dcf4afb8ba34e4
-- 
2.42.0




[PATCH v3 1/6] target/i386: add support for FRED in CPUID enumeration

2023-11-08 Thread Xin Li
FRED, i.e., the Intel flexible return and event delivery architecture,
defines simple new transitions that change privilege level (ring
transitions).

The new transitions defined by the FRED architecture are FRED event
delivery and, for returning from events, two FRED return instructions.
FRED event delivery can effect a transition from ring 3 to ring 0, but
it is used also to deliver events incident to ring 0.  One FRED
instruction (ERETU) effects a return from ring 0 to ring 3, while the
other (ERETS) returns while remaining in ring 0.  Collectively, FRED
event delivery and the FRED return instructions are FRED transitions.

In addition to these transitions, the FRED architecture defines a new
instruction (LKGS) for managing the state of the GS segment register.
The LKGS instruction can be used by 64-bit operating systems that do
not use the new FRED transitions.

WRMSRNS is an instruction that behaves exactly like WRMSR, with the
only difference being that it is not a serializing instruction by
default.  Under certain conditions, WRMSRNS may replace WRMSR to improve
performance.  FRED uses it to switch RSP0 in a faster manner.

Search for the latest FRED spec in most search engines with this search
pattern:

  site:intel.com FRED (flexible return and event delivery) specification

The CPUID feature flag CPUID.(EAX=7,ECX=1):EAX[17] enumerates FRED, and
the CPUID feature flag CPUID.(EAX=7,ECX=1):EAX[18] enumerates LKGS, and
the CPUID feature flag CPUID.(EAX=7,ECX=1):EAX[19] enumerates WRMSRNS.

Add CPUID definitions for FRED/LKGS/WRMSRNS, and expose them to KVM guests.

Because FRED relies on LKGS and WRMSRNS, add that to feature dependency
map.

Tested-by: Shan Kang 
Signed-off-by: Xin Li 
---
 target/i386/cpu.c | 10 +-
 target/i386/cpu.h |  6 ++
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 358d9c0a65..403c84177a 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -965,7 +965,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 "avx-vnni", "avx512-bf16", NULL, "cmpccxadd",
 NULL, NULL, "fzrm", "fsrs",
 "fsrc", NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
+NULL, "fred", "lkgs", "wrmsrns",
 NULL, "amx-fp16", NULL, "avx-ifma",
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
@@ -1552,6 +1552,14 @@ static FeatureDep feature_dependencies[] = {
 .from = { FEAT_VMX_SECONDARY_CTLS,  
VMX_SECONDARY_EXEC_ENABLE_USER_WAIT_PAUSE },
 .to = { FEAT_7_0_ECX,   CPUID_7_0_ECX_WAITPKG },
 },
+{
+.from = { FEAT_7_1_EAX, CPUID_7_1_EAX_FRED },
+.to = { FEAT_7_1_EAX,   CPUID_7_1_EAX_LKGS },
+},
+{
+.from = { FEAT_7_1_EAX, CPUID_7_1_EAX_FRED },
+.to = { FEAT_7_1_EAX,   CPUID_7_1_EAX_WRMSRNS },
+},
 };
 
 typedef struct X86RegisterInfo32 {
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index cd2e295bd6..5faf00551d 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -934,6 +934,12 @@ uint64_t x86_cpu_get_supported_feature_word(FeatureWord w,
 #define CPUID_7_1_EDX_AMX_COMPLEX   (1U << 8)
 /* PREFETCHIT0/1 Instructions */
 #define CPUID_7_1_EDX_PREFETCHITI   (1U << 14)
+/* Flexible return and event delivery (FRED) */
+#define CPUID_7_1_EAX_FRED  (1U << 17)
+/* Load into IA32_KERNEL_GS_BASE (LKGS) */
+#define CPUID_7_1_EAX_LKGS  (1U << 18)
+/* Non-Serializing Write to Model Specific Register (WRMSRNS) */
+#define CPUID_7_1_EAX_WRMSRNS   (1U << 19)
 
 /* Do not exhibit MXCSR Configuration Dependent Timing (MCDT) behavior */
 #define CPUID_7_2_EDX_MCDT_NO   (1U << 5)
-- 
2.42.0




[PATCH v3 2/6] target/i386: mark CR4.FRED not reserved

2023-11-08 Thread Xin Li
The CR4.FRED bit, i.e., CR4[32], is no longer a reserved bit when FRED
is exposed to guests, otherwise it is still a reserved bit.

Tested-by: Shan Kang 
Signed-off-by: Xin Li 
---
 target/i386/cpu.h | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 5faf00551d..e210957cba 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -262,6 +262,12 @@ typedef enum X86Seg {
 #define CR4_PKE_MASK   (1U << 22)
 #define CR4_PKS_MASK   (1U << 24)
 
+#ifdef TARGET_X86_64
+#define CR4_FRED_MASK   (1ULL << 32)
+#else
+#define CR4_FRED_MASK   0
+#endif
+
 #define CR4_RESERVED_MASK \
 (~(target_ulong)(CR4_VME_MASK | CR4_PVI_MASK | CR4_TSD_MASK \
 | CR4_DE_MASK | CR4_PSE_MASK | CR4_PAE_MASK \
@@ -269,7 +275,8 @@ typedef enum X86Seg {
 | CR4_OSFXSR_MASK | CR4_OSXMMEXCPT_MASK | CR4_UMIP_MASK \
 | CR4_LA57_MASK \
 | CR4_FSGSBASE_MASK | CR4_PCIDE_MASK | CR4_OSXSAVE_MASK \
-| CR4_SMEP_MASK | CR4_SMAP_MASK | CR4_PKE_MASK | CR4_PKS_MASK))
+| CR4_SMEP_MASK | CR4_SMAP_MASK | CR4_PKE_MASK | CR4_PKS_MASK \
+| CR4_FRED_MASK))
 
 #define DR6_BD  (1 << 13)
 #define DR6_BS  (1 << 14)
@@ -2520,6 +2527,9 @@ static inline uint64_t cr4_reserved_bits(CPUX86State *env)
 if (!(env->features[FEAT_7_0_ECX] & CPUID_7_0_ECX_PKS)) {
 reserved_bits |= CR4_PKS_MASK;
 }
+if (!(env->features[FEAT_7_1_EAX] & CPUID_7_1_EAX_FRED)) {
+reserved_bits |= CR4_FRED_MASK;
+}
 return reserved_bits;
 }
 
-- 
2.42.0




Re: [PATCH] tracetool: avoid invalid escape in Python string

2023-11-08 Thread Stefan Hajnoczi
On Wed, Nov 08, 2023 at 02:56:49PM +0400, marcandre.lur...@redhat.com wrote:
> From: Marc-André Lureau 
> 
> This is an error in Python 3.12; fix it by using a raw string literal.
> 
> Cc: qemu-sta...@nongnu.org
> Signed-off-by: Marc-André Lureau 
> ---
>  scripts/tracetool/__init__.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks, applied to my tracing tree:
https://gitlab.com/stefanha/qemu/commits/tracing

Stefan


signature.asc
Description: PGP signature


Re: [PATCH v3] hw/ide/ahci: fix legacy software reset

2023-11-08 Thread Marcin Juszkiewicz

W dniu 8.11.2023 o 23:26, Niklas Cassel pisze:

From: Niklas Cassel 



This fixes an issue for FreeBSD where the device would fail to reset.
The problem was not noticed in Linux, because Linux uses a COMRESET
instead of a legacy software reset by default.

Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
Reported-by: Marcin Juszkiewicz 
Signed-off-by: Niklas Cassel 


Tested-by: Marcin Juszkiewicz 

FreeBSD 14-rc3 boots fine on AArch64 with this patch:

Trying to mount root from cd9660:/dev/iso9660/14_0_RC3_AARCH64_BO [ro]...
cd0 at ahcich0 bus 0 scbus0 target 0 lun 0
cd0:  Removable CD-ROM SCSI device
cd0: Serial Number QM1
cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd0: 347MB (177954 2048 byte sectors)
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0:  ATA-7 SATA device
ada0: Serial Number QM3
ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 504MB (1032192 512 byte sectors)
ada1 at ahcich2 bus 0 scbus2 target 0 lun 0
ada1:  ATA-7 SATA device
ada1: Serial Number QM5
ada1: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 8192MB (16777216 512 byte sectors)




[PULL 1/1] tracetool: avoid invalid escape in Python string

2023-11-08 Thread Stefan Hajnoczi
From: Marc-André Lureau 

This is an error in Python 3.12; fix it by using a raw string literal.

Cc:  
Signed-off-by: Marc-André Lureau 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Stefan Hajnoczi 
Message-ID: <20231108105649.60453-1-marcandre.lur...@redhat.com>
---
 scripts/tracetool/__init__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index b29594d75e..b887540a55 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -91,7 +91,7 @@ def out(*lines, **kwargs):
 def validate_type(name):
 bits = name.split(" ")
 for bit in bits:
-bit = re.sub("\*", "", bit)
+bit = re.sub(r"\*", "", bit)
 if bit == "":
 continue
 if bit == "const":
-- 
2.41.0




[PULL 0/1] Tracing patches

2023-11-08 Thread Stefan Hajnoczi
The following changes since commit a3c3aaa846ad61b801e7196482dcf4afb8ba34e4:

  Merge tag 'pull-ppc-20231107' of https://gitlab.com/danielhb/qemu into 
staging (2023-11-08 20:35:00 +0800)

are available in the Git repository at:

  https://gitlab.com/stefanha/qemu.git tags/tracing-pull-request

for you to fetch changes up to 4d96307c5b4fac40c6ca25f38318b4b65d315de0:

  tracetool: avoid invalid escape in Python string (2023-11-09 15:03:02 +0800)


Pull request



Marc-André Lureau (1):
  tracetool: avoid invalid escape in Python string

 scripts/tracetool/__init__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.41.0




Re: [PATCH RFC v1 0/1] clipboard sharing implementation for SDL

2023-11-08 Thread Markus Armbruster
Kamay Xutax  writes:

> Hello,
>
> This is my first try contributing to QEMU,

Welcome!

> and I would like some advices before merging my patch into master branch.

First piece of advice: it's a busy mailing list, and to get people's
attention, cc: them.  For a patch, you want to cc: maintainers of the
code you patch.  To find them, use scripts/get_maintainer.pl and
exercise judgement.  Let me show you:

$ scripts/get_maintainer.pl ./0001-*patch

Gerd Hoffmann  (odd fixer:Graphics)
"Marc-André Lureau"  (odd fixer:Graphics)
Paolo Bonzini  (maintainer:Meson)
"Daniel P. Berrangé"  (reviewer:Meson)
Thomas Huth  (reviewer:Meson)
"Philippe Mathieu-Daudé"  (reviewer:Meson)
qemu-devel@nongnu.org (open list:All patches CC here)

Since the patch's Meson part is straightforward, I'd just cc: the two
Graphics people,  I'm doing it in this message, so you don't have to.

[...]




[PATCH v6] tests/avocado: add test to exercize processor address space memory bound checks

2023-11-08 Thread Ani Sinha
QEMU has validations to make sure that a VM is not started with more memory
(static and hotpluggable memory) than what the guest processor can address
directly with its addressing bits. This change adds a test to make sure QEMU
fails to start with a specific error message when an attempt is made to
start a VM with more memory than what the processor can directly address.
The test also checks for passing cases when the address space of the processor
is capable of addressing all memory. Boundary cases are tested.

CC: imamm...@redhat.com
CC: David Hildenbrand 
Acked-by: David Hildenbrand 
Acked-by: Philippe Mathieu-Daudé 
Signed-off-by: Ani Sinha 
---
 tests/avocado/mem-addr-space-check.py | 367 ++
 1 file changed, 367 insertions(+)
 create mode 100644 tests/avocado/mem-addr-space-check.py

Changelog:
v6: added phil's suggestions - added comment to explain why a sleep delay
is needed. Reduced delay to 1 sec. Added a one place definition for
the sleep duration so we can tweak it if needed later. Added phil's
tag. rebased.
v5:
  - made the negative test cases (ones that do not result in QEMU crash)
more robust by checking the non-existence of the "phys-bits too low"
log.
  - added a new test case for AMD HT window where QEMU starts fine.
  - rebased.
  - cosmetic typo/comment adjustments.

Tests all pass:
$ ./pyvenv/bin/avocado run tests/avocado/mem-addr-space-check.py --tap -
1..15
ok 1 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pse36
ok 2 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pae
ok 3 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pse36
ok 4 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pae
ok 5 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium2
ok 6 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_nonpse36
ok 7 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_70_amd
ok 8 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd
ok 9 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_70_amd
ok 10 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd
ok 11 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_intel
ok 12 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd_41bits
ok 13 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd_41bits
ok 14 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_intel_cxl
ok 15 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_intel_cxl

v4: incorporated changes related to suggestions from David.
v3: added pae tests as well.
v2: added 64-bit tests. Added cxl tests.

diff --git a/tests/avocado/mem-addr-space-check.py 
b/tests/avocado/mem-addr-space-check.py
new file mode 100644
index 00..fae7d48598
--- /dev/null
+++ b/tests/avocado/mem-addr-space-check.py
@@ -0,0 +1,367 @@
+# Check for crash when using memory beyond the available guest processor
+# address space.
+#
+# Copyright (c) 2023 Red Hat, Inc.
+#
+# Author:
+#  Ani Sinha 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+from avocado_qemu import QemuSystemTest
+import signal
+import time
+
+class MemAddrCheck(QemuSystemTest):
+# after launch, in order to generate the logs from QEMU we need to
+# wait for some time. Launching and then immediately shutting down
+# the VM generates empty logs. A delay of 1 second is added for
+# this reason.
+DELAY_Q35_BOOT_SEQUENCE = 1
+
+# first, lets test some 32-bit processors.
+# for all 32-bit cases, pci64_hole_size is 0.
+def test_phybits_low_pse36(self):
+"""
+:avocado: tags=machine:q35
+:avocado: tags=arch:x86_64
+
+With pse36 feature ON, a processor has 36 bits of addressing. So it can
+access up to a maximum of 64GiB of memory. Memory hotplug region begins
+at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
when
+we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
+hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
memory
+for dimm alignment for all newer machines (see 

Re: [PULL v2 00/25] Block layer patches

2023-11-08 Thread Stefan Hajnoczi
Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any 
user-visible changes.


signature.asc
Description: PGP signature


Re: [PULL v2 00/23] Final test, gdbstub, plugin and gitdm updates for 8.2

2023-11-08 Thread Stefan Hajnoczi
Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any 
user-visible changes.


signature.asc
Description: PGP signature


Re: [PATCH v5] tests/avocado: add test to exercize processor address space memory bound checks

2023-11-08 Thread Ani Sinha



> On 08-Nov-2023, at 8:33 PM, Philippe Mathieu-Daudé  wrote:
> 
> Hi Ani,
> 
> On 3/11/23 12:06, Ani Sinha wrote:
>> QEMU has validations to make sure that a VM is not started with more memory
>> (static and hotpluggable memory) than what the guest processor can address
>> directly with its addressing bits. This change adds a test to make sure QEMU
>> fails to start with a specific error message when an attempt is made to
>> start a VM with more memory than what the processor can directly address.
>> The test also checks for passing cases when the address space of the 
>> processor
>> is capable of addressing all memory. Boundary cases are tested.
>> CC: imamm...@redhat.com
>> CC: David Hildenbrand 
>> Acked-by: David Hildenbrand 
>> Signed-off-by: Ani Sinha 
>> ---
>>  tests/avocado/mem-addr-space-check.py | 361 ++
>>  1 file changed, 361 insertions(+)
>>  create mode 100644 tests/avocado/mem-addr-space-check.py
>> Changelog:
>> v5:
>>   - made the negative test cases (ones that do not result in QEMU crash)
>> more robust by checking the non-existence of the "phys-bits too low"
>> log.
>>   - added a new test case for AMD HT window where QEMU starts fine.
>>   - rebased.
>>   - cosmetic typo/comment adjustments.
>> Tests all pass:
>> $ ./pyvenv/bin/avocado run tests/avocado/mem-addr-space-check.py --tap -
>> 1..15
>> ok 1 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pse36
>> ok 2 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pae
>> ok 3 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pse36
>> ok 4 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pae
>> ok 5 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium2
>> ok 6 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_nonpse36
>> ok 7 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_70_amd
>> ok 8 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd
>> ok 9 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_70_amd
>> ok 10 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd
>> ok 11 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_intel
>> ok 12 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd_41bits
>> ok 13 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd_41bits
>> ok 14 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_intel_cxl
>> ok 15 
>> tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_intel_cxl
>> v4: incorporated changes related to suggestions from David.
>> v3: added pae tests as well.
>> v2: added 64-bit tests. Added cxl tests.
>> diff --git a/tests/avocado/mem-addr-space-check.py 
>> b/tests/avocado/mem-addr-space-check.py
>> new file mode 100644
>> index 00..6b4ada5857
>> --- /dev/null
>> +++ b/tests/avocado/mem-addr-space-check.py
>> @@ -0,0 +1,361 @@
>> +# Check for crash when using memory beyond the available guest processor
>> +# address space.
>> +#
>> +# Copyright (c) 2023 Red Hat, Inc.
>> +#
>> +# Author:
>> +#  Ani Sinha 
>> +#
>> +# This program is free software; you can redistribute it and/or modify
>> +# it under the terms of the GNU General Public License as published by
>> +# the Free Software Foundation; either version 2 of the License, or
>> +# (at your option) any later version.
>> +#
>> +# This program is distributed in the hope that it will be useful,
>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> +# GNU General Public License for more details.
>> +#
>> +# You should have received a copy of the GNU General Public License
>> +# along with this program.  If not, see .
>> +
>> +from avocado_qemu import QemuSystemTest
>> +import signal
>> +import time
>> +
>> +class MemAddrCheck(QemuSystemTest):
>> +# first, lets test some 32-bit processors.
>> +# for all 32-bit cases, pci64_hole_size is 0.
>> +def test_phybits_low_pse36(self):
>> +"""
>> +:avocado: tags=machine:q35
>> +:avocado: tags=arch:x86_64
>> +
>> +With pse36 feature ON, a processor has 36 bits of addressing. So it 
>> can
>> +access up to a maximum of 64GiB of memory. Memory hotplug region 
>> begins
>> +at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
>> when
>> +we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
>> +hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
>> memory
>> +for dimm alignment for all newer machines (see enforce_aligned_dimm
>> +property for pc machines and pc_get_device_memory_range()). That 
>> leaves

RE: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend

2023-11-08 Thread Duan, Zhenzhong



>-Original Message-
>From: Jason Gunthorpe 
>Sent: Wednesday, November 8, 2023 10:19 PM
>Subject: Re: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend
>
>On Wed, Nov 08, 2023 at 01:25:34PM +, Duan, Zhenzhong wrote:
>
>> >I was expecting that hwpt manipulation would be done exclusively
>> >inside the device-specific vIOMMU userspace driver. Generic code paths
>> >that don't have that knowledge should use the IOAS for everything
>>
>> Yes, this way we don't need to distinguish between mdev and real device,
>> just attach to IOAS. But lose the benefit that same hwpt could be passed
>> into vIOMMU to be used as S2 hwpt in nesting.
>
>If you have a nesting capable vIOMMU driver then it should be
>creating the HWPTs and managing them in its layer. Maybe the core code
>provides some helpers.

OK, thanks for suggestion.

>
>Obviously you can't link a mdev to a nesting vIOMMU driver in the
>first place. Mdev should be connected to a different IOMMU driver that
>doesn't use HWPT at all.
>
>I think it will make alot of trouble to put the hwpt in the wrong
>layer as there shouldn't really be much generic code touching it.

I'll send v5 with your suggested changes.

Thanks
Zhenzhong



Re: [PATCH 1/1] hw/intc/riscv_aclint:Change the way to get CPUState from hard-base to pu_index

2023-11-08 Thread Dongxue Zhang
Reviewed-by: Dongxue Zhang 


On Thu, Nov 9, 2023 at 10:22 AM Leo Hou  wrote:
>
> From: Leo Hou 
>
> cpu_by_arch_id() uses hartid-base as the index to obtain the corresponding 
> CPUState structure variable.
> qemu_get_cpu() uses cpu_index as the index to obtain the corresponding 
> CPUState structure variable.
>
> In heterogeneous CPU or multi-socket scenarios, multiple aclint needs to be 
> instantiated,
> and the hartid-base of each cpu bound by aclint can start from 0. If 
> cpu_by_arch_id() is still used
> in this case, all aclint will bind to the earliest initialized hart with 
> hartid-base 0 and cause conflicts.
>
> So with cpu_index as the index, use qemu_get_cpu() to get the CPUState struct 
> variable,
> and connect the aclint interrupt line to the hart of the CPU indexed with 
> cpu_index
> (the corresponding hartid-base can start at 0). It's more reasonable.
>
> Signed-off-by: Leo Hou 
> ---
>  hw/intc/riscv_aclint.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/hw/intc/riscv_aclint.c b/hw/intc/riscv_aclint.c
> index ab1a0b4b3a..be8f539fcb 100644
> --- a/hw/intc/riscv_aclint.c
> +++ b/hw/intc/riscv_aclint.c
> @@ -130,7 +130,7 @@ static uint64_t riscv_aclint_mtimer_read(void *opaque, 
> hwaddr addr,
>  addr < (mtimer->timecmp_base + (mtimer->num_harts << 3))) {
>  size_t hartid = mtimer->hartid_base +
>  ((addr - mtimer->timecmp_base) >> 3);
> -CPUState *cpu = cpu_by_arch_id(hartid);
> +CPUState *cpu = qemu_get_cpu(hartid);
>  CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
>  if (!env) {
>  qemu_log_mask(LOG_GUEST_ERROR,
> @@ -173,7 +173,7 @@ static void riscv_aclint_mtimer_write(void *opaque, 
> hwaddr addr,
>  addr < (mtimer->timecmp_base + (mtimer->num_harts << 3))) {
>  size_t hartid = mtimer->hartid_base +
>  ((addr - mtimer->timecmp_base) >> 3);
> -CPUState *cpu = cpu_by_arch_id(hartid);
> +CPUState *cpu = qemu_get_cpu(hartid);
>  CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
>  if (!env) {
>  qemu_log_mask(LOG_GUEST_ERROR,
> @@ -232,7 +232,7 @@ static void riscv_aclint_mtimer_write(void *opaque, 
> hwaddr addr,
>
>  /* Check if timer interrupt is triggered for each hart. */
>  for (i = 0; i < mtimer->num_harts; i++) {
> -CPUState *cpu = cpu_by_arch_id(mtimer->hartid_base + i);
> +CPUState *cpu = qemu_get_cpu(mtimer->hartid_base + i);
>  CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
>  if (!env) {
>  continue;
> @@ -293,7 +293,7 @@ static void riscv_aclint_mtimer_realize(DeviceState *dev, 
> Error **errp)
>  s->timecmp = g_new0(uint64_t, s->num_harts);
>  /* Claim timer interrupt bits */
>  for (i = 0; i < s->num_harts; i++) {
> -RISCVCPU *cpu = RISCV_CPU(cpu_by_arch_id(s->hartid_base + i));
> +RISCVCPU *cpu = RISCV_CPU(qemu_get_cpu(s->hartid_base + i));
>  if (riscv_cpu_claim_interrupts(cpu, MIP_MTIP) < 0) {
>  error_report("MTIP already claimed");
>  exit(1);
> @@ -373,7 +373,7 @@ DeviceState *riscv_aclint_mtimer_create(hwaddr addr, 
> hwaddr size,
>  sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, addr);
>
>  for (i = 0; i < num_harts; i++) {
> -CPUState *cpu = cpu_by_arch_id(hartid_base + i);
> +CPUState *cpu = qemu_get_cpu(hartid_base + i);
>  RISCVCPU *rvcpu = RISCV_CPU(cpu);
>  CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
>  riscv_aclint_mtimer_callback *cb =
> @@ -408,7 +408,7 @@ static uint64_t riscv_aclint_swi_read(void *opaque, 
> hwaddr addr,
>
>  if (addr < (swi->num_harts << 2)) {
>  size_t hartid = swi->hartid_base + (addr >> 2);
> -CPUState *cpu = cpu_by_arch_id(hartid);
> +CPUState *cpu = qemu_get_cpu(hartid);
>  CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
>  if (!env) {
>  qemu_log_mask(LOG_GUEST_ERROR,
> @@ -431,7 +431,7 @@ static void riscv_aclint_swi_write(void *opaque, hwaddr 
> addr, uint64_t value,
>
>  if (addr < (swi->num_harts << 2)) {
>  size_t hartid = swi->hartid_base + (addr >> 2);
> -CPUState *cpu = cpu_by_arch_id(hartid);
> +CPUState *cpu = qemu_get_cpu(hartid);
>  CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
>  if (!env) {
>  qemu_log_mask(LOG_GUEST_ERROR,
> @@ -546,7 +546,7 @@ DeviceState *riscv_aclint_swi_create(hwaddr addr, 
> uint32_t hartid_base,
>  sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, addr);
>
>  for (i = 0; i < num_harts; i++) {
> -CPUState *cpu = cpu_by_arch_id(hartid_base + i);
> +CPUState *cpu = qemu_get_cpu(hartid_base + i);
>  RISCVCPU *rvcpu = RISCV_CPU(cpu);
>
>  qdev_connect_gpio_out(dev, i,
> --
> 2.34.1
>



Re: [PATCH 2/2] .gitlab-ci.d/cirrus: Add manual testing of macOS 14 (Sonoma)

2023-11-08 Thread Paolo Bonzini
Il mer 8 nov 2023, 19:33 Philippe Mathieu-Daudé  ha
scritto:

> Upgrade libvirt-ci so it covers macOS 14. Add a manual entry
> (QEMU_JOB_OPTIONAL: 1) to test on Sonoma release. Refresh the
> lci-tool generated files.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Docs are disabled due to:
>
>   Collecting sphinx
> Downloading sphinx-7.2.6-py3-none-any.whl.metadata (5.9 kB)
>   Collecting sphinx-rtd-theme
> Downloading sphinx_rtd_theme-1.3.0-py2.py3-none-any.whl.metadata (4.5
> kB)
>

Same issue: the pip that is installing sphinx is unrelated to the Python
that is used to compile QEMU. Use /opt/homebrew/bin/pip3 instead.

Paolo

  ...
>   Installing collected packages ...
>   ...
>   python determined to be '/opt/homebrew/bin/python3'
>   python version: Python 3.11.6
>   mkvenv: Creating non-isolated virtual environment at 'pyvenv'
>   mkvenv: checking for sphinx>=1.6
>   mkvenv: checking for sphinx_rtd_theme>=0.5
>   ...
>   Program /opt/homebrew/opt/python@3.12/bin/sphinx-build found: NO
>   ../docs/meson.build:1:15: ERROR: Program 
> '/opt/homebrew/opt/python@3.12/bin/sphinx-build'
> not found or not executable
>
> ¯\_(ツ)_/¯
> ---
>  .gitlab-ci.d/cirrus.yml   | 17 +
>  .gitlab-ci.d/cirrus/macos-14.vars | 16 
>  tests/lcitool/libvirt-ci  |  2 +-
>  tests/lcitool/refresh |  1 +
>  4 files changed, 35 insertions(+), 1 deletion(-)
>  create mode 100644 .gitlab-ci.d/cirrus/macos-14.vars
>
> diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
> index 07dc6edae1..84ce143509 100644
> --- a/.gitlab-ci.d/cirrus.yml
> +++ b/.gitlab-ci.d/cirrus.yml
> @@ -74,6 +74,23 @@ aarch64-macos-13-base-build:
>  PKG_CONFIG_PATH:
> /opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
>  TEST_TARGETS: check-unit check-block check-qapi-schema
> check-softfloat check-qtest-x86_64
>
> +aarch64-macos-14-base-build:
> +  extends: .cirrus_build_job
> +  variables:
> +NAME: macos-14
> +CIRRUS_VM_INSTANCE_TYPE: macos_instance
> +CIRRUS_VM_IMAGE_SELECTOR: image
> +CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-sonoma-base:latest
> +CIRRUS_VM_CPUS: 12
> +CIRRUS_VM_RAM: 24G
> +UPDATE_COMMAND: brew update
> +INSTALL_COMMAND: brew install
> +PATH_EXTRA: /opt/homebrew/ccache/libexec:/opt/homebrew/gettext/bin
> +PKG_CONFIG_PATH:
> /opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
> +TEST_TARGETS: check-unit check-block check-qapi-schema
> check-softfloat check-qtest-x86_64
> +QEMU_JOB_OPTIONAL: 1
> +CONFIGURE_ARGS: --disable-docs
> +
>
>  # The following jobs run VM-based tests via KVM on a Linux-based
> Cirrus-CI job
>  .cirrus_kvm_job:
> diff --git a/.gitlab-ci.d/cirrus/macos-14.vars
> b/.gitlab-ci.d/cirrus/macos-14.vars
> new file mode 100644
> index 00..43070f4a26
> --- /dev/null
> +++ b/.gitlab-ci.d/cirrus/macos-14.vars
> @@ -0,0 +1,16 @@
> +# THIS FILE WAS AUTO-GENERATED
> +#
> +#  $ lcitool variables macos-14 qemu
> +#
> +# https://gitlab.com/libvirt/libvirt-ci
> +
> +CCACHE='/opt/homebrew/bin/ccache'
> +CPAN_PKGS=''
> +CROSS_PKGS=''
> +MAKE='/opt/homebrew/bin/gmake'
> +NINJA='/opt/homebrew/bin/ninja'
> +PACKAGING_COMMAND='brew'
> +PIP3='/opt/homebrew/bin/pip3'
> +PKGS='bash bc bison bzip2 capstone ccache cmocka ctags curl dbus
> diffutils dtc flex gcovr gettext git glib gnu-sed gnutls gtk+3 jemalloc
> jpeg-turbo json-c libepoxy libffi libgcrypt libiscsi libnfs libpng libslirp
> libssh libtasn1 libusb llvm lzo make meson mtools ncurses nettle ninja
> pixman pkg-config python3 rpm2cpio sdl2 sdl2_image snappy socat sparse
> spice-protocol swtpm tesseract usbredir vde vte3 xorriso zlib zstd'
> +PYPI_PKGS='PyYAML numpy pillow sphinx sphinx-rtd-theme tomli'
> +PYTHON='/opt/homebrew/bin/python3'
> diff --git a/tests/lcitool/libvirt-ci b/tests/lcitool/libvirt-ci
> index 36bc517161..77c800186f 16
> --- a/tests/lcitool/libvirt-ci
> +++ b/tests/lcitool/libvirt-ci
> @@ -1 +1 @@
> -Subproject commit 36bc517161c45ead20224d47f2dc4fa428af6724
> +Subproject commit 77c800186f34b21be7660750577cc5582a914deb
> diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
> index 2259f131b4..e11d0ba381 100755
> --- a/tests/lcitool/refresh
> +++ b/tests/lcitool/refresh
> @@ -197,6 +197,7 @@ try:
>  #
>  generate_cirrus("freebsd-13")
>  generate_cirrus("macos-13")
> +generate_cirrus("macos-14")
>
>  #
>  # VM packages lists
> --
> 2.41.0
>
>


Re: [NOTFORMERGE PATCH 1/2] configure: Use distrib meson

2023-11-08 Thread Paolo Bonzini
Il mer 8 nov 2023, 20:52 BALATON Zoltan  ha scritto:

> AFAIU the problem is that macOS has system python in
> /Library/Frameworks/python.framework (or something like that) but homebrew
> does not use that but installs its own python somewhere in /opt and meson
> from homebrew uses that python but configure finds the system python which
> does not have meson so it then downloads its own meson but that's too old
> for macOS Sonoma


Correct (except s/downloads/installs/), basically --python/$PYTHON is the
sole interpreter used to run *any* Python code during the QEMU build. The
difference is that QEMU 8.1 would indeed download Meson, while QEMU 8.2
always uses the wheel that is shipped with QEMU. This change was done
because the embedded Meson is intended to be a "known good" version that we
(and pythondeps.toml) can point users to, in case a newer version from the
distro has issues. Of course the other side of the coin is that an older
version might not support new OSes as in this case.

The workaround below is not just a workaround but the intended solution if
one wants to use the Meson and Sphinx packages from homebrew, and cannot
modify the PATH to privilege homebrew's Python interpreter. In order to
support Sonoma out of the box with the system Python, however, we can bump
the shipped version of Meson to 1.2.x (and adjust pythondeps.toml).

Paolo

It should probably check for homebrew or macports
> locations too or check for meson and get the python that's using. A
> workaround apparently is to pass --python with the right path to
> configure.
>


Re: [PATCH RFC 3/7] migration: multifd_send_kick_main()

2023-11-08 Thread Fabiano Rosas
Peter Xu  writes:

> When a multifd sender thread hit errors, it always needs to kick the main
> thread by kicking all the semaphores that it can be waiting upon.
>
> Provide a helper for it and deduplicate the code.
>
> Signed-off-by: Peter Xu 
> ---
>  migration/multifd.c | 21 +++--
>  1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/migration/multifd.c b/migration/multifd.c
> index 4afdd88602..33fb21d0e4 100644
> --- a/migration/multifd.c
> +++ b/migration/multifd.c
> @@ -374,6 +374,18 @@ struct {
>  MultiFDMethods *ops;
>  } *multifd_send_state;
>  
> +/*
> + * The migration thread can wait on either of the two semaphores.  This
> + * function can be used to kick the main thread out of waiting on either of
> + * them.  Should mostly only be called when something wrong happened with
> + * the current multifd send thread.
> + */
> +static void multifd_send_kick_main(MultiFDSendParams *p)
> +{
> +qemu_sem_post(>sem_sync);
> +qemu_sem_post(_send_state->channels_ready);
> +}
> +
>  /*
>   * How we use multifd_send_state->pages and channel->pages?
>   *
> @@ -746,8 +758,7 @@ out:
>  assert(local_err);
>  trace_multifd_send_error(p->id);
>  multifd_send_terminate_threads(local_err);
> -qemu_sem_post(>sem_sync);
> -qemu_sem_post(_send_state->channels_ready);
> +multifd_send_kick_main(p);
>  error_free(local_err);
>  }
>  
> @@ -787,8 +798,7 @@ static void multifd_tls_outgoing_handshake(QIOTask *task,
>   * is not created, and then tell who pay attention to me.
>   */
>  p->quit = true;
> -qemu_sem_post(_send_state->channels_ready);
> -qemu_sem_post(>sem_sync);
> +multifd_send_kick_main(p);

There's a bug here in the original code:

It's not really safe to call any of these outside of the channel lock
because multifd_save_cleanup() could execute at the same time and call
qemu_sem_destroy() -> qemu_mutex_destroy(), which can assert because we
might be holding the sem_lock.

It seems the reason we get away with this today is merely due to
timing. A subset of this problem was already encountered here:

[PATCH] migrate/multifd: fix coredump when the multifd thread cleanup
https://lore.kernel.org/r/20230621081826.3203053-1-zhangjiangu...@huawei.com

We could probably release the semaphores for all channels at once inside
multifd_save_cleanup() in the main thread. We'd have a
multifd_send_kick_main() in each channel when it fails and this:

void multifd_save_cleanup(void)
{
...   
for (i = 0; i < migrate_multifd_channels(); i++) {
MultiFDSendParams *p = _send_state->params[i];

if (p->running) {
qemu_thread_join(>thread);
} else {
multifd_send_kick_main(p);
}
}
for (i = 0; i < migrate_multifd_channels(); i++) {
qemu_sem_destroy, etc...
}
...
}



[PATCH v3] hw/ide/ahci: fix legacy software reset

2023-11-08 Thread Niklas Cassel
From: Niklas Cassel 

Legacy software contains a standard mechanism for generating a reset to a
Serial ATA device - setting the SRST (software reset) bit in the Device
Control register.

Serial ATA has a more robust mechanism called COMRESET, also referred to
as port reset. A port reset is the preferred mechanism for error
recovery and should be used in place of software reset.

Commit e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
improved the handling of PxCI, such that PxCI gets cleared after handling
a non-NCQ, or NCQ command (instead of incorrectly clearing PxCI after
receiving anything - even a FIS that failed to parse, which should NOT
clear PxCI, so that you can see which command slot that caused an error).

However, simply clearing PxCI after a non-NCQ, or NCQ command, is not
enough, we also need to clear PxCI when receiving a SRST in the Device
Control register.

A legacy software reset is performed by the host sending two H2D FISes,
the first H2D FIS asserts SRST, and the second H2D FIS deasserts SRST.

The first H2D FIS will not get a D2H reply, and requires the FIS to have
the C bit set to one, such that the HBA itself will clear the bit in PxCI.

The second H2D FIS will get a D2H reply once the diagnostic is completed.
The clearing of the bit in PxCI for this command should ideally be done
in ahci_init_d2h() (if it was a legacy software reset that caused the
reset (a COMRESET does not use a command slot)). However, since the reset
value for PxCI is 0, modify ahci_reset_port() to actually clear PxCI to 0,
that way we can avoid complex logic in ahci_init_d2h().

This fixes an issue for FreeBSD where the device would fail to reset.
The problem was not noticed in Linux, because Linux uses a COMRESET
instead of a legacy software reset by default.

Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
Reported-by: Marcin Juszkiewicz 
Signed-off-by: Niklas Cassel 
---
Changes since v3: remove superfluous ahci_write_fis_d2h(), and add
comments describing how the (quite confusing) spec actually works.

 hw/ide/ahci.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
index fcc5476e9e..56c7672eb9 100644
--- a/hw/ide/ahci.c
+++ b/hw/ide/ahci.c
@@ -623,9 +623,13 @@ static void ahci_init_d2h(AHCIDevice *ad)
 return;
 }
 
+/*
+ * For simplicity, do not call ahci_clear_cmd_issue() for this
+ * ahci_write_fis_d2h(). (The reset value for PxCI is 0.)
+ */
 if (ahci_write_fis_d2h(ad, true)) {
 ad->init_d2h_sent = true;
-/* We're emulating receiving the first Reg H2D Fis from the device;
+/* We're emulating receiving the first Reg D2H FIS from the device;
  * Update the SIG register, but otherwise proceed as normal. */
 pr->sig = ((uint32_t)ide_state->hcyl << 24) |
 (ide_state->lcyl << 16) |
@@ -663,6 +667,7 @@ static void ahci_reset_port(AHCIState *s, int port)
 pr->scr_act = 0;
 pr->tfdata = 0x7F;
 pr->sig = 0x;
+pr->cmd_issue = 0;
 d->busy_slot = -1;
 d->init_d2h_sent = false;
 
@@ -1243,10 +1248,30 @@ static void handle_reg_h2d_fis(AHCIState *s, int port,
 case STATE_RUN:
 if (cmd_fis[15] & ATA_SRST) {
 s->dev[port].port_state = STATE_RESET;
+/*
+ * When setting SRST in the first H2D FIS in the reset 
sequence,
+ * the device does not send a D2H FIS. Host software thus has 
to
+ * set the "Clear Busy upon R_OK" bit such that PxCI (and BUSY)
+ * gets cleared. See AHCI 1.3.1, section 10.4.1 Software Reset.
+ */
+if (opts & AHCI_CMD_CLR_BUSY) {
+ahci_clear_cmd_issue(ad, slot);
+}
 }
 break;
 case STATE_RESET:
 if (!(cmd_fis[15] & ATA_SRST)) {
+/*
+ * When clearing SRST in the second H2D FIS in the reset
+ * sequence, the device will execute diagnostics. When this is
+ * done, the device will send a D2H FIS with the good status.
+ * See SATA 3.5a Gold, section 11.4 Software reset protocol.
+ *
+ * This D2H FIS is the first D2H FIS received from the device,
+ * and is received regardless if the reset was performed by a
+ * COMRESET or by setting and clearing the SRST bit. Therefore,
+ * the logic for this is found in ahci_init_d2h() and not here.
+ */
 ahci_reset_port(s, port);
 }
 break;
-- 
2.41.0




Re: [PATCH v5 0/2] Qemu crashes on VM migration after an handled memory error

2023-11-08 Thread Peter Xu
On Mon, Nov 06, 2023 at 10:03:17PM +, “William Roche wrote:
> From: William Roche 
> 
> 
> Note about ARM specificities:
> This code has a small part impacting more specificaly ARM machines,
> that's the reason why I added qemu-...@nongnu.org -- see description.
> 
> 
> A Qemu VM can survive a memory error, as qemu can relay the error to the
> VM kernel which could also deal with it -- poisoning/off-lining the impacted
> page.
> This situation creates a hole in the VM memory address space that the VM 
> kernel
> knows about (an unreadable page or set of pages).
> 
> But the migration of this VM (live migration through the network or
> pseudo-migration with the creation of a state file) will crash Qemu when
> it sequentially reads the memory address space and stumbles on the
> existing hole.
> 
> In order to thoroughly correct this problem, the poison information should
> follow the migration which represents several difficulties:
> - poisoning a page on the destination machine to replicate the source
>   poison requires CAP_SYS_ADMIN priviledges, and qemu process may not
>   always run as a root process
> - the destination kernel needs to be configured with CONFIG_MEMORY_FAILURE
> - the poison information would require a memory transfer protocol
>   enhancement to provide this information
> (The current patches don't provide any of that)
> 
> But if we rely on the fact that the a running VM kernel is correctly
> dealing with memory poison it is informed about: marking the poison page
> as inaccessible, we could count on the VM kernel to make sure that
> poisoned pages are not used, even after a migration.
> In this case, I suggest to treat the poisoned pages as if they were
> zero-pages for the migration copy.
> This fix also works with underlying large pages, taking into account the
> RAMBlock segment "page-size".
> 
> Now, it leaves a case that we have to deal with: if a memory error is
> reported to qemu but not injected into the running kernel...
> As the migration will go from a poisoned page to an all-zero page, if
> the VM kernel doesn't prevent the access to this page, a memory read
> that would generate a BUS_MCEERR_AR error on the source platform, could
> be reading zeros on the destination. This is a memory corruption.
> 
> So we have to ensure that all poisoned pages we set to zero are known by
> the running kernel. But we have a problem with platforms where BUS_MCEERR_AO
> errors are ignored, which means that qemu knows about the poison but the VM
> doesn't. For the moment it's only the case for ARM, but could later be
> also needed for AMD VMs.
> See https://lore.kernel.org/all/20230912211824.90952-3-john.al...@amd.com/
> 
> In order to avoid this possible silent data corruption situation, we should
> prevent the migration when we know that a poisoned page is ignored from the 
> VM.
> 
> Which is, according to me, the smallest fix we need  to avoid qemu crashes
> on migration after an handled memory error, without introducing a possible
> corruption situation.
> 
> This fix is scripts/checkpatch.pl clean.
> Unit test: Migration blocking succesfully tested on ARM -- injected AO error
> blocks it. On x86 the same type of error being relayed doesn't block.
> 
> v2:
>   - adding compressed transfer handling of poisoned pages
> 
> v3:
>   - Included the Reviewed-by and Tested-by information on first patch
>   - added a TODO comment above control_save_page()
> mentioning Zhijian's feedback about RDMA migration failure.
> 
> v4:
>   - adding a patch to deal with unknown poison tracking (impacting ARM)
> (not using migrate_add_blocker as this is not devices related and
> we want to avoid the interaction with --only-migratable mechanism)
> 
> v5:
>   - Updating the code to the latest version
>   - adding qemu-...@nongnu.org for a complementary review
> 
> 
> William Roche (2):
>   migration: skip poisoned memory pages on "ram saving" phase
>   migration: prevent migration when a poisoned page is unknown from the
> VM

I hope someone from arch-specific can have a quick look at patch 2..

One thing to mention is unfortunately waiting on patch 2 means we'll miss
this release. Actually it is already missed.. softfreeze yesterday [1].  So
it may likely need to wait for 9.0.

[1] https://wiki.qemu.org/Planning/8.2

-- 
Peter Xu




Re: [PATCH v4 2/2] migration: prevent migration when a poisoned page is unknown from the VM

2023-11-08 Thread Peter Xu
On Mon, Nov 06, 2023 at 10:38:14PM +0100, William Roche wrote:
> Note also that large pages are taken into account too for our live
> migration, but the poisoning of a qemu large page requires more work
> especially for VM using standard 4k pages on top of these qemu large
> pages -- and this is a completely different issue. I'm mentioning this
> aspect here because even on Intel platforms, underlying large pages
> poisoning needs to be reported better to the running VM as a large
> section of its memory is gone (not just a single head 4k page), and
> adding live migration to this problem will not make things any better...

Good point.. Yes, huge poisoned pages seem all broken.

> I did that in a self content test program: memory allocation,
> UFFDIO_REGISTER and use of UFFDIO_POISON.  The register mode has to be
> given but MISSING or WP both works. This gives the possibility to inject
> poison in a much easier and better way than using
> madvise(... MADV_HWPOISON, ...) for example.

Indeed, I should have left a comment if I noticed that when reviewing the
POISON changes; I overlooked that find_dst_vma(), even named like that,
will check the vma uffd context existed.  Doesn't really be necessary to
UFFDIO_POISON.

I can consider proposing a patch to allow that, which should be
trivial.. but it won't help with old kernels, so QEMU may still need to
better always register to make it always work as long as
UFFD_FEATURE_POISON reported.. sad.

> 
> But it implies a lot of other changes:
>     - The source has to flag the error pages to indicate a poison
>   (new flag in the exchange protocole)
>     - The destination has to be able to deal with the new protocole

IIUC these two can be simply implemented by migrating hwpoison_page_list
over to dest.  You need to have a compat bit for doing this, ignoring the
list on old machine types, because old QEMUs will not recognize this vmsd.

QEMU should even support migrating a list object in VMSD, feel free to have
a look at VMSTATE_QLIST_V().

>     - The destination has to be able to mark the pages as poisoned
>   (authorized to use userfaultfd)

Note: userfaultfd is actually available without any privilege if to use
UFFDIO_POISON only, as long as to open the uffd (either via syscall or
/dev/userfaultfd) using UFFD_FLAG_USER_ONLY.

A trick is we can register with UFFD_WP mode (not MISSING; because when a
kernel accesses a missing page it'll cause SIGBUS then with USER_ONLY),
then inject whatever POISON we want.  As long as UFFDIO_WRITEPROTECT is not
invoked, UFFD_WP does nothing (unlike MISSING).

>     - So both source and destination have to be upgraded (of course
>   qemu but also an appropriate kernel version providing
>   UFFDIO_POISON on the destination)

True.  Unfortunately this is not avoidable.

>     - we may need to be able to negotiate a fall back solution
>     - an indication of the method to use could belong to the
>   migration capabilities and parameters

For above two points: it's a common issue with migration compatibility.  As
long as you can provide above VMSD to migrate hwpoison_page_list, marking
all old QEMU machine types skipping that, then it should just work.

You can have a closer look at anything in hw_compat_* as an example.

>     - etc...

I think you did summarize mostly all the points I can think of; is there
really anything more? :)

It'll be great if you can, or plan to, fix that for good.

Thanks,

-- 
Peter Xu




Re: [PATCH v2 27/35] tcg/ppc: Support TCG_COND_TST{EQ,NE}

2023-11-08 Thread Richard Henderson

On 11/8/23 12:40, Philippe Mathieu-Daudé wrote:

Hi Richard,

On 28/10/23 21:45, Richard Henderson wrote:

Signed-off-by: Richard Henderson 
---
  tcg/ppc/tcg-target.c.inc | 105 ---
  1 file changed, 98 insertions(+), 7 deletions(-)




-static inline void tcg_out_rld(TCGContext *s, int op, TCGReg ra, TCGReg rs,
-   int sh, int mb)
+static void tcg_out_rld_rc(TCGContext *s, int op, TCGReg ra, TCGReg rs,
+   int sh, int mb, bool rc)
  {
  tcg_debug_assert(TCG_TARGET_REG_BITS == 64);
  sh = SH(sh & 0x1f) | (((sh >> 5) & 1) << 1);
  mb = MB64((mb >> 5) | ((mb << 1) & 0x3f));
-    tcg_out32(s, op | RA(ra) | RS(rs) | sh | mb);
+    tcg_out32(s, op | RA(ra) | RS(rs) | sh | mb | rc);
  }
-static inline void tcg_out_rlw(TCGContext *s, int op, TCGReg ra, TCGReg rs,
-   int sh, int mb, int me)
+static void tcg_out_rld(TCGContext *s, int op, TCGReg ra, TCGReg rs,
+    int sh, int mb)
+{
+    tcg_out_rld_rc(s, op, ra, rs, sh, mb, false);
+}
+
+static void tcg_out_rlw_rc(TCGContext *s, int op, TCGReg ra, TCGReg rs,
+   int sh, int mb, int me, bool rc)
  {
  tcg_out32(s, op | RA(ra) | RS(rs) | SH(sh) | MB(mb) | ME(me));


Here I'm a bit confused because 'rc' is not used. Shouldn't we OR it
to tcg_out32()' second argument?


Yep, should be just like rld_rc above.


r~



Re: [PATCH] block-backend: per-device throttling of BLOCK_IO_ERROR reports

2023-11-08 Thread Eric Blake
On Tue, Nov 07, 2023 at 11:58:42AM +0300, Vladimir Sementsov-Ogievskiy wrote:
> From: Leonid Kaplan 
> 
> BLOCK_IO_ERROR events comes from guest, so we must throttle them.
> We still want per-device throttling, so let's use device id as a key.
> 
> Signed-off-by: Leonid Kaplan 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  monitor/monitor.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/monitor/monitor.c b/monitor/monitor.c
> index 01ede1babd..ad0243e9d7 100644
> --- a/monitor/monitor.c
> +++ b/monitor/monitor.c
> @@ -309,6 +309,7 @@ int error_printf_unless_qmp(const char *fmt, ...)
>  static MonitorQAPIEventConf monitor_qapi_event_conf[QAPI_EVENT__MAX] = {
>  /* Limit guest-triggerable events to 1 per second */
>  [QAPI_EVENT_RTC_CHANGE]= { 1000 * SCALE_MS },
> +[QAPI_EVENT_BLOCK_IO_ERROR]= { 1000 * SCALE_MS },
>  [QAPI_EVENT_WATCHDOG]  = { 1000 * SCALE_MS },
>  [QAPI_EVENT_BALLOON_CHANGE]= { 1000 * SCALE_MS },
>  [QAPI_EVENT_QUORUM_REPORT_BAD] = { 1000 * SCALE_MS },
> @@ -498,6 +499,10 @@ static unsigned int qapi_event_throttle_hash(const void 
> *key)
>  hash += g_str_hash(qdict_get_str(evstate->data, "qom-path"));
>  }
>  
> +if (evstate->event == QAPI_EVENT_BLOCK_IO_ERROR) {
> +hash += g_str_hash(qdict_get_str(evstate->data, "device"));

Wouldn't ^= be better than += for combining hashes?

> +}
> +
>  return hash;
>  }
>  
> @@ -525,6 +530,11 @@ static gboolean qapi_event_throttle_equal(const void *a, 
> const void *b)
> qdict_get_str(evb->data, "qom-path"));
>  }
>  
> +if (eva->event == QAPI_EVENT_BLOCK_IO_ERROR) {
> +return !strcmp(qdict_get_str(eva->data, "device"),
> +   qdict_get_str(evb->data, "device"));
> +}
> +

At any rate, the idea makes sense for me.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org




Re: [PATCH for-8.2] target/sparc: Fix RETURN

2023-11-08 Thread Philippe Mathieu-Daudé

On 8/11/23 21:47, Richard Henderson wrote:

Perform window restore before pc update. Required in order
to recognize any window underflow trap with the current pc.

Fixes: 86b82fe021f4 ("target/sparc: Move JMPL, RETT, RETURN to decodetree")
Reported-by: Mark Cave-Ayland 
Signed-off-by: Richard Henderson 
---
  target/sparc/translate.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index 6fc333a6b8..9387299559 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -4096,12 +4096,12 @@ TRANS(RETT, 32, do_add_special, a, do_rett)
  static bool do_return(DisasContext *dc, int rd, TCGv src)
  {
  gen_check_align(dc, src, 3);
+gen_helper_restore(tcg_env);
  
  gen_mov_pc_npc(dc);

  tcg_gen_mov_tl(cpu_npc, src);
  gen_address_mask(dc, cpu_npc);
  
-gen_helper_restore(tcg_env);


Ahah! I noticed that earlier in a late review, wondered why you moved
that gen_helper_restore() call after updating $nPC, but my SPARC is now
rusty so I was sure I was missing something. Too shy to ask :/

Reviewed-by: Philippe Mathieu-Daudé 


  dc->npc = DYNAMIC_PC_LOOKUP;
  return true;
  }





Re: [PATCH v2 34/35] target/alpha: Use TCG_COND_TSTNE for gen_fold_mzero

2023-11-08 Thread Philippe Mathieu-Daudé

On 28/10/23 21:45, Richard Henderson wrote:

Signed-off-by: Richard Henderson 
---
  target/alpha/translate.c | 49 +++-
  1 file changed, 23 insertions(+), 26 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index c7daf46de7..c68c2bcd21 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -490,56 +490,53 @@ static DisasJumpType gen_bcond(DisasContext *ctx, TCGCond 
cond, int ra,
  
  /* Fold -0.0 for comparison with COND.  */
  
-static void gen_fold_mzero(TCGCond cond, TCGv dest, TCGv src)

+static TCGv_i64 gen_fold_mzero(TCGCond *pcond, uint64_t *pimm, TCGv_i64 src)
  {
-uint64_t mzero = 1ull << 63;
+TCGv_i64 tmp;
  
-switch (cond) {

+*pimm = 0;
+switch (*pcond) {
  case TCG_COND_LE:
  case TCG_COND_GT:
  /* For <= or >, the -0.0 value directly compares the way we want.  */
-tcg_gen_mov_i64(dest, src);
-break;
+return src;
  
  case TCG_COND_EQ:

  case TCG_COND_NE:
-/* For == or !=, we can simply mask off the sign bit and compare.  */
-tcg_gen_andi_i64(dest, src, mzero - 1);
-break;
+/* For == or !=, we can compare without the sign bit. */



+*pcond = *pcond == TCG_COND_EQ ? TCG_COND_TSTEQ : TCG_COND_TSTNE;


OK, $subject is only this line, the rest is purely refactoring.

Reviewed-by: Philippe Mathieu-Daudé 


+*pimm = INT64_MAX;
+return src;
  
  case TCG_COND_GE:

  case TCG_COND_LT:
  /* For >= or <, map -0.0 to +0.0. */
-tcg_gen_movcond_i64(TCG_COND_NE, dest, src, tcg_constant_i64(mzero),
-src, tcg_constant_i64(0));
-break;
+tmp = tcg_temp_new_i64();
+tcg_gen_movcond_i64(TCG_COND_EQ, tmp,
+src, tcg_constant_i64(INT64_MIN),
+tcg_constant_i64(0), src);
+return tmp;
  
  default:

-abort();
+g_assert_not_reached();
  }
  }





Re: [PATCH v2 20/35] tcg/sparc64: Hoist read of tcg_cond_to_rcond

2023-11-08 Thread Richard Henderson

On 11/6/23 13:02, Philippe Mathieu-Daudé wrote:

On 28/10/23 21:45, Richard Henderson wrote:

Use a non-zero value here (an illegal encoding) as a better
condition than is_unsigned_cond for when MOVR/BPR is usable.

Signed-off-by: Richard Henderson 
---
  tcg/sparc64/tcg-target.c.inc | 25 ++---
  1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/tcg/sparc64/tcg-target.c.inc b/tcg/sparc64/tcg-target.c.inc
index ac86b92b75..e16b25e309 100644
--- a/tcg/sparc64/tcg-target.c.inc
+++ b/tcg/sparc64/tcg-target.c.inc
@@ -620,7 +620,7 @@ static const uint8_t tcg_cond_to_bcond[] = {
  [TCG_COND_GTU] = COND_GU,
  };
-static const uint8_t tcg_cond_to_rcond[] = {
+static const uint8_t tcg_cond_to_rcond[16] = {




-static void tcg_out_movr(TCGContext *s, TCGCond cond, TCGReg ret, TCGReg c1,
+static void tcg_out_movr(TCGContext *s, int rcond, TCGReg ret, TCGReg c1,


Isn't rcond unsigned?


Yes, though it is in [0-7], so it doesn't matter.


r~



Re: [RFC PATCH] tests/docker: merge debian-native with debian-amd64

2023-11-08 Thread Anders Roxell
On Wed, 8 Nov 2023 at 17:56, Alex Bennée  wrote:
>
> debian-native isn't really needed and suffers from the problem of
> tracking a distros dependencies rather than the projects. With a
> little surgery we can make the debian-amd64 container architecture
> neutral and allow people to use it to build a native QEMU.
>
> Rename it so it follows the same non-arch pattern of the other distro
> containers.
>
> Signed-off-by: Alex Bennée 
> Cc: Anders Roxell 

I tried it on my arm machine and it worked as expected.
And this should work for me

Tested-by: Anders Roxell 

Cheers,
Anders

> ---
>  .gitlab-ci.d/buildtest.yml| 12 ++---
>  .gitlab-ci.d/containers.yml   |  2 +-
>  tests/docker/Makefile.include |  3 --
>  tests/docker/dockerfiles/debian-native.docker | 54 ---
>  .../{debian-amd64.docker => debian.docker}|  7 ++-
>  tests/lcitool/refresh |  9 ++--
>  6 files changed, 18 insertions(+), 69 deletions(-)
>  delete mode 100644 tests/docker/dockerfiles/debian-native.docker
>  rename tests/docker/dockerfiles/{debian-amd64.docker => debian.docker} (96%)
>
> diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
> index da72f7c690..7f9af83b10 100644
> --- a/.gitlab-ci.d/buildtest.yml
> +++ b/.gitlab-ci.d/buildtest.yml
> @@ -70,7 +70,7 @@ build-system-debian:
>needs:
>  job: amd64-debian-container
>variables:
> -IMAGE: debian-amd64
> +IMAGE: debian
>  CONFIGURE_ARGS: --with-coroutine=sigaltstack
>  TARGETS: arm-softmmu i386-softmmu riscv64-softmmu sh4eb-softmmu
>sparc-softmmu xtensa-softmmu
> @@ -82,7 +82,7 @@ check-system-debian:
>  - job: build-system-debian
>artifacts: true
>variables:
> -IMAGE: debian-amd64
> +IMAGE: debian
>  MAKE_CHECK_ARGS: check
>
>  avocado-system-debian:
> @@ -91,7 +91,7 @@ avocado-system-debian:
>  - job: build-system-debian
>artifacts: true
>variables:
> -IMAGE: debian-amd64
> +IMAGE: debian
>  MAKE_CHECK_ARGS: check-avocado
>  AVOCADO_TAGS: arch:arm arch:i386 arch:riscv64 arch:sh4 arch:sparc 
> arch:xtensa
>
> @@ -101,7 +101,7 @@ crash-test-debian:
>  - job: build-system-debian
>artifacts: true
>variables:
> -IMAGE: debian-amd64
> +IMAGE: debian
>script:
>  - cd build
>  - make NINJA=":" check-venv
> @@ -589,7 +589,7 @@ build-tools-and-docs-debian:
>  # when running on 'master' we use pre-existing container
>  optional: true
>variables:
> -IMAGE: debian-amd64
> +IMAGE: debian
>  MAKE_CHECK_ARGS: check-unit ctags TAGS cscope
>  CONFIGURE_ARGS: --disable-system --disable-user --enable-docs 
> --enable-tools
>  QEMU_JOB_PUBLISH: 1
> @@ -609,7 +609,7 @@ build-tools-and-docs-debian:
>  # of what topic branch they're currently using
>  pages:
>extends: .base_job_template
> -  image: $CI_REGISTRY_IMAGE/qemu/debian-amd64:$QEMU_CI_CONTAINER_TAG
> +  image: $CI_REGISTRY_IMAGE/qemu/debian:$QEMU_CI_CONTAINER_TAG
>stage: test
>needs:
>  - job: build-tools-and-docs-debian
> diff --git a/.gitlab-ci.d/containers.yml b/.gitlab-ci.d/containers.yml
> index 8637a13d86..ae79d4c58b 100644
> --- a/.gitlab-ci.d/containers.yml
> +++ b/.gitlab-ci.d/containers.yml
> @@ -11,7 +11,7 @@ amd64-debian-container:
>extends: .container_job_template
>stage: containers
>variables:
> -NAME: debian-amd64
> +NAME: debian
>
>  amd64-ubuntu2204-container:
>extends: .container_job_template
> diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
> index cd4688bf07..5ba5b50ab9 100644
> --- a/tests/docker/Makefile.include
> +++ b/tests/docker/Makefile.include
> @@ -88,9 +88,6 @@ DOCKER_PARTIAL_IMAGES += debian-s390x-cross
>  DOCKER_PARTIAL_IMAGES += fedora
>  endif
>
> -# The native build should never use the registry
> -docker-image-debian-native: DOCKER_REGISTRY=
> -
>  # alpine has no adduser
>  docker-image-alpine: NOUSER=1
>
> diff --git a/tests/docker/dockerfiles/debian-native.docker 
> b/tests/docker/dockerfiles/debian-native.docker
> deleted file mode 100644
> index abac7d7cd7..00
> --- a/tests/docker/dockerfiles/debian-native.docker
> +++ /dev/null
> @@ -1,54 +0,0 @@
> -#
> -# Docker Debian Native
> -#
> -# This is intended to build QEMU on native host systems. Debian is
> -# chosen due to the broadest range on supported host systems for QEMU.
> -#
> -# This docker target is based on the docker.io Debian Bullseye base
> -# image rather than QEMU's base because we would otherwise confuse the
> -# build grabbing stuff from the registry built for other
> -# architectures.
> -#
> -FROM docker.io/library/debian:bullseye-slim
> -MAINTAINER Alex Bennée 
> -
> -# Duplicate deb line as deb-src
> -RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> 
> /etc/apt/sources.list
> -
> -# Install common build utilities
> -RUN apt update && \
> -DEBIAN_FRONTEND=noninteractive apt install 

Re: [PATCH v2 32/35] target/alpha: Use TCG_COND_TST{EQ,NE} for BLB{C,S}

2023-11-08 Thread Philippe Mathieu-Daudé

On 28/10/23 21:45, Richard Henderson wrote:

Signed-off-by: Richard Henderson 
---
  target/alpha/translate.c | 39 ---
  1 file changed, 16 insertions(+), 23 deletions(-)


Preferably split:
Reviewed-by: Philippe Mathieu-Daudé 




Re: [PATCH v2 32/35 1/2] target/alpha: Pass immediate value to gen_bcond_internal()

2023-11-08 Thread Philippe Mathieu-Daudé

On 8/11/23 21:52, Philippe Mathieu-Daudé wrote:

From: Richard Henderson 

Simplify gen_bcond() by passing an immediate value.

Signed-off-by: Richard Henderson 
Message-Id: <20231028194522.245170-33-richard.hender...@linaro.org>
[PMD: Split from bigger patch, part 1/2]
Signed-off-by: Philippe Mathieu-Daudé 
---
  target/alpha/translate.c | 21 +++--
  1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 32333081d8..46efe1df7c 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -453,13 +453,13 @@ static DisasJumpType gen_bdirect(DisasContext *ctx, int 
ra, int32_t disp)
  }
  
  static DisasJumpType gen_bcond_internal(DisasContext *ctx, TCGCond cond,

-TCGv cmp, int32_t disp)
+TCGv cmp, uint64_t imm, int32_t disp)
  {
  uint64_t dest = ctx->base.pc_next + (disp << 2);
  TCGLabel *lab_true = gen_new_label();
  
  if (use_goto_tb(ctx, dest)) {

-tcg_gen_brcondi_i64(cond, cmp, 0, lab_true);
+tcg_gen_brcondi_i64(cond, cmp, imm, lab_true);
  
  tcg_gen_goto_tb(0);

  tcg_gen_movi_i64(cpu_pc, ctx->base.pc_next);
@@ -472,11 +472,11 @@ static DisasJumpType gen_bcond_internal(DisasContext 
*ctx, TCGCond cond,
  
  return DISAS_NORETURN;

  } else {
-TCGv_i64 z = load_zero(ctx);
+TCGv_i64 i = tcg_constant_i64(imm);
  TCGv_i64 d = tcg_constant_i64(dest);
  TCGv_i64 p = tcg_constant_i64(ctx->base.pc_next);
  
-tcg_gen_movcond_i64(cond, cpu_pc, cmp, z, d, p);

+tcg_gen_movcond_i64(cond, cpu_pc, cmp, i, d, p);
  return DISAS_PC_UPDATED;
  }
  }
@@ -484,15 +484,8 @@ static DisasJumpType gen_bcond_internal(DisasContext *ctx, 
TCGCond cond,
  static DisasJumpType gen_bcond(DisasContext *ctx, TCGCond cond, int ra,
 int32_t disp, int mask)
  {
-if (mask) {
-TCGv tmp = tcg_temp_new();
-DisasJumpType ret;
-
-tcg_gen_andi_i64(tmp, load_gpr(ctx, ra), 1);
-ret = gen_bcond_internal(ctx, cond, tmp, disp);
-return ret;
-}
-return gen_bcond_internal(ctx, cond, load_gpr(ctx, ra), disp);
+return gen_bcond_internal(ctx, cond, load_gpr(ctx, ra),
+  !!mask, disp);


Hmm we can pass 'mask' directly.


  }
  
  /* Fold -0.0 for comparison with COND.  */

@@ -533,7 +526,7 @@ static DisasJumpType gen_fbcond(DisasContext *ctx, TCGCond 
cond, int ra,
  DisasJumpType ret;
  
  gen_fold_mzero(cond, cmp_tmp, load_fpr(ctx, ra));

-ret = gen_bcond_internal(ctx, cond, cmp_tmp, disp);
+ret = gen_bcond_internal(ctx, cond, cmp_tmp, 0, disp);
  return ret;
  }
  





Re: [PATCH v2 33/35] target/alpha: Use TCG_COND_TST{EQ,NE} for CMOVLB{C,S}

2023-11-08 Thread Philippe Mathieu-Daudé

On 28/10/23 21:45, Richard Henderson wrote:

Signed-off-by: Richard Henderson 
---
  target/alpha/translate.c | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 




[PATCH v2 32/35 2/2] target/alpha: Use TCG_COND_TST{EQ, NE} for BLB{C, S}

2023-11-08 Thread Philippe Mathieu-Daudé
From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20231028194522.245170-33-richard.hender...@linaro.org>
[PMD: Split from bigger patch, part 2/2]
Signed-off-by: Philippe Mathieu-Daudé 
---
 target/alpha/translate.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 46efe1df7c..49e6a7b62d 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -482,10 +482,10 @@ static DisasJumpType gen_bcond_internal(DisasContext 
*ctx, TCGCond cond,
 }
 
 static DisasJumpType gen_bcond(DisasContext *ctx, TCGCond cond, int ra,
-   int32_t disp, int mask)
+   int32_t disp)
 {
 return gen_bcond_internal(ctx, cond, load_gpr(ctx, ra),
-  !!mask, disp);
+  is_tst_cond(cond), disp);
 }
 
 /* Fold -0.0 for comparison with COND.  */
@@ -2820,35 +2820,35 @@ static DisasJumpType translate_one(DisasContext *ctx, 
uint32_t insn)
 break;
 case 0x38:
 /* BLBC */
-ret = gen_bcond(ctx, TCG_COND_EQ, ra, disp21, 1);
+ret = gen_bcond(ctx, TCG_COND_TSTEQ, ra, disp21);
 break;
 case 0x39:
 /* BEQ */
-ret = gen_bcond(ctx, TCG_COND_EQ, ra, disp21, 0);
+ret = gen_bcond(ctx, TCG_COND_EQ, ra, disp21);
 break;
 case 0x3A:
 /* BLT */
-ret = gen_bcond(ctx, TCG_COND_LT, ra, disp21, 0);
+ret = gen_bcond(ctx, TCG_COND_LT, ra, disp21);
 break;
 case 0x3B:
 /* BLE */
-ret = gen_bcond(ctx, TCG_COND_LE, ra, disp21, 0);
+ret = gen_bcond(ctx, TCG_COND_LE, ra, disp21);
 break;
 case 0x3C:
 /* BLBS */
-ret = gen_bcond(ctx, TCG_COND_NE, ra, disp21, 1);
+ret = gen_bcond(ctx, TCG_COND_TSTNE, ra, disp21);
 break;
 case 0x3D:
 /* BNE */
-ret = gen_bcond(ctx, TCG_COND_NE, ra, disp21, 0);
+ret = gen_bcond(ctx, TCG_COND_NE, ra, disp21);
 break;
 case 0x3E:
 /* BGE */
-ret = gen_bcond(ctx, TCG_COND_GE, ra, disp21, 0);
+ret = gen_bcond(ctx, TCG_COND_GE, ra, disp21);
 break;
 case 0x3F:
 /* BGT */
-ret = gen_bcond(ctx, TCG_COND_GT, ra, disp21, 0);
+ret = gen_bcond(ctx, TCG_COND_GT, ra, disp21);
 break;
 invalid_opc:
 ret = gen_invalid(ctx);
-- 
2.41.0




[PATCH v2 32/35 1/2] target/alpha: Pass immediate value to gen_bcond_internal()

2023-11-08 Thread Philippe Mathieu-Daudé
From: Richard Henderson 

Simplify gen_bcond() by passing an immediate value.

Signed-off-by: Richard Henderson 
Message-Id: <20231028194522.245170-33-richard.hender...@linaro.org>
[PMD: Split from bigger patch, part 1/2]
Signed-off-by: Philippe Mathieu-Daudé 
---
 target/alpha/translate.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/target/alpha/translate.c b/target/alpha/translate.c
index 32333081d8..46efe1df7c 100644
--- a/target/alpha/translate.c
+++ b/target/alpha/translate.c
@@ -453,13 +453,13 @@ static DisasJumpType gen_bdirect(DisasContext *ctx, int 
ra, int32_t disp)
 }
 
 static DisasJumpType gen_bcond_internal(DisasContext *ctx, TCGCond cond,
-TCGv cmp, int32_t disp)
+TCGv cmp, uint64_t imm, int32_t disp)
 {
 uint64_t dest = ctx->base.pc_next + (disp << 2);
 TCGLabel *lab_true = gen_new_label();
 
 if (use_goto_tb(ctx, dest)) {
-tcg_gen_brcondi_i64(cond, cmp, 0, lab_true);
+tcg_gen_brcondi_i64(cond, cmp, imm, lab_true);
 
 tcg_gen_goto_tb(0);
 tcg_gen_movi_i64(cpu_pc, ctx->base.pc_next);
@@ -472,11 +472,11 @@ static DisasJumpType gen_bcond_internal(DisasContext 
*ctx, TCGCond cond,
 
 return DISAS_NORETURN;
 } else {
-TCGv_i64 z = load_zero(ctx);
+TCGv_i64 i = tcg_constant_i64(imm);
 TCGv_i64 d = tcg_constant_i64(dest);
 TCGv_i64 p = tcg_constant_i64(ctx->base.pc_next);
 
-tcg_gen_movcond_i64(cond, cpu_pc, cmp, z, d, p);
+tcg_gen_movcond_i64(cond, cpu_pc, cmp, i, d, p);
 return DISAS_PC_UPDATED;
 }
 }
@@ -484,15 +484,8 @@ static DisasJumpType gen_bcond_internal(DisasContext *ctx, 
TCGCond cond,
 static DisasJumpType gen_bcond(DisasContext *ctx, TCGCond cond, int ra,
int32_t disp, int mask)
 {
-if (mask) {
-TCGv tmp = tcg_temp_new();
-DisasJumpType ret;
-
-tcg_gen_andi_i64(tmp, load_gpr(ctx, ra), 1);
-ret = gen_bcond_internal(ctx, cond, tmp, disp);
-return ret;
-}
-return gen_bcond_internal(ctx, cond, load_gpr(ctx, ra), disp);
+return gen_bcond_internal(ctx, cond, load_gpr(ctx, ra),
+  !!mask, disp);
 }
 
 /* Fold -0.0 for comparison with COND.  */
@@ -533,7 +526,7 @@ static DisasJumpType gen_fbcond(DisasContext *ctx, TCGCond 
cond, int ra,
 DisasJumpType ret;
 
 gen_fold_mzero(cond, cmp_tmp, load_fpr(ctx, ra));
-ret = gen_bcond_internal(ctx, cond, cmp_tmp, disp);
+ret = gen_bcond_internal(ctx, cond, cmp_tmp, 0, disp);
 return ret;
 }
 
-- 
2.41.0




[PATCH for-8.2] target/sparc: Fix RETURN

2023-11-08 Thread Richard Henderson
Perform window restore before pc update. Required in order
to recognize any window underflow trap with the current pc.

Fixes: 86b82fe021f4 ("target/sparc: Move JMPL, RETT, RETURN to decodetree")
Reported-by: Mark Cave-Ayland 
Signed-off-by: Richard Henderson 
---
 target/sparc/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/sparc/translate.c b/target/sparc/translate.c
index 6fc333a6b8..9387299559 100644
--- a/target/sparc/translate.c
+++ b/target/sparc/translate.c
@@ -4096,12 +4096,12 @@ TRANS(RETT, 32, do_add_special, a, do_rett)
 static bool do_return(DisasContext *dc, int rd, TCGv src)
 {
 gen_check_align(dc, src, 3);
+gen_helper_restore(tcg_env);
 
 gen_mov_pc_npc(dc);
 tcg_gen_mov_tl(cpu_npc, src);
 gen_address_mask(dc, cpu_npc);
 
-gen_helper_restore(tcg_env);
 dc->npc = DYNAMIC_PC_LOOKUP;
 return true;
 }
-- 
2.34.1




Re: [PATCH v2 27/35] tcg/ppc: Support TCG_COND_TST{EQ,NE}

2023-11-08 Thread Philippe Mathieu-Daudé

Hi Richard,

On 28/10/23 21:45, Richard Henderson wrote:

Signed-off-by: Richard Henderson 
---
  tcg/ppc/tcg-target.c.inc | 105 ---
  1 file changed, 98 insertions(+), 7 deletions(-)




-static inline void tcg_out_rld(TCGContext *s, int op, TCGReg ra, TCGReg rs,
-   int sh, int mb)
+static void tcg_out_rld_rc(TCGContext *s, int op, TCGReg ra, TCGReg rs,
+   int sh, int mb, bool rc)
  {
  tcg_debug_assert(TCG_TARGET_REG_BITS == 64);
  sh = SH(sh & 0x1f) | (((sh >> 5) & 1) << 1);
  mb = MB64((mb >> 5) | ((mb << 1) & 0x3f));
-tcg_out32(s, op | RA(ra) | RS(rs) | sh | mb);
+tcg_out32(s, op | RA(ra) | RS(rs) | sh | mb | rc);
  }
  
-static inline void tcg_out_rlw(TCGContext *s, int op, TCGReg ra, TCGReg rs,

-   int sh, int mb, int me)
+static void tcg_out_rld(TCGContext *s, int op, TCGReg ra, TCGReg rs,
+int sh, int mb)
+{
+tcg_out_rld_rc(s, op, ra, rs, sh, mb, false);
+}
+
+static void tcg_out_rlw_rc(TCGContext *s, int op, TCGReg ra, TCGReg rs,
+   int sh, int mb, int me, bool rc)
  {
  tcg_out32(s, op | RA(ra) | RS(rs) | SH(sh) | MB(mb) | ME(me));


Here I'm a bit confused because 'rc' is not used. Shouldn't we OR it
to tcg_out32()' second argument?


  }
  
+static void tcg_out_rlw(TCGContext *s, int op, TCGReg ra, TCGReg rs,

+int sh, int mb, int me)
+{
+tcg_out_rlw_rc(s, op, ra, rs, sh, mb, me, false);
+}





Re: [NOTFORMERGE PATCH 1/2] configure: Use distrib meson

2023-11-08 Thread BALATON Zoltan

On Wed, 8 Nov 2023, Peter Maydell wrote:

On Wed, 8 Nov 2023 at 18:33, Philippe Mathieu-Daudé  wrote:


Signed-off-by: Philippe Mathieu-Daudé 
---
 configure | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/configure b/configure
index f1456f6123..93735b7661 100755
--- a/configure
+++ b/configure
@@ -955,15 +955,8 @@ if $python -c 'import sys; sys.exit(sys.version_info >= 
(3,11))'; then
 $mkvenv ensure --dir "${source_path}/python/wheels" \
 'tomli>=1.2.0' || exit 1
 fi
-$mkvenv ensuregroup --dir "${source_path}/python/wheels" \
- ${source_path}/pythondeps.toml meson || exit 1

-# At this point, we expect Meson to be installed and available.
-# We expect mkvenv or pip to have created pyvenv/bin/meson for us.
-# We ignore PATH completely here: we want to use the venv's Meson
-# *exclusively*.
-
-meson="$(cd pyvenv/bin; pwd)/meson"
+meson="$(which meson)"


Doesn't this revert 66e2c6cbace ?


Presumably the other approach would be to make the pythondeps.toml
say "on macos we need at least version X of meson" ?

Do we know what the upstream meson issue is that we're running into
with the older version on this host ?


Linked from the QEMU ticket in the cover letter:
https://github.com/mesonbuild/meson/issues/12399

AFAIU the problem is that macOS has system python in 
/Library/Frameworks/python.framework (or something like that) but homebrew 
does not use that but installs its own python somewhere in /opt and meson 
from homebrew uses that python but configure finds the system python which 
does not have meson so it then downloads its own meson but that's too old 
for macOS Sonoma. It should probably check for homebrew or macports 
locations too or check for meson and get the python that's using. A 
workaround apparently is to pass --python with the right path to 
configure.


Regards,
BALATON Zoltan

Re: [PATCH v9 5/5] amd_iommu: report x2APIC support to the operating system

2023-11-08 Thread Michael S. Tsirkin
On Wed, Nov 08, 2023 at 09:22:18PM +0700, Bui Quang Minh wrote:
> On 11/7/23 07:39, Michael S. Tsirkin wrote:
> > On Tue, Oct 24, 2023 at 10:21:05PM +0700, Bui Quang Minh wrote:
> > > This commit adds XTSup configuration to let user choose to whether enable
> > > this feature or not. When XTSup is enabled, additional bytes in IRTE with
> > > enabled guest virtual VAPIC are used to support 32-bit destination id.
> > > 
> > > Additionally, this commit exports IVHD type 0x11 besides the old IVHD type
> > > 0x10 in ACPI table. IVHD type 0x10 does not report full set of IOMMU
> > > features only the legacy ones, so operating system (e.g. Linux) may only
> > > detects x2APIC support if IVHD type 0x11 is available. The IVHD type 0x10
> > > is kept so that old operating system that only parses type 0x10 can detect
> > > the IOMMU device.
> > > 
> > > Reviewed-by: Michael S. Tsirkin 
> > > Signed-off-by: Bui Quang Minh 
> > 
> > 
> > changes IVRS without updating expected files for tests.
> > result seems to be CI failures:
> > https://gitlab.com/mstredhat/qemu/-/jobs/5470533834
> 
> 
> Thanks Michael, I am preparing the fix in the next version. I've read the
> instructions to update the test data in bios-tables-test.c. It says I need
> to create some separate patches to update the test data. Are there any
> reasons for this? I intend to change the binary and include the ASL diff
> into the commit message. Is it enough?

No, not enough.  No, do not ignore the rules please.  Yes, there's a
reason.  The reason is that I need to be able to rebase your patches.  I
then regenerate the binaries. If the patch includes binaries it won't
rebase.




Invitation to comment on Virtual I/O Device (VIRTIO) Version 1.3 - ends December 8th

2023-11-08 Thread Paul Knight
OASIS members and other interested parties,

OASIS and the OASIS Virtual I/O Device (VIRTIO) TC are pleased to announce
that Virtual I/O Device (VIRTIO) Version 1.3 is now available for public
review and comment.

Specification Overview:

This document describes the specifications of the 'virtio' family of
devices. These devices are found in virtual environments, yet by design
they look like physical devices to the guest within the virtual machine -
and this document treats them as such. This similarity allows the guest to
use standard drivers and discovery mechanisms. The purpose of virtio and
this specification is that virtual environments and guests should have a
straightforward, efficient, standard and extensible mechanism for virtual
devices, rather than boutique per-environment or per-OS mechanisms.

The documents and related files are available here:

Virtual I/O Device (VIRTIO) Version 1.3
Committee Specification Draft 01
06 October 2023

Editable source (Authoritative):
https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/tex/
HTML:
https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html
PDF:
https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.pdf
Example driver listing:
https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/listings/
PDF file marked to indicate changes from Version 1.2 Committee
Specification 01:
https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01-diff-from-v1.2-cs01.pdf

For your convenience, OASIS provides a complete package of the
specification document and any related files in ZIP distribution files. You
can download the ZIP file at:
https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.zip

A public review metadata record documenting this and any previous public
reviews is available at:
https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01-public-review-metadata.html

How to Provide Feedback

OASIS and the OASIS Virtual I/O Device (VIRTIO) TC value your feedback. We
solicit input from developers, users and others, whether OASIS members or
not, for the sake of improving the interoperability and quality of its
technical work.

The public review starts 09 November 2023 at 00:00 UTC and ends 08 December
2023 at 23:59 UTC.

Comments may be submitted to the TC by any person through the use of the
OASIS TC Comment Facility which can be used by following the instructions
on the TC's "Send A Comment" page (
https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio).

Comments submitted by TC non-members for this work and for other work of
this TC are publicly archived and can be viewed at:

https://lists.oasis-open.org/archives/virtio-comment/

All comments submitted to OASIS are subject to the OASIS Feedback License,
which ensures that the feedback you provide carries the same obligations at
least as the obligations of the TC members. In connection with this public
review, we call your attention to the OASIS IPR Policy [1] applicable
especially [2] to the work of this technical committee. All members of the
TC should be familiar with this document, which may create obligations
regarding the disclosure and availability of a member's patent, copyright,
trademark and license rights that read on an approved OASIS specification.

OASIS invites any persons who know of any such claims to disclose these if
they may be essential to the implementation of the above specification, so
that notice of them may be posted to the notice page for this TC's work.

Additional information about the specification and the VIRTIO TC can be
found at the TC's public home page:
https://www.oasis-open.org/committees/virtio/

== Additional references:

[1] https://www.oasis-open.org/policies-guidelines/ipr/

[2] https://github.com/oasis-tcs/virtio-admin/blob/master/IPR.md
https://www.oasis-open.org/policies-guidelines/ipr/#Non-Assertion-Mode
Non-Assertion Mode
-- 
Paul Knight Document Process Analyst

OASIS ...Setting the standard for open
collaboration


Re: [NOTFORMERGE PATCH 1/2] configure: Use distrib meson

2023-11-08 Thread Peter Maydell
On Wed, 8 Nov 2023 at 18:33, Philippe Mathieu-Daudé  wrote:
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  configure | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/configure b/configure
> index f1456f6123..93735b7661 100755
> --- a/configure
> +++ b/configure
> @@ -955,15 +955,8 @@ if $python -c 'import sys; sys.exit(sys.version_info >= 
> (3,11))'; then
>  $mkvenv ensure --dir "${source_path}/python/wheels" \
>  'tomli>=1.2.0' || exit 1
>  fi
> -$mkvenv ensuregroup --dir "${source_path}/python/wheels" \
> - ${source_path}/pythondeps.toml meson || exit 1
>
> -# At this point, we expect Meson to be installed and available.
> -# We expect mkvenv or pip to have created pyvenv/bin/meson for us.
> -# We ignore PATH completely here: we want to use the venv's Meson
> -# *exclusively*.
> -
> -meson="$(cd pyvenv/bin; pwd)/meson"
> +meson="$(which meson)"

Presumably the other approach would be to make the pythondeps.toml
say "on macos we need at least version X of meson" ?

Do we know what the upstream meson issue is that we're running into
with the older version on this host ?

thanks
-- PMM



Re: [PATCH v1 9/9] target/loongarch: Add loongarch kvm into meson build

2023-11-08 Thread Richard Henderson

On 11/7/23 17:41, xianglai li wrote:

From: Tianrui Zhao 

Add kvm.c and kvm-stub.c into meson.build to compile
it when kvm is configed. Meanwhile in meson.build,
we set the kvm_targets to loongarch64-softmmu when
the cpu is loongarch.

Signed-off-by: Tianrui Zhao 
Signed-off-by: xianglai li 
---
  meson.build  | 2 ++
  target/loongarch/meson.build | 1 +
  2 files changed, 3 insertions(+)


Reviewed-by: Richard Henderson 


r~



Re: [RFC PATCH] tests/docker: merge debian-native with debian-amd64

2023-11-08 Thread Alex Bennée
Philippe Mathieu-Daudé  writes:

> On 8/11/23 17:56, Alex Bennée wrote:
>> debian-native isn't really needed and suffers from the problem of
>> tracking a distros dependencies rather than the projects. With a
>> little surgery we can make the debian-amd64 container architecture
>> neutral and allow people to use it to build a native QEMU.
>> Rename it so it follows the same non-arch pattern of the other
>> distro
>> containers.
>> Signed-off-by: Alex Bennée 
>> Cc: Anders Roxell 
>> ---
>>   .gitlab-ci.d/buildtest.yml| 12 ++---
>>   .gitlab-ci.d/containers.yml   |  2 +-
>>   tests/docker/Makefile.include |  3 --
>>   tests/docker/dockerfiles/debian-native.docker | 54 ---
>>   .../{debian-amd64.docker => debian.docker}|  7 ++-
>>   tests/lcitool/refresh |  9 ++--
>>   6 files changed, 18 insertions(+), 69 deletions(-)
>>   delete mode 100644 tests/docker/dockerfiles/debian-native.docker
>>   rename tests/docker/dockerfiles/{debian-amd64.docker => debian.docker} 
>> (96%)
>
> Good idea. Why RFC?

Well mostly to see if it is usable for Ander's as a generic build env
for QEMU builds for tuxbuild images.

>
> Reviewed-by: Philippe Mathieu-Daudé 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



Re: [SeaBIOS] [PATCH v5] limit physical address space size

2023-11-08 Thread Kevin O'Connor
On Tue, Nov 07, 2023 at 02:03:09PM +0100, Gerd Hoffmann wrote:
> For better compatibility with old linux kernels,
> see source code comment.
> 
> Related (same problem in ovmf):
> https://github.com/tianocore/edk2/commit/c1e853769046

Thanks.  I'll defer to your judgement on this.  It does seem a little
odd to alter the CPUPhysBits variable itself instead of adding
additional checking to the pciinit.c code that uses CPUPhysBits.
(That is, if there are old Linux kernels that can't handle a very high
PCI space, then a workaround in the PCI code might make it more clear
what is occurring.)

Cheers,
-Kevin


> 
> Cc: Claudio Fontana 
> Signed-off-by: Gerd Hoffmann 
> ---
>  src/fw/paravirt.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/src/fw/paravirt.c b/src/fw/paravirt.c
> index e5d4eca0cb5a..a2c9c64d5e78 100644
> --- a/src/fw/paravirt.c
> +++ b/src/fw/paravirt.c
> @@ -182,6 +182,14 @@ static void physbits(int qemu_quirk)
>  __func__, signature, pae ? "yes" : "no", CPULongMode ? "yes" : 
> "no",
>  physbits, valid ? "yes" : "no");
>  
> +if (valid && physbits > 46) {
> +// Old linux kernels have trouble dealing with more than 46
> +// phys-bits, so avoid that for now.  Seems to be a bug in the
> +// virtio-pci driver.  Reported: centos-7, ubuntu-18.04
> +dprintf(1, "%s: using phys-bits=46 (old linux kernel 
> compatibility)\n", __func__);
> +physbits = 46;
> +}
> +
>  if (valid)
>  CPUPhysBits = physbits;
>  }
> -- 
> 2.41.0
> 
> ___
> SeaBIOS mailing list -- seab...@seabios.org
> To unsubscribe send an email to seabios-le...@seabios.org



[PATCH 2/2] .gitlab-ci.d/cirrus: Add manual testing of macOS 14 (Sonoma)

2023-11-08 Thread Philippe Mathieu-Daudé
Upgrade libvirt-ci so it covers macOS 14. Add a manual entry
(QEMU_JOB_OPTIONAL: 1) to test on Sonoma release. Refresh the
lci-tool generated files.

Signed-off-by: Philippe Mathieu-Daudé 
---
Docs are disabled due to:

  Collecting sphinx
Downloading sphinx-7.2.6-py3-none-any.whl.metadata (5.9 kB)
  Collecting sphinx-rtd-theme
Downloading sphinx_rtd_theme-1.3.0-py2.py3-none-any.whl.metadata (4.5 kB)
  ...
  Installing collected packages ...
  ...
  python determined to be '/opt/homebrew/bin/python3'
  python version: Python 3.11.6
  mkvenv: Creating non-isolated virtual environment at 'pyvenv'
  mkvenv: checking for sphinx>=1.6
  mkvenv: checking for sphinx_rtd_theme>=0.5
  ...
  Program /opt/homebrew/opt/python@3.12/bin/sphinx-build found: NO
  ../docs/meson.build:1:15: ERROR: Program 
'/opt/homebrew/opt/python@3.12/bin/sphinx-build' not found or not executable

¯\_(ツ)_/¯
---
 .gitlab-ci.d/cirrus.yml   | 17 +
 .gitlab-ci.d/cirrus/macos-14.vars | 16 
 tests/lcitool/libvirt-ci  |  2 +-
 tests/lcitool/refresh |  1 +
 4 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 .gitlab-ci.d/cirrus/macos-14.vars

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 07dc6edae1..84ce143509 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -74,6 +74,23 @@ aarch64-macos-13-base-build:
 PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
 TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
 
+aarch64-macos-14-base-build:
+  extends: .cirrus_build_job
+  variables:
+NAME: macos-14
+CIRRUS_VM_INSTANCE_TYPE: macos_instance
+CIRRUS_VM_IMAGE_SELECTOR: image
+CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-sonoma-base:latest
+CIRRUS_VM_CPUS: 12
+CIRRUS_VM_RAM: 24G
+UPDATE_COMMAND: brew update
+INSTALL_COMMAND: brew install
+PATH_EXTRA: /opt/homebrew/ccache/libexec:/opt/homebrew/gettext/bin
+PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
+TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
+QEMU_JOB_OPTIONAL: 1
+CONFIGURE_ARGS: --disable-docs
+
 
 # The following jobs run VM-based tests via KVM on a Linux-based Cirrus-CI job
 .cirrus_kvm_job:
diff --git a/.gitlab-ci.d/cirrus/macos-14.vars 
b/.gitlab-ci.d/cirrus/macos-14.vars
new file mode 100644
index 00..43070f4a26
--- /dev/null
+++ b/.gitlab-ci.d/cirrus/macos-14.vars
@@ -0,0 +1,16 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool variables macos-14 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
+CCACHE='/opt/homebrew/bin/ccache'
+CPAN_PKGS=''
+CROSS_PKGS=''
+MAKE='/opt/homebrew/bin/gmake'
+NINJA='/opt/homebrew/bin/ninja'
+PACKAGING_COMMAND='brew'
+PIP3='/opt/homebrew/bin/pip3'
+PKGS='bash bc bison bzip2 capstone ccache cmocka ctags curl dbus diffutils dtc 
flex gcovr gettext git glib gnu-sed gnutls gtk+3 jemalloc jpeg-turbo json-c 
libepoxy libffi libgcrypt libiscsi libnfs libpng libslirp libssh libtasn1 
libusb llvm lzo make meson mtools ncurses nettle ninja pixman pkg-config 
python3 rpm2cpio sdl2 sdl2_image snappy socat sparse spice-protocol swtpm 
tesseract usbredir vde vte3 xorriso zlib zstd'
+PYPI_PKGS='PyYAML numpy pillow sphinx sphinx-rtd-theme tomli'
+PYTHON='/opt/homebrew/bin/python3'
diff --git a/tests/lcitool/libvirt-ci b/tests/lcitool/libvirt-ci
index 36bc517161..77c800186f 16
--- a/tests/lcitool/libvirt-ci
+++ b/tests/lcitool/libvirt-ci
@@ -1 +1 @@
-Subproject commit 36bc517161c45ead20224d47f2dc4fa428af6724
+Subproject commit 77c800186f34b21be7660750577cc5582a914deb
diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index 2259f131b4..e11d0ba381 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -197,6 +197,7 @@ try:
 #
 generate_cirrus("freebsd-13")
 generate_cirrus("macos-13")
+generate_cirrus("macos-14")
 
 #
 # VM packages lists
-- 
2.41.0




[NOTFORMERGE PATCH 1/2] configure: Use distrib meson

2023-11-08 Thread Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé 
---
 configure | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/configure b/configure
index f1456f6123..93735b7661 100755
--- a/configure
+++ b/configure
@@ -955,15 +955,8 @@ if $python -c 'import sys; sys.exit(sys.version_info >= 
(3,11))'; then
 $mkvenv ensure --dir "${source_path}/python/wheels" \
 'tomli>=1.2.0' || exit 1
 fi
-$mkvenv ensuregroup --dir "${source_path}/python/wheels" \
- ${source_path}/pythondeps.toml meson || exit 1
 
-# At this point, we expect Meson to be installed and available.
-# We expect mkvenv or pip to have created pyvenv/bin/meson for us.
-# We ignore PATH completely here: we want to use the venv's Meson
-# *exclusively*.
-
-meson="$(cd pyvenv/bin; pwd)/meson"
+meson="$(which meson)"
 
 # Conditionally ensure Sphinx is installed.
 
-- 
2.41.0




[RFC PATCH 0/2] buildsys: Use host meson on macOS Sonoma (14)

2023-11-08 Thread Philippe Mathieu-Daudé
macOS 14 "Sonoma" was released end of September 2023,
developers who upgraded they host can not build QEMU
anymore due to some issue with meson, described in
https://gitlab.com/qemu-project/qemu/-/issues/1939
(mkvenv ignore the host meson and forces to use the
old meson 0.63.3, which doesn't work on Sonoma).

I have no clue how to fix this meson issue, but I put
these 2 patches to keep testing Sonoma out-of-tree
during the release freeze window.

Successful build:
https://gitlab.com/philmd/qemu/-/jobs/5491256155

Based-on: <20231108162022.76189-1-phi...@linaro.org>
  .gitlab-ci.d/cirrus: Upgrade macOS to 13 (Ventura)
  https://lore.kernel.org/qemu-devel/20231108162022.76189-1-phi...@linaro.org/

Philippe Mathieu-Daudé (2):
  configure: Use distrib meson on macOS
  .gitlab-ci.d/cirrus: Add manual testing of macOS 14 (Sonoma)

 configure |  9 +
 .gitlab-ci.d/cirrus.yml   | 17 +
 .gitlab-ci.d/cirrus/macos-14.vars | 16 
 tests/lcitool/libvirt-ci  |  2 +-
 tests/lcitool/refresh |  1 +
 5 files changed, 36 insertions(+), 9 deletions(-)
 create mode 100644 .gitlab-ci.d/cirrus/macos-14.vars

-- 
2.41.0




Re: [PATCH v2 14/35] tcg/i386: Support TCG_COND_TST{EQ,NE}

2023-11-08 Thread Philippe Mathieu-Daudé

On 28/10/23 21:45, Richard Henderson wrote:

Merge tcg_out_testi into tcg_out_cmp and adjust the two uses.

Signed-off-by: Richard Henderson 
---
  tcg/i386/tcg-target.c.inc | 83 ++-
  1 file changed, 47 insertions(+), 36 deletions(-)




  #if TCG_TARGET_REG_BITS == 64
@@ -1422,15 +1424,35 @@ static void tcg_out_jxx(TCGContext *s, int opc, 
TCGLabel *l, bool small)
  static int tcg_out_cmp(TCGContext *s, TCGCond cond, TCGArg arg1,
 TCGArg arg2, int const_arg2, int rexw)
  {
-if (const_arg2) {
-if (arg2 == 0) {
-/* test r, r */
-tcg_out_modrm(s, OPC_TESTL + rexw, arg1, arg1);
+if (is_tst_cond(cond)) {
+if (!const_arg2) {
+tcg_out_modrm(s, OPC_TESTL + rexw, arg1, arg2);
+} else if (arg2 <= 0xff && (TCG_TARGET_REG_BITS == 64 || arg1 < 4)) {
+tcg_out_modrm(s, OPC_GRP3_Eb | P_REXB_RM, EXT3_TESTi, arg1);
+tcg_out8(s, arg2);
+} else if ((arg2 & ~0xff00) == 0 && arg1 < 4) {
+tcg_out_modrm(s, OPC_GRP3_Eb, EXT3_TESTi, arg1 + 4);
+tcg_out8(s, arg2 >> 8);
  } else {


For this part, a double-review from x86 developer is welcomed,


-tgen_arithi(s, ARITH_CMP + rexw, arg1, arg2, 0);
+if (rexw) {
+if (arg2 == (uint32_t)arg2) {
+rexw = 0;
+} else {
+tcg_debug_assert(arg2 == (int32_t)arg2);
+}
+}
+tcg_out_modrm(s, OPC_GRP3_Ev + rexw, EXT3_TESTi, arg1);
+tcg_out32(s, arg2);
  }
  } else {


then the rest is OK.

Reviewed-by: Philippe Mathieu-Daudé 




Re: [PATCH v2 11/35 2/2] tcg/arm: Support TCG_COND_TST{EQ,NE}

2023-11-08 Thread Philippe Mathieu-Daudé

On 8/11/23 15:52, Philippe Mathieu-Daudé wrote:

From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20231028194522.245170-12-richard.hender...@linaro.org>
[PMD: Split from bigger patch, part 2/2]
Signed-off-by: Philippe Mathieu-Daudé 
---
  tcg/arm/tcg-target.c.inc | 29 -
  1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/tcg/arm/tcg-target.c.inc b/tcg/arm/tcg-target.c.inc
index 66d71af8bf..0fc7273b16 100644
--- a/tcg/arm/tcg-target.c.inc
+++ b/tcg/arm/tcg-target.c.inc
@@ -1194,7 +1194,27 @@ static void tcg_out_mb(TCGContext *s, TCGArg a0)
  static TCGCond tcg_out_cmp(TCGContext *s, TCGCond cond, TCGReg a,
 TCGArg b, int b_const)
  {
-tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0, a, b, b_const);
+if (!is_tst_cond(cond)) {
+tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0, a, b, b_const);
+return cond;
+}
+
+cond = tcg_tst_eqne_cond(cond);
+if (b_const) {
+int imm12 = encode_imm(b);
+
+/*
+ * The compare constraints allow rIN, but TST does not support N.
+ * Be prepared to load the constant into a scratch register.
+ */
+if (imm12 >= 0) {
+tcg_out_dat_imm(s, COND_AL, ARITH_TST, 0, a, imm12);
+return cond;
+}
+tcg_out_movi32(s, COND_AL, TCG_REG_TMP, b);
+b = TCG_REG_TMP;
+}
+tcg_out_dat_reg(s, COND_AL, ARITH_TST, 0, a, b, SHIFT_IMM_LSL(0));
  return cond;
  }


To the best of my knowledge,

Reviewed-by: Philippe Mathieu-Daudé 




Re: [PATCH v6 1/4] qom: add default value

2023-11-08 Thread Philippe Mathieu-Daudé

On 8/11/23 16:38, Maksim Davydov wrote:

qmp_qom_list_properties can print default values if they are available
as qmp_device_list_properties does, because both of them use the
ObjectPropertyInfo structure with default_value field. This can be useful
when working with "not device" types (e.g. memory-backend).

Signed-off-by: Maksim Davydov 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
  qom/qom-qmp-cmds.c | 1 +
  1 file changed, 1 insertion(+)


Reviewed-by: Philippe Mathieu-Daudé 




Re: [PATCH] host/include/generic/host/atomic128: Fix compilation problem with Clang 17

2023-11-08 Thread Richard Henderson

On 11/8/23 00:59, Thomas Huth wrote:

When compiling QEMU with Clang 17 on a s390x, the compilation fails:

In file included from ../accel/tcg/cputlb.c:32:
In file included from /root/qemu/include/exec/helper-proto-common.h:10:
In file included from /root/qemu/include/qemu/atomic128.h:62:
/root/qemu/host/include/generic/host/atomic128-ldst.h:68:15: error:
  __sync builtin operation MUST have natural alignment (consider using __
atomic). [-Werror,-Wsync-alignment]
68 | } while (!__sync_bool_compare_and_swap_16(ptr_align, old, new.i));
   |   ^
In file included from ../accel/tcg/cputlb.c:32:
In file included from /root/qemu/include/exec/helper-proto-common.h:10:
In file included from /root/qemu/include/qemu/atomic128.h:61:
/root/qemu/host/include/generic/host/atomic128-cas.h:36:11: error:
  __sync builtin operation MUST have natural alignment (consider using __a
tomic). [-Werror,-Wsync-alignment]
36 | r.i = __sync_val_compare_and_swap_16(ptr_align, c.i, n.i);
   |   ^
2 errors generated.

It's arguably a bug in Clang since we already use __builtin_assume_aligned()
to tell the compiler that the pointer is properly aligned. But according to
https://github.com/llvm/llvm-project/issues/69146 it seems like the Clang
folks don't see an easy fix on their side and recommend to use a type
declared with __attribute__((aligned(16))) to work around this problem.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1934
Signed-off-by: Thomas Huth 
---
  host/include/generic/host/atomic128-cas.h  | 2 +-
  host/include/generic/host/atomic128-ldst.h | 2 +-
  include/qemu/int128.h  | 1 +
  3 files changed, 3 insertions(+), 2 deletions(-)


Reviewed-by: Richard Henderson 


r~



Re: [PATCH v6 3/4] python: add binary

2023-11-08 Thread Philippe Mathieu-Daudé

Hi Maksim,

On 8/11/23 16:38, Maksim Davydov wrote:

Add a supportive property to access the path to the qemu binary

Signed-off-by: Maksim Davydov 
---
  python/qemu/machine/machine.py | 5 +
  1 file changed, 5 insertions(+)

diff --git a/python/qemu/machine/machine.py b/python/qemu/machine/machine.py
index 31cb9d617d..78436403b2 100644
--- a/python/qemu/machine/machine.py
+++ b/python/qemu/machine/machine.py
@@ -328,6 +328,11 @@ def args(self) -> List[str]:
  """Returns the list of arguments given to the QEMU binary."""
  return self._args
  
+@property

+def binary(self) -> str:
+"""Returns path to the qemu binary"""


s/qemu/QEMU/ (like 2 lines earlier).

Otherwise,

Reviewed-by: Philippe Mathieu-Daudé 


+return self._binary
+
  def _pre_launch(self) -> None:
  if self._qmp_set:
  if self._monitor_address is None:





Re: [RFC PATCH] tests/docker: merge debian-native with debian-amd64

2023-11-08 Thread Philippe Mathieu-Daudé

On 8/11/23 17:56, Alex Bennée wrote:

debian-native isn't really needed and suffers from the problem of
tracking a distros dependencies rather than the projects. With a
little surgery we can make the debian-amd64 container architecture
neutral and allow people to use it to build a native QEMU.

Rename it so it follows the same non-arch pattern of the other distro
containers.

Signed-off-by: Alex Bennée 
Cc: Anders Roxell 
---
  .gitlab-ci.d/buildtest.yml| 12 ++---
  .gitlab-ci.d/containers.yml   |  2 +-
  tests/docker/Makefile.include |  3 --
  tests/docker/dockerfiles/debian-native.docker | 54 ---
  .../{debian-amd64.docker => debian.docker}|  7 ++-
  tests/lcitool/refresh |  9 ++--
  6 files changed, 18 insertions(+), 69 deletions(-)
  delete mode 100644 tests/docker/dockerfiles/debian-native.docker
  rename tests/docker/dockerfiles/{debian-amd64.docker => debian.docker} (96%)


Good idea. Why RFC?

Reviewed-by: Philippe Mathieu-Daudé 




Re: [PATCH] MAINTAINERS: Fix a couple s390 paths

2023-11-08 Thread Halil Pasic
On Fri, 20 Oct 2023 16:15:09 +0200
Eric Farman  wrote:

> : Fri, 20 Oct 2023 16:15:09 +0200
> X-Mailer: git-send-email 2.39.2
> 
> These are simple typos, since the directories don't exist but the
> files themselves do in hw/s390x/
> 
> Fixes: 56e3483402 ("MAINTAINERS: split out s390x sections")
> Signed-off-by: Eric Farman 
Reviewed-by:  Halil Pasic 



Re: [PATCH] .gitlab-ci.d/cirrus: Upgrade macOS to 13 (Ventura)

2023-11-08 Thread Alex Bennée
Philippe Mathieu-Daudé  writes:

> macOS 14 "Sonoma" was released on September 2023 [1].
>
> According to QEMU's support policy, we stop supporting the
> previous major release two years after the the new major
> release has been published. Replace the macOS 12 (Monterey)
> testing by macOS 13 (Ventura, released on October 2022, [2]).
>
> Refresh the generated files by running:

Queued to for-8.2/random-fixes, thanks.

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



[PULL v2 00/25] Block layer patches

2023-11-08 Thread Kevin Wolf
The following changes since commit 462ad017ed76889d46696a3581e1b52343f9b683:

  Merge tag 'pixman-pull-request' of https://gitlab.com/marcandre.lureau/qemu 
into staging (2023-11-07 19:00:03 +0800)

are available in the Git repository at:

  https://repo.or.cz/qemu/kevin.git tags/for-upstream

for you to fetch changes up to b523a3d54f3d031a54cd0931cc5d855608e63140:

  hw/ide/ahci: trigger either error IRQ or regular IRQ, not both (2023-11-08 
17:56:18 +0100)


Block layer patches

- Graph locking part 6 (bs->file/backing)
- ahci: trigger either error IRQ or regular IRQ, not both


Kevin Wolf (24):
  block: Mark bdrv_probe_blocksizes() and callers GRAPH_RDLOCK
  block: Mark bdrv_has_zero_init() and callers GRAPH_RDLOCK
  block: Mark bdrv_filter_bs() and callers GRAPH_RDLOCK
  block: Mark bdrv_root_attach_child() GRAPH_WRLOCK
  block: Mark block_job_add_bdrv() GRAPH_WRLOCK
  block: Mark bdrv_filter_or_cow_bs() and callers GRAPH_RDLOCK
  block: Mark bdrv_skip_implicit_filters() and callers GRAPH_RDLOCK
  block: Mark bdrv_skip_filters() and callers GRAPH_RDLOCK
  block: Mark bdrv_(un)freeze_backing_chain() and callers GRAPH_RDLOCK
  block: Mark bdrv_chain_contains() and callers GRAPH_RDLOCK
  block: Mark bdrv_filter_child() and callers GRAPH_RDLOCK
  block: Mark bdrv_cow_child() and callers GRAPH_RDLOCK
  block: Mark bdrv_set_backing_hd_drained() GRAPH_WRLOCK
  block: Inline bdrv_set_backing_noperm()
  block: Mark bdrv_replace_node_common() GRAPH_WRLOCK
  block: Mark bdrv_replace_node() GRAPH_WRLOCK
  block: Protect bs->backing with graph_lock
  blkverify: Add locking for request_fn
  block: Introduce bdrv_co_change_backing_file()
  block: Add missing GRAPH_RDLOCK annotations
  qcow2: Take locks for accessing bs->file
  vhdx: Take locks for accessing bs->file
  block: Take graph lock for most of .bdrv_open
  block: Protect bs->file with graph_lock

Niklas Cassel (1):
  hw/ide/ahci: trigger either error IRQ or regular IRQ, not both

 block/copy-on-read.h   |   3 +-
 block/parallels.h  |   5 +-
 block/qcow2.h  |  59 +-
 block/qed.h|   2 +-
 block/vhdx.h   |   9 +-
 include/block/block-global-state.h |  43 
 include/block/block-io.h   |  10 +-
 include/block/block_int-common.h   |  31 +++---
 include/block/block_int-global-state.h |  16 +--
 include/block/block_int-io.h   |  19 ++--
 include/block/blockjob.h   |   5 +-
 include/block/blockjob_int.h   |   9 +-
 block.c| 192 +++--
 block/backup.c |  21 ++--
 block/blkdebug.c   |  29 ++---
 block/blkreplay.c  |   8 +-
 block/blkverify.c  |  18 ++--
 block/block-backend.c  |   5 +
 block/block-copy.c |  11 +-
 block/bochs.c  |   4 +
 block/cloop.c  |   4 +
 block/commit.c |  32 +-
 block/copy-before-write.c  |   6 +-
 block/copy-on-read.c   |  19 +++-
 block/crypto.c |  10 ++
 block/dmg.c|  21 ++--
 block/filter-compress.c|   5 +-
 block/io.c |   2 +
 block/mirror.c |  88 ++-
 block/monitor/block-hmp-cmds.c |   3 +
 block/parallels-ext.c  |  21 ++--
 block/parallels.c  |  22 ++--
 block/preallocate.c|  27 +++--
 block/qcow.c   |  13 ++-
 block/qcow2-bitmap.c   |  14 +--
 block/qcow2-cluster.c  |  25 ++---
 block/qcow2.c  | 148 +
 block/qed.c|  88 ---
 block/raw-format.c |  36 ---
 block/replication.c|  12 ++-
 block/snapshot-access.c|   5 +-
 block/stream.c |  48 ++---
 block/throttle.c   |   3 +
 block/vdi.c|  15 ++-
 block/vhdx-log.c   |  40 +++
 block/vhdx.c   |  37 ---
 block/vmdk.c   |  23 ++--
 block/vpc.c|   6 +-
 blockdev.c |  72 -
 blockjob.c |   6 +-
 hw/ide/ahci.c  |   5 +-
 migration/block-dirty-bitmap.c |   4 +
 nbd/server.c   |   6 ++
 qemu-img.c |  31 --
 

[RFC PATCH] tests/docker: merge debian-native with debian-amd64

2023-11-08 Thread Alex Bennée
debian-native isn't really needed and suffers from the problem of
tracking a distros dependencies rather than the projects. With a
little surgery we can make the debian-amd64 container architecture
neutral and allow people to use it to build a native QEMU.

Rename it so it follows the same non-arch pattern of the other distro
containers.

Signed-off-by: Alex Bennée 
Cc: Anders Roxell 
---
 .gitlab-ci.d/buildtest.yml| 12 ++---
 .gitlab-ci.d/containers.yml   |  2 +-
 tests/docker/Makefile.include |  3 --
 tests/docker/dockerfiles/debian-native.docker | 54 ---
 .../{debian-amd64.docker => debian.docker}|  7 ++-
 tests/lcitool/refresh |  9 ++--
 6 files changed, 18 insertions(+), 69 deletions(-)
 delete mode 100644 tests/docker/dockerfiles/debian-native.docker
 rename tests/docker/dockerfiles/{debian-amd64.docker => debian.docker} (96%)

diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index da72f7c690..7f9af83b10 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -70,7 +70,7 @@ build-system-debian:
   needs:
 job: amd64-debian-container
   variables:
-IMAGE: debian-amd64
+IMAGE: debian
 CONFIGURE_ARGS: --with-coroutine=sigaltstack
 TARGETS: arm-softmmu i386-softmmu riscv64-softmmu sh4eb-softmmu
   sparc-softmmu xtensa-softmmu
@@ -82,7 +82,7 @@ check-system-debian:
 - job: build-system-debian
   artifacts: true
   variables:
-IMAGE: debian-amd64
+IMAGE: debian
 MAKE_CHECK_ARGS: check
 
 avocado-system-debian:
@@ -91,7 +91,7 @@ avocado-system-debian:
 - job: build-system-debian
   artifacts: true
   variables:
-IMAGE: debian-amd64
+IMAGE: debian
 MAKE_CHECK_ARGS: check-avocado
 AVOCADO_TAGS: arch:arm arch:i386 arch:riscv64 arch:sh4 arch:sparc 
arch:xtensa
 
@@ -101,7 +101,7 @@ crash-test-debian:
 - job: build-system-debian
   artifacts: true
   variables:
-IMAGE: debian-amd64
+IMAGE: debian
   script:
 - cd build
 - make NINJA=":" check-venv
@@ -589,7 +589,7 @@ build-tools-and-docs-debian:
 # when running on 'master' we use pre-existing container
 optional: true
   variables:
-IMAGE: debian-amd64
+IMAGE: debian
 MAKE_CHECK_ARGS: check-unit ctags TAGS cscope
 CONFIGURE_ARGS: --disable-system --disable-user --enable-docs 
--enable-tools
 QEMU_JOB_PUBLISH: 1
@@ -609,7 +609,7 @@ build-tools-and-docs-debian:
 # of what topic branch they're currently using
 pages:
   extends: .base_job_template
-  image: $CI_REGISTRY_IMAGE/qemu/debian-amd64:$QEMU_CI_CONTAINER_TAG
+  image: $CI_REGISTRY_IMAGE/qemu/debian:$QEMU_CI_CONTAINER_TAG
   stage: test
   needs:
 - job: build-tools-and-docs-debian
diff --git a/.gitlab-ci.d/containers.yml b/.gitlab-ci.d/containers.yml
index 8637a13d86..ae79d4c58b 100644
--- a/.gitlab-ci.d/containers.yml
+++ b/.gitlab-ci.d/containers.yml
@@ -11,7 +11,7 @@ amd64-debian-container:
   extends: .container_job_template
   stage: containers
   variables:
-NAME: debian-amd64
+NAME: debian
 
 amd64-ubuntu2204-container:
   extends: .container_job_template
diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index cd4688bf07..5ba5b50ab9 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -88,9 +88,6 @@ DOCKER_PARTIAL_IMAGES += debian-s390x-cross
 DOCKER_PARTIAL_IMAGES += fedora
 endif
 
-# The native build should never use the registry
-docker-image-debian-native: DOCKER_REGISTRY=
-
 # alpine has no adduser
 docker-image-alpine: NOUSER=1
 
diff --git a/tests/docker/dockerfiles/debian-native.docker 
b/tests/docker/dockerfiles/debian-native.docker
deleted file mode 100644
index abac7d7cd7..00
--- a/tests/docker/dockerfiles/debian-native.docker
+++ /dev/null
@@ -1,54 +0,0 @@
-#
-# Docker Debian Native
-#
-# This is intended to build QEMU on native host systems. Debian is
-# chosen due to the broadest range on supported host systems for QEMU.
-#
-# This docker target is based on the docker.io Debian Bullseye base
-# image rather than QEMU's base because we would otherwise confuse the
-# build grabbing stuff from the registry built for other
-# architectures.
-#
-FROM docker.io/library/debian:bullseye-slim
-MAINTAINER Alex Bennée 
-
-# Duplicate deb line as deb-src
-RUN cat /etc/apt/sources.list | sed "s/^deb\ /deb-src /" >> 
/etc/apt/sources.list
-
-# Install common build utilities
-RUN apt update && \
-DEBIAN_FRONTEND=noninteractive apt install -yy eatmydata
-
-RUN apt update && \
-DEBIAN_FRONTEND=noninteractive eatmydata \
-apt build-dep -yy --arch-only qemu
-
-RUN apt update && \
-DEBIAN_FRONTEND=noninteractive eatmydata \
-apt install -y --no-install-recommends \
-cscope \
-genisoimage \
-exuberant-ctags \
-global \
-libbz2-dev \
-liblzo2-dev \
-libgcrypt20-dev \
-libfdt-dev \
-

Re: [PATCH] .gitlab-ci.d/cirrus: Upgrade macOS to 13 (Ventura)

2023-11-08 Thread Daniel P . Berrangé
On Wed, Nov 08, 2023 at 05:20:22PM +0100, Philippe Mathieu-Daudé wrote:
> macOS 14 "Sonoma" was released on September 2023 [1].
> 
> According to QEMU's support policy, we stop supporting the
> previous major release two years after the the new major
> release has been published. Replace the macOS 12 (Monterey)
> testing by macOS 13 (Ventura, released on October 2022, [2]).
> 
> Refresh the generated files by running:
> 
>   $ make lcitool-refresh
> 
> [1] https://www.apple.com/newsroom/2023/09/macos-sonoma-is-available-today/
> [2] https://www.apple.com/newsroom/2022/10/macos-ventura-is-now-available/
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  .gitlab-ci.d/cirrus.yml  | 6 +++---
>  .gitlab-ci.d/cirrus/{macos-12.vars => macos-13.vars} | 2 +-
>  tests/lcitool/refresh| 2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>  rename .gitlab-ci.d/cirrus/{macos-12.vars => macos-13.vars} (95%)

Reviewed-by: Daniel P. Berrangé 


With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|




[PATCH] risu: Add test summary

2023-11-08 Thread Sebastian Mitterle
Currently, a successful test run finishes silently with exit code 0.
The last message on the console is "starting image" which can leave
the user wondering if they executed the commands correctly.

Now add a summary of the number of executed instructions in case
of success. Don't add that message when printing the trace to
stdout (`-t -`).

Tested:
a) master/apprentice mode
b) trace mode to file
c) trace mode to stdout

Suggested-by: Thomas Huth 
Signed-off-by: Sebastian Mitterle 
---
 risu.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/risu.c b/risu.c
index 36fc82a..740663a 100644
--- a/risu.c
+++ b/risu.c
@@ -551,6 +551,7 @@ int main(int argc, char **argv)
 struct option *longopts;
 char *shortopts;
 stack_t ss;
+int ret;
 
 longopts = setup_options();
 
@@ -635,8 +636,15 @@ int main(int argc, char **argv)
 arch_init();
 
 if (ismaster) {
-return master();
+ret = master();
 } else {
-return apprentice();
+ret = apprentice();
 }
+
+if (ret == EXIT_SUCCESS && (!trace || (trace  && strcmp(trace_fn, "-") != 
0))) {
+fprintf(stderr, "No mismatches found. Executed %zd checkpoints.\n",
+signal_count);
+}
+
+return ret;
 }
-- 
2.41.0




[PATCH] .gitlab-ci.d/cirrus: Upgrade macOS to 13 (Ventura)

2023-11-08 Thread Philippe Mathieu-Daudé
macOS 14 "Sonoma" was released on September 2023 [1].

According to QEMU's support policy, we stop supporting the
previous major release two years after the the new major
release has been published. Replace the macOS 12 (Monterey)
testing by macOS 13 (Ventura, released on October 2022, [2]).

Refresh the generated files by running:

  $ make lcitool-refresh

[1] https://www.apple.com/newsroom/2023/09/macos-sonoma-is-available-today/
[2] https://www.apple.com/newsroom/2022/10/macos-ventura-is-now-available/

Signed-off-by: Philippe Mathieu-Daudé 
---
 .gitlab-ci.d/cirrus.yml  | 6 +++---
 .gitlab-ci.d/cirrus/{macos-12.vars => macos-13.vars} | 2 +-
 tests/lcitool/refresh| 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)
 rename .gitlab-ci.d/cirrus/{macos-12.vars => macos-13.vars} (95%)

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index e7f1f83c2c..07dc6edae1 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -59,13 +59,13 @@ x64-freebsd-13-build:
 INSTALL_COMMAND: pkg install -y
 TEST_TARGETS: check
 
-aarch64-macos-12-base-build:
+aarch64-macos-13-base-build:
   extends: .cirrus_build_job
   variables:
-NAME: macos-12
+NAME: macos-13
 CIRRUS_VM_INSTANCE_TYPE: macos_instance
 CIRRUS_VM_IMAGE_SELECTOR: image
-CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-monterey-base:latest
+CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-ventura-base:latest
 CIRRUS_VM_CPUS: 12
 CIRRUS_VM_RAM: 24G
 UPDATE_COMMAND: brew update
diff --git a/.gitlab-ci.d/cirrus/macos-12.vars 
b/.gitlab-ci.d/cirrus/macos-13.vars
similarity index 95%
rename from .gitlab-ci.d/cirrus/macos-12.vars
rename to .gitlab-ci.d/cirrus/macos-13.vars
index 5f3fb346d1..534f029956 100644
--- a/.gitlab-ci.d/cirrus/macos-12.vars
+++ b/.gitlab-ci.d/cirrus/macos-13.vars
@@ -1,6 +1,6 @@
 # THIS FILE WAS AUTO-GENERATED
 #
-#  $ lcitool variables macos-12 qemu
+#  $ lcitool variables macos-13 qemu
 #
 # https://gitlab.com/libvirt/libvirt-ci
 
diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index 92e7d30982..2259f131b4 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -196,7 +196,7 @@ try:
 # Cirrus packages lists for GitLab
 #
 generate_cirrus("freebsd-13")
-generate_cirrus("macos-12")
+generate_cirrus("macos-13")
 
 #
 # VM packages lists
-- 
2.41.0




[PATCH RFC v1 0/1] clipboard sharing implementation for SDL

2023-11-08 Thread Kamay Xutax
Hello,

This is my first try contributing to QEMU,
and I would like some advices before merging my patch into master branch.

Current implementation works with qemu-vdagent character device.
I decided to ignore QemuClipboardPeer's request function pointer
for my current implementation because I couldn't get any clipboard
requests from the host with,
so instead I've decided to use SDL event loop with SDL_CLIPBOARDUPDATE
and handle the request from here.
I suppose this is the normal behavior, but since I'm not entirely
sure I would like some confirmation or advices about it.

I'm getting also a wanring from the scripts/checkpatch.pl
since I've added a c file for the implementation,
it asks me to update MAINTAINERS, I would gladly put myself here
but I think this decision shouldn't be taken by me.

I'm also up to any corrections if there's errors or something you want
to change in the code.

Thank you.

Kamay Xutax (1):
  ui/sdl2: clipboard sharing implementation for SDL

 include/ui/sdl2.h   |   5 ++
 meson.build |   1 +
 ui/meson.build  |   1 +
 ui/sdl2-clipboard.c | 147 
 ui/sdl2.c   |   8 +++
 5 files changed, 162 insertions(+)
 create mode 100644 ui/sdl2-clipboard.c

-- 
2.41.0




Re: [PULL 00/23] Final test, gdbstub, plugin and gitdm updates for 8.2

2023-11-08 Thread Alex Bennée
Stefan Hajnoczi  writes:

> On Tue, 7 Nov 2023 at 22:25, Alex Bennée  wrote:
>>
>> The following changes since commit 462ad017ed76889d46696a3581e1b52343f9b683:
>>
>>   Merge tag 'pixman-pull-request' of 
>> https://gitlab.com/marcandre.lureau/qemu into staging (2023-11-07 19:00:03 
>> +0800)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.com/stsquad/qemu.git tags/pull-halloween-omnibus-071123-1
>>
>> for you to fetch changes up to 00da668de6856d912cd75474ba759927e29d0e49:
>>
>>   Revert "tests/tcg/nios2: Re-enable linux-user tests" (2023-11-07 14:18:29 
>> +)
>>
>> 
>> Final test, gdbstub, plugin and gitdm updates for 8.2
>>
>>   - fix duplicate register in arm xml
>>   - hide various duplicate system registers from gdbstub
>>   - add new gdb register test to the CI (skipping s390x/ppc64 for now)
>>   - introduce GDBFeatureBuilder
>>   - move plugin initialisation to after vCPU init completes
>>   - enable building TCG plugins on Windows platform
>
> Hi Alex,
> Please take a look at the following CI failure:
>
> i686-w64-mingw32-gcc -m32 -o tests/plugin/libempty.dll
> plugins/qemu_plugin_api.lib tests/plugin/libempty.dll.p/empty.c.obj
> tests/plugin/libempty.dll.p/.._.._contrib_plugins_win32_linker.c.obj
> -Wl,--allow-shlib-undefined -shared -Wl,--start-group
> -Wl,--out-implib=tests/plugin/libempty.dll.a -fstack-protector-strong
> -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--warn-common
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libintl.dll.a
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a
> -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
> -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
> /usr/lib/gcc/i686-w64-mingw32/12.2.1/../../../../i686-w64-mingw32/bin/ld:
> tests/plugin/libempty.dll.p/empty.c.obj: in function
> `qemu_plugin_install':
> /builds/qemu-project/qemu/build/../tests/plugin/empty.c:30: undefined
> reference to `_imp__qemu_plugin_register_vcpu_tb_trans_cb'
> collect2: error: ld returned 1 exit status
>
> https://gitlab.com/qemu-project/qemu/-/jobs/5487689202

Please see:

  Message-Id: <20231108151743.3834165-1-alex.ben...@linaro.org>
  Date: Wed,  8 Nov 2023 15:17:43 +
  Subject: [PULL v2 00/23] Final test, gdbstub, plugin and gitdm updates for 8.2
  From: =?UTF-8?q?Alex=20Benn=C3=A9e?= 

CI currently running:

  https://gitlab.com/stsquad/qemu/-/pipelines/1065418931

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



[PATCH RFC v1 1/1] ui/sdl2: clipboard sharing implementation for SDL

2023-11-08 Thread Kamay Xutax
Signed-off-by: Kamay Xutax 
---
 include/ui/sdl2.h   |   5 ++
 meson.build |   1 +
 ui/meson.build  |   1 +
 ui/sdl2-clipboard.c | 147 
 ui/sdl2.c   |   8 +++
 5 files changed, 162 insertions(+)
 create mode 100644 ui/sdl2-clipboard.c

diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h
index e3acc7c82a..120fe6f856 100644
--- a/include/ui/sdl2.h
+++ b/include/ui/sdl2.h
@@ -21,6 +21,7 @@
 # include 
 #endif
 
+#include "ui/clipboard.h"
 #include "ui/kbd-state.h"
 #ifdef CONFIG_OPENGL
 # include "ui/egl-helpers.h"
@@ -51,6 +52,7 @@ struct sdl2_console {
 bool y0_top;
 bool scanout_mode;
 #endif
+QemuClipboardPeer cbpeer;
 };
 
 void sdl2_window_create(struct sdl2_console *scon);
@@ -70,6 +72,9 @@ void sdl2_2d_redraw(struct sdl2_console *scon);
 bool sdl2_2d_check_format(DisplayChangeListener *dcl,
   pixman_format_code_t format);
 
+void sdl2_clipboard_handle_request(struct sdl2_console *scon);
+void sdl2_clipboard_init(struct sdl2_console *scon);
+
 void sdl2_gl_update(DisplayChangeListener *dcl,
 int x, int y, int w, int h);
 void sdl2_gl_switch(DisplayChangeListener *dcl,
diff --git a/meson.build b/meson.build
index 4848930680..1358d14b2e 100644
--- a/meson.build
+++ b/meson.build
@@ -2157,6 +2157,7 @@ config_host_data.set('CONFIG_RDMA', rdma.found())
 config_host_data.set('CONFIG_RELOCATABLE', get_option('relocatable'))
 config_host_data.set('CONFIG_SAFESTACK', get_option('safe_stack'))
 config_host_data.set('CONFIG_SDL', sdl.found())
+config_host_data.set('CONFIG_SDL_CLIPBOARD', sdl.found())
 config_host_data.set('CONFIG_SDL_IMAGE', sdl_image.found())
 config_host_data.set('CONFIG_SECCOMP', seccomp.found())
 if seccomp.found()
diff --git a/ui/meson.build b/ui/meson.build
index 0ccb3387ee..0cadd1a18f 100644
--- a/ui/meson.build
+++ b/ui/meson.build
@@ -125,6 +125,7 @@ if sdl.found()
   sdl_ss = ss.source_set()
   sdl_ss.add(sdl, sdl_image, pixman, glib, files(
 'sdl2-2d.c',
+'sdl2-clipboard.c',
 'sdl2-input.c',
 'sdl2.c',
   ))
diff --git a/ui/sdl2-clipboard.c b/ui/sdl2-clipboard.c
new file mode 100644
index 00..405bb9ea8b
--- /dev/null
+++ b/ui/sdl2-clipboard.c
@@ -0,0 +1,147 @@
+/*
+ * SDL UI -- clipboard support
+ *
+ * Copyright (C) 2023 Kamay Xutax 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/main-loop.h"
+#include "ui/sdl2.h"
+
+static void sdl2_clipboard_update(struct sdl2_console *scon,
+  QemuClipboardInfo *info)
+{
+bool self_update = info->owner == >cbpeer;
+char *text;
+size_t text_size;
+
+/*
+ * In case of a self update,
+ * set again the text in SDL
+ *
+ * This is a workaround for hosts that have clipboard history
+ * or when they're copying again something,
+ * so that SDL can accept a new request from the host
+ * and make a new SDL_CLIPBOARDUPDATE event
+ */
+
+if (self_update) {
+text = SDL_GetClipboardText();
+SDL_SetClipboardText(text);
+SDL_free(text);
+return;
+}
+
+if (!info->types[QEMU_CLIPBOARD_TYPE_TEXT].available) {
+return;
+}
+
+info = qemu_clipboard_info_ref(info);
+qemu_clipboard_request(info, QEMU_CLIPBOARD_TYPE_TEXT);
+
+while (info == qemu_clipboard_info(info->selection) &&
+   info->types[QEMU_CLIPBOARD_TYPE_TEXT].available &&
+   info->types[QEMU_CLIPBOARD_TYPE_TEXT].data == NULL) {
+main_loop_wait(false);
+}
+
+/* clipboard info changed while waiting for data */
+if (info != qemu_clipboard_info(info->selection)) {
+qemu_clipboard_info_unref(info);
+return;
+}
+
+/* text is not null terminated in cb info, so we need to copy it */
+text_size = info->types[QEMU_CLIPBOARD_TYPE_TEXT].size;
+
+if (!text_size) {
+qemu_clipboard_info_unref(info);
+return;
+}
+
+text = malloc(text_size + 1);
+
+if (!text) {
+qemu_clipboard_info_unref(info);
+return;
+}
+
+text[text_size] = 0;
+memcpy(text, info->types[QEMU_CLIPBOARD_TYPE_TEXT].data, text_size);
+/* unref as soon we copied the text */
+qemu_clipboard_info_unref(info);
+SDL_SetClipboardText(text);
+
+free(text);
+}
+
+static void 

[PATCH v6 4/4] scripts: add script to compare compatible properties

2023-11-08 Thread Maksim Davydov
This script runs QEMU to obtain compat_props of machines and default
values of different types of drivers to produce comparison table. This
table can be used to compare machine types to choose the most suitable
machine or compare binaries to be sure that migration to the newer version
will save all device properties. Also the json or csv format of this
table can be used to check does a new machine affect the previous ones by
comparing tables with and without the new machine.

Default values (that will be used without machine compat_props) of
properties are needed to fill "holes" in the table (one machine has
the property but another machine not. For instance, 2.12 machine has
`{ "EPYC-" TYPE_X86_CPU, "xlevel", "0x800a" }`, but compat_pros of
3.1 machine doesn't have it. Thus, to compare these machines we need to
get unknown value of "EPYC-x86_64-cpu-xlevel" for 3.1 machine. These
unknown values in the table are called "holes". To get values for these
"holes" the script uses list of appropriate methods.)

Notes:
* Some init values from the devices can't be available like properties
  from virtio-9p when configure has --disable-virtfs. This situations will
  be seen in the table as "unavailable driver".
* Default values can be obtained in an unobvious way, like x86 features.
  If the script doesn't know how to get property default value to compare
  one machine with another it fills "holes" with "unavailable method". This
  is done because script uses whitelist model to get default values of
  different types. It means that the method that can't be applied to a new
  type that can crash this script. It is better to get an "unavailable
  driver" when creating a new machine with new compatible properties than
  to break this script. So it turns out a more stable and generic script.
* If the default value can't be obtained because this property doesn't
  exist or because this property can't have default value, appropriate
  "hole" will be filled by "unknown property" or "no default value"
* If the property is applied to the abstract class, the script collects
  default values from all child classes (set of default values)
* Raw table (--raw flag) should be used with json/csv parameters for
  scripts and etc. Human-readable (default) format contains transformed
  and simplified values and it doesn't contain lines with the same values
  in columns

Example:
./scripts/compare_mt.py --mt pc-q35-6.2 pc-q35-7.1
╒══╤══╤╤╕
│  Driver  │ Property │  build/qemu-system-x86_64  │  
build/qemu-system-x86_64  │
│  │  │ pc-q35-6.2 │
 pc-q35-7.1 │
╞══╪══╪╪╡
│ PIIX4_PM │ x-not-migrate-acpi-index │True│
   False│
├──┼──┼┼┤
│ arm-gicv3-common │ force-8-bit-prio │True│
 unavailable driver │
├──┼──┼┼┤
│ nvme-ns  │  eui64-default   │True│
   False│
├──┼──┼┼┤
│virtio-mem│  unplugged-inaccessible  │   False│
auto│
╘══╧══╧╧╛

Signed-off-by: Maksim Davydov 
Co-developed-by: Vladimir Sementsov-Ogievskiy 
---
 scripts/compare_mt.py | 484 ++
 1 file changed, 484 insertions(+)
 create mode 100755 scripts/compare_mt.py

diff --git a/scripts/compare_mt.py b/scripts/compare_mt.py
new file mode 100755
index 00..685bd9a336
--- /dev/null
+++ b/scripts/compare_mt.py
@@ -0,0 +1,484 @@
+#!/usr/bin/env python3
+#
+# Script to compare machine type compatible properties (include/hw/boards.h).
+# compat_props are applied to the driver during initialization to change
+# default values, for instance, to maintain compatibility.
+# This script constructs table with machines and values of their compat_props
+# to compare and to find places for improvements or places with bugs. If
+# during the comparison, some machine type doesn't have a property (it is in
+# the comparison table because another machine type has it), then the
+# appropriate method will be used to obtain the default value of this driver
+# property via qmp command (e.g. query-cpu-model-expansion for x86_64-cpu).
+# These methods are defined below in qemu_property_methods.
+#
+# Copyright (c) Yandex Technologies LLC, 2023
+#
+# This program is free software; you can redistribute it 

[PATCH v6 2/4] qmp: add dump machine type compatible properties

2023-11-08 Thread Maksim Davydov
To control that creating new machine type doesn't affect the previous
types (their compat_props) and to check complex compat_props inheritance
we need qmp command to print machine type compatible properties.
This patch adds the ability to get list of all the compat_props of the
corresponding supported machines for their comparison via new optional
argument of "query-machines" command.

Signed-off-by: Maksim Davydov 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 hw/core/machine-qmp-cmds.c  | 23 +++-
 qapi/machine.json   | 54 +++--
 tests/qtest/fuzz/qos_fuzz.c |  2 +-
 3 files changed, 75 insertions(+), 4 deletions(-)

diff --git a/hw/core/machine-qmp-cmds.c b/hw/core/machine-qmp-cmds.c
index 3860a50c3b..a49d0dc362 100644
--- a/hw/core/machine-qmp-cmds.c
+++ b/hw/core/machine-qmp-cmds.c
@@ -66,7 +66,8 @@ CpuInfoFastList *qmp_query_cpus_fast(Error **errp)
 return head;
 }
 
-MachineInfoList *qmp_query_machines(Error **errp)
+MachineInfoList *qmp_query_machines(bool has_compat_props, bool compat_props,
+Error **errp)
 {
 GSList *el, *machines = object_class_get_list(TYPE_MACHINE, false);
 MachineInfoList *mach_list = NULL;
@@ -98,6 +99,26 @@ MachineInfoList *qmp_query_machines(Error **errp)
 info->default_ram_id = g_strdup(mc->default_ram_id);
 }
 
+if (compat_props && mc->compat_props) {
+int i;
+info->compat_props = NULL;
+CompatPropertyList **tail = &(info->compat_props);
+info->has_compat_props = true;
+
+for (i = 0; i < mc->compat_props->len; i++) {
+GlobalProperty *mt_prop = g_ptr_array_index(mc->compat_props,
+i);
+CompatProperty *prop;
+
+prop = g_malloc0(sizeof(*prop));
+prop->driver = g_strdup(mt_prop->driver);
+prop->property = g_strdup(mt_prop->property);
+prop->value = g_strdup(mt_prop->value);
+
+QAPI_LIST_APPEND(tail, prop);
+}
+}
+
 QAPI_LIST_PREPEND(mach_list, info);
 }
 
diff --git a/qapi/machine.json b/qapi/machine.json
index b6d634b30d..8ca0c134a2 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -135,6 +135,25 @@
 ##
 { 'command': 'query-cpus-fast', 'returns': [ 'CpuInfoFast' ] }
 
+##
+# @CompatProperty:
+#
+# Machine type compatible property. It's based on GlobalProperty and created
+# for machine type compat properties (see scripts)
+#
+# @driver: name of the driver that has GlobalProperty
+#
+# @property: global property name
+#
+# @value: global property value
+#
+# Since: 8.2
+##
+{ 'struct': 'CompatProperty',
+  'data': { 'driver': 'str',
+'property': 'str',
+'value': 'str' } }
+
 ##
 # @MachineInfo:
 #
@@ -166,6 +185,9 @@
 #
 # @acpi: machine type supports ACPI (since 8.0)
 #
+# @compat-props: List of compatible properties that defines machine type
+#(since 8.2)
+#
 # Since: 1.2
 ##
 { 'struct': 'MachineInfo',
@@ -173,18 +195,46 @@
 '*is-default': 'bool', 'cpu-max': 'int',
 'hotpluggable-cpus': 'bool',  'numa-mem-supported': 'bool',
 'deprecated': 'bool', '*default-cpu-type': 'str',
-'*default-ram-id': 'str', 'acpi': 'bool' } }
+'*default-ram-id': 'str', 'acpi': 'bool', '*compat-props': 
['CompatProperty'] } }
 
 ##
 # @query-machines:
 #
 # Return a list of supported machines
 #
+# @compat-props: if true return will contain information about machine type
+#compatible properties (since 8.2)
+#
 # Returns: a list of MachineInfo
 #
 # Since: 1.2
+#
+# Example:
+#
+# -> { "execute": "query-machines", "arguments": { "compat-props": true } }
+# <- { "return": [
+#  {
+#  "hotpluggable-cpus": true,
+#  "name": "pc-q35-6.2",
+#  "compat-props": [
+#  {
+#  "driver": "virtio-mem",
+#  "property": "unplugged-inaccessible",
+#  "value": "off"
+#   }
+#   ],
+#   "numa-mem-supported": false,
+#   "default-cpu-type": "qemu64-x86_64-cpu",
+#   "cpu-max": 288,
+#   "deprecated": false,
+#   "default-ram-id": "pc.ram"
+#   },
+#   ...
+#}
 ##
-{ 'command': 'query-machines', 'returns': ['MachineInfo'] }
+{ 'command': 'query-machines',
+  'data': { '*compat-props': 'bool' },
+  'returns': ['MachineInfo'] }
 
 ##
 # @CurrentMachineParams:
diff --git a/tests/qtest/fuzz/qos_fuzz.c b/tests/qtest/fuzz/qos_fuzz.c
index e403d373a0..b71e945c5f 100644
--- a/tests/qtest/fuzz/qos_fuzz.c
+++ b/tests/qtest/fuzz/qos_fuzz.c
@@ -46,7 +46,7 @@ static void qos_set_machines_devices_available(void)
 MachineInfoList *mach_info;
 ObjectTypeInfoList *type_info;
 
-mach_info = 

[PATCH v6 0/4] compare machine type compat_props

2023-11-08 Thread Maksim Davydov
This script can be used to choose the best machine type in the
appropriate cases. Also we have to check compat_props of the old MT
after changes to be sure that they haven't broken old the MT. For
example, pc_compat_3_1 of pc-q35-3.1 has Icelake-Client which was
removed.

v6 -> v5:
* add ability to compare different QEMU binaries
* replace abstract drivers by its implementations
* improve human-readable format
* code refactoring

v5 -> v4:
* minor fixes

v4 -> v3:
* increase read buffer limit to limit value in libvirt
* add caching of qmp requests to speed up the script 

v3 -> v2:
* simplify adding new methods for getting QEMU default values
* add typing
* change concept from fixed dictionaries to classes

v2 -> v1:
* fix script code style and descriptions
* reorder patches
 
v1 -> previous iteration:
* new default value print concept
* QEMU python library is used to collect qmp data
* remove auxiliary patches (that was used to fix `->get` sematics)
* print compat_props in the correct order
* delete `absract` field to reduce output JSON size

Maksim Davydov (4):
  qom: add default value
  qmp: add dump machine type compatible properties
  python: add binary
  scripts: add script to compare compatible properties

 hw/core/machine-qmp-cmds.c |  23 +-
 python/qemu/machine/machine.py |   5 +
 qapi/machine.json  |  54 +++-
 qom/qom-qmp-cmds.c |   1 +
 scripts/compare_mt.py  | 484 +
 tests/qtest/fuzz/qos_fuzz.c|   2 +-
 6 files changed, 565 insertions(+), 4 deletions(-)
 create mode 100755 scripts/compare_mt.py

-- 
2.34.1




[PATCH v6 3/4] python: add binary

2023-11-08 Thread Maksim Davydov
Add a supportive property to access the path to the qemu binary

Signed-off-by: Maksim Davydov 
---
 python/qemu/machine/machine.py | 5 +
 1 file changed, 5 insertions(+)

diff --git a/python/qemu/machine/machine.py b/python/qemu/machine/machine.py
index 31cb9d617d..78436403b2 100644
--- a/python/qemu/machine/machine.py
+++ b/python/qemu/machine/machine.py
@@ -328,6 +328,11 @@ def args(self) -> List[str]:
 """Returns the list of arguments given to the QEMU binary."""
 return self._args
 
+@property
+def binary(self) -> str:
+"""Returns path to the qemu binary"""
+return self._binary
+
 def _pre_launch(self) -> None:
 if self._qmp_set:
 if self._monitor_address is None:
-- 
2.34.1




[PATCH v6 1/4] qom: add default value

2023-11-08 Thread Maksim Davydov
qmp_qom_list_properties can print default values if they are available
as qmp_device_list_properties does, because both of them use the
ObjectPropertyInfo structure with default_value field. This can be useful
when working with "not device" types (e.g. memory-backend).

Signed-off-by: Maksim Davydov 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
---
 qom/qom-qmp-cmds.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/qom/qom-qmp-cmds.c b/qom/qom-qmp-cmds.c
index 7c087299de..e91a235347 100644
--- a/qom/qom-qmp-cmds.c
+++ b/qom/qom-qmp-cmds.c
@@ -212,6 +212,7 @@ ObjectPropertyInfoList *qmp_qom_list_properties(const char 
*typename,
 info->name = g_strdup(prop->name);
 info->type = g_strdup(prop->type);
 info->description = g_strdup(prop->description);
+info->default_value = qobject_ref(prop->defval);
 
 QAPI_LIST_PREPEND(prop_list, info);
 }
-- 
2.34.1




[PULL v2 00/23] Final test, gdbstub, plugin and gitdm updates for 8.2

2023-11-08 Thread Alex Bennée
The following changes since commit a3c3aaa846ad61b801e7196482dcf4afb8ba34e4:

  Merge tag 'pull-ppc-20231107' of https://gitlab.com/danielhb/qemu into 
staging (2023-11-08 20:35:00 +0800)

are available in the Git repository at:

  https://gitlab.com/stsquad/qemu.git tags/pull-halloween-omnibus-081123-1

for you to fetch changes up to a475f32b075d566f3f92f94387d50e132b73bcb8:

  Revert "tests/tcg/nios2: Re-enable linux-user tests" (2023-11-08 15:15:23 
+)


Final test, gdbstub, plugin and gitdm updates for 8.2

  - fix duplicate register in arm xml
  - hide various duplicate system registers from gdbstub
  - add new gdb register test to the CI (skipping s390x/ppc64 for now)
  - introduce GDBFeatureBuilder
  - move plugin initialisation to after vCPU init completes
  - enable building TCG plugins on Windows platform
  - various gitdm updates
  - some mailmap fixes
  - disable testing for nios2 signals which have regressed


Akihiko Odaki (5):
  default-configs: Add TARGET_XML_FILES definition
  gdbstub: Add num_regs member to GDBFeature
  gdbstub: Introduce gdb_find_static_feature()
  gdbstub: Introduce GDBFeatureBuilder
  cpu: Call plugin hooks only when ready

Alex Bennée (13):
  gdb-xml: fix duplicate register in arm-neon.xml
  target/arm: mark the 32bit alias of PAR when LPAE enabled
  target/arm: hide all versions of DBGD[RS]AR from gdbstub
  target/arm: hide aliased MIDR from gdbstub
  tests/tcg: add an explicit gdbstub register tester
  tests/avocado: update the tcg_plugins test
  configure: tell meson and contrib_plugins about DLLTOOL
  gitlab: add dlltool to Windows CI
  contrib/gitdm: Add Rivos Inc to the domain map
  contrib/gitdm: map HiSilicon to Huawei
  contrib/gitdm: add Daynix to domain-map
  mailmap: fixup some more corrupted author fields
  Revert "tests/tcg/nios2: Re-enable linux-user tests"

Greg Manning (4):
  plugins: add dllexport and dllimport to api funcs
  plugins: make test/example plugins work on windows
  plugins: disable lockstep plugin on windows
  plugins: allow plugins to be enabled on windows

luzhipeng (1):
  contrib/gitdm: add domain-map for Cestc

 MAINTAINERS|   2 +-
 configure  |  13 +-
 configs/targets/loongarch64-linux-user.mak |   1 +
 meson.build|   5 +
 include/exec/gdbstub.h |  59 ++
 include/qemu/qemu-plugin.h |  50 +-
 contrib/plugins/win32_linker.c |  34 
 cpu-target.c   |  11 --
 gdbstub/gdbstub.c  |  78 
 hw/core/cpu-common.c   |  10 ++
 target/arm/debug_helper.c  |  10 +-
 target/arm/helper.c|  37 ++--
 .gitlab-ci.d/crossbuilds.yml   |   4 +-
 .gitlab-ci.d/windows.yml   |   1 +
 .mailmap   |   2 +
 contrib/gitdm/domain-map   |   4 +
 contrib/plugins/Makefile   |  26 ++-
 gdb-xml/arm-neon.xml   |   2 +-
 plugins/meson.build|  19 ++
 scripts/feature_to_c.py|  46 -
 tests/avocado/tcg_plugins.py   |  28 +--
 tests/plugin/meson.build   |  14 +-
 tests/tcg/multiarch/Makefile.target|  11 +-
 tests/tcg/multiarch/gdbstub/registers.py   | 197 +
 tests/tcg/multiarch/system/Makefile.softmmu-target |  13 +-
 tests/tcg/nios2/Makefile.target|  11 ++
 tests/tcg/ppc64/Makefile.target|   7 +
 tests/tcg/s390x/Makefile.target|   4 +
 28 files changed, 639 insertions(+), 60 deletions(-)
 create mode 100644 contrib/plugins/win32_linker.c
 create mode 100644 tests/tcg/multiarch/gdbstub/registers.py
 create mode 100644 tests/tcg/nios2/Makefile.target

-- 
2.39.2




Re: QEMU Virtio GPU features status & roadmap?

2023-11-08 Thread Alex Bennée
Hans de Ruiter  writes:

(Cc: Adding others with interest in VirtIO GPUs to the thread)

> Hi,
>
> I'm working on Virtio GPU drivers for AmigaOS, and would like to know
> what features are currently stable enough to use. Looking at the
> master QEMU branch, both Virgl and blob resources are supported, but
> NOT at the same time. Is the ability to use both simultaneously coming
> soon?
>
> Also, what's the state of Venus/Vulkan support? Surveying various
> forks/branches, it looks very experimental and subject to change.
>
> I have the added difficulty that the AmigaOS Picasso96 driver API
> expects direct CPU access to all of VRAM, and likes to peek/poke
> directly into the bitmaps. That's clearly not possible without blob
> resources, or shared memory (not entirely sure what the shared memory
> feature is for). This is why I want to know what features are stable
> or coming soon.
>
> regards,
> Hans
>
> [2. application/pgp-keys; publickey - h...@keasigmadelta.com - 
> 4293c311.asc]...

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



Re: [PATCH v5] tests/avocado: add test to exercize processor address space memory bound checks

2023-11-08 Thread Philippe Mathieu-Daudé

Hi Ani,

On 3/11/23 12:06, Ani Sinha wrote:

QEMU has validations to make sure that a VM is not started with more memory
(static and hotpluggable memory) than what the guest processor can address
directly with its addressing bits. This change adds a test to make sure QEMU
fails to start with a specific error message when an attempt is made to
start a VM with more memory than what the processor can directly address.
The test also checks for passing cases when the address space of the processor
is capable of addressing all memory. Boundary cases are tested.

CC: imamm...@redhat.com
CC: David Hildenbrand 
Acked-by: David Hildenbrand 
Signed-off-by: Ani Sinha 
---
  tests/avocado/mem-addr-space-check.py | 361 ++
  1 file changed, 361 insertions(+)
  create mode 100644 tests/avocado/mem-addr-space-check.py

Changelog:
v5:
   - made the negative test cases (ones that do not result in QEMU crash)
 more robust by checking the non-existence of the "phys-bits too low"
 log.
   - added a new test case for AMD HT window where QEMU starts fine.
   - rebased.
   - cosmetic typo/comment adjustments.

Tests all pass:
$ ./pyvenv/bin/avocado run tests/avocado/mem-addr-space-check.py --tap -
1..15
ok 1 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pse36
ok 2 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_pae
ok 3 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pse36
ok 4 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium_pae
ok 5 tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_pentium2
ok 6 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_nonpse36
ok 7 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_70_amd
ok 8 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd
ok 9 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_70_amd
ok 10 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd
ok 11 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_intel
ok 12 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_71_amd_41bits
ok 13 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_71_amd_41bits
ok 14 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_low_tcg_q35_intel_cxl
ok 15 
tests/avocado/mem-addr-space-check.py:MemAddrCheck.test_phybits_ok_tcg_q35_intel_cxl

v4: incorporated changes related to suggestions from David.
v3: added pae tests as well.
v2: added 64-bit tests. Added cxl tests.

diff --git a/tests/avocado/mem-addr-space-check.py 
b/tests/avocado/mem-addr-space-check.py
new file mode 100644
index 00..6b4ada5857
--- /dev/null
+++ b/tests/avocado/mem-addr-space-check.py
@@ -0,0 +1,361 @@
+# Check for crash when using memory beyond the available guest processor
+# address space.
+#
+# Copyright (c) 2023 Red Hat, Inc.
+#
+# Author:
+#  Ani Sinha 
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+from avocado_qemu import QemuSystemTest
+import signal
+import time
+
+class MemAddrCheck(QemuSystemTest):
+# first, lets test some 32-bit processors.
+# for all 32-bit cases, pci64_hole_size is 0.
+def test_phybits_low_pse36(self):
+"""
+:avocado: tags=machine:q35
+:avocado: tags=arch:x86_64
+
+With pse36 feature ON, a processor has 36 bits of addressing. So it can
+access up to a maximum of 64GiB of memory. Memory hotplug region begins
+at 4 GiB boundary when "above_4g_mem_size" is 0 (this would be true 
when
+we have 0.5 GiB of VM memory, see pc_q35_init()). This means total
+hotpluggable memory size is 60 GiB. Per slot, we reserve 1 GiB of 
memory
+for dimm alignment for all newer machines (see enforce_aligned_dimm
+property for pc machines and pc_get_device_memory_range()). That leaves
+total hotpluggable actual memory size of 59 GiB. If the VM is started
+with 0.5 GiB of memory, maxmem should be set to a maximum value of
+59.5 GiB to ensure that the processor can address all memory directly.
+Note that 64-bit pci hole size is 0 in this case. If maxmem is set to
+59.6G, QEMU should fail to start with a message "phy-bits are too low".

Re: [PULL 00/23] Final test, gdbstub, plugin and gitdm updates for 8.2

2023-11-08 Thread Alex Bennée
Stefan Hajnoczi  writes:

> On Tue, 7 Nov 2023 at 22:25, Alex Bennée  wrote:
>>
>> The following changes since commit 462ad017ed76889d46696a3581e1b52343f9b683:
>>
>>   Merge tag 'pixman-pull-request' of 
>> https://gitlab.com/marcandre.lureau/qemu into staging (2023-11-07 19:00:03 
>> +0800)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.com/stsquad/qemu.git tags/pull-halloween-omnibus-071123-1
>>
>> for you to fetch changes up to 00da668de6856d912cd75474ba759927e29d0e49:
>>
>>   Revert "tests/tcg/nios2: Re-enable linux-user tests" (2023-11-07 14:18:29 
>> +)
>>
>> 
>> Final test, gdbstub, plugin and gitdm updates for 8.2
>>
>>   - fix duplicate register in arm xml
>>   - hide various duplicate system registers from gdbstub
>>   - add new gdb register test to the CI (skipping s390x/ppc64 for now)
>>   - introduce GDBFeatureBuilder
>>   - move plugin initialisation to after vCPU init completes
>>   - enable building TCG plugins on Windows platform
>
> Hi Alex,
> Please take a look at the following CI failure:
>
> i686-w64-mingw32-gcc -m32 -o tests/plugin/libempty.dll
> plugins/qemu_plugin_api.lib tests/plugin/libempty.dll.p/empty.c.obj
> tests/plugin/libempty.dll.p/.._.._contrib_plugins_win32_linker.c.obj
> -Wl,--allow-shlib-undefined -shared -Wl,--start-group
> -Wl,--out-implib=tests/plugin/libempty.dll.a -fstack-protector-strong
> -Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--warn-common
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libintl.dll.a
> /usr/i686-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a
> -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
> -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
> /usr/lib/gcc/i686-w64-mingw32/12.2.1/../../../../i686-w64-mingw32/bin/ld:
> tests/plugin/libempty.dll.p/empty.c.obj: in function
> `qemu_plugin_install':
> /builds/qemu-project/qemu/build/../tests/plugin/empty.c:30: undefined
> reference to `_imp__qemu_plugin_register_vcpu_tb_trans_cb'
> collect2: error: ld returned 1 exit status

Sorry I missed that. While the native msys2-win32bit/msys2-win64bit
builds work the mingw cross builds fail despite having dlltool
installed.

For now I shall --disable-plugins on those builds and raise a bug to
make sure we don't forget.

Greg,

Do you have a Linux/WSL2 system as well that you could look at the
difference? It seems weird its only complaining about some of the
symbols.

To do a local mingw cross build in Linux:

  make docker-test-build@fedora-win64-cross J=30 V=1 
EXTRA_CONFIGURE_OPTS="--enable-fdt=internal" NETWORK=1 DEBUG=1

The NETWORK is important to ensure git can fetch stuff. DEBUG will drop
you into a shell inside the container so you can poke around the build.

>
> https://gitlab.com/qemu-project/qemu/-/jobs/5487689202
>
> Thanks,
> Stefan
>
>>   - various gitdm updates
>>   - some mailmap fixes
>>   - disable testing for nios2 signals which have regressed
>>
>> 
>> Akihiko Odaki (5):
>>   default-configs: Add TARGET_XML_FILES definition
>>   gdbstub: Add num_regs member to GDBFeature
>>   gdbstub: Introduce gdb_find_static_feature()
>>   gdbstub: Introduce GDBFeatureBuilder
>>   cpu: Call plugin hooks only when ready
>>
>> Alex Bennée (13):
>>   gdb-xml: fix duplicate register in arm-neon.xml
>>   target/arm: mark the 32bit alias of PAR when LPAE enabled
>>   target/arm: hide all versions of DBGD[RS]AR from gdbstub
>>   target/arm: hide aliased MIDR from gdbstub
>>   tests/tcg: add an explicit gdbstub register tester
>>   tests/avocado: update the tcg_plugins test
>>   configure: tell meson and contrib_plugins about DLLTOOL
>>   gitlab: add dlltool to Windows CI
>>   contrib/gitdm: Add Rivos Inc to the domain map
>>   contrib/gitdm: map HiSilicon to Huawei
>>   contrib/gitdm: add Daynix to domain-map
>>   mailmap: fixup some more corrupted author fields
>>   Revert "tests/tcg/nios2: Re-enable linux-user tests"
>>
>> Greg Manning (4):
>>   plugins: add dllexport and dllimport to api funcs
>>   plugins: make test/example plugins work on windows
>>   plugins: disable lockstep plugin on windows
>>   plugins: allow plugins to be enabled on windows
>>
>> luzhipeng (1):
>>   contrib/gitdm: add domain-map for Cestc
>>
>>  MAINTAINERS|   2 +-
>>  configure  |  13 +-
>>  configs/targets/loongarch64-linux-user.mak |   1 +
>>  meson.build|   5 +
>>  include/exec/gdbstub.h |  59 ++
>>  include/qemu/qemu-plugin.h |  50 +-
>>  contrib/plugins/win32_linker.c |  34 
>>  cpu-target.c   |  11 --
>>  

[PATCH v2 11/35 2/2] tcg/arm: Support TCG_COND_TST{EQ,NE}

2023-11-08 Thread Philippe Mathieu-Daudé
From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20231028194522.245170-12-richard.hender...@linaro.org>
[PMD: Split from bigger patch, part 2/2]
Signed-off-by: Philippe Mathieu-Daudé 
---
 tcg/arm/tcg-target.c.inc | 29 -
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/tcg/arm/tcg-target.c.inc b/tcg/arm/tcg-target.c.inc
index 66d71af8bf..0fc7273b16 100644
--- a/tcg/arm/tcg-target.c.inc
+++ b/tcg/arm/tcg-target.c.inc
@@ -1194,7 +1194,27 @@ static void tcg_out_mb(TCGContext *s, TCGArg a0)
 static TCGCond tcg_out_cmp(TCGContext *s, TCGCond cond, TCGReg a,
TCGArg b, int b_const)
 {
-tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0, a, b, b_const);
+if (!is_tst_cond(cond)) {
+tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0, a, b, b_const);
+return cond;
+}
+
+cond = tcg_tst_eqne_cond(cond);
+if (b_const) {
+int imm12 = encode_imm(b);
+
+/*
+ * The compare constraints allow rIN, but TST does not support N.
+ * Be prepared to load the constant into a scratch register.
+ */
+if (imm12 >= 0) {
+tcg_out_dat_imm(s, COND_AL, ARITH_TST, 0, a, imm12);
+return cond;
+}
+tcg_out_movi32(s, COND_AL, TCG_REG_TMP, b);
+b = TCG_REG_TMP;
+}
+tcg_out_dat_reg(s, COND_AL, ARITH_TST, 0, a, b, SHIFT_IMM_LSL(0));
 return cond;
 }
 
@@ -1225,6 +1245,13 @@ static TCGCond tcg_out_cmp2(TCGContext *s, const TCGArg 
*args,
 tcg_out_dat_rI(s, COND_EQ, ARITH_CMP, 0, al, bl, const_bl);
 return cond;
 
+case TCG_COND_TSTEQ:
+case TCG_COND_TSTNE:
+/* Similar, but with TST instead of CMP. */
+tcg_out_dat_rI(s, COND_AL, ARITH_TST, 0, ah, bh, const_bh);
+tcg_out_dat_rI(s, COND_EQ, ARITH_TST, 0, al, bl, const_bl);
+return tcg_tst_eqne_cond(cond);
+
 case TCG_COND_LT:
 case TCG_COND_GE:
 /* We perform a double-word subtraction and examine the result.
-- 
2.41.0




[PATCH v2 11/35 1/2] tcg/arm: Factor tcg_out_cmp() out

2023-11-08 Thread Philippe Mathieu-Daudé
From: Richard Henderson 

Signed-off-by: Richard Henderson 
Message-Id: <20231028194522.245170-12-richard.hender...@linaro.org>
[PMD: Split from bigger patch, part 1/2]
Signed-off-by: Philippe Mathieu-Daudé 
---
 tcg/arm/tcg-target.c.inc | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/tcg/arm/tcg-target.c.inc b/tcg/arm/tcg-target.c.inc
index 0c29a3929b..66d71af8bf 100644
--- a/tcg/arm/tcg-target.c.inc
+++ b/tcg/arm/tcg-target.c.inc
@@ -1191,6 +1191,13 @@ static void tcg_out_mb(TCGContext *s, TCGArg a0)
 }
 }
 
+static TCGCond tcg_out_cmp(TCGContext *s, TCGCond cond, TCGReg a,
+   TCGArg b, int b_const)
+{
+tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0, a, b, b_const);
+return cond;
+}
+
 static TCGCond tcg_out_cmp2(TCGContext *s, const TCGArg *args,
 const int *const_args)
 {
@@ -1806,9 +1813,8 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 /* Constraints mean that v2 is always in the same register as dest,
  * so we only need to do "if condition passed, move v1 to dest".
  */
-tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0,
-args[1], args[2], const_args[2]);
-tcg_out_dat_rIK(s, tcg_cond_to_arm_cond[args[5]], ARITH_MOV,
+c = tcg_out_cmp(s, args[5], args[1], args[2], const_args[2]);
+tcg_out_dat_rIK(s, tcg_cond_to_arm_cond[c], ARITH_MOV,
 ARITH_MVN, args[0], 0, args[3], const_args[3]);
 break;
 case INDEX_op_add_i32:
@@ -1958,25 +1964,21 @@ static void tcg_out_op(TCGContext *s, TCGOpcode opc,
 break;
 
 case INDEX_op_brcond_i32:
-tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0,
-   args[0], args[1], const_args[1]);
-tcg_out_goto_label(s, tcg_cond_to_arm_cond[args[2]],
-   arg_label(args[3]));
+c = tcg_out_cmp(s, args[2], args[0], args[1], const_args[1]);
+tcg_out_goto_label(s, tcg_cond_to_arm_cond[c], arg_label(args[3]));
 break;
 case INDEX_op_setcond_i32:
-tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0,
-args[1], args[2], const_args[2]);
-tcg_out_dat_imm(s, tcg_cond_to_arm_cond[args[3]],
+c = tcg_out_cmp(s, args[3], args[1], args[2], const_args[2]);
+tcg_out_dat_imm(s, tcg_cond_to_arm_cond[c],
 ARITH_MOV, args[0], 0, 1);
-tcg_out_dat_imm(s, tcg_cond_to_arm_cond[tcg_invert_cond(args[3])],
+tcg_out_dat_imm(s, tcg_cond_to_arm_cond[tcg_invert_cond(c)],
 ARITH_MOV, args[0], 0, 0);
 break;
 case INDEX_op_negsetcond_i32:
-tcg_out_dat_rIN(s, COND_AL, ARITH_CMP, ARITH_CMN, 0,
-args[1], args[2], const_args[2]);
-tcg_out_dat_imm(s, tcg_cond_to_arm_cond[args[3]],
+c = tcg_out_cmp(s, args[3], args[1], args[2], const_args[2]);
+tcg_out_dat_imm(s, tcg_cond_to_arm_cond[c],
 ARITH_MVN, args[0], 0, 0);
-tcg_out_dat_imm(s, tcg_cond_to_arm_cond[tcg_invert_cond(args[3])],
+tcg_out_dat_imm(s, tcg_cond_to_arm_cond[tcg_invert_cond(c)],
 ARITH_MOV, args[0], 0, 0);
 break;
 
-- 
2.41.0




Re: [PATCH v3 05/20] mcdstub: tcp packet processing added

2023-11-08 Thread Philippe Mathieu-Daudé

Hi Nicolas,

On 7/11/23 14:03, Nicolas Eder wrote:

---
  include/mcdstub/mcdstub.h | 144 
  mcdstub/mcdstub.c | 277 ++
  2 files changed, 421 insertions(+)

diff --git a/include/mcdstub/mcdstub.h b/include/mcdstub/mcdstub.h
index 36058157ae..1461d0e1cb 100644
--- a/include/mcdstub/mcdstub.h
+++ b/include/mcdstub/mcdstub.h
@@ -25,6 +25,21 @@ typedef struct MCDProcess {
  char target_xml[1024];
  } MCDProcess;
  
+typedef void (*MCDCmdHandler)(GArray *params, void *user_ctx);

+typedef struct MCDCmdParseEntry {
+MCDCmdHandler handler;
+const char *cmd;
+char schema[CMD_SCHEMA_LENGTH];
+} MCDCmdParseEntry;
+
+typedef union MCDCmdVariant {
+const char *data;
+uint32_t data_uint32_t;
+uint64_t data_uint64_t;
+uint32_t query_handle;
+uint32_t cpu_id;
+} MCDCmdVariant;


[...]

Can we add an URL to the spec in this file header?

It should be relatively easy to add a qtest for MCB, with raw
packets to:
- read memory
- write memory
- read register
- write register
- register breakpoint
- run vcpu
- stop vcpu

Maybe we can write a tiny code that loop incrementing a static
variable, run for few ms and check the variable got incremented?
That would exercise most of these commands.

Regards,

Phil.



Re: [PATCH v3 00/20] first version of mcdstub

2023-11-08 Thread Philippe Mathieu-Daudé

Hi Nicolas,

On 7/11/23 14:03, Nicolas Eder wrote:

SUMMARY
===

This patch-set introduces the first version of the mcdstub.




  30 files changed, 3749 insertions(+), 38 deletions(-)
  create mode 100644 debug/debug-common.c
  create mode 100644 debug/debug-gdb.c
  create mode 100644 debug/debug-mcd.c
  create mode 100644 include/cutils.h
  create mode 100644 include/mcdstub/arm_mcdstub.h
  create mode 100644 include/mcdstub/mcd_shared_defines.h
  create mode 100644 include/mcdstub/mcdstub.h
  create mode 100644 include/mcdstub/mcdstub_common.h
  create mode 100644 include/qemu/debug.h
  create mode 100644 mcdstub/mcdstub.c
  create mode 100644 mcdstub/meson.build
  create mode 100644 target/arm/mcdstub.c


These files are missing a license. Adding:
/* SPDX-License-Identifier: GPL-2.0-or-later */
on the first line is usually enough.

No need to respin a v4 yet, let's wait for technical
comments on your patches.

Regards,

Phil.



Re: [PATCH v9 5/5] amd_iommu: report x2APIC support to the operating system

2023-11-08 Thread Bui Quang Minh

On 11/7/23 07:39, Michael S. Tsirkin wrote:

On Tue, Oct 24, 2023 at 10:21:05PM +0700, Bui Quang Minh wrote:

This commit adds XTSup configuration to let user choose to whether enable
this feature or not. When XTSup is enabled, additional bytes in IRTE with
enabled guest virtual VAPIC are used to support 32-bit destination id.

Additionally, this commit exports IVHD type 0x11 besides the old IVHD type
0x10 in ACPI table. IVHD type 0x10 does not report full set of IOMMU
features only the legacy ones, so operating system (e.g. Linux) may only
detects x2APIC support if IVHD type 0x11 is available. The IVHD type 0x10
is kept so that old operating system that only parses type 0x10 can detect
the IOMMU device.

Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Bui Quang Minh 



changes IVRS without updating expected files for tests.
result seems to be CI failures:
https://gitlab.com/mstredhat/qemu/-/jobs/5470533834



Thanks Michael, I am preparing the fix in the next version. I've read 
the instructions to update the test data in bios-tables-test.c. It says 
I need to create some separate patches to update the test data. Are 
there any reasons for this? I intend to change the binary and include 
the ASL diff into the commit message. Is it enough?




Re: [PULL 0/5] Misc fixes patches

2023-11-08 Thread Stefan Hajnoczi
Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any 
user-visible changes.


signature.asc
Description: PGP signature


Re: [PULL 00/75] Misc HW/UI patches for 2023-11-07

2023-11-08 Thread Stefan Hajnoczi
Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any 
user-visible changes.


signature.asc
Description: PGP signature


Re: [PULL 0/9] ppc queue

2023-11-08 Thread Stefan Hajnoczi
Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any 
user-visible changes.


signature.asc
Description: PGP signature


Re: [PULL 00/11] s390x and MAINTAINERS updates

2023-11-08 Thread Stefan Hajnoczi
Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/8.2 for any 
user-visible changes.


signature.asc
Description: PGP signature


Re: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend

2023-11-08 Thread Jason Gunthorpe
On Wed, Nov 08, 2023 at 01:25:34PM +, Duan, Zhenzhong wrote:

> >I was expecting that hwpt manipulation would be done exclusively
> >inside the device-specific vIOMMU userspace driver. Generic code paths
> >that don't have that knowledge should use the IOAS for everything
> 
> Yes, this way we don't need to distinguish between mdev and real device,
> just attach to IOAS. But lose the benefit that same hwpt could be passed
> into vIOMMU to be used as S2 hwpt in nesting.

If you have a nesting capable vIOMMU driver then it should be
creating the HWPTs and managing them in its layer. Maybe the core code
provides some helpers.

Obviously you can't link a mdev to a nesting vIOMMU driver in the
first place. Mdev should be connected to a different IOMMU driver that
doesn't use HWPT at all.

I think it will make alot of trouble to put the hwpt in the wrong
layer as there shouldn't really be much generic code touching it.

Jason



Re: [PATCH v4 26/41] backends/iommufd: Introduce the iommufd object

2023-11-08 Thread Cédric Le Goater

On 11/8/23 11:30, Markus Armbruster wrote:

Cédric Le Goater  writes:


Hello Markus,

On 11/8/23 06:50, Markus Armbruster wrote:

Cédric Le Goater  writes:


On 11/2/23 08:12, Zhenzhong Duan wrote:

From: Eric Auger 
Introduce an iommufd object which allows the interaction
with the host /dev/iommu device.
The /dev/iommu can have been already pre-opened outside of qemu,
in which case the fd can be passed directly along with the
iommufd object:
This allows the iommufd object to be shared accross several
subsystems (VFIO, VDPA, ...). For example, libvirt would open
the /dev/iommu once.
If no fd is passed along with the iommufd object, the /dev/iommu
is opened by the qemu code.
The CONFIG_IOMMUFD option must be set to compile this new object.
Suggested-by: Alex Williamson 
Signed-off-by: Eric Auger 
Signed-off-by: Yi Liu 
Signed-off-by: Zhenzhong Duan 
---
v4: add CONFIG_IOMMUFD check, document default case
MAINTAINERS  |   7 ++
qapi/qom.json|  22 
include/sysemu/iommufd.h |  46 +++
backends/iommufd-stub.c  |  59 +
backends/iommufd.c   | 257 +++
backends/Kconfig |   4 +
backends/meson.build |   5 +
backends/trace-events|  12 ++
qemu-options.hx  |  13 ++
9 files changed, 425 insertions(+)
create mode 100644 include/sysemu/iommufd.h
create mode 100644 backends/iommufd-stub.c
create mode 100644 backends/iommufd.c
diff --git a/MAINTAINERS b/MAINTAINERS
index cd8d6b140f..6f35159255 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2135,6 +2135,13 @@ F: hw/vfio/ap.c
F: docs/system/s390x/vfio-ap.rst
L: qemu-s3...@nongnu.org
+iommufd
+M: Yi Liu 
+M: Eric Auger 
+S: Supported
+F: backends/iommufd.c
+F: include/sysemu/iommufd.h
+
vhost
M: Michael S. Tsirkin 
S: Supported
diff --git a/qapi/qom.json b/qapi/qom.json
index c53ef978ff..27300add48 100644
--- a/qapi/qom.json
+++ b/qapi/qom.json
@@ -794,6 +794,24 @@
{ 'struct': 'VfioUserServerProperties',
  'data': { 'socket': 'SocketAddress', 'device': 'str' } }
+##
+# @IOMMUFDProperties:
+#
+# Properties for iommufd objects.
+#
+# @fd: file descriptor name previously passed via 'getfd' command,
+# which represents a pre-opened /dev/iommu.  This allows the
+# iommufd object to be shared accross several subsystems
+# (VFIO, VDPA, ...), and the file descriptor to be shared
+# with other process, e.g. DPDK.  (default: QEMU opens
+# /dev/iommu by itself)
+#
+# Since: 8.2
+##
+{ 'struct': 'IOMMUFDProperties',
+  'data': { '*fd': 'str' },
+  'if': 'CONFIG_IOMMUFD' }



Activating or not IOMMUFD on a platform is a configuration choice
and it is not a dependency on an external resource. I would make
things simpler and drop all the #ifdef in the documentation files.


What exactly are you proposing?


I would like to simplify the configuration part of this new IOMMUFD
feature and avoid a ./configure option to enable/disable the feature
since it has no external dependencies and can be compiled on all
platforms.

However, we know that it only makes sense to have the IOMMUFD backend
on platforms s390x, aarch64, x86_64. So I am proposing as an improvement
to enable IOMMUFD only on these platforms with this addition :

   imply IOMMUFD

to hw/{i386,s390x,arm}/Kconfig files.

This gives us the possibility to compile out the feature downstream
if something goes wrong, using the files under : configs/devices/.


Shouldn't we then compile out the relevant parts of the QAPI schema,
too?


Is it possible with Kconfig options ?
 

Given that the IOMMUFD feature doesn't have any external dependencies
and that the IOMMUFD backend object is common to all platforms, I am
also proposing to remove all the CONFIG_IOMMUFD define usage in the
documentation file "qemu-options.hx" and the schema file "qapi/qom.json".


Any CONFIG_IOMMUFD left elsewhere?


There are. To expose or not vfio properties. Stuff like :

ifdef CONFIG_IOMMUFD
DEFINE_PROP_LINK("iommufd", VFIOPCIDevice, vbasedev.iommufd,
 TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
#endif
DEFINE_PROP_END_OF_LIST(),

and

#ifdef CONFIG_IOMMUFD
object_class_property_add_str(klass, "fd", NULL, vfio_pci_set_fd);
#endif



The use of 'if': 'CONFIG_IOMMUFD' in the QAPI schema enables
introspection with query-qmp-schema: when ObjectType @iommufd exists,
QEMU supports creating the object.  Or am I confused?


Object iommufd should always exist since it is common to all.

Is that acceptable ?


Perhaps the question to ask is whether a management application needs to
know whether this version of QEMU supports iommufd objects.  If yes,
then query-qmp-schema is an obvious way to find out.  


Thanks for reminding me of this possibility. In that case, we should
indeed avoid returning iommufd support when !CONFIG_IOMMUFD.

Can it be implemented in qapi/qom.json with Kconfig options ?


What could go
wrong when this returns 

Re: QEMU Virtio GPU features status & roadmap?

2023-11-08 Thread Antonio Caggiano

Hi Marc-André,

On 08/11/2023 12:07, Marc-André Lureau wrote:

Hi

On Wed, Nov 8, 2023 at 1:04 PM Antonio Caggiano
 wrote:


Hi Hans,

+cc Gert and Dmitry

On 17/10/2023 02:48, Hans de Ruiter wrote:

Hi,

I'm working on Virtio GPU drivers for AmigaOS, and would like to know
what features are currently stable enough to use. Looking at the master
QEMU branch, both Virgl and blob resources are supported, but NOT at the
same time. Is the ability to use both simultaneously coming soon?



Mmh, well, they should be compatible, I'll try sending a patch.


Also, what's the state of Venus/Vulkan support? Surveying various
forks/branches, it looks very experimental and subject to change.



I believe this is quite stable now:
https://gitlab.freedesktop.org/virgl/venus-protocol/-/issues/5


The last patch series for QEMU is from Huang Rui:
https://patchew.org/QEMU/2023091530.24064-1-ray.hu...@amd.com/



Yes, I forgot about that!



Virglrenderer 1.0.0 has been released as well. I wonder if that requires
any change in QEMU. Gert or Dmitry might know the answer.


No changes required afaik.




I have the added difficulty that the AmigaOS Picasso96 driver API
expects direct CPU access to all of VRAM, and likes to peek/poke
directly into the bitmaps. That's clearly not possible without blob
resources, or shared memory (not entirely sure what the shared memory
feature is for). This is why I want to know what features are stable or
coming soon.



The shared memory feature is just a requirement which enables support
for blob resources.


Now that we are in freeze, we won't merge new features until the end
of this year / next year. But we can already plan / test / review etc.

Antonio, do you have your work coordinated with Huang?

Huang, are you going to send a new version of the venus series?



I do not need to add anything. Huang, I believe you'll need to rebase as 
some commits in the series have been merged :)



It would be great to include docs/system/devices/virtio-gpu.rst
updates too. It's getting difficult to follow the various ways
virtio-gpu can be used nowadays.

thanks



Cheers,
Antonio



[PATCH] ui/console: fix default VC when there are no display

2023-11-08 Thread marcandre . lureau
From: Marc-André Lureau 

When display is "none", we may still have remote displays (I think it
would be simpler if VNC/Spice were regular display btw). Return the
default VC then, and set them up to fix a regression when using remote
display and it used the TTY instead.

Fixes: commit 1bec1cc0d ("ui/console: allow to override the default VC")
Reported-by: German Maglione 
Signed-off-by: Marc-André Lureau 
---
 system/vl.c  |  4 +++-
 ui/console.c | 14 --
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/system/vl.c b/system/vl.c
index bd7fad770b..8c522a07da 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -1359,6 +1359,7 @@ static void qemu_setup_display(void)
 dpy.type = DISPLAY_TYPE_NONE;
 #if defined(CONFIG_VNC)
 vnc_parse("localhost:0,to=99,id=default");
+display_remote++;
 #endif
 }
 }
@@ -1391,7 +1392,8 @@ static void qemu_create_default_devices(void)
 }
 }
 
-if (nographic || (!vc && !is_daemonized() && isatty(STDOUT_FILENO))) {
+if (nographic ||
+((!display_remote || !vc) && !is_daemonized() && 
isatty(STDOUT_FILENO))) {
 if (default_parallel) {
 add_device_config(DEV_PARALLEL, "null");
 }
diff --git a/ui/console.c b/ui/console.c
index 8e688d3569..f08c8365b0 100644
--- a/ui/console.c
+++ b/ui/console.c
@@ -1679,19 +1679,21 @@ void qemu_display_init(DisplayState *ds, DisplayOptions 
*opts)
 
 const char *qemu_display_get_vc(DisplayOptions *opts)
 {
+#ifdef CONFIG_PIXMAN
+const char *vc = "vc:80Cx24C";
+#else
+const char *vc = NULL;
+#endif
+
 assert(opts->type < DISPLAY_TYPE__MAX);
 if (opts->type == DISPLAY_TYPE_NONE) {
-return NULL;
+return vc;
 }
 assert(dpys[opts->type] != NULL);
 if (dpys[opts->type]->vc) {
 return dpys[opts->type]->vc;
-} else {
-#ifdef CONFIG_PIXMAN
-return "vc:80Cx24C";
-#endif
 }
-return NULL;
+return vc;
 }
 
 void qemu_display_help(void)
-- 
2.41.0




RE: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend

2023-11-08 Thread Duan, Zhenzhong



>-Original Message-
>From: Jason Gunthorpe 
>Sent: Wednesday, November 8, 2023 8:48 PM
>Subject: Re: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend
>
>On Wed, Nov 08, 2023 at 07:16:52AM +, Duan, Zhenzhong wrote:
>
>> >> +ret = iommufd_backend_alloc_hwpt(iommufd, vbasedev->devid,
>> >> + container->ioas_id, _id);
>> >> +
>> >> +if (ret) {
>> >> +error_setg_errno(errp, errno, "error alloc shadow hwpt");
>> >> +return ret;
>> >> +}
>> >
>> >The above alloc_hwpt fails for mdevs (at least, it fails for me attempting 
>> >to
>use
>> >iommufd backend with vfio-ccw and vfio-ap on s390).  The ioctl is failing 
>> >in the
>> >kernel because it can't find an IOMMUFD_OBJ_DEVICE.
>> >
>> >AFAIU that's because the mdevs are meant to instead use kernel access via
>> >vfio_iommufd_emulated_attach_ioas, not hwpt.  That's how mdevs behave
>when
>> >looking at the kernel vfio compat container.
>> >
>> >As a test, I was able to get vfio-ccw and vfio-ap working using the iommufd
>> >backend by just skipping this alloc_hwpt above and instead passing 
>> >container-
>> >>ioas_id into the iommufd_cdev_attach_hwpt below.  That triggers the
>> >vfio_iommufd_emulated_attach_ioas call in the kernel.
>>
>> Thanks for help test and investigation.
>> I was only focusing on real device and missed the mdev particularity, sorry.
>> You are right, there is no hwpt support for mdev, not even an emulated hwpt.
>> I'll digging into this and see how to distinguish mdev with real device in
>> this low level function.
>
>I was expecting that hwpt manipulation would be done exclusively
>inside the device-specific vIOMMU userspace driver. Generic code paths
>that don't have that knowledge should use the IOAS for everything

Yes, this way we don't need to distinguish between mdev and real device,
just attach to IOAS. But lose the benefit that same hwpt could be passed
into vIOMMU to be used as S2 hwpt in nesting.

If you don't have a strong opinion to use IOAS for everything, I'm thinking
about adding a bool variable is_mdev in VFIODevice, checking this bool
to decide if attach to manually allocated hwpt or IOAS.
For vfio-ap and vfio-ccw, is_mdev is set to true, for vfio-pci, we check
"/sys/bus/mdev" from vbasedev->sysfsdev to decide if it's true.

Another choice is to add VFIO_DEVICE_FLAGS_MDEV in vfio_device_info.flags
on kernel side, qemu can know if this device is mdev by checking the flag from
kernel, this works even in fd passing case.

Thanks
Zhenzhong



Re: [PATCH] tracetool: avoid invalid escape in Python string

2023-11-08 Thread Philippe Mathieu-Daudé

On 8/11/23 11:56, marcandre.lur...@redhat.com wrote:

From: Marc-André Lureau 

This is an error in Python 3.12; fix it by using a raw string literal.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau 
---
  scripts/tracetool/__init__.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Philippe Mathieu-Daudé 




Re: [PATCH v2] hw/ide/ahci: fix legacy software reset

2023-11-08 Thread Kevin Wolf
Am 08.11.2023 um 00:57 hat Niklas Cassel geschrieben:
> On Tue, Nov 07, 2023 at 07:14:07PM +0100, Kevin Wolf wrote:
> > Am 05.10.2023 um 12:04 hat Niklas Cassel geschrieben:
> > > From: Niklas Cassel 
> > > 
> > > Legacy software contains a standard mechanism for generating a reset to a
> > > Serial ATA device - setting the SRST (software reset) bit in the Device
> > > Control register.
> > > 
> > > Serial ATA has a more robust mechanism called COMRESET, also referred to
> > > as port reset. A port reset is the preferred mechanism for error
> > > recovery and should be used in place of software reset.
> > > 
> > > Commit e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
> > > improved the handling of PxCI, such that PxCI gets cleared after handling
> > > a non-NCQ, or NCQ command (instead of incorrectly clearing PxCI after
> > > receiving an arbitrary FIS).
> > > 
> > > However, simply clearing PxCI after a non-NCQ, or NCQ command, is not
> > > enough, we also need to clear PxCI when receiving a SRST in the Device
> > > Control register.
> > > 
> > > This fixes an issue for FreeBSD where the device would fail to reset.
> > > The problem was not noticed in Linux, because Linux uses a COMRESET
> > > instead of a legacy software reset by default.
> > > 
> > > Fixes: e2a5d9b3d9c3 ("hw/ide/ahci: simplify and document PxCI handling")
> > > Reported-by: Marcin Juszkiewicz 
> > > Signed-off-by: Niklas Cassel 
> > > ---
> > > Changes since v1: write the D2H FIS before clearing PxCI.
> > > 
> > >  hw/ide/ahci.c | 16 
> > >  1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> > > index babdd7b458..7269dabbdb 100644
> > > --- a/hw/ide/ahci.c
> > > +++ b/hw/ide/ahci.c
> > > @@ -1254,10 +1254,26 @@ static void handle_reg_h2d_fis(AHCIState *s, int 
> > > port,
> > >  case STATE_RUN:
> > >  if (cmd_fis[15] & ATA_SRST) {
> > >  s->dev[port].port_state = STATE_RESET;
> > > +/*
> > > + * When setting SRST in the first H2D FIS in the reset 
> > > sequence,
> > > + * the device does not send a D2H FIS. Host software 
> > > thus has to
> > > + * set the "Clear Busy upon R_OK" bit such that PxCI 
> > > (and BUSY)
> > > + * gets cleared. See AHCI 1.3.1, section 10.4.1 Software 
> > > Reset.
> > > + */
> > > +if (opts & AHCI_CMD_CLR_BUSY) {
> > > +ahci_clear_cmd_issue(ad, slot);
> > > +}
> > 
> > I suspect that AHCI_CMD_CLR_BUSY really should be checked in a more
> > generic place, but this will do for fixing software reset.
> 
> This weirdo option "Clear Busy upon R_OK" is for the HBA itself to
> clear the bit for the command in PxCI, when it gets the R_OK that the
> Host to Device (H2D) FIS was transmitted successfully to the device.
> The normal way is that the device sends back a Device to Host (D2H) FIS
> which then causes the bit in PxCI to be cleared in the HBA.
> 
> Yes, theoretically you could probably build a FIS that has the "Clear
> Busy upon R_OK" even for e.g. a regular non-NCQ I/O command (where
> PxCI/BUSY is first supposed to be cleared once the command is
> done...), however this would surely cause problems as PxCI would then
> no longer shadow the state of the device.
> 
> If you search for "Clear Busy upon R_OK", the only usage seems
> to be for legacy software reset.
> [...]

Yes, looks like ignoring it otherwise is harmless.

> > ahci_reset_port() already calls ahci_init_d2h() -> ahci_write_fis_d2h().
> > So I think this new ahci_write_fis_d2h() only sets some state that will
> > immediately be overwritten again. Which is good, because we didn't set
> > the signature as described in the SATA software reset protocol yet, that
> > is only done in ahci_reset_port().
> > 
> > Am I missing something? Why do we need this ahci_write_fis_d2h() call
> > here?
> > 
> > As for the ahci_clear_cmd_issue(), I'm surprised that ahci_reset_port()
> > doesn't already clear the register. Wouldn't it make more sense there
> > than just in this one caller?
> 
> A start/stop of the engine (PxCMD.ST) does clear PxCI, as I implemented in:
> https://github.com/qemu/qemu/commit/d73b84d0b664e60fffb66f46e84d0db4a8e1c713
> 
> But according to AHCI 1.3.1, section:
> 3.3.14 Offset 38h: PxCI – Port x Command Issue
> 
> PxCI does also have a reset value of 0h.
> 
> So I would assume that it is okay to clear PxCI to zero also in
> ahci_reset_port().

Yes, that was what I thought.

> By doing so, we could avoid both the ahci_clear_cmd_issue(),
> and the ahci_write_fis_d2h(ad, false).
> 
> Perhaps you can drop the "bonus" part of my patch and simply
> add a pr->cmd_issue to ahci_reset_port()?

I agree that this is probably the best change to make.

If you also want to add that comment that there already is a D2H FIS
sent during reset, and maybe change the commit message to explain why
we're 

Re: [PATCH v4 28/41] vfio/iommufd: Implement the iommufd backend

2023-11-08 Thread Jason Gunthorpe
On Wed, Nov 08, 2023 at 07:16:52AM +, Duan, Zhenzhong wrote:

> >> +ret = iommufd_backend_alloc_hwpt(iommufd, vbasedev->devid,
> >> + container->ioas_id, _id);
> >> +
> >> +if (ret) {
> >> +error_setg_errno(errp, errno, "error alloc shadow hwpt");
> >> +return ret;
> >> +}
> >
> >The above alloc_hwpt fails for mdevs (at least, it fails for me attempting 
> >to use
> >iommufd backend with vfio-ccw and vfio-ap on s390).  The ioctl is failing in 
> >the
> >kernel because it can't find an IOMMUFD_OBJ_DEVICE.
> >
> >AFAIU that's because the mdevs are meant to instead use kernel access via
> >vfio_iommufd_emulated_attach_ioas, not hwpt.  That's how mdevs behave when
> >looking at the kernel vfio compat container.
> >
> >As a test, I was able to get vfio-ccw and vfio-ap working using the iommufd
> >backend by just skipping this alloc_hwpt above and instead passing container-
> >>ioas_id into the iommufd_cdev_attach_hwpt below.  That triggers the
> >vfio_iommufd_emulated_attach_ioas call in the kernel.
> 
> Thanks for help test and investigation.
> I was only focusing on real device and missed the mdev particularity, sorry.
> You are right, there is no hwpt support for mdev, not even an emulated hwpt.
> I'll digging into this and see how to distinguish mdev with real device in
> this low level function.

I was expecting that hwpt manipulation would be done exclusively
inside the device-specific vIOMMU userspace driver. Generic code paths
that don't have that knowledge should use the IOAS for everything

Jason



[PATCH 1/1] Changed the way aclint gets CPUState from hartid-base to cpu_index

2023-11-08 Thread Leo Hou
From: Leo Hou 

cpu_by_arch_id() uses hartid-base as the index to obtain the corresponding 
CPUState structure variable.
qemu_get_cpu() uses cpu_index as the index to obtain the corresponding CPUState 
structure variable.

In heterogeneous CPU or multi-socket scenarios, multiple aclint needs to be 
instantiated,
and the hartid-base of each cpu bound by aclint can start from 0. If 
cpu_by_arch_id() is still used
in this case, all aclint will bind to the earliest initialized hart with 
hartid-base 0 and cause conflicts.

So with cpu_index as the index, use qemu_get_cpu() to get the CPUState struct 
variable,
and connect the aclint interrupt line to the hart of the CPU indexed with 
cpu_index
(the corresponding hartid-base can start at 0). It's more reasonable.

Signed-off-by: Leo Hou 
---
 hw/intc/riscv_aclint.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/hw/intc/riscv_aclint.c b/hw/intc/riscv_aclint.c
index ab1a0b4b3a..be8f539fcb 100644
--- a/hw/intc/riscv_aclint.c
+++ b/hw/intc/riscv_aclint.c
@@ -130,7 +130,7 @@ static uint64_t riscv_aclint_mtimer_read(void *opaque, 
hwaddr addr,
 addr < (mtimer->timecmp_base + (mtimer->num_harts << 3))) {
 size_t hartid = mtimer->hartid_base +
 ((addr - mtimer->timecmp_base) >> 3);
-CPUState *cpu = cpu_by_arch_id(hartid);
+CPUState *cpu = qemu_get_cpu(hartid);
 CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
 if (!env) {
 qemu_log_mask(LOG_GUEST_ERROR,
@@ -173,7 +173,7 @@ static void riscv_aclint_mtimer_write(void *opaque, hwaddr 
addr,
 addr < (mtimer->timecmp_base + (mtimer->num_harts << 3))) {
 size_t hartid = mtimer->hartid_base +
 ((addr - mtimer->timecmp_base) >> 3);
-CPUState *cpu = cpu_by_arch_id(hartid);
+CPUState *cpu = qemu_get_cpu(hartid);
 CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
 if (!env) {
 qemu_log_mask(LOG_GUEST_ERROR,
@@ -232,7 +232,7 @@ static void riscv_aclint_mtimer_write(void *opaque, hwaddr 
addr,
 
 /* Check if timer interrupt is triggered for each hart. */
 for (i = 0; i < mtimer->num_harts; i++) {
-CPUState *cpu = cpu_by_arch_id(mtimer->hartid_base + i);
+CPUState *cpu = qemu_get_cpu(mtimer->hartid_base + i);
 CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
 if (!env) {
 continue;
@@ -293,7 +293,7 @@ static void riscv_aclint_mtimer_realize(DeviceState *dev, 
Error **errp)
 s->timecmp = g_new0(uint64_t, s->num_harts);
 /* Claim timer interrupt bits */
 for (i = 0; i < s->num_harts; i++) {
-RISCVCPU *cpu = RISCV_CPU(cpu_by_arch_id(s->hartid_base + i));
+RISCVCPU *cpu = RISCV_CPU(qemu_get_cpu(s->hartid_base + i));
 if (riscv_cpu_claim_interrupts(cpu, MIP_MTIP) < 0) {
 error_report("MTIP already claimed");
 exit(1);
@@ -373,7 +373,7 @@ DeviceState *riscv_aclint_mtimer_create(hwaddr addr, hwaddr 
size,
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, addr);
 
 for (i = 0; i < num_harts; i++) {
-CPUState *cpu = cpu_by_arch_id(hartid_base + i);
+CPUState *cpu = qemu_get_cpu(hartid_base + i);
 RISCVCPU *rvcpu = RISCV_CPU(cpu);
 CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
 riscv_aclint_mtimer_callback *cb =
@@ -408,7 +408,7 @@ static uint64_t riscv_aclint_swi_read(void *opaque, hwaddr 
addr,
 
 if (addr < (swi->num_harts << 2)) {
 size_t hartid = swi->hartid_base + (addr >> 2);
-CPUState *cpu = cpu_by_arch_id(hartid);
+CPUState *cpu = qemu_get_cpu(hartid);
 CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
 if (!env) {
 qemu_log_mask(LOG_GUEST_ERROR,
@@ -431,7 +431,7 @@ static void riscv_aclint_swi_write(void *opaque, hwaddr 
addr, uint64_t value,
 
 if (addr < (swi->num_harts << 2)) {
 size_t hartid = swi->hartid_base + (addr >> 2);
-CPUState *cpu = cpu_by_arch_id(hartid);
+CPUState *cpu = qemu_get_cpu(hartid);
 CPURISCVState *env = cpu ? cpu_env(cpu) : NULL;
 if (!env) {
 qemu_log_mask(LOG_GUEST_ERROR,
@@ -546,7 +546,7 @@ DeviceState *riscv_aclint_swi_create(hwaddr addr, uint32_t 
hartid_base,
 sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, addr);
 
 for (i = 0; i < num_harts; i++) {
-CPUState *cpu = cpu_by_arch_id(hartid_base + i);
+CPUState *cpu = qemu_get_cpu(hartid_base + i);
 RISCVCPU *rvcpu = RISCV_CPU(cpu);
 
 qdev_connect_gpio_out(dev, i,
-- 
2.34.1




Re: [PULL 00/23] Final test, gdbstub, plugin and gitdm updates for 8.2

2023-11-08 Thread Stefan Hajnoczi
On Tue, 7 Nov 2023 at 22:25, Alex Bennée  wrote:
>
> The following changes since commit 462ad017ed76889d46696a3581e1b52343f9b683:
>
>   Merge tag 'pixman-pull-request' of https://gitlab.com/marcandre.lureau/qemu 
> into staging (2023-11-07 19:00:03 +0800)
>
> are available in the Git repository at:
>
>   https://gitlab.com/stsquad/qemu.git tags/pull-halloween-omnibus-071123-1
>
> for you to fetch changes up to 00da668de6856d912cd75474ba759927e29d0e49:
>
>   Revert "tests/tcg/nios2: Re-enable linux-user tests" (2023-11-07 14:18:29 
> +)
>
> 
> Final test, gdbstub, plugin and gitdm updates for 8.2
>
>   - fix duplicate register in arm xml
>   - hide various duplicate system registers from gdbstub
>   - add new gdb register test to the CI (skipping s390x/ppc64 for now)
>   - introduce GDBFeatureBuilder
>   - move plugin initialisation to after vCPU init completes
>   - enable building TCG plugins on Windows platform

Hi Alex,
Please take a look at the following CI failure:

i686-w64-mingw32-gcc -m32 -o tests/plugin/libempty.dll
plugins/qemu_plugin_api.lib tests/plugin/libempty.dll.p/empty.c.obj
tests/plugin/libempty.dll.p/.._.._contrib_plugins_win32_linker.c.obj
-Wl,--allow-shlib-undefined -shared -Wl,--start-group
-Wl,--out-implib=tests/plugin/libempty.dll.a -fstack-protector-strong
-Wl,--no-seh -Wl,--nxcompat -Wl,--dynamicbase -Wl,--warn-common
/usr/i686-w64-mingw32/sys-root/mingw/lib/libglib-2.0.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libintl.dll.a
/usr/i686-w64-mingw32/sys-root/mingw/lib/libgmodule-2.0.dll.a
-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
-luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
/usr/lib/gcc/i686-w64-mingw32/12.2.1/../../../../i686-w64-mingw32/bin/ld:
tests/plugin/libempty.dll.p/empty.c.obj: in function
`qemu_plugin_install':
/builds/qemu-project/qemu/build/../tests/plugin/empty.c:30: undefined
reference to `_imp__qemu_plugin_register_vcpu_tb_trans_cb'
collect2: error: ld returned 1 exit status

https://gitlab.com/qemu-project/qemu/-/jobs/5487689202

Thanks,
Stefan

>   - various gitdm updates
>   - some mailmap fixes
>   - disable testing for nios2 signals which have regressed
>
> 
> Akihiko Odaki (5):
>   default-configs: Add TARGET_XML_FILES definition
>   gdbstub: Add num_regs member to GDBFeature
>   gdbstub: Introduce gdb_find_static_feature()
>   gdbstub: Introduce GDBFeatureBuilder
>   cpu: Call plugin hooks only when ready
>
> Alex Bennée (13):
>   gdb-xml: fix duplicate register in arm-neon.xml
>   target/arm: mark the 32bit alias of PAR when LPAE enabled
>   target/arm: hide all versions of DBGD[RS]AR from gdbstub
>   target/arm: hide aliased MIDR from gdbstub
>   tests/tcg: add an explicit gdbstub register tester
>   tests/avocado: update the tcg_plugins test
>   configure: tell meson and contrib_plugins about DLLTOOL
>   gitlab: add dlltool to Windows CI
>   contrib/gitdm: Add Rivos Inc to the domain map
>   contrib/gitdm: map HiSilicon to Huawei
>   contrib/gitdm: add Daynix to domain-map
>   mailmap: fixup some more corrupted author fields
>   Revert "tests/tcg/nios2: Re-enable linux-user tests"
>
> Greg Manning (4):
>   plugins: add dllexport and dllimport to api funcs
>   plugins: make test/example plugins work on windows
>   plugins: disable lockstep plugin on windows
>   plugins: allow plugins to be enabled on windows
>
> luzhipeng (1):
>   contrib/gitdm: add domain-map for Cestc
>
>  MAINTAINERS|   2 +-
>  configure  |  13 +-
>  configs/targets/loongarch64-linux-user.mak |   1 +
>  meson.build|   5 +
>  include/exec/gdbstub.h |  59 ++
>  include/qemu/qemu-plugin.h |  50 +-
>  contrib/plugins/win32_linker.c |  34 
>  cpu-target.c   |  11 --
>  gdbstub/gdbstub.c  |  78 
>  hw/core/cpu-common.c   |  10 ++
>  target/arm/debug_helper.c  |  10 +-
>  target/arm/helper.c|  37 ++--
>  .gitlab-ci.d/windows.yml   |   1 +
>  .mailmap   |   2 +
>  contrib/gitdm/domain-map   |   4 +
>  contrib/plugins/Makefile   |  26 ++-
>  gdb-xml/arm-neon.xml   |   2 +-
>  plugins/meson.build|  19 ++
>  scripts/feature_to_c.py|  46 -
>  tests/avocado/tcg_plugins.py   |  28 +--
>  tests/plugin/meson.build   |  14 +-
>  

Re: [PATCH 14/22] plugins: make test/example plugins work on windows

2023-11-08 Thread Paolo Bonzini
On Tue, Nov 7, 2023 at 1:43 PM Greg Manning  wrote:
> Windows will look for __pfnDliFailureHook2 in the module doing the delay
> loading, which in this case is the plugin DLL.

Fair enough, this is what was not clear from the Microsoft docs.

Paolo




Re: virtio...@redhat.com bouncing

2023-11-08 Thread Mauro Matteo Cascella
Hi,

On Wed, Nov 8, 2023 at 12:40 PM Stefan Hajnoczi  wrote:
>
> On Wed, 8 Nov 2023 at 19:05, Philippe Mathieu-Daudé  wrote:
> >
> > Hi Stefan,
> >
> > You are listed as virtiofs maintainer, see MAINTAINERS:
> >
> >virtiofs
> >M: Stefan Hajnoczi 
> >S: Supported
> >F: hw/virtio/vhost-user-fs*
> >F: include/hw/virtio/vhost-user-fs.h
> >L: virtio...@redhat.com
> >
> > Mails sent to this list address are bouncing:
> >
> > : host int-mx-rdu2.corp.redhat.com[10.11.203.6]
> > said: 550
> >  5.1.1 : Recipient address rejected: User
> > unknown in
> >  local recipient table (in reply to RCPT TO command)
> >
> > Maybe the list need to be updated, like Daniel did with libvir-list@?
> > https://lore.kernel.org/qemu-devel/20231027095643.2842382-1-berra...@redhat.com/
>
> Yes, it does. The new mailing list address has not been created yet.
> I'll update the MAINTAINERS file when the new mailing list becomes
> available in the coming days.
>
> > Looking at other lists, I also see secalert@:
> >
> >$ git grep L:.*redhat MAINTAINERS
> >MAINTAINERS:86:L: secal...@redhat.com
> >MAINTAINERS:2231:L: virtio...@redhat.com
> >
> > So Cc'ing Michael / Mauro.
>
> I'm not sure about secalert. Thanks for CCing Michael and Mauro.

secalert@ is regularly monitored and working fine. Perhaps we can add
qemu-secur...@nongnu.org, in addition to secalert, to match what's
stated in the 'Security Process' page.

```
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e8a7d5be5..af74d5487f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -83,6 +83,7 @@ Responsible Disclosure, Reporting Security Issues
 -
 W: https://wiki.qemu.org/SecurityProcess
 M: Michael S. Tsirkin 
+L: qemu-secur...@nongnu.org
 L: secal...@redhat.com

 Trivial patches
```

> Thanks,
> Stefan
>

Thank you,
-- 
Mauro Matteo Cascella
Red Hat Product Security
PGP-Key ID: BB3410B0




Re: virtio...@redhat.com bouncing

2023-11-08 Thread Stefan Hajnoczi
On Wed, 8 Nov 2023 at 19:05, Philippe Mathieu-Daudé  wrote:
>
> Hi Stefan,
>
> You are listed as virtiofs maintainer, see MAINTAINERS:
>
>virtiofs
>M: Stefan Hajnoczi 
>S: Supported
>F: hw/virtio/vhost-user-fs*
>F: include/hw/virtio/vhost-user-fs.h
>L: virtio...@redhat.com
>
> Mails sent to this list address are bouncing:
>
> : host int-mx-rdu2.corp.redhat.com[10.11.203.6]
> said: 550
>  5.1.1 : Recipient address rejected: User
> unknown in
>  local recipient table (in reply to RCPT TO command)
>
> Maybe the list need to be updated, like Daniel did with libvir-list@?
> https://lore.kernel.org/qemu-devel/20231027095643.2842382-1-berra...@redhat.com/

Yes, it does. The new mailing list address has not been created yet.
I'll update the MAINTAINERS file when the new mailing list becomes
available in the coming days.

> Looking at other lists, I also see secalert@:
>
>$ git grep L:.*redhat MAINTAINERS
>MAINTAINERS:86:L: secal...@redhat.com
>MAINTAINERS:2231:L: virtio...@redhat.com
>
> So Cc'ing Michael / Mauro.

I'm not sure about secalert. Thanks for CCing Michael and Mauro.

Thanks,
Stefan



Re: [PATCH] Fix Windows 2000 and XP HDAudio Support

2023-11-08 Thread Gerd Hoffmann
On Wed, Nov 08, 2023 at 11:02:06AM +0100, Philippe Mathieu-Daudé wrote:
> Thanks Christopher for your patch,
> 
> I'm Cc'ing Volker and Gerd who know better this hardware model.
> 
> On 7/11/23 20:27, Christopher Lentocha wrote:
> > 
> > Change the ID to be a Realtek ALC885 so that both

No.  Rewriting the existing codecs is clearly a non-starter.

You can add a 'hda-realtek-alc885' variant which tries to
mimic the realtek coded close enough to make old guests
without generic hda driver happy.

> > +#define QEMU_HDA_ID 0x10EC0885

Nope.  Somemething like 'REALTEK_ALC885_ID' please.

[ remaining bits of the patch snipped, needs major rework ]

take care,
  Gerd




Re: QEMU Virtio GPU features status & roadmap?

2023-11-08 Thread Marc-André Lureau
Hi

On Wed, Nov 8, 2023 at 1:04 PM Antonio Caggiano
 wrote:
>
> Hi Hans,
>
> +cc Gert and Dmitry
>
> On 17/10/2023 02:48, Hans de Ruiter wrote:
> > Hi,
> >
> > I'm working on Virtio GPU drivers for AmigaOS, and would like to know
> > what features are currently stable enough to use. Looking at the master
> > QEMU branch, both Virgl and blob resources are supported, but NOT at the
> > same time. Is the ability to use both simultaneously coming soon?
> >
>
> Mmh, well, they should be compatible, I'll try sending a patch.
>
> > Also, what's the state of Venus/Vulkan support? Surveying various
> > forks/branches, it looks very experimental and subject to change.
> >
>
> I believe this is quite stable now:
> https://gitlab.freedesktop.org/virgl/venus-protocol/-/issues/5

The last patch series for QEMU is from Huang Rui:
https://patchew.org/QEMU/2023091530.24064-1-ray.hu...@amd.com/

>
> Virglrenderer 1.0.0 has been released as well. I wonder if that requires
> any change in QEMU. Gert or Dmitry might know the answer.

No changes required afaik.

>
> > I have the added difficulty that the AmigaOS Picasso96 driver API
> > expects direct CPU access to all of VRAM, and likes to peek/poke
> > directly into the bitmaps. That's clearly not possible without blob
> > resources, or shared memory (not entirely sure what the shared memory
> > feature is for). This is why I want to know what features are stable or
> > coming soon.
> >
>
> The shared memory feature is just a requirement which enables support
> for blob resources.

Now that we are in freeze, we won't merge new features until the end
of this year / next year. But we can already plan / test / review etc.

Antonio, do you have your work coordinated with Huang?

Huang, are you going to send a new version of the venus series?

It would be great to include docs/system/devices/virtio-gpu.rst
updates too. It's getting difficult to follow the various ways
virtio-gpu can be used nowadays.

thanks

-- 
Marc-André Lureau



virtio...@redhat.com bouncing

2023-11-08 Thread Philippe Mathieu-Daudé

Hi Stefan,

You are listed as virtiofs maintainer, see MAINTAINERS:

  virtiofs
  M: Stefan Hajnoczi 
  S: Supported
  F: hw/virtio/vhost-user-fs*
  F: include/hw/virtio/vhost-user-fs.h
  L: virtio...@redhat.com

Mails sent to this list address are bouncing:

: host int-mx-rdu2.corp.redhat.com[10.11.203.6] 
said: 550
5.1.1 : Recipient address rejected: User 
unknown in

local recipient table (in reply to RCPT TO command)

Maybe the list need to be updated, like Daniel did with libvir-list@?
https://lore.kernel.org/qemu-devel/20231027095643.2842382-1-berra...@redhat.com/

Looking at other lists, I also see secalert@:

  $ git grep L:.*redhat MAINTAINERS
  MAINTAINERS:86:L: secal...@redhat.com
  MAINTAINERS:2231:L: virtio...@redhat.com

So Cc'ing Michael / Mauro.

Regards,

Phil.



RE: [PATCH V6 7/9] hw/acpi: Update ACPI GED framework to support vCPU Hotplug

2023-11-08 Thread Salil Mehta via
Hi Igor,

> From: Igor Mammedov 
> Sent: Friday, October 27, 2023 2:18 PM
> To: Salil Mehta 
> Cc: qemu-devel@nongnu.org; qemu-...@nongnu.org; m...@kernel.org; jean-
> phili...@linaro.org; Jonathan Cameron ;
> lpieral...@kernel.org; peter.mayd...@linaro.org;
> richard.hender...@linaro.org; andrew.jo...@linux.dev; da...@redhat.com;
> phi...@linaro.org; eric.au...@redhat.com; oliver.up...@linux.dev;
> pbonz...@redhat.com; m...@redhat.com; w...@kernel.org; gs...@redhat.com;
> raf...@kernel.org; alex.ben...@linaro.org; li...@armlinux.org.uk;
> dar...@os.amperecomputing.com; il...@os.amperecomputing.com;
> vis...@os.amperecomputing.com; karl.heub...@oracle.com;
> miguel.l...@oracle.com; salil.me...@opnsrc.net; zhukeqian
> ; wangxiongfeng (C) ;
> wangyanan (Y) ; jiakern...@gmail.com;
> maob...@loongson.cn; lixiang...@loongson.cn; Linuxarm 
> Subject: Re: [PATCH V6 7/9] hw/acpi: Update ACPI GED framework to support
> vCPU Hotplug
> 
> On Fri, 13 Oct 2023 11:51:27 +0100
> Salil Mehta  wrote:
> 
> > ACPI GED shall be used to convey to the guest kernel about any CPU 
> > hot-(un)plug
> > events. Therefore, existing ACPI GED framework inside QEMU needs to be 
> > enhanced
> > to support CPU hotplug state and events.
> >
> 
> This is a part of hw wiring which you started to introduce in 4/9
> Given patches are small, I'd merge this into 4/9 to avoid broken context.
> So essentially GED improvement would consist from hw and aml parts.
> with some extra refactoring (5/9) in a separate patch.


No issues. Will merge.

Thanks
Salil.

> > Co-developed-by: Keqian Zhu 
> > Signed-off-by: Keqian Zhu 
> > Signed-off-by: Salil Mehta 
> > Reviewed-by: Jonathan Cameron 
> > Reviewed-by: Gavin Shan 
> > Tested-by: Vishnu Pajjuri 
> > Tested-by: Xianglai Li 
> > ---
> >  hw/acpi/generic_event_device.c | 10 ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/hw/acpi/generic_event_device.c b/hw/acpi/generic_event_device.c
> > index 62d504d231..0d5f0140e5 100644
> > --- a/hw/acpi/generic_event_device.c
> > +++ b/hw/acpi/generic_event_device.c
> > @@ -12,6 +12,7 @@
> >  #include "qemu/osdep.h"
> >  #include "qapi/error.h"
> >  #include "hw/acpi/acpi.h"
> > +#include "hw/acpi/cpu.h"
> >  #include "hw/acpi/generic_event_device.h"
> >  #include "hw/irq.h"
> >  #include "hw/mem/pc-dimm.h"
> > @@ -239,6 +240,8 @@ static void acpi_ged_device_plug_cb(HotplugHandler 
> > *hotplug_dev,
> >  } else {
> >  acpi_memory_plug_cb(hotplug_dev, >memhp_state, dev, errp);
> >  }
> > +} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
> > +acpi_cpu_plug_cb(hotplug_dev, >cpuhp_state, dev, errp);
> >  } else {
> >  error_setg(errp, "virt: device plug request for unsupported device"
> > " type: %s", object_get_typename(OBJECT(dev)));
> > @@ -253,6 +256,8 @@ static void acpi_ged_unplug_request_cb(HotplugHandler 
> > *hotplug_dev,
> >  if ((object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM) &&
> > !(object_dynamic_cast(OBJECT(dev), TYPE_NVDIMM {
> >  acpi_memory_unplug_request_cb(hotplug_dev, >memhp_state, dev, 
> > errp);
> > +} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
> > +acpi_cpu_unplug_request_cb(hotplug_dev, >cpuhp_state, dev, 
> > errp);
> >  } else {
> >  error_setg(errp, "acpi: device unplug request for unsupported 
> > device"
> > " type: %s", object_get_typename(OBJECT(dev)));
> > @@ -266,6 +271,8 @@ static void acpi_ged_unplug_cb(HotplugHandler 
> > *hotplug_dev,
> >
> >  if (object_dynamic_cast(OBJECT(dev), TYPE_PC_DIMM)) {
> >  acpi_memory_unplug_cb(>memhp_state, dev, errp);
> > +} else if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
> > +acpi_cpu_unplug_cb(>cpuhp_state, dev, errp);
> >  } else {
> >  error_setg(errp, "acpi: device unplug for unsupported device"
> > " type: %s", object_get_typename(OBJECT(dev)));
> > @@ -277,6 +284,7 @@ static void acpi_ged_ospm_status(AcpiDeviceIf *adev, 
> > ACPIOSTInfoList ***list)
> >  AcpiGedState *s = ACPI_GED(adev);
> >
> >  acpi_memory_ospm_status(>memhp_state, list);
> > +acpi_cpu_ospm_status(>cpuhp_state, list);
> >  }
> >
> >  static void acpi_ged_send_event(AcpiDeviceIf *adev, AcpiEventStatusBits ev)
> > @@ -291,6 +299,8 @@ static void acpi_ged_send_event(AcpiDeviceIf *adev, 
> > AcpiEventStatusBits ev)
> >  sel = ACPI_GED_PWR_DOWN_EVT;
> >  } else if (ev & ACPI_NVDIMM_HOTPLUG_STATUS) {
> >  sel = ACPI_GED_NVDIMM_HOTPLUG_EVT;
> > +} else if (ev & ACPI_CPU_HOTPLUG_STATUS) {
> > +sel = ACPI_GED_CPU_HOTPLUG_EVT;
> >  } else {
> >  /* Unknown event. Return without generating interrupt. */
> >  warn_report("GED: Unsupported event %d. No irq injected", ev);




[PATCH] tracetool: avoid invalid escape in Python string

2023-11-08 Thread marcandre . lureau
From: Marc-André Lureau 

This is an error in Python 3.12; fix it by using a raw string literal.

Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau 
---
 scripts/tracetool/__init__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index b29594d75e..b887540a55 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -91,7 +91,7 @@ def out(*lines, **kwargs):
 def validate_type(name):
 bits = name.split(" ")
 for bit in bits:
-bit = re.sub("\*", "", bit)
+bit = re.sub(r"\*", "", bit)
 if bit == "":
 continue
 if bit == "const":
-- 
2.41.0




Re: [PATCH] vl: constify default_list

2023-11-08 Thread Philippe Mathieu-Daudé

On 30/10/23 11:19, Philippe Mathieu-Daudé wrote:

On 30/10/23 11:15, marcandre.lur...@redhat.com wrote:

From: Marc-André Lureau 

It's not modified, let's make it const.

Signed-off-by: Marc-André Lureau 
---
  system/vl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Philippe Mathieu-Daudé 


... and queued via my cpu/misc tree, thanks!





  1   2   >