date:20211106

The following changes since commit c39deb218178d1fb814dd2138ceff4b541a03d85:

  Merge remote-tracking branch 'remotes/kraxel/tags/egl-20211105-pull-request' 
into staging (2021-11-05 11:42:06 -0400)

are available in the Git repository at:

  https://github.com/juanquintela/qemu.git tags/migration-20211106-pull-request

for you to fetch changes up to f78d4ed701454f10079461b981ba2a61a95762ab:

  docs: fix qemu incorrect tag (2021-11-06 12:35:38 +0100)


Migration Pull request

- fix vhost-user crash when using postcopy (me)
- fix incorrect tag for docs (hyman)

Please apply, Juan.



Hyman Huang(黄勇) (1):
  docs: fix qemu incorrect tag

Juan Quintela (1):
  migration: Check that postcopy fd's are not NULL

 qapi/migration.json  | 10 +-
 migration/postcopy-ram.c |  4 
 2 files changed, 9 insertions(+), 5 deletions(-)

-- 
2.33.1

[PULL 2/2] docs: fix qemu incorrect tag

From: Hyman Huang(黄勇) 

The patchset merged in 71864eadd9a ("migration/dirtyrate:
introduce struct and adjust DirtyRateStat") was targeting
QEMU 6.1 but got merged later, so correct the tag for 6.2.

Signed-off-by: Hyman Huang(黄勇) 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Juan Quintela 
Signed-off-by: Juan Quintela 
---
 qapi/migration.json | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/qapi/migration.json b/qapi/migration.json
index 87146ceea2..f0aefdab64 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -1740,7 +1740,7 @@
 #
 # @dirty-rate: dirty rate.
 #
-# Since: 6.1
+# Since: 6.2
 #
 ##
 { 'struct': 'DirtyRateVcpu',
@@ -1774,7 +1774,7 @@
 #
 # @dirty-bitmap: calculate dirtyrate by dirty bitmap.
 #
-# Since: 6.1
+# Since: 6.2
 #
 ##
 { 'enum': 'DirtyRateMeasureMode',
@@ -1796,13 +1796,13 @@
 # @calc-time: time in units of second for sample dirty pages
 #
 # @sample-pages: page count per GB for sample dirty pages
-#the default value is 512 (since 6.1)
+#the default value is 512 (since 6.2)
 #
 # @mode: mode containing method of calculate dirtyrate includes
-#'page-sampling' and 'dirty-ring' (Since 6.1)
+#'page-sampling' and 'dirty-ring' (Since 6.2)
 #
 # @vcpu-dirty-rate: dirtyrate for each vcpu if dirty-ring
-#   mode specified (Since 6.1)
+#   mode specified (Since 6.2)
 #
 # Since: 5.2
 #
-- 
2.33.1

[PULL 1/2] migration: Check that postcopy fd's are not NULL

If postcopy has finished, it frees the array.
But vhost-user unregister it at cleanup time.

fixes: c4f7538
Signed-off-by: Juan Quintela 
Reviewed-by: Dr. David Alan Gilbert 
---
 migration/postcopy-ram.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
index e721f69d0f..d18b5d05b2 100644
--- a/migration/postcopy-ram.c
+++ b/migration/postcopy-ram.c
@@ -1457,6 +1457,10 @@ void postcopy_unregister_shared_ufd(struct PostCopyFD 
*pcfd)
 MigrationIncomingState *mis = migration_incoming_get_current();
 GArray *pcrfds = mis->postcopy_remote_fds;
 
+if (!pcrfds) {
+/* migration has already finished and freed the array */
+return;
+}
 for (i = 0; i < pcrfds->len; i++) {
 struct PostCopyFD *cur = _array_index(pcrfds, struct PostCopyFD, i);
 if (cur->fd == pcfd->fd) {
-- 
2.33.1

Re: [PULL 4/6] ui/gtk-egl: guest fb texture needs to be regenerated when reinitializing egl


Le 05/11/2021 à 12:30, Gerd Hoffmann a écrit :

From: Dongwon Kim 

If guest fb is backed by dmabuf (blob-resource), the texture bound to the
old context needs to be recreated in case the egl is re-initialized (e.g.
new window for vc is created in case of detaching/reattaching of the tab)

v2: call egl_dmabuf_release_texutre instead of putting 0 to dmabuf->texture
 (Vivek Kasireddy)

Cc: Gerd Hoffmann 
Signed-off-by: Dongwon Kim 
Message-Id: <20211104065153.28897-3-dongwon@intel.com>
Signed-off-by: Gerd Hoffmann 
---
  ui/gtk-egl.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index 21649950983f..f2026e4b5c9b 100644
--- a/ui/gtk-egl.c
+++ b/ui/gtk-egl.c
@@ -155,6 +155,10 @@ void gd_egl_refresh(DisplayChangeListener *dcl)
  surface_gl_destroy_texture(vc->gfx.gls, vc->gfx.ds);
  surface_gl_create_texture(vc->gfx.gls, vc->gfx.ds);
  }
+if (vc->gfx.guest_fb.dmabuf) {
+egl_dmabuf_release_texture(vc->gfx.guest_fb.dmabuf);
+gd_egl_scanout_dmabuf(dcl, vc->gfx.guest_fb.dmabuf);
+}
  }
  
  graphic_hw_update(dcl->con);




This patch breaks something:

$ .../configure' '--target-list=m68k-softmmu' '--enable-virglrenderer'
$ make
...

FAILED: libcommon.fa.p/ui_gtk-egl.c.o
cc -m64 -mcx16 -Ilibcommon.fa.p -I../../../Projects/qemu-next/capstone/include/capstone 
-I../../../Projects/qemu-next/dtc/libfdt -I../../../Projects/qemu-next/slirp 
-I../../../Projects/qemu-next/slirp/src -I/usr/include/pixman-1 -I/usr/include/libpng16 
-I/usr/include/p11-kit-1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
-I/usr/include/sysprof-4 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 
-I/usr/include/virgl -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz 
-I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/libxml2 -I/usr/include/cairo 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cloudproviders -I/usr/include/atk-1.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include 
-I/usr/include/at-spi-2.0 -I/usr/include/vte-2.91 -fdiagnostics-color=auto -Wall -Winvalid-pch 
-Werror -std=gnu11 -O2 -g -isystem /home/laurent/Projects/qemu-next/linux-headers -isystem 
linux-headers -iquote . -iquote /home/laurent/Projects/qemu-next -iquote 
/home/laurent/Projects/qemu-next/include -iquote /home/laurent/Projects/qemu-next/disas/libvixl 
-iquote /home/laurent/Projects/qemu-next/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls 
-Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k 
-Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined 
-Wimplicit-fallthrough=2 -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi 
-fstack-protector-strong -fPIE -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -DNCURSES_WIDECHAR -D_REENTRANT 
-MD -MQ libcommon.fa.p/ui_gtk-egl.c.o -MF libcommon.fa.p/ui_gtk-egl.c.o.d -o 
libcommon.fa.p/ui_gtk-egl.c.o -c ../../../Projects/qemu-next/ui/gtk-egl.c

../../../Projects/qemu-next/ui/gtk-egl.c: In function 'gd_egl_refresh':
../../../Projects/qemu-next/ui/gtk-egl.c:159:13: error: implicit declaration of function 
'egl_dmabuf_release_texture' [-Werror=implicit-function-declaration]

  159 | egl_dmabuf_release_texture(vc->gfx.guest_fb.dmabuf);
  | ^~
../../../Projects/qemu-next/ui/gtk-egl.c:159:13: error: nested extern declaration of 
'egl_dmabuf_release_texture' [-Werror=nested-externs]


I think we need something like:

diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index f2026e4b5c9b..45cb67712df0 100644
--- a/ui/gtk-egl.c
+++ b/ui/gtk-egl.c
@@ -155,10 +155,12 @@ void gd_egl_refresh(DisplayChangeListener *dcl)
 surface_gl_destroy_texture(vc->gfx.gls, vc->gfx.ds);
 surface_gl_create_texture(vc->gfx.gls, vc->gfx.ds);
 }
+#ifdef CONFIG_GBM
 if (vc->gfx.guest_fb.dmabuf) {
 egl_dmabuf_release_texture(vc->gfx.guest_fb.dmabuf);
 gd_egl_scanout_dmabuf(dcl, vc->gfx.guest_fb.dmabuf);
 }
+#endif
 }

 graphic_hw_update(dcl->con);

Thanks,
Laurent

[PATCH 0/2] hw: m68k: add missing virt machine types

Add the machine type for 6.2, and also for 6.1 that I have
missed on the previous release.

Laurent Vivier (2):
  hw: m68: virt: Add compat machines for 6.1
  hw: m68: virt: Add compat machines for 6.2

 hw/m68k/virt.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

-- 
2.31.1

[PATCH 2/2] hw: m68: virt: Add compat machines for 6.2

Add the missing machine type for m68k/virt

Signed-off-by: Laurent Vivier 
---
 hw/m68k/virt.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 0d9e3f83c169..978c26e025a7 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -304,10 +304,17 @@ type_init(virt_machine_register_types)
 } \
 type_init(machvirt_machine_##major##_##minor##_init);
 
+static void virt_machine_6_2_options(MachineClass *mc)
+{
+}
+DEFINE_VIRT_MACHINE(6, 2, true)
+
 static void virt_machine_6_1_options(MachineClass *mc)
 {
+virt_machine_6_2_options(mc);
+compat_props_add(mc->compat_props, hw_compat_6_1, hw_compat_6_1_len);
 }
-DEFINE_VIRT_MACHINE(6, 1, true)
+DEFINE_VIRT_MACHINE(6, 1, false)
 
 static void virt_machine_6_0_options(MachineClass *mc)
 {
-- 
2.31.1

[PATCH 1/2] hw: m68: virt: Add compat machines for 6.1

Add the missing machine type for m68k/virt

Cc: qemu-sta...@nongnu.org
Signed-off-by: Laurent Vivier 
---
 hw/m68k/virt.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 4e8bce5aa6f7..0d9e3f83c169 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -304,7 +304,14 @@ type_init(virt_machine_register_types)
 } \
 type_init(machvirt_machine_##major##_##minor##_init);
 
+static void virt_machine_6_1_options(MachineClass *mc)
+{
+}
+DEFINE_VIRT_MACHINE(6, 1, true)
+
 static void virt_machine_6_0_options(MachineClass *mc)
 {
+virt_machine_6_1_options(mc);
+compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len);
 }
-DEFINE_VIRT_MACHINE(6, 0, true)
+DEFINE_VIRT_MACHINE(6, 0, false)
-- 
2.31.1

Re: [PATCH v4 0/1] hw/hyperv/vmbus: Is it maintained?

2021-11-06 Thread Maciej S. Szmigiero


On 06.11.2021 14:41, Philippe Mathieu-Daudé wrote:

This is the 4th time I send this patch. Is the VMBus infrastructure
used / maintained? Should we deprecate & remove?

   $ ./scripts/get_maintainer.pl -f hw/hyperv/vmbus.c -f 
include/hw/hyperv/vmbus.h
   get_maintainer.pl: No maintainers found


There's an email thread at [1] explaining the reasons for having VMBus
infrastructure last time such question was asked.

In short: mere presence of a working VMBus is needed for some high-speed
Windows debugging, also people are working on VMBus host device drivers.

Your patch makes sense to me, so for it:
Reviewed-by: Maciej S. Szmigiero 

Thanks,
Maciej

[1]: https://lore.kernel.org/qemu-devel/20201009193919.gf7...@habkost.net/T/#u

Re: [PATCH v2 0/4] hw/isa: Remove unuseful qemu_allocate_irqs() call

2021-11-06 Thread BALATON Zoltan


On Sat, 6 Nov 2021, Philippe Mathieu-Daudé wrote:

Cc'ing Zoltan


What do I have to do with this? This was a while ago so I don't remember 
and it seems to not touch any of the devices I have some experience with 
so not sure what do you expect from me for this series.


Regards,
BALATON Zoltan


On 5/11/21 06:06, Philippe Mathieu-Daudé wrote:

I started to fix the LeakSanitizer error in piix4_realize(),
then looked for similar pattern and found 2 other places.
The older is i82378 (historically the first one) which then
spread.

Since v1:
- rebased
- removed vt82c686 patches

Philippe Mathieu-Daudé (4):
  hw/isa/i82378: Name output IRQ as 'intr'
  hw/isa/i82378: Simplify removing unuseful qemu_allocate_irqs() call
  hw/isa/i82378: Rename output IRQ variable
  hw/isa/piix4: Fix leak removing unuseful qemu_allocate_irqs() call

 hw/isa/i82378.c | 13 +++--
 hw/isa/piix4.c  | 10 +-
 hw/ppc/prep.c   |  4 ++--
 3 files changed, 6 insertions(+), 21 deletions(-)

Re: Qemu and ARM secure state.

2021-11-06 Thread Jean-Christophe DUBOIS

One small question/remark:

According to the the "Arm Power State Coordinate Interface" (DEN0022D.b)
document (chapter 5) PSCI calls can only be issued by "normal world"
(EL1 or EL2). Therefore, should we be adding a test for the current
secure state in the arm_is_psci_call() function? This would prevent
calling the built-in Qemu PSCI function if SMC is issued from secure state.

Regards.

Le 06/11/2021 à 14:04, Jean-Christophe DUBOIS a écrit :
So it seems that what is needed is a way to choose on the command line
if we want to enable the Qemu built-in PSCI implementation (because we
are booting linux for example) or if we really want a bare metal
processor (because we are booting a trustedOS like optee).

The "virt" platform allows to dynamically choose one or the other.
Other platforms seems to need the same feature.

Le 06/11/2021 à 11:04, Jean-Christophe DUBOIS a écrit :

So, I am trying to understand:

Contrary to what I said, In my case the SMC instruction is not really
a "no-op" as it sets R0 to -1 (0x) to indicate an unknown
PSCI service (by the Qemu internal PSCI handler).

With the new code introduced by the "arm: tcg: Adhere to SMCCC 1.3
section 5.2" commit, once a processor/platform configure things to
have PSCI requests handled by Qemu code (with "psci-conduit"
attribute set to QEMU_PSCI_CONDUIT_SMC for example), then any
exception raised by an "SMC" instruction will be only handled by the
Qemu internal code and will no call the monitor related code in the
guest/OS application. This seems to be why my SMC monitor handler is
not called anymore in my case.

As my i.MX6UL is a mono-processor platform I don't really need to set
the "psci-conduit" attribute (which really makes sense when you have
a cluster of 2 or more cores I guess). As a matter of fact if I
remove the "psci-conduit" attribute setting from the i.MX6UL
processor file, my application is working again on main/latest.

But this still raises the question to know if the current behavior
for processors with "psci-conduit" set to SMC or HVC is correct. For
example an i.MX7 based platform (with up to 4 cortex A7 cores) would
not be able to trigger OS SMC handler as the exception would be
entirely processed by the Qemu internal code (with CR generally set
to -1 in R0 to indicate unknown PSCI request).

Is there something I am missing?

Regards

Le 04/11/2021 à 22:11, Jean-Christophe DUBOIS a écrit :

Le 04/11/2021 à 12:11, Peter Maydell a écrit :

On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS
wrote:

I have a little application that is designed to work on the i.MX6UL processor.

I developed it and tested it on the mcimx6ul-evk platform emulated by Qemu.

This application used to work "flawlessly" on Qemu 5.0.50 and is working on
Qemu 6.0.0 (available as a pre-built package on the latest Ubuntu).

But when I try to run the exact same command line on a Qemu version I compile
myself from main/latest of github (Qemu 6.1.50), my application fails to start.

So a little background:

My application expects to start in "secure" state and supervisor mode (which is
the default state of i.MX6UL when booting barebone [without u-boot]).

>From this state the application tries to get to "non secure" / hypervisor mode which imply going to the
"secure" / monitor state before being able to drop to "non secure" / hypervisor. To do so is runs a "smc
0" operand (from "secure" / supervisor).

This "smc" instruction is processed "as expected" by Qemu 5.0.50 and Qemu 6.0.0 (getting to
"secure" / monitor mode) but on Qemu 6.1.50 (latest from github) it is as if the smc operand was a no-op. It
doesn't trigger any exception and the processor just get to the next instruction after the "smc" instruction.
So I am a bit puzzled.

Is there something that changed in Qemu (since Qemu 6.0.0) when it comes to the
"secure" world/state?
Is there some additional command line parameters to use (I search in the
documentation but without luck) to get secure world behavior ?
Is it necessary to "adapt" the emulated platform (i.MX6UL/mcimx6ul-evk) in some way (it looks like
the "virt" machine with "secure=on" does work for arm platform)?

Could you try doing a bisect to find the QEMU commit that caused
your guest to stop working ?

OK, I did the bisect and the commit that break the i.MX6UL behavior
for my program is commit 9fcd15b9193e819b6cc2fd0a45e3506148812bb4
(arm: tcg: Adhere to SMCCC 1.3 section 5.2).

Before it the SMC instruction would trigger a monitor exception.

After it the SMC instruction is acting like a no-op.

Thanks

thanks
-- PMM

Re: [PATCH] target/ppc, hw/ppc: Change maintainers

2021-11-06 Thread Cédric Le Goater


What we are going do will depend on inputs really. We have pseries
and KVM in focus because there is still business using the software
stack. TCG is extremely useful for pseries and powernv. We clearly
want to keep that running and improve it. Some parts have been barely
touched (and probably used) in the last 15 years. I think we should
drop some support to modernize the useful parts and ease maintenance.


Here let me recommend the ant work approach I'm doing for MIPS. Instead
of dropping ISA extensions, I'm splitting them in various compile units,
that way 1/ we can chose to build without them and 2/ sub-maintainers
can maintain them separately. Having a finer grained MAINTAINERS
entries allow to filter-out/in and reduce reviewers pressure.


OK. Yes, the goal is to ease maintenance, not to remove platforms or
CPUs. QEMU is the perfect project for legacy systems.

I am very willing to go in that direction and take the risk to break
a few things. We have been through such an episode when HV mode was
added for the PowerNV machine and we managed to fix all regressions,
down to OpenBIOS. Ben and his ppc32 knowledge helped a lot of course.

Untangling some parts won't be easy. Exception modeling for instance.
The instruction implementation shouldn't be too hard and it's being
modernized by Luis and Matheus. I guess we should improve our
testsuite to catch early any issues. An acceptance test for each
machine is a minimum.

Thanks,

C.

Re: [PATCH] meson: Fix 'interpretor' typo


Le 06/11/2021 à 15:53, Philippe Mathieu-Daudé a écrit :

ping...

https://lore.kernel.org/qemu-devel/20210521103423.2780345-1-phi...@redhat.com/

On Sat, Jun 5, 2021 at 9:03 PM Laurent Vivier  wrote:


Le 21/05/2021 à 12:34, Philippe Mathieu-Daudé a écrit :

Fix a typo from commit fa2f7b0b9b7 ("meson: Warn when TCI is
selected but TCG backend is available").

Reported-by: Peter Maydell 
Signed-off-by: Philippe Mathieu-Daudé 
---
  meson.build | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 1559e8d873a..230a0e4b558 100644
--- a/meson.build
+++ b/meson.build
@@ -247,7 +247,7 @@
error('Unsupported CPU @0@, try --enable-tcg-interpreter'.format(cpu))
  endif
elif get_option('tcg_interpreter')
-warning('Use of the TCG interpretor is not recommended on this host')
+warning('Use of the TCG interpreter is not recommended on this host')
  warning('architecture. There is a native TCG execution backend available')
  warning('which provides substantially better performance and 
reliability.')
  warning('It is strongly recommended to remove the 
--enable-tcg-interpreter')



Reviewed-by: Laurent Vivier 






Applied to my trivial-patches branch.

Thanks,
Laurent

Re: [PATCH v2 0/4] hw/isa: Remove unuseful qemu_allocate_irqs() call

Cc'ing Zoltan

On 5/11/21 06:06, Philippe Mathieu-Daudé wrote:
> I started to fix the LeakSanitizer error in piix4_realize(),
> then looked for similar pattern and found 2 other places.
> The older is i82378 (historically the first one) which then
> spread.
> 
> Since v1:
> - rebased
> - removed vt82c686 patches
> 
> Philippe Mathieu-Daudé (4):
>   hw/isa/i82378: Name output IRQ as 'intr'
>   hw/isa/i82378: Simplify removing unuseful qemu_allocate_irqs() call
>   hw/isa/i82378: Rename output IRQ variable
>   hw/isa/piix4: Fix leak removing unuseful qemu_allocate_irqs() call
> 
>  hw/isa/i82378.c | 13 +++--
>  hw/isa/piix4.c  | 10 +-
>  hw/ppc/prep.c   |  4 ++--
>  3 files changed, 6 insertions(+), 21 deletions(-)
>

Re: [PATCH 00/11] exec: Restrict various system emulation specific headers (to sysemu)

6 months passed, heavy rebased required, dropping for now.

On 5/25/21 16:13, Philippe Mathieu-Daudé wrote:
> Ping for review? :)
> 
> On 5/17/21 1:11 PM, Philippe Mathieu-Daudé wrote:
>> Hi,
>>
>> This series restricts various system emulation specific headers
>> by moving them under sysemu/ and adding #error if included from
>> user emulation.
>> We could avoid the sysemu/ rename if too much churn, but enforcing
>> error of headers that must not be included in user emulation allows
>> further cleanups (to be sent later).
>>
>> I had to split the ioport.c file to cpu-io (generic to any target
>> having access to I/O bus, but I haven't checked the TCG implementation
>> details for user emulation) VS ioport (system specific, access to
>> hardware).
>>
>> Many files are changed, but this is mostly one-line mechanical
>> updates of old path to new path using sed.
>>
>> Regards,
>>
>> Phil.
>>
>> Philippe Mathieu-Daudé (11):
>>   NOTFORMERGE target/arm: Restrict KVM files to softmmu
>>   exec: Restrict hwaddr.h to sysemu/
>>   exec: Restrict cputlb.h to sysemu/
>>   exec: Restrict memory.h to sysemu/
>>   exec: Restrict memory-internal.h to sysemu/
>>   exec: Restrict address-spaces.h to sysemu/
>>   exec: Extract CPU I/O instructions to "cpu-io.h"
>>   exec: Restrict ioport.h to sysemu/
>>   exec: Restrict ram_addr.h to sysemu/
>>   exec: Restrict ramblock.h to sysemu/
>>   exec: Restrict confidential-guest-support.h to sysemu/
> 
>>  275 files changed, 491 insertions(+), 409 deletions(-)
>>  create mode 100644 include/exec/cpu-io.h
>>  rename include/exec/{ => sysemu}/address-spaces.h (80%)
>>  rename include/exec/{ => sysemu}/cputlb.h (86%)
>>  rename include/exec/{ => sysemu}/hwaddr.h (81%)
>>  rename include/exec/{ => sysemu}/memory-internal.h (94%)
>>  rename include/exec/{ => sysemu}/memory.h (99%)
>>  rename include/{exec => sysemu}/confidential-guest-support.h (95%)
>>  rename include/{exec => sysemu}/ioport.h (86%)
>>  rename include/{exec => sysemu}/ram_addr.h (99%)
>>  rename include/{exec => sysemu}/ramblock.h (92%)
>>  create mode 100644 softmmu/cpu-io.c
>>
>

Re: [PATCH] meson: Fix 'interpretor' typo

ping...

https://lore.kernel.org/qemu-devel/20210521103423.2780345-1-phi...@redhat.com/

On Sat, Jun 5, 2021 at 9:03 PM Laurent Vivier  wrote:
>
> Le 21/05/2021 à 12:34, Philippe Mathieu-Daudé a écrit :
> > Fix a typo from commit fa2f7b0b9b7 ("meson: Warn when TCI is
> > selected but TCG backend is available").
> >
> > Reported-by: Peter Maydell 
> > Signed-off-by: Philippe Mathieu-Daudé 
> > ---
> >  meson.build | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meson.build b/meson.build
> > index 1559e8d873a..230a0e4b558 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -247,7 +247,7 @@
> >error('Unsupported CPU @0@, try 
> > --enable-tcg-interpreter'.format(cpu))
> >  endif
> >elif get_option('tcg_interpreter')
> > -warning('Use of the TCG interpretor is not recommended on this host')
> > +warning('Use of the TCG interpreter is not recommended on this host')
> >  warning('architecture. There is a native TCG execution backend 
> > available')
> >  warning('which provides substantially better performance and 
> > reliability.')
> >  warning('It is strongly recommended to remove the 
> > --enable-tcg-interpreter')
> >
>
> Reviewed-by: Laurent Vivier 
>

[PATCH-for-6.2 v2] hw/mem/pc-dimm: Restrict NUMA-specific code to NUMA machines

When trying to use the pc-dimm device on a non-NUMA machine, we get:

  $ qemu-system-arm -M none -cpu max -S \
  -object memory-backend-file,id=mem1,size=1M,mem-path=/tmp/1m \
  -device pc-dimm,id=dimm1,memdev=mem1
  Segmentation fault (core dumped)

  (gdb) bt
  #0  pc_dimm_realize (dev=0x56da3e90, errp=0x7fffcd10) at 
hw/mem/pc-dimm.c:184
  #1  0x55fe1f8f in device_set_realized (obj=0x56da3e90, 
value=true, errp=0x7fffce18) at hw/core/qdev.c:531
  #2  0x55feb4a9 in property_set_bool (obj=0x56da3e90, 
v=0x56e54420, name=0x563c3c41 "realized", opaque=0x56a704f0, 
errp=0x7fffce18) at qom/object.c:2257

To avoid that crash, restrict the pc-dimm NUMA check to machines
supporting NUMA, and do not allow the use of 'node' property on
non-NUMA machines.

Suggested-by: Igor Mammedov 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2: Follow Igor suggestion

Supersedes: <20210524171352.3796151-1-f4...@amsat.org>
---
 hw/mem/pc-dimm.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/hw/mem/pc-dimm.c b/hw/mem/pc-dimm.c
index a3a2560301c..48b913aba67 100644
--- a/hw/mem/pc-dimm.c
+++ b/hw/mem/pc-dimm.c
@@ -181,7 +181,21 @@ static void pc_dimm_realize(DeviceState *dev, Error **errp)
 PCDIMMDevice *dimm = PC_DIMM(dev);
 PCDIMMDeviceClass *ddc = PC_DIMM_GET_CLASS(dimm);
 MachineState *ms = MACHINE(qdev_get_machine());
-int nb_numa_nodes = ms->numa_state->num_nodes;
+
+if (ms->numa_state) {
+int nb_numa_nodes = ms->numa_state->num_nodes;
+
+if (((nb_numa_nodes > 0) && (dimm->node >= nb_numa_nodes)) ||
+(!nb_numa_nodes && dimm->node)) {
+error_setg(errp, "'DIMM property " PC_DIMM_NODE_PROP " has value %"
+   PRIu32 "' which exceeds the number of numa nodes: %d",
+   dimm->node, nb_numa_nodes ? nb_numa_nodes : 1);
+return;
+}
+} else if (dimm->node > 0) {
+error_setg(errp, "machine doesn't support NUMA");
+return;
+}
 
 if (!dimm->hostmem) {
 error_setg(errp, "'" PC_DIMM_MEMDEV_PROP "' property is not set");
@@ -191,13 +205,6 @@ static void pc_dimm_realize(DeviceState *dev, Error **errp)
object_get_canonical_path_component(OBJECT(dimm->hostmem)));
 return;
 }
-if (((nb_numa_nodes > 0) && (dimm->node >= nb_numa_nodes)) ||
-(!nb_numa_nodes && dimm->node)) {
-error_setg(errp, "'DIMM property " PC_DIMM_NODE_PROP " has value %"
-   PRIu32 "' which exceeds the number of numa nodes: %d",
-   dimm->node, nb_numa_nodes ? nb_numa_nodes : 1);
-return;
-}
 
 if (ddc->realize) {
 ddc->realize(dimm, errp);
-- 
2.31.1

Chardev: delete the QemuOpts reserved in vm_config_groups

2021-11-06 Thread ????????????

We have found that qemu cannot plug in the previously unplugged device.
start qemu with the following command:
./qemu-system-x86_64 -enable-kvm -m 8192 -smp 16 \
 -object 
memory-backend-file,id=mem,size=8192M,mem-path=/dev/hugepages,share=on \
 -numa node,memdev=mem -mem-prealloc \
 ...
 -chardev 
socket,id=drive-virtio-disk1,path=/var/run/spdk/vhost_blk_socket-30dcf467-486a-45cf-b754-093bf5cf24d1,reconnect=10
 \
 -device 
vhost-user-blk-pci,chardev=drive-virtio-disk1,num-queues=1,bus=pci.0,addr=0x5,id=virtio-disk1
 \
 ...


(qemu) info chardev
serial0: filename=pty:/dev/pts/0
drive-virtio-disk1: filename=unix:
charmonitor:
filename=unix:/usr/local/var/lib/libvirt/qemu/domain-55-e59039db-d576-40db-a/monitor.sock,server
(qemu) device_del virtio-disk1
(qemu) chardev-remove drive-virtio-disk1
(qemu) info chardev
serial0: filename=pty:/dev/pts/0
charmonitor:
filename=unix:/usr/local/var/lib/libvirt/qemu/domain-55-e59039db-d576-40db-a/monitor.sock,server
(qemu) chardev-add 
socket,id=drive-virtio-disk1,path=/var/run/spdk/vhost_blk_socket-30dcf467-486a-45cf-b754-093bf5cf24d1,reconnect=10
device failed: Duplicate ID 'drive-virtio-disk1' for chardev Error: Parsing 
chardev args failed


The root cause of this issue is that the QemuOpts is still reserved in 
vm_config_groups list,
so qemu_opts_create will fail with the error above. So the QemuOpts should be 
removed when
invoking qmp_chardev_remove.




Signed-off-by: Zhoujian Yu

Re: [PATCH] tests/vm/freebsd: Increase code coverage

On 6/15/21 19:40, Wainer dos Santos Moschetta wrote:
> Hi,
> 
> On 6/15/21 2:19 PM, Daniel P. Berrangé wrote:
>> On Tue, Jun 15, 2021 at 06:02:02PM +0100, Daniel P. Berrangé wrote:
>>> On Mon, May 31, 2021 at 05:53:25PM -0300, Wainer dos Santos Moschetta
>>> wrote:
 Hi,

 On 5/31/21 7:03 AM, Philippe Mathieu-Daudé wrote:
> Install more dependencies to increase code coverage.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>    tests/vm/freebsd | 5 +
>    1 file changed, 5 insertions(+)
 With or without this patch I got an error when `make
 vm-build-freebsd`. It
 fails to install packages.

 For example, with this patch I got:

 < Output omitted>

 ### Installing packages ...
 Failed to prepare guest environment
 Traceback (most recent call last):
    File "/home/wmoschet/src/qemu/tests/vm/basevm.py", line 634, in main
  return vm.build_image(args.image)
    File "/home/wmoschet/src/qemu/tests/vm/freebsd", line 206, in
 build_image
  self.ssh_root_check("pkg install -y %s\n" % " ".join(self.pkgs))
    File "/home/wmoschet/src/qemu/tests/vm/basevm.py", line 255, in
 ssh_root_check
  self._ssh_do(self._config["root_user"], cmd, True)
    File "/home/wmoschet/src/qemu/tests/vm/basevm.py", line 242, in
 _ssh_do
  raise Exception("SSH command failed: %s" % cmd)
 Exception: SSH command failed: pkg install -y git pkgconf bzip2
 python37
 ninja bash gmake gsed gettext cyrus-sasl gnutls nettle jpeg-turbo
 png sdl2
 gtk3 libxkbcommon pixman libepoxy mesa-libs zstd usbredir

 Is it a known issue?
>>> Hard to actually tell what the error really is. This message is
>>> only giving the command that was invoked, but seems to have thrown
>>> away stdout/stderr which would have the messages telling us what
>>> went wrong.  This lack of error reporting in basevm.py so badly
>>> needs to be fixed, otherwise we're working blind when debugging
>>> failures.
>> Hmm, when I try the same command, it *does* print all the output
>> so you can see what's going on, but it doesn't actually fail for
>> me either (without this patch).
> 
> Thomas sent me a message in private while ago that the error could be
> related with the amount of ssh keys in my agent-ssh. I didn' t check
> that hypothesis yet; will debug a littler further and let you all posted.
> 
> ah, if this problem cannot be reproduced on other machinesI see no
> reason to hold this patch.

OK thank you!

[PATCH v4 1/1] hw/hyperv/vmbus: Remove unused vmbus_load/save_req()

vmbus_save_req() and vmbus_load_req() are not used.
Remove them to avoid maintaining dead code.

This partially reverts commit 4dd8a7064b8a6527f99a62be11
("vmbus: add infrastructure to save/load vmbus requests").

Signed-off-by: Philippe Mathieu-Daudé 
---
 include/hw/hyperv/vmbus.h |  3 --
 hw/hyperv/vmbus.c | 59 ---
 2 files changed, 62 deletions(-)

diff --git a/include/hw/hyperv/vmbus.h b/include/hw/hyperv/vmbus.h
index f98bea3888d..8ea660dd8e6 100644
--- a/include/hw/hyperv/vmbus.h
+++ b/include/hw/hyperv/vmbus.h
@@ -223,7 +223,4 @@ int vmbus_map_sgl(VMBusChanReq *req, DMADirection dir, 
struct iovec *iov,
 void vmbus_unmap_sgl(VMBusChanReq *req, DMADirection dir, struct iovec *iov,
  unsigned iov_cnt, size_t accessed);
 
-void vmbus_save_req(QEMUFile *f, VMBusChanReq *req);
-void *vmbus_load_req(QEMUFile *f, VMBusDevice *dev, uint32_t size);
-
 #endif
diff --git a/hw/hyperv/vmbus.c b/hw/hyperv/vmbus.c
index dbce3b35fba..78c19caf5f7 100644
--- a/hw/hyperv/vmbus.c
+++ b/hw/hyperv/vmbus.c
@@ -1311,65 +1311,6 @@ static const VMStateDescription vmstate_vmbus_chan_req = 
{
 }
 };
 
-void vmbus_save_req(QEMUFile *f, VMBusChanReq *req)
-{
-VMBusChanReqSave req_save;
-
-req_save.chan_idx = req->chan->subchan_idx;
-req_save.pkt_type = req->pkt_type;
-req_save.msglen = req->msglen;
-req_save.msg = req->msg;
-req_save.transaction_id = req->transaction_id;
-req_save.need_comp = req->need_comp;
-req_save.num = req->sgl.nsg;
-req_save.sgl = g_memdup(req->sgl.sg,
-req_save.num * sizeof(ScatterGatherEntry));
-
-vmstate_save_state(f, _vmbus_chan_req, _save, NULL);
-
-g_free(req_save.sgl);
-}
-
-void *vmbus_load_req(QEMUFile *f, VMBusDevice *dev, uint32_t size)
-{
-VMBusChanReqSave req_save;
-VMBusChanReq *req = NULL;
-VMBusChannel *chan = NULL;
-uint32_t i;
-
-vmstate_load_state(f, _vmbus_chan_req, _save, 0);
-
-if (req_save.chan_idx >= dev->num_channels) {
-error_report("%s: %u(chan_idx) > %u(num_channels)", __func__,
- req_save.chan_idx, dev->num_channels);
-goto out;
-}
-chan = >channels[req_save.chan_idx];
-
-if (vmbus_channel_reserve(chan, 0, req_save.msglen)) {
-goto out;
-}
-
-req = vmbus_alloc_req(chan, size, req_save.pkt_type, req_save.msglen,
-  req_save.transaction_id, req_save.need_comp);
-if (req_save.msglen) {
-memcpy(req->msg, req_save.msg, req_save.msglen);
-}
-
-for (i = 0; i < req_save.num; i++) {
-qemu_sglist_add(>sgl, req_save.sgl[i].base, req_save.sgl[i].len);
-}
-
-out:
-if (req_save.msglen) {
-g_free(req_save.msg);
-}
-if (req_save.num) {
-g_free(req_save.sgl);
-}
-return req;
-}
-
 static void channel_event_cb(EventNotifier *e)
 {
 VMBusChannel *chan = container_of(e, VMBusChannel, notifier);
-- 
2.31.1

[PATCH v4 0/1] hw/hyperv/vmbus: Is it maintained?

This is the 4th time I send this patch. Is the VMBus infrastructure
used / maintained? Should we deprecate & remove?

  $ ./scripts/get_maintainer.pl -f hw/hyperv/vmbus.c -f 
include/hw/hyperv/vmbus.h
  get_maintainer.pl: No maintainers found

Philippe Mathieu-Daudé (1):
  hw/hyperv/vmbus: Remove unused vmbus_load/save_req()

 include/hw/hyperv/vmbus.h |  3 --
 hw/hyperv/vmbus.c | 59 ---
 2 files changed, 62 deletions(-)

-- 
2.31.1

Re: Qemu and ARM secure state.

2021-11-06 Thread Jean-Christophe DUBOIS

So it seems that what is needed is a way to choose on the command line
if we want to enable the Qemu built-in PSCI implementation (because we
are booting linux for example) or if we really want a bare metal
processor (because we are booting a trustedOS like optee).

The "virt" platform allows to dynamically choose one or the other. Other
platforms seems to need the same feature.

Le 06/11/2021 à 11:04, Jean-Christophe DUBOIS a écrit :

So, I am trying to understand:

Contrary to what I said, In my case the SMC instruction is not really
a "no-op" as it sets R0 to -1 (0x) to indicate an unknown PSCI
service (by the Qemu internal PSCI handler).

With the new code introduced by the "arm: tcg: Adhere to SMCCC 1.3
section 5.2" commit, once a processor/platform configure things to
have PSCI requests handled by Qemu code (with "psci-conduit" attribute
set to QEMU_PSCI_CONDUIT_SMC for example), then any exception raised
by an "SMC" instruction will be only handled by the Qemu internal code
and will no call the monitor related code in the guest/OS application.
This seems to be why my SMC monitor handler is not called anymore in
my case.

As my i.MX6UL is a mono-processor platform I don't really need to set
the "psci-conduit" attribute (which really makes sense when you have a
cluster of 2 or more cores I guess). As a matter of fact if I remove
the "psci-conduit" attribute setting from the i.MX6UL processor file,
my application is working again on main/latest.

But this still raises the question to know if the current behavior for
processors with "psci-conduit" set to SMC or HVC is correct. For
example an i.MX7 based platform (with up to 4 cortex A7 cores) would
not be able to trigger OS SMC handler as the exception would be
entirely processed by the Qemu internal code (with CR generally set to
-1 in R0 to indicate unknown PSCI request).

Is there something I am missing?

Regards

Le 04/11/2021 à 22:11, Jean-Christophe DUBOIS a écrit :

Le 04/11/2021 à 12:11, Peter Maydell a écrit :

On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS
wrote:

I have a little application that is designed to work on the i.MX6UL processor.

I developed it and tested it on the mcimx6ul-evk platform emulated by Qemu.

This application used to work "flawlessly" on Qemu 5.0.50 and is working on
Qemu 6.0.0 (available as a pre-built package on the latest Ubuntu).

But when I try to run the exact same command line on a Qemu version I compile
myself from main/latest of github (Qemu 6.1.50), my application fails to start.

So a little background:

My application expects to start in "secure" state and supervisor mode (which is
the default state of i.MX6UL when booting barebone [without u-boot]).

Could you try doing a bisect to find the QEMU commit that caused
your guest to stop working ?

OK, I did the bisect and the commit that break the i.MX6UL behavior
for my program is commit 9fcd15b9193e819b6cc2fd0a45e3506148812bb4
(arm: tcg: Adhere to SMCCC 1.3 section 5.2).

Before it the SMC instruction would trigger a monitor exception.

After it the SMC instruction is acting like a no-op.

Thanks

thanks
-- PMM

Re: [PATCH v4 1/2] vhost: Rename last_index to vq_index_end

Eugenio Pérez  wrote:
> The doc of this field pointed out that last_index is the last vq index.
> This is misleading, since it's actually one past the end of the vqs.
>
> Renaming and modifying comment.
>
> Signed-off-by: Eugenio Pérez 

Reviewed-by: Juan Quintela

Re: [PULL 07/20] migration/dirtyrate: implement dirty-ring dirtyrate calculation

Philippe Mathieu-Daudé  wrote:
> Hi Juan,
>
> On 11/1/21 23:08, Juan Quintela wrote:
>> From: Hyman Huang(é»„å‹‡) 
>> 
>> use dirty ring feature to implement dirtyrate calculation.
>> 
>> introduce mode option in qmp calc_dirty_rate to specify what
>> method should be used when calculating dirtyrate, either
>> page-sampling or dirty-ring should be passed.
>> 
>> introduce "dirty_ring:-r" option in hmp calc_dirty_rate to
>> indicate dirty ring method should be used for calculation.
>> 
>> Signed-off-by: Hyman Huang(é»„å‹‡) 
>
> Just noticing in the git history some commits from your
> pull request have the author name (from + S-o-b) mojibaked.

Didn't knew the term.

I noticed that after the fact.  Still have to debug *why* my setup
decided to break some of the patches and not the others.  Obviosly, I
have no clue about how to write/read/whatever anything that is not
latin1, so if something breaks, I got in a difficult place O:-)

Thanks, Juan.

>> <7db445109bd18125ce8ec86816d14f6ab5de6a7d.1624040308.git.huang...@chinatelecom.cn>
>> Reviewed-by: Peter Xu 
>> Reviewed-by: Juan Quintela 
>> Signed-off-by: Juan Quintela 
>> ---
>>  qapi/migration.json|  16 +++-
>>  migration/dirtyrate.c  | 208 +++--
>>  hmp-commands.hx|   7 +-
>>  migration/trace-events |   2 +
>>  4 files changed, 218 insertions(+), 15 deletions(-)

[PATCH v2] linux-user: Mark cpu_loop() with noreturn attribute

cpu_loop() never exits, so mark it with QEMU_NORETURN.

Reviewed-by: Richard Henderson 
Reviewed-By: Warner Losh 
Reviewed-by: Bin Meng 
Signed-off-by: Philippe Mathieu-Daudé 
---
v2:
- rebased
- restricted to linux-user

Supersedes: <20210905000429.1097336-1-f4...@amsat.org>
---
 linux-user/user-internals.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/user-internals.h b/linux-user/user-internals.h
index 661612a088b..c7ad00268af 100644
--- a/linux-user/user-internals.h
+++ b/linux-user/user-internals.h
@@ -65,7 +65,7 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 abi_long arg5, abi_long arg6, abi_long arg7,
 abi_long arg8);
 extern __thread CPUState *thread_cpu;
-void cpu_loop(CPUArchState *env);
+void QEMU_NORETURN cpu_loop(CPUArchState *env);
 const char *target_strerror(int err);
 int get_osversion(void);
 void init_qemu_uname_release(void);
-- 
2.31.1

Re: [PATCH v7 0/2] memory: Have 'info mtree' remove duplicated Address Space information

Ping?

On 9/5/21 01:10, Philippe Mathieu-Daudé wrote:
> Series fully reviewed.
> 
> Follow Peter Maydell suggestions:
> - Split mtree_info() as mtree_info_flatview() + mtree_info_as()
> - Remove duplicated Address Space information
> 
> Since v6:
> - Added missing vertical whitespace (rth)
> - Added rth's R-b
> 
> Since v5:
> - Fixed messed up during v3->v4 (peterx)
>   . Restore format
>   . Remove unused 'int counter'
> 
> Since v4:
> - Merged patches 1 & 2 (David)
> - Remove unnecessary return void (David)
> - Added David R-b
> 
> Since v3:
> - Fix typos
> - Split mtree_info_flatview() + mtree_info_as() first
> - Rebased last patch keeping Peter's R-b tag
> 
> Since v2:
> - Removed unused AddressSpaceInfo::counter
> 
> Since v1:
> - List AS similarly to 'info mtree -f' (peterx)
> 
> checkpatch warning (81 chars):
> 
>   WARNING: line over 80 characters
>   #86: FILE: softmmu/memory.c:3359:
>   +  address_space_compare_name);
> 
> Philippe Mathieu-Daudé (2):
>   memory: Split mtree_info() as mtree_info_flatview() + mtree_info_as()
>   memory: Have 'info mtree' remove duplicated Address Space information
> 
>  softmmu/memory.c | 150 ++-
>  1 file changed, 108 insertions(+), 42 deletions(-)
>

Re: [PATCH] docs: fix qemu incorrect tag

huang...@chinatelecom.cn wrote:
> From: Hyman Huang(黄勇) 
>
> The last modification of the patchset may be 2 month before
> merging dirtyrate implementation, it used the wrong tag, so
> fix with 6.2.
>
> Signed-off-by: Hyman Huang(黄勇) 

Reviewed-by: Juan Quintela 

queued.

Lei: a new tool for filtering patch series

2021-11-06 Thread Stefan Hajnoczi

Hi,
lore.kernel.org has been archiving qemu-devel for some time. You can use b4
(https://pypi.org/project/b4/) to easily apply patch series. Now there is a
new tool called lei that could be of interest to the QEMU community.

lei let's you query the mailing list for patch series that match queries
like specific filenames or functions touched by a patch. It keeps track of
patch series that you've already downloaded so you can see just the new
stuff.

Instead of adding "R:" entries to the MAINTAINERS file in qemu.git you can
now do that locally using lei.

I haven't tried it yet but it seems like a useful tool!

https://people.kernel.org/monsieuricon/lore-lei-part-1-getting-started

Stefan

[PATCH v2] tcg: Remove TCI experimental status

The following commits (released in v6.0.0) made raised the
quality of the TCI backend to the other TCG architectures,
thus is is not considerated experimental anymore:
- c6fbea47664..2f74f45e32b
- dc09f047edd..9e9acb7b348
- b6139eb0578..2fc6f16ca5e
- dbcbda2cd84..5e8892db93f

Signed-off-by: Philippe Mathieu-Daudé 
---
v2:
- rebase
- precise sysemu/user (Richard)

Supersedes: <20210920062306.2723797-1-f4...@amsat.org>
---
 docs/about/build-platforms.rst | 10 ++
 meson.build|  4 ++--
 meson_options.txt  |  2 +-
 scripts/meson-buildoptions.sh  |  3 +--
 4 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/docs/about/build-platforms.rst b/docs/about/build-platforms.rst
index bcb15497213..c29a4b8fe64 100644
--- a/docs/about/build-platforms.rst
+++ b/docs/about/build-platforms.rst
@@ -54,10 +54,12 @@ Those hosts are officially supported, with various 
accelerators:
* - x86
  - hax, hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
 
-Other host architectures are not supported. It is possible to build QEMU on an
-unsupported host architecture using the configure ``--enable-tcg-interpreter``
-option to enable the experimental TCI support, but note that this is very slow
-and is not recommended.
+Other host architectures are not supported. It is possible to build QEMU system
+emulation on an unsupported host architecture using the configure
+``--enable-tcg-interpreter`` option to enable the TCI support, but note that
+this is very slow and is not recommended for normal use. QEMU user emulation
+requires host-specific support for signal handling, therefore TCI won't help
+on unsupported host architectures.
 
 Non-supported architectures may be removed in the future following the
 :ref:`deprecation process`.
diff --git a/meson.build b/meson.build
index 47df10afc21..16de7103d69 100644
--- a/meson.build
+++ b/meson.build
@@ -331,7 +331,7 @@
 if not get_option('tcg').disabled()
   if cpu not in supported_cpus
 if get_option('tcg_interpreter')
-  warning('Unsupported CPU @0@, will use TCG with TCI (experimental and 
slow)'.format(cpu))
+  warning('Unsupported CPU @0@, will use TCG with TCI (slow)'.format(cpu))
 else
   error('Unsupported CPU @0@, try --enable-tcg-interpreter'.format(cpu))
 endif
@@ -3286,7 +3286,7 @@
 summary_info += {'TCG support':   config_all.has_key('CONFIG_TCG')}
 if config_all.has_key('CONFIG_TCG')
   if get_option('tcg_interpreter')
-summary_info += {'TCG backend':   'TCI (TCG with bytecode interpreter, 
experimental and slow)'}
+summary_info += {'TCG backend':   'TCI (TCG with bytecode interpreter, 
slow)'}
   else
 summary_info += {'TCG backend':   'native (@0@)'.format(cpu)}
   endif
diff --git a/meson_options.txt b/meson_options.txt
index e740dce2a51..411952bc91a 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -59,7 +59,7 @@ option('xen_pci_passthrough', type: 'feature', value: 'auto',
 option('tcg', type: 'feature', value: 'auto',
description: 'TCG support')
 option('tcg_interpreter', type: 'boolean', value: false,
-   description: 'TCG with bytecode interpreter (experimental and slow)')
+   description: 'TCG with bytecode interpreter (slow)')
 option('cfi', type: 'boolean', value: 'false',
description: 'Control-Flow Integrity (CFI)')
 option('cfi_debug', type: 'boolean', value: 'false',
diff --git a/scripts/meson-buildoptions.sh b/scripts/meson-buildoptions.sh
index 55b8a785600..45e1f2e20da 100644
--- a/scripts/meson-buildoptions.sh
+++ b/scripts/meson-buildoptions.sh
@@ -13,8 +13,7 @@ meson_options_help() {
   printf "%s\n" '   jemalloc/system/tcmalloc)'
   printf "%s\n" '  --enable-slirp[=CHOICE]  Whether and how to find the slirp 
library'
   printf "%s\n" '   (choices: 
auto/disabled/enabled/internal/system)'
-  printf "%s\n" '  --enable-tcg-interpreter TCG with bytecode interpreter 
(experimental and'
-  printf "%s\n" '   slow)'
+  printf "%s\n" '  --enable-tcg-interpreter TCG with bytecode interpreter 
(slow)'
   printf "%s\n" '  --enable-trace-backends=CHOICE'
   printf "%s\n" '   Set available tracing backends 
[log] (choices:'
   printf "%s\n" '   
dtrace/ftrace/log/nop/simple/syslog/ust)'
-- 
2.31.1

[PATCH] hw/timer/etraxfs_timer: Add vmstate for ETRAX timers

Add the vmstate for the ETRAX timers.
This is in theory a migration compatibility break
for the 'AXIS devboard 88' CRIS machine.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/timer/etraxfs_timer.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/hw/timer/etraxfs_timer.c b/hw/timer/etraxfs_timer.c
index 4ba662190de..139e5b86a44 100644
--- a/hw/timer/etraxfs_timer.c
+++ b/hw/timer/etraxfs_timer.c
@@ -26,6 +26,7 @@
 #include "hw/sysbus.h"
 #include "sysemu/reset.h"
 #include "sysemu/runstate.h"
+#include "migration/vmstate.h"
 #include "qemu/module.h"
 #include "qemu/timer.h"
 #include "hw/irq.h"
@@ -64,7 +65,7 @@ struct ETRAXTimerState {
 ptimer_state *ptimer_t1;
 ptimer_state *ptimer_wd;
 
-int wd_hits;
+uint32_t wd_hits;
 
 /* Control registers.  */
 uint32_t rw_tmr0_div;
@@ -83,6 +84,36 @@ struct ETRAXTimerState {
 uint32_t r_masked_intr;
 };
 
+static const VMStateDescription vmstate_etraxfs = {
+.name = "etraxfs",
+.version_id = 0,
+.minimum_version_id = 0,
+.fields = (VMStateField[]) {
+VMSTATE_PTIMER(ptimer_t0, ETRAXTimerState),
+VMSTATE_PTIMER(ptimer_t1, ETRAXTimerState),
+VMSTATE_PTIMER(ptimer_wd, ETRAXTimerState),
+
+VMSTATE_UINT32(wd_hits, ETRAXTimerState),
+
+VMSTATE_UINT32(rw_tmr0_div, ETRAXTimerState),
+VMSTATE_UINT32(r_tmr0_data, ETRAXTimerState),
+VMSTATE_UINT32(rw_tmr0_ctrl, ETRAXTimerState),
+
+VMSTATE_UINT32(rw_tmr1_div, ETRAXTimerState),
+VMSTATE_UINT32(r_tmr1_data, ETRAXTimerState),
+VMSTATE_UINT32(rw_tmr1_ctrl, ETRAXTimerState),
+
+VMSTATE_UINT32(rw_wd_ctrl, ETRAXTimerState),
+
+VMSTATE_UINT32(rw_intr_mask, ETRAXTimerState),
+VMSTATE_UINT32(rw_ack_intr, ETRAXTimerState),
+VMSTATE_UINT32(r_intr, ETRAXTimerState),
+VMSTATE_UINT32(r_masked_intr, ETRAXTimerState),
+
+VMSTATE_END_OF_LIST()
+}
+};
+
 static uint64_t
 timer_read(void *opaque, hwaddr addr, unsigned int size)
 {
@@ -357,6 +388,7 @@ static void etraxfs_timer_class_init(ObjectClass *klass, 
void *data)
 ResettableClass *rc = RESETTABLE_CLASS(klass);
 
 dc->realize = etraxfs_timer_realize;
+dc->vmsd = _etraxfs;
 rc->phases.enter = etraxfs_timer_reset_enter;
 rc->phases.hold = etraxfs_timer_reset_hold;
 }
-- 
2.31.1

Emulation of solo key

2021-11-06 Thread Niraj Sorathiya

Hello Team,

I really need your suggestions on how I should proceed to build a Solo key
emulator ?  Since I am new to QEMU  , I would like to know how I should do
planing before getting into technical of QEMU

Please find all information about solo key below:

Docs: https://docs.solokeys.io/solo/building/
Firmware: https://github.com/solokeys/solo/
Hardware: https://github.com/solokeys/solo-hw


-- 


Best Regards,
Niraj

Re: Qemu and ARM secure state.

2021-11-06 Thread Jean-Christophe DUBOIS

So, I am trying to understand:

Contrary to what I said, In my case the SMC instruction is not really a
"no-op" as it sets R0 to -1 (0x) to indicate an unknown PSCI
service (by the Qemu internal PSCI handler).

With the new code introduced by the "arm: tcg: Adhere to SMCCC 1.3
section 5.2" commit, once a processor/platform configure things to have
PSCI requests handled by Qemu code (with "psci-conduit" attribute set to
QEMU_PSCI_CONDUIT_SMC for example), then any exception raised by an
"SMC" instruction will be only handled by the Qemu internal code and
will no call the monitor related code in the guest/OS application. This
seems to be why my SMC monitor handler is not called anymore in my case.

As my i.MX6UL is a mono-processor platform I don't really need to set
the "psci-conduit" attribute (which really makes sense when you have a
cluster of 2 or more cores I guess). As a matter of fact if I remove the
"psci-conduit" attribute setting from the i.MX6UL processor file, my
application is working again on main/latest.

But this still raises the question to know if the current behavior for
processors with "psci-conduit" set to SMC or HVC is correct. For example
an i.MX7 based platform (with up to 4 cortex A7 cores) would not be able
to trigger OS SMC handler as the exception would be entirely processed
by the Qemu internal code (with CR generally set to -1 in R0 to indicate
unknown PSCI request).

Is there something I am missing?

Regards

Le 04/11/2021 à 22:11, Jean-Christophe DUBOIS a écrit :

Le 04/11/2021 à 12:11, Peter Maydell a écrit :

On Wed, 3 Nov 2021 at 13:27, Jean-Christophe DUBOIS
wrote:

I have a little application that is designed to work on the i.MX6UL processor.

I developed it and tested it on the mcimx6ul-evk platform emulated by Qemu.

This application used to work "flawlessly" on Qemu 5.0.50 and is working on
Qemu 6.0.0 (available as a pre-built package on the latest Ubuntu).

But when I try to run the exact same command line on a Qemu version I compile
myself from main/latest of github (Qemu 6.1.50), my application fails to start.

So a little background:

My application expects to start in "secure" state and supervisor mode (which is
the default state of i.MX6UL when booting barebone [without u-boot]).

Could you try doing a bisect to find the QEMU commit that caused
your guest to stop working ?

OK, I did the bisect and the commit that break the i.MX6UL behavior
for my program is commit 9fcd15b9193e819b6cc2fd0a45e3506148812bb4
(arm: tcg: Adhere to SMCCC 1.3 section 5.2).

Before it the SMC instruction would trigger a monitor exception.

After it the SMC instruction is acting like a no-op.

Thanks

thanks
-- PMM

Re: [PATCH] target/ppc, hw/ppc: Change maintainers

On 11/6/21 00:00, Cédric Le Goater wrote:
>> In term of the MAINTAINERS file:
>>
>>  S: Status, one of the following:
>>     Supported:   Someone is actually paid to look after this.
>>     Maintained:  Someone actually looks after it.
>>
>> The PPC entries have a 'Maintained' status. You say "IBM will shoulder
>> this responsibility", does that mean the entries will be 'Supported'
>> as in "someone paid to look after them"?
>> I wonder because both Cédric and you have some commits with an IBM
>> email, but both are registering a non-IBM email as contact. 
> 
> Lotus Notes was not designed for patch communication. You don't want
> me to send patches with it I assure you :)
> 
>> I don't
>> mind the email technical detail, but I am curious about the status
>> and expectations.
> 
> We have other IBM commitments. IBM is willing to share some/most of
> our time for QEMU-PPC maintenance.
> 
> What we are going do will depend on inputs really. We have pseries
> and KVM in focus because there is still business using the software
> stack. TCG is extremely useful for pseries and powernv. We clearly
> want to keep that running and improve it. Some parts have been barely
> touched (and probably used) in the last 15 years. I think we should
> drop some support to modernize the useful parts and ease maintenance.

Here let me recommend the ant work approach I'm doing for MIPS. Instead
of dropping ISA extensions, I'm splitting them in various compile units,
that way 1/ we can chose to build without them and 2/ sub-maintainers
can maintain them separately. Having a finer grained MAINTAINERS
entries allow to filter-out/in and reduce reviewers pressure.

Re: [PATCH] target/ppc, hw/ppc: Change maintainers

On 11/5/21 21:05, Daniel Henrique Barboza wrote:
> On 11/5/21 16:16, Philippe Mathieu-Daudé wrote:
>> Hi Daniel,
>>
>> On 11/5/21 10:48, Daniel Henrique Barboza wrote:
>>> On 11/5/21 00:46, David Gibson wrote:
 As our day jobs and interests have moved onto other things, Greg and I
 have
 been struggling to keep on top of maintainership of target/ppc and
 associated pieces like the pseries and powernv machine types, with
 their
 platform specific devices.

 We've therefore discussed and plan to transfer maintainership to
 Cédric Le
 Goater (primary) and Daniel Henrique Barboza (backup).  Cédric and
 Daniel
 have been actively contributing to the area for some time, and they're
 supported in this by their current employer, IBM, who has an obvious
 interest in the platform.
>>>
>>> Thank you and Greg and Red Hat for all the years of service supporting
>>> qemu-ppc in the community. IBM will shoulder this responsibility now.
>>
>> In term of the MAINTAINERS file:
>>
>>  S: Status, one of the following:
>>     Supported:   Someone is actually paid to look after this.
>>     Maintained:  Someone actually looks after it.
>>
>> The PPC entries have a 'Maintained' status. You say "IBM will shoulder
>> this responsibility", does that mean the entries will be 'Supported'
>> as in "someone paid to look after them"?
> 
> Yes. It's appropriate to change the PPC entries of this patch to
> "Supported"
> now.

This is a great news :)

>> I wonder because both Cédric and you have some commits with an IBM
>> email, but both are registering a non-IBM email as contact. I don't
>> mind the email technical detail, but I am curious about the status
>> and expectations.
> 
> I had problems using IBM corporate email with mailing lists in the past,
> and started using this gmail account instead. I believe Cedric has a
> similar sob story.
> 
> FWIW the contrib/gitdm/group-map-ibm file has both our emails there to
> indicate that we're IBM contributors.

OK this is how I understood it first then. Thanks for the clarification.

Regards,

Phil.

[PATCH] tests/avocado: Remove p7zip binary availability check

The single use of the 7z binary has been removed in commit a30e114f3
("tests/acceptance: remove Armbian 19.11.3 test for orangepi-pc"),
we don't need to check for this binary availability anymore.

Signed-off-by: Philippe Mathieu-Daudé 
---
Based-on: <20211105155354.154864-1-willi...@redhat.com>
---
 tests/avocado/boot_linux_console.py | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/tests/avocado/boot_linux_console.py 
b/tests/avocado/boot_linux_console.py
index 4ed01ed7893..9c618d4809f 100644
--- a/tests/avocado/boot_linux_console.py
+++ b/tests/avocado/boot_linux_console.py
@@ -22,13 +22,6 @@
 from avocado_qemu import wait_for_console_pattern
 from avocado.utils import process
 from avocado.utils import archive
-from avocado.utils.path import find_command, CmdNotFoundError
-
-P7ZIP_AVAILABLE = True
-try:
-find_command('7z')
-except CmdNotFoundError:
-P7ZIP_AVAILABLE = False
 
 """
 Round up to next power of 2
-- 
2.31.1

Re: [PATCH] target/ppc, hw/ppc: Change maintainers

2021-11-06 Thread David Gibson

On Sat, Nov 06, 2021 at 09:28:54AM +0100, Cédric Le Goater wrote:
> > > > > Thank you and Greg and Red Hat for all the years of service supporting
> > > > > qemu-ppc in the community. IBM will shoulder this responsibility now.
> > > > 
> > > > In term of the MAINTAINERS file:
> > > > 
> > > >   S: Status, one of the following:
> > > >  Supported:   Someone is actually paid to look after this.
> > > >  Maintained:  Someone actually looks after it.
> > > > 
> > > > The PPC entries have a 'Maintained' status. You say "IBM will shoulder
> > > > this responsibility", does that mean the entries will be 'Supported'
> > > > as in "someone paid to look after them"?
> > > 
> > > Yes. It's appropriate to change the PPC entries of this patch to 
> > > "Supported"
> > > now.
> > 
> > Good point, I've adjusted that.
> 
> "Supported" would be setting the expectations too high. It is an extra
> activity among what we are already dealing with. Please leave it to
> "Maintained".

Fair enough, reverted.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH] target/ppc, hw/ppc: Change maintainers

2021-11-06 Thread Cédric Le Goater


Thank you and Greg and Red Hat for all the years of service supporting
qemu-ppc in the community. IBM will shoulder this responsibility now.


In term of the MAINTAINERS file:

  S: Status, one of the following:
 Supported:   Someone is actually paid to look after this.
 Maintained:  Someone actually looks after it.

The PPC entries have a 'Maintained' status. You say "IBM will shoulder
this responsibility", does that mean the entries will be 'Supported'
as in "someone paid to look after them"?


Yes. It's appropriate to change the PPC entries of this patch to "Supported"
now.


Good point, I've adjusted that.


"Supported" would be setting the expectations too high. It is an extra
activity among what we are already dealing with. Please leave it to
"Maintained".

Thanks,

C.

Re: Artificially target-dependend compiles

Paolo Bonzini  writes:

> On 11/5/21 14:45, Markus Armbruster wrote:
>> Moving these definitions to machine-target.json moves the generated C
>> from qapi/qapi-*-machine.[ch] to qapi/qapi-*-machine-target.[ch], where
>> CONFIG_ACPI_VMGENID is okay.  It also makes qmp_query_vm_generation_id()
>> target-dependent: it needs qapi/qapi-commands-machine-target.h.
>
> If I understand correctly, the problem that
> qapi-commands-machine-target.h is target-dependent, because it uses 
> "#ifdef CONFIG_ACPI_VMGENID" around the prototype?

Around the prototype and struct GuidInfo.

> On one hand, the "#ifdef" is unnecessary: the prototype does not
> depend on anything target-specific.  Removing it will avoid the 
> target-dependence.  On the other hand, the "#ifdef" has a defensive
> purpose, in that an unnecessary definition (such as the one currently
> in the stub) will fail due to the implicit definition of 
> qmp_query_vm_generation_id().

Also, it immediately flags uses of qmp_query_vm_generation_id() and
struct GuidInfo.  Without it, the linker still catches most, but not all
uses.

>> Have you seen similar artificial target-dependence elsewhere?
>
> I can't think of a specific example, but it does ring some bells.

I just ran into an instance that may be clearer.

The "rocker" device is target-independent (hw/net/meson.build adds it to
softmmu_ss), but linked only for selected targets (hw/net/Kconfig has
depends on PCI && MSI_NONBROKEN).

This makes our build machinery put CONFIG_ROCKER in
$TARGET-softmmu-config-devices.h, and poison it in config-poison.h.
Feels uncalled for.

Re: [PATCH v4 6/7] hw/nvram: Update at24c EEPROM init function in NPCM7xx boards

Hao Wu  writes:

> We made 3 changes to the at24c_eeprom_init function in
> npcm7xx_boards.c:
>
> 1. We allow the function to take a I2CBus* as parameter. This allows
>us to attach an EEPROM device behind an I2C mux which is not
>possible with the old method.
>
> 2. We make at24c EEPROMs are backed by drives so that we can
>specify the content of the EEPROMs.
>
> 3. Instead of using i2c address as unit number, This patch assigns
>unique unit numbers for each eeproms in each board. This avoids
>conflict in providing multiple eeprom contents with the same address.
>In the old method if we specify two drives with the same unit number,
>the following error will occur: `Device with id 'none85' exists`.

When a commit does three things, chances are splitting it into three
commits would be an improvement.  This is *not* a demand.

>
> Signed-off-by: Hao Wu 
> ---
>  hw/arm/npcm7xx_boards.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/hw/arm/npcm7xx_boards.c b/hw/arm/npcm7xx_boards.c
> index dec7d16ae5..9121e081fa 100644
> --- a/hw/arm/npcm7xx_boards.c
> +++ b/hw/arm/npcm7xx_boards.c
> @@ -126,13 +126,17 @@ static I2CBus *npcm7xx_i2c_get_bus(NPCM7xxState *soc, 
> uint32_t num)
>  return I2C_BUS(qdev_get_child_bus(DEVICE(>smbus[num]), "i2c-bus"));
>  }
>  
> -static void at24c_eeprom_init(NPCM7xxState *soc, int bus, uint8_t addr,
> -  uint32_t rsize)
> +static void at24c_eeprom_init(I2CBus *i2c_bus, int bus, uint8_t addr,
> +  uint32_t rsize, int unit_number)

I'd keep bus and unit number together.

I'd name the new parameter @unit, to match drive_get().

>  {
> -I2CBus *i2c_bus = npcm7xx_i2c_get_bus(soc, bus);
>  I2CSlave *i2c_dev = i2c_slave_new("at24c-eeprom", addr);
>  DeviceState *dev = DEVICE(i2c_dev);
> +DriveInfo *dinfo;
>  
> +dinfo = drive_get(IF_OTHER, bus, unit_number);
> +if (dinfo) {
> +qdev_prop_set_drive(dev, "drive", blk_by_legacy_dinfo(dinfo));
> +}
>  qdev_prop_set_uint32(dev, "rom-size", rsize);
>  i2c_slave_realize_and_unref(i2c_dev, i2c_bus, _abort);
>  }
> @@ -239,8 +243,8 @@ static void quanta_gsj_i2c_init(NPCM7xxState *soc)
>  i2c_slave_create_simple(npcm7xx_i2c_get_bus(soc, 3), "tmp105", 0x5c);
>  i2c_slave_create_simple(npcm7xx_i2c_get_bus(soc, 4), "tmp105", 0x5c);
>  
> -at24c_eeprom_init(soc, 9, 0x55, 8192);
> -at24c_eeprom_init(soc, 10, 0x55, 8192);
> +at24c_eeprom_init(npcm7xx_i2c_get_bus(soc, 9), 9, 0x55, 8192, 0);
> +at24c_eeprom_init(npcm7xx_i2c_get_bus(soc, 10), 10, 0x55, 8192, 1);
>  
>  /*
>   * i2c-11:

Re: [PATCH v4 5/7] blockdev: Add a new IF type IF_OTHER

Hao Wu  writes:

> This type is used to represent block devs that are not suitable to
> be represented by other existing types.

Hinting at intended use wouldn't hurt: ", such as "

>
> Signed-of-by: Hao Wu 
> ---
>  blockdev.c| 3 ++-
>  include/sysemu/blockdev.h | 1 +
>  meson | 2 +-
>  3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/blockdev.c b/blockdev.c
> index b35072644e..c26cbcc422 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -80,6 +80,7 @@ static const char *const if_name[IF_COUNT] = {
>  [IF_MTD] = "mtd",
>  [IF_SD] = "sd",
>  [IF_VIRTIO] = "virtio",
> +[IF_OTHER] = "other",
>  [IF_XEN] = "xen",
>  };
>  
> @@ -739,7 +740,7 @@ QemuOptsList qemu_legacy_drive_opts = {
>  },{
>  .name = "if",
>  .type = QEMU_OPT_STRING,
> -.help = "interface (ide, scsi, sd, mtd, floppy, pflash, virtio)",
> +.help = "interface (ide, scsi, sd, mtd, floppy, pflash, virtio, 
> other)",
>  },{
>  .name = "file",
>  .type = QEMU_OPT_STRING,
> diff --git a/include/sysemu/blockdev.h b/include/sysemu/blockdev.h
> index 32c2d6023c..bce6aab573 100644
> --- a/include/sysemu/blockdev.h
> +++ b/include/sysemu/blockdev.h
> @@ -24,6 +24,7 @@ typedef enum {
>   */
>  IF_NONE = 0,
>  IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
> +IF_OTHER,
>  IF_COUNT
>  } BlockInterfaceType;
>  
> diff --git a/meson b/meson
> index b25d94e7c7..776acd2a80 16
> --- a/meson
> +++ b/meson
> @@ -1 +1 @@
> -Subproject commit b25d94e7c77fda05a7fdfe8afe562cf9760d69da
> +Subproject commit 776acd2a805c9b42b4f0375150977df42130317f

Oopsie :)

Re: [PATCH v3 03/12] vfio-user: define vfio-user-server object