Re: Let's remove some deprecated stuff

[Alistair Francis]

On Mon, May 3, 2021 at 2:49 PM Thomas Huth  wrote:
>
> On 03/05/2021 03.41, Alistair Francis wrote:
> > On Thu, Apr 29, 2021 at 8:00 PM Markus Armbruster  wrote:
> >>
> >> If you're cc'ed, you added a section to docs/system/deprecated.rst that
> >> is old enough to permit removal.  This is *not* a demand to remove, it's
> >> a polite request to consider whether the time for removal has come.
> >> Extra points for telling us in a reply.  "We should remove, but I can't
> >> do it myself right now" is a valid answer.  Let's review the file:
> >>
> >>  System emulator command line arguments
> >>  --
> >>
> >> Kővágó, Zoltán:
> >>
> >>  ``QEMU_AUDIO_`` environment variables and ``-audio-help`` (since 4.0)
> >>  '
> >>
> >>  The ``-audiodev`` argument is now the preferred way to specify audio
> >>  backend settings instead of environment variables.  To ease migration 
> >> to
> >>  the new format, the ``-audiodev-help`` option can be used to convert
> >>  the current values of the environment variables to ``-audiodev`` 
> >> options.
> >>
> >> Kővágó, Zoltán:
> >>
> >>  Creating sound card devices and vnc without ``audiodev=`` property 
> >> (since 4.2)
> >>  
> >> ''
> >>
> >>  When not using the deprecated legacy audio config, each sound card
> >>  should specify an ``audiodev=`` property.  Additionally, when using
> >>  vnc, you should specify an ``audiodev=`` property if you plan to
> >>  transmit audio through the VNC protocol.
> >>
> >> Gerd Hoffmann:
> >>
> >>  Creating sound card devices using ``-soundhw`` (since 5.1)
> >>  ''
> >>
> >>  Sound card devices should be created using ``-device`` instead.  The
> >>  names are the same for most devices.  The exceptions are ``hda`` which
> >>  needs two devices (``-device intel-hda -device hda-duplex``) and
> >>  ``pcspk`` which can be activated using ``-machine
> >>  pcspk-audiodev=``.
> >>
> >> [...]
> >>
> >> Alistair Francis:
> >>
> >>  RISC-V ``-bios`` (since 5.1)
> >>  
> >>
> >>  QEMU 4.1 introduced support for the -bios option in QEMU for RISC-V 
> >> for the
> >>  RISC-V virt machine and sifive_u machine. QEMU 4.1 had no changes to 
> >> the
> >>  default behaviour to avoid breakages.
> >>
> >>  QEMU 5.1 changes the default behaviour from ``-bios none`` to ``-bios 
> >> default``.
> >>
> >>  QEMU 5.1 has three options:
> >>   1. ``-bios default`` - This is the current default behavior if no 
> >> -bios option
> >>is included. This option will load the default OpenSBI firmware 
> >> automatically.
> >>The firmware is included with the QEMU release and no user 
> >> interaction is
> >>required. All a user needs to do is specify the kernel they 
> >> want to boot
> >>with the -kernel option
> >>   2. ``-bios none`` - QEMU will not automatically load any firmware. 
> >> It is up
> >>to the user to load all the images they need.
> >>   3. ``-bios `` - Tells QEMU to load the specified file as the 
> >> firmwrae.
> >>
> >
> > This has already been acted upon in the code, we now default to
> > including a "bios" with RISC-V softmmu which is what this is
> > describing.
> >
> > Do we need to take any action to indicate that it's already in effect?
>
> deprecated.rst is mainly thought for the things that only have been marked
> as deprecated, but not changed yet. Once it's done, the items normally get
> moved to docs/system/removed-features.rst instead.

Too easy, I'll move it there instead.

Alistair

>
>   Thomas
>

Re: [Bug 1925496] Re: nvme disk cannot be hotplugged after removal

[Klaus Jensen]

On Apr 28 15:00, Max Reitz wrote:

On 28.04.21 12:12, Klaus Jensen wrote:

On Apr 28 09:31, Oguz Bektas wrote:

My understanding is that this is the expected behavior. The reason is
that the drive cannot be deleted immediately when the device is
hot-unplugged, since it might not be safe (other parts of QEMU could
be using it, like background block jobs).

On the other hand, the fact that if the drive is removed explicitly
through QMP (or in the monitor with drive_del), the drive id is
remains "in use". This might be a completely different bug that is
unrelated to the nvme device.


using the same commands I can hot-plug and hot-unplug a scsi disk like
this without issue - this behavior only appeared on nvme devices.



Kevin, Max, can you shed any light on this?

Specifically what the expected behavior is wrt. to the drive when 
unplugging a device that has one attached?


If the scsi disk is capable of "cleaning up" immediately, then I 
suppose that some steps are missing in the nvme unrealization.




Hi Max,

Thanks for your help!

I’m not very strong when it comes to question for guest devices, but 
looking into the QAPI documentation, it says that when DEVICE_DELETED 
is emitted, it’s safe to reuse the device ID.  Before then, it isn’t, 
because the guest may yet need to release the device.




This is specifically related to releasing the "drive", not the device. 
Problem is that when the device is deleted (using device_del), the pci 
device goes away rapidly, but the drive (as shown in `info block`) 
lingers for a couple of seconds before going into the "unlocked" state. 

If the drive is then deleted (`drive_del`) everything is good, but if 
the drive is deleted within those couple of seconds, the drive_del 
completes successfully, but the drive id never becomes available again.



So the questions that come to my mind are:
- Do nvme guest devices have a release protocol with the guest, so 
that it just may take some time for the guest to release the device?  
I.e. that this would be perfectly normal and documented behavior?
(Perhaps this just isn’t the case for scsi, or the guest just releases 
those devices much quicker)




The NVMe device is a PCIDevice, I wonder if that is what adds some delay 
on this?


- Did Oguz always wait for the DEVICE_DELETED event before reusing the 
ID?  Sounds like it would be a bug if reusing the ID after getting 
that event failed.




From the bug report, it does not look like anything like that is done.

I basically dont understand the deletion protocol here and why the drive 
is not released immediately. Even if I add a call to 
blockdev_mark_auto_del() there is a delay, but the drive does get 
automatically deleted.


signature.asc
Description: PGP signature

Re: [PATCH 1/4] pc-bios/s390-ccw: Silence warning from Clang by marking panic() as noreturn

[Philippe Mathieu-Daudé]

On 5/3/21 6:53 AM, Thomas Huth wrote:
> On 02/05/2021 20.57, Philippe Mathieu-Daudé wrote:
>> On 5/2/21 7:48 PM, Thomas Huth wrote:
>>> When compiling the s390-ccw bios with Clang, the compiler emits a
>>> warning:
>>>
>>>   pc-bios/s390-ccw/main.c:210:5: warning: variable 'found' is used
>>> uninitialized
>>>    whenever switch default is taken [-Wsometimes-uninitialized]
>>>   default:
>>>   ^~~
>>>   pc-bios/s390-ccw/main.c:214:16: note: uninitialized use occurs here
>>>   IPL_assert(found, "Boot device not found\n");
>>>  ^
>>>
>>> It's a false positive, it only happens because Clang is not smart enough
>>> to see that the panic() function in the "default:" case can never
>>> return.
>>>
>>> Anyway, let's explicitely mark panic() with "noreturn" to shut up the
>>> warning.
>>
>> Why not simply initialize the variable instead?
> 
> First, it's a false positive. If you only look at the code, someone
> might later wonder whether it's really necessary or not and try to
> remove it again (and since there is no warning with gcc, this patch
> would also have a good chance to get merged, bringing us back to where
> we are right now).
> 
> Second, declaring panic() as noreturn is certainly more sustainable,
> since it might prevent similar situations in other parts of the code in
> the future.

Fine then:
Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[David Hildenbrand]

On 03.05.21 07:17, Thomas Huth wrote:

On 03/05/2021 06.58, Markus Armbruster wrote:

Thomas Huth  writes:


Clang unfortunately does not support generating code for the z900
architecture level and starts with the z10 instead. Thus to be able
to support compiling with Clang, we have to check for the supported
compiler flags. The disadvantage is of course that the bios image
will only run with z10 guest CPUs upwards (which is what most people
use anyway), so just in case let's also emit a warning in that case.


What happens when you try to use this bios with an old CPU anyway?


Interesting question. I was expecting the guest to crash since it would be
using a CPU instruction that is not supported on the old CPU model. But I
just gave it a try, and there was no crash. The guest booted just fine.
Either Clang only emits instructions that work with the old z900 anyway, or
our emulation in QEMU is imprecise and we allow newer instructions to be
executed on old models, too.


Yes, that's currently still done. We once thought about disabling that 
(there was a patch from Richard), but decided against it because -- back 
then -- the default QEMU model was still very basic and would have 
essentially disabled all more recent instructions as default.


We can most probably do that change soon as we have a "fairly new" 
default QEMU CPU model. I can glue it to my z14 change.

[Bug 1920752] Re: USB SoundCard Passthrough not working on arm64

[Ravishankar]

One more point. The solution above is not usb passthrough.
I just noticed that qemu needs to be configured for usb passthrough. I am 
trying that out now

Configure with --enable-libusb
  libusb  libusb (for usb passthrough)

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1920752

Title:
  USB SoundCard Passthrough not working on arm64

Status in QEMU:
  New

Bug description:
  Hello,

  I am virtualizing a armhf guest on a aarch64 host and was to use my
  Sound Blaster USB Soundcard as passthrough.

  armhf Guest is: Debian Buster 
  aarch64 host is a jetson nano. KVM is enabled.

  Latest qemu is built from sources.
  The command I use for running is as follows:

  ../qemu/build/qemu-system-aarch64 -M virt -m 2048 -smp 2 -cpu 
host,aarch64=off -enable-kvm  \
  -kernel vmlinuz-4.19.0-14-armmp-lpae  -initrd initrd.img-4.19.0-14-armmp-lpae 
-append 'root=/dev/vda2' \
  -device nec-usb-xhci -device usb-kbd  -device usb-mouse -device 
usb-host,hostbus=1,hostport=2.3  -serial stdio  \
  -device virtio-gpu-pci,virgl=on,xres=1600,yres=900 -display sdl,gl=on \
  -drive if=none,file=hda2.qcow2,format=qcow2,id=hd   -device 
virtio-blk-device,drive=hd   \
  -netdev user,id=mynet   -device virtio-net-device,netdev=mynet \
  -bios edk2-arm-code.fd -no-reboot

  
  Where are my lsusb -t shows:

  rreddy78@jetson-nano:~/Downloads$ lsusb -t
  /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/4p, 5000M
  |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
  /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=tegra-xusb/5p, 480M
  |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
  |__ Port 1: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 
1.5M
  |__ Port 1: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 
1.5M
  |__ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid, 
12M
  |__ Port 3: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
  |__ Port 3: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
  |__ Port 3: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
  |__ Port 4: Dev 9, If 0, Class=Human Interface Device, Driver=usbhid, 
1.5M

  Within the VM I can see the usb as follows

  rreddy78@debian:~$ lsusb -t
  /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
  /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
  |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M
  |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 480M

  
  Its looks like some passthrough as but it seems like only for

   _ Port 3: Dev 8, If 3, Class=Human Interface Device, Driver=usbhid,
  12M

  I am not sure if passthrough  even works because this post I saw

  https://community.arm.com/developer/ip-products/system/f/embedded-
  forum/48031/usb-pass-through-in-qemu-command-line-for-arm-
  machines/168764#168764

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1920752/+subscriptions

Re: [PATCH] block: simplify write-threshold and drop write notifiers

[Vladimir Sementsov-Ogievskiy]

30.04.2021 13:04, Max Reitz wrote:

On 22.04.21 00:09, Vladimir Sementsov-Ogievskiy wrote:

write-notifiers are used only for write-threshold. New code for such
purpose should create filters.

Let's handle write-threshold simply in generic code and drop write
notifiers at all.

Also move part of write-threshold API that is used only for testing to
the test.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
---

I agree that this could be split into 2-3 parts and not combining
everything into one. But I'm tired now.


Er...  You should have put it off until the next day then? O:)


Yes, sorry. I wanted to send that day... Don't remember why :) Checked now, 
that was not Friday.. I wanted to drop write notifiers long ago, and when I 
finally do it I couldn't wait, so cool it seemed to me :)

Thanks for comments, I'll send v2 soon.



It should be multiple patches.  At least one to move the write threshold update 
to block/io.c, and then another to drop write notifiers.


I can send v2 if needed, so
consider it as RFC. Or take as is if you think it's not too much-in-one.

I also suggest this as a prepartion (and partly substitution) for
"[PATCH v2 0/8] Block layer thread-safety, continued"

  include/block/block_int.h | 12 -
  include/block/write-threshold.h   | 24 -
  block.c   |  1 -
  block/io.c    | 21 +---
  block/write-threshold.c   | 87 ++-
  tests/unit/test-write-threshold.c | 38 ++
  6 files changed, 54 insertions(+), 129 deletions(-)


[...]


diff --git a/block/io.c b/block/io.c
index ca2dca3007..e0aa775952 100644
--- a/block/io.c
+++ b/block/io.c
@@ -36,6 +36,8 @@
  #include "qemu/main-loop.h"
  #include "sysemu/replay.h"
+#include "qapi/qapi-events-block-core.h"
+
  /* Maximum bounce buffer for copy-on-read and write zeroes, in bytes */
  #define MAX_BOUNCE_BUFFER (32768 << BDRV_SECTOR_BITS)
@@ -1974,6 +1976,8 @@ bdrv_co_write_req_prepare(BdrvChild *child, int64_t 
offset, int64_t bytes,
 child->perm & BLK_PERM_RESIZE);
  switch (req->type) {
+    uint64_t write_threshold;
+


Works, but I think this is the first time I see a variable declared in a switch 
block.  What I usually do for such cases is to put a block after the label.  
(i.e. case X: { uint64_t write_threshold; ... })

But it wouldn’t hurt to just declare this at the beginning of 
bdrv_co_write_req_prepare(), I think.


  case BDRV_TRACKED_WRITE:
  case BDRV_TRACKED_DISCARD:
  if (flags & BDRV_REQ_WRITE_UNCHANGED) {
@@ -1981,8 +1985,15 @@ bdrv_co_write_req_prepare(BdrvChild *child, int64_t 
offset, int64_t bytes,
  } else {
  assert(child->perm & BLK_PERM_WRITE);
  }
-    return notifier_with_return_list_notify(&bs->before_write_notifiers,
-    req);
+    write_threshold = qatomic_read(&bs->write_threshold_offset);
+    if (write_threshold > 0 && offset + bytes > write_threshold) {
+    qapi_event_send_block_write_threshold(
+    bs->node_name,
+    offset + bytes - write_threshold,
+    write_threshold);
+    qatomic_set(&bs->write_threshold_offset, 0);
+    }


I’d put all of this into a function in block/write-threshold.c that’s called 
from here.

Max


+    return 0;
  case BDRV_TRACKED_TRUNCATE:
  assert(child->perm & BLK_PERM_RESIZE);
  return 0;
@@ -3137,12 +3148,6 @@ bool bdrv_qiov_is_aligned(BlockDriverState *bs, 
QEMUIOVector *qiov)
  return true;
  }
-void bdrv_add_before_write_notifier(BlockDriverState *bs,
-    NotifierWithReturn *notifier)
-{
-    notifier_with_return_list_add(&bs->before_write_notifiers, notifier);
-}
-
  void bdrv_io_plug(BlockDriverState *bs)
  {
  BdrvChild *child;





--
Best regards,
Vladimir

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[Markus Armbruster]

David Hildenbrand  writes:

> On 03.05.21 07:17, Thomas Huth wrote:
>> On 03/05/2021 06.58, Markus Armbruster wrote:
>>> Thomas Huth  writes:
>>>
 Clang unfortunately does not support generating code for the z900
 architecture level and starts with the z10 instead. Thus to be able
 to support compiling with Clang, we have to check for the supported
 compiler flags. The disadvantage is of course that the bios image
 will only run with z10 guest CPUs upwards (which is what most people
 use anyway), so just in case let's also emit a warning in that case.
>>>
>>> What happens when you try to use this bios with an old CPU anyway?
>> 
>> Interesting question. I was expecting the guest to crash since it would be
>> using a CPU instruction that is not supported on the old CPU model. But I
>> just gave it a try, and there was no crash. The guest booted just fine.
>> Either Clang only emits instructions that work with the old z900 anyway, or
>> our emulation in QEMU is imprecise and we allow newer instructions to be
>> executed on old models, too.
>
> Yes, that's currently still done. We once thought about disabling that 
> (there was a patch from Richard), but decided against it because -- back 
> then -- the default QEMU model was still very basic and would have 
> essentially disabled all more recent instructions as default.
>
> We can most probably do that change soon as we have a "fairly new" 
> default QEMU CPU model. I can glue it to my z14 change.

In case this makes the BIOS crash with old CPUs: when a guest refuses to
start because the BIOS was compiled the wrong way for it, configure
having told you so back then is not a nice user experience.  Can we do
better, with reasonable effort?

Re: [PATCH] block: Drop the sheepdog block driver

[Peter Krempa]

On Sat, May 01, 2021 at 09:57:47 +0200, Markus Armbruster wrote:
> It was deprecated in commit e1c4269763, v5.2.0.  See that commit
> message for rationale.
> 
> Signed-off-by: Markus Armbruster 
> ---
>  docs/system/deprecated.rst |9 -
>  docs/system/device-url-syntax.rst.inc  |   18 -
>  docs/system/qemu-block-drivers.rst.inc |   69 -
>  docs/system/removed-features.rst   |7 +
>  configure  |   10 -
>  meson.build|1 -
>  qapi/block-core.json   |   93 +-
>  qapi/transaction.json  |8 +-
>  block/sheepdog.c   | 3356 
>  .gitlab-ci.yml |1 -
>  MAINTAINERS|6 -
>  block/meson.build  |1 -
>  block/trace-events |   14 -
>  tests/qemu-iotests/005 |5 -
>  tests/qemu-iotests/025 |2 +-
>  tests/qemu-iotests/check   |3 +-
>  tests/qemu-iotests/common.rc   |4 -
>  17 files changed, 14 insertions(+), 3593 deletions(-)
>  delete mode 100644 block/sheepdog.c

Libvirt will need to adjust one test case (lock it to qemu-6.0 test
data), but other than that, this change is okay with us.

ACKed-by: Peter Krempa 

[PULL 00/23] Trivial branch for 6.1 patches

[Laurent Vivier]

The following changes since commit 53c5433e84e8935abed8e91d4a2eb813168a0ecf:

  Merge remote-tracking branch 'remotes/rth-gitlab/tags/pull-tcg-20210501' into 
staging (2021-05-02 12:02:46 +0100)

are available in the Git repository at:

  git://github.com/vivier/qemu.git tags/trivial-branch-for-6.1-pull-request

for you to fetch changes up to 9197b5d4b5f163455c891baec531ae73f5d3a73a:

  hw/rx/rx-gdbsim: Do not accept invalid memory size (2021-05-03 10:07:41 +0200)


Trivial patches pull request 20210503



David Edmondson (1):
  accel: kvm: clarify that extra exit data is hexadecimal

Gan Qixin (1):
  mc146818rtc: put it into the 'misc' category

Greg Kurz (1):
  docs/system: Document the removal of "compat" property for POWER CPUs

Keqian Zhu (1):
  vmstate: Constify some VMStateDescriptions

Philippe Mathieu-Daudé (8):
  hw/arm/pxa2xx: Declare PCMCIA bus with Kconfig
  hw/ide: Add Kconfig dependency MICRODRIVE -> PCMCIA
  hw/pcmcia: Do not register PCMCIA type if not required
  hw/arm: Constify VMStateDescription
  hw/display/qxl: Constify VMStateDescription
  hw/usb: Constify VMStateDescription
  ui: Fix memory leak in qemu_xkeymap_mapping_table()
  hw/rx/rx-gdbsim: Do not accept invalid memory size

Robert Hoo (1):
  docs: More precisely describe memory-backend-*::id's user

Serge Guelton (1):
  Fix typo in CFI build documentation

Silvano Cirujano Cuesta (1):
  scripts: fix generation update-binfmts templates

Thomas Huth (8):
  hw: Remove superfluous includes of hw/hw.h
  hw: Do not include hw/sysbus.h if it is not necessary
  hw: Do not include hw/irq.h if it is not necessary
  hw: Do not include qemu/log.h if it is not necessary
  Do not include sysemu/sysemu.h if it's not really necessary
  Do not include hw/boards.h if it's not really necessary
  Do not include cpu.h if it's not really necessary
  Do not include exec/address-spaces.h if it's not really necessary

 accel/kvm/kvm-all.c   |  4 +---
 accel/stubs/kvm-stub.c|  1 -
 accel/stubs/tcg-stub.c|  1 -
 accel/tcg/cpu-exec-common.c   |  1 -
 accel/tcg/cpu-exec.c  |  1 -
 accel/tcg/cputlb.c|  2 --
 accel/tcg/plugin-gen.c|  1 -
 accel/tcg/tcg-accel-ops-icount.c  |  1 -
 accel/tcg/tcg-accel-ops-rr.c  |  1 -
 accel/tcg/tcg-accel-ops.c |  1 -
 accel/tcg/translate-all.c |  1 -
 accel/tcg/translator.c|  1 -
 accel/tcg/user-exec-stub.c|  1 -
 accel/tcg/user-exec.c |  1 -
 backends/hostmem-file.c   |  1 -
 backends/hostmem-memfd.c  |  1 -
 backends/hostmem.c|  1 -
 block.c   |  1 -
 block/block-backend.c |  1 -
 block/nfs.c   |  1 -
 bsd-user/main.c   |  1 -
 chardev/char-mux.c|  1 -
 chardev/char.c|  1 -
 disas.c   |  1 -
 docs/devel/control-flow-integrity.rst |  4 ++--
 docs/system/removed-features.rst  |  6 ++
 dump/dump.c   |  1 -
 dump/win_dump.c   |  1 -
 gdbstub.c |  1 -
 hw/acpi/cpu.c |  1 -
 hw/acpi/generic_event_device.c|  1 -
 hw/acpi/ich9.c|  1 -
 hw/acpi/memory_hotplug.c  |  1 -
 hw/acpi/pcihp.c   |  1 -
 hw/acpi/piix4.c   |  1 -
 hw/alpha/dp264.c  |  1 -
 hw/alpha/typhoon.c|  2 --
 hw/arm/Kconfig|  1 +
 hw/arm/allwinner-a10.c|  2 --
 hw/arm/allwinner-h3.c |  2 --
 hw/arm/armv7m.c   |  2 --
 hw/arm/aspeed.c   |  5 -
 hw/arm/aspeed_ast2600.c   |  3 ---
 hw/arm/aspeed_soc.c   |  3 ---
 hw/arm/bcm2836.c  |  1 -
 hw/arm/boot.c |  1 -
 hw/arm/cubieboard.c   |  4 
 hw/arm/digic_boards.c |  3 ---
 hw/arm/exynos4210.c   |  1 -
 hw/arm/exynos4_boards.c   |  2 --
 hw/arm/fsl-imx25.c|  2 --
 hw/arm/fsl-imx31.c|  1 -
 hw/arm/highbank.c |  3 +--
 hw/arm/imx25_pdk.c|  2 --
 hw/arm/kzm.c  |  1 -
 hw/arm/mcimx6ul-evk.c |  1 -
 hw/arm/mcimx7d-sabre.c|  1 -
 hw/arm/msf2-soc.c |  1 -
 hw/arm/msf2-som.c |  1 -
 hw/arm/musicpal.c |  2 --
 hw/arm/npcm7xx.c  |  1 -
 hw/arm/npcm7xx_boards.c   |  2 --
 hw/ar

[PULL 10/23] ui: Fix memory leak in qemu_xkeymap_mapping_table()

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Refactor qemu_xkeymap_mapping_table() to have a single exit point,
so we can easily free the memory allocated by XGetAtomName().

This fixes when running a binary configured with --enable-sanitizers:

  Direct leak of 22 byte(s) in 1 object(s) allocated from:
  #0 0x561344a7473f in malloc (qemu-system-x86_64+0x1dab73f)
  #1 0x7fa4d9dc08aa in XGetAtomName (/lib64/libX11.so.6+0x2a8aa)

Fixes: 2ec78706d18 ("ui: convert GTK and SDL1 frontends to keycodemapdb")
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Laurent Vivier 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20210430155009.259755-1-phi...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 ui/x_keymap.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/ui/x_keymap.c b/ui/x_keymap.c
index 555086fb6bd5..2ce7b899615f 100644
--- a/ui/x_keymap.c
+++ b/ui/x_keymap.c
@@ -56,6 +56,7 @@ const guint16 *qemu_xkeymap_mapping_table(Display *dpy, 
size_t *maplen)
 {
 XkbDescPtr desc;
 const gchar *keycodes = NULL;
+const guint16 *map;
 
 /* There is no easy way to determine what X11 server
  * and platform & keyboard driver is in use. Thus we
@@ -83,21 +84,21 @@ const guint16 *qemu_xkeymap_mapping_table(Display *dpy, 
size_t *maplen)
 if (check_for_xwin(dpy)) {
 trace_xkeymap_keymap("xwin");
 *maplen = qemu_input_map_xorgxwin_to_qcode_len;
-return qemu_input_map_xorgxwin_to_qcode;
+map = qemu_input_map_xorgxwin_to_qcode;
 } else if (check_for_xquartz(dpy)) {
 trace_xkeymap_keymap("xquartz");
 *maplen = qemu_input_map_xorgxquartz_to_qcode_len;
-return qemu_input_map_xorgxquartz_to_qcode;
+map = qemu_input_map_xorgxquartz_to_qcode;
 } else if ((keycodes && g_str_has_prefix(keycodes, "evdev")) ||
(XKeysymToKeycode(dpy, XK_Page_Up) == 0x70)) {
 trace_xkeymap_keymap("evdev");
 *maplen = qemu_input_map_xorgevdev_to_qcode_len;
-return qemu_input_map_xorgevdev_to_qcode;
+map = qemu_input_map_xorgevdev_to_qcode;
 } else if ((keycodes && g_str_has_prefix(keycodes, "xfree86")) ||
(XKeysymToKeycode(dpy, XK_Page_Up) == 0x63)) {
 trace_xkeymap_keymap("kbd");
 *maplen = qemu_input_map_xorgkbd_to_qcode_len;
-return qemu_input_map_xorgkbd_to_qcode;
+map = qemu_input_map_xorgkbd_to_qcode;
 } else {
 trace_xkeymap_keymap("NULL");
 g_warning("Unknown X11 keycode mapping '%s'.\n"
@@ -109,6 +110,10 @@ const guint16 *qemu_xkeymap_mapping_table(Display *dpy, 
size_t *maplen)
   "  - xprop -root\n"
   "  - xdpyinfo\n",
   keycodes ? keycodes : "");
-return NULL;
+map = NULL;
 }
+if (keycodes) {
+XFree((void *)keycodes);
+}
+return map;
 }
-- 
2.31.1

[PULL 05/23] Fix typo in CFI build documentation

[Laurent Vivier]

From: Serge Guelton 

Signed-off-by: Serge Guelton 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210430150745.ga1401...@sguelton.remote.csb>
Signed-off-by: Laurent Vivier 
---
 docs/devel/control-flow-integrity.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/devel/control-flow-integrity.rst 
b/docs/devel/control-flow-integrity.rst
index d89d70733d88..e6b73a4fe1a5 100644
--- a/docs/devel/control-flow-integrity.rst
+++ b/docs/devel/control-flow-integrity.rst
@@ -39,7 +39,7 @@ later).
 Given the use of LTO, a version of AR that supports LLVM IR is required.
 The easies way of doing this is by selecting the AR provided by LLVM::
 
- AR=llvm-ar-9 CC=clang-9 CXX=lang++-9 /path/to/configure --enable-cfi
+ AR=llvm-ar-9 CC=clang-9 CXX=clang++-9 /path/to/configure --enable-cfi
 
 CFI is enabled on every binary produced.
 
@@ -131,7 +131,7 @@ lld with version 11+.
 In other words, to compile with fuzzing and CFI, clang 11+ is required, and
 lld needs to be used as a linker::
 
- AR=llvm-ar-11 CC=clang-11 CXX=lang++-11 /path/to/configure --enable-cfi \
+ AR=llvm-ar-11 CC=clang-11 CXX=clang++-11 /path/to/configure --enable-cfi \
-enable-fuzzing --extra-ldflags="-fuse-ld=lld"
 
 and then, compile the fuzzers as usual.
-- 
2.31.1

[PULL 01/23] accel: kvm: clarify that extra exit data is hexadecimal

[Laurent Vivier]

From: David Edmondson 

When dumping the extra exit data provided by KVM, make it clear that
the data is hexadecimal.

At the same time, zero-pad the output.

Signed-off-by: David Edmondson 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210428142431.266879-1-david.edmond...@oracle.com>
Signed-off-by: Laurent Vivier 
---
 accel/kvm/kvm-all.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index b6d9f92f1513..93d7cbfeaf88 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -2269,7 +2269,7 @@ static int kvm_handle_internal_error(CPUState *cpu, 
struct kvm_run *run)
 int i;
 
 for (i = 0; i < run->internal.ndata; ++i) {
-fprintf(stderr, "extra data[%d]: %"PRIx64"\n",
+fprintf(stderr, "extra data[%d]: 0x%016"PRIx64"\n",
 i, (uint64_t)run->internal.data[i]);
 }
 }
-- 
2.31.1

[PULL 08/23] hw/display/qxl: Constify VMStateDescription

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20210313171150.2122409-3-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/display/qxl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/display/qxl.c b/hw/display/qxl.c
index 93907e82a332..2ba75637ec30 100644
--- a/hw/display/qxl.c
+++ b/hw/display/qxl.c
@@ -2384,7 +2384,7 @@ static bool qxl_monitors_config_needed(void *opaque)
 }
 
 
-static VMStateDescription qxl_memslot = {
+static const VMStateDescription qxl_memslot = {
 .name   = "qxl-memslot",
 .version_id = QXL_SAVE_VERSION,
 .minimum_version_id = QXL_SAVE_VERSION,
@@ -2396,7 +2396,7 @@ static VMStateDescription qxl_memslot = {
 }
 };
 
-static VMStateDescription qxl_surface = {
+static const VMStateDescription qxl_surface = {
 .name   = "qxl-surface",
 .version_id = QXL_SAVE_VERSION,
 .minimum_version_id = QXL_SAVE_VERSION,
@@ -2414,7 +2414,7 @@ static VMStateDescription qxl_surface = {
 }
 };
 
-static VMStateDescription qxl_vmstate_monitors_config = {
+static const VMStateDescription qxl_vmstate_monitors_config = {
 .name   = "qxl/monitors-config",
 .version_id = 1,
 .minimum_version_id = 1,
@@ -2425,7 +2425,7 @@ static VMStateDescription qxl_vmstate_monitors_config = {
 },
 };
 
-static VMStateDescription qxl_vmstate = {
+static const VMStateDescription qxl_vmstate = {
 .name   = "qxl",
 .version_id = QXL_SAVE_VERSION,
 .minimum_version_id = QXL_SAVE_VERSION,
-- 
2.31.1

[PULL 02/23] hw/arm/pxa2xx: Declare PCMCIA bus with Kconfig

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

The Intel XScale PXA chipsets provide a PCMCIA controller,
which expose a PCMCIA bus. Express this dependency using
the Kconfig 'select' expression.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Warner Losh 
Reviewed-by: Richard Henderson 
Message-Id: <20210424222057.3434459-2-f4...@amsat.org>
[lv: remove "(IDE)"]
Signed-off-by: Laurent Vivier 
---
 hw/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 8c37cf00da74..b887f6a5b17d 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -142,6 +142,7 @@ config PXA2XX
 select SD
 select SSI
 select USB_OHCI
+select PCMCIA
 
 config GUMSTIX
 bool
-- 
2.31.1

[PULL 12/23] hw: Do not include hw/sysbus.h if it is not necessary

[Laurent Vivier]

From: Thomas Huth 

Many files include hw/sysbus.h without needing it. Remove the superfluous
include statements.

Signed-off-by: Thomas Huth 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210327082804.2259480-1-th...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/arm/cubieboard.c | 1 -
 hw/arm/orangepi.c   | 1 -
 hw/char/riscv_htif.c| 1 -
 hw/char/sifive_uart.c   | 1 -
 hw/char/virtio-serial-bus.c | 1 -
 hw/core/generic-loader.c| 1 -
 hw/core/guest-loader.c  | 1 -
 hw/ide/ahci_internal.h  | 1 -
 hw/input/lasips2.c  | 1 -
 hw/intc/arm_gic_kvm.c   | 1 -
 hw/intc/arm_gicv3.c | 1 -
 hw/intc/arm_gicv3_kvm.c | 1 -
 hw/intc/s390_flic_kvm.c | 1 -
 hw/isa/lpc_ich9.c   | 1 -
 hw/isa/piix4.c  | 1 -
 hw/moxie/moxiesim.c | 1 -
 hw/nios2/generic_nommu.c| 1 -
 hw/nubus/nubus-bus.c| 1 -
 hw/nvram/spapr_nvram.c  | 1 -
 hw/rx/rx-gdbsim.c   | 1 -
 hw/s390x/s390-ccw.c | 1 -
 hw/s390x/virtio-ccw.c   | 1 -
 hw/timer/mips_gictimer.c| 1 -
 hw/usb/xen-usb.c| 1 -
 hw/vfio/ap.c| 1 -
 hw/vfio/ccw.c   | 1 -
 hw/xen/xen-bus-helper.c | 1 -
 27 files changed, 27 deletions(-)

diff --git a/hw/arm/cubieboard.c b/hw/arm/cubieboard.c
index 9d0d728180bc..3ec30ca5afa4 100644
--- a/hw/arm/cubieboard.c
+++ b/hw/arm/cubieboard.c
@@ -20,7 +20,6 @@
 #include "qapi/error.h"
 #include "cpu.h"
 #include "sysemu/sysemu.h"
-#include "hw/sysbus.h"
 #include "hw/boards.h"
 #include "hw/qdev-properties.h"
 #include "hw/arm/allwinner-a10.h"
diff --git a/hw/arm/orangepi.c b/hw/arm/orangepi.c
index 40cdb5c6d2cb..b8d38c9e8d04 100644
--- a/hw/arm/orangepi.c
+++ b/hw/arm/orangepi.c
@@ -22,7 +22,6 @@
 #include "exec/address-spaces.h"
 #include "qapi/error.h"
 #include "cpu.h"
-#include "hw/sysbus.h"
 #include "hw/boards.h"
 #include "hw/qdev-properties.h"
 #include "hw/arm/allwinner-h3.h"
diff --git a/hw/char/riscv_htif.c b/hw/char/riscv_htif.c
index ba1af1cfc450..ddae738d5631 100644
--- a/hw/char/riscv_htif.c
+++ b/hw/char/riscv_htif.c
@@ -23,7 +23,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu/log.h"
-#include "hw/sysbus.h"
 #include "hw/char/riscv_htif.h"
 #include "hw/char/serial.h"
 #include "chardev/char.h"
diff --git a/hw/char/sifive_uart.c b/hw/char/sifive_uart.c
index ee7adb8e3083..fe1266678932 100644
--- a/hw/char/sifive_uart.c
+++ b/hw/char/sifive_uart.c
@@ -19,7 +19,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu/log.h"
-#include "hw/sysbus.h"
 #include "chardev/char.h"
 #include "chardev/char-fe.h"
 #include "hw/irq.h"
diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index b20038991a6c..dd6bc27b3b5d 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -28,7 +28,6 @@
 #include "qemu/error-report.h"
 #include "qemu/queue.h"
 #include "hw/qdev-properties.h"
-#include "hw/sysbus.h"
 #include "trace.h"
 #include "hw/virtio/virtio-serial.h"
 #include "hw/virtio/virtio-access.h"
diff --git a/hw/core/generic-loader.c b/hw/core/generic-loader.c
index 2b2a7b5e9aab..d14f932eea2e 100644
--- a/hw/core/generic-loader.c
+++ b/hw/core/generic-loader.c
@@ -32,7 +32,6 @@
 
 #include "qemu/osdep.h"
 #include "hw/core/cpu.h"
-#include "hw/sysbus.h"
 #include "sysemu/dma.h"
 #include "sysemu/reset.h"
 #include "hw/boards.h"
diff --git a/hw/core/guest-loader.c b/hw/core/guest-loader.c
index bde44e27b432..d3f9d1a06eb3 100644
--- a/hw/core/guest-loader.c
+++ b/hw/core/guest-loader.c
@@ -26,7 +26,6 @@
 
 #include "qemu/osdep.h"
 #include "hw/core/cpu.h"
-#include "hw/sysbus.h"
 #include "sysemu/dma.h"
 #include "hw/loader.h"
 #include "hw/qdev-properties.h"
diff --git a/hw/ide/ahci_internal.h b/hw/ide/ahci_internal.h
index 7f32e87731d9..109de9e2d112 100644
--- a/hw/ide/ahci_internal.h
+++ b/hw/ide/ahci_internal.h
@@ -26,7 +26,6 @@
 
 #include "hw/ide/ahci.h"
 #include "hw/ide/internal.h"
-#include "hw/sysbus.h"
 #include "hw/pci/pci.h"
 
 #define AHCI_MEM_BAR_SIZE 0x1000
diff --git a/hw/input/lasips2.c b/hw/input/lasips2.c
index 60afb94c780e..275737842e95 100644
--- a/hw/input/lasips2.c
+++ b/hw/input/lasips2.c
@@ -26,7 +26,6 @@
 #include "hw/qdev-properties.h"
 #include "hw/input/ps2.h"
 #include "hw/input/lasips2.h"
-#include "hw/sysbus.h"
 #include "exec/hwaddr.h"
 #include "sysemu/sysemu.h"
 #include "trace.h"
diff --git a/hw/intc/arm_gic_kvm.c b/hw/intc/arm_gic_kvm.c
index 9494185cf467..49f79a8674b0 100644
--- a/hw/intc/arm_gic_kvm.c
+++ b/hw/intc/arm_gic_kvm.c
@@ -23,7 +23,6 @@
 #include "qapi/error.h"
 #include "qemu/module.h"
 #include "cpu.h"
-#include "hw/sysbus.h"
 #include "migration/blocker.h"
 #include "sysemu/kvm.h"
 #include "kvm_arm.h"
diff --git a/hw/intc/arm_gicv3.c b/hw/intc/arm_gicv3.c
index 66eaa9719828..d63f8af604d6 100644
--- a/hw/intc/arm_gicv3.c
+++ b/hw/intc/arm_gicv3.c
@@ -18,7 +18,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "qemu/module.h

[PULL 15/23] Do not include sysemu/sysemu.h if it's not really necessary

[Laurent Vivier]

From: Thomas Huth 

Stop including sysemu/sysemu.h in files that don't need it.

Signed-off-by: Thomas Huth 
Message-Id: <20210416171314.2074665-2-th...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 accel/kvm/kvm-all.c  | 1 -
 accel/tcg/user-exec-stub.c   | 1 -
 backends/hostmem-file.c  | 1 -
 backends/hostmem-memfd.c | 1 -
 backends/hostmem.c   | 1 -
 block.c  | 1 -
 block/block-backend.c| 1 -
 block/nfs.c  | 1 -
 chardev/char-mux.c   | 1 -
 chardev/char.c   | 1 -
 gdbstub.c| 1 -
 hw/alpha/dp264.c | 1 -
 hw/arm/aspeed.c  | 1 -
 hw/arm/cubieboard.c  | 1 -
 hw/arm/digic_boards.c| 1 -
 hw/arm/exynos4_boards.c  | 1 -
 hw/arm/mcimx6ul-evk.c| 1 -
 hw/arm/mcimx7d-sabre.c   | 1 -
 hw/arm/npcm7xx_boards.c  | 1 -
 hw/arm/orangepi.c| 1 -
 hw/arm/raspi.c   | 1 -
 hw/arm/sabrelite.c   | 1 -
 hw/arm/virt.c| 1 -
 hw/block/nvme-subsys.c   | 1 -
 hw/core/machine-qmp-cmds.c   | 1 -
 hw/core/null-machine.c   | 1 -
 hw/core/numa.c   | 1 -
 hw/i386/pc_piix.c| 1 -
 hw/i386/pc_sysfw.c   | 1 -
 hw/input/lasips2.c   | 1 -
 hw/intc/sifive_plic.c| 1 -
 hw/isa/isa-superio.c | 1 -
 hw/isa/piix3.c   | 1 -
 hw/m68k/next-kbd.c   | 1 -
 hw/microblaze/boot.c | 1 -
 hw/mips/malta.c  | 1 -
 hw/misc/macio/macio.c| 1 -
 hw/net/can/xlnx-zynqmp-can.c | 1 -
 hw/net/i82596.c  | 1 -
 hw/net/lasi_i82596.c | 1 -
 hw/nios2/boot.c  | 1 -
 hw/ppc/ppc405_boards.c   | 1 -
 hw/ppc/prep.c| 1 -
 hw/rx/rx-gdbsim.c| 1 -
 hw/s390x/ipl.c   | 1 -
 hw/s390x/sclp.c  | 1 -
 hw/sh4/shix.c| 1 -
 hw/ssi/sifive_spi.c  | 1 -
 hw/vfio/display.c| 1 -
 hw/vfio/pci.c| 1 -
 hw/xtensa/virt.c | 1 -
 migration/ram.c  | 1 -
 monitor/monitor.c| 1 -
 net/net.c| 2 --
 net/netmap.c | 1 -
 plugins/api.c| 1 -
 plugins/core.c   | 1 -
 semihosting/config.c | 1 -
 semihosting/console.c| 1 -
 softmmu/arch_init.c  | 1 -
 softmmu/device_tree.c| 1 -
 softmmu/physmem.c| 1 -
 softmmu/qdev-monitor.c   | 1 -
 stubs/semihost.c | 1 -
 target/arm/cpu.c | 1 -
 target/openrisc/sys_helper.c | 1 -
 target/rx/helper.c   | 1 -
 target/s390x/cpu.c   | 1 -
 target/s390x/excp_helper.c   | 1 -
 tcg/tcg.c| 1 -
 tests/qtest/fuzz/fuzz.c  | 1 -
 tests/qtest/fuzz/qos_fuzz.c  | 1 -
 util/oslib-win32.c   | 1 -
 73 files changed, 74 deletions(-)

diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c
index 93d7cbfeaf88..50e56664cc6d 100644
--- a/accel/kvm/kvm-all.c
+++ b/accel/kvm/kvm-all.c
@@ -30,7 +30,6 @@
 #include "sysemu/kvm_int.h"
 #include "sysemu/runstate.h"
 #include "sysemu/cpus.h"
-#include "sysemu/sysemu.h"
 #include "qemu/bswap.h"
 #include "exec/memory.h"
 #include "exec/ram_addr.h"
diff --git a/accel/tcg/user-exec-stub.c b/accel/tcg/user-exec-stub.c
index b876f5c1e45d..968cd3ca60d7 100644
--- a/accel/tcg/user-exec-stub.c
+++ b/accel/tcg/user-exec-stub.c
@@ -1,7 +1,6 @@
 #include "qemu/osdep.h"
 #include "hw/core/cpu.h"
 #include "sysemu/replay.h"
-#include "sysemu/sysemu.h"
 
 bool enable_cpu_pm = false;
 
diff --git a/backends/hostmem-file.c b/backends/hostmem-file.c
index b683da9daf81..9b1b9f0a5604 100644
--- a/backends/hostmem-file.c
+++ b/backends/hostmem-file.c
@@ -15,7 +15,6 @@
 #include "qemu/error-report.h"
 #include "qemu/module.h"
 #include "sysemu/hostmem.h"
-#include "sysemu/sysemu.h"
 #include "qom/object_interfaces.h"
 #include "qom/object.h"
 
diff --git a/backends/hostmem-memfd.c b/backends/hostmem-memfd.c
index 69b0ae30bb08..da75e270573f 100644
--- a/backends/hostmem-memfd.c
+++ b/backends/hostmem-memfd.c
@@ -12,7 +12,6 @@
 
 #include "qemu/osdep.h"
 #include "sysemu/hostmem.h"
-#include "sysemu/sysemu.h"
 #include "qom/object_interfaces.h"
 #include "qemu/memfd.h"
 #include "qemu/module.h"
diff --git a/backends/hostmem.c b/backends/hostmem.c
index c6c1ff5b99c2..aab3de84083e 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -12,7 +12,6 @@
 
 #include "qemu/osdep.h"
 #include "sysemu/hostmem.h"
-#include "sysemu/sysemu.h"
 #include "hw/boards.h"
 #include "qapi/error.h"
 #include "qapi/qapi-builtin-visit.h"
diff --git a/block.c b/block.c
index 874c22c43e3d..9ad725d2057d 100644
--- a/block.c
+++ b/block.c
@@ -42,7 +42,6 @@
 #include "qapi/qobject-output-visitor.h"
 #include "qapi/qapi-visit-block-core.h"
 #include "sysemu/block-backend.h"
-#include "sysemu/sysemu.h"
 #include "qemu/notify.h"
 #include "qemu/option.h"
 #include "qemu/coroutine.h"
diff --git a/block/block-backend.c b/block/block-backen

[PULL 04/23] hw/pcmcia: Do not register PCMCIA type if not required

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

If the Kconfig 'PCMCIA' value is not selected, it is pointless
to build the PCMCIA core components.

(Currently only one machine of the ARM targets requires this).

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20210424222057.3434459-4-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/pcmcia/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/pcmcia/meson.build b/hw/pcmcia/meson.build
index ab50bd325d6c..51f2512b8ed0 100644
--- a/hw/pcmcia/meson.build
+++ b/hw/pcmcia/meson.build
@@ -1,2 +1,2 @@
-softmmu_ss.add(files('pcmcia.c'))
+softmmu_ss.add(when: 'CONFIG_PCMCIA', if_true: files('pcmcia.c'))
 softmmu_ss.add(when: 'CONFIG_PXA2XX', if_true: files('pxa2xx.c'))
-- 
2.31.1

[PULL 06/23] vmstate: Constify some VMStateDescriptions

[Laurent Vivier]

From: Keqian Zhu 

Constify vmstate_ecc_state and vmstate_x86_cpu.

Signed-off-by: Keqian Zhu 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20210408140706.23412-1-zhukeqi...@huawei.com>
Signed-off-by: Laurent Vivier 
---
 hw/block/ecc.c   | 2 +-
 include/hw/block/flash.h | 2 +-
 target/i386/cpu.h| 2 +-
 target/i386/machine.c| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/block/ecc.c b/hw/block/ecc.c
index 1a182367ee63..6e0d63842c14 100644
--- a/hw/block/ecc.c
+++ b/hw/block/ecc.c
@@ -78,7 +78,7 @@ void ecc_reset(ECCState *s)
 }
 
 /* Save/restore */
-VMStateDescription vmstate_ecc_state = {
+const VMStateDescription vmstate_ecc_state = {
 .name = "ecc-state",
 .version_id = 0,
 .minimum_version_id = 0,
diff --git a/include/hw/block/flash.h b/include/hw/block/flash.h
index 7dde0adcee78..86d8363bb09e 100644
--- a/include/hw/block/flash.h
+++ b/include/hw/block/flash.h
@@ -74,6 +74,6 @@ typedef struct {
 
 uint8_t ecc_digest(ECCState *s, uint8_t sample);
 void ecc_reset(ECCState *s);
-extern VMStateDescription vmstate_ecc_state;
+extern const VMStateDescription vmstate_ecc_state;
 
 #endif
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 570f916878f9..1bc300ce85de 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1786,7 +1786,7 @@ struct X86CPU {
 
 
 #ifndef CONFIG_USER_ONLY
-extern VMStateDescription vmstate_x86_cpu;
+extern const VMStateDescription vmstate_x86_cpu;
 #endif
 
 int x86_cpu_pending_interrupt(CPUState *cs, int interrupt_request);
diff --git a/target/i386/machine.c b/target/i386/machine.c
index 137604ddb898..f6f094f1c938 100644
--- a/target/i386/machine.c
+++ b/target/i386/machine.c
@@ -1396,7 +1396,7 @@ static const VMStateDescription vmstate_msr_tsx_ctrl = {
 }
 };
 
-VMStateDescription vmstate_x86_cpu = {
+const VMStateDescription vmstate_x86_cpu = {
 .name = "cpu",
 .version_id = 12,
 .minimum_version_id = 11,
-- 
2.31.1

[PATCH 0/2] Drop deprecated lm32 and unicore32

[Markus Armbruster]

Markus Armbruster (2):
  Drop the deprecated lm32 target
  Drop the deprecated unicore32 target

 docs/system/deprecated.rst|   16 -
 docs/system/removed-features.rst  |   14 +
 configure |7 +-
 default-configs/devices/lm32-softmmu.mak  |   12 -
 default-configs/devices/unicore32-softmmu.mak |6 -
 default-configs/targets/lm32-softmmu.mak  |2 -
 default-configs/targets/unicore32-softmmu.mak |1 -
 meson.build   |3 +-
 qapi/machine.json |4 +-
 hw/display/milkymist-vgafb_template.h |   74 -
 hw/lm32/lm32.h|   48 -
 hw/lm32/lm32_hwsetup.h|  179 --
 hw/lm32/milkymist-hw.h|  133 --
 hw/usb/quirks-ftdi-ids.h  |6 -
 hw/usb/quirks.h   |1 -
 include/disas/dis-asm.h   |3 -
 include/elf.h |3 +-
 include/exec/poison.h |3 -
 include/hw/char/lm32_juart.h  |   13 -
 include/hw/display/milkymist_tmu2.h   |   42 -
 include/hw/lm32/lm32_pic.h|   10 -
 include/hw/unicore32/puv3.h   |   40 -
 include/sysemu/arch_init.h|2 -
 target/lm32/cpu-param.h   |   17 -
 target/lm32/cpu-qom.h |   48 -
 target/lm32/cpu.h |  262 ---
 target/lm32/helper.h  |   14 -
 target/unicore32/cpu-param.h  |   17 -
 target/unicore32/cpu-qom.h|   37 -
 target/unicore32/cpu.h|  168 --
 target/unicore32/helper.h |   62 -
 disas/lm32.c  |  361 ---
 hw/audio/milkymist-ac97.c |  360 ---
 hw/char/lm32_juart.c  |  166 --
 hw/char/lm32_uart.c   |  314 ---
 hw/char/milkymist-uart.c  |  258 --
 hw/display/milkymist-tmu2.c   |  551 -
 hw/display/milkymist-vgafb.c  |  360 ---
 hw/dma/puv3_dma.c |  119 -
 hw/gpio/puv3_gpio.c   |  154 --
 hw/input/milkymist-softusb.c  |  319 ---
 hw/intc/lm32_pic.c|  195 --
 hw/intc/puv3_intc.c   |  147 --
 hw/lm32/lm32_boards.c |  333 ---
 hw/lm32/milkymist.c   |  250 --
 hw/misc/milkymist-hpdmc.c |  172 --
 hw/misc/milkymist-pfpu.c  |  548 -
 hw/misc/puv3_pm.c |  159 --
 hw/net/milkymist-minimac2.c   |  547 -
 hw/sd/milkymist-memcard.c |  335 ---
 hw/timer/lm32_timer.c |  249 --
 hw/timer/milkymist-sysctl.c   |  361 ---
 hw/timer/puv3_ost.c   |  166 --
 hw/unicore32/puv3.c   |  145 --
 softmmu/arch_init.c   |4 -
 target/lm32/cpu.c |  274 ---
 target/lm32/gdbstub.c |   92 -
 target/lm32/helper.c  |  224 --
 target/lm32/lm32-semi.c   |  212 --
 target/lm32/machine.c |   33 -
 target/lm32/op_helper.c   |  148 --
 target/lm32/translate.c   | 1237 --
 target/unicore32/cpu.c|  174 --
 target/unicore32/helper.c |  183 --
 target/unicore32/op_helper.c  |  244 --
 target/unicore32/softmmu.c|  280 ---
 target/unicore32/translate.c  | 2083 -
 target/unicore32/ucf64_helper.c   |  324 ---
 tests/qtest/machine-none-test.c   |2 -
 fpu/softfloat-specialize.c.inc|   11 +-
 .gitlab-ci.yml|2 +-
 MAINTAINERS   |   40 -
 disas/meson.build |1 -
 hw/Kconfig|2 -
 hw/audio/meson.build  |1 -
 hw/audio/trace-events |   12 -
 hw/char/meson.build   |3 -
 hw/char/trace-events  |   17 -
 hw/display/Kconfig|4 -
 hw/display/meson.build|2 -
 hw/display/trace-events   |   10 -
 hw/dma/meson.build|1 -
 hw/gpio/meson.build   |1 -
 hw/input/meson.build  |1 -
 hw/input/trace-events |7 -
 hw/intc/meson.build   |2 -

[PULL 14/23] hw: Do not include qemu/log.h if it is not necessary

[Laurent Vivier]

From: Thomas Huth 

Many files include qemu/log.h without needing it. Remove the superfluous
include statements.

Signed-off-by: Thomas Huth 
Reviewed-by: Alistair Francis 
Message-Id: <20210328054833.2351597-1-th...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/arm/aspeed.c | 1 -
 hw/arm/aspeed_ast2600.c | 1 -
 hw/arm/aspeed_soc.c | 1 -
 hw/arm/exynos4210.c | 1 -
 hw/arm/xlnx-versal-virt.c   | 1 -
 hw/arm/xlnx-versal.c| 1 -
 hw/i2c/mpc_i2c.c| 1 -
 hw/intc/imx_gpcv2.c | 1 -
 hw/intc/ompic.c | 1 -
 hw/intc/openpic.c   | 1 -
 hw/ipmi/isa_ipmi_bt.c   | 1 -
 hw/ipmi/isa_ipmi_kcs.c  | 1 -
 hw/mips/fuloong2e.c | 1 -
 hw/mips/loongson3_virt.c| 1 -
 hw/misc/imx7_snvs.c | 1 -
 hw/misc/imx_ccm.c   | 1 -
 hw/misc/imx_rngc.c  | 1 -
 hw/misc/pvpanic-isa.c   | 1 -
 hw/misc/pvpanic-pci.c   | 1 -
 hw/net/xgmac.c  | 1 -
 hw/ppc/pnv.c| 1 -
 hw/ppc/pnv_pnor.c   | 1 -
 hw/ppc/ppc405_boards.c  | 1 -
 hw/ppc/ppc405_uc.c  | 1 -
 hw/ppc/ppc_booke.c  | 1 -
 hw/ppc/virtex_ml507.c   | 1 -
 hw/riscv/microchip_pfsoc.c  | 1 -
 hw/riscv/numa.c | 1 -
 hw/riscv/sifive_e.c | 1 -
 hw/riscv/sifive_u.c | 1 -
 hw/riscv/spike.c| 1 -
 hw/riscv/virt.c | 1 -
 hw/sd/cadence_sdhci.c   | 1 -
 hw/ssi/xilinx_spi.c | 1 -
 hw/tricore/tc27x_soc.c  | 1 -
 hw/usb/chipidea.c   | 1 -
 hw/usb/hcd-dwc3.c   | 1 -
 hw/usb/imx-usb-phy.c| 1 -
 hw/usb/xlnx-usb-subsystem.c | 1 -
 hw/usb/xlnx-versal-usb2-ctrl-regs.c | 1 -
 hw/xen/xen-legacy-backend.c | 1 -
 net/dump.c  | 1 -
 net/filter-replay.c | 1 -
 semihosting/arm-compat-semi.c   | 1 -
 target/arm/op_helper.c  | 1 -
 target/hexagon/cpu.c| 1 -
 target/hexagon/decode.c | 1 -
 target/hexagon/genptr.c | 1 -
 target/lm32/lm32-semi.c | 1 -
 target/riscv/op_helper.c| 1 -
 target/s390x/interrupt.c| 1 -
 51 files changed, 51 deletions(-)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index a17b75f4940a..c3345fce5366 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -22,7 +22,6 @@
 #include "hw/misc/tmp105.h"
 #include "hw/misc/led.h"
 #include "hw/qdev-properties.h"
-#include "qemu/log.h"
 #include "sysemu/block-backend.h"
 #include "sysemu/sysemu.h"
 #include "hw/loader.h"
diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
index bc87e754a3cc..504aabf17371 100644
--- a/hw/arm/aspeed_ast2600.c
+++ b/hw/arm/aspeed_ast2600.c
@@ -14,7 +14,6 @@
 #include "hw/misc/unimp.h"
 #include "hw/arm/aspeed_soc.h"
 #include "hw/char/serial.h"
-#include "qemu/log.h"
 #include "qemu/module.h"
 #include "qemu/error-report.h"
 #include "hw/i2c/aspeed_i2c.h"
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 057d053c8478..516277800c9c 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -17,7 +17,6 @@
 #include "hw/misc/unimp.h"
 #include "hw/arm/aspeed_soc.h"
 #include "hw/char/serial.h"
-#include "qemu/log.h"
 #include "qemu/module.h"
 #include "qemu/error-report.h"
 #include "hw/i2c/aspeed_i2c.h"
diff --git a/hw/arm/exynos4210.c b/hw/arm/exynos4210.c
index ced2769b102a..5c7a51bbad75 100644
--- a/hw/arm/exynos4210.c
+++ b/hw/arm/exynos4210.c
@@ -23,7 +23,6 @@
 
 #include "qemu/osdep.h"
 #include "qapi/error.h"
-#include "qemu/log.h"
 #include "cpu.h"
 #include "hw/cpu/a9mpcore.h"
 #include "hw/irq.h"
diff --git a/hw/arm/xlnx-versal-virt.c b/hw/arm/xlnx-versal-virt.c
index 8482cd61960e..73e8268b353b 100644
--- a/hw/arm/xlnx-versal-virt.c
+++ b/hw/arm/xlnx-versal-virt.c
@@ -10,7 +10,6 @@
  */
 
 #include "qemu/osdep.h"
-#include "qemu/log.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
 #include "sysemu/device_tree.h"
diff --git a/hw/arm/xlnx-versal.c b/hw/arm/xlnx-versal.c
index 79609692e4eb..fb776834f7e9 100644
--- a/hw/arm/xlnx-versal.c
+++ b/hw/arm/xlnx-versal.c
@@ -12,7 +12,6 @@
 #include "qemu/osdep.h"
 #include "qemu/units.h"
 #include "qapi/error.h"
-#include "qemu/log.h"
 #include "qemu/module.h"
 #include "hw/sysbus.h"
 #include "net/net.h"
diff --git a/hw/i2c/mpc_i2c.c b/hw/i2c/mpc_i2c.c
index 720d2331e952..845392505ff2 100644
--- a/hw/i2c/mpc_i2c.c
+++ b/hw/i2c/mpc_i2c.c
@@ -20,7 +20,6 @@
 #include "qemu/osdep.h"
 #include "hw/i2c/i2c.h"
 #include "hw/irq.h"
-#include "qemu/log.h"
 #include "qemu/module.h"
 #include "hw/sysbus.h"
 #include "migration/vmstate.h"
diff --git a/hw/intc/imx_gpcv2.c b/hw/intc/imx_gpcv2.c
index 17007a407803..237d5f97eba3 100644
---

[PULL 07/23] hw/arm: Constify VMStateDescription

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20210313171150.2122409-2-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/arm/highbank.c   | 2 +-
 hw/arm/pxa2xx_pic.c | 2 +-
 hw/arm/spitz.c  | 4 ++--
 hw/arm/strongarm.c  | 2 +-
 hw/arm/z2.c | 4 ++--
 hw/dma/pxa2xx_dma.c | 4 ++--
 hw/misc/mst_fpga.c  | 2 +-
 7 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/arm/highbank.c b/hw/arm/highbank.c
index bf886268c57d..5afdd28b35c1 100644
--- a/hw/arm/highbank.c
+++ b/hw/arm/highbank.c
@@ -170,7 +170,7 @@ struct HighbankRegsState {
 uint32_t regs[NUM_REGS];
 };
 
-static VMStateDescription vmstate_highbank_regs = {
+static const VMStateDescription vmstate_highbank_regs = {
 .name = "highbank-regs",
 .version_id = 0,
 .minimum_version_id = 0,
diff --git a/hw/arm/pxa2xx_pic.c b/hw/arm/pxa2xx_pic.c
index cf6cb2a373ac..ed032fed548d 100644
--- a/hw/arm/pxa2xx_pic.c
+++ b/hw/arm/pxa2xx_pic.c
@@ -301,7 +301,7 @@ DeviceState *pxa2xx_pic_init(hwaddr base, ARMCPU *cpu)
 return dev;
 }
 
-static VMStateDescription vmstate_pxa2xx_pic_regs = {
+static const VMStateDescription vmstate_pxa2xx_pic_regs = {
 .name = "pxa2xx_pic",
 .version_id = 0,
 .minimum_version_id = 0,
diff --git a/hw/arm/spitz.c b/hw/arm/spitz.c
index 6b3bf9828bcb..b45a929cbd9e 100644
--- a/hw/arm/spitz.c
+++ b/hw/arm/spitz.c
@@ -1134,7 +1134,7 @@ static bool is_version_0(void *opaque, int version_id)
 return version_id == 0;
 }
 
-static VMStateDescription vmstate_sl_nand_info = {
+static const VMStateDescription vmstate_sl_nand_info = {
 .name = "sl-nand",
 .version_id = 0,
 .minimum_version_id = 0,
@@ -1170,7 +1170,7 @@ static const TypeInfo sl_nand_info = {
 .class_init= sl_nand_class_init,
 };
 
-static VMStateDescription vmstate_spitz_kbd = {
+static const VMStateDescription vmstate_spitz_kbd = {
 .name = "spitz-keyboard",
 .version_id = 1,
 .minimum_version_id = 0,
diff --git a/hw/arm/strongarm.c b/hw/arm/strongarm.c
index c7ca54bceaa4..e3e3ea61634f 100644
--- a/hw/arm/strongarm.c
+++ b/hw/arm/strongarm.c
@@ -207,7 +207,7 @@ static int strongarm_pic_post_load(void *opaque, int 
version_id)
 return 0;
 }
 
-static VMStateDescription vmstate_strongarm_pic_regs = {
+static const VMStateDescription vmstate_strongarm_pic_regs = {
 .name = "strongarm_pic",
 .version_id = 0,
 .minimum_version_id = 0,
diff --git a/hw/arm/z2.c b/hw/arm/z2.c
index 5099bd83802e..9c1e876207b3 100644
--- a/hw/arm/z2.c
+++ b/hw/arm/z2.c
@@ -162,7 +162,7 @@ static void zipit_lcd_realize(SSIPeripheral *dev, Error 
**errp)
 z->pos = 0;
 }
 
-static VMStateDescription vmstate_zipit_lcd_state = {
+static const VMStateDescription vmstate_zipit_lcd_state = {
 .name = "zipit-lcd",
 .version_id = 2,
 .minimum_version_id = 2,
@@ -268,7 +268,7 @@ static uint8_t aer915_recv(I2CSlave *slave)
 return retval;
 }
 
-static VMStateDescription vmstate_aer915_state = {
+static const VMStateDescription vmstate_aer915_state = {
 .name = "aer915",
 .version_id = 1,
 .minimum_version_id = 1,
diff --git a/hw/dma/pxa2xx_dma.c b/hw/dma/pxa2xx_dma.c
index b3707ff3de25..fa896f7edf77 100644
--- a/hw/dma/pxa2xx_dma.c
+++ b/hw/dma/pxa2xx_dma.c
@@ -525,7 +525,7 @@ static bool is_version_0(void *opaque, int version_id)
 return version_id == 0;
 }
 
-static VMStateDescription vmstate_pxa2xx_dma_chan = {
+static const VMStateDescription vmstate_pxa2xx_dma_chan = {
 .name = "pxa2xx_dma_chan",
 .version_id = 1,
 .minimum_version_id = 1,
@@ -540,7 +540,7 @@ static VMStateDescription vmstate_pxa2xx_dma_chan = {
 },
 };
 
-static VMStateDescription vmstate_pxa2xx_dma = {
+static const VMStateDescription vmstate_pxa2xx_dma = {
 .name = "pxa2xx_dma",
 .version_id = 1,
 .minimum_version_id = 0,
diff --git a/hw/misc/mst_fpga.c b/hw/misc/mst_fpga.c
index edfc35d5f0f9..2aaadfa96681 100644
--- a/hw/misc/mst_fpga.c
+++ b/hw/misc/mst_fpga.c
@@ -222,7 +222,7 @@ static void mst_fpga_init(Object *obj)
 sysbus_init_mmio(sbd, &s->iomem);
 }
 
-static VMStateDescription vmstate_mst_fpga_regs = {
+static const VMStateDescription vmstate_mst_fpga_regs = {
 .name = "mainstone_fpga",
 .version_id = 0,
 .minimum_version_id = 0,
-- 
2.31.1

[PULL 13/23] hw: Do not include hw/irq.h if it is not necessary

[Laurent Vivier]

From: Thomas Huth 

Many files include hw/irq.h without needing it. Remove the superfluous
include statements.

Signed-off-by: Thomas Huth 
Reviewed-by: Alistair Francis 
Message-Id: <20210327050236.2232347-1-th...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/arm/msf2-soc.c   | 1 -
 hw/i386/kvm/ioapic.c| 1 -
 hw/i386/xen/xen_platform.c  | 1 -
 hw/m68k/q800.c  | 1 -
 hw/m68k/virt.c  | 1 -
 hw/misc/led.c   | 1 -
 hw/misc/virt_ctrl.c | 1 -
 hw/ppc/prep.c   | 1 -
 hw/riscv/microchip_pfsoc.c  | 1 -
 hw/sd/cadence_sdhci.c   | 1 -
 hw/timer/sse-counter.c  | 1 -
 hw/usb/xlnx-usb-subsystem.c | 1 -
 12 files changed, 12 deletions(-)

diff --git a/hw/arm/msf2-soc.c b/hw/arm/msf2-soc.c
index d2c29e82d13a..5cfe7caf8349 100644
--- a/hw/arm/msf2-soc.c
+++ b/hw/arm/msf2-soc.c
@@ -27,7 +27,6 @@
 #include "qapi/error.h"
 #include "exec/address-spaces.h"
 #include "hw/char/serial.h"
-#include "hw/irq.h"
 #include "hw/arm/msf2-soc.h"
 #include "hw/misc/unimp.h"
 #include "sysemu/sysemu.h"
diff --git a/hw/i386/kvm/ioapic.c b/hw/i386/kvm/ioapic.c
index dfc3c9800574..71a563181e03 100644
--- a/hw/i386/kvm/ioapic.c
+++ b/hw/i386/kvm/ioapic.c
@@ -13,7 +13,6 @@
 #include "qemu/osdep.h"
 #include "monitor/monitor.h"
 #include "hw/i386/x86.h"
-#include "hw/irq.h"
 #include "hw/qdev-properties.h"
 #include "hw/i386/ioapic_internal.h"
 #include "hw/i386/apic_internal.h"
diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
index 01ae1fb16184..bf4f20e92b6f 100644
--- a/hw/i386/xen/xen_platform.c
+++ b/hw/i386/xen/xen_platform.c
@@ -27,7 +27,6 @@
 #include "qapi/error.h"
 #include "hw/ide.h"
 #include "hw/pci/pci.h"
-#include "hw/irq.h"
 #include "hw/xen/xen_common.h"
 #include "migration/vmstate.h"
 #include "hw/xen/xen-legacy-backend.h"
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 1c7f7aa07f07..d1ab1ff77d5c 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -27,7 +27,6 @@
 #include "sysemu/sysemu.h"
 #include "cpu.h"
 #include "hw/boards.h"
-#include "hw/irq.h"
 #include "hw/or-irq.h"
 #include "elf.h"
 #include "hw/loader.h"
diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 18e6f11041da..9469f82800c9 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -13,7 +13,6 @@
 #include "sysemu/sysemu.h"
 #include "cpu.h"
 #include "hw/boards.h"
-#include "hw/irq.h"
 #include "hw/qdev-properties.h"
 #include "elf.h"
 #include "hw/loader.h"
diff --git a/hw/misc/led.c b/hw/misc/led.c
index f552b8b6483c..f6d6d68bce59 100644
--- a/hw/misc/led.c
+++ b/hw/misc/led.c
@@ -10,7 +10,6 @@
 #include "migration/vmstate.h"
 #include "hw/qdev-properties.h"
 #include "hw/misc/led.h"
-#include "hw/irq.h"
 #include "trace.h"
 
 #define LED_INTENSITY_PERCENT_MAX   100
diff --git a/hw/misc/virt_ctrl.c b/hw/misc/virt_ctrl.c
index 2ea01bd7a1f0..3552d7a09abd 100644
--- a/hw/misc/virt_ctrl.c
+++ b/hw/misc/virt_ctrl.c
@@ -5,7 +5,6 @@
  */
 
 #include "qemu/osdep.h"
-#include "hw/irq.h"
 #include "hw/qdev-properties.h"
 #include "hw/sysbus.h"
 #include "migration/vmstate.h"
diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
index f1b1efdcef9f..af4ccb9f431f 100644
--- a/hw/ppc/prep.c
+++ b/hw/ppc/prep.c
@@ -38,7 +38,6 @@
 #include "qapi/error.h"
 #include "qemu/error-report.h"
 #include "qemu/log.h"
-#include "hw/irq.h"
 #include "hw/loader.h"
 #include "hw/rtc/mc146818rtc.h"
 #include "hw/isa/pc87312.h"
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index c4146b7a6b38..01537b30ebc9 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -41,7 +41,6 @@
 #include "qemu/cutils.h"
 #include "qapi/error.h"
 #include "hw/boards.h"
-#include "hw/irq.h"
 #include "hw/loader.h"
 #include "hw/sysbus.h"
 #include "chardev/char.h"
diff --git a/hw/sd/cadence_sdhci.c b/hw/sd/cadence_sdhci.c
index 0b371c843d8e..c89538b491f7 100644
--- a/hw/sd/cadence_sdhci.c
+++ b/hw/sd/cadence_sdhci.c
@@ -26,7 +26,6 @@
 #include "qemu/log.h"
 #include "qapi/error.h"
 #include "migration/vmstate.h"
-#include "hw/irq.h"
 #include "hw/sd/cadence_sdhci.h"
 #include "sdhci-internal.h"
 
diff --git a/hw/timer/sse-counter.c b/hw/timer/sse-counter.c
index 0384051f1511..16c0e8ad15db 100644
--- a/hw/timer/sse-counter.c
+++ b/hw/timer/sse-counter.c
@@ -33,7 +33,6 @@
 #include "trace.h"
 #include "hw/timer/sse-counter.h"
 #include "hw/sysbus.h"
-#include "hw/irq.h"
 #include "hw/registerfields.h"
 #include "hw/clock.h"
 #include "hw/qdev-clock.h"
diff --git a/hw/usb/xlnx-usb-subsystem.c b/hw/usb/xlnx-usb-subsystem.c
index 568257370cb0..c760c3058a42 100644
--- a/hw/usb/xlnx-usb-subsystem.c
+++ b/hw/usb/xlnx-usb-subsystem.c
@@ -24,7 +24,6 @@
 
 #include "qemu/osdep.h"
 #include "hw/sysbus.h"
-#include "hw/irq.h"
 #include "hw/register.h"
 #include "qemu/bitops.h"
 #include "qemu/log.h"
-- 
2.31.1

[PULL 09/23] hw/usb: Constify VMStateDescription

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Message-Id: <20210313171150.2122409-4-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/usb/ccid-card-passthru.c   | 2 +-
 hw/usb/dev-smartcard-reader.c | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/hw/usb/ccid-card-passthru.c b/hw/usb/ccid-card-passthru.c
index c1a90fcc7a52..7212d0d7fb5e 100644
--- a/hw/usb/ccid-card-passthru.c
+++ b/hw/usb/ccid-card-passthru.c
@@ -374,7 +374,7 @@ static void passthru_realize(CCIDCardState *base, Error 
**errp)
 card->atr_length = sizeof(DEFAULT_ATR);
 }
 
-static VMStateDescription passthru_vmstate = {
+static const VMStateDescription passthru_vmstate = {
 .name = "ccid-card-passthru",
 .version_id = 1,
 .minimum_version_id = 1,
diff --git a/hw/usb/dev-smartcard-reader.c b/hw/usb/dev-smartcard-reader.c
index bc3d94092a23..f7043075be58 100644
--- a/hw/usb/dev-smartcard-reader.c
+++ b/hw/usb/dev-smartcard-reader.c
@@ -1365,7 +1365,7 @@ static int ccid_pre_save(void *opaque)
 return 0;
 }
 
-static VMStateDescription bulk_in_vmstate = {
+static const VMStateDescription bulk_in_vmstate = {
 .name = "CCID BulkIn state",
 .version_id = 1,
 .minimum_version_id = 1,
@@ -1377,7 +1377,7 @@ static VMStateDescription bulk_in_vmstate = {
 }
 };
 
-static VMStateDescription answer_vmstate = {
+static const VMStateDescription answer_vmstate = {
 .name = "CCID Answer state",
 .version_id = 1,
 .minimum_version_id = 1,
@@ -1388,7 +1388,7 @@ static VMStateDescription answer_vmstate = {
 }
 };
 
-static VMStateDescription usb_device_vmstate = {
+static const VMStateDescription usb_device_vmstate = {
 .name = "usb_device",
 .version_id = 1,
 .minimum_version_id = 1,
@@ -1400,7 +1400,7 @@ static VMStateDescription usb_device_vmstate = {
 }
 };
 
-static VMStateDescription ccid_vmstate = {
+static const VMStateDescription ccid_vmstate = {
 .name = "usb-ccid",
 .version_id = 1,
 .minimum_version_id = 1,
-- 
2.31.1

[PULL 11/23] hw: Remove superfluous includes of hw/hw.h

[Laurent Vivier]

From: Thomas Huth 

The include/hw/hw.h header only has a prototype for hw_error(),
so it does not make sense to include this in files that do not
use this function.

Signed-off-by: Thomas Huth 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210326151848.2217216-1-th...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/arm/musicpal.c  | 1 -
 hw/char/sifive_uart.c  | 1 -
 hw/display/next-fb.c   | 1 -
 hw/dma/sifive_pdma.c   | 1 -
 hw/dma/xlnx_csu_dma.c  | 1 -
 hw/hppa/lasi.c | 1 -
 hw/input/lasips2.c | 1 -
 hw/m68k/mcf_intc.c | 1 -
 hw/m68k/next-kbd.c | 1 -
 hw/m68k/q800.c | 1 -
 hw/m68k/virt.c | 1 -
 hw/misc/mchp_pfsoc_dmc.c   | 1 -
 hw/misc/mchp_pfsoc_ioscb.c | 1 -
 hw/misc/mchp_pfsoc_sysreg.c| 1 -
 hw/misc/sifive_e_prci.c| 1 -
 hw/misc/sifive_test.c  | 1 -
 hw/rx/rx-gdbsim.c  | 1 -
 hw/rx/rx62n.c  | 1 -
 hw/vfio/pci-quirks.c   | 1 -
 include/hw/char/avr_usart.h| 1 -
 include/hw/misc/avr_power.h| 1 -
 include/hw/misc/stm32f4xx_exti.h   | 1 -
 include/hw/misc/stm32f4xx_syscfg.h | 1 -
 include/hw/pci-host/i440fx.h   | 1 -
 include/hw/timer/avr_timer16.h | 1 -
 25 files changed, 25 deletions(-)

diff --git a/hw/arm/musicpal.c b/hw/arm/musicpal.c
index 9cebece2de0b..7d67dc72542e 100644
--- a/hw/arm/musicpal.c
+++ b/hw/arm/musicpal.c
@@ -19,7 +19,6 @@
 #include "sysemu/sysemu.h"
 #include "hw/boards.h"
 #include "hw/char/serial.h"
-#include "hw/hw.h"
 #include "qemu/timer.h"
 #include "hw/ptimer.h"
 #include "hw/qdev-properties.h"
diff --git a/hw/char/sifive_uart.c b/hw/char/sifive_uart.c
index 3a00ba7f006c..ee7adb8e3083 100644
--- a/hw/char/sifive_uart.c
+++ b/hw/char/sifive_uart.c
@@ -22,7 +22,6 @@
 #include "hw/sysbus.h"
 #include "chardev/char.h"
 #include "chardev/char-fe.h"
-#include "hw/hw.h"
 #include "hw/irq.h"
 #include "hw/char/sifive_uart.h"
 
diff --git a/hw/display/next-fb.c b/hw/display/next-fb.c
index e2d895109dbe..cc134c2d5beb 100644
--- a/hw/display/next-fb.c
+++ b/hw/display/next-fb.c
@@ -24,7 +24,6 @@
 #include "qemu/osdep.h"
 #include "qapi/error.h"
 #include "ui/console.h"
-#include "hw/hw.h"
 #include "hw/boards.h"
 #include "hw/loader.h"
 #include "framebuffer.h"
diff --git a/hw/dma/sifive_pdma.c b/hw/dma/sifive_pdma.c
index e1f6fedbda73..9b2ac2017d9d 100644
--- a/hw/dma/sifive_pdma.c
+++ b/hw/dma/sifive_pdma.c
@@ -24,7 +24,6 @@
 #include "qemu/bitops.h"
 #include "qemu/log.h"
 #include "qapi/error.h"
-#include "hw/hw.h"
 #include "hw/irq.h"
 #include "hw/qdev-properties.h"
 #include "hw/sysbus.h"
diff --git a/hw/dma/xlnx_csu_dma.c b/hw/dma/xlnx_csu_dma.c
index 98324dadcd4c..797b4fed8f5f 100644
--- a/hw/dma/xlnx_csu_dma.c
+++ b/hw/dma/xlnx_csu_dma.c
@@ -21,7 +21,6 @@
 #include "qemu/osdep.h"
 #include "qemu/log.h"
 #include "qapi/error.h"
-#include "hw/hw.h"
 #include "hw/irq.h"
 #include "hw/qdev-properties.h"
 #include "hw/sysbus.h"
diff --git a/hw/hppa/lasi.c b/hw/hppa/lasi.c
index 1a8565794846..a8f5defcd01e 100644
--- a/hw/hppa/lasi.c
+++ b/hw/hppa/lasi.c
@@ -15,7 +15,6 @@
 #include "qapi/error.h"
 #include "cpu.h"
 #include "trace.h"
-#include "hw/hw.h"
 #include "hw/irq.h"
 #include "sysemu/sysemu.h"
 #include "sysemu/runstate.h"
diff --git a/hw/input/lasips2.c b/hw/input/lasips2.c
index 0786e5733880..60afb94c780e 100644
--- a/hw/input/lasips2.c
+++ b/hw/input/lasips2.c
@@ -24,7 +24,6 @@
 #include "qemu/osdep.h"
 #include "qemu/log.h"
 #include "hw/qdev-properties.h"
-#include "hw/hw.h"
 #include "hw/input/ps2.h"
 #include "hw/input/lasips2.h"
 #include "hw/sysbus.h"
diff --git a/hw/m68k/mcf_intc.c b/hw/m68k/mcf_intc.c
index cf02f57a7117..4cd30188c053 100644
--- a/hw/m68k/mcf_intc.c
+++ b/hw/m68k/mcf_intc.c
@@ -11,7 +11,6 @@
 #include "qemu/module.h"
 #include "qemu/log.h"
 #include "cpu.h"
-#include "hw/hw.h"
 #include "hw/irq.h"
 #include "hw/sysbus.h"
 #include "hw/m68k/mcf.h"
diff --git a/hw/m68k/next-kbd.c b/hw/m68k/next-kbd.c
index c11b5281f199..bee40e25bca0 100644
--- a/hw/m68k/next-kbd.c
+++ b/hw/m68k/next-kbd.c
@@ -30,7 +30,6 @@
 #include "qemu/osdep.h"
 #include "qemu/log.h"
 #include "exec/address-spaces.h"
-#include "hw/hw.h"
 #include "hw/sysbus.h"
 #include "hw/m68k/next-cube.h"
 #include "ui/console.h"
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index 4d2e866eec7f..1c7f7aa07f07 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -26,7 +26,6 @@
 #include "qemu/datadir.h"
 #include "sysemu/sysemu.h"
 #include "cpu.h"
-#include "hw/hw.h"
 #include "hw/boards.h"
 #include "hw/irq.h"
 #include "hw/or-irq.h"
diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index e9a5d4c69b97..18e6f11041da 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -12,7 +12,6 @@
 #include "qemu-common.h"
 #include "sysemu/sysemu.h"
 #include "cpu.h"
-#include "hw/hw.h"
 #include "hw/boards.h"
 #include "hw/

[PULL 23/23] hw/rx/rx-gdbsim: Do not accept invalid memory size

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

We check the amount of RAM is enough, warn when it is
not, but if so we neglect to bail out. Fix that by
adding the missing exit() call.

Fixes: bda19d7bb56 ("hw/rx: Add RX GDB simulator")
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Richard Henderson 
Reviewed-by: Yoshinori Sato 
Message-Id: <20210407223056.1870497-1-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/rx/rx-gdbsim.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/rx/rx-gdbsim.c b/hw/rx/rx-gdbsim.c
index b52d76b9b681..75d1fec6ca46 100644
--- a/hw/rx/rx-gdbsim.c
+++ b/hw/rx/rx-gdbsim.c
@@ -89,6 +89,7 @@ static void rx_gdbsim_init(MachineState *machine)
 char *sz = size_to_str(mc->default_ram_size);
 error_report("Invalid RAM size, should be more than %s", sz);
 g_free(sz);
+exit(1);
 }
 
 /* Allocate memory space */
-- 
2.31.1

[PULL 18/23] Do not include exec/address-spaces.h if it's not really necessary

[Laurent Vivier]

From: Thomas Huth 

Stop including exec/address-spaces.h in files that don't need it.

Signed-off-by: Thomas Huth 
Message-Id: <20210416171314.2074665-5-th...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 accel/kvm/kvm-all.c   | 1 -
 accel/tcg/cputlb.c| 1 -
 hw/acpi/generic_event_device.c| 1 -
 hw/acpi/ich9.c| 1 -
 hw/acpi/pcihp.c   | 1 -
 hw/acpi/piix4.c   | 1 -
 hw/alpha/typhoon.c| 1 -
 hw/arm/allwinner-a10.c| 1 -
 hw/arm/allwinner-h3.c | 1 -
 hw/arm/armv7m.c   | 1 -
 hw/arm/aspeed.c   | 1 -
 hw/arm/aspeed_ast2600.c   | 1 -
 hw/arm/aspeed_soc.c   | 1 -
 hw/arm/boot.c | 1 -
 hw/arm/cubieboard.c   | 1 -
 hw/arm/digic_boards.c | 1 -
 hw/arm/fsl-imx25.c| 1 -
 hw/arm/highbank.c | 1 -
 hw/arm/imx25_pdk.c| 1 -
 hw/arm/musicpal.c | 1 -
 hw/arm/npcm7xx.c  | 1 -
 hw/arm/npcm7xx_boards.c   | 1 -
 hw/arm/nrf51_soc.c| 1 -
 hw/arm/nseries.c  | 1 -
 hw/arm/palm.c | 1 -
 hw/arm/realview.c | 1 -
 hw/arm/sbsa-ref.c | 1 -
 hw/arm/smmu-common.c  | 1 -
 hw/arm/smmuv3.c   | 1 -
 hw/arm/versatilepb.c  | 1 -
 hw/arm/vexpress.c | 1 -
 hw/arm/virt.c | 1 -
 hw/arm/xilinx_zynq.c  | 1 -
 hw/arm/xlnx-versal-virt.c | 1 -
 hw/arm/xlnx-zynqmp.c  | 1 -
 hw/char/mchp_pfsoc_mmuart.c   | 1 -
 hw/core/loader.c  | 1 -
 hw/cris/axis_dev88.c  | 1 -
 hw/dma/pl080.c| 1 -
 hw/hppa/dino.c| 1 -
 hw/hppa/lasi.c| 1 -
 hw/i386/intel_iommu.c | 1 -
 hw/i386/pc.c  | 1 -
 hw/i386/pc_piix.c | 1 -
 hw/i386/pc_q35.c  | 1 -
 hw/i386/xen/xen-hvm.c | 1 -
 hw/i386/xen/xen_platform.c| 1 -
 hw/intc/openpic_kvm.c | 1 -
 hw/isa/lpc_ich9.c | 1 -
 hw/isa/vt82c686.c | 1 -
 hw/lm32/lm32_boards.c | 1 -
 hw/lm32/milkymist.c   | 1 -
 hw/m68k/an5206.c  | 1 -
 hw/m68k/mcf5208.c | 1 -
 hw/m68k/next-cube.c   | 1 -
 hw/m68k/next-kbd.c| 1 -
 hw/m68k/q800.c| 1 -
 hw/m68k/virt.c| 1 -
 hw/mem/sparse-mem.c   | 1 -
 hw/mips/boston.c  | 1 -
 hw/mips/fuloong2e.c   | 1 -
 hw/mips/gt64xxx_pci.c | 1 -
 hw/mips/jazz.c| 1 -
 hw/mips/loongson3_virt.c  | 1 -
 hw/mips/malta.c   | 1 -
 hw/mips/mipssim.c | 1 -
 hw/moxie/moxiesim.c   | 1 -
 hw/net/msf2-emac.c| 1 -
 hw/nvram/nrf51_nvm.c  | 1 -
 hw/openrisc/openrisc_sim.c| 1 -
 hw/pci-host/bonito.c  | 1 -
 hw/pci-host/ppce500.c | 1 -
 hw/pci-host/prep.c| 1 -
 hw/pci-host/sabre.c   | 1 -
 hw/pci-host/sh_pci.c  | 1 -
 hw/pci/pci.c  | 1 -
 hw/pci/pcie_host.c| 1 -
 hw/ppc/e500.c | 1 -
 hw/ppc/mac_newworld.c | 1 -
 hw/ppc/mac_oldworld.c | 1 -
 hw/ppc/pnv.c  | 1 -
 hw/ppc/pnv_psi.c  | 1 -
 hw/ppc/ppc405_boards.c| 1 -
 hw/ppc/ppc440_bamboo.c| 1 -
 hw/ppc/ppc440_pcix.c  | 1 -
 hw/ppc/ppc440_uc.c| 1 -
 hw/ppc/ppc4xx_pci.c   | 1 -
 hw/ppc/prep.c | 1 -
 hw/ppc/sam460ex.c | 1 -
 hw/ppc/spapr.c| 1 -
 hw/ppc/spapr_iommu.c  | 1 -
 hw/ppc/spapr_pci.c| 1 -
 hw/ppc/virtex_ml507.c | 1 -
 hw/remote/machine.c   | 1 -
 hw/remote/memory.c| 1 -
 hw/remote/proxy-memory-listener.c | 1 -
 hw/riscv/opentitan.c  | 1 -
 hw/riscv/sifive_e.c   | 1 -
 hw/rtc/m48t59.c   | 1 -
 hw/rtc/mc146818rtc.c  | 1 -
 hw/s390x/s390-virtio-ccw.c| 1 -
 hw/sh4/r2d.c  | 1 -
 hw/sh4/shix.c | 1 -
 hw/sparc/leon3.c  | 1 -
 hw/sparc64/niagara.c  | 1 -
 hw/ssi/aspeed_smc.c   | 1 -
 hw/tpm/tpm_crb.c  | 1 -
 hw/tricore/tc27x_soc.c| 1 -
 hw/tricore/triboard.c | 1 -
 hw/tricore/tricore_testboard.c| 1 -
 hw/virtio/vhost.c | 1 -
 hw/virtio/virtio.c| 1 -
 hw/xen/xen_pt.c   | 1 -
 hw/xtensa/sim.c   | 1 -
 hw/xtensa/virt.c  | 1 -
 hw/xtensa/xtfpga.c| 1 -
 softmmu/memory.c  | 

[PULL 03/23] hw/ide: Add Kconfig dependency MICRODRIVE -> PCMCIA

[Laurent Vivier]

From: Philippe Mathieu-Daudé 

The Microdrive Compact Flash can be plugged on a PCMCIA bus.
Express the dependency using the 'depends on' Kconfig expression.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Warner Losh 
Reviewed-by: Richard Henderson 
Message-Id: <20210424222057.3434459-3-f4...@amsat.org>
Signed-off-by: Laurent Vivier 
---
 hw/ide/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ide/Kconfig b/hw/ide/Kconfig
index 5d9106b1ac2b..8e2c89345497 100644
--- a/hw/ide/Kconfig
+++ b/hw/ide/Kconfig
@@ -41,6 +41,7 @@ config IDE_VIA
 config MICRODRIVE
 bool
 select IDE_QDEV
+depends on PCMCIA
 
 config AHCI
 bool
-- 
2.31.1

Re: [PATCH 0/1] Acceptance Tests: bump Avocado version requirement to 87.0

[Philippe Mathieu-Daudé]

On 5/3/21 3:50 AM, Cleber Rosa wrote:
> - Original Message -
>> From: "Philippe Mathieu-Daudé" 
>> On 4/14/21 6:11 PM, Cleber Rosa wrote:
>>> This is being proposed as a separate single patch simply to show
>>> that no known regressions have been introduced as far as the
>>> acceptance tests/jobs are related.  CI job:
>>>
>>>https://gitlab.com/cleber.gnu/qemu/-/pipelines/286347312
>>>
>>> This version (and 86.0) contain improvements that address specific
>>> QEMU use cases, including:
>>>
>>>  * Fix to the error message given when downloading assets
>>>
>>>  * Asset listing/purging capabilities
>>>
>>> Cleber Rosa (1):
>>>   Acceptance Tests: bump Avocado version requirement to 87.0
>>>
>>>  tests/requirements.txt | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>
>> Ping? This patch should fix the mainstream pipeline error:
>> https://gitlab.com/qemu-project/qemu/-/jobs/1229752162
>>
> 
> Hi Phil,
> 
> I'll send with my python-next (and other) patches to be queued in a day
> or two... but the bad news is: I don't think Avocado 87.0 has the fix for
> the pipeline issue above.  I looked at the test log, and the kernel boot
> hangs right after:
> 
> 11:43:53 DEBUG| Freeing unused kernel memory: 1176K
> 11:43:53 DEBUG| This architecture does not have kernel memory protection.
> 
> And then gets interrupted by Avocado some 90 seconds after that.  I'll try
> to reproduce it and debug.

Oh, there was 2 errors... I just looked at the first one. Thanks for
being cautious with the test logs :)

Thomas / Alex, what do you suggest we do with the test_or1k_sim
timeouting? This is not the first time:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg781695.html

> 
>> (see
>> https://www.mail-archive.com/qemu-devel@nongnu.org/msg794416.html)
>>
>>
> 
> Avocado 87.0 does fix the issue you referenced here though.
> 
> Regards,
> - Cleber.
> 

[PULL 19/23] mc146818rtc: put it into the 'misc' category

[Laurent Vivier]

From: Gan Qixin 

The category of the mc146818rtc device is not set, put it into the 'misc'
category.

Signed-off-by: Gan Qixin 
Reviewed-by: Thomas Huth 
Message-Id: <20201130083630.2520597-6-ganqi...@huawei.com>
Signed-off-by: Laurent Vivier 
---
 hw/rtc/mc146818rtc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c
index 36a2dbf62f9c..3d2d3854e716 100644
--- a/hw/rtc/mc146818rtc.c
+++ b/hw/rtc/mc146818rtc.c
@@ -1039,6 +1039,7 @@ static void rtc_class_initfn(ObjectClass *klass, void 
*data)
 dc->vmsd = &vmstate_rtc;
 isa->build_aml = rtc_build_aml;
 device_class_set_props(dc, mc146818rtc_properties);
+set_bit(DEVICE_CATEGORY_MISC, dc->categories);
 }
 
 static const TypeInfo mc146818rtc_info = {
-- 
2.31.1

[PULL 16/23] Do not include hw/boards.h if it's not really necessary

[Laurent Vivier]

From: Thomas Huth 

Stop including hw/boards.h in files that don't need it.

Signed-off-by: Thomas Huth 
Message-Id: <20210416171314.2074665-3-th...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 accel/tcg/tcg-accel-ops-icount.c | 1 -
 accel/tcg/tcg-accel-ops-rr.c | 1 -
 accel/tcg/tcg-accel-ops.c| 1 -
 hw/acpi/cpu.c| 1 -
 hw/acpi/memory_hotplug.c | 1 -
 hw/alpha/typhoon.c   | 1 -
 hw/arm/aspeed.c  | 1 -
 hw/arm/omap1.c   | 1 -
 hw/arm/omap2.c   | 1 -
 hw/arm/strongarm.c   | 1 -
 hw/arm/virt.c| 1 -
 hw/avr/arduino.c | 1 -
 hw/avr/atmega.c  | 1 -
 hw/display/next-fb.c | 1 -
 hw/hppa/machine.c| 1 -
 hw/i386/acpi-build.c | 1 -
 hw/i386/acpi-microvm.c   | 1 -
 hw/i386/intel_iommu.c| 1 -
 hw/i386/pc.c | 1 -
 hw/i386/x86-iommu.c  | 1 -
 hw/intc/sifive_plic.c| 1 -
 hw/mips/loongson3_virt.c | 1 -
 hw/ppc/e500.c| 1 -
 hw/ppc/mac_newworld.c| 1 -
 hw/ppc/mac_oldworld.c| 1 -
 hw/ppc/pnv.c | 1 -
 hw/ppc/ppc4xx_devs.c | 1 -
 hw/ppc/rs6000_mc.c   | 1 -
 hw/ppc/spapr.c   | 1 -
 hw/ppc/spapr_rtas.c  | 1 -
 hw/remote/iohub.c| 1 -
 hw/s390x/s390-virtio-ccw.c   | 2 --
 hw/tricore/tc27x_soc.c   | 1 -
 hw/tricore/triboard.c| 1 -
 softmmu/vl.c | 1 -
 35 files changed, 36 deletions(-)

diff --git a/accel/tcg/tcg-accel-ops-icount.c b/accel/tcg/tcg-accel-ops-icount.c
index 13b8fbeb699d..ea42d1d51b10 100644
--- a/accel/tcg/tcg-accel-ops-icount.c
+++ b/accel/tcg/tcg-accel-ops-icount.c
@@ -30,7 +30,6 @@
 #include "qemu/main-loop.h"
 #include "qemu/guest-random.h"
 #include "exec/exec-all.h"
-#include "hw/boards.h"
 
 #include "tcg-accel-ops.h"
 #include "tcg-accel-ops-icount.h"
diff --git a/accel/tcg/tcg-accel-ops-rr.c b/accel/tcg/tcg-accel-ops-rr.c
index 018b54c508fa..c02c061ecb35 100644
--- a/accel/tcg/tcg-accel-ops-rr.c
+++ b/accel/tcg/tcg-accel-ops-rr.c
@@ -30,7 +30,6 @@
 #include "qemu/main-loop.h"
 #include "qemu/guest-random.h"
 #include "exec/exec-all.h"
-#include "hw/boards.h"
 
 #include "tcg-accel-ops.h"
 #include "tcg-accel-ops-rr.h"
diff --git a/accel/tcg/tcg-accel-ops.c b/accel/tcg/tcg-accel-ops.c
index 6cdcaa2855c8..7191315aeed4 100644
--- a/accel/tcg/tcg-accel-ops.c
+++ b/accel/tcg/tcg-accel-ops.c
@@ -32,7 +32,6 @@
 #include "qemu/main-loop.h"
 #include "qemu/guest-random.h"
 #include "exec/exec-all.h"
-#include "hw/boards.h"
 
 #include "tcg-accel-ops.h"
 #include "tcg-accel-ops-mttcg.h"
diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
index e2317be546b3..f82e9512fdf5 100644
--- a/hw/acpi/cpu.c
+++ b/hw/acpi/cpu.c
@@ -1,5 +1,4 @@
 #include "qemu/osdep.h"
-#include "hw/boards.h"
 #include "migration/vmstate.h"
 #include "hw/acpi/cpu.h"
 #include "qapi/error.h"
diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c
index 0bdcf15528f3..af3788942350 100644
--- a/hw/acpi/memory_hotplug.c
+++ b/hw/acpi/memory_hotplug.c
@@ -2,7 +2,6 @@
 #include "hw/acpi/memory_hotplug.h"
 #include "hw/acpi/pc-hotplug.h"
 #include "hw/mem/pc-dimm.h"
-#include "hw/boards.h"
 #include "hw/qdev-core.h"
 #include "migration/vmstate.h"
 #include "trace.h"
diff --git a/hw/alpha/typhoon.c b/hw/alpha/typhoon.c
index a42b31981216..96c35c5fdbd8 100644
--- a/hw/alpha/typhoon.c
+++ b/hw/alpha/typhoon.c
@@ -11,7 +11,6 @@
 #include "qemu/units.h"
 #include "qapi/error.h"
 #include "cpu.h"
-#include "hw/boards.h"
 #include "hw/irq.h"
 #include "alpha_sys.h"
 #include "exec/address-spaces.h"
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index c4f85dab63b3..b1e5bc76e4d2 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -16,7 +16,6 @@
 #include "hw/arm/boot.h"
 #include "hw/arm/aspeed.h"
 #include "hw/arm/aspeed_soc.h"
-#include "hw/boards.h"
 #include "hw/i2c/smbus_eeprom.h"
 #include "hw/misc/pca9552.h"
 #include "hw/misc/tmp105.h"
diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c
index 02c0f66431b9..180d3788f891 100644
--- a/hw/arm/omap1.c
+++ b/hw/arm/omap1.c
@@ -24,7 +24,6 @@
 #include "qemu-common.h"
 #include "cpu.h"
 #include "exec/address-spaces.h"
-#include "hw/boards.h"
 #include "hw/hw.h"
 #include "hw/irq.h"
 #include "hw/qdev-properties.h"
diff --git a/hw/arm/omap2.c b/hw/arm/omap2.c
index 16d388fc79d5..02b1aa8c974b 100644
--- a/hw/arm/omap2.c
+++ b/hw/arm/omap2.c
@@ -27,7 +27,6 @@
 #include "sysemu/qtest.h"
 #include "sysemu/reset.h"
 #include "sysemu/runstate.h"
-#include "hw/boards.h"
 #include "hw/irq.h"
 #include "hw/qdev-properties.h"
 #include "hw/arm/boot.h"
diff --git a/hw/arm/strongarm.c b/hw/arm/strongarm.c
index e3e3ea61634f..939a57dda558 100644
--- a/hw/arm/strongarm.c
+++ b/hw/arm/strongarm.c
@@ -30,7 +30,6 @@
 #include "qemu/osdep.h"
 #include "qemu-common.h"
 #include "cpu.h"
-#incl

[PULL 21/23] scripts: fix generation update-binfmts templates

[Laurent Vivier]

From: Silvano Cirujano Cuesta 

This patch fixes the update-binfmts templates being used in the script
scripts/qemu-binfmt-conf.sh when the option --debian is used.

Fixed issues are:
- Typo in flag 'credentials' (previously 'credential').
- Missing flags 'preserve' and 'fix_binary'.

Reference: 
https://manpages.debian.org/buster/binfmt-support/update-binfmts.8.en.html#FORMAT_FILES

Signed-off-by: Silvano Cirujano Cuesta 
Reviewed-by: Laurent Vivier 
Message-Id: <20210323123457.23747-1-silvano.cirujano-cue...@siemens.com>
Signed-off-by: Laurent Vivier 
---
 scripts/qemu-binfmt-conf.sh | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
index 573b5dc6acd7..7de996d536ea 100755
--- a/scripts/qemu-binfmt-conf.sh
+++ b/scripts/qemu-binfmt-conf.sh
@@ -294,7 +294,9 @@ package qemu-$cpu
 interpreter $qemu
 magic $magic
 mask $mask
-credential $CREDENTIAL
+credentials $CREDENTIAL
+preserve $PRESERVE_ARG0
+fix_binary $PERSISTENT
 EOF
 }
 
-- 
2.31.1

[PULL 17/23] Do not include cpu.h if it's not really necessary

[Laurent Vivier]

From: Thomas Huth 

Stop including cpu.h in files that don't need it.

Signed-off-by: Thomas Huth 
Message-Id: <20210416171314.2074665-4-th...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 accel/stubs/kvm-stub.c| 1 -
 accel/stubs/tcg-stub.c| 1 -
 accel/tcg/cpu-exec-common.c   | 1 -
 accel/tcg/cpu-exec.c  | 1 -
 accel/tcg/cputlb.c| 1 -
 accel/tcg/plugin-gen.c| 1 -
 accel/tcg/translate-all.c | 1 -
 accel/tcg/translator.c| 1 -
 accel/tcg/user-exec.c | 1 -
 bsd-user/main.c   | 1 -
 disas.c   | 1 -
 dump/dump.c   | 1 -
 dump/win_dump.c   | 1 -
 hw/arm/allwinner-a10.c| 1 -
 hw/arm/allwinner-h3.c | 1 -
 hw/arm/armv7m.c   | 1 -
 hw/arm/aspeed.c   | 1 -
 hw/arm/aspeed_ast2600.c   | 1 -
 hw/arm/aspeed_soc.c   | 1 -
 hw/arm/bcm2836.c  | 1 -
 hw/arm/cubieboard.c   | 1 -
 hw/arm/digic_boards.c | 1 -
 hw/arm/exynos4_boards.c   | 1 -
 hw/arm/fsl-imx25.c| 1 -
 hw/arm/fsl-imx31.c| 1 -
 hw/arm/imx25_pdk.c| 1 -
 hw/arm/kzm.c  | 1 -
 hw/arm/msf2-som.c | 1 -
 hw/arm/nrf51_soc.c| 1 -
 hw/arm/orangepi.c | 1 -
 hw/arm/raspi.c| 1 -
 hw/arm/stellaris.c| 1 -
 hw/arm/xlnx-zcu102.c  | 1 -
 hw/arm/xlnx-zynqmp.c  | 1 -
 hw/char/spapr_vty.c   | 1 -
 hw/core/machine-qmp-cmds.c| 1 -
 hw/hppa/dino.c| 1 -
 hw/hppa/lasi.c| 1 -
 hw/i386/kvm/apic.c| 1 -
 hw/i386/kvm/clock.c   | 1 -
 hw/i386/kvmvapic.c| 1 -
 hw/i386/microvm.c | 1 -
 hw/i386/pc_piix.c | 1 -
 hw/i386/vmport.c  | 1 -
 hw/intc/apic.c| 1 -
 hw/intc/apic_common.c | 1 -
 hw/intc/arm_gic_kvm.c | 1 -
 hw/intc/armv7m_nvic.c | 1 -
 hw/intc/grlib_irqmp.c | 1 -
 hw/intc/openpic_kvm.c | 1 -
 hw/intc/s390_flic.c   | 1 -
 hw/intc/s390_flic_kvm.c   | 1 -
 hw/intc/xics.c| 1 -
 hw/intc/xics_kvm.c| 1 -
 hw/intc/xics_spapr.c  | 1 -
 hw/m68k/next-cube.c   | 1 -
 hw/mips/loongson3_virt.c  | 1 -
 hw/mips/malta.c   | 1 -
 hw/mips/mips_int.c| 1 -
 hw/mips/mipssim.c | 1 -
 hw/misc/mips_itu.c| 1 -
 hw/net/spapr_llan.c   | 1 -
 hw/nios2/10m50_devboard.c | 1 -
 hw/nios2/boot.c   | 1 -
 hw/nios2/generic_nommu.c  | 1 -
 hw/nvram/spapr_nvram.c| 1 -
 hw/ppc/ppc.c  | 1 -
 hw/ppc/ppc440_uc.c| 1 -
 hw/ppc/prep.c | 1 -
 hw/ppc/spapr_drc.c| 1 -
 hw/ppc/spapr_events.c | 1 -
 hw/ppc/spapr_hcall.c  | 1 -
 hw/ppc/spapr_pci.c| 1 -
 hw/ppc/spapr_pci_vfio.c   | 1 -
 hw/ppc/spapr_rng.c| 1 -
 hw/ppc/spapr_rtas.c   | 1 -
 hw/ppc/spapr_rtas_ddw.c   | 1 -
 hw/ppc/spapr_rtc.c| 1 -
 hw/ppc/spapr_tpm_proxy.c  | 1 -
 hw/remote/proxy-memory-listener.c | 1 -
 hw/rx/rx-gdbsim.c | 1 -
 hw/rx/rx62n.c | 1 -
 hw/s390x/3270-ccw.c   | 1 -
 hw/s390x/css-bridge.c | 1 -
 hw/s390x/css.c| 1 -
 hw/s390x/ipl.c| 1 -
 hw/s390x/pv.c | 1 -
 hw/s390x/s390-pci-bus.c   | 1 -
 hw/s390x/s390-pci-inst.c  | 1 -
 hw/s390x/s390-stattrib-kvm.c  | 1 -
 hw/s390x/s390-stattrib.c  | 1 -
 hw/s390x/s390-virtio-ccw.c| 1 -
 hw/s390x/sclp.c   | 1 -
 hw/s390x/sclpcpu.c| 1 -
 hw/scsi/spapr_vscsi.c | 1 -
 hw/sh4/sh7750.c   | 1 -
 hw/tricore/tc27x_soc.c| 1 -
 hw/tricore/triboard.c | 1 -
 hw/vfio/ap.c  | 1 -
 hw/vfio/migration.c   | 1 -
 hw/vfio/spapr.c   | 1 -
 hw/xtensa/sim.c   | 1 -
 hw/xtensa/virt.c  | 1 -
 hw/xtensa/xtensa_memory.c | 1 -
 linux-user/main.c | 1 -
 linux-user/semihost.c | 1 -
 migration/ram.c   | 1 -
 monitor/misc.c| 1 -
 plugins/api.c | 1 -
 plugins/core.c| 1 -
 plugins/loader.c  | 1 -
 semihosting/arm-compat-semi.c | 1 -
 semihosting/console.c | 1 -
 softmmu/arch_init.c   | 1 -
 softmmu/memory.c  | 1 -
 softmmu/memory_mapping.c  | 1 -
 softmmu/physmem.c | 1 -
 tcg/tcg-op-

[PULL 22/23] docs: More precisely describe memory-backend-*::id's user

[Laurent Vivier]

From: Robert Hoo 

'id' of memory-backend-{file,ram} is not only for '-numa''s reference, but
also other parameters like '-device nvdimm'.
More clearly call out this to avoid misinterpretation.

Signed-off-by: Robert Hoo 
Reviewed-by: Markus Armbruster 
Message-Id: <1619080922-83527-1-git-send-email-robert...@linux.intel.com>
Signed-off-by: Laurent Vivier 
---
 qemu-options.hx | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/qemu-options.hx b/qemu-options.hx
index fd21002bd61d..635dc8a6243a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4508,11 +4508,11 @@ SRST
 the guest RAM with huge pages.
 
 The ``id`` parameter is a unique ID that will be used to
-reference this memory region when configuring the ``-numa``
-argument.
+reference this memory region in other parameters, e.g. ``-numa``,
+``-device nvdimm``, etc.
 
 The ``size`` option provides the size of the memory region, and
-accepts common suffixes, eg ``500M``.
+accepts common suffixes, e.g. ``500M``.
 
 The ``mem-path`` provides the path to either a shared memory or
 huge page filesystem mount.
-- 
2.31.1

[PULL 20/23] docs/system: Document the removal of "compat" property for POWER CPUs

[Laurent Vivier]

From: Greg Kurz 

This is just an oversight.

Fixes: f518be3aa35b ("target/ppc: Remove "compat" property of server class 
POWER CPUs")
Cc: gr...@kaod.org
Signed-off-by: Greg Kurz 
Reviewed-by: Laurent Vivier 
Message-Id: <161399328834.51902.14269239378658110394.st...@bahia.lan>
Signed-off-by: Laurent Vivier 
---
 docs/system/removed-features.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 29e90601a51a..c21e6fa5ee3c 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -285,6 +285,12 @@ The RISC-V no MMU cpus have been removed. The two CPUs: 
``rv32imacu-nommu`` and
 ``rv64imacu-nommu`` can no longer be used. Instead the MMU status can be 
specified
 via the CPU ``mmu`` option when using the ``rv32`` or ``rv64`` CPUs.
 
+``compat`` property of server class POWER CPUs (removed in 6.0)
+'''
+
+The ``max-cpu-compat`` property of the ``pseries`` machine type should be used
+instead.
+
 System emulator machines
 
 
-- 
2.31.1

Re: [PATCH 1/4] pc-bios/s390-ccw: Silence warning from Clang by marking panic() as noreturn

[Cornelia Huck]

On Sun,  2 May 2021 19:48:33 +0200
Thomas Huth  wrote:

> When compiling the s390-ccw bios with Clang, the compiler emits a warning:
> 
>  pc-bios/s390-ccw/main.c:210:5: warning: variable 'found' is used 
> uninitialized
>   whenever switch default is taken [-Wsometimes-uninitialized]
>  default:
>  ^~~
>  pc-bios/s390-ccw/main.c:214:16: note: uninitialized use occurs here
>  IPL_assert(found, "Boot device not found\n");
> ^
> 
> It's a false positive, it only happens because Clang is not smart enough
> to see that the panic() function in the "default:" case can never return.
> 
> Anyway, let's explicitely mark panic() with "noreturn" to shut up the
> warning.
> 
> Signed-off-by: Thomas Huth 
> ---
>  pc-bios/s390-ccw/s390-ccw.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/pc-bios/s390-ccw/s390-ccw.h b/pc-bios/s390-ccw/s390-ccw.h
> index 6cd92669e9..79db69ff54 100644
> --- a/pc-bios/s390-ccw/s390-ccw.h
> +++ b/pc-bios/s390-ccw/s390-ccw.h
> @@ -89,6 +89,7 @@ bool menu_is_enabled_enum(void);
>  
>  #define MAX_BOOT_ENTRIES  31
>  
> +__attribute__ ((__noreturn__))
>  static inline void panic(const char *string)
>  {
>  sclp_print(string);

I'm surprised that the noreturn annotation of disabled_wait (called
right after the sclp_print()) is not enough. Anyway,

Reviewed-by: Cornelia Huck 

[PATCH 2/2] Drop the deprecated unicore32 target

[Markus Armbruster]

Target unicore32 was deprecated in commit 8e4ff4a8d2b, v5.2.0.  See
there for rationale.

Cc: Guan Xuetao 
Signed-off-by: Markus Armbruster 
---
 docs/system/deprecated.rst|8 -
 docs/system/removed-features.rst  |9 +-
 configure |2 +-
 default-configs/devices/unicore32-softmmu.mak |6 -
 default-configs/targets/unicore32-softmmu.mak |1 -
 qapi/machine.json |2 +-
 include/elf.h |3 +-
 include/exec/poison.h |1 -
 include/hw/unicore32/puv3.h   |   40 -
 include/sysemu/arch_init.h|1 -
 target/unicore32/cpu-param.h  |   17 -
 target/unicore32/cpu-qom.h|   37 -
 target/unicore32/cpu.h|  168 --
 target/unicore32/helper.h |   62 -
 hw/dma/puv3_dma.c |  119 -
 hw/gpio/puv3_gpio.c   |  154 --
 hw/intc/puv3_intc.c   |  147 --
 hw/misc/puv3_pm.c |  159 --
 hw/timer/puv3_ost.c   |  166 --
 hw/unicore32/puv3.c   |  145 --
 softmmu/arch_init.c   |2 -
 target/unicore32/cpu.c|  174 --
 target/unicore32/helper.c |  183 --
 target/unicore32/op_helper.c  |  244 --
 target/unicore32/softmmu.c|  280 ---
 target/unicore32/translate.c  | 2083 -
 target/unicore32/ucf64_helper.c   |  324 ---
 tests/qtest/machine-none-test.c   |1 -
 fpu/softfloat-specialize.c.inc|   11 +-
 .gitlab-ci.yml|2 +-
 MAINTAINERS   |   15 -
 hw/Kconfig|1 -
 hw/dma/meson.build|1 -
 hw/gpio/meson.build   |1 -
 hw/intc/meson.build   |1 -
 hw/meson.build|1 -
 hw/misc/meson.build   |3 -
 hw/timer/meson.build  |1 -
 hw/unicore32/Kconfig  |5 -
 hw/unicore32/meson.build  |5 -
 target/meson.build|1 -
 target/unicore32/meson.build  |   14 -
 42 files changed, 17 insertions(+), 4583 deletions(-)
 delete mode 100644 default-configs/devices/unicore32-softmmu.mak
 delete mode 100644 default-configs/targets/unicore32-softmmu.mak
 delete mode 100644 include/hw/unicore32/puv3.h
 delete mode 100644 target/unicore32/cpu-param.h
 delete mode 100644 target/unicore32/cpu-qom.h
 delete mode 100644 target/unicore32/cpu.h
 delete mode 100644 target/unicore32/helper.h
 delete mode 100644 hw/dma/puv3_dma.c
 delete mode 100644 hw/gpio/puv3_gpio.c
 delete mode 100644 hw/intc/puv3_intc.c
 delete mode 100644 hw/misc/puv3_pm.c
 delete mode 100644 hw/timer/puv3_ost.c
 delete mode 100644 hw/unicore32/puv3.c
 delete mode 100644 target/unicore32/cpu.c
 delete mode 100644 target/unicore32/helper.c
 delete mode 100644 target/unicore32/op_helper.c
 delete mode 100644 target/unicore32/softmmu.c
 delete mode 100644 target/unicore32/translate.c
 delete mode 100644 target/unicore32/ucf64_helper.c
 delete mode 100644 hw/unicore32/Kconfig
 delete mode 100644 hw/unicore32/meson.build
 delete mode 100644 target/unicore32/meson.build

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index e914d34298..2592c4fbd5 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -198,14 +198,6 @@ from Linux upstream kernel, declare it deprecated.
 System emulator CPUS
 
 
-``unicore32`` CPUs (since 5.2.0)
-
-
-The ``unicore32`` guest CPU support is deprecated and will be removed in
-a future version of QEMU. Support for this CPU was removed from the
-upstream Linux kernel, and there is no available upstream toolchain
-to build binaries for it.
-
 ``Icelake-Client`` CPU Model (since 5.2.0)
 ''
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index e9850e4b96..b399084438 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -293,12 +293,19 @@ available to make sure that the code is still working, so 
it has been removed
 without replacement.
 
 ``lm32`` CPUs (removed in 6.1.0)
-'''
+
 
 The only public user of this architecture was the milkymist project,
 which has been dead for years; there was never an upstream Linux
 port.  Removed without replacement.
 
+``unicore32`` CPUs (since 6.1.0)
+
+
+Support for this CPU was removed f

Re: [PATCH] spapr: Modify ibm, get-config-addr-info2 to set DEVNUM in PE config address.

[Mahesh J Salgaonkar]

On 2021-04-30 07:52:58 Fri, Daniel Henrique Barboza wrote:
> 
> 
> On 4/29/21 6:02 AM, Mahesh J Salgaonkar wrote:
> > On 2021-04-28 22:33:45 Wed, Oliver O'Halloran wrote:
> > > On Tue, Apr 27, 2021 at 9:56 PM Mahesh Salgaonkar  
> > > wrote:
> > > > 
> > > > With upstream kernel, especially after commit 98ba956f6a389
> > > > ("powerpc/pseries/eeh: Rework device EEH PE determination") we see that 
> > > > KVM
> > > > guest isn't able to enable EEH option for PCI pass-through devices 
> > > > anymore.
> > > 
> > > How are you passing the devices through to the guest?
> > 
> > I am using libvirt with below xml section to add pass-through:
> > 
> >  
> >
> >
> >  
> >
> > > function='0x0' multifunction='on'/>
> >  
> >  
> >
> >
> >  
> >
> > > function='0x1' multifunction='on'/>
> >  
> > 
> > Looks like libvirt does not allow pass through device in slot zero, and
> > throws following error.
> 
> There's no such restriction in Libvirt, at least as far as I remember.
> 
> > 
> > error: XML error: Invalid PCI address :01:00.0. slot must be >= 1
> > Failed. Try again? [y,n,i,f,?]:
> 
> 
> This looks odd. The error message is complaining about :01:00.0 but
> your XML up there is declaring :01:01.0.

Above XML snipphet is working one. I see the XML error when I change slot
value to zero.

> 
> Also, the 'multifunction' bool is usually used only in the function 0
> passthrough, indicating that the guest will configure all other functions as
> the the multifunction device. You can ignore this bool in the XML for
> PCI passthrough if you don't care about the guest seeing this device as
> multifunction (i.e. all functions in the same IOMMU group and so on).
> 

Thanks,
-Mahesh.

[PATCH 2/5] usb/redir: avoid dynamic stack allocation (CVE-2021-3527)

[Gerd Hoffmann]

Use autofree heap allocation instead.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/redirect.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 17f06f34179a..db1a89a7cc92 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -818,7 +818,7 @@ static void usbredir_handle_bulk_data(USBRedirDevice *dev, 
USBPacket *p,
 usbredirparser_send_bulk_packet(dev->parser, p->id,
 &bulk_packet, NULL, 0);
 } else {
-uint8_t buf[size];
+g_autofree uint8_t *buf = g_malloc(size);
 usb_packet_copy(p, buf, size);
 usbredir_log_data(dev, "bulk data out:", buf, size);
 usbredirparser_send_bulk_packet(dev->parser, p->id,
@@ -923,7 +923,7 @@ static void 
usbredir_handle_interrupt_out_data(USBRedirDevice *dev,
USBPacket *p, uint8_t ep)
 {
 struct usb_redir_interrupt_packet_header interrupt_packet;
-uint8_t buf[p->iov.size];
+g_autofree uint8_t *buf = g_malloc(p->iov.size);
 
 DPRINTF("interrupt-out ep %02X len %zd id %"PRIu64"\n", ep,
 p->iov.size, p->id);
-- 
2.30.2

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[Cornelia Huck]

On Mon, 03 May 2021 10:23:20 +0200
Markus Armbruster  wrote:

> David Hildenbrand  writes:
> 
> > On 03.05.21 07:17, Thomas Huth wrote:  
> >> On 03/05/2021 06.58, Markus Armbruster wrote:  
> >>> Thomas Huth  writes:
> >>>  
>  Clang unfortunately does not support generating code for the z900
>  architecture level and starts with the z10 instead. Thus to be able
>  to support compiling with Clang, we have to check for the supported
>  compiler flags. The disadvantage is of course that the bios image
>  will only run with z10 guest CPUs upwards (which is what most people
>  use anyway), so just in case let's also emit a warning in that case.  
> >>>
> >>> What happens when you try to use this bios with an old CPU anyway?  
> >> 
> >> Interesting question. I was expecting the guest to crash since it would be
> >> using a CPU instruction that is not supported on the old CPU model. But I
> >> just gave it a try, and there was no crash. The guest booted just fine.
> >> Either Clang only emits instructions that work with the old z900 anyway, or
> >> our emulation in QEMU is imprecise and we allow newer instructions to be
> >> executed on old models, too.  
> >
> > Yes, that's currently still done. We once thought about disabling that 
> > (there was a patch from Richard), but decided against it because -- back 
> > then -- the default QEMU model was still very basic and would have 
> > essentially disabled all more recent instructions as default.
> >
> > We can most probably do that change soon as we have a "fairly new" 
> > default QEMU CPU model. I can glue it to my z14 change.  
> 
> In case this makes the BIOS crash with old CPUs: when a guest refuses to
> start because the BIOS was compiled the wrong way for it, configure
> having told you so back then is not a nice user experience.  Can we do
> better, with reasonable effort?

I fear the experience will be as bad as for any guest that is using
features from a newer cpu level (i.e. random crashes when the guest
actually tries to use that newer instruction.)

I see two options:
- Just try to start and hope that it works.
- Deprecate any cpu model older than z10.

Anyone have a better idea? I don't particularly like any of the two.

[PATCH 3/5] usb/mtp: avoid dynamic stack allocation

[Gerd Hoffmann]

Use autofree heap allocation instead.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/dev-mtp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/usb/dev-mtp.c b/hw/usb/dev-mtp.c
index bbb827434482..2a895a73b083 100644
--- a/hw/usb/dev-mtp.c
+++ b/hw/usb/dev-mtp.c
@@ -907,7 +907,8 @@ static MTPData *usb_mtp_get_object_handles(MTPState *s, 
MTPControl *c,
MTPObject *o)
 {
 MTPData *d = usb_mtp_data_alloc(c);
-uint32_t i = 0, handles[o->nchildren];
+uint32_t i = 0;
+g_autofree uint32_t *handles = g_new(uint32_t, o->nchildren);
 MTPObject *iter;
 
 trace_usb_mtp_op_get_object_handles(s->dev.addr, o->handle, o->path);
-- 
2.30.2

Re: [PATCH 3/4] pc-bios/s390-ccw: Silence GCC 11 stringop-overflow warning

[Cornelia Huck]

On Sun,  2 May 2021 19:48:35 +0200
Thomas Huth  wrote:

> From: Philippe Mathieu-Daudé 
> 
> When building on Fedora 34 (gcc version 11.0.0 20210210) we get:
> 
>   In file included from pc-bios/s390-ccw/main.c:11:
>   In function ‘memset’,
>   inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
>   inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
>   pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of 
> size 0 [-Wstringop-overflow=]
>  28 | p[i] = c;
> | ~^~~
> 
> The offending code is:
> 
>   memset((char *)S390EP, 0, 6);
> 
> where S390EP is a const address:
> 
>   #define S390EP 0x10008
> 
> The compiler doesn't now how big that pointed area is, so assume its

s/now/know/
s/assume/it assumes that/

> length is zero. This has been reported as BZ#99578 to GCC:
> "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
> pointer from integer literal"
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
> 
> As this warning does us more harm than good in the BIOS code (where
> lot of direct accesses to low memory are done), silence this warning
> for all BIOS objects.
> 
> Suggested-by: Thomas Huth 
> Signed-off-by: Philippe Mathieu-Daudé 
> Message-Id: <20210422145911.2513980-1-phi...@redhat.com>
> Acked-by: Christian Borntraeger 
> [thuth: Use the pre-existing cc-option macro instead of adding a new one]
> Signed-off-by: Thomas Huth 
> ---
>  pc-bios/s390-ccw/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/pc-bios/s390-ccw/Makefile b/pc-bios/s390-ccw/Makefile
> index f0fe84c9eb..83fb1afb73 100644
> --- a/pc-bios/s390-ccw/Makefile
> +++ b/pc-bios/s390-ccw/Makefile
> @@ -30,6 +30,7 @@ OBJECTS = start.o main.o bootmap.o jump2ipl.o sclp.o menu.o 
> \
> virtio.o virtio-scsi.o virtio-blkdev.o libc.o cio.o dasd-ipl.o
>  
>  QEMU_CFLAGS := -Wall $(filter -W%, $(QEMU_CFLAGS))
> +QEMU_CFLAGS += $(call cc-option,-Werror 
> $(QEMU_CFLAGS),-Wno-stringop-overflow)
>  QEMU_CFLAGS += -ffreestanding -fno-delete-null-pointer-checks -fno-common 
> -fPIE
>  QEMU_CFLAGS += -fwrapv -fno-strict-aliasing -fno-asynchronous-unwind-tables
>  QEMU_CFLAGS += $(call cc-option, $(QEMU_CFLAGS), -fno-stack-protector)

Reviewed-by: Cornelia Huck 

[PATCH 5/5] usb: limit combined packets to 1 MiB

[Gerd Hoffmann]

usb-host and usb-redirect try to batch bulk transfers by combining many
small usb packets into a single, large transfer request, to reduce the
overhead and improve performance.

This patch adds a size limit of 1 MiB for those combined packets to
restrict the host resources the guest can bind that way.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/combined-packet.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/usb/combined-packet.c b/hw/usb/combined-packet.c
index 5d57e883dcb5..e56802f89a32 100644
--- a/hw/usb/combined-packet.c
+++ b/hw/usb/combined-packet.c
@@ -171,7 +171,9 @@ void usb_ep_combine_input_packets(USBEndpoint *ep)
 if ((p->iov.size % ep->max_packet_size) != 0 || !p->short_not_ok ||
 next == NULL ||
 /* Work around for Linux usbfs bulk splitting + migration */
-(totalsize == (16 * KiB - 36) && p->int_req)) {
+(totalsize == (16 * KiB - 36) && p->int_req) ||
+/* Next package may grow combined package over 1MiB */
+totalsize > 1 * MiB - ep->max_packet_size) {
 usb_device_handle_data(ep->dev, first);
 assert(first->status == USB_RET_ASYNC);
 if (first->combined) {
-- 
2.30.2

[PATCH 4/5] usb/xhci: sanity check packet size

[Gerd Hoffmann]

Make sure the usb packet size is within the
bounds of the endpoint configuration.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/hcd-xhci.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/usb/hcd-xhci.c b/hw/usb/hcd-xhci.c
index 46212b1e695a..7acfb8137bc9 100644
--- a/hw/usb/hcd-xhci.c
+++ b/hw/usb/hcd-xhci.c
@@ -1568,6 +1568,11 @@ static int xhci_setup_packet(XHCITransfer *xfer)
 qemu_sglist_destroy(&xfer->sgl);
 return -1;
 }
+if (xfer->packet.iov.size > ep->max_packet_size) {
+usb_packet_unmap(&xfer->packet, &xfer->sgl);
+qemu_sglist_destroy(&xfer->sgl);
+return -1;
+}
 DPRINTF("xhci: setup packet pid 0x%x addr %d ep %d\n",
 xfer->packet.pid, ep->dev->addr, ep->nr);
 return 0;
-- 
2.30.2

[PATCH 0/5] usb: fix some memory allocation issues.

[Gerd Hoffmann]

Gerd Hoffmann (5):
  usb/hid: avoid dynamic stack allocation
  usb/redir: avoid dynamic stack allocation (CVE-2021-3527)
  usb/mtp: avoid dynamic stack allocation
  usb/xhci: sanity check packet size
  usb: limit combined packets to 1 MiB

 hw/usb/combined-packet.c | 4 +++-
 hw/usb/dev-hid.c | 2 +-
 hw/usb/dev-mtp.c | 3 ++-
 hw/usb/dev-wacom.c   | 2 +-
 hw/usb/hcd-xhci.c| 5 +
 hw/usb/redirect.c| 4 ++--
 6 files changed, 14 insertions(+), 6 deletions(-)

-- 
2.30.2

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[David Hildenbrand]

On 03.05.21 11:14, Cornelia Huck wrote:

On Mon, 03 May 2021 10:23:20 +0200
Markus Armbruster  wrote:


David Hildenbrand  writes:


On 03.05.21 07:17, Thomas Huth wrote:

On 03/05/2021 06.58, Markus Armbruster wrote:

Thomas Huth  writes:
  

Clang unfortunately does not support generating code for the z900
architecture level and starts with the z10 instead. Thus to be able
to support compiling with Clang, we have to check for the supported
compiler flags. The disadvantage is of course that the bios image
will only run with z10 guest CPUs upwards (which is what most people
use anyway), so just in case let's also emit a warning in that case.


What happens when you try to use this bios with an old CPU anyway?


Interesting question. I was expecting the guest to crash since it would be
using a CPU instruction that is not supported on the old CPU model. But I
just gave it a try, and there was no crash. The guest booted just fine.
Either Clang only emits instructions that work with the old z900 anyway, or
our emulation in QEMU is imprecise and we allow newer instructions to be
executed on old models, too.


Yes, that's currently still done. We once thought about disabling that
(there was a patch from Richard), but decided against it because -- back
then -- the default QEMU model was still very basic and would have
essentially disabled all more recent instructions as default.

We can most probably do that change soon as we have a "fairly new"
default QEMU CPU model. I can glue it to my z14 change.


In case this makes the BIOS crash with old CPUs: when a guest refuses to
start because the BIOS was compiled the wrong way for it, configure
having told you so back then is not a nice user experience.  Can we do
better, with reasonable effort?


I fear the experience will be as bad as for any guest that is using
features from a newer cpu level (i.e. random crashes when the guest
actually tries to use that newer instruction.)

I see two options:
- Just try to start and hope that it works.
- Deprecate any cpu model older than z10.

Anyone have a better idea? I don't particularly like any of the two.


As the default CPU model with new compat machines is >= z13, I wouldn't 
lose sleep about this. Even with a broken bios one can still boot an 
external kernel+initrd for testing purposes.


--
Thanks,

David / dhildenb

[PATCH 1/5] usb/hid: avoid dynamic stack allocation

[Gerd Hoffmann]

Use autofree heap allocation instead.

Signed-off-by: Gerd Hoffmann 
---
 hw/usb/dev-hid.c   | 2 +-
 hw/usb/dev-wacom.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/usb/dev-hid.c b/hw/usb/dev-hid.c
index fc39bab79f94..1c7ae97c3033 100644
--- a/hw/usb/dev-hid.c
+++ b/hw/usb/dev-hid.c
@@ -656,7 +656,7 @@ static void usb_hid_handle_data(USBDevice *dev, USBPacket 
*p)
 {
 USBHIDState *us = USB_HID(dev);
 HIDState *hs = &us->hid;
-uint8_t buf[p->iov.size];
+g_autofree uint8_t *buf = g_malloc(p->iov.size);
 int len = 0;
 
 switch (p->pid) {
diff --git a/hw/usb/dev-wacom.c b/hw/usb/dev-wacom.c
index b59504863509..ed687bc9f1eb 100644
--- a/hw/usb/dev-wacom.c
+++ b/hw/usb/dev-wacom.c
@@ -301,7 +301,7 @@ static void usb_wacom_handle_control(USBDevice *dev, 
USBPacket *p,
 static void usb_wacom_handle_data(USBDevice *dev, USBPacket *p)
 {
 USBWacomState *s = (USBWacomState *) dev;
-uint8_t buf[p->iov.size];
+g_autofree uint8_t *buf = g_malloc(p->iov.size);
 int len = 0;
 
 switch (p->pid) {
-- 
2.30.2

Re: [PATCH 04/15] gitlab-ci: Replace YAML anchors by extends (acceptance_test_job)

[Thomas Huth]

On 19/04/2021 01.34, Philippe Mathieu-Daudé wrote:

From: Philippe Mathieu-Daudé 

'extends' is an alternative to using YAML anchors
and is a little more flexible and readable. See:
https://docs.gitlab.com/ee/ci/yaml/#extends

Reviewed-by: Wainer dos Santos Moschetta 
Signed-off-by: Philippe Mathieu-Daudé 
---
  .gitlab-ci.yml | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 11bda3abf33..07e5e737685 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -48,7 +48,7 @@ include:
  # Avoid recompiling by hiding ninja with NINJA=":"
  - make NINJA=":" $MAKE_CHECK_ARGS
  
-.acceptance_template: &acceptance_definition

+.acceptance_test_job_template:
cache:
  key: "${CI_JOB_NAME}-cache"
  paths:
@@ -111,7 +111,7 @@ acceptance-system-alpine:
variables:
  IMAGE: alpine
  MAKE_CHECK_ARGS: check-acceptance
-  <<: *acceptance_definition
+  extends: .acceptance_test_job_template


FYI, I'm getting "YAML invalid" errors when adding this patch to my staging 
branch. I guess you cannot use extends twice in a job and you should extend 
the .acceptance_test_job_template from ..native_build_job_template instead.


 Thomas

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[Cornelia Huck]

On Mon, 3 May 2021 11:17:54 +0200
David Hildenbrand  wrote:

> On 03.05.21 11:14, Cornelia Huck wrote:
> > On Mon, 03 May 2021 10:23:20 +0200
> > Markus Armbruster  wrote:
> >   
> >> David Hildenbrand  writes:
> >>  
> >>> On 03.05.21 07:17, Thomas Huth wrote:  
>  On 03/05/2021 06.58, Markus Armbruster wrote:  
> > Thomas Huth  writes:
> > 
> >> Clang unfortunately does not support generating code for the z900
> >> architecture level and starts with the z10 instead. Thus to be able
> >> to support compiling with Clang, we have to check for the supported
> >> compiler flags. The disadvantage is of course that the bios image
> >> will only run with z10 guest CPUs upwards (which is what most people
> >> use anyway), so just in case let's also emit a warning in that case.  
> >
> > What happens when you try to use this bios with an old CPU anyway?  
> 
>  Interesting question. I was expecting the guest to crash since it would 
>  be
>  using a CPU instruction that is not supported on the old CPU model. But I
>  just gave it a try, and there was no crash. The guest booted just fine.
>  Either Clang only emits instructions that work with the old z900 anyway, 
>  or
>  our emulation in QEMU is imprecise and we allow newer instructions to be
>  executed on old models, too.  
> >>>
> >>> Yes, that's currently still done. We once thought about disabling that
> >>> (there was a patch from Richard), but decided against it because -- back
> >>> then -- the default QEMU model was still very basic and would have
> >>> essentially disabled all more recent instructions as default.
> >>>
> >>> We can most probably do that change soon as we have a "fairly new"
> >>> default QEMU CPU model. I can glue it to my z14 change.  
> >>
> >> In case this makes the BIOS crash with old CPUs: when a guest refuses to
> >> start because the BIOS was compiled the wrong way for it, configure
> >> having told you so back then is not a nice user experience.  Can we do
> >> better, with reasonable effort?  
> > 
> > I fear the experience will be as bad as for any guest that is using
> > features from a newer cpu level (i.e. random crashes when the guest
> > actually tries to use that newer instruction.)
> > 
> > I see two options:
> > - Just try to start and hope that it works.
> > - Deprecate any cpu model older than z10.
> > 
> > Anyone have a better idea? I don't particularly like any of the two.  
> 
> As the default CPU model with new compat machines is >= z13, I wouldn't 
> lose sleep about this. Even with a broken bios one can still boot an 
> external kernel+initrd for testing purposes.

Yes, I do not see many people running into this problem. Still, I fear
it will be hard to figure out what exactly the problem is, when it
arises...

Re: [PATCH 2/5] usb/redir: avoid dynamic stack allocation (CVE-2021-3527)

[Philippe Mathieu-Daudé]

On 5/3/21 11:14 AM, Gerd Hoffmann wrote:
> Use autofree heap allocation instead.
> 
> Signed-off-by: Gerd Hoffmann 

Fixes: 4f4321c11ff ("usb: use iovecs in USBPacket")
Reviewed-by: Philippe Mathieu-Daudé 

> ---
>  hw/usb/redirect.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
> index 17f06f34179a..db1a89a7cc92 100644
> --- a/hw/usb/redirect.c
> +++ b/hw/usb/redirect.c
> @@ -818,7 +818,7 @@ static void usbredir_handle_bulk_data(USBRedirDevice 
> *dev, USBPacket *p,
>  usbredirparser_send_bulk_packet(dev->parser, p->id,
>  &bulk_packet, NULL, 0);
>  } else {
> -uint8_t buf[size];
> +g_autofree uint8_t *buf = g_malloc(size);
>  usb_packet_copy(p, buf, size);
>  usbredir_log_data(dev, "bulk data out:", buf, size);
>  usbredirparser_send_bulk_packet(dev->parser, p->id,
> @@ -923,7 +923,7 @@ static void 
> usbredir_handle_interrupt_out_data(USBRedirDevice *dev,
> USBPacket *p, uint8_t ep)
>  {
>  struct usb_redir_interrupt_packet_header interrupt_packet;
> -uint8_t buf[p->iov.size];
> +g_autofree uint8_t *buf = g_malloc(p->iov.size);
>  
>  DPRINTF("interrupt-out ep %02X len %zd id %"PRIu64"\n", ep,
>  p->iov.size, p->id);
> 

Re: [PATCH 3/4] pc-bios/s390-ccw: Silence GCC 11 stringop-overflow warning

[Philippe Mathieu-Daudé]

On 5/3/21 11:00 AM, Cornelia Huck wrote:
> On Sun,  2 May 2021 19:48:35 +0200
> Thomas Huth  wrote:
> 
>> From: Philippe Mathieu-Daudé 
>>
>> When building on Fedora 34 (gcc version 11.0.0 20210210) we get:
>>
>>   In file included from pc-bios/s390-ccw/main.c:11:
>>   In function ‘memset’,
>>   inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
>>   inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
>>   pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of 
>> size 0 [-Wstringop-overflow=]
>>  28 | p[i] = c;
>> | ~^~~
>>
>> The offending code is:
>>
>>   memset((char *)S390EP, 0, 6);
>>
>> where S390EP is a const address:
>>
>>   #define S390EP 0x10008
>>
>> The compiler doesn't now how big that pointed area is, so assume its
> 
> s/now/know/
> s/assume/it assumes that/

Oops, thanks. Thomas, do you want me to repost this patch fixed?

>> length is zero. This has been reported as BZ#99578 to GCC:
>> "gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a
>> pointer from integer literal"
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578
>>
>> As this warning does us more harm than good in the BIOS code (where
>> lot of direct accesses to low memory are done), silence this warning
>> for all BIOS objects.
>>
>> Suggested-by: Thomas Huth 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> Message-Id: <20210422145911.2513980-1-phi...@redhat.com>
>> Acked-by: Christian Borntraeger 
>> [thuth: Use the pre-existing cc-option macro instead of adding a new one]
>> Signed-off-by: Thomas Huth 
>> ---
>>  pc-bios/s390-ccw/Makefile | 1 +
>>  1 file changed, 1 insertion(+)

Re: [PATCH 1/2] Drop the deprecated lm32 target

[Michael Walle]

Am 2021-05-03 10:40, schrieb Markus Armbruster:

Target lm32 was deprecated in commit d8498005122, v5.2.0.  See there
for rationale.

Some of its code lives on in device models derived from milkymist
ones: hw/char/digic-uart.c and hw/display/bcm2835_fb.c.


yaay ;)


Cc: Michael Walle 
Signed-off-by: Markus Armbruster 


Acked-by: Michael Walle 

Re: [PATCH v2 00/16] virtio-gpu: split into two devices.

[Gerd Hoffmann]

On Fri, Apr 30, 2021 at 07:32:58PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Fri, Apr 30, 2021 at 4:23 PM Gerd Hoffmann  wrote:
> 
> > Currently we have one virtio-gpu device.  Problem with this approach is
> > that if you compile a full-featured qemu you'll get a virtio-gpu device
> > which depends on opengl and virgl, so these dependencies must be
> > installed and the libraries will be loaded into memory even if you don't
> > use virgl.  Also the code is cluttered with #ifdefs and a bit messy.
> >
> > This patch series splits the virtio-gpu device into two:
> >
> >  (1) virtio-gpu-device becomes the non-virgl device, same as
> >  virtio-gpu-device,virgl=off today.
> >  (2) virtio-gpu-gl-device is the new virgl device, same as
> >  virtio-gpu-device,virgl=on today.
> >
> > When compiling qemu without virglrenderer support virtio-gpu-device
> > behavior doesn't change.
> >
> > v2:
> >  - rebase to latest master.
> >  - move pci and vga wrappers to separate modules.
> >  - fix ci failures.
> >
> 
> The patch series looks good.
> 
> But isn't that a breaking change? Any existing user of
> virtio-gpu/vga,virgl=on will no longer get a working setup. Right?

Correct.

> Imho, in
> this case (virgl VM being not very common) the benefit is worth it.
> However, I suggest to keep the 'virgl=' property, and print a deprecation /
> replaced-by warning, falling back to non-virgl/2d mode.

Problem with that is that libvirt uses the virgl property to figure
whenever virtio-gpu-pci / virtio-vga supports virgl or not.  So a dummy
virgl property just for printing a warning message doesn't look like a
good idea to me.

> Or perhaps we could
> have more cleverness to have virgl=on aliasing to the new devices.

If that is doable without ugly hacks I'm open to it.
Suggestions how to do that anyone?

take care,
  Gerd

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[Thomas Huth]

On 03/05/2021 11.14, Cornelia Huck wrote:

On Mon, 03 May 2021 10:23:20 +0200
Markus Armbruster  wrote:


David Hildenbrand  writes:


On 03.05.21 07:17, Thomas Huth wrote:

On 03/05/2021 06.58, Markus Armbruster wrote:

Thomas Huth  writes:
  

Clang unfortunately does not support generating code for the z900
architecture level and starts with the z10 instead. Thus to be able
to support compiling with Clang, we have to check for the supported
compiler flags. The disadvantage is of course that the bios image
will only run with z10 guest CPUs upwards (which is what most people
use anyway), so just in case let's also emit a warning in that case.


What happens when you try to use this bios with an old CPU anyway?


Interesting question. I was expecting the guest to crash since it would be
using a CPU instruction that is not supported on the old CPU model. But I
just gave it a try, and there was no crash. The guest booted just fine.
Either Clang only emits instructions that work with the old z900 anyway, or
our emulation in QEMU is imprecise and we allow newer instructions to be
executed on old models, too.


Yes, that's currently still done. We once thought about disabling that
(there was a patch from Richard), but decided against it because -- back
then -- the default QEMU model was still very basic and would have
essentially disabled all more recent instructions as default.

We can most probably do that change soon as we have a "fairly new"
default QEMU CPU model. I can glue it to my z14 change.


In case this makes the BIOS crash with old CPUs: when a guest refuses to
start because the BIOS was compiled the wrong way for it, configure
having told you so back then is not a nice user experience.  Can we do
better, with reasonable effort?


I fear the experience will be as bad as for any guest that is using
features from a newer cpu level (i.e. random crashes when the guest
actually tries to use that newer instruction.)

I see two options:
- Just try to start and hope that it works.
- Deprecate any cpu model older than z10.

Anyone have a better idea? I don't particularly like any of the two.


I think we should simply continue to build the default bios with GCC and 
-mz900. So the normal user (who does not explicitly use the freshly compiled 
binaries but the pre-built ones) will never experience any problem here. The 
Clang builds are (at least right now) rather only meant for us developers to 
check the sources from time to time with this compiler, to see whether it 
detects some additional issues compared to GCC.


 Thomas

Re: [PATCH 3/4] pc-bios/s390-ccw: Silence GCC 11 stringop-overflow warning

[Thomas Huth]

On 03/05/2021 11.30, Philippe Mathieu-Daudé wrote:

On 5/3/21 11:00 AM, Cornelia Huck wrote:

On Sun,  2 May 2021 19:48:35 +0200
Thomas Huth  wrote:


From: Philippe Mathieu-Daudé 

When building on Fedora 34 (gcc version 11.0.0 20210210) we get:

   In file included from pc-bios/s390-ccw/main.c:11:
   In function ‘memset’,
   inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
   inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
   pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a region of size 
0 [-Wstringop-overflow=]
  28 | p[i] = c;
 | ~^~~

The offending code is:

   memset((char *)S390EP, 0, 6);

where S390EP is a const address:

   #define S390EP 0x10008

The compiler doesn't now how big that pointed area is, so assume its


s/now/know/
s/assume/it assumes that/


Oops, thanks. Thomas, do you want me to repost this patch fixed?


I can fix it up in my tree here, no need to resend.

 Thomas

[Bug 811683] Re: 7400, 7410, 7450 cpus vector have wrong exception prefix at reset

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/85


** Changed in: qemu
   Status: Triaged => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #85
   https://gitlab.com/qemu-project/qemu/-/issues/85

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/811683

Title:
  7400,7410,7450 cpus vector have wrong exception prefix at reset

Status in QEMU:
  Expired

Bug description:
  I have a proprietary ROM implementing system calls that are executed
  via the 'SC' instruction.

  I use qemu-0.14.1,

  qemu-system-ppc -M prep -cpu $CPU -bios my_bios -kernel my_kernel

  That works fine on a 604 (CPU=0x00040103) - but does not on an emulated 7400 
(CPU=0x000c0209) or 7450 (CPU=0x8201). I found that the emulator jumps to 
0x0c00 instead of 0xfff00c00.
  Probably this is due to a wrong setting in target-ppc/translate_init.c:

  init_excp_604() correctly sets env->hreset_vector=0xfff0UL;

  but

  init_excp_7400() says env->hreset_vector=0xUL;

  which seems wrong. (the 7400 manual says a hard-reset jumps initializes the
  prefix to 0xfff0.)

  Likewise, init_excp_7450() (and probably other, related CPUs) are
  wrong.

  Indeed, when I change the value in init_excp_7400() to 0xfff0UL then
  everything works as expected for me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/811683/+subscriptions

[Bug 697510] Re: Machine shut off after tons of lsi_scsi: error: MSG IN data too long

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/84


** Changed in: qemu
   Status: New => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #84
   https://gitlab.com/qemu-project/qemu/-/issues/84

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/697510

Title:
  Machine shut off after tons of lsi_scsi: error: MSG IN data too long

Status in QEMU:
  Expired

Bug description:
  The problem mostly happens during our backup, syslog does not have any
  problematic messages.

  Host is Ubuntu 10.10 x86 64 bits
  Guest is Windows 2003 Server 32 bits
  Using Virtio and Red Hat driver I get a STOP screen 0x10d1 and machine 
either reboot, stay frozen or shut off.
  Using SCSI the machine shuts off and I get tons of message on stdout;

  LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin 
QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 3500 -smp 
4,sockets=4,cores=1,threads=1 -name BMSRV0101 -uuid 
6ccbb5fa-5880-a1ab-3b7a-fb7ccc7c8ccf -nodefaults -chardev 
socket,id=monitor,path=/var/lib/libvirt/qemu/BMSRV0101.monitor,server,nowait 
-mon chardev=monitor,mode=readline -rtc base=localtime -boot c -device 
lsi,id=scsi0,bus=pci.0,addr=0x4 -drive 
if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device 
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive 
file=/dev/vgUbuntu/vmBMSRV0101,if=none,id=drive-scsi0-0-0,boot=on,format=raw 
-device scsi-disk,bus=scsi0.0,scsi-id=0,drive=drive-scsi0-0-0,id=scsi0-0-0 
-device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:5d:7b:07,bus=pci.0,addr=0x3 
-net tap,fd=63,vlan=0,name=hostnet0 -chardev pty,id=serial0 -device 
isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:0 
-vga cirrus -device usb-host,hostbus=002,hostaddr=005,id=hostdev0 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 
  char device redirected to /dev/pts/0
  pci_add_option_rom: failed to find romfile "pxe-virtio.bin"
  husb: open device 2.5
  husb: config #1 need -1
  husb: 1 interfaces claimed for configuration 1
  husb: grabbed usb device 2.5
  husb: config #1 need 1
  husb: 1 interfaces claimed for configuration 1

  lsi_scsi: error: Unimplemented message 0x00
  (x8)

  lsi_scsi: error: MSG IN data too long
  lsi_scsi: error: Unimplemented message 0x00
  (x760)

  lsi_scsi: error: MSG IN data too long
  lsi_scsi: error: MSG IN data too long
  kvm: /build/buildd/qemu-kvm-0.12.5+noroms/hw/lsi53c895a.c:512: lsi_do_dma: 
Assertion `s->current' failed.

  
  I can include minidump file if needed.
  I am currently using IDE and it seems OK.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/697510/+subscriptions

[Bug 645662] Re: QEMU x87 emulation of trig and other complex ops is only at 64-bit precision, not 80-bit

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/83


** Changed in: qemu
   Status: Confirmed => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #83
   https://gitlab.com/qemu-project/qemu/-/issues/83

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/645662

Title:
  QEMU x87 emulation of trig and other complex ops is only at 64-bit
  precision, not 80-bit

Status in QEMU:
  Expired

Bug description:
  When doing the regression tests for Python 3.1.2 with Qemu 0.12.5, (Linux 
version 2.6.26-2-686 (Debian 2.6.26-25lenny1)),
  gcc (Debian 4.3.2-1.1) 4.3.2, Python compiled from sources within qemu,
  3 math tests fail, apparently because the floating point unit is buggy. Qmeu 
was compiled from original sources
  on Debian Lenny with kernel  2.6.34.6 from kernel.org, gcc  (Debian 
4.3.2-1.1) 4.3. 

  Regression testing errors:

  test_cmath
  test test_cmath failed -- Traceback (most recent call last):
File "/root/tools/python3/Python-3.1.2/Lib/test/test_cmath.py", line 364, in
  self.fail(error_message)
  AssertionError: acos0034: acos(complex(-1.0002, 0.0))
  Expected: complex(3.141592653589793, -2.1073424255447014e-08)
  Received: complex(3.141592653589793, -2.1073424338879928e-08)
  Received value insufficiently close to expected value.

  
  test_float
  test test_float failed -- Traceback (most recent call last):
File "/root/tools/python3/Python-3.1.2/Lib/test/test_float.py", line 479, in
  self.assertEqual(s, repr(float(s)))
  AssertionError: '8.72293771110361e+25' != '8.722937711103609e+25'

  
  test_math
  test test_math failed -- multiple errors occurred; run in verbose mode for 
deta

  =>

  runtests.sh -v test_math

  le01:~/tools/python3/Python-3.1.2# ./runtests.sh -v test_math
  test_math BAD
   1 BAD
   0 GOOD
   0 SKIPPED
   1 total
  le01:~/tools/python3/Python-3.1.2#

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/645662/+subscriptions

Re: [PULL 37/64] block/snapshot: Fix fallback

[Kevin Wolf]

Am 01.05.2021 um 00:30 hat Peter Maydell geschrieben:
> On Mon, 7 Sept 2020 at 12:11, Kevin Wolf  wrote:
> >
> > From: Max Reitz 
> >
> > If the top node's driver does not provide snapshot functionality and we
> > want to fall back to a node down the chain, we need to snapshot all
> > non-COW children.  For simplicity's sake, just do not fall back if there
> > is more than one such child.  Furthermore, we really only can fall back
> > to bs->file and bs->backing, because bdrv_snapshot_goto() has to modify
> > the child link (notably, set it to NULL).
> >
> > Suggested-by: Vladimir Sementsov-Ogievskiy 
> > Signed-off-by: Max Reitz 
> > Reviewed-by: Andrey Shinkevich 
> > Reviewed-by: Kevin Wolf 
> 
> Hi; Coverity thinks it's found a problem with this code
> (CID 1452774):

Cc: Max as the patch author

> > @@ -205,39 +258,46 @@ int bdrv_snapshot_goto(BlockDriverState *bs,
> >  return ret;
> >  }
> >
> > -if (bs->file) {
> > -BlockDriverState *file;
> > -QDict *options = qdict_clone_shallow(bs->options);
> > +fallback_ptr = bdrv_snapshot_fallback_ptr(bs);
> > +if (fallback_ptr) {
> > +QDict *options;
> >  QDict *file_options;
> >  Error *local_err = NULL;
> > +BlockDriverState *fallback_bs = (*fallback_ptr)->bs;
> > +char *subqdict_prefix = g_strdup_printf("%s.", 
> > (*fallback_ptr)->name);
> > +
> > +options = qdict_clone_shallow(bs->options);
> >
> > -file = bs->file->bs;
> >  /* Prevent it from getting deleted when detached from bs */
> > -bdrv_ref(file);
> > +bdrv_ref(fallback_bs);
> >
> > -qdict_extract_subqdict(options, &file_options, "file.");
> > +qdict_extract_subqdict(options, &file_options, subqdict_prefix);
> >  qobject_unref(file_options);
> > -qdict_put_str(options, "file", bdrv_get_node_name(file));
> > +g_free(subqdict_prefix);
> > +
> > +qdict_put_str(options, (*fallback_ptr)->name,
> > +  bdrv_get_node_name(fallback_bs));
> >
> >  if (drv->bdrv_close) {
> >  drv->bdrv_close(bs);
> >  }
> > -bdrv_unref_child(bs, bs->file);
> > -bs->file = NULL;
> >
> > -ret = bdrv_snapshot_goto(file, snapshot_id, errp);
> > +bdrv_unref_child(bs, *fallback_ptr);
> > +*fallback_ptr = NULL;
> 
> Here we set *fallback_ptr to NULL...
> 
> > +
> > +ret = bdrv_snapshot_goto(fallback_bs, snapshot_id, errp);
> >  open_ret = drv->bdrv_open(bs, options, bs->open_flags, &local_err);
> >  qobject_unref(options);
> >  if (open_ret < 0) {
> > -bdrv_unref(file);
> > +bdrv_unref(fallback_bs);
> >  bs->drv = NULL;
> >  /* A bdrv_snapshot_goto() error takes precedence */
> >  error_propagate(errp, local_err);
> >  return ret < 0 ? ret : open_ret;
> >  }
> >
> > -assert(bs->file->bs == file);
> > -bdrv_unref(file);
> > +assert(fallback_bs == (*fallback_ptr)->bs);
> 
> ...but here we dereference *fallback_ptr, and Coverity doesn't see
> anything that it recognizes as being able to change it.
> 
> > +bdrv_unref(fallback_bs);
> >  return ret;
> >  }
> 
> False positive, or real issue? (If a false positive, a comment
> explaining what's going on wouldn't go amiss -- as a human reader
> I'm kind of confused about whether there's some kind of hidden
> magic going on here.)

I think it's a false positive because drv->bdrv_open() is supposed to
give it a non-NULL value again. Not sure if we can make the assumption
in every case without checking it, but it feels reasonable to require
that drv->bdrv_open() would return failure otherwise. Max?

Kevin

Re: [PULL 37/64] block/snapshot: Fix fallback

[Max Reitz]

On 03.05.21 11:40, Kevin Wolf wrote:

Am 01.05.2021 um 00:30 hat Peter Maydell geschrieben:

On Mon, 7 Sept 2020 at 12:11, Kevin Wolf  wrote:


From: Max Reitz 

If the top node's driver does not provide snapshot functionality and we
want to fall back to a node down the chain, we need to snapshot all
non-COW children.  For simplicity's sake, just do not fall back if there
is more than one such child.  Furthermore, we really only can fall back
to bs->file and bs->backing, because bdrv_snapshot_goto() has to modify
the child link (notably, set it to NULL).

Suggested-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Max Reitz 
Reviewed-by: Andrey Shinkevich 
Reviewed-by: Kevin Wolf 


Hi; Coverity thinks it's found a problem with this code
(CID 1452774):


Cc: Max as the patch author


Yes, I’m writing a patch to add a comment.


@@ -205,39 +258,46 @@ int bdrv_snapshot_goto(BlockDriverState *bs,
  return ret;
  }

-if (bs->file) {
-BlockDriverState *file;
-QDict *options = qdict_clone_shallow(bs->options);
+fallback_ptr = bdrv_snapshot_fallback_ptr(bs);
+if (fallback_ptr) {
+QDict *options;
  QDict *file_options;
  Error *local_err = NULL;
+BlockDriverState *fallback_bs = (*fallback_ptr)->bs;
+char *subqdict_prefix = g_strdup_printf("%s.", (*fallback_ptr)->name);
+
+options = qdict_clone_shallow(bs->options);

-file = bs->file->bs;
  /* Prevent it from getting deleted when detached from bs */
-bdrv_ref(file);
+bdrv_ref(fallback_bs);

-qdict_extract_subqdict(options, &file_options, "file.");
+qdict_extract_subqdict(options, &file_options, subqdict_prefix);
  qobject_unref(file_options);
-qdict_put_str(options, "file", bdrv_get_node_name(file));
+g_free(subqdict_prefix);
+
+qdict_put_str(options, (*fallback_ptr)->name,
+  bdrv_get_node_name(fallback_bs));

  if (drv->bdrv_close) {
  drv->bdrv_close(bs);
  }
-bdrv_unref_child(bs, bs->file);
-bs->file = NULL;

-ret = bdrv_snapshot_goto(file, snapshot_id, errp);
+bdrv_unref_child(bs, *fallback_ptr);
+*fallback_ptr = NULL;


Here we set *fallback_ptr to NULL...


+
+ret = bdrv_snapshot_goto(fallback_bs, snapshot_id, errp);
  open_ret = drv->bdrv_open(bs, options, bs->open_flags, &local_err);
  qobject_unref(options);
  if (open_ret < 0) {
-bdrv_unref(file);
+bdrv_unref(fallback_bs);
  bs->drv = NULL;
  /* A bdrv_snapshot_goto() error takes precedence */
  error_propagate(errp, local_err);
  return ret < 0 ? ret : open_ret;
  }

-assert(bs->file->bs == file);
-bdrv_unref(file);
+assert(fallback_bs == (*fallback_ptr)->bs);


...but here we dereference *fallback_ptr, and Coverity doesn't see
anything that it recognizes as being able to change it.


+bdrv_unref(fallback_bs);
  return ret;
  }


False positive, or real issue? (If a false positive, a comment
explaining what's going on wouldn't go amiss -- as a human reader
I'm kind of confused about whether there's some kind of hidden
magic going on here.)


I think it's a false positive because drv->bdrv_open() is supposed to
give it a non-NULL value again. Not sure if we can make the assumption
in every case without checking it, but it feels reasonable to require
that drv->bdrv_open() would return failure otherwise. Max?


Yes.  I think it’s sensible to add an *fallback_ptr non-NULL check to 
the assert condition (i.e.,


assert(*fallback_ptr && fallback_bs == (*fallback_ptr)->bs);

), because the intention of the condition is already to verify that 
.bdrv_open() has opened the right node.  So we might say what’s missing 
is to also assert that it has opened any node at all, but if we’re fine 
with asserting that it has opened the right node (which we did since 
7a9e51198c24), we should definitely be fine with asserting that it has 
opened any node at all.


Max

Re: [PATCH 04/15] gitlab-ci: Replace YAML anchors by extends (acceptance_test_job)

[Philippe Mathieu-Daudé]

On 5/3/21 11:22 AM, Thomas Huth wrote:
> On 19/04/2021 01.34, Philippe Mathieu-Daudé wrote:
>> From: Philippe Mathieu-Daudé 
>>
>> 'extends' is an alternative to using YAML anchors
>> and is a little more flexible and readable. See:
>> https://docs.gitlab.com/ee/ci/yaml/#extends
>>
>> Reviewed-by: Wainer dos Santos Moschetta 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>   .gitlab-ci.yml | 20 ++--
>>   1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> index 11bda3abf33..07e5e737685 100644
>> --- a/.gitlab-ci.yml
>> +++ b/.gitlab-ci.yml
>> @@ -48,7 +48,7 @@ include:
>>   # Avoid recompiling by hiding ninja with NINJA=":"
>>   - make NINJA=":" $MAKE_CHECK_ARGS
>>   -.acceptance_template: &acceptance_definition
>> +.acceptance_test_job_template:
>>     cache:
>>   key: "${CI_JOB_NAME}-cache"
>>   paths:
>> @@ -111,7 +111,7 @@ acceptance-system-alpine:
>>     variables:
>>   IMAGE: alpine
>>   MAKE_CHECK_ARGS: check-acceptance
>> -  <<: *acceptance_definition
>> +  extends: .acceptance_test_job_template
> 
> FYI, I'm getting "YAML invalid" errors when adding this patch to my
> staging branch. I guess you cannot use extends twice in a job and you
> should extend the .acceptance_test_job_template from
> ..native_build_job_template instead.

I'm surprised because I tested/used that branch quite a lot.
Maybe a job using anchors got added meanwhile and I need to
rebase?

Re: [PATCH 0/5] usb: fix some memory allocation issues.

[Philippe Mathieu-Daudé]

On 5/3/21 11:14 AM, Gerd Hoffmann wrote:
> 
> 
> Gerd Hoffmann (5):
>   usb/hid: avoid dynamic stack allocation
>   usb/redir: avoid dynamic stack allocation (CVE-2021-3527)
>   usb/mtp: avoid dynamic stack allocation
>   usb/xhci: sanity check packet size
>   usb: limit combined packets to 1 MiB

What about enabling -Wvla by default?

  -Wvla
Warn if a variable-length array is used in the code.

Most of our variable-length stack alloc could use some
LENGTH_MAX definition or use the heap:

[2/1072] Compiling C object libqemuutil.a.p/util_iov.c.o
FAILED: libqemuutil.a.p/util_iov.c.o
util/iov.c: In function ‘qemu_iovec_clone’:
util/iov.c:626:5: error: ISO C90 forbids variable length array
‘sortelems’ [-Werror=vla]
  626 | IOVectorSortElem sortelems[src->niov];
  | ^~~~
cc1: all warnings being treated as errors
[125/1072] Compiling C object libio.fa.p/io_channel-websock.c.o
FAILED: libio.fa.p/io_channel-websock.c.o
io/channel-websock.c: In function
‘qio_channel_websock_handshake_send_res_ok’:
io/channel-websock.c:350:23: error: ISO C90 forbids array ‘combined_key’
whose size cannot be evaluated [-Werror=vla]
  350 |   QIO_CHANNEL_WEBSOCK_GUID_LEN + 1];
  |   ^~~~
cc1: all warnings being treated as errors
[177/1072] Compiling C object libblock.fa.p/block_vpc.c.o
FAILED: libblock.fa.p/block_vpc.c.o
block/vpc.c: In function ‘get_image_offset’:
block/vpc.c:512:9: error: ISO C90 forbids variable length array ‘bitmap’
[-Werror=vla]
  512 | uint8_t bitmap[s->bitmap_size];
  | ^~~
block/vpc.c: In function ‘alloc_block’:
block/vpc.c:559:5: error: ISO C90 forbids variable length array ‘bitmap’
[-Werror=vla]
  559 | uint8_t bitmap[s->bitmap_size];
  | ^~~
cc1: all warnings being treated as errors
[278/1072] Compiling C object libcommon.fa.p/ui_vnc-enc-hextile.c.o
FAILED: libcommon.fa.p/ui_vnc-enc-hextile.c.o
In file included from ui/vnc-enc-hextile.c:37:
ui/vnc-enc-hextile-template.h: In function ‘send_hextile_tile_32’:
ui/vnc-enc-hextile-template.h:28:5: error: ISO C90 forbids variable
length array ‘data’ [-Werror=vla]
   28 | uint8_t data[(vs->client_pf.bytes_per_pixel + 2) * 16 * 16];
  | ^~~
In file included from ui/vnc-enc-hextile.c:42:
ui/vnc-enc-hextile-template.h: In function ‘send_hextile_tile_generic_32’:
ui/vnc-enc-hextile-template.h:28:5: error: ISO C90 forbids variable
length array ‘data’ [-Werror=vla]
   28 | uint8_t data[(vs->client_pf.bytes_per_pixel + 2) * 16 * 16];
  | ^~~
cc1: all warnings being treated as errors
[283/1072] Compiling C object libcommon.fa.p/ui_vnc-enc-tight.c.o
FAILED: libcommon.fa.p/ui_vnc-enc-tight.c.o
ui/vnc-enc-tight.c: In function ‘send_palette_rect’:
ui/vnc-enc-tight.c:1101:9: error: ISO C90 forbids variable length array
‘header’ [-Werror=vla]
 1101 | uint32_t header[palette_size(palette)];
  | ^~~~
ui/vnc-enc-tight.c:1118:9: error: ISO C90 forbids variable length array
‘header’ [-Werror=vla]
 1118 | uint16_t header[palette_size(palette)];
  | ^~~~
cc1: all warnings being treated as errors
[353/1072] Compiling C object libcommon.fa.p/net_dump.c.o
FAILED: libcommon.fa.p/net_dump.c.o
net/dump.c: In function ‘dump_receive_iov’:
net/dump.c:71:12: error: ISO C90 forbids variable length array ‘dumpiov’
[-Werror=vla]
   71 | struct iovec dumpiov[cnt + 1];
  |^
cc1: all warnings being treated as errors
[375/1072] Compiling C object libcommon.fa.p/net_tap.c.o
FAILED: libcommon.fa.p/net_tap.c.o
net/tap.c: In function ‘tap_receive_iov’:
net/tap.c:123:12: error: ISO C90 forbids variable length array
‘iov_copy’ [-Werror=vla]
  123 | struct iovec iov_copy[iovcnt + 1];
  |^
cc1: all warnings being treated as errors
[451/1072] Compiling C object libcommon.fa.p/hw_block_nvme.c.o
FAILED: libcommon.fa.p/hw_block_nvme.c.o
hw/block/nvme.c: In function ‘nvme_map_prp’:
hw/block/nvme.c:655:13: error: ISO C90 forbids variable length array
‘prp_list’ [-Werror=vla]
  655 | uint64_t prp_list[n->max_prp_ents];
  | ^~~~
hw/block/nvme.c: In function ‘nvme_map_sgl’:
hw/block/nvme.c:817:5: error: ISO C90 forbids variable length array
‘segment’ [-Werror=vla]
  817 | NvmeSglDescriptor segment[SEG_CHUNK_SIZE], *sgld, *last_sgld;
  | ^
hw/block/nvme.c: In function ‘nvme_dsm’:
hw/block/nvme.c:2513:9: error: ISO C90 forbids variable length array
‘range’ [-Werror=vla]
 2513 | NvmeDsmRange range[nr];
  | ^~~~
cc1: all warnings being treated as errors
[653/1072] Compiling C object libcommon.fa.p/hw_net_e1000e_core.c.o
FAILED: libcommon.fa.p/hw_net_e1000e_core.c.o
hw/net/e1000e_core.c: In function ‘e1000e_receive_iov’:
hw/net/e1000e_core.c:1632:5: error: ISO C90 forbids variable length
array ‘min_buf’ [-Werror=vla]
 1632 | uint8_t min_buf[min_buf_size];
  | ^~

Re: [PATCH 3/4] pc-bios/s390-ccw: Silence GCC 11 stringop-overflow warning

[Philippe Mathieu-Daudé]

On 5/3/21 11:31 AM, Thomas Huth wrote:
> On 03/05/2021 11.30, Philippe Mathieu-Daudé wrote:
>> On 5/3/21 11:00 AM, Cornelia Huck wrote:
>>> On Sun,  2 May 2021 19:48:35 +0200
>>> Thomas Huth  wrote:
>>>
 From: Philippe Mathieu-Daudé 

 When building on Fedora 34 (gcc version 11.0.0 20210210) we get:

    In file included from pc-bios/s390-ccw/main.c:11:
    In function ‘memset’,
    inlined from ‘boot_setup’ at pc-bios/s390-ccw/main.c:185:5,
    inlined from ‘main’ at pc-bios/s390-ccw/main.c:288:5:
    pc-bios/s390-ccw/libc.h:28:14: warning: writing 1 byte into a
 region of size 0 [-Wstringop-overflow=]
   28 | p[i] = c;
  | ~^~~

 The offending code is:

    memset((char *)S390EP, 0, 6);

 where S390EP is a const address:

    #define S390EP 0x10008

 The compiler doesn't now how big that pointed area is, so assume its
>>>
>>> s/now/know/
>>> s/assume/it assumes that/
>>
>> Oops, thanks. Thomas, do you want me to repost this patch fixed?
> 
> I can fix it up in my tree here, no need to resend.

Great, thank you!

Phil.

[PATCH] block/snapshot: Clarify goto fallback behavior

[Max Reitz]

In the bdrv_snapshot_goto() fallback code, we work with a pointer to
either bs->file or bs->backing.  We close that child, close the node
(with .bdrv_close()), apply the snapshot on the child node, and then
re-open the node (with .bdrv_open()).

In order for .bdrv_open() to attach the same child node that we had
before, we pass "file={child-node}" or "backing={child-node}" to it.
Therefore, when .bdrv_open() has returned success, we can assume that
bs->file or bs->backing (respectively) points to our original child
again.  This is verified by an assertion.

All of this is not immediately clear from a quick glance at the code,
so add a comment to the assertion what it is for, and why it is valid.
It certainly confused Coverity.

Reported-by: Coverity (CID 1452774)
Signed-off-by: Max Reitz 
---
 block/snapshot.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/block/snapshot.c b/block/snapshot.c
index e8ae9a28c1..cce5e35b35 100644
--- a/block/snapshot.c
+++ b/block/snapshot.c
@@ -275,13 +275,16 @@ int bdrv_snapshot_goto(BlockDriverState *bs,
 qobject_unref(file_options);
 g_free(subqdict_prefix);
 
+/* Force .bdrv_open() below to re-attach fallback_bs on *fallback_ptr 
*/
 qdict_put_str(options, (*fallback_ptr)->name,
   bdrv_get_node_name(fallback_bs));
 
+/* Now close bs, apply the snapshot on fallback_bs, and re-open bs */
 if (drv->bdrv_close) {
 drv->bdrv_close(bs);
 }
 
+/* .bdrv_open() will re-attach it */
 bdrv_unref_child(bs, *fallback_ptr);
 *fallback_ptr = NULL;
 
@@ -296,7 +299,16 @@ int bdrv_snapshot_goto(BlockDriverState *bs,
 return ret < 0 ? ret : open_ret;
 }
 
-assert(fallback_bs == (*fallback_ptr)->bs);
+/*
+ * fallback_ptr is &bs->file or &bs->backing.  *fallback_ptr
+ * was closed above and set to NULL, but the .bdrv_open() call
+ * has opened it again, because we set the respective option
+ * (with the qdict_put_str() call above).
+ * Assert that .bdrv_open() has attached some child on
+ * *fallback_ptr, and that it has attached the one we wanted
+ * it to (i.e., fallback_bs).
+ */
+assert(*fallback_ptr && fallback_bs == (*fallback_ptr)->bs);
 bdrv_unref(fallback_bs);
 return ret;
 }
-- 
2.31.1

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[Cornelia Huck]

On Mon, 3 May 2021 11:31:00 +0200
Thomas Huth  wrote:

> On 03/05/2021 11.14, Cornelia Huck wrote:
> > On Mon, 03 May 2021 10:23:20 +0200
> > Markus Armbruster  wrote:
> >   
> >> David Hildenbrand  writes:
> >>  
> >>> On 03.05.21 07:17, Thomas Huth wrote:  
>  On 03/05/2021 06.58, Markus Armbruster wrote:  
> > Thomas Huth  writes:
> > 
> >> Clang unfortunately does not support generating code for the z900
> >> architecture level and starts with the z10 instead. Thus to be able
> >> to support compiling with Clang, we have to check for the supported
> >> compiler flags. The disadvantage is of course that the bios image
> >> will only run with z10 guest CPUs upwards (which is what most people
> >> use anyway), so just in case let's also emit a warning in that case.  
> >
> > What happens when you try to use this bios with an old CPU anyway?  
> 
>  Interesting question. I was expecting the guest to crash since it would 
>  be
>  using a CPU instruction that is not supported on the old CPU model. But I
>  just gave it a try, and there was no crash. The guest booted just fine.
>  Either Clang only emits instructions that work with the old z900 anyway, 
>  or
>  our emulation in QEMU is imprecise and we allow newer instructions to be
>  executed on old models, too.  
> >>>
> >>> Yes, that's currently still done. We once thought about disabling that
> >>> (there was a patch from Richard), but decided against it because -- back
> >>> then -- the default QEMU model was still very basic and would have
> >>> essentially disabled all more recent instructions as default.
> >>>
> >>> We can most probably do that change soon as we have a "fairly new"
> >>> default QEMU CPU model. I can glue it to my z14 change.  
> >>
> >> In case this makes the BIOS crash with old CPUs: when a guest refuses to
> >> start because the BIOS was compiled the wrong way for it, configure
> >> having told you so back then is not a nice user experience.  Can we do
> >> better, with reasonable effort?  
> > 
> > I fear the experience will be as bad as for any guest that is using
> > features from a newer cpu level (i.e. random crashes when the guest
> > actually tries to use that newer instruction.)
> > 
> > I see two options:
> > - Just try to start and hope that it works.
> > - Deprecate any cpu model older than z10.
> > 
> > Anyone have a better idea? I don't particularly like any of the two.  
> 
> I think we should simply continue to build the default bios with GCC and 
> -mz900. So the normal user (who does not explicitly use the freshly compiled 
> binaries but the pre-built ones) will never experience any problem here. The 
> Clang builds are (at least right now) rather only meant for us developers to 
> check the sources from time to time with this compiler, to see whether it 
> detects some additional issues compared to GCC.

OK, sounds reasonable to me.

Re: [PATCH 2/5] usb/redir: avoid dynamic stack allocation (CVE-2021-3527)

[Philippe Mathieu-Daudé]

On 5/3/21 11:27 AM, Philippe Mathieu-Daudé wrote:
> On 5/3/21 11:14 AM, Gerd Hoffmann wrote:
>> Use autofree heap allocation instead.
>>
>> Signed-off-by: Gerd Hoffmann 
> 
> Fixes: 4f4321c11ff ("usb: use iovecs in USBPacket")
> Reviewed-by: Philippe Mathieu-Daudé 

Hmm there is still another use:

 618 if (dev->endpoint[EP2I(ep)].iso_started) {
 619 struct usb_redir_iso_packet_header iso_packet = {
 620 .endpoint = ep,
 621 .length = p->iov.size
 622 };
 623 uint8_t buf[p->iov.size];

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[Cornelia Huck]

On Sun,  2 May 2021 19:48:36 +0200
Thomas Huth  wrote:

> Clang unfortunately does not support generating code for the z900
> architecture level and starts with the z10 instead. Thus to be able
> to support compiling with Clang, we have to check for the supported
> compiler flags. The disadvantage is of course that the bios image
> will only run with z10 guest CPUs upwards (which is what most people
> use anyway), so just in case let's also emit a warning in that case.

Maybe add a note here that the pre-built image will continue to be
built with gcc for the z900, so for most people nothing will change?

> 
> Signed-off-by: Thomas Huth 
> ---
>  configure | 9 -
>  pc-bios/s390-ccw/Makefile | 3 ++-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 

Reviewed-by: Cornelia Huck 

[Bug 922076] Re: doesn't clear screen on boot

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/87


** Changed in: qemu
   Status: Triaged => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #87
   https://gitlab.com/qemu-project/qemu/-/issues/87

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/922076

Title:
  doesn't clear screen on boot

Status in QEMU:
  Expired

Bug description:
  When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", Qemu
  window appears and it shows message "Starting Seabios (version
  0.5.1-2010...)", and then Linux writes messages like "Loading, please
  wait..." on top of previous message!

  For example, I can see "Loading, please wait...on 0.5.1-2010...)"

  So, Qemu doesn't clean screan before booting OS.

  Moreover, when I start Linux via "qemu /disk-image", Qemu shows
  "Starting Seabios (version 0.5.1-2010...)", then switches to graphical
  mode, shows GRUB, then switches back to text mode and shows "Starting
  Seabios" again! And again Linux prints messages on top of Seabios
  messages, and we see a mix of symbols on screen.

  Also, I found another bug! I am learning now to write kernels. And I
  see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't
  clean first charaster of screen in Qemu in "-curses" mode! If I want
  to real clean this charaster, I must type "*(char *)0xb8000 = ' '".

  I attach a kernel (x86, multiboot) with this bug. Just type "make"
  (you need gcc) and "qemu -curses -kernel kernel". You will see that
  screen is not cleared, but kernel tries to clean it. If you change 0
  to ' ', all will work!

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/922076/+subscriptions

[Bug 925405] Re: VNC server does not work with Mac Screen Sharing

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/88


** Changed in: qemu
   Status: Confirmed => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #88
   https://gitlab.com/qemu-project/qemu/-/issues/88

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/925405

Title:
  VNC server does not work with Mac Screen Sharing

Status in QEMU:
  Expired
Status in Ubuntu:
  Invalid

Bug description:
  When connecting to a QEMU instance from a Mac using any VNC settings
  on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection
  is attempted but the negotiation never finishes.

  I've verified this when building QEMU from source (1.0 and HEAD) on
  Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian
  (Lenny) packages.

  It does not matter whether I specify authentication (or anything else)
  on QEMU's side, the behavior is always the same - I see the connection
  being established using netstat and tcpdump, but QEMU does not seem to
  send back any pixmap data after the connection setup.

  Best guess as to why this happens is that the VNC negotiation on QEMU
  does not like the protocol version and VNC encoding sent by the Mac's
  built-in VNC client, or that its negotiation logic is subtly broken. I
  appreciate that it's not meant to be a full VNC server, but it
  prevents me from using it remotely until a stable Mac build is
  feasible.

  Background info:

  Mac OS X includes a VNC client called Screen Sharing that you can
  invoke in two different ways:

  * At a terminal, by typing "open vnc://hostname:tcp_port"
  * From any URI-enabled field (such as the Safari URI field), where you can 
just type the URI as vnc://hostname:tcp_port

  Please do not confuse the enhanced VNC protocol Apple Remote Desktop
  uses with Screen Sharing - they are not mutually exclusive, but they
  are not incompatible either, since what Apple does is to negotiate
  extra pixmap encoding and authentication options - I use Screen
  Sharing to access many VNC servers such as vnc4server, tightvncserver,
  vino, etc. without any issues whatsoever, so the issue I'm reporting
  is not an issue with Apple's implementation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/925405/+subscriptions

Re: [PATCH v2 2/3] hw/pci-host/raven: Manually reset the OR_IRQ device

[Philippe Mathieu-Daudé]

On 5/2/21 10:45 PM, Peter Maydell wrote:
> On Sun, 2 May 2021 at 21:31, Philippe Mathieu-Daudé  wrote:
>>
>> The OR_IRQ device is bus-less, thus isn't reset automatically.
>> Add the raven_pcihost_reset() handler to manually reset the OR IRQ.
>>
>> Fixes: f40b83a4e31 ("40p: use OR gate to wire up raven PCI interrupts")
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  hw/pci-host/prep.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/hw/pci-host/prep.c b/hw/pci-host/prep.c
>> index 0a9162fba97..7481bbf99d4 100644
>> --- a/hw/pci-host/prep.c
>> +++ b/hw/pci-host/prep.c
>> @@ -230,6 +230,15 @@ static void raven_change_gpio(void *opaque, int n, int 
>> level)
>>  s->contiguous_map = level;
>>  }
>>
>> +static void raven_pcihost_reset_enter(Object *obj, ResetType type)
>> +{
>> +PREPPCIState *s = RAVEN_PCI_HOST_BRIDGE(obj);
>> +
>> +if (!s->is_legacy_prep) {
>> +device_cold_reset(DEVICE(&s->or_irq));
>> +}
>> +}
>> +
>>  static void raven_pcihost_realizefn(DeviceState *d, Error **errp)
>>  {
>>  SysBusDevice *dev = SYS_BUS_DEVICE(d);
>> @@ -419,11 +428,13 @@ static Property raven_pcihost_properties[] = {
>>  static void raven_pcihost_class_init(ObjectClass *klass, void *data)
>>  {
>>  DeviceClass *dc = DEVICE_CLASS(klass);
>> +ResettableClass *rc = RESETTABLE_CLASS(klass);
>>
>>  set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
>>  dc->realize = raven_pcihost_realizefn;
>>  device_class_set_props(dc, raven_pcihost_properties);
>>  dc->fw_name = "pci";
>> +rc->phases.enter = raven_pcihost_reset_enter;
>>  }
> 
> Why does this device have an OR gate rather than having its
> map_irq function say "all PCI IRQs go to interrupt 0" ?
> (The PCI core code provides you the "OR" functionality for
> free, because it has to do that anyway for when multiple PCI
> cards share a PCI IRQ -- see pci_change_irq_level() and
> pci_bus_change_irq_level().
> 
> Supplementary question: why does the legacy_prep setup create 4
> outbound sysbus IRQs when the map_irq function can only ever
> return 0 or 1 ?

I'll let the maintainers have a look (I'm just trying to pay the
technical debts so we can remove legacy/deprecated API and move
forward).

Thanks for the careful analysis,

Phil.

[Bug 812398] Re: powerpc 7450 MMU initialization broken

[Thomas Huth]

This is an automated cleanup. This bug report has been moved to QEMU's
new bug tracker on gitlab.com and thus gets marked as 'expired' now.
Please continue with the discussion here:

 https://gitlab.com/qemu-project/qemu/-/issues/86


** Changed in: qemu
   Status: Triaged => Expired

** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #86
   https://gitlab.com/qemu-project/qemu/-/issues/86

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/812398

Title:
  powerpc 7450 MMU initialization broken

Status in QEMU:
  Expired

Bug description:
  The 7540 family of PPCs' MMU can update TLBs using hardware search
  (like a 604 or 7400) but also using a software algorithm. The
  mechanism used is defined by HID0[STEN].

  By default (CPU reset) HID0 is set to 0x8000 (BTW; another small bug, 
qemu doesn't set the hardwired MSB), hence
  the software-table lookup feature is *disabled*. However, the default (and 
immutable) 'mmu_model' for this CPU family is POWERC_MMU_SOFT_74XX which choses 
the soft TLB replacement scheme.

  To fix this:

  1) the initial mmu_model for the 7450 family (includes 7441, 7445, 7451, 
7455, 7457, 7447, 7448) should be: POWERPC_MMU_32B
  2) when HID0[STEN] is written then the mmu_model should be changed 
accordingly (I'm not familiar enough with the qemu internal state to judge if 
any cached state would have to be updated).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/812398/+subscriptions

[Bug 721825] Re: VDI block driver bugs

[Thomas Huth]

Hi Stefan (Weil) - this bug is now assigned to you since more than 10
years ... do you still plan to tackle it at some point in time? If not,
I'd suggest to unassign it. Also, it's been four years again since the
last comment ... should we maybe close this as "Wont Fix" ?

** Changed in: qemu
   Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/721825

Title:
  VDI block driver bugs

Status in QEMU:
  Incomplete

Bug description:
  Chunqiang Tang reports the following issues with the VDI block driver,
  these are present in QEMU 0.14:

  "Bug 1. The most serious bug is caused by race condition in updating a new 
  bmap entry in memory and on disk. Considering the following operation 
  sequence. 
O1: VM issues a write to sector X
O2: VDI allocates a new bmap entry and updates in-memory s->bmap
O3: VDI writes data to disk
O4: The disk I/O for writing sector X fails
O5: VDI reports error to VM and returns.

  Note that the bmap entry is updated in memory, but not persisted on disk. 
  Now consider another write that immediately follows:
P1: VM issues a write to sector X+1, which locates in the same block as 
  the previously used sector X.
P2: s->bmap already has one entry for the block, and hence VDI writes 
  data directly without persisting the new s->bmap entry on disk.
P3: The write disk I/O succeeds
P4: VDI report success to VM, but the bitmap entry is still not 
  persisted on disk.

  Now suppose the VM powers off gracefully (i.e., the QEMU process quits) 
  and reboots. The second write to sector X+1, which is reported as finished 
  successfully, is simply lost, because the corresponding in-memory s->bmap 
  entry is never persisted on disk. This is exactly what FVD's testing tool 
  discovers. After the block device is closed and then re-opened, disk 
  content verification fails.

  This is just one example of the problem. Race condition plus host crash 
  also causes problems. Consider another example below.
Q1: VM issues a write to sector X
Q2: VDI allocates a new bmap entry and updates in-memory s->bmap
Q3: VDI writes sector X to disk and waits for the callback
Q4: VM issues a write to another sector X+1, which is in the same block 
  as sector X.
Q5: VDI sees the bitmap entry in s->bmap is already allocated, and 
  writes sector X+1 to disk.
Q6: Write to sector X+1 finishes, and VDI's callback is invoked.
Q7: VDI acknowledges to the VM the completion of writing sector X+1
Q8: After observing the completion of writing sector X+1, VM issues a 
  flush to ensure that sector X+1 is persisted on disk.
Q9: VDI finishes the flush and acknowledge the completion of the 
  operation.
Q10: ... (some other arbitrary operations, but the disk I/O for writing 
  sector X is still not finished)
Q11: The host crashes

  Now the new bitmap entry is not persisted on disk, while both writing to 
  sector X+1 and the flush has been acknowledged as finished. Sector X+1 is 
  lost, which is a corruption. This problem exists even if it uses O_DSYNC. 
  The root cause of the problem is that, if a request updates in-memory 
  s->bmap, another request that sees this update assumes that the update is 
  already persisted on disk, which is not.

  Bug 2: Similar to the bugs the FVD testing tool found for QCOW2, there are 
  several cases of the code below on failure handling path without setting 
  error return code, which mistakenly reports failure as success. This 
  mistake is caught by FVD when doing image content validation.
 if (acb->hd_aiocb == NULL) {
 /* missing ret = -EIO; */
  goto done; 
  } 

  Bug 3: Similar to the bugs the FVD testing tool found for QCOW2, 
  vdi_aio_cancel does not perform a complete clean up and there are several 
  related bugs. First, memory buffer is not freed, acb->orig_buf and 
  acb->block_buffer. Second, acb->bh is not cancelled. Third, 
  vdi_aio_setup() does not initialize acb->bh to NULL so that when a request 
  acb is cancelled and then later reused for another request, its acb->bh != 
  NULL and the new request fails in  vdi_schedule_bh(). This is caught by 
  FVD's testing tool, when it observes that no I/O failure is injected but 
  VDI reports a failed I/O request, which indicates a bug in the driver."

  http://permalink.gmane.org/gmane.comp.emulators.qemu/94340

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/721825/+subscriptions

Re: [PATCH 4/4] pc-bios/s390-ccw: Allow building with Clang, too

[Christian Borntraeger]

On 03.05.21 11:31, Thomas Huth wrote:

On 03/05/2021 11.14, Cornelia Huck wrote:

On Mon, 03 May 2021 10:23:20 +0200
Markus Armbruster  wrote:


David Hildenbrand  writes:


On 03.05.21 07:17, Thomas Huth wrote:

On 03/05/2021 06.58, Markus Armbruster wrote:

Thomas Huth  writes:

Clang unfortunately does not support generating code for the z900
architecture level and starts with the z10 instead. Thus to be able
to support compiling with Clang, we have to check for the supported
compiler flags. The disadvantage is of course that the bios image
will only run with z10 guest CPUs upwards (which is what most people
use anyway), so just in case let's also emit a warning in that case.


What happens when you try to use this bios with an old CPU anyway?


Interesting question. I was expecting the guest to crash since it would be
using a CPU instruction that is not supported on the old CPU model. But I
just gave it a try, and there was no crash. The guest booted just fine.
Either Clang only emits instructions that work with the old z900 anyway, or
our emulation in QEMU is imprecise and we allow newer instructions to be
executed on old models, too.


Yes, that's currently still done. We once thought about disabling that
(there was a patch from Richard), but decided against it because -- back
then -- the default QEMU model was still very basic and would have
essentially disabled all more recent instructions as default.

We can most probably do that change soon as we have a "fairly new"
default QEMU CPU model. I can glue it to my z14 change.


In case this makes the BIOS crash with old CPUs: when a guest refuses to
start because the BIOS was compiled the wrong way for it, configure
having told you so back then is not a nice user experience.  Can we do
better, with reasonable effort?


I fear the experience will be as bad as for any guest that is using
features from a newer cpu level (i.e. random crashes when the guest
actually tries to use that newer instruction.)

I see two options:
- Just try to start and hope that it works.
- Deprecate any cpu model older than z10.

Anyone have a better idea? I don't particularly like any of the two.


I think we should simply continue to build the default bios with GCC and 
-mz900. So the normal user (who does not explicitly use the freshly compiled 
binaries but the pre-built ones) will never experience any problem here. The 
Clang builds are (at least right now) rather only meant for us developers to 
check the sources from time to time with this compiler, to see whether it 
detects some additional issues compared to GCC.


Ack.

Re: [PULL 37/64] block/snapshot: Fix fallback

[Kevin Wolf]

Am 03.05.2021 um 11:45 hat Max Reitz geschrieben:
> On 03.05.21 11:40, Kevin Wolf wrote:
> > Am 01.05.2021 um 00:30 hat Peter Maydell geschrieben:
> > > On Mon, 7 Sept 2020 at 12:11, Kevin Wolf  wrote:
> > > > 
> > > > From: Max Reitz 
> > > > 
> > > > If the top node's driver does not provide snapshot functionality and we
> > > > want to fall back to a node down the chain, we need to snapshot all
> > > > non-COW children.  For simplicity's sake, just do not fall back if there
> > > > is more than one such child.  Furthermore, we really only can fall back
> > > > to bs->file and bs->backing, because bdrv_snapshot_goto() has to modify
> > > > the child link (notably, set it to NULL).
> > > > 
> > > > Suggested-by: Vladimir Sementsov-Ogievskiy 
> > > > Signed-off-by: Max Reitz 
> > > > Reviewed-by: Andrey Shinkevich 
> > > > Reviewed-by: Kevin Wolf 
> > > 
> > > Hi; Coverity thinks it's found a problem with this code
> > > (CID 1452774):
> > 
> > Cc: Max as the patch author
> 
> Yes, I’m writing a patch to add a comment.
> 
> > > > @@ -205,39 +258,46 @@ int bdrv_snapshot_goto(BlockDriverState *bs,
> > > >   return ret;
> > > >   }
> > > > 
> > > > -if (bs->file) {
> > > > -BlockDriverState *file;
> > > > -QDict *options = qdict_clone_shallow(bs->options);
> > > > +fallback_ptr = bdrv_snapshot_fallback_ptr(bs);
> > > > +if (fallback_ptr) {
> > > > +QDict *options;
> > > >   QDict *file_options;
> > > >   Error *local_err = NULL;
> > > > +BlockDriverState *fallback_bs = (*fallback_ptr)->bs;
> > > > +char *subqdict_prefix = g_strdup_printf("%s.", 
> > > > (*fallback_ptr)->name);
> > > > +
> > > > +options = qdict_clone_shallow(bs->options);
> > > > 
> > > > -file = bs->file->bs;
> > > >   /* Prevent it from getting deleted when detached from bs */
> > > > -bdrv_ref(file);
> > > > +bdrv_ref(fallback_bs);
> > > > 
> > > > -qdict_extract_subqdict(options, &file_options, "file.");
> > > > +qdict_extract_subqdict(options, &file_options, 
> > > > subqdict_prefix);
> > > >   qobject_unref(file_options);
> > > > -qdict_put_str(options, "file", bdrv_get_node_name(file));
> > > > +g_free(subqdict_prefix);
> > > > +
> > > > +qdict_put_str(options, (*fallback_ptr)->name,
> > > > +  bdrv_get_node_name(fallback_bs));
> > > > 
> > > >   if (drv->bdrv_close) {
> > > >   drv->bdrv_close(bs);
> > > >   }
> > > > -bdrv_unref_child(bs, bs->file);
> > > > -bs->file = NULL;
> > > > 
> > > > -ret = bdrv_snapshot_goto(file, snapshot_id, errp);
> > > > +bdrv_unref_child(bs, *fallback_ptr);
> > > > +*fallback_ptr = NULL;
> > > 
> > > Here we set *fallback_ptr to NULL...
> > > 
> > > > +
> > > > +ret = bdrv_snapshot_goto(fallback_bs, snapshot_id, errp);
> > > >   open_ret = drv->bdrv_open(bs, options, bs->open_flags, 
> > > > &local_err);
> > > >   qobject_unref(options);
> > > >   if (open_ret < 0) {
> > > > -bdrv_unref(file);
> > > > +bdrv_unref(fallback_bs);
> > > >   bs->drv = NULL;
> > > >   /* A bdrv_snapshot_goto() error takes precedence */
> > > >   error_propagate(errp, local_err);
> > > >   return ret < 0 ? ret : open_ret;
> > > >   }
> > > > 
> > > > -assert(bs->file->bs == file);
> > > > -bdrv_unref(file);
> > > > +assert(fallback_bs == (*fallback_ptr)->bs);
> > > 
> > > ...but here we dereference *fallback_ptr, and Coverity doesn't see
> > > anything that it recognizes as being able to change it.
> > > 
> > > > +bdrv_unref(fallback_bs);
> > > >   return ret;
> > > >   }
> > > 
> > > False positive, or real issue? (If a false positive, a comment
> > > explaining what's going on wouldn't go amiss -- as a human reader
> > > I'm kind of confused about whether there's some kind of hidden
> > > magic going on here.)
> > 
> > I think it's a false positive because drv->bdrv_open() is supposed to
> > give it a non-NULL value again. Not sure if we can make the assumption
> > in every case without checking it, but it feels reasonable to require
> > that drv->bdrv_open() would return failure otherwise. Max?
> 
> Yes.  I think it’s sensible to add an *fallback_ptr non-NULL check to the
> assert condition (i.e.,
> 
> assert(*fallback_ptr && fallback_bs == (*fallback_ptr)->bs);
> 
> ), because the intention of the condition is already to verify that
> .bdrv_open() has opened the right node.  So we might say what’s missing is
> to also assert that it has opened any node at all, but if we’re fine with
> asserting that it has opened the right node (which we did since
> 7a9e51198c24), we should definitely be fine with asserting that it has
> opened any node at all.

True, that's a good point.

Kevin

[Bug 1776478] Re: Getting qemu: uncaught target signal 6 when running lv2 plugin cross-compilation

[Peter Maydell]

Well, first try with QEMU 6.0 and see if it's still present...

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1776478

Title:
  Getting qemu: uncaught target signal 6 when running  lv2 plugin cross-
  compilation

Status in QEMU:
  Incomplete

Bug description:
  Hey,
  I am part of the Zynthian team and we use qemu-arm-static to cross compile 
lv2 audio plugins.

  When running a compilation of DISTRHO-Ports we get:

  lv2_ttl_generator: pthread_mutex_lock.c:81: __pthread_mutex_lock: Assertion 
`mutex->__data.__owner == 0' failed.
  qemu: uncaught target signal 6 (Aborted) - core dumped
  ./scripts/generate-ttl.sh: line 27: 16524 Aborted $GEN ./$FILE
  Makefile:62: recipe for target 'gen_lv2' failed
  make[1]: *** [gen_lv2] Error 134
  make[1]: Leaving directory '/home/pi/zynthian-sw/plugins/DISTRHO-Ports'
  Makefile:104: recipe for target 'lv2' failed
  make: *** [lv2] Error 2

  
  lv2_ttl_generator source is here:
  https://github.com/DISTRHO/DISTRHO-Ports/tree/master/libs/lv2-ttl-generator

  The command that is ruining is
  lv2_ttl_generator ./TAL-Filter-2.so 

  And ./TAL-Filter-2.so source is here:
  https://github.com/DISTRHO/DISTRHO-Ports/tree/master/ports/tal-filter-2/source


  Is there a way to debug what is going on?
  This runs fine on a Raspberrypi which is armv7

  A workaround would also help.

  
  Bug in Zynthian:
  https://github.com/zynthian/zynthian-sys/issues/59
  Bug in DISTRHO-Ports:
  https://github.com/DISTRHO/DISTRHO-Ports/issues/29

  Using qemu-arm-static version from master from two days ago:
  qemu-arm version 2.12.50 (v2.12.0-1182-ga7a7309ca5-dirty), commit: 
a7a7309ca52c327c6603d60db90ae4feeae719f7

  Also saw this in qemu-arm version 2.12.0 (Debian 1:2.12+dfsg-3)

  Thanks,
  Guy

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1776478/+subscriptions

Re: [PATCH 1/2] Drop the deprecated lm32 target

[Markus Armbruster]

Michael Walle  writes:

> Am 2021-05-03 10:40, schrieb Markus Armbruster:
>> Target lm32 was deprecated in commit d8498005122, v5.2.0.  See there
>> for rationale.
>> 
>> Some of its code lives on in device models derived from milkymist
>> ones: hw/char/digic-uart.c and hw/display/bcm2835_fb.c.
>
> yaay ;)

Even at a glance, it was obvious to me that a lot of care went into the
code being removed.  Thanks for serving as its maintainer!

>> Cc: Michael Walle 
>> Signed-off-by: Markus Armbruster 
>
> Acked-by: Michael Walle 

And for this, too :)

[qemu-web PATCH] Update website to point to the new bug tracker at GitLab instead of Launchpad

[Thomas Huth]

We've started migrating the bug tickets from Launchpad to GitLab, so
it does not make too much sense anymore that users open new tickets
in the old system. Let's direct them now to the GitLab tracker instead.

Signed-off-by: Thomas Huth 
---
 contribute.md  | 3 ++-
 contribute/report-a-bug.md | 5 -
 support.md | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/contribute.md b/contribute.md
index d7e295f..cbb476d 100644
--- a/contribute.md
+++ b/contribute.md
@@ -3,7 +3,8 @@ title: Contribute to QEMU!
 permalink: /contribute/
 ---
 
-* Report a bug in our bugtracker: 
[https://bugs.launchpad.net/qemu/](https://bugs.launchpad.net/qemu/)
+* Report a bug in our bugtracker:
+  
   See also [How to report a bug](report-a-bug/) or [How to report a security 
bug](security-process/)
 
 * Clone ([or browse](https://gitlab.com/qemu-project/qemu)) the git 
repository: `git clone https://gitlab.com/qemu-project/qemu.git`
diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
index 1cc42e7..922f699 100644
--- a/contribute/report-a-bug.md
+++ b/contribute/report-a-bug.md
@@ -3,7 +3,10 @@ title: Reporting a bug
 permalink: /contribute/report-a-bug/
 ---
 
-Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), 
which is hosted on Launchpad. If you've got a problem with how your Linux 
distribution packages QEMU, use the bug tracker from your distro instead.
+Bugs can be filed at our
+[bug tracker](https://gitlab.com/qemu-project/qemu/-/issues), which is hosted
+on GitLab. Note: If you've got a problem with how your Linux distribution
+packages QEMU, please use the bug tracker from your distro instead.
 
 When submitting a bug report, please try to do the following:
 
diff --git a/support.md b/support.md
index 252351c..b622362 100644
--- a/support.md
+++ b/support.md
@@ -41,5 +41,5 @@ response. If you can't leave IRC open and wait you may be 
better
 served by a mailing list.
 
 * If you think you have found a bug you can report it on [our bug
-  tracker](https://bugs.launchpad.net/qemu/).
+  tracker](https://gitlab.com/qemu-project/qemu/-/issues).
 Please see our guide on [how to report a bug](/contribute/report-a-bug/)
-- 
2.27.0

Re: [PATCH 0/2] Drop deprecated lm32 and unicore32

[Markus Armbruster]

Forgot to mention it's based on Thomas's "[PATCH] Remove the deprecated
moxie target".

Based-on: <20210430160355.698194-1-th...@redhat.com>

Re: Let's remove some deprecated stuff

[Markus Armbruster]

Peter Maydell  writes:

> On Thu, 29 Apr 2021 at 12:19, Thomas Huth  wrote:
>>
>> On 29/04/2021 11.59, Markus Armbruster wrote:
>> > If you're cc'ed, you added a section to docs/system/deprecated.rst that
>> > is old enough to permit removal.  This is *not* a demand to remove, it's
>> > a polite request to consider whether the time for removal has come.
>> > Extra points for telling us in a reply.  "We should remove, but I can't
>> > do it myself right now" is a valid answer.  Let's review the file:
>> [...]
>> > Thomas Huth:
>> >
>> >  ``moxie`` CPU (since 5.2.0)
>> >  '''
>> >
>> >  The ``moxie`` guest CPU support is deprecated and will be removed in
>> >  a future version of QEMU. It's unclear whether anybody is still using
>> >  CPU emulation in QEMU, and there are no test images available to make
>> >  sure that the code is still working.
>>
>> I'm fine with dropping moxie now - I've never seen anybody using it and I've
>> never spotted any binaries in the internet that could still be used for
>> regression testing of this target. And I've also put Anthony Green on CC:
>> when I suggested the deprecation and he never replied. So I think it's
>> really completely unused.
>>
>> >  ``lm32`` CPUs (since 5.2.0)
>> >  '''
>> >
>> >  The ``lm32`` guest CPU support is deprecated and will be removed in
>> >  a future version of QEMU. The only public user of this architecture
>> >  was the milkymist project, which has been dead for years; there was
>> >  never an upstream Linux port.
>> >
>> >  ``unicore32`` CPUs (since 5.2.0)
>> >  
>> >
>> >  The ``unicore32`` guest CPU support is deprecated and will be removed 
>> > in
>> >  a future version of QEMU. Support for this CPU was removed from the
>> >  upstream Linux kernel, and there is no available upstream toolchain
>> >  to build binaries for it.
>>
>> I didn't add these two entries to the deprecation list, I just moved them
>> around since they were in the wrong section. Both have been added by Peter
>> instead (commit d8498005122 and 8e4ff4a8d2b)
>
> Yes, I think moxie, lm32 and unicore32 are all OK to drop now.

Done:

[PATCH] Remove the deprecated moxie target
Message-Id: <20210430160355.698194-1-th...@redhat.com>

[PATCH 0/2] Drop deprecated lm32 and unicore32
Message-Id: <20210503084034.3804963-1-arm...@redhat.com>

Re: [PATCH 0/2] Drop deprecated lm32 and unicore32

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20210503084034.3804963-1-arm...@redhat.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20210503084034.3804963-1-arm...@redhat.com
Subject: [PATCH 0/2] Drop deprecated lm32 and unicore32

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/20210502174836.838816-1-th...@redhat.com -> 
patchew/20210502174836.838816-1-th...@redhat.com
 * [new tag] patchew/20210503084034.3804963-1-arm...@redhat.com -> 
patchew/20210503084034.3804963-1-arm...@redhat.com
Switched to a new branch 'test'
c70774a Drop the deprecated unicore32 target
3299efe Drop the deprecated lm32 target

=== OUTPUT BEGIN ===
1/2 Checking commit 3299efeaeca9 (Drop the deprecated lm32 target)
ERROR: line over 90 characters
#9969: FILE: tests/tcg/configure.sh:99:
+
alpha|cris|hexagon|hppa|i386|microblaze|microblazeel|m68k|openrisc|riscv64|s390x|sh4|sparc64)

total: 1 errors, 0 warnings, 494 lines checked

Patch 1/2 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

2/2 Checking commit c70774a52a24 (Drop the deprecated unicore32 target)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20210503084034.3804963-1-arm...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[PULL 00/10] Gitlab-CI, qtest, moxie removal and misc patches

[Thomas Huth]

 Hi Peter,

the following changes since commit 53c5433e84e8935abed8e91d4a2eb813168a0ecf:

  Merge remote-tracking branch 'remotes/rth-gitlab/tags/pull-tcg-20210501' into 
staging (2021-05-02 12:02:46 +0100)

are available in the Git repository at:

  https://gitlab.com/thuth/qemu.git tags/pull-request-2021-05-03

for you to fetch changes up to 8f582fa290e5d5d0a00db23eaf1ab1bb3d3ae68d:

  util/compatfd.c: Replaced a malloc call with g_malloc. (2021-05-03 11:40:40 
+0200)


* Removal of the deprecated moxie target
* Replace some YAML anchors by "extends" in the Gitlab-CI
* Some small improvements for using the qtests
* Some other small misc patches


Mahmoud Mandour (1):
  util/compatfd.c: Replaced a malloc call with g_malloc.

Philippe Mathieu-Daudé (3):
  gitlab-ci: Replace YAML anchors by extends (container_job)
  gitlab-ci: Replace YAML anchors by extends (native_build_job)
  gitlab-ci: Replace YAML anchors by extends (native_test_job)

Stefan Hajnoczi (3):
  libqos/qgraph: fix "UNAVAILBLE" typo
  docs/devel/qgraph: add troubleshooting information
  libqtest: refuse QTEST_QEMU_BINARY=qemu-kvm

Thomas Huth (3):
  Remove the deprecated moxie target
  tests/docker/dockerfiles: Add ccache to containers where it was missing
  include/sysemu: Poison all accelerator CONFIG switches in common code

 .gitlab-ci.d/containers.yml|  76 +-
 .gitlab-ci.yml | 110 +--
 MAINTAINERS|   8 -
 default-configs/devices/moxie-softmmu.mak  |   5 -
 default-configs/targets/moxie-softmmu.mak  |   2 -
 disas/meson.build  |   1 -
 disas/moxie.c  | 360 -
 docs/devel/qgraph.rst  |  58 ++
 docs/system/deprecated.rst |   8 -
 docs/system/removed-features.rst   |   7 +
 fpu/softfloat-specialize.c.inc |   2 +-
 hw/Kconfig |   1 -
 hw/meson.build |   1 -
 hw/moxie/Kconfig   |   3 -
 hw/moxie/meson.build   |   4 -
 hw/moxie/moxiesim.c| 157 
 include/disas/dis-asm.h|   1 -
 include/elf.h  |   3 -
 include/exec/poison.h  |   6 +-
 include/hw/elf_ops.h   |   8 -
 include/sysemu/arch_init.h |   1 -
 include/sysemu/hax.h   |   4 +
 include/sysemu/hvf.h   |   4 +
 include/sysemu/whpx.h  |   4 +
 meson.build|   1 -
 qapi/machine.json  |   2 +-
 qapi/misc-target.json  |   2 +-
 softmmu/arch_init.c|   2 -
 target/meson.build |   1 -
 target/moxie/cpu-param.h   |  17 -
 target/moxie/cpu.c | 161 
 target/moxie/cpu.h | 123 ---
 target/moxie/helper.c  | 120 ---
 target/moxie/helper.h  |   5 -
 target/moxie/machine.c |  19 -
 target/moxie/machine.h |   1 -
 target/moxie/meson.build   |  14 -
 target/moxie/mmu.c |  32 -
 target/moxie/mmu.h |  19 -
 target/moxie/translate.c   | 892 -
 tests/docker/dockerfiles/alpine.docker |   1 +
 tests/docker/dockerfiles/fedora-i386-cross.docker  |   1 +
 tests/docker/dockerfiles/fedora-win32-cross.docker |   1 +
 tests/docker/dockerfiles/fedora-win64-cross.docker |   1 +
 tests/docker/dockerfiles/opensuse-leap.docker  |   1 +
 tests/qtest/boot-serial-test.c |   8 -
 tests/qtest/libqos/qgraph.c|   2 +-
 tests/qtest/libqtest.c |   9 +-
 tests/qtest/machine-none-test.c|   1 -
 tests/qtest/meson.build|   2 -
 util/compatfd.c|   8 +-
 51 files changed, 193 insertions(+), 2087 deletions(-)
 delete mode 100644 default-configs/devices/moxie-softmmu.mak
 delete mode 100644 default-configs/targets/moxie-softmmu.mak
 delete mode 100644 disas/moxie.c
 delete mode 100644 hw/moxie/Kconfig
 delete mode 100644 hw/moxie/meson.build
 delete mode 100644 hw/moxie/moxiesim.c
 delete mode 100644 target/moxie/cpu-param.h
 delete mode 100644 target/moxi

[PULL 02/10] tests/docker/dockerfiles: Add ccache to containers where it was missing

[Thomas Huth]

Make sure that ccache is available in all containers.

Message-Id: <20210414081907.871437-2-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 tests/docker/dockerfiles/alpine.docker | 1 +
 tests/docker/dockerfiles/fedora-i386-cross.docker  | 1 +
 tests/docker/dockerfiles/fedora-win32-cross.docker | 1 +
 tests/docker/dockerfiles/fedora-win64-cross.docker | 1 +
 tests/docker/dockerfiles/opensuse-leap.docker  | 1 +
 5 files changed, 5 insertions(+)

diff --git a/tests/docker/dockerfiles/alpine.docker 
b/tests/docker/dockerfiles/alpine.docker
index d63a269aef..a1ef408a6a 100644
--- a/tests/docker/dockerfiles/alpine.docker
+++ b/tests/docker/dockerfiles/alpine.docker
@@ -9,6 +9,7 @@ ENV PACKAGES \
alsa-lib-dev \
bash \
binutils \
+   ccache \
coreutils \
curl-dev \
g++ \
diff --git a/tests/docker/dockerfiles/fedora-i386-cross.docker 
b/tests/docker/dockerfiles/fedora-i386-cross.docker
index 966072c08e..66cdb06c19 100644
--- a/tests/docker/dockerfiles/fedora-i386-cross.docker
+++ b/tests/docker/dockerfiles/fedora-i386-cross.docker
@@ -1,6 +1,7 @@
 FROM fedora:33
 ENV PACKAGES \
 bzip2 \
+ccache \
 diffutils \
 findutils \
 gcc \
diff --git a/tests/docker/dockerfiles/fedora-win32-cross.docker 
b/tests/docker/dockerfiles/fedora-win32-cross.docker
index 81b5659e9c..3733df63e9 100644
--- a/tests/docker/dockerfiles/fedora-win32-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win32-cross.docker
@@ -4,6 +4,7 @@ FROM fedora:33
 ENV PACKAGES \
 bc \
 bzip2 \
+ccache \
 diffutils \
 findutils \
 gcc \
diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker 
b/tests/docker/dockerfiles/fedora-win64-cross.docker
index bcb428e724..2564ce4979 100644
--- a/tests/docker/dockerfiles/fedora-win64-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win64-cross.docker
@@ -4,6 +4,7 @@ FROM fedora:33
 ENV PACKAGES \
 bc \
 bzip2 \
+ccache \
 diffutils \
 findutils \
 gcc \
diff --git a/tests/docker/dockerfiles/opensuse-leap.docker 
b/tests/docker/dockerfiles/opensuse-leap.docker
index 0e64893e4a..f7e1cbfbe6 100644
--- a/tests/docker/dockerfiles/opensuse-leap.docker
+++ b/tests/docker/dockerfiles/opensuse-leap.docker
@@ -5,6 +5,7 @@ ENV PACKAGES \
 bc \
 brlapi-devel \
 bzip2 \
+ccache \
 cyrus-sasl-devel \
 gcc \
 gcc-c++ \
-- 
2.27.0

[PULL 04/10] gitlab-ci: Replace YAML anchors by extends (container_job)

[Thomas Huth]

From: Philippe Mathieu-Daudé 

'extends' is an alternative to using YAML anchors
and is a little more flexible and readable. See:
https://docs.gitlab.com/ee/ci/yaml/#extends

Reviewed-by: Wainer dos Santos Moschetta 
Reviewed-by: Thomas Huth 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20210418233448.1267991-2-f4...@amsat.org>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/containers.yml | 76 ++---
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/.gitlab-ci.d/containers.yml b/.gitlab-ci.d/containers.yml
index 33e4046e23..4ef76d1f54 100644
--- a/.gitlab-ci.d/containers.yml
+++ b/.gitlab-ci.d/containers.yml
@@ -1,4 +1,4 @@
-.container_job_template: &container_job_definition
+.container_job_template:
   image: docker:stable
   stage: containers
   services:
@@ -22,230 +22,230 @@
 - docker logout
 
 amd64-alpine-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   variables:
 NAME: alpine
 
 amd64-centos7-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   variables:
 NAME: centos7
 
 amd64-centos8-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   variables:
 NAME: centos8
 
 amd64-debian10-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   variables:
 NAME: debian10
 
 amd64-debian11-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   variables:
 NAME: debian11
 
 alpha-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-alpha-cross
 
 amd64-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-amd64-cross
 
 amd64-debian-user-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-all-test-cross
 
 amd64-debian-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-amd64
 
 arm64-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-arm64-cross
 
 arm64-test-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian11-container']
   variables:
 NAME: debian-arm64-test-cross
 
 armel-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-armel-cross
 
 armhf-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-armhf-cross
 
 hppa-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-hppa-cross
 
 m68k-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-m68k-cross
 
 mips64-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-mips64-cross
 
 mips64el-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-mips64el-cross
 
 mips-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-mips-cross
 
 mipsel-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-mipsel-cross
 
 powerpc-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-powerpc-cross
 
 ppc64-debian-cross-container:
-  <<: *container_job_definition
+  extends: .container_job_template
   stage: containers-layer2
   needs: ['amd64-debian10-container']
   variables:
 NAME: debian-ppc64-cross
 
 ppc64el-debian-cross-container:
-  <<: *container_job_defin

[PULL 10/10] util/compatfd.c: Replaced a malloc call with g_malloc.

[Thomas Huth]

From: Mahmoud Mandour 

Replaced a call to malloc() and its respective call to free()
with g_malloc() and g_free().

g_malloc() is preferred more than g_try_* functions, which
return NULL on error, when the size of the requested
allocation  is small. This is because allocating few
bytes should not be a problem in a healthy system.
Otherwise, the system is already in a critical state.

Subsequently, removed NULL-checking after g_malloc().

Signed-off-by: Mahmoud Mandour 
Message-Id: <20210315105814.5188-3-ma.mando...@gmail.com>
Signed-off-by: Thomas Huth 
---
 util/compatfd.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/util/compatfd.c b/util/compatfd.c
index 174f394533..a8ec525c6c 100644
--- a/util/compatfd.c
+++ b/util/compatfd.c
@@ -72,14 +72,10 @@ static int qemu_signalfd_compat(const sigset_t *mask)
 QemuThread thread;
 int fds[2];
 
-info = malloc(sizeof(*info));
-if (info == NULL) {
-errno = ENOMEM;
-return -1;
-}
+info = g_malloc(sizeof(*info));
 
 if (pipe(fds) == -1) {
-free(info);
+g_free(info);
 return -1;
 }
 
-- 
2.27.0

[PULL 03/10] include/sysemu: Poison all accelerator CONFIG switches in common code

[Thomas Huth]

We are already poisoning CONFIG_KVM since this switch is not working
in common code. Do the same with the other accelerator switches, too
(except for CONFIG_TCG, which is special, since it is also defined in
config-host.h).

Message-Id: <20210414112004.943383-2-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 include/exec/poison.h | 4 
 include/sysemu/hax.h  | 4 
 include/sysemu/hvf.h  | 4 
 include/sysemu/whpx.h | 4 
 4 files changed, 16 insertions(+)

diff --git a/include/exec/poison.h b/include/exec/poison.h
index de972bfd8e..f769dcc781 100644
--- a/include/exec/poison.h
+++ b/include/exec/poison.h
@@ -86,8 +86,12 @@
 #pragma GCC poison CONFIG_SPARC_DIS
 #pragma GCC poison CONFIG_XTENSA_DIS
 
+#pragma GCC poison CONFIG_HAX
+#pragma GCC poison CONFIG_HVF
 #pragma GCC poison CONFIG_LINUX_USER
 #pragma GCC poison CONFIG_KVM
 #pragma GCC poison CONFIG_SOFTMMU
+#pragma GCC poison CONFIG_WHPX
+#pragma GCC poison CONFIG_XEN
 
 #endif
diff --git a/include/sysemu/hax.h b/include/sysemu/hax.h
index 12fb54f990..247f0661d1 100644
--- a/include/sysemu/hax.h
+++ b/include/sysemu/hax.h
@@ -24,6 +24,8 @@
 
 int hax_sync_vcpus(void);
 
+#ifdef NEED_CPU_H
+
 #ifdef CONFIG_HAX
 
 int hax_enabled(void);
@@ -34,4 +36,6 @@ int hax_enabled(void);
 
 #endif /* CONFIG_HAX */
 
+#endif /* NEED_CPU_H */
+
 #endif /* QEMU_HAX_H */
diff --git a/include/sysemu/hvf.h b/include/sysemu/hvf.h
index c98636bc81..bb70082e45 100644
--- a/include/sysemu/hvf.h
+++ b/include/sysemu/hvf.h
@@ -16,6 +16,8 @@
 #include "qemu/accel.h"
 #include "qom/object.h"
 
+#ifdef NEED_CPU_H
+
 #ifdef CONFIG_HVF
 uint32_t hvf_get_supported_cpuid(uint32_t func, uint32_t idx,
  int reg);
@@ -26,6 +28,8 @@ extern bool hvf_allowed;
 #define hvf_get_supported_cpuid(func, idx, reg) 0
 #endif /* !CONFIG_HVF */
 
+#endif /* NEED_CPU_H */
+
 #define TYPE_HVF_ACCEL ACCEL_CLASS_NAME("hvf")
 
 typedef struct HVFState HVFState;
diff --git a/include/sysemu/whpx.h b/include/sysemu/whpx.h
index 8ca1c1c4ac..2889fa2278 100644
--- a/include/sysemu/whpx.h
+++ b/include/sysemu/whpx.h
@@ -13,6 +13,8 @@
 #ifndef QEMU_WHPX_H
 #define QEMU_WHPX_H
 
+#ifdef NEED_CPU_H
+
 #ifdef CONFIG_WHPX
 
 int whpx_enabled(void);
@@ -25,4 +27,6 @@ bool whpx_apic_in_platform(void);
 
 #endif /* CONFIG_WHPX */
 
+#endif /* NEED_CPU_H */
+
 #endif /* QEMU_WHPX_H */
-- 
2.27.0

[PULL 06/10] gitlab-ci: Replace YAML anchors by extends (native_test_job)

[Thomas Huth]

From: Philippe Mathieu-Daudé 

'extends' is an alternative to using YAML anchors
and is a little more flexible and readable. See:
https://docs.gitlab.com/ee/ci/yaml/#extends

Reviewed-by: Wainer dos Santos Moschetta 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20210418233448.1267991-4-f4...@amsat.org>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.yml | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 442e78a0a7..f01a1dbd7c 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -37,7 +37,7 @@ include:
 make -j"$JOBS" $MAKE_CHECK_ARGS ;
   fi
 
-.native_test_job_template: &native_test_job_definition
+.native_test_job_template:
   stage: test
   image: $CI_REGISTRY_IMAGE/qemu/$IMAGE:latest
   script:
@@ -95,7 +95,7 @@ build-system-alpine:
   - build
 
 check-system-alpine:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-alpine
   artifacts: true
@@ -104,7 +104,7 @@ check-system-alpine:
 MAKE_CHECK_ARGS: check
 
 acceptance-system-alpine:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-alpine
   artifacts: true
@@ -129,7 +129,7 @@ build-system-ubuntu:
   - build
 
 check-system-ubuntu:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-ubuntu
   artifacts: true
@@ -138,7 +138,7 @@ check-system-ubuntu:
 MAKE_CHECK_ARGS: check
 
 acceptance-system-ubuntu:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-ubuntu
   artifacts: true
@@ -163,7 +163,7 @@ build-system-debian:
   - build
 
 check-system-debian:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-debian
   artifacts: true
@@ -172,7 +172,7 @@ check-system-debian:
 MAKE_CHECK_ARGS: check
 
 acceptance-system-debian:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-debian
   artifacts: true
@@ -198,7 +198,7 @@ build-system-fedora:
   - build
 
 check-system-fedora:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-fedora
   artifacts: true
@@ -207,7 +207,7 @@ check-system-fedora:
 MAKE_CHECK_ARGS: check
 
 acceptance-system-fedora:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-fedora
   artifacts: true
@@ -233,7 +233,7 @@ build-system-centos:
   - build
 
 check-system-centos:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-centos
   artifacts: true
@@ -242,7 +242,7 @@ check-system-centos:
 MAKE_CHECK_ARGS: check
 
 acceptance-system-centos:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-centos
   artifacts: true
@@ -266,7 +266,7 @@ build-system-opensuse:
   - build
 
 check-system-opensuse:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-opensuse
   artifacts: true
@@ -275,7 +275,7 @@ check-system-opensuse:
 MAKE_CHECK_ARGS: check
 
 acceptance-system-opensuse:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-system-opensuse
   artifacts: true
@@ -509,7 +509,7 @@ build-cfi-aarch64:
   - build
 
 check-cfi-aarch64:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-cfi-aarch64
   artifacts: true
@@ -518,7 +518,7 @@ check-cfi-aarch64:
 MAKE_CHECK_ARGS: check
 
 acceptance-cfi-aarch64:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-cfi-aarch64
   artifacts: true
@@ -546,7 +546,7 @@ build-cfi-ppc64-s390x:
   - build
 
 check-cfi-ppc64-s390x:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-cfi-ppc64-s390x
   artifacts: true
@@ -555,7 +555,7 @@ check-cfi-ppc64-s390x:
 MAKE_CHECK_ARGS: check
 
 acceptance-cfi-ppc64-s390x:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-cfi-ppc64-s390x
   artifacts: true
@@ -583,7 +583,7 @@ build-cfi-x86_64:
   - build
 
 check-cfi-x86_64:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-cfi-x86_64
   artifacts: true
@@ -592,7 +592,7 @@ check-cfi-x86_64:
 MAKE_CHECK_ARGS: check
 
 acceptance-cfi-x86_64:
-  <<: *native_test_job_definition
+  extends: .native_test_job_template
   needs:
 - job: build-cfi-x86_64
   artifacts: true
@@ -630,7 +630,7 @@ build-deprecated:
 # We split the check-tcg step as test failures are expected bu

[PULL 05/10] gitlab-ci: Replace YAML anchors by extends (native_build_job)

[Thomas Huth]

From: Philippe Mathieu-Daudé 

'extends' is an alternative to using YAML anchors
and is a little more flexible and readable. See:
https://docs.gitlab.com/ee/ci/yaml/#extends

Reviewed-by: Wainer dos Santos Moschetta 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20210418233448.1267991-3-f4...@amsat.org>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.yml | 64 +-
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 9970d91809..442e78a0a7 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -13,7 +13,7 @@ include:
   - local: '/.gitlab-ci.d/containers.yml'
   - local: '/.gitlab-ci.d/crossbuilds.yml'
 
-.native_build_job_template: &native_build_job_definition
+.native_build_job_template:
   stage: build
   image: $CI_REGISTRY_IMAGE/qemu/$IMAGE:latest
   before_script:
@@ -79,7 +79,7 @@ include:
 - du -chs ${CI_PROJECT_DIR}/avocado-cache
 
 build-system-alpine:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 - job: amd64-alpine-container
   variables:
@@ -114,7 +114,7 @@ acceptance-system-alpine:
   <<: *acceptance_definition
 
 build-system-ubuntu:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-ubuntu2004-container
   variables:
@@ -148,7 +148,7 @@ acceptance-system-ubuntu:
   <<: *acceptance_definition
 
 build-system-debian:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-debian-container
   variables:
@@ -182,7 +182,7 @@ acceptance-system-debian:
   <<: *acceptance_definition
 
 build-system-fedora:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-fedora-container
   variables:
@@ -217,7 +217,7 @@ acceptance-system-fedora:
   <<: *acceptance_definition
 
 build-system-centos:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-centos8-container
   variables:
@@ -252,7 +252,7 @@ acceptance-system-centos:
   <<: *acceptance_definition
 
 build-system-opensuse:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-opensuse-leap-container
   variables:
@@ -286,7 +286,7 @@ acceptance-system-opensuse:
 
 
 build-disabled:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-fedora-container
   variables:
@@ -373,7 +373,7 @@ build-disabled:
 # Also use a different coroutine implementation (which is only really of
 # interest to KVM users, i.e. with TCG disabled)
 build-tcg-disabled:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-centos8-container
   variables:
@@ -396,7 +396,7 @@ build-tcg-disabled:
 260 261 262 263 264 270 272 273 277 279
 
 build-user:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-debian-user-cross-container
   variables:
@@ -405,7 +405,7 @@ build-user:
 MAKE_CHECK_ARGS: check-tcg
 
 build-user-static:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-debian-user-cross-container
   variables:
@@ -415,7 +415,7 @@ build-user-static:
 
 # Only build the softmmu targets we have check-tcg tests for
 build-some-softmmu:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-debian-user-cross-container
   variables:
@@ -428,7 +428,7 @@ build-some-softmmu:
 # we skip sparc64-linux-user until it has been fixed somewhat
 # we skip cris-linux-user as it doesn't use the common run loop
 build-user-plugins:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-debian-user-cross-container
   variables:
@@ -438,7 +438,7 @@ build-user-plugins:
   timeout: 1h 30m
 
 build-user-centos7:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-centos7-container
   variables:
@@ -447,7 +447,7 @@ build-user-centos7:
 MAKE_CHECK_ARGS: check-tcg
 
 build-some-softmmu-plugins:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-debian-user-cross-container
   variables:
@@ -457,7 +457,7 @@ build-some-softmmu-plugins:
 MAKE_CHECK_ARGS: check-tcg
 
 clang-system:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-fedora-container
   variables:
@@ -469,7 +469,7 @@ clang-system:
 MAKE_CHECK_ARGS: check-qtest check-tcg
 
 clang-user:
-  <<: *native_build_job_definition
+  extends: .native_build_job_template
   needs:
 job: amd64-debian-user-cross-container
   variables:
@@ -491,7 +491,7 @@ clang-user:
 # Split in three sets of build/check/acceptance to limit the execution time of 
each
 # job
 build-cfi-aarch64:
-  <<: *native_build_job_definition
+  extends: .nati

Re: [qemu-web PATCH] Update website to point to the new bug tracker at GitLab instead of Launchpad

[Philippe Mathieu-Daudé]

Hi Thomas,

On 5/3/21 12:30 PM, Thomas Huth wrote:
> We've started migrating the bug tickets from Launchpad to GitLab, so
> it does not make too much sense anymore that users open new tickets
> in the old system. Let's direct them now to the GitLab tracker instead.

We should document the user has to request a Gitlab 'Reporter' access to
the project, and warn there might be a delay of some days before the
request to be accepted, before the user be able to fill the bug.

TBH this is annoying and could discourage reporters to fill bugs.

Personally I fill a bug when I have all pieces in front of me. I'm
less motivated to take notes of my environment to come back filling
the bug ticket few days later.

> 
> Signed-off-by: Thomas Huth 
> ---
>  contribute.md  | 3 ++-
>  contribute/report-a-bug.md | 5 -
>  support.md | 2 +-
>  3 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/contribute.md b/contribute.md
> index d7e295f..cbb476d 100644
> --- a/contribute.md
> +++ b/contribute.md
> @@ -3,7 +3,8 @@ title: Contribute to QEMU!
>  permalink: /contribute/
>  ---
>  
> -* Report a bug in our bugtracker: 
> [https://bugs.launchpad.net/qemu/](https://bugs.launchpad.net/qemu/)
> +* Report a bug in our bugtracker:
> +  
>See also [How to report a bug](report-a-bug/) or [How to report a security 
> bug](security-process/)
>  
>  * Clone ([or browse](https://gitlab.com/qemu-project/qemu)) the git 
> repository: `git clone https://gitlab.com/qemu-project/qemu.git`
> diff --git a/contribute/report-a-bug.md b/contribute/report-a-bug.md
> index 1cc42e7..922f699 100644
> --- a/contribute/report-a-bug.md
> +++ b/contribute/report-a-bug.md
> @@ -3,7 +3,10 @@ title: Reporting a bug
>  permalink: /contribute/report-a-bug/
>  ---
>  
> -Bugs can be filed at our [bug tracker](https://bugs.launchpad.net/qemu/), 
> which is hosted on Launchpad. If you've got a problem with how your Linux 
> distribution packages QEMU, use the bug tracker from your distro instead.
> +Bugs can be filed at our
> +[bug tracker](https://gitlab.com/qemu-project/qemu/-/issues), which is hosted
> +on GitLab. Note: If you've got a problem with how your Linux distribution
> +packages QEMU, please use the bug tracker from your distro instead.
>  
>  When submitting a bug report, please try to do the following:
>  
> diff --git a/support.md b/support.md
> index 252351c..b622362 100644
> --- a/support.md
> +++ b/support.md
> @@ -41,5 +41,5 @@ response. If you can't leave IRC open and wait you may be 
> better
>  served by a mailing list.
>  
>  * If you think you have found a bug you can report it on [our bug
> -  tracker](https://bugs.launchpad.net/qemu/).
> +  tracker](https://gitlab.com/qemu-project/qemu/-/issues).
>  Please see our guide on [how to report a bug](/contribute/report-a-bug/)
> 

[PULL 01/10] Remove the deprecated moxie target

[Thomas Huth]

There are no known users of this CPU anymore, and there are no
binaries available online which could be used for regression tests,
so the code has likely completely bit-rotten already. It's been
marked as deprecated since two releases now and nobody spoke up
that there is still a need to keep it, thus let's remove it now.

Signed-off-by: Thomas Huth 
Reviewed-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Message-Id: <20210430160355.698194-1-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.yml|   6 +-
 MAINTAINERS   |   8 -
 default-configs/devices/moxie-softmmu.mak |   5 -
 default-configs/targets/moxie-softmmu.mak |   2 -
 disas/meson.build |   1 -
 disas/moxie.c | 360 -
 docs/system/deprecated.rst|   8 -
 docs/system/removed-features.rst  |   7 +
 fpu/softfloat-specialize.c.inc|   2 +-
 hw/Kconfig|   1 -
 hw/meson.build|   1 -
 hw/moxie/Kconfig  |   3 -
 hw/moxie/meson.build  |   4 -
 hw/moxie/moxiesim.c   | 157 
 include/disas/dis-asm.h   |   1 -
 include/elf.h |   3 -
 include/exec/poison.h |   2 -
 include/hw/elf_ops.h  |   8 -
 include/sysemu/arch_init.h|   1 -
 meson.build   |   1 -
 qapi/machine.json |   2 +-
 qapi/misc-target.json |   2 +-
 softmmu/arch_init.c   |   2 -
 target/meson.build|   1 -
 target/moxie/cpu-param.h  |  17 -
 target/moxie/cpu.c| 161 
 target/moxie/cpu.h| 123 ---
 target/moxie/helper.c | 120 ---
 target/moxie/helper.h |   5 -
 target/moxie/machine.c|  19 -
 target/moxie/machine.h|   1 -
 target/moxie/meson.build  |  14 -
 target/moxie/mmu.c|  32 -
 target/moxie/mmu.h|  19 -
 target/moxie/translate.c  | 892 --
 tests/qtest/boot-serial-test.c|   8 -
 tests/qtest/machine-none-test.c   |   1 -
 tests/qtest/meson.build   |   2 -
 38 files changed, 13 insertions(+), 1989 deletions(-)
 delete mode 100644 default-configs/devices/moxie-softmmu.mak
 delete mode 100644 default-configs/targets/moxie-softmmu.mak
 delete mode 100644 disas/moxie.c
 delete mode 100644 hw/moxie/Kconfig
 delete mode 100644 hw/moxie/meson.build
 delete mode 100644 hw/moxie/moxiesim.c
 delete mode 100644 target/moxie/cpu-param.h
 delete mode 100644 target/moxie/cpu.c
 delete mode 100644 target/moxie/cpu.h
 delete mode 100644 target/moxie/helper.c
 delete mode 100644 target/moxie/helper.h
 delete mode 100644 target/moxie/machine.c
 delete mode 100644 target/moxie/machine.h
 delete mode 100644 target/moxie/meson.build
 delete mode 100644 target/moxie/mmu.c
 delete mode 100644 target/moxie/mmu.h
 delete mode 100644 target/moxie/translate.c

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 52d65d6c04..9970d91809 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -85,7 +85,7 @@ build-system-alpine:
   variables:
 IMAGE: alpine
 TARGETS: aarch64-softmmu alpha-softmmu cris-softmmu hppa-softmmu
-  moxie-softmmu microblazeel-softmmu mips64el-softmmu
+  microblazeel-softmmu mips64el-softmmu
 MAKE_CHECK_ARGS: check-build
 CONFIGURE_ARGS: --enable-docs --enable-trace-backends=log,simple,syslog
   artifacts:
@@ -121,7 +121,7 @@ build-system-ubuntu:
 IMAGE: ubuntu2004
 CONFIGURE_ARGS: --enable-docs --enable-fdt=system --enable-slirp=system
 TARGETS: aarch64-softmmu alpha-softmmu cris-softmmu hppa-softmmu
-  moxie-softmmu microblazeel-softmmu mips64el-softmmu
+  microblazeel-softmmu mips64el-softmmu
 MAKE_CHECK_ARGS: check-build
   artifacts:
 expire_in: 2 days
@@ -680,7 +680,7 @@ build-tci:
   variables:
 IMAGE: debian-all-test-cross
   script:
-- TARGETS="aarch64 alpha arm hppa m68k microblaze moxie ppc64 s390x x86_64"
+- TARGETS="aarch64 alpha arm hppa m68k microblaze ppc64 s390x x86_64"
 - mkdir build
 - cd build
 - ../configure --enable-tcg-interpreter
diff --git a/MAINTAINERS b/MAINTAINERS
index 4c05ff8bba..7b9683732a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -258,14 +258,6 @@ MIPS TCG CPUs (nanoMIPS ISA)
 S: Orphan
 F: disas/nanomips.*
 
-Moxie TCG CPUs
-M: Anthony Green 
-S: Maintained
-F: target/moxie/
-F: disas/moxie.c
-F: hw/moxie/
-F: default-configs/*/moxie-softmmu.mak
-
 NiosII TCG CPUs
 M: Chris Wulff 
 M: Marek Vasut 
diff --git a/default-configs/devices/moxie-softmmu.mak 
b/default-configs/devices/moxie-softmmu.mak
deleted file mode 100644
index 

[PULL 07/10] libqos/qgraph: fix "UNAVAILBLE" typo

[Thomas Huth]

From: Stefan Hajnoczi 

Signed-off-by: Stefan Hajnoczi 
Message-Id: <20210412143437.727560-2-stefa...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Acked-by: Paolo Bonzini 
Signed-off-by: Thomas Huth 
---
 tests/qtest/libqos/qgraph.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qtest/libqos/qgraph.c b/tests/qtest/libqos/qgraph.c
index b3b1a31f81..d1dc491930 100644
--- a/tests/qtest/libqos/qgraph.c
+++ b/tests/qtest/libqos/qgraph.c
@@ -844,7 +844,7 @@ void qos_dump_graph(void)
 }
 qos_printf_literal("type=%d cmd_line='%s' [%s]\n",
node->type, node->command_line,
-   node->available ? "available" : "UNAVAILBLE"
+   node->available ? "available" : "UNAVAILABLE"
 );
 }
 g_list_free(keys);
-- 
2.27.0

[PULL 08/10] docs/devel/qgraph: add troubleshooting information

[Thomas Huth]

From: Stefan Hajnoczi 

It can be tricky to troubleshoot qos-test when a test won't execute. Add
an explanation of how to trace qgraph node connectivity and find which
node has the problem.

Signed-off-by: Stefan Hajnoczi 
Message-Id: <20210412143437.727560-3-stefa...@redhat.com>
Acked-by: Paolo Bonzini 
Signed-off-by: Thomas Huth 
---
 docs/devel/qgraph.rst | 58 +++
 1 file changed, 58 insertions(+)

diff --git a/docs/devel/qgraph.rst b/docs/devel/qgraph.rst
index a9aff167ad..318534d4b0 100644
--- a/docs/devel/qgraph.rst
+++ b/docs/devel/qgraph.rst
@@ -92,6 +92,64 @@ The basic framework steps are the following:
 Depending on the QEMU binary used, only some drivers/machines will be
 available and only test that are reached by them will be executed.
 
+Troubleshooting unavailable tests
+^
+If there is no path from an available machine to a test then that test will be
+unavailable and won't execute. This can happen if a test or driver did not set
+up its qgraph node correctly. It can also happen if the necessary machine type
+or device is missing from the QEMU binary because it was compiled out or
+otherwise.
+
+It is possible to troubleshoot unavailable tests by running::
+
+  $ QTEST_QEMU_BINARY=build/qemu-system-x86_64 build/tests/qtest/qos-test 
--verbose
+  # ALL QGRAPH EDGES: {
+  #   src='virtio-net'
+  #  |-> dest='virtio-net-tests/vhost-user/multiqueue' type=2 
(node=0x559142109e30)
+  #  |-> dest='virtio-net-tests/vhost-user/migrate' type=2 
(node=0x559142109d00)
+  #   src='virtio-net-pci'
+  #  |-> dest='virtio-net' type=1 (node=0x55914210d740)
+  #   src='pci-bus'
+  #  |-> dest='virtio-net-pci' type=2 (node=0x55914210d880)
+  #   src='pci-bus-pc'
+  #  |-> dest='pci-bus' type=1 (node=0x559142103f40)
+  #   src='i440FX-pcihost'
+  #  |-> dest='pci-bus-pc' type=0 (node=0x55914210ac70)
+  #   src='x86_64/pc'
+  #  |-> dest='i440FX-pcihost' type=0 (node=0x5591421117f0)
+  #   src=''
+  #  |-> dest='x86_64/pc' type=0 (node=0x559142111600)
+  #  |-> dest='arm/raspi2' type=0 (node=0x559142110740)
+  ...
+  # }
+  # ALL QGRAPH NODES: {
+  #   name='virtio-net-tests/announce-self' type=3 cmd_line='(null)' 
[available]
+  #   name='arm/raspi2' type=0 cmd_line='-M raspi2 ' [UNAVAILABLE]
+  ...
+  # }
+
+The ``virtio-net-tests/announce-self`` test is listed as "available" in the
+"ALL QGRAPH NODES" output. This means the test will execute. We can follow the
+qgraph path in the "ALL QGRAPH EDGES" output as follows: '' -> 'x86_64/pc' ->
+'i440FX-pcihost' -> 'pci-bus-pc' -> 'pci-bus' -> 'virtio-net-pci' ->
+'virtio-net'. The root of the qgraph is '' and the depth first search begins
+there.
+
+The ``arm/raspi`` machine node is listed as "UNAVAILABLE". Although it is
+reachable from the root via '' -> 'arm/raspi2' the node is unavailable because
+the QEMU binary did not list it when queried by the framework. This is expected
+because we used the ``qemu-system-x86_64`` binary which does not support ARM
+machine types.
+
+If a test is unexpectedly listed as "UNAVAILABLE", first check that the "ALL
+QGRAPH EDGES" output reports edge connectivity from the root ('') to the test.
+If there is no connectivity then the qgraph nodes were not set up correctly and
+the driver or test code is incorrect. If there is connectivity, check the
+availability of each node in the path in the "ALL QGRAPH NODES" output. The
+first unavailable node in the path is the reason why the test is unavailable.
+Typically this is because the QEMU binary lacks support for the necessary
+machine type or device.
+
 Creating a new driver and its interface
 "
 
-- 
2.27.0

Re: [PATCH 2/2] Drop the deprecated unicore32 target

[Thomas Huth]

On 03/05/2021 10.40, Markus Armbruster wrote:

Target unicore32 was deprecated in commit 8e4ff4a8d2b, v5.2.0.  See
there for rationale.

Cc: Guan Xuetao 
Signed-off-by: Markus Armbruster 
---

[...]

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index e914d34298..2592c4fbd5 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -198,14 +198,6 @@ from Linux upstream kernel, declare it deprecated.
  System emulator CPUS
  
  
-``unicore32`` CPUs (since 5.2.0)

-
-
-The ``unicore32`` guest CPU support is deprecated and will be removed in
-a future version of QEMU. Support for this CPU was removed from the
-upstream Linux kernel, and there is no available upstream toolchain
-to build binaries for it.
-
  ``Icelake-Client`` CPU Model (since 5.2.0)
  ''
  
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst

index e9850e4b96..b399084438 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -293,12 +293,19 @@ available to make sure that the code is still working, so 
it has been removed
  without replacement.
  
  ``lm32`` CPUs (removed in 6.1.0)

-'''
+


Nit: That hunk should go into the previous patch.


diff --git a/fpu/softfloat-specialize.c.inc b/fpu/softfloat-specialize.c.inc
index 45b7bf81dc..b5b50537bf 100644
--- a/fpu/softfloat-specialize.c.inc
+++ b/fpu/softfloat-specialize.c.inc
@@ -103,7 +103,7 @@ static inline bool snan_bit_is_one(float_status *status)
  {
  #if defined(TARGET_MIPS)
  return status->snan_bit_is_one;
-#elif defined(TARGET_HPPA) || defined(TARGET_UNICORE32) || defined(TARGET_SH4)
+#elif defined(TARGET_HPPA) || defined(TARGET_SH4)
  return 1;
  #else
  return 0;
@@ -146,11 +146,10 @@ static FloatParts parts_default_nan(float_status *status)
  /* snan_bit_is_one, set msb-1.  */
  frac = 1ULL << (DECOMPOSED_BINARY_POINT - 2);
  #else
-/* This case is true for Alpha, ARM, MIPS, OpenRISC, PPC, RISC-V,
- * S390, SH4, TriCore, and Xtensa.  I cannot find documentation
- * for Unicore32; the choice from the original commit is unchanged.
- * Our other supported targets, CRIS, Nios2, and Tile,
- * do not have floating-point.
+/*
+ * This case is true for Alpha, ARM, MIPS, OpenRISC, PPC, RISC-V,
+ * S390, SH4, TriCore, and Xtensa.  Our other supported targets,
+ * CRIS, Nios2, and Tile, do not have floating-point.
   */


I guess you'll get a conflict here with my moxie removal patch... but that 
should be easy to solve.


FWIW:
Acked-by: Thomas Huth 

[PULL 09/10] libqtest: refuse QTEST_QEMU_BINARY=qemu-kvm

[Thomas Huth]

From: Stefan Hajnoczi 

Some downstreams rename the QEMU binary to "qemu-kvm". This breaks
qtest_get_arch(), which attempts to parse the target architecture from
the QTEST_QEMU_BINARY environment variable.

Print an error instead of returning the architecture "kvm". Things fail
in weird ways when the architecture string is bogus.

Arguably qtests should always be run in a build directory instead of
against an installed QEMU. In any case, printing a clear error when this
happens is helpful.

Since this is an error that is triggered by the user and not a test
failure, use exit(1) instead of abort(). Change the existing abort()
call in qtest_get_arch() to exit(1) too for the same reason and to be
consistent.

Reported-by: Qin Wang 
Signed-off-by: Stefan Hajnoczi 
Reviewed-by: Emanuele Giuseppe Esposito 
Reviewed-by: Thomas Huth 
Cc: Emanuele Giuseppe Esposito 
Message-Id: <20210412143050.725918-1-stefa...@redhat.com>
Signed-off-by: Thomas Huth 
---
 tests/qtest/libqtest.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index 71e359efcd..825b13a44c 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -907,7 +907,14 @@ const char *qtest_get_arch(void)
 
 if (!end) {
 fprintf(stderr, "Can't determine architecture from binary name.\n");
-abort();
+exit(1);
+}
+
+if (!strstr(qemu, "-system-")) {
+fprintf(stderr, "QTEST_QEMU_BINARY must end with *-system- "
+"where 'arch' is the target\narchitecture (x86_64, aarch64, "
+"etc).\n");
+exit(1);
 }
 
 return end + 1;
-- 
2.27.0

Re: [qemu-web PATCH] Update website to point to the new bug tracker at GitLab instead of Launchpad

[Thomas Huth]

On 03/05/2021 12.47, Philippe Mathieu-Daudé wrote:

Hi Thomas,

On 5/3/21 12:30 PM, Thomas Huth wrote:

We've started migrating the bug tickets from Launchpad to GitLab, so
it does not make too much sense anymore that users open new tickets
in the old system. Let's direct them now to the GitLab tracker instead.


We should document the user has to request a Gitlab 'Reporter' access to
the project, and warn there might be a delay of some days before the
request to be accepted, before the user be able to fill the bug.

I think it is possible for everybody with a Gitlab account to file bugs. We 
already have two tickets that were created by non-members:


 https://gitlab.com/qemu-project/qemu/-/issues/47

 https://gitlab.com/qemu-project/qemu/-/issues/45

AFAIK, you just need the "Reporter" state if you want to add labels to a 
ticket, or if you want to assign it to somebody else.


 Thomas

[PATCH] hw/arm/raspi: Remove deprecated raspi2/raspi3 aliases

[Philippe Mathieu-Daudé]

Remove the raspi2/raspi3 machine aliases,
deprecated since commit 155e1c82ed0.

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/system/deprecated.rst   | 7 ---
 docs/system/removed-features.rst | 7 +++
 hw/arm/raspi.c   | 2 --
 3 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index 80cae862528..7895bd4d849 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -238,13 +238,6 @@ this CPU is also deprecated.
 System emulator machines
 
 
-Raspberry Pi ``raspi2`` and ``raspi3`` machines (since 5.2)
-'''
-
-The Raspberry Pi machines come in various models (A, A+, B, B+). To be able
-to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3``
-machines have been renamed ``raspi2b`` and ``raspi3b``.
-
 Device options
 --
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 29e90601a51..8a8b8ca627b 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -312,6 +312,13 @@ This machine has been renamed ``fuloong2e``.
 These machine types were very old and likely could not be used for live
 migration from old QEMU versions anymore. Use a newer machine type instead.
 
+Raspberry Pi ``raspi2`` and ``raspi3`` machines (removed in 6.1)
+
+
+The Raspberry Pi machines come in various models (A, A+, B, B+). To be able
+to distinguish which model QEMU is implementing, the ``raspi2`` and ``raspi3``
+machines have been renamed ``raspi2b`` and ``raspi3b``.
+
 
 linux-user mode CPUs
 
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
index 990509d3852..20bba0316f1 100644
--- a/hw/arm/raspi.c
+++ b/hw/arm/raspi.c
@@ -342,7 +342,6 @@ static void raspi2b_machine_class_init(ObjectClass *oc, 
void *data)
 MachineClass *mc = MACHINE_CLASS(oc);
 RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc);
 
-mc->alias = "raspi2";
 rmc->board_rev = 0xa21041;
 raspi_machine_class_common_init(mc, rmc->board_rev);
 };
@@ -362,7 +361,6 @@ static void raspi3b_machine_class_init(ObjectClass *oc, 
void *data)
 MachineClass *mc = MACHINE_CLASS(oc);
 RaspiMachineClass *rmc = RASPI_MACHINE_CLASS(oc);
 
-mc->alias = "raspi3";
 rmc->board_rev = 0xa02082;
 raspi_machine_class_common_init(mc, rmc->board_rev);
 };
-- 
2.26.3

[PATCH v4 2/5] qemu-iotests: allow passing unittest.main arguments to the test scripts

[Paolo Bonzini]

Python test scripts that use unittest consist of multiple tests.
unittest.main allows selecting which tests to run, but currently this
is not possible because the iotests wrapper ignores sys.argv.

unittest.main command line options also allow the user to pick the
desired options for verbosity, failfast mode, etc.  While "-d" is
currently translated to "-v", it also enables extra debug output,
and other options are not available at all.

These command line options only work if the unittest.main testRunner
argument is a type, rather than a TestRunner instance.  Therefore, pass
the class name and "verbosity" argument to unittest.main, and adjust for
the different default warnings between TextTestRunner and unittest.main.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Tested-by: Emanuele Giuseppe Esposito 
Message-Id: <20210323181928.311862-3-pbonz...@redhat.com>
---
 tests/qemu-iotests/iotests.py | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 55a017577f..5ead94229f 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -1308,12 +1308,16 @@ def __init__(self, stream: Optional[TextIO] = None,
  resultclass=resultclass,
  **kwargs)
 
-def execute_unittest(debug=False):
+def execute_unittest(argv: List[str], debug: bool = False) -> None:
 """Executes unittests within the calling module."""
 
-verbosity = 2 if debug else 1
-runner = ReproducibleTestRunner(verbosity=verbosity)
-unittest.main(testRunner=runner)
+# Some tests have warnings, especially ResourceWarnings for unclosed
+# files and sockets.  Ignore them for now to ensure reproducibility of
+# the test output.
+unittest.main(argv=argv,
+  testRunner=ReproducibleTestRunner,
+  verbosity=2 if debug else 1,
+  warnings=None if sys.warnoptions else 'ignore')
 
 def execute_setup_common(supported_fmts: Sequence[str] = (),
  supported_platforms: Sequence[str] = (),
@@ -1350,7 +1354,7 @@ def execute_test(*args, test_function=None, **kwargs):
 
 debug = execute_setup_common(*args, **kwargs)
 if not test_function:
-execute_unittest(debug)
+execute_unittest(sys.argv, debug)
 else:
 test_function()
 
-- 
2.31.1

[PATCH v4 1/5] qemu-iotests: do not buffer the test output

[Paolo Bonzini]

Instead of buffering the test output into a StringIO, patch it on
the fly by wrapping sys.stdout's write method.  This can be
done unconditionally, even if using -d, which makes execute_unittest
a bit simpler.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Tested-by: Emanuele Giuseppe Esposito 
Message-Id: <20210323181928.311862-2-pbonz...@redhat.com>
---
 tests/qemu-iotests/240.out|  8 ++--
 tests/qemu-iotests/245.out|  8 ++--
 tests/qemu-iotests/295.out|  6 +--
 tests/qemu-iotests/296.out|  8 ++--
 tests/qemu-iotests/iotests.py | 70 ---
 5 files changed, 56 insertions(+), 44 deletions(-)

diff --git a/tests/qemu-iotests/240.out b/tests/qemu-iotests/240.out
index e0982831ae..89ed25e506 100644
--- a/tests/qemu-iotests/240.out
+++ b/tests/qemu-iotests/240.out
@@ -15,7 +15,7 @@
 {"return": {}}
 {"execute": "blockdev-del", "arguments": {"node-name": "hd0"}}
 {"return": {}}
-==Attach two SCSI disks using the same block device and the same iothread==
+.==Attach two SCSI disks using the same block device and the same iothread==
 {"execute": "blockdev-add", "arguments": {"driver": "null-co", "node-name": 
"hd0", "read-only": true, "read-zeroes": true}}
 {"return": {}}
 {"execute": "object-add", "arguments": {"id": "iothread0", "qom-type": 
"iothread"}}
@@ -32,7 +32,7 @@
 {"return": {}}
 {"execute": "blockdev-del", "arguments": {"node-name": "hd0"}}
 {"return": {}}
-==Attach two SCSI disks using the same block device but different iothreads==
+.==Attach two SCSI disks using the same block device but different iothreads==
 {"execute": "blockdev-add", "arguments": {"driver": "null-co", "node-name": 
"hd0", "read-only": true, "read-zeroes": true}}
 {"return": {}}
 {"execute": "object-add", "arguments": {"id": "iothread0", "qom-type": 
"iothread"}}
@@ -55,7 +55,7 @@
 {"return": {}}
 {"execute": "blockdev-del", "arguments": {"node-name": "hd0"}}
 {"return": {}}
-==Attach a SCSI disks using the same block device as a NBD server==
+.==Attach a SCSI disks using the same block device as a NBD server==
 {"execute": "blockdev-add", "arguments": {"driver": "null-co", "node-name": 
"hd0", "read-only": true, "read-zeroes": true}}
 {"return": {}}
 {"execute": "nbd-server-start", "arguments": {"addr": {"data": {"path": 
"SOCK_DIR/PID-nbd.sock"}, "type": "unix"}}}
@@ -68,7 +68,7 @@
 {"return": {}}
 {"execute": "device_add", "arguments": {"drive": "hd0", "driver": "scsi-hd", 
"id": "scsi-hd0"}}
 {"return": {}}
-
+.
 --
 Ran 4 tests
 
diff --git a/tests/qemu-iotests/245.out b/tests/qemu-iotests/245.out
index 4b33dcaf5c..99c12f4f98 100644
--- a/tests/qemu-iotests/245.out
+++ b/tests/qemu-iotests/245.out
@@ -1,16 +1,16 @@
-{"execute": "job-finalize", "arguments": {"id": "commit0"}}
+..{"execute": "job-finalize", "arguments": {"id": "commit0"}}
 {"return": {}}
 {"data": {"id": "commit0", "type": "commit"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
 {"data": {"device": "commit0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "commit"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
-{"execute": "job-finalize", "arguments": {"id": "stream0"}}
+...{"execute": "job-finalize", "arguments": {"id": "stream0"}}
 {"return": {}}
 {"data": {"id": "stream0", "type": "stream"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
 {"data": {"device": "stream0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "stream"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
-{"execute": "job-finalize", "arguments": {"id": "stream0"}}
+.{"execute": "job-finalize", "arguments": {"id": "stream0"}}
 {"return": {}}
 {"data": {"id": "stream0", "type": "stream"}, "event": "BLOCK_JOB_PENDING", 
"timestamp": {"microseconds": "USECS", "seconds": "SECS"}}
 {"data": {"device": "stream0", "len": 3145728, "offset": 3145728, "speed": 0, 
"type": "stream"}, "event": "BLOCK_JOB_COMPLETED", "timestamp": 
{"microseconds": "USECS", "seconds": "SECS"}}
-.
+...
 --
 Ran 21 tests
 
diff --git a/tests/qemu-iotests/295.out b/tests/qemu-iotests/295.out
index ad34b2ca2c..5ff91f116c 100644
--- a/tests/qemu-iotests/295.out
+++ b/tests/qemu-iotests/295.out
@@ -4,7 +4,7 @@
 {"return": {}}
 {"execute": "job-dismiss", "arguments": {"id": "job_erase_key"}}
 {"return": {}}
-{"execute": "job-dismiss", "arguments": {"id": "job_add_key"}}
+.{"execute": "job-dismiss", "arguments": {"id": "job_add_key"}}
 {"return": {}}
 {"execute": "job-dismiss", "arguments": {"id": "job_erase_key"}}
 {"return": {}}
@@ -13,7 +13,7 @@ Job failed: Invalid password, cannot unlock any keyslot
 {"return": {}}
 {"execute": "job-dismiss", "arguments": {"id": "job_add_key"}}
 {"return": {

[PATCH v4 5/5] qemu-iotests: fix case of SOCK_DIR already in the environment

[Paolo Bonzini]

Due to a typo, in this case the SOCK_DIR was not being created.

Reviewed-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Paolo Bonzini 
Tested-by: Emanuele Giuseppe Esposito 
Message-Id: <20210323181928.311862-6-pbonz...@redhat.com>
---
 tests/qemu-iotests/testenv.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qemu-iotests/testenv.py b/tests/qemu-iotests/testenv.py
index cd0e39b789..0c3fe75636 100644
--- a/tests/qemu-iotests/testenv.py
+++ b/tests/qemu-iotests/testenv.py
@@ -120,7 +120,7 @@ def init_directories(self) -> None:
 try:
 self.sock_dir = os.environ['SOCK_DIR']
 self.tmp_sock_dir = False
-Path(self.test_dir).mkdir(parents=True, exist_ok=True)
+Path(self.sock_dir).mkdir(parents=True, exist_ok=True)
 except KeyError:
 self.sock_dir = tempfile.mkdtemp()
 self.tmp_sock_dir = True
-- 
2.31.1

[PATCH v4 3/5] qemu-iotests: move command line and environment handling from TestRunner to TestEnv

[Paolo Bonzini]

In the next patch, "check" will learn how to execute a test script without
going through TestRunner.  To enable this, keep only the text output
and subprocess handling in the TestRunner; move into TestEnv the logic
to prepare for running a subprocess.

Reviewed-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Paolo Bonzini 
Tested-by: Emanuele Giuseppe Esposito 
Message-Id: <20210323181928.311862-4-pbonz...@redhat.com>
---
 tests/qemu-iotests/testenv.py| 17 -
 tests/qemu-iotests/testrunner.py | 14 +-
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/tests/qemu-iotests/testenv.py b/tests/qemu-iotests/testenv.py
index 6d27712617..fca3a609e0 100644
--- a/tests/qemu-iotests/testenv.py
+++ b/tests/qemu-iotests/testenv.py
@@ -25,7 +25,7 @@
 import random
 import subprocess
 import glob
-from typing import Dict, Any, Optional, ContextManager
+from typing import List, Dict, Any, Optional, ContextManager
 
 
 def isxfile(path: str) -> bool:
@@ -74,6 +74,21 @@ class TestEnv(ContextManager['TestEnv']):
  'CACHEMODE_IS_DEFAULT', 'IMGFMT_GENERIC', 'IMGOPTSSYNTAX',
  'IMGKEYSECRET', 'QEMU_DEFAULT_MACHINE', 'MALLOC_PERTURB_']
 
+def prepare_subprocess(self, args: List[str]) -> Dict[str, str]:
+if self.debug:
+args.append('-d')
+
+with open(args[0], encoding="utf-8") as f:
+try:
+if f.readline().rstrip() == '#!/usr/bin/env python3':
+args.insert(0, self.python)
+except UnicodeDecodeError:  # binary test? for future.
+pass
+
+os_env = os.environ.copy()
+os_env.update(self.get_env())
+return os_env
+
 def get_env(self) -> Dict[str, str]:
 env = {}
 for v in self.env_variables:
diff --git a/tests/qemu-iotests/testrunner.py b/tests/qemu-iotests/testrunner.py
index 1fc61fcaa3..519924dc81 100644
--- a/tests/qemu-iotests/testrunner.py
+++ b/tests/qemu-iotests/testrunner.py
@@ -129,7 +129,6 @@ class TestRunner(ContextManager['TestRunner']):
 def __init__(self, env: TestEnv, makecheck: bool = False,
  color: str = 'auto') -> None:
 self.env = env
-self.test_run_env = self.env.get_env()
 self.makecheck = makecheck
 self.last_elapsed = LastElapsedTime('.last-elapsed-cache', env)
 
@@ -243,18 +242,7 @@ def do_run_test(self, test: str) -> TestResult:
 silent_unlink(p)
 
 args = [str(f_test.resolve())]
-if self.env.debug:
-args.append('-d')
-
-with f_test.open(encoding="utf-8") as f:
-try:
-if f.readline().rstrip() == '#!/usr/bin/env python3':
-args.insert(0, self.env.python)
-except UnicodeDecodeError:  # binary test? for future.
-pass
-
-env = os.environ.copy()
-env.update(self.test_run_env)
+env = self.env.prepare_subprocess(args)
 
 t0 = time.time()
 with f_bad.open('w', encoding="utf-8") as f:
-- 
2.31.1

[PATCH v4 4/5] qemu-iotests: let "check" spawn an arbitrary test command

[Paolo Bonzini]

Right now there is no easy way for "check" to print a reproducer command.
Because such a reproducer command line would be huge, we can instead teach
check to start a command of our choice.  This can be for example a Python
unit test with arguments to only run a specific subtest.

Move the trailing empty line to print_env(), since it always looks better
and one caller was not adding it.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Tested-by: Emanuele Giuseppe Esposito 
Message-Id: <20210323181928.311862-5-pbonz...@redhat.com>
---
 tests/qemu-iotests/check | 19 ++-
 tests/qemu-iotests/testenv.py|  3 ++-
 tests/qemu-iotests/testrunner.py |  1 -
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/tests/qemu-iotests/check b/tests/qemu-iotests/check
index d1c87ceaf1..7c9d3a0852 100755
--- a/tests/qemu-iotests/check
+++ b/tests/qemu-iotests/check
@@ -19,6 +19,9 @@
 import os
 import sys
 import argparse
+import shutil
+from pathlib import Path
+
 from findtests import TestFinder
 from testenv import TestEnv
 from testrunner import TestRunner
@@ -101,7 +104,7 @@ def make_argparser() -> argparse.ArgumentParser:
'rerun failed ./check command, starting from the '
'middle of the process.')
 g_sel.add_argument('tests', metavar='TEST_FILES', nargs='*',
-   help='tests to run')
+   help='tests to run, or "--" followed by a command')
 
 return p
 
@@ -114,6 +117,20 @@ if __name__ == '__main__':
   imgopts=args.imgopts, misalign=args.misalign,
   debug=args.debug, valgrind=args.valgrind)
 
+if len(sys.argv) > 1 and sys.argv[-len(args.tests)-1] == '--':
+if not args.tests:
+sys.exit("missing command after '--'")
+cmd = args.tests
+env.print_env()
+exec_pathstr = shutil.which(cmd[0])
+if exec_pathstr is None:
+sys.exit('command not found: ' + cmd[0])
+exec_path = Path(exec_pathstr).resolve()
+cmd[0] = str(exec_path)
+full_env = env.prepare_subprocess(cmd)
+os.chdir(exec_path.parent)
+os.execve(cmd[0], cmd, full_env)
+
 testfinder = TestFinder(test_dir=env.source_iotests)
 
 groups = args.groups.split(',') if args.groups else None
diff --git a/tests/qemu-iotests/testenv.py b/tests/qemu-iotests/testenv.py
index fca3a609e0..cd0e39b789 100644
--- a/tests/qemu-iotests/testenv.py
+++ b/tests/qemu-iotests/testenv.py
@@ -284,7 +284,8 @@ def print_env(self) -> None:
 PLATFORM  -- {platform}
 TEST_DIR  -- {TEST_DIR}
 SOCK_DIR  -- {SOCK_DIR}
-SOCKET_SCM_HELPER -- {SOCKET_SCM_HELPER}"""
+SOCKET_SCM_HELPER -- {SOCKET_SCM_HELPER}
+"""
 
 args = collections.defaultdict(str, self.get_env())
 
diff --git a/tests/qemu-iotests/testrunner.py b/tests/qemu-iotests/testrunner.py
index 519924dc81..2f56ac545d 100644
--- a/tests/qemu-iotests/testrunner.py
+++ b/tests/qemu-iotests/testrunner.py
@@ -316,7 +316,6 @@ def run_tests(self, tests: List[str]) -> bool:
 
 if not self.makecheck:
 self.env.print_env()
-print()
 
 test_field_width = max(len(os.path.basename(t)) for t in tests) + 2
 
-- 
2.31.1

Re: [PULL v2 00/31] target/hexagon patch queue

[Peter Maydell]

On Sun, 2 May 2021 at 15:44, Richard Henderson
 wrote:
>
> The following changes since commit 8f860d2633baf9c2b6261f703f86e394c6bc22ca:
>
>   Merge remote-tracking branch 'remotes/armbru/tags/pull-qapi-2021-04-30' 
> into staging (2021-04-30 16:02:00 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/rth7680/qemu.git tags/pull-hex-20210502
>
> for you to fetch changes up to e628c0156be74dd14a261bbd18674bacd1afcc7d:
>
>   Hexagon (target/hexagon) CABAC decode bin (2021-05-01 16:06:11 -0700)
>
> 
> Minor cleanups.
> Finish the rest of the hexagon integer instructions.
>
> 
> Taylor Simpson (31):
>   target/hexagon: translation changes
>   target/hexagon: remove unnecessary checks in find_iclass_slots
>   target/hexagon: Change DECODE_MAPPED_REG operand name to OPNUM
>   target/hexagon: fix typo in comment
>   target/hexagon: remove unnecessary semicolons
>   Hexagon (target/hexagon) TCG generation cleanup
>   Hexagon (target/hexagon) cleanup gen_log_predicated_reg_write_pair
>   Hexagon (target/hexagon) remove unnecessary inline directives
>   Hexagon (target/hexagon) use env_archcpu and env_cpu
>   Hexagon (target/hexagon) properly generate TB end for DISAS_NORETURN
>   Hexagon (target/hexagon) decide if pred has been written at TCG gen time
>   Hexagon (target/hexagon) change variables from int to bool when 
> appropriate
>   Hexagon (target/hexagon) remove unused carry_from_add64 function
>   Hexagon (target/hexagon) change type of softfloat_roundingmodes
>   Hexagon (target/hexagon) use softfloat default NaN and tininess
>   Hexagon (target/hexagon) replace float32_mul_pow2 with float32_scalbn
>   Hexagon (target/hexagon) use softfloat for float-to-int conversions
>   Hexagon (target/hexagon) cleanup ternary operators in semantics
>   Hexagon (target/hexagon) cleanup reg_field_info definition
>   Hexagon (target/hexagon) move QEMU_GENERATE to only be on during 
> macros.h
>   Hexagon (target/hexagon) compile all debug code
>   Hexagon (target/hexagon) add F2_sfrecipa instruction
>   Hexagon (target/hexagon) add F2_sfinvsqrta
>   Hexagon (target/hexagon) add A5_ACS (vacsh)
>   Hexagon (target/hexagon) add A6_vminub_RdP
>   Hexagon (target/hexagon) add A4_addp_c/A4_subp_c
>   Hexagon (target/hexagon) circular addressing
>   Hexagon (target/hexagon) bit reverse (brev) addressing
>   Hexagon (target/hexagon) load and unpack bytes instructions
>   Hexagon (target/hexagon) load into shifted register instructions
>   Hexagon (target/hexagon) CABAC decode bin


Applied, thanks.

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

-- PMM