Re: [PATCH] Deprecate the "-no-acpi" command line switch

[Sunil V L]

On Fri, Feb 24, 2023 at 08:34:41AM +0100, Thomas Huth wrote:
> Similar to "-no-hpet", the "-no-acpi" switch is a legacy command
> line option that should be replaced with the "acpi" machine parameter
> nowadays.
> 
> Signed-off-by: Thomas Huth 
> ---
>  docs/about/deprecated.rst | 6 ++
>  softmmu/vl.c  | 1 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index ee95bcb1a6..15084f7bea 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -99,6 +99,12 @@ form is preferred.
>  The HPET setting has been turned into a machine property.
>  Use ``-machine hpet=off`` instead.
>  
> +``-no-acpi`` (since 8.0)
> +
> +
> +The ``-no-acpi`` setting has been turned into a machine property.
> +Use ``-machine acpi=off`` instead.
> +
>  ``-accel hax`` (since 8.0)
>  ''
>  
> diff --git a/softmmu/vl.c b/softmmu/vl.c
> index 459588aa7d..07d5215325 100644
> --- a/softmmu/vl.c
> +++ b/softmmu/vl.c
> @@ -3271,6 +3271,7 @@ void qemu_init(int argc, char **argv)
>  vnc_parse(optarg);
>  break;
>  case QEMU_OPTION_no_acpi:
> +warn_report("-no-hpet is deprecated, use '-machine acpi=off' 
> instead");

"no-acpi" is deprecated? 

Is my understanding correct that there is no need to update qemu-options.hx ?

Thanks,
Sunil

Re: [PATCH v5 5/5] dump: Add create_win_dump() stub for non-x86 targets

[Thomas Huth]

On 24/02/2023 08.38, Philippe Mathieu-Daudé wrote:

Implement the non-x86 create_win_dump(). We can remove
the last TARGET_X86_64 #ifdef'ry in dump.c, which thus
becomes target-independent. Update meson accordingly.

Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/dump.c  | 2 --
  dump/meson.build | 2 +-
  dump/win_dump.c  | 5 +
  3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index 0c96c6e735..7260558852 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -2020,9 +2020,7 @@ static void dump_process(DumpState *s, Error **errp)
  DumpQueryResult *result = NULL;
  
  if (s->has_format && s->format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP) {

-#ifdef TARGET_X86_64
  create_win_dump(s, errp);
-#endif
  } else if (s->has_format && s->format != DUMP_GUEST_MEMORY_FORMAT_ELF) {
  create_kdump_vmcore(s, errp);
  } else {
diff --git a/dump/meson.build b/dump/meson.build
index f13b29a849..7b116f1bd7 100644
--- a/dump/meson.build
+++ b/dump/meson.build
@@ -1,4 +1,4 @@
  softmmu_ss.add(files('dump-hmp-cmds.c'))
  
-specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, lzo])

+softmmu_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, lzo])
  specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: files('win_dump.c'))
diff --git a/dump/win_dump.c b/dump/win_dump.c
index ff9c5bd339..0152f7330a 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump.c
@@ -487,4 +487,9 @@ bool win_dump_available(Error **errp)
  return false;
  }
  
+void create_win_dump(DumpState *s, Error **errp)

+{
+win_dump_available(errp);
+}
+
  #endif


Looks good now, indeed! Thanks for tackling this!

 Thomas

Re: [PATCH v5 4/5] dump: Introduce win_dump_available()

[Thomas Huth]

On 24/02/2023 08.38, Philippe Mathieu-Daudé wrote:

Remove a pair of TARGET_X86_64 #ifdef'ry by introducing
the win_dump_available() method. Doing so we can build
win_dump.c on any target, and simplify the meson rule.


Nit: The commit description is a little bit misleading now since you 
introduce the #ifdef in win_dump.c instead. Maybe rather something like:


To make dump.c less target dependent, move the TARGET_X86_64 #ifdef'ry from 
dump.c to win_dump.c (and introduce a win_dump_available() method there). By 
doing so we can build win_dump.c on any target, and simplify the meson rule.


Anyway, you can keep my Reviewed-by here.

 Thomas

Re: [PATCH v3 1/2] linux-user: Fix unaligned memory access in prlimit64 syscall

[Philippe Mathieu-Daudé]

On 24/2/23 01:39, Ilya Leoshkevich wrote:

target_rlimit64 contains uint64_t fields, so it's 8-byte aligned on
some hosts, while some guests may align their respective type on a
4-byte boundary. This may lead to an unaligned access, which is an UB.

Fix by defining the fields as abi_ullong. This makes the host alignment
match that of the guest, and lets the compiler know that it should emit
code that can deal with the guest alignment.

While at it, also use __get_user() and __put_user() instead of
tswap64().

Fixes: 163a05a8398b ("linux-user: Implement prlimit64 syscall")
Reported-by: Richard Henderson 
Signed-off-by: Ilya Leoshkevich 
---
  linux-user/generic/target_resource.h | 4 ++--
  linux-user/syscall.c | 8 
  2 files changed, 6 insertions(+), 6 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH] Deprecate the "-no-acpi" command line switch

[Philippe Mathieu-Daudé]

On 24/2/23 08:34, Thomas Huth wrote:

Similar to "-no-hpet", the "-no-acpi" switch is a legacy command
line option that should be replaced with the "acpi" machine parameter
nowadays.

Signed-off-by: Thomas Huth 
---
  docs/about/deprecated.rst | 6 ++
  softmmu/vl.c  | 1 +
  2 files changed, 7 insertions(+)


Reviewed-by: Philippe Mathieu-Daudé 

[PATCH v5 4/5] dump: Introduce win_dump_available()

[Philippe Mathieu-Daudé]

Remove a pair of TARGET_X86_64 #ifdef'ry by introducing
the win_dump_available() method. Doing so we can build
win_dump.c on any target, and simplify the meson rule.

Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/dump.c  | 16 +---
 dump/meson.build |  2 +-
 dump/win_dump.c  | 18 ++
 dump/win_dump.h  |  3 +++
 4 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index a84f78738a..0c96c6e735 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -28,10 +28,7 @@
 #include "hw/misc/vmcoreinfo.h"
 #include "migration/blocker.h"
 #include "hw/core/cpu.h"
-
-#ifdef TARGET_X86_64
 #include "win_dump.h"
-#endif
 
 #include 
 #ifdef CONFIG_LZO
@@ -2128,12 +2125,10 @@ void qmp_dump_guest_memory(bool paging, const char 
*file,
 }
 #endif
 
-#ifndef TARGET_X86_64
-if (has_format && format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP) {
-error_setg(errp, "Windows dump is only available for x86-64");
+if (has_format && format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP
+&& !win_dump_available(errp)) {
 return;
 }
-#endif
 
 #if !defined(WIN32)
 if (strstart(file, "fd:", )) {
@@ -2215,10 +2210,9 @@ DumpGuestMemoryCapability 
*qmp_query_dump_guest_memory_capability(Error **errp)
 QAPI_LIST_APPEND(tail, DUMP_GUEST_MEMORY_FORMAT_KDUMP_SNAPPY);
 #endif
 
-/* Windows dump is available only if target is x86_64 */
-#ifdef TARGET_X86_64
-QAPI_LIST_APPEND(tail, DUMP_GUEST_MEMORY_FORMAT_WIN_DMP);
-#endif
+if (win_dump_available(NULL)) {
+QAPI_LIST_APPEND(tail, DUMP_GUEST_MEMORY_FORMAT_WIN_DMP);
+}
 
 return cap;
 }
diff --git a/dump/meson.build b/dump/meson.build
index 2eff29c3ea..f13b29a849 100644
--- a/dump/meson.build
+++ b/dump/meson.build
@@ -1,4 +1,4 @@
 softmmu_ss.add(files('dump-hmp-cmds.c'))
 
 specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, 
lzo])
-specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'], if_true: 
files('win_dump.c'))
+specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: files('win_dump.c'))
diff --git a/dump/win_dump.c b/dump/win_dump.c
index ba7fa404fe..ff9c5bd339 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump.c
@@ -18,6 +18,13 @@
 #include "win_dump.h"
 #include "cpu.h"
 
+#if defined(TARGET_X86_64)
+
+bool win_dump_available(Error **errp)
+{
+return true;
+}
+
 static size_t win_dump_ptr_size(bool x64)
 {
 return x64 ? sizeof(uint64_t) : sizeof(uint32_t);
@@ -470,3 +477,14 @@ out_cr3:
 
 return;
 }
+
+#else /* !TARGET_X86_64 */
+
+bool win_dump_available(Error **errp)
+{
+error_setg(errp, "Windows dump is only available for x86-64");
+
+return false;
+}
+
+#endif
diff --git a/dump/win_dump.h b/dump/win_dump.h
index 56f63683c3..c9b49f87dc 100644
--- a/dump/win_dump.h
+++ b/dump/win_dump.h
@@ -13,6 +13,9 @@
 
 #include "sysemu/dump.h"
 
+/* Check Windows dump availability for the current target */
+bool win_dump_available(Error **errp);
+
 void create_win_dump(DumpState *s, Error **errp);
 
 #endif /* WIN_DUMP_H */
-- 
2.38.1

[PATCH v5 1/5] dump: Replace tswapN() -> cpu_to_dumpN()

[Philippe Mathieu-Daudé]

All uses of tswap in that file are wrong, and should be using
cpu_to_dumpN, which correctly tests the endianness of the output.

Suggested-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
---
 dump/dump.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index 279b07f09b..7101169ecb 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -907,13 +907,13 @@ static void get_note_sizes(DumpState *s, const void *note,
 if (dump_is_64bit(s)) {
 const Elf64_Nhdr *hdr = note;
 note_head_sz = sizeof(Elf64_Nhdr);
-name_sz = tswap64(hdr->n_namesz);
-desc_sz = tswap64(hdr->n_descsz);
+name_sz = cpu_to_dump64(s, hdr->n_namesz);
+desc_sz = cpu_to_dump64(s, hdr->n_descsz);
 } else {
 const Elf32_Nhdr *hdr = note;
 note_head_sz = sizeof(Elf32_Nhdr);
-name_sz = tswap32(hdr->n_namesz);
-desc_sz = tswap32(hdr->n_descsz);
+name_sz = cpu_to_dump32(s, hdr->n_namesz);
+desc_sz = cpu_to_dump32(s, hdr->n_descsz);
 }
 
 if (note_head_size) {
-- 
2.38.1

[PATCH v5 0/5] dump: Make most of it target agnostic (build once)

[Philippe Mathieu-Daudé]

Since v4:
- more unused headers removed
- KISS, use a bit of #ifdef'ry to avoid a stub file

Thanks to Richard help, we can now build dump.o once
for all targets, keeping win_dump.o for x86* targets.

Philippe Mathieu-Daudé (5):
  dump: Replace tswapN() -> cpu_to_dumpN()
  dump: Replace TARGET_PAGE_SIZE -> qemu_target_page_size()
  dump: Clean included headers
  dump: Introduce win_dump_available()
  dump: Add create_win_dump() stub for non-x86 targets

 dump/dump-hmp-cmds.c |  2 +-
 dump/dump.c  | 35 +--
 dump/meson.build |  4 ++--
 dump/win_dump.c  | 38 --
 dump/win_dump.h  |  5 -
 5 files changed, 48 insertions(+), 36 deletions(-)

-- 
2.38.1

[PATCH v5 5/5] dump: Add create_win_dump() stub for non-x86 targets

[Philippe Mathieu-Daudé]

Implement the non-x86 create_win_dump(). We can remove
the last TARGET_X86_64 #ifdef'ry in dump.c, which thus
becomes target-independent. Update meson accordingly.

Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/dump.c  | 2 --
 dump/meson.build | 2 +-
 dump/win_dump.c  | 5 +
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index 0c96c6e735..7260558852 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -2020,9 +2020,7 @@ static void dump_process(DumpState *s, Error **errp)
 DumpQueryResult *result = NULL;
 
 if (s->has_format && s->format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP) {
-#ifdef TARGET_X86_64
 create_win_dump(s, errp);
-#endif
 } else if (s->has_format && s->format != DUMP_GUEST_MEMORY_FORMAT_ELF) {
 create_kdump_vmcore(s, errp);
 } else {
diff --git a/dump/meson.build b/dump/meson.build
index f13b29a849..7b116f1bd7 100644
--- a/dump/meson.build
+++ b/dump/meson.build
@@ -1,4 +1,4 @@
 softmmu_ss.add(files('dump-hmp-cmds.c'))
 
-specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, 
lzo])
+softmmu_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, lzo])
 specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: files('win_dump.c'))
diff --git a/dump/win_dump.c b/dump/win_dump.c
index ff9c5bd339..0152f7330a 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump.c
@@ -487,4 +487,9 @@ bool win_dump_available(Error **errp)
 return false;
 }
 
+void create_win_dump(DumpState *s, Error **errp)
+{
+win_dump_available(errp);
+}
+
 #endif
-- 
2.38.1

[PATCH v5 3/5] dump: Clean included headers

[Philippe Mathieu-Daudé]

"qemu/win_dump_defs.h" is only required by win_dump.c,
but win_dump.h requires "sysemu/dump.h" which declares
the DumpState type. Remove various unused headers.

Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/dump-hmp-cmds.c |  2 +-
 dump/dump.c  |  6 ++
 dump/win_dump.c  | 15 +--
 dump/win_dump.h  |  2 +-
 4 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/dump/dump-hmp-cmds.c b/dump/dump-hmp-cmds.c
index e5053b04cd..b038785fee 100644
--- a/dump/dump-hmp-cmds.c
+++ b/dump/dump-hmp-cmds.c
@@ -1,5 +1,5 @@
 /*
- * Human Monitor Interface commands
+ * Windows crashdump (Human Monitor Interface commands)
  *
  * This work is licensed under the terms of the GNU GPL, version 2 or later.
  * See the COPYING file in the top-level directory.
diff --git a/dump/dump.c b/dump/dump.c
index 3784a9054d..a84f78738a 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -14,22 +14,20 @@
 #include "qemu/osdep.h"
 #include "qemu/cutils.h"
 #include "elf.h"
-#include "exec/hwaddr.h"
+#include "qemu/bswap.h"
 #include "exec/target_page.h"
 #include "monitor/monitor.h"
-#include "sysemu/kvm.h"
 #include "sysemu/dump.h"
-#include "sysemu/memory_mapping.h"
 #include "sysemu/runstate.h"
 #include "sysemu/cpus.h"
 #include "qapi/error.h"
 #include "qapi/qapi-commands-dump.h"
 #include "qapi/qapi-events-dump.h"
 #include "qapi/qmp/qerror.h"
-#include "qemu/error-report.h"
 #include "qemu/main-loop.h"
 #include "hw/misc/vmcoreinfo.h"
 #include "migration/blocker.h"
+#include "hw/core/cpu.h"
 
 #ifdef TARGET_X86_64
 #include "win_dump.h"
diff --git a/dump/win_dump.c b/dump/win_dump.c
index f20b6051b6..ba7fa404fe 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump.c
@@ -1,5 +1,5 @@
 /*
- * Windows crashdump
+ * Windows crashdump (target specific implementations)
  *
  * Copyright (c) 2018 Virtuozzo International GmbH
  *
@@ -9,19 +9,14 @@
  */
 
 #include "qemu/osdep.h"
-#include "qemu/cutils.h"
-#include "elf.h"
-#include "exec/hwaddr.h"
-#include "monitor/monitor.h"
-#include "sysemu/kvm.h"
 #include "sysemu/dump.h"
-#include "sysemu/memory_mapping.h"
-#include "sysemu/cpus.h"
 #include "qapi/error.h"
 #include "qapi/qmp/qerror.h"
-#include "qemu/error-report.h"
-#include "hw/misc/vmcoreinfo.h"
+#include "exec/cpu-defs.h"
+#include "hw/core/cpu.h"
+#include "qemu/win_dump_defs.h"
 #include "win_dump.h"
+#include "cpu.h"
 
 static size_t win_dump_ptr_size(bool x64)
 {
diff --git a/dump/win_dump.h b/dump/win_dump.h
index b8c25348f4..56f63683c3 100644
--- a/dump/win_dump.h
+++ b/dump/win_dump.h
@@ -11,7 +11,7 @@
 #ifndef WIN_DUMP_H
 #define WIN_DUMP_H
 
-#include "qemu/win_dump_defs.h"
+#include "sysemu/dump.h"
 
 void create_win_dump(DumpState *s, Error **errp);
 
-- 
2.38.1

[PATCH v5 2/5] dump: Replace TARGET_PAGE_SIZE -> qemu_target_page_size()

[Philippe Mathieu-Daudé]

TARGET_PAGE_SIZE is target specific. In preparation of
making dump.c target-agnostic, replace the compile-time
TARGET_PAGE_SIZE definition by runtime qemu_target_page_size().

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
---
 dump/dump.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dump/dump.c b/dump/dump.c
index 7101169ecb..3784a9054d 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -15,6 +15,7 @@
 #include "qemu/cutils.h"
 #include "elf.h"
 #include "exec/hwaddr.h"
+#include "exec/target_page.h"
 #include "monitor/monitor.h"
 #include "sysemu/kvm.h"
 #include "sysemu/dump.h"
@@ -1859,7 +1860,7 @@ static void dump_init(DumpState *s, int fd, bool 
has_format,
 }
 
 if (!s->dump_info.page_size) {
-s->dump_info.page_size = TARGET_PAGE_SIZE;
+s->dump_info.page_size = qemu_target_page_size();
 }
 
 s->note_size = cpu_get_note_size(s->dump_info.d_class,
-- 
2.38.1

[PATCH] Deprecate the "-no-acpi" command line switch

[Thomas Huth]

Similar to "-no-hpet", the "-no-acpi" switch is a legacy command
line option that should be replaced with the "acpi" machine parameter
nowadays.

Signed-off-by: Thomas Huth 
---
 docs/about/deprecated.rst | 6 ++
 softmmu/vl.c  | 1 +
 2 files changed, 7 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index ee95bcb1a6..15084f7bea 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -99,6 +99,12 @@ form is preferred.
 The HPET setting has been turned into a machine property.
 Use ``-machine hpet=off`` instead.
 
+``-no-acpi`` (since 8.0)
+
+
+The ``-no-acpi`` setting has been turned into a machine property.
+Use ``-machine acpi=off`` instead.
+
 ``-accel hax`` (since 8.0)
 ''
 
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 459588aa7d..07d5215325 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -3271,6 +3271,7 @@ void qemu_init(int argc, char **argv)
 vnc_parse(optarg);
 break;
 case QEMU_OPTION_no_acpi:
+warn_report("-no-hpet is deprecated, use '-machine acpi=off' 
instead");
 qdict_put_str(machine_opts_dict, "acpi", "off");
 break;
 case QEMU_OPTION_no_hpet:
-- 
2.31.1

Re: [RFC PATCH 10/43] target/loongarch: Implement vaddw/vsubw

[gaosong]

在 2023/2/23 下午11:22, Richard Henderson 写道:

On 2/22/23 22:23, gaosong wrote:

Hi, Richard

在 2023/2/21 上午1:21, Richard Henderson 写道:

On 2/19/23 21:47, gaosong wrote:

I have some questions:
1 Should we need implement  GVecGen*  for simple gvec instructiosn?
 such as add, sub , or , xor..


No, these are done generically.


2 Should we need implement all fni8/fni4, fniv,  fno?


You need not implement them all.  Generally you will only implement 
fni4 for 32-bit arithmetic operations, and only fni8 for logical 
operations; there is rarely a cause for both with the same operation.


You can rely on the generic cutoff of 4 integer inline operations -- 
easy for your maximum vector length of 128-bits -- to avoid 
implementing fno.


But in extreme, you can implement only fno.  You can choose this 
over directly calling a helper function, minimizing differences in 
the translator code paths and letting generic code build all of the 
pointers.



Sorry for the late reply,  and Thanks for you answers.

But I still need more help.

How gvec singed or unsigned extensions of vector elements?


There are no generic sign-extending; that turns out to be widely 
variable across the different hosts and guest architectures.


If your architecture widens the even elements, you can implement 
extensions as a pair of shifts in the wider element size.  E.g. 
sign-extend is shl + sar.


I found no gvec function that implements signed and unsigned 
extensions of vector elements.
However, the result of some instructions requires the elements to be 
signed or unsigned extensions.


You may need to implement these operations with fni[48] or out of line 
in a helper.
It's hard to give advice without a specific example. 
I was wrong, the instruction is to sign-extend the odd or even elements 
of the vector before the operation, not to sign-extend the result.

E.g
vaddwev_h_b  vd, vj, vk
vd->H[i] = SignExtend(vj->B[2i])  + SignExtend(vk->B[2i]);
vaddwev_w_h  vd, vj, vk
vd->W[i] = SignExtend(vj->H[2i])  + SignExtend(vk->H[2i]);
vaddwev_d_w  vd, vj, vk
vd->Q[i] = SignExtend(vj->W[2i])  + SignExtend(vk->W[2i]);
vaddwev_q_d  vd, vj, vk
vd->Q[i] = SignExtend(vj->D[2i])  + SignExtend(vk->D[2i]);


Use  shl + sar  to sign-extend  vj/vk  even element.

static bool gvec_vvv(DisasContext *ctx, arg_vvv *a, MemOp mop,
 void (*func)(unsigned, uint32_t, uint32_t,
  uint32_t, uint32_t, uint32_t))
{
    uint32_t vd_ofs, vj_ofs, vk_ofs;

    CHECK_SXE;

    vd_ofs = vreg_full_offset(a->vd);
    vj_ofs = vreg_full_offset(a->vj);
    vk_ofs = vreg_full_offset(a->vk);

    func(mop, vd_ofs, vj_ofs, vk_ofs, 16, 16);
    return true;
}
static void gen_vaddwev_s(unsigned vece, TCGv_vec t, TCGv_vec a, TCGv_vec b)
{
    TCGv_vec t1 = tcg_temp_new_vec_matching(a);
    TCGv_vec t2 = tcg_temp_new_vec_matching(b);

    int halfbits  =  4 << vece;

    /* Sign-extend even elements from a */
    tcg_gen_dupi_vec(vece, t1, MAKE_64BIT_MASK(0, halfbits));
    tcg_gen_and_vec(vece, a, a, t1);
    tcg_gen_shli_vec(vece, a, a, halfbits);
    tcg_gen_sari_vec(vece, a, a, halfbits);

    /* Sign-extend even elements from b */
    tcg_gen_dupi_vec(vece, t2, MAKE_64BIT_MASK(0, halfbits));
    tcg_gen_and_vec(vece, b, b, t2);
    tcg_gen_shli_vec(vece, b, b, halfbits);
    tcg_gen_sari_vec(vece,  b, b, halfbits);

    tcg_gen_add_vec(vece, t, a, b);

    tcg_temp_free_vec(t1);
    tcg_temp_free_vec(t2);
}

static void gvec_vaddwev_s(unsigned vece, uint32_t vd_ofs, uint32_t vj_ofs,
   uint32_t vk_ofs, uint32_t oprsz, uint32_t maxsz)
{
    static const TCGOpcode vecop_list[] = {
    INDEX_op_shli_vec, INDEX_op_shri_vec, INDEX_op_add_vec, 
INDEX_op_sari_vec, 0

    };
    static const GVecGen3 op[4] = {
    {
    .fniv = gen_vaddwev_s,
    .fno = gen_helper_vaddwev_h_b,
    .opt_opc = vecop_list,
    .vece = MO_16
    },
    {
    .fniv = gen_vaddwev_s,
    .fno = gen_helper_vaddwev_w_h,
    .opt_opc = vecop_list,
    .vece = MO_32
    },
    {
    .fniv = gen_vaddwev_s,
    .fno = gen_helper_vaddwev_d_w,
    .opt_opc = vecop_list,
    .vece = MO_64
    },
    {
    .fniv = gen_vaddwev_s,
    .fno = gen_helper_vaddwev_q_d,
    .opt_opc = vecop_list,
    .vece = MO_128
    },
    };

    tcg_gen_gvec_3(vd_ofs, vj_ofs, vk_ofs, oprsz, maxsz, [vece]);
}

TRANS(vaddwev_h_b, gvec_vvv, MO_8,  gvec_vaddwev_s)
TRANS(vaddwev_w_h, gvec_vvv, MO_16, gvec_vaddwev_s)
TRANS(vaddwev_d_w, gvec_vvv, MO_32, gvec_vaddwev_s)
TRANS(vaddwev_q_d, gvec_vvv, MO_64, gvec_vaddwev_s)

and I also implement  gen_helper_vaddwev_x_x. Is this example correct?

Thanks.
Song Gao

Re: [PATCH v2 0/4] NUMA: Apply socket-NUMA-node boundary for aarch64 and RiscV machines

[Gavin Shan]

Hi Drew,

On 2/23/23 11:25 PM, Andrew Jones wrote:

On Thu, Feb 23, 2023 at 04:13:57PM +0800, Gavin Shan wrote:

For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is
used to populate the CPU topology in the Linux guest. It's required that
the CPUs in one socket can't span mutiple NUMA nodes. Otherwise, the Linux
scheduling domain can't be sorted out, as the following warning message
indicates. To avoid the unexpected confusion, this series attempts to
rejects such kind of insane configurations.


I'm not sure 'insane' is the right word, maybe 'irregular'. I've never
seen, and don't really expect to find, specifications stating that arm
and/or riscv must have 1:1 mappings for numa nodes and sockets. But, as
QEMU machine types can choose certain configurations to support, if
everyone is in agreement to restrict sbsa-ref and arm/riscv virt to 1:1
mappings, then why not. However, I suggest stating that this is simply a
choice being made for these boards, since the expectation of needing
"irregular" configurations is low. We should not be trying to use Linux
assumptions as rationale, since other OSes may cope better with irregular
configurations.

Also, I suggest adding a comment to the boards, which adopt this
restriction, which explains that it's only a platform choice, not
something specified by the architecture.



[...]

Thanks for your comments. Yes, "irregular" is definitely better words. I failed
to find the statement that ARM64 has the requirement for 1:1 mapping between
socket and NUMA node, which makes it hard to tell if the restriction is required
from architectural level. However, the linux driver 
(drivers/base/arch_topology.c)
considers both CPU-to-NUMA-association and CPU toplogy from ACPI PPTT when the
CPU set in the core group is calculated. It means the CPU-to-NUMA-association
can affect the CPU topology seen by Linux scheduler.

With the restriction of 1:1 mapping between socket and NUMA node, or between
cluster and NUMA node as I mentioned in the reply to Daniel P. Berrangé 
,
the existing configuration for other OSes can become invalid.

Yes, a comment to mention it's a platform choice, not architectural requirement,
definitely helps to understand the context.

Thanks,
Gavin

Re: [PATCH 2/5] hw/isa/vt82c686: Implement PCI IRQ routing

[Bernhard Beschow]

Am 23. Februar 2023 23:47:58 UTC schrieb BALATON Zoltan :
>On Thu, 23 Feb 2023, Bernhard Beschow wrote:
>> Am 23. Februar 2023 21:11:23 UTC schrieb BALATON Zoltan :
>>> On Thu, 23 Feb 2023, Bernhard Beschow wrote:
 The real VIA south bridges implement a PCI IRQ router which is configured
 by the BIOS or the OS. In order to respect these configurations, QEMU
 needs to implement it as well.
 
 Note: The implementation was taken from piix4_set_irq() in hw/isa/piix4.
 
 Signed-off-by: Bernhard Beschow 
 ---
 hw/isa/vt82c686.c | 44 
 1 file changed, 44 insertions(+)
 
 diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
 index 3f9bd0c04d..f24e387d63 100644
 --- a/hw/isa/vt82c686.c
 +++ b/hw/isa/vt82c686.c
 @@ -604,6 +604,48 @@ static void via_isa_request_i8259_irq(void *opaque, 
 int irq, int level)
 qemu_set_irq(s->cpu_intr, level);
 }
 
 +static int via_isa_get_pci_irq(const ViaISAState *s, int irq_num)
 +{
 +switch (irq_num) {
 +case 0:
 +return s->dev.config[0x55] >> 4;
 +
 +case 1:
 +return s->dev.config[0x56] & 0xf;
 +
 +case 2:
 +return s->dev.config[0x56] >> 4;
 +
 +case 3:
 +return s->dev.config[0x57] >> 4;
 +}
 +
 +return 0;
 +}
 +
 +static void via_isa_set_pci_irq(void *opaque, int irq_num, int level)
 +{
 +ViaISAState *s = opaque;
 +PCIBus *bus = pci_get_bus(>dev);
 +int pic_irq;
 +
 +/* now we change the pic irq level according to the via irq mappings 
 */
 +/* XXX: optimize */
 +pic_irq = via_isa_get_pci_irq(s, irq_num);
 +if (pic_irq < ISA_NUM_IRQS) {
 +int i, pic_level;
 +
 +/* The pic level is the logical OR of all the PCI irqs mapped to 
 it. */
 +pic_level = 0;
 +for (i = 0; i < PCI_NUM_PINS; i++) {
 +if (pic_irq == via_isa_get_pci_irq(s, i)) {
 +pic_level |= pci_bus_get_irq_level(bus, i);
 +}
 +}
 +qemu_set_irq(s->isa_irqs[pic_irq], pic_level);
 +}
 +}
 +
 static void via_isa_realize(PCIDevice *d, Error **errp)
 {
 ViaISAState *s = VIA_ISA(d);
 @@ -676,6 +718,8 @@ static void via_isa_realize(PCIDevice *d, Error **errp)
 if (!qdev_realize(DEVICE(>mc97), BUS(pci_bus), errp)) {
 return;
 }
 +
 +pci_bus_irqs(pci_bus, via_isa_set_pci_irq, s, PCI_NUM_PINS);
>>> 
>>> Please no oversimplification. This replaces the connections to mv64361 gpp 
>>> pins made in mv64361_realize() and breaks the interrupts that can be 
>>> enabled in mv64361.
>> 
>> Let's split our work as follows: You'll do the audio and pegasos2 changes 
>> including exporting the pirq properties, I'll do the first three routing 
>> patches of this series as the base.
>
>I'm OK with doing audio as said and already did the PIRQ and pegaosos2 changes 
>(patch 2 and 3 in my series), just take those without deleting half of them.

I can only take the three VT82xx patches as I proposed since I don't know the 
Pegasos2 board as well as you do and I don't want to iterate on any review 
comments for the other patches. I'll send my series soonish.

Best regards,
Bernhard

>So drop the last two via-ac97 patches and do the IRQ fixes in your way but 
>keep working what now works.
>
>>> I've implemented that for something but can't remember now which guest 
>>> exactly,
>> 
>> Could you please put this information into the commit message or into the 
>> code? That would ease maintainance a lot.
>
>I did, see patch 3 in my series.
>
>>> but this would be needed so please restore my pegasos2 patch and move this 
>>> there connecting both mv64361 and via-isa to PCI interrupts as shown in the 
>>> schematics. That means you also need the PIRQ pins here. Can you do a new 
>>> version with that?
>> 
>> As proposed above I'd fold the first three patches into a separate series 
>> which you can build upon. I have no way to test the pegasos2 IRQ changes 
>> since the test cases I'm aware of either work or we agreed that they can be 
>> fixed later (-> USB).
>
>I did fix the USB just haven't sent a v2 yet due to this thread but it's just 
>the change I've sent yesterday, just add this before qemu_set_irq at the end 
>of via_isa_set_irq() in my series. This is what I have now:
>
>+uint16_t old_state;
>+if (old_state && s->isa_irq_state[isa_irq]) {
>+/* FIXME: i8259 model does not support level sensitive mode */
>+qemu_set_irq(s->isa_irqs[isa_irq], 0);
>+}
>
>How to do that with your version I have no idea but this fixed the problem 
>with my series. I can send a v2 of this patch with this change if it's not 
>clear from this and the other message what I did.
>
>>> I'll try this one in the 

Re: [PATCH v2 0/4] NUMA: Apply socket-NUMA-node boundary for aarch64 and RiscV machines

[Gavin Shan]

On 2/24/23 12:18 AM, Daniel Henrique Barboza wrote:

On 2/23/23 05:13, Gavin Shan wrote:

For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is
used to populate the CPU topology in the Linux guest. It's required that
the CPUs in one socket can't span mutiple NUMA nodes. Otherwise, the Linux
scheduling domain can't be sorted out, as the following warning message
indicates. To avoid the unexpected confusion, this series attempts to
rejects such kind of insane configurations.

    -smp 6,maxcpus=6,sockets=2,clusters=1,cores=3,threads=1 \
    -numa node,nodeid=0,cpus=0-1,memdev=ram0    \
    -numa node,nodeid=1,cpus=2-3,memdev=ram1    \
    -numa node,nodeid=2,cpus=4-5,memdev=ram2    \



And why is this a QEMU problem? This doesn't hurt ACPI.

Also, this restriction impacts breaks ARM guests in the wild that are running
non-Linux OSes. I don't see why we should impact use cases that has nothing to
do with Linux Kernel feelings about sockets - NUMA nodes exclusivity.



With above configuration, CPU-0/1/2 are put into socket-0-cluster-0 while 
CPU-3/4/5
are put into socket-1-cluster-0, meaning CPU-2/3 belong to different socket and
cluster. However, CPU-2/3 are associated with NUMA node-1. In summary, multiple
CPUs in different clusters and sockets have been associated with one NUMA node.

If I'm correct, the configuration isn't sensible in a baremetal environment and
same Linux kernel is supposed to work well for baremetal and virtualized 
machine.
So I think QEMU needs to emulate the topology as much as we can to match with 
the
baremetal environment. It's the reason why I think it's a QEMU problem even it
doesn't hurt ACPI. As I said in the reply to Daniel P. Berrangé 

in another thread, we may need to gurantee that the CPUs in one cluster can't be
split to multiple NUMA nodes, which matches with the baremetal environment, as I
can understand.

Right, the restriction to have socket-NUMA-node or cluster-NUMA-node boundary 
will
definitely break the configurations running in the wild.

Thanks,
Gavin

[...]

Re: [PATCH v4 5/7] dump: Introduce create_win_dump()

[Thomas Huth]

On 24/02/2023 00.17, Philippe Mathieu-Daudé wrote:

Remove another TARGET_X86_64 #ifdef'ry by introducing
a create_win_dump() stub. We'll extract it to a stub
file for non-x86 targets in the next commit.

Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/dump.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index c356a88be1..b33a613d45 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -39,6 +39,11 @@ bool win_dump_available(Error **errp)
  
  return false;

  }
+
+void create_win_dump(DumpState *s, Error **errp)
+{
+win_dump_available(errp);
+}
  #endif
  
  #include 

@@ -2031,9 +2036,7 @@ static void dump_process(DumpState *s, Error **errp)
  DumpQueryResult *result = NULL;
  
  if (s->has_format && s->format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP) {

-#ifdef TARGET_X86_64
  create_win_dump(s, errp);
-#endif
  } else if (s->has_format && s->format != DUMP_GUEST_MEMORY_FORMAT_ELF) {
  create_kdump_vmcore(s, errp);
  } else {


Reviewed-by: Thomas Huth 

Re: [PATCH v4 4/7] dump: Introduce win_dump_available()

[Thomas Huth]

On 24/02/2023 00.17, Philippe Mathieu-Daudé wrote:

Remove a pair of TARGET_X86_64 #ifdef'ry by introducing
the win_dump_available() method. We'll soon extract it
to a stub file for non-x86 targets.

Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/dump.c | 23 +--
  dump/win_dump.c |  5 +
  dump/win_dump.h |  3 +++
  3 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index 3784a9054d..c356a88be1 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -30,9 +30,15 @@
  #include "qemu/main-loop.h"
  #include "hw/misc/vmcoreinfo.h"
  #include "migration/blocker.h"
-
-#ifdef TARGET_X86_64
  #include "win_dump.h"
+
+#ifndef TARGET_X86_64
+bool win_dump_available(Error **errp)
+{
+error_setg(errp, "Windows dump is only available for x86-64");
+
+return false;
+}
  #endif


I think I'd prefer to introduce the stub file immediately here already, but 
it's just a matter of taste.


So with the indentation fixed (that Richard mentioned):

Reviewed-by: Thomas Huth 

Re: [PATCH v4 3/7] dump: Correct headers included

[Thomas Huth]

On 24/02/2023 00.17, Philippe Mathieu-Daudé wrote:

"qemu/win_dump_defs.h" is only required by win_dump.c,
but win_dump.h requires "sysemu/dump.h" which declares
the DumpState type.

Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/win_dump.c | 1 +
  dump/win_dump.h | 2 +-
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/dump/win_dump.c b/dump/win_dump.c
index f20b6051b6..12b7da5da0 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump.c
@@ -21,6 +21,7 @@
  #include "qapi/qmp/qerror.h"
  #include "qemu/error-report.h"
  #include "hw/misc/vmcoreinfo.h"
+#include "qemu/win_dump_defs.h"
  #include "win_dump.h"
  
  static size_t win_dump_ptr_size(bool x64)

diff --git a/dump/win_dump.h b/dump/win_dump.h
index b8c25348f4..56f63683c3 100644
--- a/dump/win_dump.h
+++ b/dump/win_dump.h
@@ -11,7 +11,7 @@
  #ifndef WIN_DUMP_H
  #define WIN_DUMP_H
  
-#include "qemu/win_dump_defs.h"

+#include "sysemu/dump.h"
  
  void create_win_dump(DumpState *s, Error **errp);
  


Reviewed-by: Thomas Huth 

Re: [PATCH v4 2/7] dump: Replace TARGET_PAGE_SIZE -> qemu_target_page_size()

[Thomas Huth]

On 24/02/2023 00.17, Philippe Mathieu-Daudé wrote:

TARGET_PAGE_SIZE is target specific. In preparation of
making dump.c target-agnostic, replace the compile-time
TARGET_PAGE_SIZE definition by runtime qemu_target_page_size().

Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/dump.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dump/dump.c b/dump/dump.c
index 7101169ecb..3784a9054d 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -15,6 +15,7 @@
  #include "qemu/cutils.h"
  #include "elf.h"
  #include "exec/hwaddr.h"
+#include "exec/target_page.h"
  #include "monitor/monitor.h"
  #include "sysemu/kvm.h"
  #include "sysemu/dump.h"
@@ -1859,7 +1860,7 @@ static void dump_init(DumpState *s, int fd, bool 
has_format,
  }
  
  if (!s->dump_info.page_size) {

-s->dump_info.page_size = TARGET_PAGE_SIZE;
+s->dump_info.page_size = qemu_target_page_size();
  }
  
  s->note_size = cpu_get_note_size(s->dump_info.d_class,


Reviewed-by: Thomas Huth 

Re: [PATCH v4 1/7] dump: Replace tswapN() -> cpu_to_dumpN()

[Thomas Huth]

On 24/02/2023 00.17, Philippe Mathieu-Daudé wrote:

All uses of tswap in that file are wrong, and should be using
cpu_to_dumpN, which correctly tests the endianness of the output.

Suggested-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/dump.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index 279b07f09b..7101169ecb 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -907,13 +907,13 @@ static void get_note_sizes(DumpState *s, const void *note,
  if (dump_is_64bit(s)) {
  const Elf64_Nhdr *hdr = note;
  note_head_sz = sizeof(Elf64_Nhdr);
-name_sz = tswap64(hdr->n_namesz);
-desc_sz = tswap64(hdr->n_descsz);
+name_sz = cpu_to_dump64(s, hdr->n_namesz);
+desc_sz = cpu_to_dump64(s, hdr->n_descsz);
  } else {
  const Elf32_Nhdr *hdr = note;
  note_head_sz = sizeof(Elf32_Nhdr);
-name_sz = tswap32(hdr->n_namesz);
-desc_sz = tswap32(hdr->n_descsz);
+name_sz = cpu_to_dump32(s, hdr->n_namesz);
+desc_sz = cpu_to_dump32(s, hdr->n_descsz);
  }


Those tswaps looked suspiciuous indeed.

Reviewed-by: Thomas Huth 

Re: [PATCH] accel/tcg: Add 'size' param to probe_access_full

[Philippe Mathieu-Daudé]

On 24/2/23 01:45, Richard Henderson wrote:

Change to match the recent change to probe_access_flags.
All existing callers updated to supply 0, so no change in behaviour.

Signed-off-by: Richard Henderson 
---
  include/exec/exec-all.h  | 2 +-
  accel/tcg/cputlb.c   | 4 ++--
  target/arm/mte_helper.c  | 4 ++--
  target/arm/ptw.c | 2 +-
  target/arm/sve_helper.c  | 2 +-
  target/arm/translate-a64.c   | 2 +-
  target/i386/tcg/sysemu/excp_helper.c | 4 ++--
  7 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 165b050872..b631832e17 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -475,7 +475,7 @@ int probe_access_flags(CPUArchState *env, target_ulong 
addr, int size,
   * and must be consumed or copied immediately, before any further
   * access or changes to TLB @mmu_idx.
   */
-int probe_access_full(CPUArchState *env, target_ulong addr,
+int probe_access_full(CPUArchState *env, target_ulong addr, int size,
MMUAccessType access_type, int mmu_idx,
bool nonfault, void **phost,
CPUTLBEntryFull **pfull, uintptr_t retaddr);


Why is 'size' signed? (similar in probe_access_flags).

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PULL 0/9] Fourth RISC-V PR for QEMU 8.0

[Thomas Huth]

 Hi!

On 23/02/2023 23.49, Palmer Dabbelt wrote:

On Wed, 22 Feb 2023 07:56:10 PST (-0800), Palmer Dabbelt wrote:

On Tue, 21 Feb 2023 08:43:47 PST (-0800), Peter Maydell wrote:

...

This seems to have caused CI to decide it needs to rerun the
'docker-opensbi' job, which doesn't work:
https://gitlab.com/qemu-project/qemu/-/jobs/3808319659

I don't understand what exactly is going on here -- Alex,
Bin, any ideas?

Why do we build the firmware in CI if we have checked in
binaries in pc-bios?

Should .gitlab-ci.d/opensbi/Dockerfile really still be
starting with Ubuntu 18.04 ? That is already older than our
set of supported platforms, and falls out of support from
Ubuntu in a couple of months.


I just sent along a patch
.
I have no idea how to test it in the CI, though...


1) Fork the qemu repository in gitlab to your account
2) Add a remote to your repo on your PC to point to the
   forked gitlab repo (git remote add ...)
3) Read docs/devel/ci-jobs.rst.inc - you basically want
   these two things:

  git config --local alias.push-ci "push -o ci.variable=QEMU_CI=1"
  git config --local alias.push-ci-now "push -o ci.variable=QEMU_CI=2"

4) If you now do a "git push-ci ..." to your forked repo,
   you should be able to see the CI pipelines there

Nobody's replied, so I'm inclined to just drop the OpenSBI bump and re-send 
the PR.  At least that way we can avoid getting blocked on the CI issues.  
There's some more in flight so there'll probably be a 5th round before the 
freeze either way, at least this way the stuff that works can avoid getting 
blocked.


Please note that pull requests are currently not processed
anyway ('til March 1st), see:

 
https://lore.kernel.org/qemu-devel/cafeaca83u_enxdj3gjka-xv6eljgjpr_9frdkaqm3qacyhr...@mail.gmail.com/

 Thomas

Re: [PATCH v4 6/7] dump: Build once by adding stubs for non-x86 targets

[Philippe Mathieu-Daudé]

On 24/2/23 00:51, Richard Henderson wrote:

On 2/23/23 13:17, Philippe Mathieu-Daudé wrote:

Extract non-x86 stubs to win_dump-stub.c. We can now
build dump.o once for system emulation. Update meson.

Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/dump.c  | 14 --
  dump/meson.build |  6 --
  dump/win_dump-stub.c | 23 +++
  3 files changed, 27 insertions(+), 16 deletions(-)
  create mode 100644 dump/win_dump-stub.c



diff --git a/dump/meson.build b/dump/meson.build
index 2eff29c3ea..6ae07e6fed 100644
--- a/dump/meson.build
+++ b/dump/meson.build
@@ -1,4 +1,6 @@
  softmmu_ss.add(files('dump-hmp-cmds.c'))
-specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), 
snappy, lzo])
-specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'], if_true: 
files('win_dump.c'))
+softmmu_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), 
snappy, lzo])

+specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'],
+    if_true: files('win_dump.c'),
+    if_false: files('win_dump-stub.c'))


Doesn't this add win_dump-stub.c when !(SOFTMMU && X86_64), i.e. 
!SOFTMMU || !X86_64?


I trying to imagine how well this will scale with ARM64, for the ongoing 
Windows on ARM project.  Would it just be easier have the stubs in 
win_dump.c, using ifdefs?


Yeah I realized that later, keeping one single file with #ifdef'ry
even simplifies meson rules. I over-engineered that :)
Also various methods from win_dump.c could be reused.

Re: [PATCH v2] docs/about/build-platforms: Refine the distro support policy

[Markus Armbruster]

Thomas Huth  writes:

> For long-term distributions that release a new version only very
> seldom, we limit the support to five years after the initial release.
> Otherwise, we might need to support distros like openSUSE 15 for
> up to 7 or even more years in total due to our "two more years
> after the next major release" rule, which is just way too much to
> handle in a project like QEMU that only has limited human resources.
>
> Signed-off-by: Thomas Huth 
> ---
>  v2: Only limit the maximum amount of time to five years (instead of
>  four years + decreasing the amount of time after the next major
>  has been released)
>
>  docs/about/build-platforms.rst | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
> index 1c1e7b9e11..7ad95ae9ae 100644
> --- a/docs/about/build-platforms.rst
> +++ b/docs/about/build-platforms.rst
> @@ -67,7 +67,8 @@ Non-supported architectures may be removed in the future 
> following the
>  Linux OS, macOS, FreeBSD, NetBSD, OpenBSD
>  -
>  
> -The project aims to support the most recent major version at all times. 
> Support
> +The project aims to support the most recent major version at all times for
> +up to five years after its initial release. Support
>  for the previous major version will be dropped 2 years after the new major
>  version is released or when the vendor itself drops support, whichever comes
>  first. In this context, third-party efforts to extend the lifetime of a 
> distro

I think this is a more realistic promise.  We may elect to support
beyond the five year mark, if we're so inclined.

Reviewed-by: Markus Armbruster 

Re: [PATCH v4 0/4] target: Restrict 'qapi-commands-machine.h' to system emulation

[Markus Armbruster]

Philippe Mathieu-Daudé  writes:

> All series reviewed, can patches be picked by corresponding
> maintainers, or should I include them in on of my PRs?
>
> The "qapi-commands-machine.h" header is not generated in user-only
> emulation. This series removes its use in user-emu code by moving
> the QMP code depending on this header into a separate sysemu unit.

Queued.  Thanks!

Re: [PATCH] MAINTAINERS: Cover RCU documentation

[Markus Armbruster]

Philippe Mathieu-Daudé  writes:

> ping^2

You misspelled "Paolo?"  You're welcome!  ;-P

Re: Fortnightly KVM call for 2023-02-07

[Markus Armbruster]

Sean Christopherson  writes:

> On Tue, Jan 24, 2023, Juan Quintela wrote:
>> Please, send any topic that you are interested in covering in the next
>> call in 2 weeks.
>> 
>> We have already topics:
>> - single qemu binary
>>   People on previous call (today) asked if Markus, Paolo and Peter could
>>   be there on next one to further discuss the topic.
>> 
>> - Huge Memory guests
>> 
>>   Will send a separate email with the questions that we want to discuss
>>   later during the week.
>> 
>> After discussions on the QEMU Summit, we are going to have always open a
>> KVM call where you can add topics.
>
> Hi Juan!
>
> I have a somewhat odd request: can I convince you to rename "KVM call" to 
> something
> like "QEMU+KVM call"?
>
> I would like to kickstart a recurring public meeting/forum that (almost) 
> exclusively
> targets internal KVM development, but I don't to cause confusion and 
> definitely don't
> want to usurp your meeting.  The goal/purpose of the KVM-specific meeting 
> would be to
> do design reviews, syncs, etc. on KVM internals and things like KVM 
> selftests, while,
> IIUC, the current "KVM call" is aimed at at the entire KVM+QEMU+VFIO 
> ecosystem.
>
> Thanks!

Sounds fair to me.

Re: [PATCH] .gitlab-ci.d/base: Mark jobs as interruptible by default

[Thomas Huth]

On 23/02/2023 21.23, Philippe Mathieu-Daudé wrote:

On 23/2/23 20:13, Thomas Huth wrote:

When handling pull requests in the staging branch, it often happens
that one of the job fails due to a problem, so that the pull request
can't be merged. Peter/Richard/Stefan then informs the sender of the
pull request and continues by pushing the next pending pull request
from another subsystem maintainer. Now the problem is that there might
still be lots of other running jobs in the pipeline of the first pull
request, eating up precious CI minutes though the pipeline is not
needed anymore. We can avoid this by marking the jobs as "interruptible".
With this setting, the jobs from previous pipelines are automatically
terminated when pushing a new one. If someone does not like this auto-
matic termination, it can still be disabled in the settings of the
repository. See this URL for details:

  https://docs.gitlab.com/ee/ci/yaml/index.html#interruptible

Signed-off-by: Thomas Huth 
---
  .gitlab-ci.d/base.yml | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/.gitlab-ci.d/base.yml b/.gitlab-ci.d/base.yml
index 50fb59e147..0274228de8 100644
--- a/.gitlab-ci.d/base.yml
+++ b/.gitlab-ci.d/base.yml
@@ -11,6 +11,8 @@
  # and show the duration of each line.
  FF_SCRIPT_SECTIONS: 1
+  interruptible: true


It makes sense for mainstream, but seems counter-productive in forks.
At least in my maintainer use case.

Is it possible to add a 'default' in .gitlab-ci.d/qemu-project.yml,
so we can overwrite with a different namespace? 'interruptible' is
listed in https://docs.gitlab.com/ee/ci/yaml/index.html#default.


As I wrote in the commit description: "If someone does not like this 
automatic termination, it can still be disabled in the settings of the 
repository."


See here for how to change the setting:


https://docs.gitlab.com/ee/ci/pipelines/settings.html#auto-cancel-redundant-pipelines

 Thomas

Re: [PATCH v2 0/4] NUMA: Apply socket-NUMA-node boundary for aarch64 and RiscV machines

[Gavin Shan]

On 2/23/23 11:57 PM, Daniel P. Berrangé wrote:

On Thu, Feb 23, 2023 at 04:13:57PM +0800, Gavin Shan wrote:

For arm64 and RiscV architecture, the driver (/base/arch_topology.c) is
used to populate the CPU topology in the Linux guest. It's required that
the CPUs in one socket can't span mutiple NUMA nodes. Otherwise, the Linux
scheduling domain can't be sorted out, as the following warning message
indicates. To avoid the unexpected confusion, this series attempts to
rejects such kind of insane configurations.

-smp 6,maxcpus=6,sockets=2,clusters=1,cores=3,threads=1 \
-numa node,nodeid=0,cpus=0-1,memdev=ram0\
-numa node,nodeid=1,cpus=2-3,memdev=ram1\
-numa node,nodeid=2,cpus=4-5,memdev=ram2\


This is somewhat odd as a config, because core 2 is in socket 0
and core 3 is in socket 1, so it wouldn't make much conceptual
sense to have them in the same NUMA node, while other cores within
the same socket are in different NUMA nodes. Basically the split
of NUMA nodes is not aligned with any level in the topology.

This series, however, also rejects configurations that I would
normally consider to be reasonable. I've not tested linux kernel
behaviour though, but as a user I would expect to be able to
ask for:

 -smp 6,maxcpus=6,sockets=2,clusters=1,cores=3,threads=1 \
 -numa node,nodeid=0,cpus=0,memdev=ram0\
 -numa node,nodeid=1,cpus=1,memdev=ram1\
 -numa node,nodeid=2,cpus=2,memdev=ram2\
 -numa node,nodeid=3,cpus=3,memdev=ram3\
 -numa node,nodeid=4,cpus=4,memdev=ram4\
 -numa node,nodeid=5,cpus=5,memdev=ram5\

ie, every core gets its own NUMA node



It doesn't work to Linux guest either. As the following warning message
indicates, the Multicore domain isn't a subset of DIE (CLUSTER or socket)
domain. For example, Multicore domain is 0-2 while DIE domain is 0 for
CPU-0.

[0.023486] CPU-0: 36,56,0,-1 thread=0  core=0-2  cluster=0-2 llc=0// 
parsed from ACPI PPTT
[0.023490] CPU-1: 36,56,1,-1 thread=1  core=0-2  cluster=0-2 llc=1
[0.023492] CPU-2: 36,56,2,-1 thread=2  core=0-2  cluster=0-2 llc=2
[0.023494] CPU-3: 136,156,3,-1 thread=3  core=3-5  cluster=3-5 llc=3
[0.023495] CPU-4: 136,156,4,-1 thread=4  core=3-5  cluster=3-5 llc=4
[0.023497] CPU-5: 136,156,5,-1 thread=5  core=3-5  cluster=3-5 llc=5
[0.023499] CPU-0: SMT=0  CLUSTER=0  MULTICORE=0-2  DIE=0  CPU-OF-NODE=0 
 // Seen by scheduling domain
[0.023501] CPU-1: SMT=1  CLUSTER=1  MULTICORE=0-2  DIE=1  CPU-OF-NODE=1
[0.023503] CPU-2: SMT=2  CLUSTER=2  MULTICORE=0-2  DIE=2  CPU-OF-NODE=2
[0.023504] CPU-3: SMT=3  CLUSTER=3  MULTICORE=3-5  DIE=3  CPU-OF-NODE=3
[0.023506] CPU-4: SMT=4  CLUSTER=4  MULTICORE=3-5  DIE=4  CPU-OF-NODE=4
[0.023508] CPU-5: SMT=5  CLUSTER=5  MULTICORE=3-5  DIE=5  CPU-OF_NODE=5
:
[0.023555] BUG: arch topology borken
[0.023556]  the MC domain not a subset of the DIE domain

NOTE that both DIE and CPU-OF-NODE are same since they're all returned by
'cpumask_of_node(cpu_to_node(cpu))'.



Or to aask for every cluster as a numa node:

 -smp 6,maxcpus=6,sockets=2,clusters=3,cores=1,threads=1 \
 -numa node,nodeid=0,cpus=0,memdev=ram0\
 -numa node,nodeid=1,cpus=1,memdev=ram1\
 -numa node,nodeid=2,cpus=2,memdev=ram2\
 -numa node,nodeid=3,cpus=3,memdev=ram3\
 -numa node,nodeid=4,cpus=4,memdev=ram4\
 -numa node,nodeid=5,cpus=5,memdev=ram5\



This case works fine to Linux guest.

[0.024505] CPU-0: 36,56,0,-1 thread=0  core=0-2  cluster=0 llc=0
// parsed from ACPI PPTT
[0.024509] CPU-1: 36,96,1,-1 thread=1  core=0-2  cluster=1 llc=1
[0.024511] CPU-2: 36,136,2,-1 thread=2  core=0-2  cluster=2 llc=2
[0.024512] CPU-3: 176,196,3,-1 thread=3  core=3-5  cluster=3 llc=3
[0.024514] CPU-4: 176,236,4,-1 thread=4  core=3-5  cluster=4 llc=4
[0.024515] CPU-5: 176,276,5,-1 thread=5  core=3-5  cluster=5 llc=5
[0.024518] CPU-0: SMT=0  CLUSTER=0  MULTICORE=0  DIE=0  CPU-OF-NODE=0  
// Seen by scheduling domain
[0.024519] CPU-1: SMT=1  CLUSTER=1  MULTICORE=1  DIE=1  CPU-OF-NODE=1
[0.024521] CPU-2: SMT=2  CLUSTER=2  MULTICORE=2  DIE=2  CPU-OF-NODE=2
[0.024522] CPU-3: SMT=3  CLUSTER=3  MULTICORE=3  DIE=3  CPU-OF-NODE=3
[0.024524] CPU-4: SMT=4  CLUSTER=4  MULTICORE=4  DIE=4  CPU-OF-NODE=4
[0.024525] CPU-5: SMT=5  CLUSTER=5  MULTICORE=5  DIE=5  CPU-OF-NODE=5



In both cases the NUMA split is aligned with a given level
in the topology, which was not the case with your example.

Rejecting these feels overly strict to me, and may risk breaking
existing valid deployments, unless we can demonstrate those
scenarios were unambiguously already broken ?

If there was something in the hardware specs that requires
this, then it is more 

Re: [PATCH v10 1/9] mm: Introduce memfd_restricted system call to create restricted user memory

[Chao Peng]

> > int restrictedmem_bind(struct file *file, pgoff_t start, pgoff_t end,
> >struct restrictedmem_notifier *notifier, bool exclusive)
> > {
> > struct restrictedmem *rm = file->f_mapping->private_data;
> > int ret = -EINVAL;
> > 
> > down_write(>lock);
> > 
> > /* Non-exclusive mappings are not yet implemented. */
> > if (!exclusive)
> > goto out_unlock;
> > 
> > if (!xa_empty(>bindings)) {
> > if (exclusive != rm->exclusive)
> > goto out_unlock;
> > 
> > if (exclusive && xa_find(>bindings, , end, 
> > XA_PRESENT))
> > goto out_unlock;
> > }
> > 
> > xa_store_range(>bindings, start, end, notifier, GFP_KERNEL);
> 
> 
> || ld: mm/restrictedmem.o: in function `restrictedmem_bind':
> mm/restrictedmem.c|295| undefined reference to `xa_store_range'

Right, xa_store_range() is only available for XARRAY_MULTI.

> 
> 
> This is missing:
> ===
> diff --git a/mm/Kconfig b/mm/Kconfig
> index f952d0172080..03aca542c0da 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -1087,6 +1087,7 @@ config SECRETMEM
>  config RESTRICTEDMEM
> bool
> depends on TMPFS
> +   select XARRAY_MULTI
> ===
> 
> Thanks,
> 
> 
> 
> > rm->exclusive = exclusive;
> > ret = 0;
> > out_unlock:
> > up_write(>lock);
> > return ret;
> > }
> > EXPORT_SYMBOL_GPL(restrictedmem_bind);
> > 
> > void restrictedmem_unbind(struct file *file, pgoff_t start, pgoff_t end,
> >   struct restrictedmem_notifier *notifier)
> > {
> > struct restrictedmem *rm = file->f_mapping->private_data;
> > 
> > down_write(>lock);
> > xa_store_range(>bindings, start, end, NULL, GFP_KERNEL);
> > synchronize_rcu();
> > up_write(>lock);
> > }
> > EXPORT_SYMBOL_GPL(restrictedmem_unbind);
> 
> -- 
> Alexey

Re: [PULL v2 00/36] Testing, docs, semihosting and plugin updates

[Akihiko Odaki]

On 2023/02/23 21:59, Philippe Mathieu-Daudé wrote:

On 3/2/23 18:38, Philippe Mathieu-Daudé wrote:

On 2/2/23 17:01, Alex Bennée wrote:




Testing, docs, semihosting and plugin updates





FTR I'm now seeing this warning on Darwin/Aarch64:

C compiler for the host machine: clang (clang 14.0.0 "Apple clang 
version 14.0.0 (clang-1400.0.29.202)")

C linker for the host machine: clang ld64 820.1
Host machine cpu family: aarch64
Host machine cpu: aarch64
...
[1/3253] Linking target tests/plugin/libbb.dylib
ld: warning: -undefined dynamic_lookup may not work with chained fixups
[2/3253] Linking target tests/plugin/libinsn.dylib
ld: warning: -undefined dynamic_lookup may not work with chained fixups
[3/3253] Linking target tests/plugin/libmem.dylib
ld: warning: -undefined dynamic_lookup may not work with chained fixups
[4/3253] Linking target tests/plugin/libsyscall.dylib
ld: warning: -undefined dynamic_lookup may not work with chained fixups


Googling, someone suggest to use --linkopt=-Wl,-no_fixup_chains:
https://github.com/bazelbuild/bazel/issues/16413#issuecomment-1270603343

This doesn't show up on GitLab which uses:

C compiler for the host machine: cc (clang 13.1.6 "Apple clang version 
13.1.6 (clang-1316.0.21.2.5)")

C linker for the host machine: cc ld64 764
Host machine cpu family: aarch64
Host machine cpu: aarch64

I guess I'll just ignore these warnings.


I think this problem is tracked at:
https://gitlab.com/qemu-project/qemu/-/issues/1244

It is caused by linker flags Meson adds. For Meson, it is tracked at:
https://github.com/mesonbuild/meson/issues/10894

[PATCH 3/3] qga: test: Add tests for `merge-output` flag

[Daniel Xu]

This commit adds a test to ensure `merge-output` functions as expected.
We also add a negative test to ensure we haven't regressed previous
functionality.

Signed-off-by: Daniel Xu 
---
 tests/unit/test-qga.c | 128 --
 1 file changed, 111 insertions(+), 17 deletions(-)

diff --git a/tests/unit/test-qga.c b/tests/unit/test-qga.c
index 9d8e1d1cd3..0b3966024c 100644
--- a/tests/unit/test-qga.c
+++ b/tests/unit/test-qga.c
@@ -755,6 +755,31 @@ static void test_qga_fsfreeze_status(gconstpointer fix)
 g_assert_cmpstr(status, ==, "thawed");
 }
 
+static QDict *wait_for_guest_exec_completion(int fd, int64_t pid)
+{
+QDict *ret = NULL;
+int64_t now;
+bool exited;
+QDict *val;
+
+now = g_get_monotonic_time();
+do {
+ret = qmp_fd(fd,
+ "{'execute': 'guest-exec-status',"
+ " 'arguments': { 'pid': %" PRId64 " } }", pid);
+g_assert_nonnull(ret);
+val = qdict_get_qdict(ret, "return");
+exited = qdict_get_bool(val, "exited");
+if (!exited) {
+qobject_unref(ret);
+}
+} while (!exited &&
+ g_get_monotonic_time() < now + 5 * G_TIME_SPAN_SECOND);
+g_assert(exited);
+
+return ret;
+}
+
 static void test_qga_guest_exec(gconstpointer fix)
 {
 const TestFixture *fixture = fix;
@@ -762,9 +787,8 @@ static void test_qga_guest_exec(gconstpointer fix)
 QDict *val;
 const gchar *out;
 g_autofree guchar *decoded = NULL;
-int64_t pid, now, exitcode;
+int64_t pid, exitcode;
 gsize len;
-bool exited;
 
 /* exec 'echo foo bar' */
 ret = qmp_fd(fixture->fd, "{'execute': 'guest-exec', 'arguments': {"
@@ -777,21 +801,7 @@ static void test_qga_guest_exec(gconstpointer fix)
 g_assert_cmpint(pid, >, 0);
 qobject_unref(ret);
 
-/* wait for completion */
-now = g_get_monotonic_time();
-do {
-ret = qmp_fd(fixture->fd,
- "{'execute': 'guest-exec-status',"
- " 'arguments': { 'pid': %" PRId64 " } }", pid);
-g_assert_nonnull(ret);
-val = qdict_get_qdict(ret, "return");
-exited = qdict_get_bool(val, "exited");
-if (!exited) {
-qobject_unref(ret);
-}
-} while (!exited &&
- g_get_monotonic_time() < now + 5 * G_TIME_SPAN_SECOND);
-g_assert(exited);
+ret = wait_for_guest_exec_completion(fixture->fd, pid);
 
 /* check stdout */
 exitcode = qdict_get_int(val, "exitcode");
@@ -802,6 +812,86 @@ static void test_qga_guest_exec(gconstpointer fix)
 g_assert_cmpstr((char *)decoded, ==, "\" test_str \"");
 }
 
+static void test_qga_guest_exec_output_no_merge(gconstpointer fix)
+{
+const TestFixture *fixture = fix;
+g_autoptr(QDict) ret = NULL;
+QDict *val;
+const gchar *out, *err;
+g_autofree guchar *out_decoded = NULL;
+g_autofree guchar *err_decoded = NULL;
+int64_t pid, exitcode;
+gsize len;
+
+/* exec 'echo foo bar' */
+ret = qmp_fd(fixture->fd, "{'execute': 'guest-exec', 'arguments': {"
+ " 'path': '/bin/bash',"
+ " 'arg': [ '-c', 'for i in $(seq 4); do if (( $i %% 2 )); 
then echo stdout; else echo stderr 1>&2; fi; done;' ],"
+ " 'capture-output': true } }");
+g_assert_nonnull(ret);
+qmp_assert_no_error(ret);
+val = qdict_get_qdict(ret, "return");
+pid = qdict_get_int(val, "pid");
+g_assert_cmpint(pid, >, 0);
+qobject_unref(ret);
+
+ret = wait_for_guest_exec_completion(fixture->fd, pid);
+
+exitcode = qdict_get_int(val, "exitcode");
+g_assert_cmpint(exitcode, ==, 0);
+
+/* check stdout */
+out = qdict_get_str(val, "out-data");
+out_decoded = g_base64_decode(out, );
+g_assert_cmpint(len, ==, 14);
+g_assert_cmpstr((char *)out_decoded, ==, "stdout\nstdout\n");
+
+/* check stderr */
+err = qdict_get_try_str(val, "err-data");
+err_decoded = g_base64_decode(err, );
+g_assert_cmpint(len, ==, 14);
+g_assert_cmpstr((char *)err_decoded, ==, "stderr\nstderr\n");
+}
+
+static void test_qga_guest_exec_output_merge(gconstpointer fix)
+{
+const TestFixture *fixture = fix;
+g_autoptr(QDict) ret = NULL;
+QDict *val;
+const gchar *out, *err;
+g_autofree guchar *decoded = NULL;
+int64_t pid, exitcode;
+gsize len;
+
+/* exec 'echo foo bar' */
+ret = qmp_fd(fixture->fd, "{'execute': 'guest-exec', 'arguments': {"
+ " 'path': '/bin/bash',"
+ " 'arg': [ '-c', 'for i in $(seq 4); do if (( $i %% 2 )); 
then echo stdout; else echo stderr 1>&2; fi; done;' ],"
+ " 'capture-output': true,"
+ " 'merge-output': true } }");
+g_assert_nonnull(ret);
+qmp_assert_no_error(ret);
+val = qdict_get_qdict(ret, "return");
+pid = qdict_get_int(val, "pid");
+g_assert_cmpint(pid, >, 0);
+qobject_unref(ret);
+
+ret = 

[PATCH 2/3] qga: Add optional `merge-output` flag to guest-exec qapi

[Daniel Xu]

Currently, the captured output (via `capture-output`) is segregated into
separate GuestExecStatus fields (`out-data` and `err-data`). This means
that downstream consumers have no way to reassemble the captured data
back into the original stream.

This is relevant for chatty and semi-interactive (ie. read only) CLI
tools.  Such tools may deliberately interleave stdout and stderr for
visual effect. If segregated, the output becomes harder to visually
understand.

This commit adds a new optional flag to the guest-exec qapi to merge the
output streams such that consumers can have a pristine view of the
original command output.

Signed-off-by: Daniel Xu 
---
 qga/commands.c   | 13 -
 qga/qapi-schema.json |  6 +-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/qga/commands.c b/qga/commands.c
index 360077364e..14b970e768 100644
--- a/qga/commands.c
+++ b/qga/commands.c
@@ -274,6 +274,15 @@ static void guest_exec_child_watch(GPid pid, gint status, 
gpointer data)
 /** Reset ignored signals back to default. */
 static void guest_exec_task_setup(gpointer data)
 {
+bool has_merge = *(bool *)data;
+
+if (has_merge) {
+if (dup2(STDOUT_FILENO, STDERR_FILENO) != 0) {
+slog("dup2() failed to merge stderr into stdout: %s",
+ strerror(errno));
+}
+}
+
 #if !defined(G_OS_WIN32)
 struct sigaction sigact;
 
@@ -385,6 +394,7 @@ GuestExec *qmp_guest_exec(const char *path,
bool has_env, strList *env,
const char *input_data,
bool has_capture_output, bool capture_output,
+   bool has_merge_output, bool merge_output,
Error **errp)
 {
 GPid pid;
@@ -398,6 +408,7 @@ GuestExec *qmp_guest_exec(const char *path,
 GIOChannel *in_ch, *out_ch, *err_ch;
 GSpawnFlags flags;
 bool has_output = (has_capture_output && capture_output);
+bool has_merge = (has_merge_output && merge_output);
 g_autofree uint8_t *input = NULL;
 size_t ninput = 0;
 
@@ -421,7 +432,7 @@ GuestExec *qmp_guest_exec(const char *path,
 }
 
 ret = g_spawn_async_with_pipes(NULL, argv, envp, flags,
-guest_exec_task_setup, NULL, , input_data ? _fd : NULL,
+guest_exec_task_setup, _merge, , input_data ? _fd : 
NULL,
 has_output ? _fd : NULL, has_output ? _fd : NULL, );
 if (!ret) {
 error_setg(errp, QERR_QGA_COMMAND_FAILED, gerr->message);
diff --git a/qga/qapi-schema.json b/qga/qapi-schema.json
index 796434ed34..4192fcc5a4 100644
--- a/qga/qapi-schema.json
+++ b/qga/qapi-schema.json
@@ -1211,6 +1211,9 @@
 # @input-data: data to be passed to process stdin (base64 encoded)
 # @capture-output: bool flag to enable capture of
 #  stdout/stderr of running process. defaults to false.
+# @merge-output: bool flag to merge stdout/stderr of running process
+#into stdout. only effective if used with @capture-output.
+#defaults to false.
 #
 # Returns: PID on success.
 #
@@ -1218,7 +1221,8 @@
 ##
 { 'command': 'guest-exec',
   'data':{ 'path': 'str', '*arg': ['str'], '*env': ['str'],
-   '*input-data': 'str', '*capture-output': 'bool' },
+   '*input-data': 'str', '*capture-output': 'bool',
+   '*merge-output': 'bool' },
   'returns': 'GuestExec' }
 
 
-- 
2.39.1

[PATCH 0/3] qga: Add optional `merge-output` flag to guest-exec QAPI

[Daniel Xu]

Currently, the captured output (via `capture-output`) is segregated into
separate GuestExecStatus fields (`out-data` and `err-data`). This means
that downstream consumers have no way to reassemble the captured data
back into the original stream.

This is relevant for chatty and semi-interactive (ie. read only) CLI
tools.  Such tools may deliberately interleave stdout and stderr for
visual effect. If segregated, the output becomes harder to visually
understand.

This patchset adds support for merging stderr and stdout output streams
via a new QAPI flag.

Daniel Xu (3):
  qga: test: Use absolute path to test data
  qga: Add optional `merge-output` flag to guest-exec qapi
  qga: test: Add tests for `merge-output` flag

 qga/commands.c|  13 +++-
 qga/qapi-schema.json  |   6 +-
 tests/unit/test-qga.c | 135 --
 3 files changed, 133 insertions(+), 21 deletions(-)

-- 
2.39.1

[PATCH 1/3] qga: test: Use absolute path to test data

[Daniel Xu]

It looks like qga's working directory is in a tempdir. So the relative
path that the test case gives qga through the QGA_OS_RELEASE=
env variable does not resolve correctly.

Fix by doing a poor man's path canonicalization of the test data file.

Note we cannot use g_canonicalize_filename() b/c that helper was only
introduced in glib 2.58 and the current GLIB_VERSION_MAX_ALLOWED is
pinned to 2.56.

Signed-off-by: Daniel Xu 
---
 tests/unit/test-qga.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/unit/test-qga.c b/tests/unit/test-qga.c
index b4e0a14573..9d8e1d1cd3 100644
--- a/tests/unit/test-qga.c
+++ b/tests/unit/test-qga.c
@@ -881,13 +881,16 @@ static void test_qga_guest_get_osinfo(gconstpointer data)
 {
 TestFixture fixture;
 const gchar *str;
+g_autofree const gchar *cwd;
 g_autoptr(QDict) ret = NULL;
 char *env[2];
 QDict *val;
 
+cwd = g_get_current_dir();
 env[0] = g_strdup_printf(
-"QGA_OS_RELEASE=%s%c..%cdata%ctest-qga-os-release",
-g_test_get_dir(G_TEST_DIST), G_DIR_SEPARATOR, G_DIR_SEPARATOR, 
G_DIR_SEPARATOR);
+"QGA_OS_RELEASE=%s%c%s%c..%cdata%ctest-qga-os-release",
+cwd, G_DIR_SEPARATOR, g_test_get_dir(G_TEST_DIST), G_DIR_SEPARATOR,
+G_DIR_SEPARATOR, G_DIR_SEPARATOR);
 env[1] = NULL;
 fixture_setup(, NULL, env);
 
-- 
2.39.1

Re: [PATCH v3 1/1] vhost-user-fs: add migration type property

[Anton Kuchin]

On 23/02/2023 23:24, Stefan Hajnoczi wrote:

On Thu, Feb 23, 2023 at 02:36:33AM -0500, Michael S. Tsirkin wrote:

On Wed, Feb 22, 2023 at 03:21:42PM -0500, Michael S. Tsirkin wrote:

On Wed, Feb 22, 2023 at 08:25:19PM +0200, Anton Kuchin wrote:

On 22/02/2023 19:12, Michael S. Tsirkin wrote:

On Wed, Feb 22, 2023 at 07:05:47PM +0200, Anton Kuchin wrote:

On 22/02/2023 18:51, Michael S. Tsirkin wrote:

On Wed, Feb 22, 2023 at 06:49:10PM +0200, Anton Kuchin wrote:

On 22/02/2023 17:14, Vladimir Sementsov-Ogievskiy wrote:

On 22.02.23 17:25, Anton Kuchin wrote:

+static int vhost_user_fs_pre_save(void *opaque)
+{
+    VHostUserFS *fs = opaque;
+    g_autofree char *path = object_get_canonical_path(OBJECT(fs));
+
+    switch (fs->migration_type) {
+    case VHOST_USER_MIGRATION_TYPE_NONE:
+    error_report("Migration is blocked by device %s", path);
+    break;
+    case VHOST_USER_MIGRATION_TYPE_EXTERNAL:
+    return 0;
+    default:
+    error_report("Migration type '%s' is not
supported by device %s",
+ VhostUserMigrationType_str(fs->migration_type), path);
+    break;
+    }
+
+    return -1;
+}

Should we also add this as .pre_load, to force user select
correct migration_type on target too?

In fact, I would claim we only want pre_load.
When qemu is started on destination we know where it's migrated
from so this flag can be set.
When qemu is started on source we generally do not yet know so
we don't know whether it's safe to set this flag.

But destination is a "source" for next migration, so there shouldn't be
real difference.
The new property has ".realized_set_allowed = true", so, as I understand
it may be changed at any time, so that's not a problem.

Yes, exactly. So destination's property sets not how it will handle this
incoming
migration but the future outgoing one.

How do you know where you are going to migrate though?
I think you don't.
Setting it on source is better since we know where we
are migrating from.

Yes, I don't know where I'm going to migrate to. This is why property
affects only how source saves state on outgoing migration.

Um. I don't get the logic.

For this feature to work we need orchestrator to manage the migration. And
we
generally assume that it is responsibility of orchestrator to ensure
matching
properties on source and destination.
As orchestrator manages both sides of migration it can set option (and we
can
check it) on either source or destination. Now it's not important which side
we
select, because now the option is essentially binary allow/deny (but IMHO it
is much better to refuse source to migrate than find later that state can't
be
loaded by destination, in case of file migration this becomes especially
painful).

But there are plans to add internal migration option (extract FUSE state
from
backend and transfer it in QEMU migration stream), and that's where
setting/checking
on source becomes important because it will rely on this property to decide
if
extra state form backend needs to be put in the migration stream subsection.


If we do internal migration that will be a different property
which has to match on source *and* destination.



If you are concerned about orchestrator breaking assumption of matching
properties
on source and destination this is not really supported AFAIK but I don't
think we
need to punish it for this, maybe it has its reasons: I can imagine scenario
where orchestrator could want to migrate from source with
'migration=external'
to destination with 'migration=none' to ensure that destination can't be
migrated further.

No. I am concerned about a simple practical matter:
- I decide to restart qemu on the same host - so I need to enable
   migration
- Later I decide to migrate qemu to another host - this should be
   blocked


Property on source does not satisfy both at the same time.
Property on destination does.


Stefan what's your take on this? Should we move this from
save to load hook?

This property can be changed on the source at runtime via qom-set, so
you don't need to predict the future. The device can be started from an
incoming migration with "external" and then set to "stateful" migration
to migrate to another host later on.

Anton, can you share the virtiofsd patches so we have a full picture of
how "external" migration works? I'd like to understand the workflow and
also how it can be extended when "stateful" migration is added.


Unfortunately internal implementation is relying heavily on our 
infrastructure,
and rust virtiofsd still lacks dirty tracking so it is not ready yet. 
But I did

have a PoC for deprecated now C virtiofsd that I didn't bother to prepare
for upstreaming because C version was declared unsupported. It 
essentially adds

reconnect and this was the only thing required from virtiofsd to support
migration via file.

If this helps I'll try to find patches or recreate then and will be 
happy to share.









This property selects if VM can migrate and if it can what should
qemu put

[PATCH 4/6] target/riscv: Add *envcfg.PBMTE related check in address translation

[Weiwei Li]

menvcfg.PBMTE bit controls whether the Svpbmt extension is available
for use in S-mode and G-stage address translation.

henvcfg.PBMTE bit controls whether the Svpbmt extension is available
for use in VS-stage address translation.

Set *envcfg.PBMTE default true for backward compatibility.

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/cpu.c|  3 +++
 target/riscv/cpu_helper.c | 10 --
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 0dd2f0c753..2d99679f2f 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -613,6 +613,9 @@ static void riscv_cpu_reset_hold(Object *obj)
 env->bins = 0;
 env->two_stage_lookup = false;
 
+env->menvcfg = (cpu->cfg.ext_svpbmt ? MENVCFG_PBMTE : 0);
+env->henvcfg = (cpu->cfg.ext_svpbmt ? HENVCFG_PBMTE : 0);
+
 /* Initialized default priorities of local interrupts. */
 for (i = 0; i < ARRAY_SIZE(env->miprio); i++) {
 iprio = riscv_cpu_default_priority(i);
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index ad8d82662c..552c0f0b58 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -936,9 +936,15 @@ restart:
 return TRANSLATE_FAIL;
 }
 
+bool pbmte = env->menvcfg & MENVCFG_PBMTE;
+
+if (first_stage && two_stage && riscv_cpu_virt_enabled(env)) {
+pbmte = pbmte && (env->henvcfg & HENVCFG_PBMTE);
+}
+
 if (riscv_cpu_sxl(env) == MXL_RV32) {
 ppn = pte >> PTE_PPN_SHIFT;
-} else if (cpu->cfg.ext_svpbmt || cpu->cfg.ext_svnapot) {
+} else if (pbmte || cpu->cfg.ext_svnapot) {
 ppn = (pte & (target_ulong)PTE_PPN_MASK) >> PTE_PPN_SHIFT;
 } else {
 ppn = pte >> PTE_PPN_SHIFT;
@@ -950,7 +956,7 @@ restart:
 if (!(pte & PTE_V)) {
 /* Invalid PTE */
 return TRANSLATE_FAIL;
-} else if (!cpu->cfg.ext_svpbmt && (pte & PTE_PBMT)) {
+} else if (!pbmte && (pte & PTE_PBMT)) {
 return TRANSLATE_FAIL;
 } else if (!(pte & (PTE_R | PTE_W | PTE_X))) {
 /* Inner PTE, continue walking */
-- 
2.25.1

[PATCH 6/6] target/riscv: Export Svadu property

[Weiwei Li]

Set it default true for backward compatibility

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/cpu.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index b81ab65de5..d7c4c747dc 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -107,6 +107,7 @@ static const struct isa_ext_data isa_edata_arr[] = {
 ISA_EXT_DATA_ENTRY(ssaia, true, PRIV_VERSION_1_12_0, ext_ssaia),
 ISA_EXT_DATA_ENTRY(sscofpmf, true, PRIV_VERSION_1_12_0, ext_sscofpmf),
 ISA_EXT_DATA_ENTRY(sstc, true, PRIV_VERSION_1_12_0, ext_sstc),
+ISA_EXT_DATA_ENTRY(svadu, true, PRIV_VERSION_1_12_0, ext_svadu),
 ISA_EXT_DATA_ENTRY(svinval, true, PRIV_VERSION_1_12_0, ext_svinval),
 ISA_EXT_DATA_ENTRY(svnapot, true, PRIV_VERSION_1_12_0, ext_svnapot),
 ISA_EXT_DATA_ENTRY(svpbmt, true, PRIV_VERSION_1_12_0, ext_svpbmt),
@@ -1104,6 +1105,8 @@ static Property riscv_cpu_extensions[] = {
 DEFINE_PROP_UINT16("vlen", RISCVCPU, cfg.vlen, 128),
 DEFINE_PROP_UINT16("elen", RISCVCPU, cfg.elen, 64),
 
+DEFINE_PROP_BOOL("svadu", RISCVCPU, cfg.ext_svadu, true),
+
 DEFINE_PROP_BOOL("svinval", RISCVCPU, cfg.ext_svinval, false),
 DEFINE_PROP_BOOL("svnapot", RISCVCPU, cfg.ext_svnapot, false),
 DEFINE_PROP_BOOL("svpbmt", RISCVCPU, cfg.ext_svpbmt, false),
-- 
2.25.1

[PATCH 5/6] target/riscv: Add *envcfg.HADE related check in address translation

[Weiwei Li]

When menvcfg.HADE is 1, hardware updating of PTE A/D bits is enabled
during single-stage address translation. When the hypervisor extension is
implemented, if menvcfg.HADE is 1, hardware updating of PTE A/D bits is
enabled during G-stage address translation.

Set *envcfg.HADE default true for backward compatibility.

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/cpu.c| 6 --
 target/riscv/cpu_helper.c | 6 ++
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 2d99679f2f..b81ab65de5 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -613,8 +613,10 @@ static void riscv_cpu_reset_hold(Object *obj)
 env->bins = 0;
 env->two_stage_lookup = false;
 
-env->menvcfg = (cpu->cfg.ext_svpbmt ? MENVCFG_PBMTE : 0);
-env->henvcfg = (cpu->cfg.ext_svpbmt ? HENVCFG_PBMTE : 0);
+env->menvcfg = (cpu->cfg.ext_svpbmt ? MENVCFG_PBMTE : 0) |
+   (cpu->cfg.ext_svadu ? MENVCFG_HADE : 0);
+env->henvcfg = (cpu->cfg.ext_svpbmt ? HENVCFG_PBMTE : 0) |
+   (cpu->cfg.ext_svadu ? HENVCFG_HADE : 0);
 
 /* Initialized default priorities of local interrupts. */
 for (i = 0; i < ARRAY_SIZE(env->miprio); i++) {
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 552c0f0b58..9e122ee92a 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -937,9 +937,11 @@ restart:
 }
 
 bool pbmte = env->menvcfg & MENVCFG_PBMTE;
+bool hade = env->menvcfg & MENVCFG_HADE;
 
 if (first_stage && two_stage && riscv_cpu_virt_enabled(env)) {
 pbmte = pbmte && (env->henvcfg & HENVCFG_PBMTE);
+hade = hade && (env->henvcfg & HENVCFG_HADE);
 }
 
 if (riscv_cpu_sxl(env) == MXL_RV32) {
@@ -998,6 +1000,10 @@ restart:
 
 /* Page table updates need to be atomic with MTTCG enabled */
 if (updated_pte != pte) {
+if (!hade) {
+return TRANSLATE_FAIL;
+}
+
 /*
  * - if accessed or dirty bits need updating, and the PTE is
  *   in RAM, then we do so atomically with a compare and swap.
-- 
2.25.1

[PATCH 3/6] target/riscv: Add csr support for svadu

[Weiwei Li]

Add ext_svadu property
Add HADE field in *envcfg:
* menvcfg.HADE is read-only zero if Svadu is not implemented.
* henvcfg.HADE is read-only zero if menvcfg.HADE is zero.

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/cpu.h  |  1 +
 target/riscv/cpu_bits.h |  4 
 target/riscv/csr.c  | 17 +++--
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 7128438d8e..bd272c35d1 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -450,6 +450,7 @@ struct RISCVCPUConfig {
 bool ext_zihintpause;
 bool ext_smstateen;
 bool ext_sstc;
+bool ext_svadu;
 bool ext_svinval;
 bool ext_svnapot;
 bool ext_svpbmt;
diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
index 8b0d7e20ea..fca7ef0cef 100644
--- a/target/riscv/cpu_bits.h
+++ b/target/riscv/cpu_bits.h
@@ -747,10 +747,12 @@ typedef enum RISCVException {
 #define MENVCFG_CBIE   (3UL << 4)
 #define MENVCFG_CBCFE  BIT(6)
 #define MENVCFG_CBZE   BIT(7)
+#define MENVCFG_HADE   (1ULL << 61)
 #define MENVCFG_PBMTE  (1ULL << 62)
 #define MENVCFG_STCE   (1ULL << 63)
 
 /* For RV32 */
+#define MENVCFGH_HADE  BIT(29)
 #define MENVCFGH_PBMTE BIT(30)
 #define MENVCFGH_STCE  BIT(31)
 
@@ -763,10 +765,12 @@ typedef enum RISCVException {
 #define HENVCFG_CBIE   MENVCFG_CBIE
 #define HENVCFG_CBCFE  MENVCFG_CBCFE
 #define HENVCFG_CBZE   MENVCFG_CBZE
+#define HENVCFG_HADE   MENVCFG_HADE
 #define HENVCFG_PBMTE  MENVCFG_PBMTE
 #define HENVCFG_STCE   MENVCFG_STCE
 
 /* For RV32 */
+#define HENVCFGH_HADE   MENVCFGH_HADE
 #define HENVCFGH_PBMTE  MENVCFGH_PBMTE
 #define HENVCFGH_STCE   MENVCFGH_STCE
 
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 02cb2c2bb7..63e140e8ad 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -1890,7 +1890,8 @@ static RISCVException write_menvcfg(CPURISCVState *env, 
int csrno,
 
 if (riscv_cpu_mxl(env) == MXL_RV64) {
 mask |= (cfg->ext_svpbmt ? MENVCFG_PBMTE : 0) |
-(cfg->ext_sstc ? MENVCFG_STCE : 0);
+(cfg->ext_sstc ? MENVCFG_STCE : 0) |
+(cfg->ext_svadu ? MENVCFG_HADE : 0);
 }
 env->menvcfg = (env->menvcfg & ~mask) | (val & mask);
 
@@ -1909,7 +1910,8 @@ static RISCVException write_menvcfgh(CPURISCVState *env, 
int csrno,
 {
 RISCVCPUConfig *cfg = _archcpu(env)->cfg;
 uint64_t mask = (cfg->ext_svpbmt ? MENVCFG_PBMTE : 0) |
-(cfg->ext_sstc ? MENVCFG_STCE : 0);
+(cfg->ext_sstc ? MENVCFG_STCE : 0) |
+(cfg->ext_svadu ? MENVCFG_HADE : 0);
 uint64_t valh = (uint64_t)val << 32;
 
 env->menvcfg = (env->menvcfg & ~mask) | (valh & mask);
@@ -1959,8 +1961,10 @@ static RISCVException read_henvcfg(CPURISCVState *env, 
int csrno,
 /*
  * henvcfg.pbmte is read_only 0 when menvcfg.pbmte = 0
  * henvcfg.stce is read_only 0 when menvcfg.stce = 0
+ * henvcfg.hade is read_only 0 when menvcfg.hade = 0
  */
-*val = env->henvcfg & (~(HENVCFG_PBMTE | HENVCFG_STCE) | env->menvcfg);
+*val = env->henvcfg & (~(HENVCFG_PBMTE | HENVCFG_STCE | HENVCFG_HADE) |
+   env->menvcfg);
 return RISCV_EXCP_NONE;
 }
 
@@ -1976,7 +1980,7 @@ static RISCVException write_henvcfg(CPURISCVState *env, 
int csrno,
 }
 
 if (riscv_cpu_mxl(env) == MXL_RV64) {
-mask |= env->menvcfg & (HENVCFG_PBMTE | HENVCFG_STCE);
+mask |= env->menvcfg & (HENVCFG_PBMTE | HENVCFG_STCE | HENVCFG_HADE);
 }
 
 env->henvcfg = (env->henvcfg & ~mask) | (val & mask);
@@ -1994,7 +1998,7 @@ static RISCVException read_henvcfgh(CPURISCVState *env, 
int csrno,
 return ret;
 }
 
-*val = (env->henvcfg & (~(HENVCFG_PBMTE | HENVCFG_STCE) |
+*val = (env->henvcfg & (~(HENVCFG_PBMTE | HENVCFG_STCE | HENVCFG_HADE) |
 env->menvcfg)) >> 32;
 return RISCV_EXCP_NONE;
 }
@@ -2002,7 +2006,8 @@ static RISCVException read_henvcfgh(CPURISCVState *env, 
int csrno,
 static RISCVException write_henvcfgh(CPURISCVState *env, int csrno,
   target_ulong val)
 {
-uint64_t mask = env->menvcfg & (HENVCFG_PBMTE | HENVCFG_STCE);
+uint64_t mask = env->menvcfg & (HENVCFG_PBMTE | HENVCFG_STCE |
+HENVCFG_HADE);
 uint64_t valh = (uint64_t)val << 32;
 RISCVException ret;
 
-- 
2.25.1

[PATCH 1/6] target/riscv: Fix the relationship between menvcfg.PBMTE/STCE and Svpbmt/Sstc extensions

[Weiwei Li]

menvcfg.PBMTE/STCE are read-only zero if Svpbmt/Sstc are not implemented.

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/csr.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index fa17d7770c..feae23cab0 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -1885,10 +1885,12 @@ static RISCVException read_menvcfg(CPURISCVState *env, 
int csrno,
 static RISCVException write_menvcfg(CPURISCVState *env, int csrno,
   target_ulong val)
 {
+RISCVCPUConfig *cfg = _archcpu(env)->cfg;
 uint64_t mask = MENVCFG_FIOM | MENVCFG_CBIE | MENVCFG_CBCFE | MENVCFG_CBZE;
 
 if (riscv_cpu_mxl(env) == MXL_RV64) {
-mask |= MENVCFG_PBMTE | MENVCFG_STCE;
+mask |= (cfg->ext_svpbmt ? MENVCFG_PBMTE : 0) |
+(cfg->ext_sstc ? MENVCFG_STCE : 0);
 }
 env->menvcfg = (env->menvcfg & ~mask) | (val & mask);
 
@@ -1905,7 +1907,9 @@ static RISCVException read_menvcfgh(CPURISCVState *env, 
int csrno,
 static RISCVException write_menvcfgh(CPURISCVState *env, int csrno,
   target_ulong val)
 {
-uint64_t mask = MENVCFG_PBMTE | MENVCFG_STCE;
+RISCVCPUConfig *cfg = _archcpu(env)->cfg;
+uint64_t mask = (cfg->ext_svpbmt ? MENVCFG_PBMTE : 0) |
+(cfg->ext_sstc ? MENVCFG_STCE : 0);
 uint64_t valh = (uint64_t)val << 32;
 
 env->menvcfg = (env->menvcfg & ~mask) | (valh & mask);
-- 
2.25.1

[PATCH 2/6] target/riscv: Fix the relationship of PBMTE/STCE fields between menvcfg and henvcfg

[Weiwei Li]

henvcfg.PBMTE/STCE are read-only zero if menvcfg.PBMTE/STCE are zero.

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/csr.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index feae23cab0..02cb2c2bb7 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -1956,7 +1956,11 @@ static RISCVException read_henvcfg(CPURISCVState *env, 
int csrno,
 return ret;
 }
 
-*val = env->henvcfg;
+/*
+ * henvcfg.pbmte is read_only 0 when menvcfg.pbmte = 0
+ * henvcfg.stce is read_only 0 when menvcfg.stce = 0
+ */
+*val = env->henvcfg & (~(HENVCFG_PBMTE | HENVCFG_STCE) | env->menvcfg);
 return RISCV_EXCP_NONE;
 }
 
@@ -1972,7 +1976,7 @@ static RISCVException write_henvcfg(CPURISCVState *env, 
int csrno,
 }
 
 if (riscv_cpu_mxl(env) == MXL_RV64) {
-mask |= HENVCFG_PBMTE | HENVCFG_STCE;
+mask |= env->menvcfg & (HENVCFG_PBMTE | HENVCFG_STCE);
 }
 
 env->henvcfg = (env->henvcfg & ~mask) | (val & mask);
@@ -1990,14 +1994,15 @@ static RISCVException read_henvcfgh(CPURISCVState *env, 
int csrno,
 return ret;
 }
 
-*val = env->henvcfg >> 32;
+*val = (env->henvcfg & (~(HENVCFG_PBMTE | HENVCFG_STCE) |
+env->menvcfg)) >> 32;
 return RISCV_EXCP_NONE;
 }
 
 static RISCVException write_henvcfgh(CPURISCVState *env, int csrno,
   target_ulong val)
 {
-uint64_t mask = HENVCFG_PBMTE | HENVCFG_STCE;
+uint64_t mask = env->menvcfg & (HENVCFG_PBMTE | HENVCFG_STCE);
 uint64_t valh = (uint64_t)val << 32;
 RISCVException ret;
 
-- 
2.25.1

[PATCH 0/6] target/riscv: Add support for Svadu extension

[Weiwei Li]

This patchset adds support svadu extension. It also fixes some relationship 
between *envcfg fields and Svpbmt/Sstc extensions.

Specification for Svadu extension can be found in:

https://github.com/riscv/riscv-svadu

The port is available here:
https://github.com/plctlab/plct-qemu/tree/plct-svadu-upstream

Weiwei Li (6):
  target/riscv: Fix the relationship between menvcfg.PBMTE/STCE and
Svpbmt/Sstc extensions
  target/riscv: Fix the relationship of PBMTE/STCE fields between
menvcfg and henvcfg
  target/riscv: Add csr support for svadu
  target/riscv: Add *envcfg.PBMTE related check in address translation
  target/riscv: Add *envcfg.HADE related check in address translation
  target/riscv: Export Svadu property

 target/riscv/cpu.c|  8 
 target/riscv/cpu.h|  1 +
 target/riscv/cpu_bits.h   |  4 
 target/riscv/cpu_helper.c | 16 ++--
 target/riscv/csr.c| 26 --
 5 files changed, 47 insertions(+), 8 deletions(-)

-- 
2.25.1

RE: [PATCH v5 7/9] aspeed/soc : Add AST1030 support

[Troy Lee]

Hi Philippe,

> -Original Message-
> From: Philippe Mathieu-Daudé 
> Sent: Thursday, February 23, 2023 6:44 PM
> To: Jamin Lin ; Cédric Le Goater ;
> Peter Maydell ; Andrew Jeffery
> ; Joel Stanley ; Alistair Francis
> ; Cleber Rosa ; Wainer dos
> Santos Moschetta ; Beraldo Leal
> ; open list:ASPEED BMCs ;
> open list:All patches CC here 
> Cc: Steven Lee ; Troy Lee
> 
> Subject: Re: [PATCH v5 7/9] aspeed/soc : Add AST1030 support
> 
> ping
> 
> On 29/12/22 12:16, Philippe Mathieu-Daudé wrote:
> > Hi,
> >
> > On 1/4/22 10:38, Jamin Lin wrote:
> >> From: Steven Lee 
> >>
> >> The embedded core of AST1030 SoC is ARM Coretex M4.
> >> It is hard to be integrated in the common Aspeed Soc framework.
> >> We introduce a new ast1030 class with instance_init and realize
> >> handlers.
> >>
> >> Signed-off-by: Troy Lee 
> >> Signed-off-by: Jamin Lin 
> >> Signed-off-by: Steven Lee 
> >> Reviewed-by: Cédric Le Goater 
> >> ---
> >>   hw/arm/aspeed_ast10xx.c | 299
> >> 
> >>   hw/arm/meson.build  |   6 +-
> >>   include/hw/arm/aspeed_soc.h |   3 +
> >>   3 files changed, 307 insertions(+), 1 deletion(-)
> >>   create mode 100644 hw/arm/aspeed_ast10xx.c
> >
> >
> >> +static void aspeed_soc_ast1030_realize(DeviceState *dev_soc, Error
> >> **errp)
> >> +{
> >> +    AspeedSoCState *s = ASPEED_SOC(dev_soc);
> >> +    AspeedSoCClass *sc = ASPEED_SOC_GET_CLASS(s);
> >> +    MemoryRegion *system_memory = get_system_memory();
> >> +    DeviceState *armv7m;
> >> +    Error *err = NULL;
> >> +    int i;
> >> +
> >> +    if (!clock_has_source(s->sysclk)) {
> >> +    error_setg(errp, "sysclk clock must be wired up by the board
> >> code");
> >> +    return;
> >> +    }
> >> +
> >> +    /* General I/O memory space to catch all unimplemented device */
> >> +    create_unimplemented_device("aspeed.sbc",
> >> +    sc->memmap[ASPEED_DEV_SBC],
> >> +    0x4);
> >> +    create_unimplemented_device("aspeed.io",
> >> +    sc->memmap[ASPEED_DEV_IOMEM],
> >> +    ASPEED_SOC_IOMEM_SIZE);
> >> +
> >> +    /* AST1030 CPU Core */
> >> +    armv7m = DEVICE(>armv7m);
> >> +    qdev_prop_set_uint32(armv7m, "num-irq", 256);
> >
> > Can you confirm this SoC has 256 and not 240 IRQs?
> >
The interrupt number start from 0 to 148, and some of them are reserved. 
Should we send an update to seth num-irq to 149?

Thanks,
Troy Lee

> >> +    qdev_prop_set_string(armv7m, "cpu-type", sc->cpu_type);
> >> +    qdev_connect_clock_in(armv7m, "cpuclk", s->sysclk);
> >> +    object_property_set_link(OBJECT(>armv7m), "memory",
> >> + OBJECT(system_memory), _abort);
> >> +    sysbus_realize(SYS_BUS_DEVICE(>armv7m), _abort);
> >

Re: [PATCH] vdpa: stop all svq on device deletion

[Jason Wang]

On Thu, Feb 23, 2023 at 4:51 PM Laurent Vivier  wrote:
>
> Hi,
>
> this patch fixes a QEMU crash, could it be merged?

Acked-by: Jason Wang 

I think it should go with Michael's tree.

Thanks

>
> Thanks,
> Laurent
>
> On 2/9/23 18:00, Eugenio Pérez wrote:
> > Not stopping them leave the device in a bad state when virtio-net
> > fronted device is unplugged with device_del monitor command.
> >
> > This is not triggable in regular poweroff or qemu forces shutdown
> > because cleanup is called right after vhost_vdpa_dev_start(false).  But
> > devices hot unplug does not call vdpa device cleanups.  This lead to all
> > the vhost_vdpa devices without stop the SVQ but the last.
> >
> > Fix it and clean the code, making it symmetric with
> > vhost_vdpa_svqs_start.
> >
> > Fixes: dff4426fa656 ("vhost: Add Shadow VirtQueue kick forwarding 
> > capabilities")
> > Reported-by: Lei Yang 
> > Signed-off-by: Eugenio Pérez 
> > ---
> >   hw/virtio/vhost-vdpa.c | 17 ++---
> >   1 file changed, 2 insertions(+), 15 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> > index 542e003101..df3a1e92ac 100644
> > --- a/hw/virtio/vhost-vdpa.c
> > +++ b/hw/virtio/vhost-vdpa.c
> > @@ -689,26 +689,11 @@ static int vhost_vdpa_get_device_id(struct vhost_dev 
> > *dev,
> >   return ret;
> >   }
> >
> > -static void vhost_vdpa_reset_svq(struct vhost_vdpa *v)
> > -{
> > -if (!v->shadow_vqs_enabled) {
> > -return;
> > -}
> > -
> > -for (unsigned i = 0; i < v->shadow_vqs->len; ++i) {
> > -VhostShadowVirtqueue *svq = g_ptr_array_index(v->shadow_vqs, i);
> > -vhost_svq_stop(svq);
> > -}
> > -}
> > -
> >   static int vhost_vdpa_reset_device(struct vhost_dev *dev)
> >   {
> > -struct vhost_vdpa *v = dev->opaque;
> >   int ret;
> >   uint8_t status = 0;
> >
> > -vhost_vdpa_reset_svq(v);
> > -
> >   ret = vhost_vdpa_call(dev, VHOST_VDPA_SET_STATUS, );
> >   trace_vhost_vdpa_reset_device(dev, status);
> >   return ret;
> > @@ -1100,6 +1085,8 @@ static void vhost_vdpa_svqs_stop(struct vhost_dev 
> > *dev)
> >
> >   for (unsigned i = 0; i < v->shadow_vqs->len; ++i) {
> >   VhostShadowVirtqueue *svq = g_ptr_array_index(v->shadow_vqs, i);
> > +
> > +vhost_svq_stop(svq);
> >   vhost_vdpa_svq_unmap_rings(dev, svq);
> >
> >   event_notifier_cleanup(>hdev_kick);
>

Re: [PATCH v2 11/13] vdpa: block migration if dev does not have _F_SUSPEND

[Jason Wang]

On Thu, Feb 23, 2023 at 7:07 PM Eugenio Perez Martin
 wrote:
>
> On Thu, Feb 23, 2023 at 3:38 AM Jason Wang  wrote:
> >
> >
> > 在 2023/2/22 22:25, Eugenio Perez Martin 写道:
> > > On Wed, Feb 22, 2023 at 5:05 AM Jason Wang  wrote:
> > >>
> > >> 在 2023/2/8 17:42, Eugenio Pérez 写道:
> > >>> Next patches enable devices to be migrated even if vdpa netdev has not
> > >>> been started with x-svq. However, not all devices are migratable, so we
> > >>> need to block migration if we detect that.
> > >>>
> > >>> Block vhost-vdpa device migration if it does not offer _F_SUSPEND and it
> > >>> has not been started with x-svq.
> > >>>
> > >>> Signed-off-by: Eugenio Pérez 
> > >>> ---
> > >>>hw/virtio/vhost-vdpa.c | 21 +
> > >>>1 file changed, 21 insertions(+)
> > >>>
> > >>> diff --git a/hw/virtio/vhost-vdpa.c b/hw/virtio/vhost-vdpa.c
> > >>> index 84a6b9690b..9d30cf9b3c 100644
> > >>> --- a/hw/virtio/vhost-vdpa.c
> > >>> +++ b/hw/virtio/vhost-vdpa.c
> > >>> @@ -442,6 +442,27 @@ static int vhost_vdpa_init(struct vhost_dev *dev, 
> > >>> void *opaque, Error **errp)
> > >>>return 0;
> > >>>}
> > >>>
> > >>> +/*
> > >>> + * If dev->shadow_vqs_enabled at initialization that means the 
> > >>> device has
> > >>> + * been started with x-svq=on, so don't block migration
> > >>> + */
> > >>> +if (dev->migration_blocker == NULL && !v->shadow_vqs_enabled) {
> > >>> +uint64_t backend_features;
> > >>> +
> > >>> +/* We don't have dev->backend_features yet */
> > >>> +ret = vhost_vdpa_call(dev, VHOST_GET_BACKEND_FEATURES,
> > >>> +  _features);
> > >>> +if (unlikely(ret)) {
> > >>> +error_setg_errno(errp, -ret, "Could not get backend 
> > >>> features");
> > >>> +return ret;
> > >>> +}
> > >>> +
> > >>> +if (!(backend_features & BIT_ULL(VHOST_BACKEND_F_SUSPEND))) {
> > >>> +error_setg(>migration_blocker,
> > >>> +"vhost-vdpa backend lacks VHOST_BACKEND_F_SUSPEND 
> > >>> feature.");
> > >>> +}
> > >>
> > >> I wonder why not let the device to decide? For networking device, we can
> > >> live without suspend probably.
> > >>
> > > Right, but how can we know if this is a net device in init? I don't
> > > think a switch (vhost_vdpa_get_device_id(dev)) is elegant.
> >
> >
> > I meant the caller of vhost_vdpa_init() which is net_init_vhost_vdpa().
> >
>
> That's doable but I'm not sure if it is convenient.

So it's a question whether or not we try to let migration work without
suspending. If we don't, there's no need to bother. Looking at the
current vhost-net implementation, it tries to make migration work upon
the error of get_vring_base() so maybe it's worth a try if it doesn't
bother too much. But I'm fine to go either way.

>
> Since we're always offering _F_LOG I thought of the lack of _F_SUSPEND
> as the default migration blocker for other kinds of devices like blk.

Or we can have this by default and allow a specific type of device to clear?

> If we move this code to net_init_vhost_vdpa, all other devices are in
> charge of block migration by themselves.
>
> I guess the right action is to use a variable similar to
> vhost_vdpa->f_log_all. It defaults to false, and the device can choose
> if it should export it or not. This way, the device does not migrate
> by default, and the equivalent of net_init_vhost_vdpa could choose
> whether to offer _F_LOG with SVQ or not.

Looks similar to what I think above.

>
> OTOH I guess other kinds of devices already must place blockers beyond
> _F_LOG, so maybe it makes sense to always offer _F_LOG even if
> _F_SUSPEND is not offered?

I don't see any dependency between the two features. Technically,
there could be devices that have neither _F_LOG nor _F_SUSPEND.

Thanks

> Stefano G., would that break vhost-vdpa-blk
> support?
>
> Thanks!
>
> > Thanks
> >
> >
> > >
> > > If the parent device does not need to be suspended i'd go with
> > > exposing a suspend ioctl but do nothing in the parent device. After
> > > that, it could even choose to return an error for GET_VRING_BASE.
> > >
> > > If we want to implement it as a fallback in qemu, I'd go for
> > > implementing it on top of this series. There are a few operations we
> > > could move to a device-kind specific ops.
> > >
> > > Would it make sense to you?
> > >
> > > Thanks!
> > >
> > >
> > >> Thanks
> > >>
> > >>
> > >>> +}
> > >>> +
> > >>>/*
> > >>> * Similar to VFIO, we end up pinning all guest memory and have 
> > >>> to
> > >>> * disable discarding of RAM.
> >
>

Re: [PATCH V2 0/5] Fix UNMAP notifier for intel-iommu

[Jason Wang]

On Thu, Feb 23, 2023 at 11:47 PM Peter Xu  wrote:
>
> On Thu, Feb 23, 2023 at 02:59:19PM +0800, Jason Wang wrote:
> > Hi All:
> >
> > According to ATS, device should work if ATS is disabled. This is not
> > correctly implemented in the current intel-iommu since it doesn't
> > handle the UNMAP notifier correctly. This breaks the vhost-net +
> > vIOMMU without dt.
> >
> > The root casue is that the when there's a device IOTLB miss (note that
> > it's not specific to PCI so it can work without ATS), Qemu doesn't
> > build the IOVA tree, so when guest start an IOTLB invalidation, Qemu
> > won't trigger the UNMAP notifier.
> >
> > Fixing this by triggering UNMAP notifier in those cases.
>
> Maybe someday we should start merging different places where we used the
> same IOMMU_NOTIFIER_UNMAP event and also taking care of truncation of
> notifier ranges within memory.c, but that can definitely be done later.

Yes, probably.

>
> Reviewed-by: Peter Xu 
>
> Thanks, Jason!

You're welcome :)

Thanks

>
> --
> Peter Xu
>

Re: [PATCH v7 4/4] target/riscv: add Zicbop cbo.prefetch{i, r, m} placeholder

[liweiwei]

On 2023/2/24 07:44, Daniel Henrique Barboza wrote:

From: Christoph Muellner 

The cmo.prefetch instructions are nops for QEMU (no emulation of the
memory hierarchy, no illegal instructions, no permission faults, no
traps).

Add a comment noting where they would be decoded in case cbo.prefetch
instructions become relevant in the future.

Co-developed-by: Philipp Tomsich 
Signed-off-by: Christoph Muellner 
Signed-off-by: Daniel Henrique Barboza 
Reviewed-by: Richard Henderson 
---


Reviewed-by: Weiwei Li 

Weiwei Li


  target/riscv/insn32.decode | 1 +
  1 file changed, 1 insertion(+)

diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 3788f86528..1aebd37572 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -134,6 +134,7 @@ addi  . 000 . 0010011 @i
  slti  . 010 . 0010011 @i
  sltiu . 011 . 0010011 @i
  xori  . 100 . 0010011 @i
+# cbo.prefetch_{i,r,m} instructions are ori with rd=x0 and not decoded.
  ori   . 110 . 0010011 @i
  andi  . 111 . 0010011 @i
  slli 0. ... 001 . 0010011 @sh

Re: [PATCH v7 3/4] target/riscv: implement Zicbom extension

[liweiwei]

On 2023/2/24 07:44, Daniel Henrique Barboza wrote:

From: Christoph Muellner 

Zicbom is the Cache-Block Management extension defined in the already
ratified RISC-V Base Cache Management Operation (CBO) ISA extension [1].

The extension contains three instructions: cbo.clean, cbo.flush and
cbo.inval. All of them must be implemented in the same group as LQ and
cbo.zero due to overlapping patterns.

All these instructions can throw a Illegal Instruction/Virtual
Instruction exception, similar to the existing cbo.zero. The same
check_zicbo_envcfg() is used to handle these exceptions.

Aside from that, these instructions also need to handle page faults and
guest page faults. This is done in a new check_zicbom_access() helper.

As with Zicboz, the cache block size for Zicbom is also configurable.
Note that the spec determines that Zicbo[mp] and Zicboz can have
different cache sizes (Section 2.7 of [1]), so we also include a
'cbom_blocksize' to go along with the existing 'cboz_blocksize'. They
are set to the same size, so unless users want to play around with the
settings both sizes will be the same.

[1] 
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.1.pdf

Co-developed-by: Philipp Tomsich 
Signed-off-by: Christoph Muellner 
Signed-off-by: Daniel Henrique Barboza 


Reviewed-by: Weiwei Li 

Weiwei Li


---
  target/riscv/cpu.c  |  3 +
  target/riscv/cpu.h  |  2 +
  target/riscv/helper.h   |  2 +
  target/riscv/insn32.decode  |  5 ++
  target/riscv/insn_trans/trans_rvzicbo.c.inc | 27 +
  target/riscv/op_helper.c| 67 +
  6 files changed, 106 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 7dd37de7f9..4b779b1775 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -74,6 +74,7 @@ struct isa_ext_data {
  static const struct isa_ext_data isa_edata_arr[] = {
  ISA_EXT_DATA_ENTRY(h, false, PRIV_VERSION_1_12_0, ext_h),
  ISA_EXT_DATA_ENTRY(v, false, PRIV_VERSION_1_10_0, ext_v),
+ISA_EXT_DATA_ENTRY(zicbom, true, PRIV_VERSION_1_12_0, ext_icbom),
  ISA_EXT_DATA_ENTRY(zicboz, true, PRIV_VERSION_1_12_0, ext_icboz),
  ISA_EXT_DATA_ENTRY(zicsr, true, PRIV_VERSION_1_10_0, ext_icsr),
  ISA_EXT_DATA_ENTRY(zifencei, true, PRIV_VERSION_1_10_0, ext_ifencei),
@@ -1127,6 +1128,8 @@ static Property riscv_cpu_extensions[] = {
  DEFINE_PROP_BOOL("zhinx", RISCVCPU, cfg.ext_zhinx, false),
  DEFINE_PROP_BOOL("zhinxmin", RISCVCPU, cfg.ext_zhinxmin, false),
  
+DEFINE_PROP_BOOL("zicbom", RISCVCPU, cfg.ext_icbom, true),

+DEFINE_PROP_UINT16("cbom_blocksize", RISCVCPU, cfg.cbom_blocksize, 64),
  DEFINE_PROP_BOOL("zicboz", RISCVCPU, cfg.ext_icboz, true),
  DEFINE_PROP_UINT16("cboz_blocksize", RISCVCPU, cfg.cboz_blocksize, 64),
  
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h

index 6b4c714d3a..a0673b4604 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -447,6 +447,7 @@ struct RISCVCPUConfig {
  bool ext_zkt;
  bool ext_ifencei;
  bool ext_icsr;
+bool ext_icbom;
  bool ext_icboz;
  bool ext_zihintpause;
  bool ext_smstateen;
@@ -495,6 +496,7 @@ struct RISCVCPUConfig {
  char *vext_spec;
  uint16_t vlen;
  uint16_t elen;
+uint16_t cbom_blocksize;
  uint16_t cboz_blocksize;
  bool mmu;
  bool pmp;
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index ce165821b8..37b54e0991 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -98,6 +98,8 @@ DEF_HELPER_FLAGS_2(fcvt_h_lu, TCG_CALL_NO_RWG, i64, env, tl)
  DEF_HELPER_FLAGS_2(fclass_h, TCG_CALL_NO_RWG_SE, tl, env, i64)
  
  /* Cache-block operations */

+DEF_HELPER_2(cbo_clean_flush, void, env, tl)
+DEF_HELPER_2(cbo_inval, void, env, tl)
  DEF_HELPER_2(cbo_zero, void, env, tl)
  
  /* Special functions */

diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 3985bc703f..3788f86528 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -181,6 +181,11 @@ sraw 010 .  . 101 . 0111011 @r
  ldu     . 111 . 011 @i
  {
[
+# *** RV32 Zicbom Standard Extension ***
+cbo_clean  000 1 . 010 0 000 @sfence_vm
+cbo_flush  000 00010 . 010 0 000 @sfence_vm
+cbo_inval  000 0 . 010 0 000 @sfence_vm
+
  # *** RV32 Zicboz Standard Extension ***
  cbo_zero   000 00100 . 010 0 000 @sfence_vm
]
diff --git a/target/riscv/insn_trans/trans_rvzicbo.c.inc 
b/target/riscv/insn_trans/trans_rvzicbo.c.inc
index feabc28342..7df9c30b58 100644
--- a/target/riscv/insn_trans/trans_rvzicbo.c.inc
+++ b/target/riscv/insn_trans/trans_rvzicbo.c.inc
@@ -16,12 +16,39 @@
   * this program.  If not, see .
   */
  
+#define REQUIRE_ZICBOM(ctx) do {\

+if (!ctx->cfg_ptr->ext_icbom) { \
+ 

Re: [PATCH v7 2/4] target/riscv: implement Zicboz extension

[liweiwei]

On 2023/2/24 07:44, Daniel Henrique Barboza wrote:

From: Christoph Muellner 

The RISC-V base cache management operation (CBO) ISA extension has been
ratified. It defines three extensions: Cache-Block Management, Cache-Block
Prefetch and Cache-Block Zero. More information about the spec can be
found at [1].

Let's start by implementing the Cache-Block Zero extension, Zicboz. It
uses the cbo.zero instruction that, as with all CBO instructions that
will be added later, needs to be implemented in an overlap group with
the LQ instruction due to overlapping patterns.

cbo.zero throws a Illegal Instruction/Virtual Instruction exception
depending on CSR state. This is also the case for the remaining cbo
instructions we're going to add next, so create a check_zicbo_envcfg()
that will be used by all Zicbo[mz] instructions.

[1] 
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.1.pdf

Co-developed-by: Philipp Tomsich 
Signed-off-by: Christoph Muellner 
Signed-off-by: Daniel Henrique Barboza 
---
  target/riscv/cpu.c  |  4 ++
  target/riscv/cpu.h  |  2 +
  target/riscv/helper.h   |  3 +
  target/riscv/insn32.decode  | 10 +++-
  target/riscv/insn_trans/trans_rvzicbo.c.inc | 30 ++
  target/riscv/op_helper.c| 65 +
  target/riscv/translate.c|  1 +
  7 files changed, 114 insertions(+), 1 deletion(-)
  create mode 100644 target/riscv/insn_trans/trans_rvzicbo.c.inc

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 93b52b826c..7dd37de7f9 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -74,6 +74,7 @@ struct isa_ext_data {
  static const struct isa_ext_data isa_edata_arr[] = {
  ISA_EXT_DATA_ENTRY(h, false, PRIV_VERSION_1_12_0, ext_h),
  ISA_EXT_DATA_ENTRY(v, false, PRIV_VERSION_1_10_0, ext_v),
+ISA_EXT_DATA_ENTRY(zicboz, true, PRIV_VERSION_1_12_0, ext_icboz),
  ISA_EXT_DATA_ENTRY(zicsr, true, PRIV_VERSION_1_10_0, ext_icsr),
  ISA_EXT_DATA_ENTRY(zifencei, true, PRIV_VERSION_1_10_0, ext_ifencei),
  ISA_EXT_DATA_ENTRY(zihintpause, true, PRIV_VERSION_1_10_0, 
ext_zihintpause),
@@ -1126,6 +1127,9 @@ static Property riscv_cpu_extensions[] = {
  DEFINE_PROP_BOOL("zhinx", RISCVCPU, cfg.ext_zhinx, false),
  DEFINE_PROP_BOOL("zhinxmin", RISCVCPU, cfg.ext_zhinxmin, false),
  
+DEFINE_PROP_BOOL("zicboz", RISCVCPU, cfg.ext_icboz, true),

+DEFINE_PROP_UINT16("cboz_blocksize", RISCVCPU, cfg.cboz_blocksize, 64),
+
  DEFINE_PROP_BOOL("zmmul", RISCVCPU, cfg.ext_zmmul, false),
  
  /* Vendor-specific custom extensions */

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 7128438d8e..6b4c714d3a 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -447,6 +447,7 @@ struct RISCVCPUConfig {
  bool ext_zkt;
  bool ext_ifencei;
  bool ext_icsr;
+bool ext_icboz;
  bool ext_zihintpause;
  bool ext_smstateen;
  bool ext_sstc;
@@ -494,6 +495,7 @@ struct RISCVCPUConfig {
  char *vext_spec;
  uint16_t vlen;
  uint16_t elen;
+uint16_t cboz_blocksize;
  bool mmu;
  bool pmp;
  bool epmp;
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 0497370afd..ce165821b8 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -97,6 +97,9 @@ DEF_HELPER_FLAGS_2(fcvt_h_l, TCG_CALL_NO_RWG, i64, env, tl)
  DEF_HELPER_FLAGS_2(fcvt_h_lu, TCG_CALL_NO_RWG, i64, env, tl)
  DEF_HELPER_FLAGS_2(fclass_h, TCG_CALL_NO_RWG_SE, tl, env, i64)
  
+/* Cache-block operations */

+DEF_HELPER_2(cbo_zero, void, env, tl)
+
  /* Special functions */
  DEF_HELPER_2(csrr, tl, env, int)
  DEF_HELPER_3(csrw, void, env, int, tl)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index b7e7613ea2..3985bc703f 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -179,7 +179,15 @@ sraw 010 .  . 101 . 0111011 @r
  
  # *** RV128I Base Instruction Set (in addition to RV64I) ***

  ldu     . 111 . 011 @i
-lq      . 010 . 000 @i
+{
+  [
+# *** RV32 Zicboz Standard Extension ***
+cbo_zero   000 00100 . 010 0 000 @sfence_vm
+  ]
+
+  # *** RVI128 lq ***
+  lq      . 010 . 000 @i
+}
  sq      . 100 . 0100011 @s
  addid  .  000 . 1011011 @i
  sllid00 ..  . 001 . 1011011 @sh6
diff --git a/target/riscv/insn_trans/trans_rvzicbo.c.inc 
b/target/riscv/insn_trans/trans_rvzicbo.c.inc
new file mode 100644
index 00..feabc28342
--- /dev/null
+++ b/target/riscv/insn_trans/trans_rvzicbo.c.inc
@@ -0,0 +1,30 @@
+/*
+ * RISC-V translation routines for the RISC-V CBO Extension.
+ *
+ * Copyright (c) 2021 Philipp Tomsich, philipp.toms...@vrull.eu
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms 

[qemu-web PATCH] Announce Google Summer of Code and Outreachy 2023

[Stefan Hajnoczi]

QEMU is participating in GSoC and Outreachy again. This blog post will
draw people's attention to our open source internships and increase the
number of applicants.

Signed-off-by: Stefan Hajnoczi 
---
 _posts/2023-02-23-gsoc-outreachy-2023.md | 46 
 1 file changed, 46 insertions(+)
 create mode 100644 _posts/2023-02-23-gsoc-outreachy-2023.md

diff --git a/_posts/2023-02-23-gsoc-outreachy-2023.md 
b/_posts/2023-02-23-gsoc-outreachy-2023.md
new file mode 100644
index 000..e25d756
--- /dev/null
+++ b/_posts/2023-02-23-gsoc-outreachy-2023.md
@@ -0,0 +1,46 @@
+---
+layout: post
+title:  "Announcing QEMU Google Summer of Code and Outreachy 2023 internships"
+date:   2023-02-23 13:30:00 +
+categories: [internships, gsoc, outreachy]
+---
+QEMU is participating in [Google Summer of
+Code](https://summerofcode.withgoogle.com/) and
+[Outreachy](https://www.outreachy.org/) again this year! Google Summer of Code
+and Outreachy are open source internship programs that offer paid remote work
+opportunities for contributing to open source. Internships generally run May
+through August, so if you have time and want to experience open source
+development, read on to find out how you can apply.
+
+Each intern is paired with one or more mentors, experienced QEMU contributors
+who support them during the internship. Code developed by the intern is
+submitted through the same open source development process that all QEMU
+contributions follow. This gives interns experience with contributing to open
+source software. Some interns then choose to pursue a career in open source
+software after completing their internship.
+
+## Find out if you are eligible
+Information on who can apply is
+[here](https://developers.google.com/open-source/gsoc/faq#what_are_the_eligibility_requirements_for_participation)
+for Google Summer of Code and [here](https://www.outreachy.org/apply/) for
+Outreachy. Note that Outreachy initial applications ended on February 6th so
+only those who have been accepted into Outreachy can apply for QEMU Outreachy
+internships.
+
+## Select a project idea
+Look through the the [list of QEMU project
+ideas](https://wiki.qemu.org/Google_Summer_of_Code_2023) and see if there is
+something you are interested in working on. Once you have found a project idea
+you want to apply for, email the mentor for that project idea to ask any
+questions you may have and discuss the idea further.
+
+## Submit your application
+You can [apply for Google Summer of Code](https://summerofcode.withgoogle.com/)
+from March 20th to April 4th and [apply for
+Outreachy](https://www.outreachy.org/apply/) from March 6th to April 3rd.
+
+Good luck with your applications!
+
+If you have questions about applying for QEMU GSoC or Outreachy, please email
+[Stefan Hajnoczi](mailto:stefa...@gmail.com) or ask on the [#qemu-gsoc IRC
+channel](https://webchat.oftc.net/?channels=qemu-gsoc).
-- 
2.39.1

[PATCH] accel/tcg: Add 'size' param to probe_access_full

[Richard Henderson]

Change to match the recent change to probe_access_flags.
All existing callers updated to supply 0, so no change in behaviour.

Signed-off-by: Richard Henderson 
---
 include/exec/exec-all.h  | 2 +-
 accel/tcg/cputlb.c   | 4 ++--
 target/arm/mte_helper.c  | 4 ++--
 target/arm/ptw.c | 2 +-
 target/arm/sve_helper.c  | 2 +-
 target/arm/translate-a64.c   | 2 +-
 target/i386/tcg/sysemu/excp_helper.c | 4 ++--
 7 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 165b050872..b631832e17 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -475,7 +475,7 @@ int probe_access_flags(CPUArchState *env, target_ulong 
addr, int size,
  * and must be consumed or copied immediately, before any further
  * access or changes to TLB @mmu_idx.
  */
-int probe_access_full(CPUArchState *env, target_ulong addr,
+int probe_access_full(CPUArchState *env, target_ulong addr, int size,
   MMUAccessType access_type, int mmu_idx,
   bool nonfault, void **phost,
   CPUTLBEntryFull **pfull, uintptr_t retaddr);
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index fc27e34457..008ae7a66d 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1589,12 +1589,12 @@ static int probe_access_internal(CPUArchState *env, 
target_ulong addr,
 return flags;
 }
 
-int probe_access_full(CPUArchState *env, target_ulong addr,
+int probe_access_full(CPUArchState *env, target_ulong addr, int size,
   MMUAccessType access_type, int mmu_idx,
   bool nonfault, void **phost, CPUTLBEntryFull **pfull,
   uintptr_t retaddr)
 {
-int flags = probe_access_internal(env, addr, 0, access_type, mmu_idx,
+int flags = probe_access_internal(env, addr, size, access_type, mmu_idx,
   nonfault, phost, pfull, retaddr);
 
 /* Handle clean RAM pages.  */
diff --git a/target/arm/mte_helper.c b/target/arm/mte_helper.c
index 98bcf59c22..fee3c7eb96 100644
--- a/target/arm/mte_helper.c
+++ b/target/arm/mte_helper.c
@@ -118,7 +118,7 @@ static uint8_t *allocation_tag_mem(CPUARMState *env, int 
ptr_mmu_idx,
  * valid.  Indicate to probe_access_flags no-fault, then assert that
  * we received a valid page.
  */
-flags = probe_access_full(env, ptr, ptr_access, ptr_mmu_idx,
+flags = probe_access_full(env, ptr, 0, ptr_access, ptr_mmu_idx,
   ra == 0, , , ra);
 assert(!(flags & TLB_INVALID_MASK));
 
@@ -154,7 +154,7 @@ static uint8_t *allocation_tag_mem(CPUARMState *env, int 
ptr_mmu_idx,
  */
 in_page = -(ptr | TARGET_PAGE_MASK);
 if (unlikely(ptr_size > in_page)) {
-flags |= probe_access_full(env, ptr + in_page, ptr_access,
+flags |= probe_access_full(env, ptr + in_page, 0, ptr_access,
ptr_mmu_idx, ra == 0, , , ra);
 assert(!(flags & TLB_INVALID_MASK));
 }
diff --git a/target/arm/ptw.c b/target/arm/ptw.c
index 1ecefb2027..d92cdc9733 100644
--- a/target/arm/ptw.c
+++ b/target/arm/ptw.c
@@ -258,7 +258,7 @@ static bool S1_ptw_translate(CPUARMState *env, S1Translate 
*ptw,
 int flags;
 
 env->tlb_fi = fi;
-flags = probe_access_full(env, addr, MMU_DATA_LOAD,
+flags = probe_access_full(env, addr, 0, MMU_DATA_LOAD,
   arm_to_core_mmu_idx(s2_mmu_idx),
   true, >out_host, , 0);
 env->tlb_fi = NULL;
diff --git a/target/arm/sve_helper.c b/target/arm/sve_helper.c
index 51909c44ac..9a8951afa4 100644
--- a/target/arm/sve_helper.c
+++ b/target/arm/sve_helper.c
@@ -5356,7 +5356,7 @@ bool sve_probe_page(SVEHostPage *info, bool nofault, 
CPUARMState *env,
>host, retaddr);
 #else
 CPUTLBEntryFull *full;
-flags = probe_access_full(env, addr, access_type, mmu_idx, nofault,
+flags = probe_access_full(env, addr, 0, access_type, mmu_idx, nofault,
   >host, , retaddr);
 #endif
 info->flags = flags;
diff --git a/target/arm/translate-a64.c b/target/arm/translate-a64.c
index da9f877476..67e9c4ee79 100644
--- a/target/arm/translate-a64.c
+++ b/target/arm/translate-a64.c
@@ -14651,7 +14651,7 @@ static bool is_guarded_page(CPUARMState *env, 
DisasContext *s)
  * that the TLB entry must be present and valid, and thus this
  * access will never raise an exception.
  */
-flags = probe_access_full(env, addr, MMU_INST_FETCH, mmu_idx,
+flags = probe_access_full(env, addr, 0, MMU_INST_FETCH, mmu_idx,
   false, , , 0);
 assert(!(flags & TLB_INVALID_MASK));
 
diff --git a/target/i386/tcg/sysemu/excp_helper.c 
b/target/i386/tcg/sysemu/excp_helper.c
index 55bd1194d3..e87f90dbe3 100644
--- a/target/i386/tcg/sysemu/excp_helper.c
+++ 

[PATCH v3 0/2] linux-user: Fix unaligned memory access in prlimit64 syscall

[Ilya Leoshkevich]

v2: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg07017.html
v2 -> v3: Fix __put_user() argument order mixup.
  I tested v2 only against sh4, where the original problem was
  discovered, but it regresses aarch64.

v1: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg06999.html
v1 -> v2: Fix by using proper target_rlimit64 alignment (Richard).
  Use __get_user() and __put_user() (Philippe - if I understood
  the suggestion correctly).

Hi,

Richard reported [1] that the new linux-fork-trap test was failing
under UBSan [2], so it was excluded from the PR.

This is a resend of the test plus the fix for the additional issue that
it uncovered.

[1] https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg06130.html
[2] https://gitlab.com/qemu-project/qemu/-/jobs/3807471447#L5064

Best regards,
Ilya

Ilya Leoshkevich (2):
  linux-user: Fix unaligned memory access in prlimit64 syscall
  tests/tcg/linux-test: Add linux-fork-trap test

 linux-user/generic/target_resource.h|  4 +-
 linux-user/syscall.c|  8 ++--
 tests/tcg/multiarch/linux/linux-fork-trap.c | 51 +
 3 files changed, 57 insertions(+), 6 deletions(-)
 create mode 100644 tests/tcg/multiarch/linux/linux-fork-trap.c

-- 
2.39.1

[PATCH v3 1/2] linux-user: Fix unaligned memory access in prlimit64 syscall

[Ilya Leoshkevich]

target_rlimit64 contains uint64_t fields, so it's 8-byte aligned on
some hosts, while some guests may align their respective type on a
4-byte boundary. This may lead to an unaligned access, which is an UB.

Fix by defining the fields as abi_ullong. This makes the host alignment
match that of the guest, and lets the compiler know that it should emit
code that can deal with the guest alignment.

While at it, also use __get_user() and __put_user() instead of
tswap64().

Fixes: 163a05a8398b ("linux-user: Implement prlimit64 syscall")
Reported-by: Richard Henderson 
Signed-off-by: Ilya Leoshkevich 
---
 linux-user/generic/target_resource.h | 4 ++--
 linux-user/syscall.c | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/linux-user/generic/target_resource.h 
b/linux-user/generic/target_resource.h
index 539d8c46772..37d3eb09b3b 100644
--- a/linux-user/generic/target_resource.h
+++ b/linux-user/generic/target_resource.h
@@ -12,8 +12,8 @@ struct target_rlimit {
 };
 
 struct target_rlimit64 {
-uint64_t rlim_cur;
-uint64_t rlim_max;
+abi_ullong rlim_cur;
+abi_ullong rlim_max;
 };
 
 #define TARGET_RLIM_INFINITY((abi_ulong)-1)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index a6c426d73cf..73082531ffc 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -12886,8 +12886,8 @@ static abi_long do_syscall1(CPUArchState *cpu_env, int 
num, abi_long arg1,
 if (!lock_user_struct(VERIFY_READ, target_rnew, arg3, 1)) {
 return -TARGET_EFAULT;
 }
-rnew.rlim_cur = tswap64(target_rnew->rlim_cur);
-rnew.rlim_max = tswap64(target_rnew->rlim_max);
+__get_user(rnew.rlim_cur, _rnew->rlim_cur);
+__get_user(rnew.rlim_max, _rnew->rlim_max);
 unlock_user_struct(target_rnew, arg3, 0);
 rnewp = 
 }
@@ -12897,8 +12897,8 @@ static abi_long do_syscall1(CPUArchState *cpu_env, int 
num, abi_long arg1,
 if (!lock_user_struct(VERIFY_WRITE, target_rold, arg4, 1)) {
 return -TARGET_EFAULT;
 }
-target_rold->rlim_cur = tswap64(rold.rlim_cur);
-target_rold->rlim_max = tswap64(rold.rlim_max);
+__put_user(rold.rlim_cur, _rold->rlim_cur);
+__put_user(rold.rlim_max, _rold->rlim_max);
 unlock_user_struct(target_rold, arg4, 1);
 }
 return ret;
-- 
2.39.1

[PATCH v3 2/2] tests/tcg/linux-test: Add linux-fork-trap test

[Ilya Leoshkevich]

Check that dying due to a signal does not deadlock.

Reviewed-by: Richard Henderson 
Reviewed-by: Alex Bennée 
Signed-off-by: Ilya Leoshkevich 
---
 tests/tcg/multiarch/linux/linux-fork-trap.c | 51 +
 1 file changed, 51 insertions(+)
 create mode 100644 tests/tcg/multiarch/linux/linux-fork-trap.c

diff --git a/tests/tcg/multiarch/linux/linux-fork-trap.c 
b/tests/tcg/multiarch/linux/linux-fork-trap.c
new file mode 100644
index 000..2bfef800c3e
--- /dev/null
+++ b/tests/tcg/multiarch/linux/linux-fork-trap.c
@@ -0,0 +1,51 @@
+/*
+ * Test that a fork()ed process terminates after __builtin_trap().
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int main(void)
+{
+struct rlimit nodump;
+pid_t err, pid;
+int wstatus;
+
+pid = fork();
+assert(pid != -1);
+if (pid == 0) {
+/* We are about to crash on purpose; disable core dumps. */
+if (getrlimit(RLIMIT_CORE, )) {
+return EXIT_FAILURE;
+}
+nodump.rlim_cur = 0;
+if (setrlimit(RLIMIT_CORE, )) {
+return EXIT_FAILURE;
+}
+/*
+ * An alternative would be to dereference a NULL pointer, but that
+ * would be an UB in C.
+ */
+printf("about to trigger fault...\n");
+#if defined(__MICROBLAZE__)
+/*
+ * gcc emits "bri 0", which is an endless loop.
+ * Take glibc's ABORT_INSTRUCTION.
+ */
+asm volatile("brki r0,-1");
+#else
+__builtin_trap();
+#endif
+}
+err = waitpid(pid, , 0);
+assert(err == pid);
+assert(WIFSIGNALED(wstatus));
+printf("faulting thread exited cleanly\n");
+
+return EXIT_SUCCESS;
+}
-- 
2.39.1

Re: [PATCH 2/2] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and Persistent)

[Fan Ni]

On Mon, Feb 20, 2023 at 11:46:46AM +, Jonathan Cameron wrote:

> On Fri, 17 Feb 2023 06:08:57 -0500
> Gregory Price  wrote:
> 
> > On Fri, Feb 17, 2023 at 04:16:17PM +, Jonathan Cameron via wrote:
> > > On Tue, 31 Jan 2023 16:38:47 +
> > > Jonathan Cameron via  wrote:
> > >   
> > > > From: Gregory Price 
> > > > 
> > > > This commit enables each CXL Type-3 device to contain one volatile
> > > > memory region and one persistent region.
> > > > 
> > > > Two new properties have been added to cxl-type3 device initialization:
> > > > [volatile-memdev] and [persistent-memdev]
> > > > 
> > > > The existing [memdev] property has been deprecated and will default the
> > > > memory region to a persistent memory region (although a user may assign
> > > > the region to a ram or file backed region). It cannot be used in
> > > > combination with the new [persistent-memdev] property.
> > > > 
> > > > Partitioning volatile memory from persistent memory is not yet 
> > > > supported.
> > > > 
> > > > Volatile memory is mapped at DPA(0x0), while Persistent memory is mapped
> > > > at DPA(vmem->size), per CXL Spec 8.2.9.8.2.0 - Get Partition Info.
> > > > 
> > > > Signed-off-by: Gregory Price 
> > > > Signed-off-by: Jonathan Cameron 
> > > >   
> > > Hi Gregory,
> > > 
> > > I've added support for multiple HDM decoders and hence can now
> > > test both volatile and non volatile on same device.
> > > It very nearly all works. With one exception which is I couldn't
> > > poke the first byte of the non volatile region.
> > > 
> > > I think we have an off by one in a single check.
> > > 
> > > Interestingly it makes no difference when creating an FS on top
> > > (which was my standard test) so I only noticed when poking memory
> > > addresses directly to sanity check the HDM decoder setup.
> > > 
> > > I'll roll a v2 if no one shouts out that I'm wrong.
> > > 
> > > Note that adding multiple HDM decoders massively increases
> > > the number of test cases over what we had before to poke all the
> > > corners so I may well be missing stuff.  Hopefully can send an RFC
> > > of that support out next week.
> > > 
> > > Jonathan
> > >   
> > 
> > Very cool! Thanks for pushing this over the finishing line.
> > 
> > All my testing so far has been really smooth since getting the TCG issue
> > worked out.
> > 
> > > > -MemTxResult cxl_type3_read(PCIDevice *d, hwaddr host_addr, uint64_t 
> > > > *data,
> > > > -   unsigned size, MemTxAttrs attrs)  
> > [...]
> > > > +if (vmr) {
> > > > +if (*dpa_offset <= int128_get64(vmr->size)) {  
> > > 
> > > Off by one I think.  < 
> > >   
> > 
> > Yes that makes sense, should be <.  Derp derp.
> > 
> > Though I think this may alludes to more off-by-one issues?  This says
> > 
> > if (dpa_offset < vmr->size)
> > 
> > but dpa_offset should be (hpa - memory_region_base),
> > 
> > The HPA is used by memory access routing for the whole system to determine
> > what device it should access.
> > 
> > If that corner case is being hit, doesn't it imply the higher level code
> > is also susceptible to this, and is routing accesses to the wrong device?
> 
> I don't think so though I may be missing something. 
> 
> Say vmr->size = 8
> 
> hpa  dpa_offset
> 0   0
> 1   1
> 2   2
> 3   3
> 4   4
> 5   5
> 6   6
> 7   7
> 8   0
> 
> etc

If vmr->size=8, we should expect that at most 8 offsets (e.g., hpa [0,7]) will
access vmem and hpa=8 will access offset=0 at pmem, right?
If with hpa=8, dpa_offset round to 0, does it mean we never get a
dpa_offset larger than 7? If so, when pmem will be accessed?

> 
> Also the writes are turning up where I expect them to.
> 
> Also just noticed that the code is setting Memory_base in the CXL dvsec.
> Given we are emulating a device as if it has been freshly powered up
> those should not be set - it's the OS or firmware's job to set them up.
> Harmless though, so can be a cleanup to follow the main series.
> 
> We don't currently handle dvsec range based routing anyway and
> I'm not sure we ever will as it is a pain to test without some firmware
> or OS code to program them for us.
> 
> Note that if you update your kernel to cxl/next it will currently fail
> as the Range register emulation is (I think) rather over enthusiastic
> and currently decides to emulate the HDM decoders for the QEMU emulated
> type 3 devices.
> 
> https://lore.kernel.org/linux-cxl/167640366272.935665.1056268838301725481.st...@dwillia2-xfh.jf.intel.com/T/#m6c025d5c9b27d8360a64079593f6c5adaa408772
> 
> Jonathan
> 
> 
> > 
> > ~Gregory
> 
> 

Re: [PATCH v7 1/4] tcg: add 'size' param to probe_access_flags()

[Richard Henderson]

On 2/23/23 14:19, Richard Henderson wrote:

On 2/23/23 13:44, Daniel Henrique Barboza wrote:

+    if (unlikely(flags & TLB_NOTDIRTY)) {
+    notdirty_write(env_cpu(env), addr, 1, full, retaddr);


That '1' should be 'size'.  Fixed locally.


Hmph, well, that matches the interface, but it's only used to figure out how many pages to 
process, so any len that doesn't cross a page boundary (which we have checked) is equal 
bar the tracepoint.



r~

Re: [PATCH v7 1/4] tcg: add 'size' param to probe_access_flags()

[Richard Henderson]

On 2/23/23 13:44, Daniel Henrique Barboza wrote:

+if (unlikely(flags & TLB_NOTDIRTY)) {
+notdirty_write(env_cpu(env), addr, 1, full, retaddr);


That '1' should be 'size'.  Fixed locally.


r~

[PATCH] hw/display/sm501: Add alternatives to pixman routines

[BALATON Zoltan]

Pixman can sometimes return false so add fallbacks for such cases and
also add a property to disable pixman and always use the fallbacks
which can be useful on platforms where pixman is broken or for testing
different drawing methods.

Signed-off-by: BALATON Zoltan 
---
Also ping for the other sm501 patch I've sent a week ago:
https://patchew.org/QEMU/20230216144043.d6328746...@zero.eik.bme.hu/
These two patches are needed to fix graphics issues with AmigaOS so
I'd like them to be merged for 8.0

 hw/display/sm501.c | 77 +++---
 1 file changed, 52 insertions(+), 25 deletions(-)

diff --git a/hw/display/sm501.c b/hw/display/sm501.c
index 58bc9701ee..2a0a9a37f8 100644
--- a/hw/display/sm501.c
+++ b/hw/display/sm501.c
@@ -464,6 +464,7 @@ typedef struct SM501State {
 uint32_t last_width;
 uint32_t last_height;
 bool do_full_update; /* perform a full update next time */
+bool use_pixman;
 I2CBus *i2c_bus;
 
 /* mmio registers */
@@ -691,7 +692,7 @@ static void sm501_2d_operation(SM501State *s)
 unsigned int dst_pitch = (s->twoD_pitch >> 16) & 0x1FFF;
 int crt = (s->dc_crt_control & SM501_DC_CRT_CONTROL_SEL) ? 1 : 0;
 int fb_len = get_width(s, crt) * get_height(s, crt) * get_bpp(s, crt);
-bool overlap = false;
+bool overlap = false, fallback = false;
 
 if ((s->twoD_stretch >> 16) & 0xF) {
 qemu_log_mask(LOG_UNIMP, "sm501: only XY addressing is supported.\n");
@@ -826,7 +827,7 @@ static void sm501_2d_operation(SM501State *s)
 de = db + (width + (height - 1) * dst_pitch) * bypp;
 overlap = (db < se && sb < de);
 }
-if (overlap) {
+if (s->use_pixman && overlap) {
 /* pixman can't do reverse blit: copy via temporary */
 int tmp_stride = DIV_ROUND_UP(width * bypp, sizeof(uint32_t));
 uint32_t *tmp = tmp_buf;
@@ -834,25 +835,43 @@ static void sm501_2d_operation(SM501State *s)
 if (tmp_stride * sizeof(uint32_t) * height > sizeof(tmp_buf)) {
 tmp = g_malloc(tmp_stride * sizeof(uint32_t) * height);
 }
-pixman_blt((uint32_t *)>local_mem[src_base], tmp,
-   src_pitch * bypp / sizeof(uint32_t),
-   tmp_stride, 8 * bypp, 8 * bypp,
-   src_x, src_y, 0, 0, width, height);
-pixman_blt(tmp, (uint32_t *)>local_mem[dst_base],
-   tmp_stride,
-   dst_pitch * bypp / sizeof(uint32_t),
-   8 * bypp, 8 * bypp,
-   0, 0, dst_x, dst_y, width, height);
+fallback = pixman_blt((uint32_t *)>local_mem[src_base], tmp,
+  src_pitch * bypp / sizeof(uint32_t),
+  tmp_stride, 8 * bypp, 8 * bypp,
+  src_x, src_y, 0, 0, width, height);
+fallback |= pixman_blt(tmp, (uint32_t 
*)>local_mem[dst_base],
+   tmp_stride,
+   dst_pitch * bypp / sizeof(uint32_t),
+   8 * bypp, 8 * bypp, 0, 0, dst_x, dst_y,
+   width, height);
 if (tmp != tmp_buf) {
 g_free(tmp);
 }
-} else {
-pixman_blt((uint32_t *)>local_mem[src_base],
-   (uint32_t *)>local_mem[dst_base],
-   src_pitch * bypp / sizeof(uint32_t),
-   dst_pitch * bypp / sizeof(uint32_t),
-   8 * bypp, 8 * bypp,
-   src_x, src_y, dst_x, dst_y, width, height);
+} else if (s->use_pixman) {
+fallback = pixman_blt((uint32_t *)>local_mem[src_base],
+  (uint32_t *)>local_mem[dst_base],
+  src_pitch * bypp / sizeof(uint32_t),
+  dst_pitch * bypp / sizeof(uint32_t),
+  8 * bypp, 8 * bypp, src_x, src_y,
+  dst_x, dst_y, width, height);
+}
+if (!s->use_pixman || fallback) {
+uint8_t *sp = s->local_mem + src_base;
+uint8_t *d = s->local_mem + dst_base;
+unsigned int y, i, j;
+for (y = 0; y < height; y++) {
+if (overlap) { /* overlap also means rtl */
+i = (dst_y + height - 1 - y) * dst_pitch;
+i = (dst_x + i) * bypp;
+j = (src_y + height - 1 - y) * src_pitch;
+j = (src_x + j) * bypp;
+memmove([i], [j], width * bypp);
+} else {
+  

Re: [PATCH v7 1/4] tcg: add 'size' param to probe_access_flags()

[Richard Henderson]

On 2/23/23 13:44, Daniel Henrique Barboza wrote:

probe_access_flags() as it is today uses probe_access_full(), which in
turn uses probe_access_internal() with size = 0. probe_access_internal()
then uses the size to call the tlb_fill() callback for the given CPU.
This size param ('fault_size' as probe_access_internal() calls it) is
ignored by most existing .tlb_fill callback implementations, e.g.
arm_cpu_tlb_fill(), ppc_cpu_tlb_fill(), x86_cpu_tlb_fill() and
mips_cpu_tlb_fill() to name a few.

But RISC-V riscv_cpu_tlb_fill() actually uses it. The 'size' parameter
is used to check for PMP (Physical Memory Protection) access. This is
necessary because PMP does not make any guarantees about all the bytes
of the same page having the same permissions, i.e. the same page can
have different PMP properties, so we're forced to make sub-page range
checks. To allow RISC-V emulation to do a probe_acess_flags() that
covers PMP, we need to either add a 'size' param to the existing
probe_acess_flags() or create a new interface (e.g.
probe_access_range_flags).

There are quite a few probe_* APIs already, so let's add a 'size' param
to probe_access_flags() and re-use this API. This is done by open coding
what probe_access_full() does inside probe_acess_flags() and passing the
'size' param to probe_acess_internal(). Existing probe_access_flags()
callers use size = 0 to not change their current API usage. 'size' is
asserted to enforce single page access like probe_access() already does.

No behavioral changes intended.

Signed-off-by: Daniel Henrique Barboza
---
  accel/stubs/tcg-stub.c|  2 +-
  accel/tcg/cputlb.c| 17 ++---
  accel/tcg/user-exec.c |  5 +++--
  include/exec/exec-all.h   |  3 ++-
  semihosting/uaccess.c |  2 +-
  target/arm/ptw.c  |  2 +-
  target/arm/sve_helper.c   |  2 +-
  target/s390x/tcg/mem_helper.c |  6 +++---
  8 files changed, 26 insertions(+), 13 deletions(-)


Queueing to tcg-next.

r~

Re: [PATCH v7 3/4] target/riscv: implement Zicbom extension

[Richard Henderson]

On 2/23/23 13:44, Daniel Henrique Barboza wrote:

From: Christoph Muellner

Zicbom is the Cache-Block Management extension defined in the already
ratified RISC-V Base Cache Management Operation (CBO) ISA extension [1].

The extension contains three instructions: cbo.clean, cbo.flush and
cbo.inval. All of them must be implemented in the same group as LQ and
cbo.zero due to overlapping patterns.

All these instructions can throw a Illegal Instruction/Virtual
Instruction exception, similar to the existing cbo.zero. The same
check_zicbo_envcfg() is used to handle these exceptions.

Aside from that, these instructions also need to handle page faults and
guest page faults. This is done in a new check_zicbom_access() helper.

As with Zicboz, the cache block size for Zicbom is also configurable.
Note that the spec determines that Zicbo[mp] and Zicboz can have
different cache sizes (Section 2.7 of [1]), so we also include a
'cbom_blocksize' to go along with the existing 'cboz_blocksize'. They
are set to the same size, so unless users want to play around with the
settings both sizes will be the same.

[1]https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.1.pdf

Co-developed-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
Signed-off-by: Daniel Henrique Barboza
---
  target/riscv/cpu.c  |  3 +
  target/riscv/cpu.h  |  2 +
  target/riscv/helper.h   |  2 +
  target/riscv/insn32.decode  |  5 ++
  target/riscv/insn_trans/trans_rvzicbo.c.inc | 27 +
  target/riscv/op_helper.c| 67 +
  6 files changed, 106 insertions(+)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH v7 2/4] target/riscv: implement Zicboz extension

[Richard Henderson]

On 2/23/23 13:44, Daniel Henrique Barboza wrote:

From: Christoph Muellner

The RISC-V base cache management operation (CBO) ISA extension has been
ratified. It defines three extensions: Cache-Block Management, Cache-Block
Prefetch and Cache-Block Zero. More information about the spec can be
found at [1].

Let's start by implementing the Cache-Block Zero extension, Zicboz. It
uses the cbo.zero instruction that, as with all CBO instructions that
will be added later, needs to be implemented in an overlap group with
the LQ instruction due to overlapping patterns.

cbo.zero throws a Illegal Instruction/Virtual Instruction exception
depending on CSR state. This is also the case for the remaining cbo
instructions we're going to add next, so create a check_zicbo_envcfg()
that will be used by all Zicbo[mz] instructions.

[1]https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.1.pdf

Co-developed-by: Philipp Tomsich
Signed-off-by: Christoph Muellner
Signed-off-by: Daniel Henrique Barboza
---
  target/riscv/cpu.c  |  4 ++
  target/riscv/cpu.h  |  2 +
  target/riscv/helper.h   |  3 +
  target/riscv/insn32.decode  | 10 +++-
  target/riscv/insn_trans/trans_rvzicbo.c.inc | 30 ++
  target/riscv/op_helper.c| 65 +
  target/riscv/translate.c|  1 +
  7 files changed, 114 insertions(+), 1 deletion(-)
  create mode 100644 target/riscv/insn_trans/trans_rvzicbo.c.inc


Reviewed-by: Richard Henderson 

r~

Re: [PATCH v7 1/4] tcg: add 'size' param to probe_access_flags()

[Richard Henderson]

On 2/23/23 13:44, Daniel Henrique Barboza wrote:

probe_access_flags() as it is today uses probe_access_full(), which in
turn uses probe_access_internal() with size = 0. probe_access_internal()
then uses the size to call the tlb_fill() callback for the given CPU.
This size param ('fault_size' as probe_access_internal() calls it) is
ignored by most existing .tlb_fill callback implementations, e.g.
arm_cpu_tlb_fill(), ppc_cpu_tlb_fill(), x86_cpu_tlb_fill() and
mips_cpu_tlb_fill() to name a few.

But RISC-V riscv_cpu_tlb_fill() actually uses it. The 'size' parameter
is used to check for PMP (Physical Memory Protection) access. This is
necessary because PMP does not make any guarantees about all the bytes
of the same page having the same permissions, i.e. the same page can
have different PMP properties, so we're forced to make sub-page range
checks. To allow RISC-V emulation to do a probe_acess_flags() that
covers PMP, we need to either add a 'size' param to the existing
probe_acess_flags() or create a new interface (e.g.
probe_access_range_flags).

There are quite a few probe_* APIs already, so let's add a 'size' param
to probe_access_flags() and re-use this API. This is done by open coding
what probe_access_full() does inside probe_acess_flags() and passing the
'size' param to probe_acess_internal(). Existing probe_access_flags()
callers use size = 0 to not change their current API usage. 'size' is
asserted to enforce single page access like probe_access() already does.

No behavioral changes intended.

Signed-off-by: Daniel Henrique Barboza 
---
  accel/stubs/tcg-stub.c|  2 +-
  accel/tcg/cputlb.c| 17 ++---
  accel/tcg/user-exec.c |  5 +++--
  include/exec/exec-all.h   |  3 ++-
  semihosting/uaccess.c |  2 +-
  target/arm/ptw.c  |  2 +-
  target/arm/sve_helper.c   |  2 +-
  target/s390x/tcg/mem_helper.c |  6 +++---
  8 files changed, 26 insertions(+), 13 deletions(-)


Reviewed-by: Richard Henderson 

I'll change probe_access_full as well, just to keep them in sync.


+int probe_access_flags(CPUArchState *env, target_ulong addr, int size,
 MMUAccessType access_type, int mmu_idx,
 bool nonfault, void **phost, uintptr_t retaddr)
  {
  CPUTLBEntryFull *full;
+int flags;
+
+g_assert(-(addr | TARGET_PAGE_MASK) >= size);
+
+flags = probe_access_internal(env, addr, size, access_type, mmu_idx,
+  nonfault, phost, , retaddr);
  
-return probe_access_full(env, addr, access_type, mmu_idx,

- nonfault, phost, , retaddr);
+/* Handle clean RAM pages. */
+if (unlikely(flags & TLB_NOTDIRTY)) {
+notdirty_write(env_cpu(env), addr, 1, full, retaddr);
+flags &= ~TLB_NOTDIRTY;
+}
+
+return flags;


But bypassing probe_access_full here is fine.


r~

Re: [PATCH 2/5] hw/isa/vt82c686: Implement PCI IRQ routing

[BALATON Zoltan]

On Fri, 24 Feb 2023, BALATON Zoltan wrote:

On Thu, 23 Feb 2023, Bernhard Beschow wrote:
Am 23. Februar 2023 21:11:23 UTC schrieb BALATON Zoltan 
:

On Thu, 23 Feb 2023, Bernhard Beschow wrote:

The real VIA south bridges implement a PCI IRQ router which is configured
by the BIOS or the OS. In order to respect these configurations, QEMU
needs to implement it as well.

Note: The implementation was taken from piix4_set_irq() in hw/isa/piix4.

Signed-off-by: Bernhard Beschow 
---
hw/isa/vt82c686.c | 44 
1 file changed, 44 insertions(+)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 3f9bd0c04d..f24e387d63 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -604,6 +604,48 @@ static void via_isa_request_i8259_irq(void *opaque, 
int irq, int level)

qemu_set_irq(s->cpu_intr, level);
}

+static int via_isa_get_pci_irq(const ViaISAState *s, int irq_num)
+{
+switch (irq_num) {
+case 0:
+return s->dev.config[0x55] >> 4;
+
+case 1:
+return s->dev.config[0x56] & 0xf;
+
+case 2:
+return s->dev.config[0x56] >> 4;
+
+case 3:
+return s->dev.config[0x57] >> 4;
+}
+
+return 0;
+}
+
+static void via_isa_set_pci_irq(void *opaque, int irq_num, int level)
+{
+ViaISAState *s = opaque;
+PCIBus *bus = pci_get_bus(>dev);
+int pic_irq;
+
+/* now we change the pic irq level according to the via irq mappings 
*/

+/* XXX: optimize */
+pic_irq = via_isa_get_pci_irq(s, irq_num);
+if (pic_irq < ISA_NUM_IRQS) {
+int i, pic_level;
+
+/* The pic level is the logical OR of all the PCI irqs mapped to 
it. */

+pic_level = 0;
+for (i = 0; i < PCI_NUM_PINS; i++) {
+if (pic_irq == via_isa_get_pci_irq(s, i)) {
+pic_level |= pci_bus_get_irq_level(bus, i);
+}
+}
+qemu_set_irq(s->isa_irqs[pic_irq], pic_level);
+}
+}
+
static void via_isa_realize(PCIDevice *d, Error **errp)
{
ViaISAState *s = VIA_ISA(d);
@@ -676,6 +718,8 @@ static void via_isa_realize(PCIDevice *d, Error 
**errp)

if (!qdev_realize(DEVICE(>mc97), BUS(pci_bus), errp)) {
return;
}
+
+pci_bus_irqs(pci_bus, via_isa_set_pci_irq, s, PCI_NUM_PINS);


Please no oversimplification. This replaces the connections to mv64361 gpp 
pins made in mv64361_realize() and breaks the interrupts that can be 
enabled in mv64361.


Let's split our work as follows: You'll do the audio and pegasos2 changes 
including exporting the pirq properties, I'll do the first three routing 
patches of this series as the base.


I'm OK with doing audio as said and already did the PIRQ and pegaosos2 
changes (patch 2 and 3 in my series), just take those without deleting half 
of them. So drop the last two via-ac97 patches and do the IRQ fixes in your 
way but keep working what now works.


I've implemented that for something but can't remember now which guest 
exactly,


Could you please put this information into the commit message or into the 
code? That would ease maintainance a lot.


I did, see patch 3 in my series.

but this would be needed so please restore my pegasos2 patch and move this 
there connecting both mv64361 and via-isa to PCI interrupts as shown in 
the schematics. That means you also need the PIRQ pins here. Can you do a 
new version with that?


As proposed above I'd fold the first three patches into a separate series 
which you can build upon. I have no way to test the pegasos2 IRQ changes 
since the test cases I'm aware of either work or we agreed that they can be 
fixed later (-> USB).


I did fix the USB just haven't sent a v2 yet due to this thread but it's just 
the change I've sent yesterday, just add this before qemu_set_irq at the end 
of via_isa_set_irq() in my series. This is what I have now:


+uint16_t old_state;
+if (old_state && s->isa_irq_state[isa_irq]) {
+/* FIXME: i8259 model does not support level sensitive mode */
+qemu_set_irq(s->isa_irqs[isa_irq], 0);
+}


Actually that should be:

+old_state = s->isa_irq_state[isa_irq];
+if (level) {
+s->isa_irq_state[isa_irq] |= BIT(n);
+} else {
+s->isa_irq_state[isa_irq] &= ~BIT(n);
+}
+if (old_state && s->isa_irq_state[isa_irq]) {
+/* FIXME: i8259 model does not support level sensitive mode */
+qemu_set_irq(s->isa_irqs[isa_irq], 0);
+}
+qemu_set_irq(s->isa_irqs[isa_irq], !!s->isa_irq_state[isa_irq]);

with the old_state variable definition at the top of the func of course.

How to do that with your version I have no idea but this fixed the problem 
with my series. I can send a v2 of this patch with this change if it's not 
clear from this and the other message what I did.



I'll try this one in the meantime


Sounds good to me -- that's what I wanted to achieve ;) Thanks!


I've answered about that in the other message, I've tried with AmigaOS, 
Debian Linux 8.11.0 netboot iso and MorphOS 

Re: [PATCH v4 7/7] dump: Rename x86-specific file as win_dump_x86.c

[Richard Henderson]

On 2/23/23 13:17, Philippe Mathieu-Daudé wrote:

win_dump.c is x86 specific. Rename it as such in case
someone is willing to add win_dump-aarch64 :)


I think this is premature.  I would *hope* there's a lot in here that would be 
shared.


r~

Re: [PATCH v4 6/7] dump: Build once by adding stubs for non-x86 targets

[Richard Henderson]

On 2/23/23 13:17, Philippe Mathieu-Daudé wrote:

Extract non-x86 stubs to win_dump-stub.c. We can now
build dump.o once for system emulation. Update meson.

Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/dump.c  | 14 --
  dump/meson.build |  6 --
  dump/win_dump-stub.c | 23 +++
  3 files changed, 27 insertions(+), 16 deletions(-)
  create mode 100644 dump/win_dump-stub.c

diff --git a/dump/dump.c b/dump/dump.c
index b33a613d45..7cde3e326e 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -32,20 +32,6 @@
  #include "migration/blocker.h"
  #include "win_dump.h"
  
-#ifndef TARGET_X86_64

-bool win_dump_available(Error **errp)
-{
-error_setg(errp, "Windows dump is only available for x86-64");
-
-return false;
-}
-
-void create_win_dump(DumpState *s, Error **errp)
-{
-win_dump_available(errp);
-}
-#endif
-
  #include 
  #ifdef CONFIG_LZO
  #include 
diff --git a/dump/meson.build b/dump/meson.build
index 2eff29c3ea..6ae07e6fed 100644
--- a/dump/meson.build
+++ b/dump/meson.build
@@ -1,4 +1,6 @@
  softmmu_ss.add(files('dump-hmp-cmds.c'))
  
-specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, lzo])

-specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'], if_true: 
files('win_dump.c'))
+softmmu_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, lzo])
+specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'],
+if_true: files('win_dump.c'),
+if_false: files('win_dump-stub.c'))


Doesn't this add win_dump-stub.c when !(SOFTMMU && X86_64), i.e. !SOFTMMU || 
!X86_64?

I trying to imagine how well this will scale with ARM64, for the ongoing Windows on ARM 
project.  Would it just be easier have the stubs in win_dump.c, using ifdefs?



r~

Re: [PATCH 2/5] hw/isa/vt82c686: Implement PCI IRQ routing

[BALATON Zoltan]

On Thu, 23 Feb 2023, Bernhard Beschow wrote:

Am 23. Februar 2023 21:11:23 UTC schrieb BALATON Zoltan :

On Thu, 23 Feb 2023, Bernhard Beschow wrote:

The real VIA south bridges implement a PCI IRQ router which is configured
by the BIOS or the OS. In order to respect these configurations, QEMU
needs to implement it as well.

Note: The implementation was taken from piix4_set_irq() in hw/isa/piix4.

Signed-off-by: Bernhard Beschow 
---
hw/isa/vt82c686.c | 44 
1 file changed, 44 insertions(+)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 3f9bd0c04d..f24e387d63 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -604,6 +604,48 @@ static void via_isa_request_i8259_irq(void *opaque, int 
irq, int level)
qemu_set_irq(s->cpu_intr, level);
}

+static int via_isa_get_pci_irq(const ViaISAState *s, int irq_num)
+{
+switch (irq_num) {
+case 0:
+return s->dev.config[0x55] >> 4;
+
+case 1:
+return s->dev.config[0x56] & 0xf;
+
+case 2:
+return s->dev.config[0x56] >> 4;
+
+case 3:
+return s->dev.config[0x57] >> 4;
+}
+
+return 0;
+}
+
+static void via_isa_set_pci_irq(void *opaque, int irq_num, int level)
+{
+ViaISAState *s = opaque;
+PCIBus *bus = pci_get_bus(>dev);
+int pic_irq;
+
+/* now we change the pic irq level according to the via irq mappings */
+/* XXX: optimize */
+pic_irq = via_isa_get_pci_irq(s, irq_num);
+if (pic_irq < ISA_NUM_IRQS) {
+int i, pic_level;
+
+/* The pic level is the logical OR of all the PCI irqs mapped to it. */
+pic_level = 0;
+for (i = 0; i < PCI_NUM_PINS; i++) {
+if (pic_irq == via_isa_get_pci_irq(s, i)) {
+pic_level |= pci_bus_get_irq_level(bus, i);
+}
+}
+qemu_set_irq(s->isa_irqs[pic_irq], pic_level);
+}
+}
+
static void via_isa_realize(PCIDevice *d, Error **errp)
{
ViaISAState *s = VIA_ISA(d);
@@ -676,6 +718,8 @@ static void via_isa_realize(PCIDevice *d, Error **errp)
if (!qdev_realize(DEVICE(>mc97), BUS(pci_bus), errp)) {
return;
}
+
+pci_bus_irqs(pci_bus, via_isa_set_pci_irq, s, PCI_NUM_PINS);


Please no oversimplification. This replaces the connections to mv64361 gpp pins 
made in mv64361_realize() and breaks the interrupts that can be enabled in 
mv64361.


Let's split our work as follows: You'll do the audio and pegasos2 
changes including exporting the pirq properties, I'll do the first three 
routing patches of this series as the base.


I'm OK with doing audio as said and already did the PIRQ and pegaosos2 
changes (patch 2 and 3 in my series), just take those without deleting 
half of them. So drop the last two via-ac97 patches and do the IRQ fixes 
in your way but keep working what now works.



I've implemented that for something but can't remember now which guest exactly,


Could you please put this information into the commit message or into 
the code? That would ease maintainance a lot.


I did, see patch 3 in my series.

but this would be needed so please restore my pegasos2 patch and move 
this there connecting both mv64361 and via-isa to PCI interrupts as 
shown in the schematics. That means you also need the PIRQ pins here. 
Can you do a new version with that?


As proposed above I'd fold the first three patches into a separate 
series which you can build upon. I have no way to test the pegasos2 IRQ 
changes since the test cases I'm aware of either work or we agreed that 
they can be fixed later (-> USB).


I did fix the USB just haven't sent a v2 yet due to this thread but it's 
just the change I've sent yesterday, just add this before qemu_set_irq at 
the end of via_isa_set_irq() in my series. This is what I have now:


+uint16_t old_state;
+if (old_state && s->isa_irq_state[isa_irq]) {
+/* FIXME: i8259 model does not support level sensitive mode */
+qemu_set_irq(s->isa_irqs[isa_irq], 0);
+}

How to do that with your version I have no idea but this fixed the problem 
with my series. I can send a v2 of this patch with this change if it's not 
clear from this and the other message what I did.



I'll try this one in the meantime


Sounds good to me -- that's what I wanted to achieve ;) Thanks!


I've answered about that in the other message, I've tried with AmigaOS, 
Debian Linux 8.11.0 netboot iso and MorphOS and they still boot but 
couldn't test them much yet. MorphOS works on my series with sound and USB 
and does not hang with the above workaround but found now it still hangs 
if I send something to it over serial (e.g. press space or enter where 
you've typed boot cd boot.img after it starts playing sound). This happens 
on both of our series but only with the via-ac97 patch so probably related 
to that. This could easily be a guest bug too so I don't care that much, 
the pegasos2 changes are more interesting to get AmigaOS run well so 
that's my main focus now, MorphOS 

[PATCH v7 3/4] target/riscv: implement Zicbom extension

[Daniel Henrique Barboza]

From: Christoph Muellner 

Zicbom is the Cache-Block Management extension defined in the already
ratified RISC-V Base Cache Management Operation (CBO) ISA extension [1].

The extension contains three instructions: cbo.clean, cbo.flush and
cbo.inval. All of them must be implemented in the same group as LQ and
cbo.zero due to overlapping patterns.

All these instructions can throw a Illegal Instruction/Virtual
Instruction exception, similar to the existing cbo.zero. The same
check_zicbo_envcfg() is used to handle these exceptions.

Aside from that, these instructions also need to handle page faults and
guest page faults. This is done in a new check_zicbom_access() helper.

As with Zicboz, the cache block size for Zicbom is also configurable.
Note that the spec determines that Zicbo[mp] and Zicboz can have
different cache sizes (Section 2.7 of [1]), so we also include a
'cbom_blocksize' to go along with the existing 'cboz_blocksize'. They
are set to the same size, so unless users want to play around with the
settings both sizes will be the same.

[1] 
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.1.pdf

Co-developed-by: Philipp Tomsich 
Signed-off-by: Christoph Muellner 
Signed-off-by: Daniel Henrique Barboza 
---
 target/riscv/cpu.c  |  3 +
 target/riscv/cpu.h  |  2 +
 target/riscv/helper.h   |  2 +
 target/riscv/insn32.decode  |  5 ++
 target/riscv/insn_trans/trans_rvzicbo.c.inc | 27 +
 target/riscv/op_helper.c| 67 +
 6 files changed, 106 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 7dd37de7f9..4b779b1775 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -74,6 +74,7 @@ struct isa_ext_data {
 static const struct isa_ext_data isa_edata_arr[] = {
 ISA_EXT_DATA_ENTRY(h, false, PRIV_VERSION_1_12_0, ext_h),
 ISA_EXT_DATA_ENTRY(v, false, PRIV_VERSION_1_10_0, ext_v),
+ISA_EXT_DATA_ENTRY(zicbom, true, PRIV_VERSION_1_12_0, ext_icbom),
 ISA_EXT_DATA_ENTRY(zicboz, true, PRIV_VERSION_1_12_0, ext_icboz),
 ISA_EXT_DATA_ENTRY(zicsr, true, PRIV_VERSION_1_10_0, ext_icsr),
 ISA_EXT_DATA_ENTRY(zifencei, true, PRIV_VERSION_1_10_0, ext_ifencei),
@@ -1127,6 +1128,8 @@ static Property riscv_cpu_extensions[] = {
 DEFINE_PROP_BOOL("zhinx", RISCVCPU, cfg.ext_zhinx, false),
 DEFINE_PROP_BOOL("zhinxmin", RISCVCPU, cfg.ext_zhinxmin, false),
 
+DEFINE_PROP_BOOL("zicbom", RISCVCPU, cfg.ext_icbom, true),
+DEFINE_PROP_UINT16("cbom_blocksize", RISCVCPU, cfg.cbom_blocksize, 64),
 DEFINE_PROP_BOOL("zicboz", RISCVCPU, cfg.ext_icboz, true),
 DEFINE_PROP_UINT16("cboz_blocksize", RISCVCPU, cfg.cboz_blocksize, 64),
 
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 6b4c714d3a..a0673b4604 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -447,6 +447,7 @@ struct RISCVCPUConfig {
 bool ext_zkt;
 bool ext_ifencei;
 bool ext_icsr;
+bool ext_icbom;
 bool ext_icboz;
 bool ext_zihintpause;
 bool ext_smstateen;
@@ -495,6 +496,7 @@ struct RISCVCPUConfig {
 char *vext_spec;
 uint16_t vlen;
 uint16_t elen;
+uint16_t cbom_blocksize;
 uint16_t cboz_blocksize;
 bool mmu;
 bool pmp;
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index ce165821b8..37b54e0991 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -98,6 +98,8 @@ DEF_HELPER_FLAGS_2(fcvt_h_lu, TCG_CALL_NO_RWG, i64, env, tl)
 DEF_HELPER_FLAGS_2(fclass_h, TCG_CALL_NO_RWG_SE, tl, env, i64)
 
 /* Cache-block operations */
+DEF_HELPER_2(cbo_clean_flush, void, env, tl)
+DEF_HELPER_2(cbo_inval, void, env, tl)
 DEF_HELPER_2(cbo_zero, void, env, tl)
 
 /* Special functions */
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 3985bc703f..3788f86528 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -181,6 +181,11 @@ sraw 010 .  . 101 . 0111011 @r
 ldu     . 111 . 011 @i
 {
   [
+# *** RV32 Zicbom Standard Extension ***
+cbo_clean  000 1 . 010 0 000 @sfence_vm
+cbo_flush  000 00010 . 010 0 000 @sfence_vm
+cbo_inval  000 0 . 010 0 000 @sfence_vm
+
 # *** RV32 Zicboz Standard Extension ***
 cbo_zero   000 00100 . 010 0 000 @sfence_vm
   ]
diff --git a/target/riscv/insn_trans/trans_rvzicbo.c.inc 
b/target/riscv/insn_trans/trans_rvzicbo.c.inc
index feabc28342..7df9c30b58 100644
--- a/target/riscv/insn_trans/trans_rvzicbo.c.inc
+++ b/target/riscv/insn_trans/trans_rvzicbo.c.inc
@@ -16,12 +16,39 @@
  * this program.  If not, see .
  */
 
+#define REQUIRE_ZICBOM(ctx) do {\
+if (!ctx->cfg_ptr->ext_icbom) { \
+return false;   \
+}   \
+} while (0)
+
 #define REQUIRE_ZICBOZ(ctx) do {\
 if 

[PATCH v7 0/4] riscv: Add support for Zicbo[m,z,p] instructions

[Daniel Henrique Barboza]

Hi,

This new version has changes based on feedbacks of both v5 and v6.

Patch 1 was revamped. We're modifying probe_access_flags() to accept a
'size' parameter to allow for RISC-V usage with PMP. Changes in the existing
callers are trivial and no behavior change is done (well, at least it's not
intended). And we avoid adding another  probe_* API that only RISC-V
will care about. 

Changes from v6:
- patch 1:
  - no longer adding a new probe_access_flags_range() API
  - add a 'size' param to probe_access_flags()
- patch 2:
  - check for RISCV_EXCP_ILLEGAL_INST first in check_zicbo_envcfg()
  - add a probe for MMU_DATA_STORE after check_zicbo_envcfg()
  - write zeros even if the address isn't mapped to RAM
- patch 3:
  - simplify the verifications in check_zicbom_access() by using probe_write()
- v6 link: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg05379.html 
 
Christoph Muellner (3):
  target/riscv: implement Zicboz extension
  target/riscv: implement Zicbom extension
  target/riscv: add Zicbop cbo.prefetch{i,r,m} placeholder

Daniel Henrique Barboza (1):
  tcg: add 'size' param to probe_access_flags()

 accel/stubs/tcg-stub.c  |   2 +-
 accel/tcg/cputlb.c  |  17 ++-
 accel/tcg/user-exec.c   |   5 +-
 include/exec/exec-all.h |   3 +-
 semihosting/uaccess.c   |   2 +-
 target/arm/ptw.c|   2 +-
 target/arm/sve_helper.c |   2 +-
 target/riscv/cpu.c  |   7 ++
 target/riscv/cpu.h  |   4 +
 target/riscv/helper.h   |   5 +
 target/riscv/insn32.decode  |  16 ++-
 target/riscv/insn_trans/trans_rvzicbo.c.inc |  57 +
 target/riscv/op_helper.c| 132 
 target/riscv/translate.c|   1 +
 target/s390x/tcg/mem_helper.c   |   6 +-
 15 files changed, 247 insertions(+), 14 deletions(-)
 create mode 100644 target/riscv/insn_trans/trans_rvzicbo.c.inc

-- 
2.39.2

[PATCH v7 1/4] tcg: add 'size' param to probe_access_flags()

[Daniel Henrique Barboza]

probe_access_flags() as it is today uses probe_access_full(), which in
turn uses probe_access_internal() with size = 0. probe_access_internal()
then uses the size to call the tlb_fill() callback for the given CPU.
This size param ('fault_size' as probe_access_internal() calls it) is
ignored by most existing .tlb_fill callback implementations, e.g.
arm_cpu_tlb_fill(), ppc_cpu_tlb_fill(), x86_cpu_tlb_fill() and
mips_cpu_tlb_fill() to name a few.

But RISC-V riscv_cpu_tlb_fill() actually uses it. The 'size' parameter
is used to check for PMP (Physical Memory Protection) access. This is
necessary because PMP does not make any guarantees about all the bytes
of the same page having the same permissions, i.e. the same page can
have different PMP properties, so we're forced to make sub-page range
checks. To allow RISC-V emulation to do a probe_acess_flags() that
covers PMP, we need to either add a 'size' param to the existing
probe_acess_flags() or create a new interface (e.g.
probe_access_range_flags).

There are quite a few probe_* APIs already, so let's add a 'size' param
to probe_access_flags() and re-use this API. This is done by open coding
what probe_access_full() does inside probe_acess_flags() and passing the
'size' param to probe_acess_internal(). Existing probe_access_flags()
callers use size = 0 to not change their current API usage. 'size' is
asserted to enforce single page access like probe_access() already does.

No behavioral changes intended.

Signed-off-by: Daniel Henrique Barboza 
---
 accel/stubs/tcg-stub.c|  2 +-
 accel/tcg/cputlb.c| 17 ++---
 accel/tcg/user-exec.c |  5 +++--
 include/exec/exec-all.h   |  3 ++-
 semihosting/uaccess.c |  2 +-
 target/arm/ptw.c  |  2 +-
 target/arm/sve_helper.c   |  2 +-
 target/s390x/tcg/mem_helper.c |  6 +++---
 8 files changed, 26 insertions(+), 13 deletions(-)

diff --git a/accel/stubs/tcg-stub.c b/accel/stubs/tcg-stub.c
index c1b05767c0..96af23dc5d 100644
--- a/accel/stubs/tcg-stub.c
+++ b/accel/stubs/tcg-stub.c
@@ -25,7 +25,7 @@ void tcg_flush_jmp_cache(CPUState *cpu)
 {
 }
 
-int probe_access_flags(CPUArchState *env, target_ulong addr,
+int probe_access_flags(CPUArchState *env, target_ulong addr, int size,
MMUAccessType access_type, int mmu_idx,
bool nonfault, void **phost, uintptr_t retaddr)
 {
diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 4812d83961..fc27e34457 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -1606,14 +1606,25 @@ int probe_access_full(CPUArchState *env, target_ulong 
addr,
 return flags;
 }
 
-int probe_access_flags(CPUArchState *env, target_ulong addr,
+int probe_access_flags(CPUArchState *env, target_ulong addr, int size,
MMUAccessType access_type, int mmu_idx,
bool nonfault, void **phost, uintptr_t retaddr)
 {
 CPUTLBEntryFull *full;
+int flags;
+
+g_assert(-(addr | TARGET_PAGE_MASK) >= size);
+
+flags = probe_access_internal(env, addr, size, access_type, mmu_idx,
+  nonfault, phost, , retaddr);
 
-return probe_access_full(env, addr, access_type, mmu_idx,
- nonfault, phost, , retaddr);
+/* Handle clean RAM pages. */
+if (unlikely(flags & TLB_NOTDIRTY)) {
+notdirty_write(env_cpu(env), addr, 1, full, retaddr);
+flags &= ~TLB_NOTDIRTY;
+}
+
+return flags;
 }
 
 void *probe_access(CPUArchState *env, target_ulong addr, int size,
diff --git a/accel/tcg/user-exec.c b/accel/tcg/user-exec.c
index ae67d84638..7b37fd229e 100644
--- a/accel/tcg/user-exec.c
+++ b/accel/tcg/user-exec.c
@@ -761,13 +761,14 @@ static int probe_access_internal(CPUArchState *env, 
target_ulong addr,
 cpu_loop_exit_sigsegv(env_cpu(env), addr, access_type, maperr, ra);
 }
 
-int probe_access_flags(CPUArchState *env, target_ulong addr,
+int probe_access_flags(CPUArchState *env, target_ulong addr, int size,
MMUAccessType access_type, int mmu_idx,
bool nonfault, void **phost, uintptr_t ra)
 {
 int flags;
 
-flags = probe_access_internal(env, addr, 0, access_type, nonfault, ra);
+g_assert(-(addr | TARGET_PAGE_MASK) >= size);
+flags = probe_access_internal(env, addr, size, access_type, nonfault, ra);
 *phost = flags ? NULL : g2h(env_cpu(env), addr);
 return flags;
 }
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 54585a9954..b0d4916573 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -446,6 +446,7 @@ static inline void *probe_read(CPUArchState *env, 
target_ulong addr, int size,
  * probe_access_flags:
  * @env: CPUArchState
  * @addr: guest virtual address to look up
+ * @size: size of the access
  * @access_type: read, write or execute permission
  * @mmu_idx: MMU index to use for lookup
  * @nonfault: suppress the fault
@@ -460,7 +461,7 @@ static inline 

[PATCH v7 2/4] target/riscv: implement Zicboz extension

[Daniel Henrique Barboza]

From: Christoph Muellner 

The RISC-V base cache management operation (CBO) ISA extension has been
ratified. It defines three extensions: Cache-Block Management, Cache-Block
Prefetch and Cache-Block Zero. More information about the spec can be
found at [1].

Let's start by implementing the Cache-Block Zero extension, Zicboz. It
uses the cbo.zero instruction that, as with all CBO instructions that
will be added later, needs to be implemented in an overlap group with
the LQ instruction due to overlapping patterns.

cbo.zero throws a Illegal Instruction/Virtual Instruction exception
depending on CSR state. This is also the case for the remaining cbo
instructions we're going to add next, so create a check_zicbo_envcfg()
that will be used by all Zicbo[mz] instructions.

[1] 
https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v1.0.1.pdf

Co-developed-by: Philipp Tomsich 
Signed-off-by: Christoph Muellner 
Signed-off-by: Daniel Henrique Barboza 
---
 target/riscv/cpu.c  |  4 ++
 target/riscv/cpu.h  |  2 +
 target/riscv/helper.h   |  3 +
 target/riscv/insn32.decode  | 10 +++-
 target/riscv/insn_trans/trans_rvzicbo.c.inc | 30 ++
 target/riscv/op_helper.c| 65 +
 target/riscv/translate.c|  1 +
 7 files changed, 114 insertions(+), 1 deletion(-)
 create mode 100644 target/riscv/insn_trans/trans_rvzicbo.c.inc

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 93b52b826c..7dd37de7f9 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -74,6 +74,7 @@ struct isa_ext_data {
 static const struct isa_ext_data isa_edata_arr[] = {
 ISA_EXT_DATA_ENTRY(h, false, PRIV_VERSION_1_12_0, ext_h),
 ISA_EXT_DATA_ENTRY(v, false, PRIV_VERSION_1_10_0, ext_v),
+ISA_EXT_DATA_ENTRY(zicboz, true, PRIV_VERSION_1_12_0, ext_icboz),
 ISA_EXT_DATA_ENTRY(zicsr, true, PRIV_VERSION_1_10_0, ext_icsr),
 ISA_EXT_DATA_ENTRY(zifencei, true, PRIV_VERSION_1_10_0, ext_ifencei),
 ISA_EXT_DATA_ENTRY(zihintpause, true, PRIV_VERSION_1_10_0, 
ext_zihintpause),
@@ -1126,6 +1127,9 @@ static Property riscv_cpu_extensions[] = {
 DEFINE_PROP_BOOL("zhinx", RISCVCPU, cfg.ext_zhinx, false),
 DEFINE_PROP_BOOL("zhinxmin", RISCVCPU, cfg.ext_zhinxmin, false),
 
+DEFINE_PROP_BOOL("zicboz", RISCVCPU, cfg.ext_icboz, true),
+DEFINE_PROP_UINT16("cboz_blocksize", RISCVCPU, cfg.cboz_blocksize, 64),
+
 DEFINE_PROP_BOOL("zmmul", RISCVCPU, cfg.ext_zmmul, false),
 
 /* Vendor-specific custom extensions */
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 7128438d8e..6b4c714d3a 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -447,6 +447,7 @@ struct RISCVCPUConfig {
 bool ext_zkt;
 bool ext_ifencei;
 bool ext_icsr;
+bool ext_icboz;
 bool ext_zihintpause;
 bool ext_smstateen;
 bool ext_sstc;
@@ -494,6 +495,7 @@ struct RISCVCPUConfig {
 char *vext_spec;
 uint16_t vlen;
 uint16_t elen;
+uint16_t cboz_blocksize;
 bool mmu;
 bool pmp;
 bool epmp;
diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 0497370afd..ce165821b8 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -97,6 +97,9 @@ DEF_HELPER_FLAGS_2(fcvt_h_l, TCG_CALL_NO_RWG, i64, env, tl)
 DEF_HELPER_FLAGS_2(fcvt_h_lu, TCG_CALL_NO_RWG, i64, env, tl)
 DEF_HELPER_FLAGS_2(fclass_h, TCG_CALL_NO_RWG_SE, tl, env, i64)
 
+/* Cache-block operations */
+DEF_HELPER_2(cbo_zero, void, env, tl)
+
 /* Special functions */
 DEF_HELPER_2(csrr, tl, env, int)
 DEF_HELPER_3(csrw, void, env, int, tl)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index b7e7613ea2..3985bc703f 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -179,7 +179,15 @@ sraw 010 .  . 101 . 0111011 @r
 
 # *** RV128I Base Instruction Set (in addition to RV64I) ***
 ldu     . 111 . 011 @i
-lq      . 010 . 000 @i
+{
+  [
+# *** RV32 Zicboz Standard Extension ***
+cbo_zero   000 00100 . 010 0 000 @sfence_vm
+  ]
+
+  # *** RVI128 lq ***
+  lq      . 010 . 000 @i
+}
 sq      . 100 . 0100011 @s
 addid  .  000 . 1011011 @i
 sllid00 ..  . 001 . 1011011 @sh6
diff --git a/target/riscv/insn_trans/trans_rvzicbo.c.inc 
b/target/riscv/insn_trans/trans_rvzicbo.c.inc
new file mode 100644
index 00..feabc28342
--- /dev/null
+++ b/target/riscv/insn_trans/trans_rvzicbo.c.inc
@@ -0,0 +1,30 @@
+/*
+ * RISC-V translation routines for the RISC-V CBO Extension.
+ *
+ * Copyright (c) 2021 Philipp Tomsich, philipp.toms...@vrull.eu
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2 or later, as published by the Free 

[PATCH v7 4/4] target/riscv: add Zicbop cbo.prefetch{i, r, m} placeholder

[Daniel Henrique Barboza]

From: Christoph Muellner 

The cmo.prefetch instructions are nops for QEMU (no emulation of the
memory hierarchy, no illegal instructions, no permission faults, no
traps).

Add a comment noting where they would be decoded in case cbo.prefetch
instructions become relevant in the future.

Co-developed-by: Philipp Tomsich 
Signed-off-by: Christoph Muellner 
Signed-off-by: Daniel Henrique Barboza 
Reviewed-by: Richard Henderson 
---
 target/riscv/insn32.decode | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 3788f86528..1aebd37572 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -134,6 +134,7 @@ addi  . 000 . 0010011 @i
 slti  . 010 . 0010011 @i
 sltiu . 011 . 0010011 @i
 xori  . 100 . 0010011 @i
+# cbo.prefetch_{i,r,m} instructions are ori with rd=x0 and not decoded.
 ori   . 110 . 0010011 @i
 andi  . 111 . 0010011 @i
 slli 0. ... 001 . 0010011 @sh
-- 
2.39.2

Re: [PATCH v4 5/7] dump: Introduce create_win_dump()

[Richard Henderson]

On 2/23/23 13:17, Philippe Mathieu-Daudé wrote:

Remove another TARGET_X86_64 #ifdef'ry by introducing
a create_win_dump() stub. We'll extract it to a stub
file for non-x86 targets in the next commit.

Signed-off-by: Philippe Mathieu-Daudé
---
  dump/dump.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH v4 4/7] dump: Introduce win_dump_available()

[Richard Henderson]

On 2/23/23 13:17, Philippe Mathieu-Daudé wrote:

@@ -2130,12 +2136,10 @@ void qmp_dump_guest_memory(bool paging, const char 
*file,
  }
  #endif
  
-#ifndef TARGET_X86_64

-if (has_format && format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP) {
-error_setg(errp, "Windows dump is only available for x86-64");
+if (has_format && format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP
+&& !win_dump_available(errp)) {


Indentation is off.

Otherwise looks plausible as an intermediate step before more targets.
Reviewed-by: Richard Henderson 

r~

Re: [PATCH v4 3/7] dump: Correct headers included

[Richard Henderson]

On 2/23/23 13:17, Philippe Mathieu-Daudé wrote:

"qemu/win_dump_defs.h" is only required by win_dump.c,
but win_dump.h requires "sysemu/dump.h" which declares
the DumpState type.

Signed-off-by: Philippe Mathieu-Daudé
---
  dump/win_dump.c | 1 +
  dump/win_dump.h | 2 +-
  2 files changed, 2 insertions(+), 1 deletion(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH v4 2/7] dump: Replace TARGET_PAGE_SIZE -> qemu_target_page_size()

[Richard Henderson]

On 2/23/23 13:17, Philippe Mathieu-Daudé wrote:

TARGET_PAGE_SIZE is target specific. In preparation of
making dump.c target-agnostic, replace the compile-time
TARGET_PAGE_SIZE definition by runtime qemu_target_page_size().

Signed-off-by: Philippe Mathieu-Daudé
---
  dump/dump.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH v4 1/7] dump: Replace tswapN() -> cpu_to_dumpN()

[Richard Henderson]

On 2/23/23 13:17, Philippe Mathieu-Daudé wrote:

All uses of tswap in that file are wrong, and should be using
cpu_to_dumpN, which correctly tests the endianness of the output.

Suggested-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/dump.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH 2/5] hw/isa/vt82c686: Implement PCI IRQ routing

[BALATON Zoltan]

On Thu, 23 Feb 2023, BALATON Zoltan wrote:

On Thu, 23 Feb 2023, Bernhard Beschow wrote:

The real VIA south bridges implement a PCI IRQ router which is configured
by the BIOS or the OS. In order to respect these configurations, QEMU
needs to implement it as well.

Note: The implementation was taken from piix4_set_irq() in hw/isa/piix4.

Signed-off-by: Bernhard Beschow 
---
hw/isa/vt82c686.c | 44 
1 file changed, 44 insertions(+)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 3f9bd0c04d..f24e387d63 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -604,6 +604,48 @@ static void via_isa_request_i8259_irq(void *opaque, 
int irq, int level)

qemu_set_irq(s->cpu_intr, level);
}

+static int via_isa_get_pci_irq(const ViaISAState *s, int irq_num)
+{
+switch (irq_num) {
+case 0:
+return s->dev.config[0x55] >> 4;
+
+case 1:
+return s->dev.config[0x56] & 0xf;
+
+case 2:
+return s->dev.config[0x56] >> 4;
+
+case 3:
+return s->dev.config[0x57] >> 4;
+}
+
+return 0;
+}
+
+static void via_isa_set_pci_irq(void *opaque, int irq_num, int level)
+{
+ViaISAState *s = opaque;
+PCIBus *bus = pci_get_bus(>dev);
+int pic_irq;
+
+/* now we change the pic irq level according to the via irq mappings 
*/

+/* XXX: optimize */
+pic_irq = via_isa_get_pci_irq(s, irq_num);
+if (pic_irq < ISA_NUM_IRQS) {
+int i, pic_level;
+
+/* The pic level is the logical OR of all the PCI irqs mapped to 
it. */

+pic_level = 0;
+for (i = 0; i < PCI_NUM_PINS; i++) {
+if (pic_irq == via_isa_get_pci_irq(s, i)) {
+pic_level |= pci_bus_get_irq_level(bus, i);
+}
+}
+qemu_set_irq(s->isa_irqs[pic_irq], pic_level);
+}
+}
+
static void via_isa_realize(PCIDevice *d, Error **errp)
{
ViaISAState *s = VIA_ISA(d);
@@ -676,6 +718,8 @@ static void via_isa_realize(PCIDevice *d, Error **errp)
if (!qdev_realize(DEVICE(>mc97), BUS(pci_bus), errp)) {
return;
}
+
+pci_bus_irqs(pci_bus, via_isa_set_pci_irq, s, PCI_NUM_PINS);


Please no oversimplification. This replaces the connections to mv64361 gpp 
pins made in mv64361_realize() and breaks the interrupts that can be enabled 
in mv64361. I've implemented that for something but can't remember now which 
guest exactly, but this would be needed so please restore my pegasos2 patch 
and move this there connecting both mv64361 and via-isa to PCI interrupts as 
shown in the schematics. That means you also need the PIRQ pins here. Can you 
do a new version with that? I'll try this one in the meantime but I'm quite 
sure this is wrong as it is. You can drop the via-ac97 patches from this 
series, I can submit them separately rebased on the final IRQ series we come 
up with.


We'd also need the workaround I've posted yesterday for missing level 
sensitive interrupts in the PIC model here somewhere which in my series 
fixed the hang with sound and USB but it's still a problem with this 
series. After brief testing my guests still boot with this, I could not 
find the guest that needed the MV64361 gpp interrupts for PCI but let's 
not break that if it's already implemented. Can you do another version 
with these changes (restore PIRQ and pegasos2 patches and add workaround 
for level sensitive mode) so I can ask others to do some more tests with 
this over the weekend?


Regards,
BALATON Zoltan

Re: [RFC PATCH] target/arm: properly document FEAT_CRC32

[Richard Henderson]

On 2/23/23 13:22, Philippe Mathieu-Daudé wrote:

On 24/2/23 00:01, Richard Henderson wrote:

On 2/22/23 01:01, Alex Bennée wrote:

This is a mandatory feature for Armv8.1 architectures but we don't
state the feature clearly in our emulation list. While checking verify
our cortex-a76 model matches up with the current TRM by breaking out
the long form isar into a more modern readable FIELD_DP code.

Signed-off-by: Alex Bennée 
---
  docs/system/arm/emulation.rst |  1 +
  target/arm/cpu64.c    | 29 ++---
  target/arm/cpu_tcg.c  |  2 +-
  3 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 2062d71261..2c4fde5eef 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -14,6 +14,7 @@ the following architecture extensions:
  - FEAT_BBM at level 2 (Translation table break-before-make levels)
  - FEAT_BF16 (AArch64 BFloat16 instructions)
  - FEAT_BTI (Branch Target Identification)
+- FEAT_CRC32 (CRC32 instruction)
  - FEAT_CSV2 (Cache speculation variant 2)
  - FEAT_CSV2_1p1 (Cache speculation variant 2, version 1.1)
  - FEAT_CSV2_1p2 (Cache speculation variant 2, version 1.2)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 4066950da1..12e1a532ab 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -912,6 +912,8 @@ static void aarch64_a72_initfn(Object *obj)
  static void aarch64_a76_initfn(Object *obj)
  {
  ARMCPU *cpu = ARM_CPU(obj);
+    uint64_t t;
+    uint32_t u;
  cpu->dtb_compatible = "arm,cortex-a76";
  set_feature(>env, ARM_FEATURE_V8);
@@ -928,7 +930,18 @@ static void aarch64_a76_initfn(Object *obj)
  cpu->ctr = 0x8444C004;
  cpu->dcz_blocksize = 4;
  cpu->isar.id_aa64dfr0  = 0x10305408ull;
-    cpu->isar.id_aa64isar0 = 0x100010211120ull;
+
+    /* per r4p1 of the Cryptographic Extension TRM */
+    t = cpu->isar.id_aa64isar0;
+    t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2);  /* FEAT_PMULL */
+    t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1); /* FEAT_SHA1 */
+    t = FIELD_DP64(t, ID_AA64ISAR0, SHA2, 1); /* FEAT_SHA512 */
+    t = FIELD_DP64(t, ID_AA64ISAR0, CRC32, 1);    /* FEAT_CRC32 */
+    t = FIELD_DP64(t, ID_AA64ISAR0, ATOMIC, 2);   /* FEAT_LSE */
+    t = FIELD_DP64(t, ID_AA64ISAR0, RDM, 1);  /* FEAT_RDM */
+    t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1);   /* FEAT_DotProd */


Maybe:

     assert(t == 0x100010211120ull);


But why bother to break it out then?


r~

Re: [PATCH v2 17/20] vfio/common: Support device dirty page tracking with vIOMMU

[Jason Gunthorpe]

On Thu, Feb 23, 2023 at 03:33:09PM -0700, Alex Williamson wrote:
> On Thu, 23 Feb 2023 16:55:54 -0400
> Jason Gunthorpe  wrote:
> 
> > On Thu, Feb 23, 2023 at 01:06:33PM -0700, Alex Williamson wrote:
> > > > #2 is the presumption that the guest is using an identity map.  
> > > 
> > > This is a dangerous assumption.
> > >   
> > > > > I'd think the only viable fallback if the vIOMMU doesn't report its 
> > > > > max
> > > > > IOVA is the full 64-bit address space, otherwise it seems like we need
> > > > > to add a migration blocker.
> > > > 
> > > > This is basically saying vIOMMU doesn't work with migration, and we've
> > > > heard that this isn't OK. There are cases where vIOMMU is on but the
> > > > guest always uses identity maps. eg for virtual interrupt remapping.  
> > > 
> > > Yes, the vIOMMU can be automatically added to a VM when we exceed 255
> > > vCPUs, but I don't see how we can therefore deduce anything about the
> > > usage mode of the vIOMMU.
> > 
> > We just loose optimizations. Any mappings that are established outside
> > the dirty tracking range are permanently dirty. So at worst the guest
> > can block migration by establishing bad mappings. It is not exactly
> > production quality but it is still useful for a closed environment
> > with known guest configurations.
> 
> That doesn't seem to be what happens in this series, 

Seems like something is missed then

> nor does it really make sense to me that userspace would simply
> decide to truncate the dirty tracking ranges array.

Who else would do it?

> > No, 2**64 is too big a number to be reasonable.
> 
> So what are the actual restrictions were dealing with here?  I think it
> would help us collaborate on a solution if we didn't have these device
> specific restrictions sprinkled through the base implementation.

Hmm? It was always like this, the driver gets to decide if it accepts
the proprosed tracking ranges or not. Given how the implementation has
to work there is no device that could do 2**64...

At least for mlx5 it is in the multi-TB range. Enough for physical
memory on any real server.

> > Ideally we'd work it the other way and tell the vIOMMU that the vHW
> > only supports a limited number of address bits for the translation, eg
> > through the ACPI tables. Then the dirty tracking could safely cover
> > the larger of all system memory or the limited IOVA address space.
> 
> Why can't we do that?  Hotplug is an obvious issue, but maybe it's not
> vHW telling the vIOMMU a restriction, maybe it's a QEMU machine or
> vIOMMU option and if it's not set to something the device can support,
> migration is blocked.

I don't know, maybe we should if we can.

> > Or even better figure out how to get interrupt remapping without IOMMU
> > support :\
> 
> -machine q35,default_bus_bypass_iommu=on,kernel-irqchip=split \
> -device intel-iommu,caching-mode=on,intremap=on

Joao?

If this works lets just block migration if the vIOMMU is turned on..

Jason

Re: [PATCH 2/5] hw/isa/vt82c686: Implement PCI IRQ routing

[Bernhard Beschow]

Am 23. Februar 2023 21:11:23 UTC schrieb BALATON Zoltan :
>On Thu, 23 Feb 2023, Bernhard Beschow wrote:
>> The real VIA south bridges implement a PCI IRQ router which is configured
>> by the BIOS or the OS. In order to respect these configurations, QEMU
>> needs to implement it as well.
>> 
>> Note: The implementation was taken from piix4_set_irq() in hw/isa/piix4.
>> 
>> Signed-off-by: Bernhard Beschow 
>> ---
>> hw/isa/vt82c686.c | 44 
>> 1 file changed, 44 insertions(+)
>> 
>> diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
>> index 3f9bd0c04d..f24e387d63 100644
>> --- a/hw/isa/vt82c686.c
>> +++ b/hw/isa/vt82c686.c
>> @@ -604,6 +604,48 @@ static void via_isa_request_i8259_irq(void *opaque, int 
>> irq, int level)
>> qemu_set_irq(s->cpu_intr, level);
>> }
>> 
>> +static int via_isa_get_pci_irq(const ViaISAState *s, int irq_num)
>> +{
>> +switch (irq_num) {
>> +case 0:
>> +return s->dev.config[0x55] >> 4;
>> +
>> +case 1:
>> +return s->dev.config[0x56] & 0xf;
>> +
>> +case 2:
>> +return s->dev.config[0x56] >> 4;
>> +
>> +case 3:
>> +return s->dev.config[0x57] >> 4;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void via_isa_set_pci_irq(void *opaque, int irq_num, int level)
>> +{
>> +ViaISAState *s = opaque;
>> +PCIBus *bus = pci_get_bus(>dev);
>> +int pic_irq;
>> +
>> +/* now we change the pic irq level according to the via irq mappings */
>> +/* XXX: optimize */
>> +pic_irq = via_isa_get_pci_irq(s, irq_num);
>> +if (pic_irq < ISA_NUM_IRQS) {
>> +int i, pic_level;
>> +
>> +/* The pic level is the logical OR of all the PCI irqs mapped to 
>> it. */
>> +pic_level = 0;
>> +for (i = 0; i < PCI_NUM_PINS; i++) {
>> +if (pic_irq == via_isa_get_pci_irq(s, i)) {
>> +pic_level |= pci_bus_get_irq_level(bus, i);
>> +}
>> +}
>> +qemu_set_irq(s->isa_irqs[pic_irq], pic_level);
>> +}
>> +}
>> +
>> static void via_isa_realize(PCIDevice *d, Error **errp)
>> {
>> ViaISAState *s = VIA_ISA(d);
>> @@ -676,6 +718,8 @@ static void via_isa_realize(PCIDevice *d, Error **errp)
>> if (!qdev_realize(DEVICE(>mc97), BUS(pci_bus), errp)) {
>> return;
>> }
>> +
>> +pci_bus_irqs(pci_bus, via_isa_set_pci_irq, s, PCI_NUM_PINS);
>
>Please no oversimplification. This replaces the connections to mv64361 gpp 
>pins made in mv64361_realize() and breaks the interrupts that can be enabled 
>in mv64361.

Let's split our work as follows: You'll do the audio and pegasos2 changes 
including exporting the pirq properties, I'll do the first three routing 
patches of this series as the base.

> I've implemented that for something but can't remember now which guest 
> exactly,

Could you please put this information into the commit message or into the code? 
That would ease maintainance a lot.

> but this would be needed so please restore my pegasos2 patch and move this 
> there connecting both mv64361 and via-isa to PCI interrupts as shown in the 
> schematics. That means you also need the PIRQ pins here. Can you do a new 
> version with that?

As proposed above I'd fold the first three patches into a separate series which 
you can build upon. I have no way to test the pegasos2 IRQ changes since the 
test cases I'm aware of either work or we agreed that they can be fixed later 
(-> USB).

> I'll try this one in the meantime

Sounds good to me -- that's what I wanted to achieve ;) Thanks!

Best regards,
Bernhard

> but I'm quite sure this is wrong as it is. You can drop the via-ac97 patches 
> from this series, I can submit them separately rebased on the final IRQ 
> series we come up with.
>
>Regards,
>BALATON Zoltan
>
>> }
>> 
>> /* TYPE_VT82C686B_ISA */
>> 

Re: [PATCH v4 7/7] dump: Rename x86-specific file as win_dump_x86.c

[Philippe Mathieu-Daudé]

Oops, "win_dump-x86.c" in subject...

On 24/2/23 00:17, Philippe Mathieu-Daudé wrote:

win_dump.c is x86 specific. Rename it as such in case
someone is willing to add win_dump-aarch64 :)

Signed-off-by: Philippe Mathieu-Daudé 
---
  dump/meson.build| 2 +-
  dump/{win_dump.c => win_dump-x86.c} | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
  rename dump/{win_dump.c => win_dump-x86.c} (99%)

diff --git a/dump/meson.build b/dump/meson.build
index 6ae07e6fed..d899949a73 100644
--- a/dump/meson.build
+++ b/dump/meson.build
@@ -2,5 +2,5 @@ softmmu_ss.add(files('dump-hmp-cmds.c'))
  
  softmmu_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, lzo])

  specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'],
-if_true: files('win_dump.c'),
+if_true: files('win_dump-x86.c'),
  if_false: files('win_dump-stub.c'))
diff --git a/dump/win_dump.c b/dump/win_dump-x86.c
similarity index 99%
rename from dump/win_dump.c
rename to dump/win_dump-x86.c
index ffeef4b738..5ee9a1d764 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump-x86.c
@@ -1,5 +1,5 @@
  /*
- * Windows crashdump
+ * Windows crashdump for x86 targets
   *
   * Copyright (c) 2018 Virtuozzo International GmbH
   *

Re: [RFC PATCH] target/arm: properly document FEAT_CRC32

[Philippe Mathieu-Daudé]

On 24/2/23 00:01, Richard Henderson wrote:

On 2/22/23 01:01, Alex Bennée wrote:

This is a mandatory feature for Armv8.1 architectures but we don't
state the feature clearly in our emulation list. While checking verify
our cortex-a76 model matches up with the current TRM by breaking out
the long form isar into a more modern readable FIELD_DP code.

Signed-off-by: Alex Bennée 
---
  docs/system/arm/emulation.rst |  1 +
  target/arm/cpu64.c    | 29 ++---
  target/arm/cpu_tcg.c  |  2 +-
  3 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/docs/system/arm/emulation.rst 
b/docs/system/arm/emulation.rst

index 2062d71261..2c4fde5eef 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -14,6 +14,7 @@ the following architecture extensions:
  - FEAT_BBM at level 2 (Translation table break-before-make levels)
  - FEAT_BF16 (AArch64 BFloat16 instructions)
  - FEAT_BTI (Branch Target Identification)
+- FEAT_CRC32 (CRC32 instruction)
  - FEAT_CSV2 (Cache speculation variant 2)
  - FEAT_CSV2_1p1 (Cache speculation variant 2, version 1.1)
  - FEAT_CSV2_1p2 (Cache speculation variant 2, version 1.2)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 4066950da1..12e1a532ab 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -912,6 +912,8 @@ static void aarch64_a72_initfn(Object *obj)
  static void aarch64_a76_initfn(Object *obj)
  {
  ARMCPU *cpu = ARM_CPU(obj);
+    uint64_t t;
+    uint32_t u;
  cpu->dtb_compatible = "arm,cortex-a76";
  set_feature(>env, ARM_FEATURE_V8);
@@ -928,7 +930,18 @@ static void aarch64_a76_initfn(Object *obj)
  cpu->ctr = 0x8444C004;
  cpu->dcz_blocksize = 4;
  cpu->isar.id_aa64dfr0  = 0x10305408ull;
-    cpu->isar.id_aa64isar0 = 0x100010211120ull;
+
+    /* per r4p1 of the Cryptographic Extension TRM */
+    t = cpu->isar.id_aa64isar0;
+    t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2);  /* FEAT_PMULL */
+    t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1); /* FEAT_SHA1 */
+    t = FIELD_DP64(t, ID_AA64ISAR0, SHA2, 1); /* FEAT_SHA512 */
+    t = FIELD_DP64(t, ID_AA64ISAR0, CRC32, 1);    /* FEAT_CRC32 */
+    t = FIELD_DP64(t, ID_AA64ISAR0, ATOMIC, 2);   /* FEAT_LSE */
+    t = FIELD_DP64(t, ID_AA64ISAR0, RDM, 1);  /* FEAT_RDM */
+    t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1);   /* FEAT_DotProd */


Maybe:

assert(t == 0x100010211120ull);


+    cpu->isar.id_aa64isar0 = t;


Ok, so, this might be helpful for grepping, but it's not helpful for 
reading the documentation, which on page B2-137 uses hex.



r~

Re: [PATCH v2 1/2] linux-user: Fix unaligned memory access in prlimit64 syscall

[Philippe Mathieu-Daudé]

On 24/2/23 00:11, Ilya Leoshkevich wrote:

target_rlimit64 contains uint64_t fields, so it's 8-byte aligned on
some hosts, while some guests may align their respective type on a
4-byte boundary. This may lead to an unaligned access, which is an UB.

Fix by defining the fields as abi_ullong. This makes the host alignment
match that of the guest, and lets the compiler know that it should emit
code that can deal with the guest alignment.

While at it, also use __get_user() and __put_user() instead of
tswap64().

Fixes: 163a05a8398b ("linux-user: Implement prlimit64 syscall")
Reported-by: Richard Henderson 
Signed-off-by: Ilya Leoshkevich 
---
  linux-user/generic/target_resource.h | 4 ++--
  linux-user/syscall.c | 8 
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/linux-user/generic/target_resource.h 
b/linux-user/generic/target_resource.h
index 539d8c46772..37d3eb09b3b 100644
--- a/linux-user/generic/target_resource.h
+++ b/linux-user/generic/target_resource.h
@@ -12,8 +12,8 @@ struct target_rlimit {
  };
  
  struct target_rlimit64 {

-uint64_t rlim_cur;
-uint64_t rlim_max;
+abi_ullong rlim_cur;
+abi_ullong rlim_max;
  };
  
  #define TARGET_RLIM_INFINITY((abi_ulong)-1)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index a6c426d73cf..1f7a272799b 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -12886,8 +12886,8 @@ static abi_long do_syscall1(CPUArchState *cpu_env, int 
num, abi_long arg1,
  if (!lock_user_struct(VERIFY_READ, target_rnew, arg3, 1)) {
  return -TARGET_EFAULT;
  }
-rnew.rlim_cur = tswap64(target_rnew->rlim_cur);
-rnew.rlim_max = tswap64(target_rnew->rlim_max);
+__get_user(rnew.rlim_cur, _rnew->rlim_cur);
+__get_user(rnew.rlim_max, _rnew->rlim_max);


Thanks,
Reviewed-by: Philippe Mathieu-Daudé 

[PATCH v4 6/7] dump: Build once by adding stubs for non-x86 targets

[Philippe Mathieu-Daudé]

Extract non-x86 stubs to win_dump-stub.c. We can now
build dump.o once for system emulation. Update meson.

Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/dump.c  | 14 --
 dump/meson.build |  6 --
 dump/win_dump-stub.c | 23 +++
 3 files changed, 27 insertions(+), 16 deletions(-)
 create mode 100644 dump/win_dump-stub.c

diff --git a/dump/dump.c b/dump/dump.c
index b33a613d45..7cde3e326e 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -32,20 +32,6 @@
 #include "migration/blocker.h"
 #include "win_dump.h"
 
-#ifndef TARGET_X86_64
-bool win_dump_available(Error **errp)
-{
-error_setg(errp, "Windows dump is only available for x86-64");
-
-return false;
-}
-
-void create_win_dump(DumpState *s, Error **errp)
-{
-win_dump_available(errp);
-}
-#endif
-
 #include 
 #ifdef CONFIG_LZO
 #include 
diff --git a/dump/meson.build b/dump/meson.build
index 2eff29c3ea..6ae07e6fed 100644
--- a/dump/meson.build
+++ b/dump/meson.build
@@ -1,4 +1,6 @@
 softmmu_ss.add(files('dump-hmp-cmds.c'))
 
-specific_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, 
lzo])
-specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'], if_true: 
files('win_dump.c'))
+softmmu_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, lzo])
+specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'],
+if_true: files('win_dump.c'),
+if_false: files('win_dump-stub.c'))
diff --git a/dump/win_dump-stub.c b/dump/win_dump-stub.c
new file mode 100644
index 00..87cb699e3d
--- /dev/null
+++ b/dump/win_dump-stub.c
@@ -0,0 +1,23 @@
+/*
+ * Windows crashdump stubs for non-x86 targets
+ *
+ * Copyright (c) 2023 Linaro Ltd
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "win_dump.h"
+
+bool win_dump_available(Error **errp)
+{
+error_setg(errp, "Windows dump is only available for x86-64");
+
+return false;
+}
+
+void create_win_dump(DumpState *s, Error **errp)
+{
+win_dump_available(errp);
+}
-- 
2.38.1

[PATCH v4 2/7] dump: Replace TARGET_PAGE_SIZE -> qemu_target_page_size()

[Philippe Mathieu-Daudé]

TARGET_PAGE_SIZE is target specific. In preparation of
making dump.c target-agnostic, replace the compile-time
TARGET_PAGE_SIZE definition by runtime qemu_target_page_size().

Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/dump.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/dump/dump.c b/dump/dump.c
index 7101169ecb..3784a9054d 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -15,6 +15,7 @@
 #include "qemu/cutils.h"
 #include "elf.h"
 #include "exec/hwaddr.h"
+#include "exec/target_page.h"
 #include "monitor/monitor.h"
 #include "sysemu/kvm.h"
 #include "sysemu/dump.h"
@@ -1859,7 +1860,7 @@ static void dump_init(DumpState *s, int fd, bool 
has_format,
 }
 
 if (!s->dump_info.page_size) {
-s->dump_info.page_size = TARGET_PAGE_SIZE;
+s->dump_info.page_size = qemu_target_page_size();
 }
 
 s->note_size = cpu_get_note_size(s->dump_info.d_class,
-- 
2.38.1

[PATCH v4 3/7] dump: Correct headers included

[Philippe Mathieu-Daudé]

"qemu/win_dump_defs.h" is only required by win_dump.c,
but win_dump.h requires "sysemu/dump.h" which declares
the DumpState type.

Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/win_dump.c | 1 +
 dump/win_dump.h | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/dump/win_dump.c b/dump/win_dump.c
index f20b6051b6..12b7da5da0 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump.c
@@ -21,6 +21,7 @@
 #include "qapi/qmp/qerror.h"
 #include "qemu/error-report.h"
 #include "hw/misc/vmcoreinfo.h"
+#include "qemu/win_dump_defs.h"
 #include "win_dump.h"
 
 static size_t win_dump_ptr_size(bool x64)
diff --git a/dump/win_dump.h b/dump/win_dump.h
index b8c25348f4..56f63683c3 100644
--- a/dump/win_dump.h
+++ b/dump/win_dump.h
@@ -11,7 +11,7 @@
 #ifndef WIN_DUMP_H
 #define WIN_DUMP_H
 
-#include "qemu/win_dump_defs.h"
+#include "sysemu/dump.h"
 
 void create_win_dump(DumpState *s, Error **errp);
 
-- 
2.38.1

[PATCH v4 7/7] dump: Rename x86-specific file as win_dump_x86.c

[Philippe Mathieu-Daudé]

win_dump.c is x86 specific. Rename it as such in case
someone is willing to add win_dump-aarch64 :)

Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/meson.build| 2 +-
 dump/{win_dump.c => win_dump-x86.c} | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename dump/{win_dump.c => win_dump-x86.c} (99%)

diff --git a/dump/meson.build b/dump/meson.build
index 6ae07e6fed..d899949a73 100644
--- a/dump/meson.build
+++ b/dump/meson.build
@@ -2,5 +2,5 @@ softmmu_ss.add(files('dump-hmp-cmds.c'))
 
 softmmu_ss.add(when: 'CONFIG_SOFTMMU', if_true: [files('dump.c'), snappy, lzo])
 specific_ss.add(when: ['CONFIG_SOFTMMU', 'TARGET_X86_64'],
-if_true: files('win_dump.c'),
+if_true: files('win_dump-x86.c'),
 if_false: files('win_dump-stub.c'))
diff --git a/dump/win_dump.c b/dump/win_dump-x86.c
similarity index 99%
rename from dump/win_dump.c
rename to dump/win_dump-x86.c
index ffeef4b738..5ee9a1d764 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump-x86.c
@@ -1,5 +1,5 @@
 /*
- * Windows crashdump
+ * Windows crashdump for x86 targets
  *
  * Copyright (c) 2018 Virtuozzo International GmbH
  *
-- 
2.38.1

[PATCH v4 5/7] dump: Introduce create_win_dump()

[Philippe Mathieu-Daudé]

Remove another TARGET_X86_64 #ifdef'ry by introducing
a create_win_dump() stub. We'll extract it to a stub
file for non-x86 targets in the next commit.

Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/dump.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index c356a88be1..b33a613d45 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -39,6 +39,11 @@ bool win_dump_available(Error **errp)
 
 return false;
 }
+
+void create_win_dump(DumpState *s, Error **errp)
+{
+win_dump_available(errp);
+}
 #endif
 
 #include 
@@ -2031,9 +2036,7 @@ static void dump_process(DumpState *s, Error **errp)
 DumpQueryResult *result = NULL;
 
 if (s->has_format && s->format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP) {
-#ifdef TARGET_X86_64
 create_win_dump(s, errp);
-#endif
 } else if (s->has_format && s->format != DUMP_GUEST_MEMORY_FORMAT_ELF) {
 create_kdump_vmcore(s, errp);
 } else {
-- 
2.38.1

[PATCH v4 4/7] dump: Introduce win_dump_available()

[Philippe Mathieu-Daudé]

Remove a pair of TARGET_X86_64 #ifdef'ry by introducing
the win_dump_available() method. We'll soon extract it
to a stub file for non-x86 targets.

Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/dump.c | 23 +--
 dump/win_dump.c |  5 +
 dump/win_dump.h |  3 +++
 3 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index 3784a9054d..c356a88be1 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -30,9 +30,15 @@
 #include "qemu/main-loop.h"
 #include "hw/misc/vmcoreinfo.h"
 #include "migration/blocker.h"
-
-#ifdef TARGET_X86_64
 #include "win_dump.h"
+
+#ifndef TARGET_X86_64
+bool win_dump_available(Error **errp)
+{
+error_setg(errp, "Windows dump is only available for x86-64");
+
+return false;
+}
 #endif
 
 #include 
@@ -2130,12 +2136,10 @@ void qmp_dump_guest_memory(bool paging, const char 
*file,
 }
 #endif
 
-#ifndef TARGET_X86_64
-if (has_format && format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP) {
-error_setg(errp, "Windows dump is only available for x86-64");
+if (has_format && format == DUMP_GUEST_MEMORY_FORMAT_WIN_DMP
+&& !win_dump_available(errp)) {
 return;
 }
-#endif
 
 #if !defined(WIN32)
 if (strstart(file, "fd:", )) {
@@ -2217,10 +2221,9 @@ DumpGuestMemoryCapability 
*qmp_query_dump_guest_memory_capability(Error **errp)
 QAPI_LIST_APPEND(tail, DUMP_GUEST_MEMORY_FORMAT_KDUMP_SNAPPY);
 #endif
 
-/* Windows dump is available only if target is x86_64 */
-#ifdef TARGET_X86_64
-QAPI_LIST_APPEND(tail, DUMP_GUEST_MEMORY_FORMAT_WIN_DMP);
-#endif
+if (win_dump_available(NULL)) {
+QAPI_LIST_APPEND(tail, DUMP_GUEST_MEMORY_FORMAT_WIN_DMP);
+}
 
 return cap;
 }
diff --git a/dump/win_dump.c b/dump/win_dump.c
index 12b7da5da0..ffeef4b738 100644
--- a/dump/win_dump.c
+++ b/dump/win_dump.c
@@ -24,6 +24,11 @@
 #include "qemu/win_dump_defs.h"
 #include "win_dump.h"
 
+bool win_dump_available(Error **errp)
+{
+return true;
+}
+
 static size_t win_dump_ptr_size(bool x64)
 {
 return x64 ? sizeof(uint64_t) : sizeof(uint32_t);
diff --git a/dump/win_dump.h b/dump/win_dump.h
index 56f63683c3..9abce289ac 100644
--- a/dump/win_dump.h
+++ b/dump/win_dump.h
@@ -13,6 +13,9 @@
 
 #include "sysemu/dump.h"
 
+/* Windows dump is available only if target is x86_64 */
+bool win_dump_available(Error **errp);
+
 void create_win_dump(DumpState *s, Error **errp);
 
 #endif /* WIN_DUMP_H */
-- 
2.38.1

[PATCH v4 1/7] dump: Replace tswapN() -> cpu_to_dumpN()

[Philippe Mathieu-Daudé]

All uses of tswap in that file are wrong, and should be using
cpu_to_dumpN, which correctly tests the endianness of the output.

Suggested-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
---
 dump/dump.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/dump/dump.c b/dump/dump.c
index 279b07f09b..7101169ecb 100644
--- a/dump/dump.c
+++ b/dump/dump.c
@@ -907,13 +907,13 @@ static void get_note_sizes(DumpState *s, const void *note,
 if (dump_is_64bit(s)) {
 const Elf64_Nhdr *hdr = note;
 note_head_sz = sizeof(Elf64_Nhdr);
-name_sz = tswap64(hdr->n_namesz);
-desc_sz = tswap64(hdr->n_descsz);
+name_sz = cpu_to_dump64(s, hdr->n_namesz);
+desc_sz = cpu_to_dump64(s, hdr->n_descsz);
 } else {
 const Elf32_Nhdr *hdr = note;
 note_head_sz = sizeof(Elf32_Nhdr);
-name_sz = tswap32(hdr->n_namesz);
-desc_sz = tswap32(hdr->n_descsz);
+name_sz = cpu_to_dump32(s, hdr->n_namesz);
+desc_sz = cpu_to_dump32(s, hdr->n_descsz);
 }
 
 if (note_head_size) {
-- 
2.38.1

[PATCH v4 0/7] dump: Make most of it target agnostic (build once)

[Philippe Mathieu-Daudé]

Thanks to Richard help, we can now build dump.o once
for all targets, keeping win_dump.o for x86* targets.

Philippe Mathieu-Daudé (7):
  dump: Replace tswapN() -> cpu_to_dumpN()
  dump: Replace TARGET_PAGE_SIZE -> qemu_target_page_size()
  dump: Correct headers included
  dump: Introduce win_dump_available()
  dump: Introduce create_win_dump()
  dump: Build once by adding stubs for non-x86 targets
  dump: Rename x86-specific file as win_dump_x86.c

 dump/dump.c | 29 +++--
 dump/meson.build|  6 --
 dump/win_dump-stub.c| 23 +++
 dump/{win_dump.c => win_dump-x86.c} |  8 +++-
 dump/win_dump.h |  5 -
 5 files changed, 49 insertions(+), 22 deletions(-)
 create mode 100644 dump/win_dump-stub.c
 rename dump/{win_dump.c => win_dump-x86.c} (99%)

-- 
2.38.1

Re: [PATCH v2 1/2] linux-user: Fix unaligned memory access in prlimit64 syscall

[Richard Henderson]

On 2/23/23 13:11, Ilya Leoshkevich wrote:

target_rlimit64 contains uint64_t fields, so it's 8-byte aligned on
some hosts, while some guests may align their respective type on a
4-byte boundary. This may lead to an unaligned access, which is an UB.

Fix by defining the fields as abi_ullong. This makes the host alignment
match that of the guest, and lets the compiler know that it should emit
code that can deal with the guest alignment.

While at it, also use __get_user() and __put_user() instead of
tswap64().

Fixes: 163a05a8398b ("linux-user: Implement prlimit64 syscall")
Reported-by: Richard Henderson
Signed-off-by: Ilya Leoshkevich
---
  linux-user/generic/target_resource.h | 4 ++--
  linux-user/syscall.c | 8 
  2 files changed, 6 insertions(+), 6 deletions(-)


Reviewed-by: Richard Henderson 

r~

[PATCH v2 2/2] tests/tcg/linux-test: Add linux-fork-trap test

[Ilya Leoshkevich]

Check that dying due to a signal does not deadlock.

Reviewed-by: Richard Henderson 
Reviewed-by: Alex Bennée 
Signed-off-by: Ilya Leoshkevich 
---
 tests/tcg/multiarch/linux/linux-fork-trap.c | 51 +
 1 file changed, 51 insertions(+)
 create mode 100644 tests/tcg/multiarch/linux/linux-fork-trap.c

diff --git a/tests/tcg/multiarch/linux/linux-fork-trap.c 
b/tests/tcg/multiarch/linux/linux-fork-trap.c
new file mode 100644
index 000..2bfef800c3e
--- /dev/null
+++ b/tests/tcg/multiarch/linux/linux-fork-trap.c
@@ -0,0 +1,51 @@
+/*
+ * Test that a fork()ed process terminates after __builtin_trap().
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+int main(void)
+{
+struct rlimit nodump;
+pid_t err, pid;
+int wstatus;
+
+pid = fork();
+assert(pid != -1);
+if (pid == 0) {
+/* We are about to crash on purpose; disable core dumps. */
+if (getrlimit(RLIMIT_CORE, )) {
+return EXIT_FAILURE;
+}
+nodump.rlim_cur = 0;
+if (setrlimit(RLIMIT_CORE, )) {
+return EXIT_FAILURE;
+}
+/*
+ * An alternative would be to dereference a NULL pointer, but that
+ * would be an UB in C.
+ */
+printf("about to trigger fault...\n");
+#if defined(__MICROBLAZE__)
+/*
+ * gcc emits "bri 0", which is an endless loop.
+ * Take glibc's ABORT_INSTRUCTION.
+ */
+asm volatile("brki r0,-1");
+#else
+__builtin_trap();
+#endif
+}
+err = waitpid(pid, , 0);
+assert(err == pid);
+assert(WIFSIGNALED(wstatus));
+printf("faulting thread exited cleanly\n");
+
+return EXIT_SUCCESS;
+}
-- 
2.39.1

[PATCH v2 1/2] linux-user: Fix unaligned memory access in prlimit64 syscall

[Ilya Leoshkevich]

target_rlimit64 contains uint64_t fields, so it's 8-byte aligned on
some hosts, while some guests may align their respective type on a
4-byte boundary. This may lead to an unaligned access, which is an UB.

Fix by defining the fields as abi_ullong. This makes the host alignment
match that of the guest, and lets the compiler know that it should emit
code that can deal with the guest alignment.

While at it, also use __get_user() and __put_user() instead of
tswap64().

Fixes: 163a05a8398b ("linux-user: Implement prlimit64 syscall")
Reported-by: Richard Henderson 
Signed-off-by: Ilya Leoshkevich 
---
 linux-user/generic/target_resource.h | 4 ++--
 linux-user/syscall.c | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/linux-user/generic/target_resource.h 
b/linux-user/generic/target_resource.h
index 539d8c46772..37d3eb09b3b 100644
--- a/linux-user/generic/target_resource.h
+++ b/linux-user/generic/target_resource.h
@@ -12,8 +12,8 @@ struct target_rlimit {
 };
 
 struct target_rlimit64 {
-uint64_t rlim_cur;
-uint64_t rlim_max;
+abi_ullong rlim_cur;
+abi_ullong rlim_max;
 };
 
 #define TARGET_RLIM_INFINITY((abi_ulong)-1)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index a6c426d73cf..1f7a272799b 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -12886,8 +12886,8 @@ static abi_long do_syscall1(CPUArchState *cpu_env, int 
num, abi_long arg1,
 if (!lock_user_struct(VERIFY_READ, target_rnew, arg3, 1)) {
 return -TARGET_EFAULT;
 }
-rnew.rlim_cur = tswap64(target_rnew->rlim_cur);
-rnew.rlim_max = tswap64(target_rnew->rlim_max);
+__get_user(rnew.rlim_cur, _rnew->rlim_cur);
+__get_user(rnew.rlim_max, _rnew->rlim_max);
 unlock_user_struct(target_rnew, arg3, 0);
 rnewp = 
 }
@@ -12897,8 +12897,8 @@ static abi_long do_syscall1(CPUArchState *cpu_env, int 
num, abi_long arg1,
 if (!lock_user_struct(VERIFY_WRITE, target_rold, arg4, 1)) {
 return -TARGET_EFAULT;
 }
-target_rold->rlim_cur = tswap64(rold.rlim_cur);
-target_rold->rlim_max = tswap64(rold.rlim_max);
+__put_user(target_rold->rlim_cur, _cur);
+__put_user(target_rold->rlim_max, _max);
 unlock_user_struct(target_rold, arg4, 1);
 }
 return ret;
-- 
2.39.1

[PATCH v2 0/2] linux-user: Fix unaligned memory access in prlimit64 syscall

[Ilya Leoshkevich]

v1: https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg06999.html
v1 -> v2: Fix by using proper target_rlimit64 alignment (Richard).
  Use __get_user() and __put_user() (Philippe - if I understood
  the suggestion correctly).

Hi,

Richard reported [1] that the new linux-fork-trap test was failing
under UBSan [2], so it was excluded from the PR.

This is a resend of the test plus the fix for the additional issue that
it uncovered.

[1] https://lists.gnu.org/archive/html/qemu-devel/2023-02/msg06130.html
[2] https://gitlab.com/qemu-project/qemu/-/jobs/3807471447#L5064

Best regards,
Ilya

Ilya Leoshkevich (2):
  linux-user: Fix unaligned memory access in prlimit64 syscall
  tests/tcg/linux-test: Add linux-fork-trap test

 linux-user/generic/target_resource.h|  4 +-
 linux-user/syscall.c|  8 ++--
 tests/tcg/multiarch/linux/linux-fork-trap.c | 51 +
 3 files changed, 57 insertions(+), 6 deletions(-)
 create mode 100644 tests/tcg/multiarch/linux/linux-fork-trap.c

-- 
2.39.1

Re: [RFC PATCH] target/arm: properly document FEAT_CRC32

[Richard Henderson]

On 2/22/23 01:01, Alex Bennée wrote:

This is a mandatory feature for Armv8.1 architectures but we don't
state the feature clearly in our emulation list. While checking verify
our cortex-a76 model matches up with the current TRM by breaking out
the long form isar into a more modern readable FIELD_DP code.

Signed-off-by: Alex Bennée 
---
  docs/system/arm/emulation.rst |  1 +
  target/arm/cpu64.c| 29 ++---
  target/arm/cpu_tcg.c  |  2 +-
  3 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/docs/system/arm/emulation.rst b/docs/system/arm/emulation.rst
index 2062d71261..2c4fde5eef 100644
--- a/docs/system/arm/emulation.rst
+++ b/docs/system/arm/emulation.rst
@@ -14,6 +14,7 @@ the following architecture extensions:
  - FEAT_BBM at level 2 (Translation table break-before-make levels)
  - FEAT_BF16 (AArch64 BFloat16 instructions)
  - FEAT_BTI (Branch Target Identification)
+- FEAT_CRC32 (CRC32 instruction)
  - FEAT_CSV2 (Cache speculation variant 2)
  - FEAT_CSV2_1p1 (Cache speculation variant 2, version 1.1)
  - FEAT_CSV2_1p2 (Cache speculation variant 2, version 1.2)
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 4066950da1..12e1a532ab 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -912,6 +912,8 @@ static void aarch64_a72_initfn(Object *obj)
  static void aarch64_a76_initfn(Object *obj)
  {
  ARMCPU *cpu = ARM_CPU(obj);
+uint64_t t;
+uint32_t u;
  
  cpu->dtb_compatible = "arm,cortex-a76";

  set_feature(>env, ARM_FEATURE_V8);
@@ -928,7 +930,18 @@ static void aarch64_a76_initfn(Object *obj)
  cpu->ctr = 0x8444C004;
  cpu->dcz_blocksize = 4;
  cpu->isar.id_aa64dfr0  = 0x10305408ull;
-cpu->isar.id_aa64isar0 = 0x100010211120ull;
+
+/* per r4p1 of the Cryptographic Extension TRM */
+t = cpu->isar.id_aa64isar0;
+t = FIELD_DP64(t, ID_AA64ISAR0, AES, 2);  /* FEAT_PMULL */
+t = FIELD_DP64(t, ID_AA64ISAR0, SHA1, 1); /* FEAT_SHA1 */
+t = FIELD_DP64(t, ID_AA64ISAR0, SHA2, 1); /* FEAT_SHA512 */
+t = FIELD_DP64(t, ID_AA64ISAR0, CRC32, 1);/* FEAT_CRC32 */
+t = FIELD_DP64(t, ID_AA64ISAR0, ATOMIC, 2);   /* FEAT_LSE */
+t = FIELD_DP64(t, ID_AA64ISAR0, RDM, 1);  /* FEAT_RDM */
+t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1);   /* FEAT_DotProd */
+cpu->isar.id_aa64isar0 = t;


Ok, so, this might be helpful for grepping, but it's not helpful for reading the 
documentation, which on page B2-137 uses hex.



r~

Re: [PULL 0/9] Fourth RISC-V PR for QEMU 8.0

[Palmer Dabbelt]

On Wed, 22 Feb 2023 07:56:10 PST (-0800), Palmer Dabbelt wrote:

On Tue, 21 Feb 2023 08:43:47 PST (-0800), Peter Maydell wrote:

On Fri, 17 Feb 2023 at 17:53, Palmer Dabbelt  wrote:


The following changes since commit 417296c8d8588f782018d01a317f88957e9786d6:

  tests/qtest/netdev-socket: Raise connection timeout to 60 seconds (2023-02-09 
11:23:53 +)

are available in the Git repository at:

  https://github.com/palmer-dabbelt/qemu.git tags/pull-riscv-to-apply-20230217

for you to fetch changes up to e8c0697d79ef05aa5aefb1121dfede5986b4:

  target/riscv: Fix vslide1up.vf and vslide1down.vf (2023-02-16 08:10:40 -0800)


Fourth RISC-V PR for QEMU 8.0

* A triplet of cleanups to the kernel/initrd loader that avoids
  duplication between the various boards.
* OpenSBI has been updated to version 1.2.
* Weiwei Li, Daniel Henrique Barboza, and Liu Zhiwei have been added as
  reviewers.  Thanks for the help!
* A fix for PMP matching to avoid incorrectly appling the default
  permissions on PMP permission violations.
* A cleanup to avoid an unnecessary avoid env_archcpu() in
  cpu_get_tb_cpu_state().
* Fixes for the vector slide instructions to avoid truncating 64-bit
  values (such as doubles) on 32-bit targets.


This seems to have caused CI to decide it needs to rerun the
'docker-opensbi' job, which doesn't work:
https://gitlab.com/qemu-project/qemu/-/jobs/3808319659

I don't understand what exactly is going on here -- Alex,
Bin, any ideas?

Why do we build the firmware in CI if we have checked in
binaries in pc-bios?

Should .gitlab-ci.d/opensbi/Dockerfile really still be
starting with Ubuntu 18.04 ? That is already older than our
set of supported platforms, and falls out of support from
Ubuntu in a couple of months.


I just sent along a patch
.
I have no idea how to test it in the CI, though...


Nobody's replied, so I'm inclined to just drop the OpenSBI bump and 
re-send the PR.  At least that way we can avoid getting blocked on the 
CI issues.  There's some more in flight so there'll probably be a 5th 
round before the freeze either way, at least this way the stuff that 
works can avoid getting blocked.



(.gitlab-ci.d/edk2/Dockerfile is also using 18.04.)


I guess I'd missed this in the original email, I stumbled on that one as
well
.



thanks
-- PMM

Re: [PATCH 1/2] linux-user: Fix unaligned memory access in prlimit64 syscall

[Ilya Leoshkevich]

On Thu, 2023-02-23 at 12:31 -1000, Richard Henderson wrote:
> On 2/23/23 11:58, Ilya Leoshkevich wrote:
> > 32-bit guests may enforce only 4-byte alignment for
> > target_rlimit64,
> > whereas 64-bit hosts normally require the 8-byte one. Therefore
> > accessing this struct directly is UB.
> > 
> > Fix by adding a local copy.
> > 
> > Fixes: 163a05a8398b ("linux-user: Implement prlimit64 syscall")
> > Reported-by: Richard Henderson 
> > Signed-off-by: Ilya Leoshkevich 
> > ---
> >   linux-user/syscall.c | 12 +++-
> >   1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> > index a6c426d73cf..8ae7696d8f1 100644
> > --- a/linux-user/syscall.c
> > +++ b/linux-user/syscall.c
> > @@ -12876,7 +12876,7 @@ static abi_long do_syscall1(CPUArchState
> > *cpu_env, int num, abi_long arg1,
> >   case TARGET_NR_prlimit64:
> >   {
> >   /* args: pid, resource number, ptr to new rlimit, ptr to
> > old rlimit */
> > -    struct target_rlimit64 *target_rnew, *target_rold;
> > +    struct target_rlimit64 *target_rnew, *target_rold, tmp;
> 
> The bug is that target_rlimit64 uses uint64_t (64-bit host
> alignment), when it should be 
> using abi_ullong (64-bit target alignment).  There are quite a number
> of these sorts of 
> bugs in linux-user.
> 
> 
> r~

Thanks, this helps.

I thought that unaligned accesses were illegal no matter what, e.g., on
sparc64, but turns out the compiler is actually smart enough to handle
them:

#include 
typedef uint64_t abi_ullong __attribute__((aligned(4)));
abi_ullong load(abi_ullong *x) { return *x; }

produces

load:
save%sp, -176, %sp
lduw[%i0], %g1
lduw[%i0+4], %i0
sllx%g1, 32, %g1
return  %i7+8
 or %o0, %g1, %o0

instead of just

load:
save%sp, -176, %sp
return  %i7+8
 ldx[%o0], %o0

I'll send a v2.

Best regards,
Ilya