For migration purposes, users might want to reuse the default RAM
backend id, but specify a different memory backend.

For example, to reuse "pc.ram" on q35, one has to set
    -machine q35,memory-backend=pc.ram
Only then, can a memory backend with the id "pc.ram" be created
manually.

Let's improve the error message by improving the hint. Use
error_append_hint() -- which in turn requires ERRP_GUARD().

Message-ID: <20230906120503.359863-12-david@redhat.com>
Suggested-by: ThinerLogoer <logoerthiner1@163.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

softmmu/physmem: Hint that "readonly=on,rom=off" exists when opening file R/W for private mapping fails

It's easy to miss that memory-backend-file with "share=off" (default)
will always try opening the file R/W as default, and fail if we don't
have write permissions to the file.

In that case, the user has to explicit specify "readonly=on,rom=off" to
get usable RAM, for example, for VM templating.

Let's hint that '-object memory-backend-file,readonly=on,rom=off,...'
exists to consume R/O files in a private mapping to create writable RAM,
but only if we have permissions to open the file read-only.

Message-ID: <20230906120503.359863-11-david@redhat.com>
Suggested-by: ThinerLogoer <logoerthiner1@163.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

Let's add some details about VM templating, focusing on the VM memory
configuration only.

There is much more to VM templating (VM state? block devices?), but I leave
that as future work.

Message-ID: <20230906120503.359863-10-david@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>

"-mem-path" corresponds to "memory-backend-file,share=off" and,
therefore, creates a private COW mapping of the file. For multi-proces
QEMU, we need proper shared file-backed memory.

Let's make that clearer.

Message-ID: <20230906120503.359863-9-david@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

open() does not fail on directories when opening them readonly (O_RDONLY).

Currently, we succeed opening such directories and fail later during
mmap(), resulting in a misleading error message.

$ ./qemu-system-x86_64 \
    -object memory-backend-file,id=ram0,mem-path=tmp,readonly=true,size=1g
 qemu-system-x86_64: unable to map backing store for guest RAM: No such device

To identify directories and handle them accordingly in file_ram_open()
also when readonly=true was specified, detect if we just opened a directory
using fstat() instead. Then, fail file_ram_open() right away, similarly
to how we now fail if the file does not exist and we want to open the
file readonly.

With this change, we get a nicer error message:
 qemu-system-x86_64: can't open backing store tmp for guest RAM: Is a directory

Note that the only memory-backend-file will end up calling
memory_region_init_ram_from_file() -> qemu_ram_alloc_from_file() ->
file_ram_open().

Message-ID: <20230906120503.359863-8-david@redhat.com>
Reported-by: Thiner Logoer <logoerthiner1@163.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Tested-by: Mario Casquero <mcasquer@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

Currently, if a file does not exist yet, file_ram_open() will create new
empty file and open it writable. However, it even does that when
readonly=true was specified.

Specifying O_RDONLY instead to create a new readonly file would
theoretically work, however, ftruncate() will refuse to resize the new
empty file and we'll get a warning:
    ftruncate: Invalid argument
And later eventually more problems when actually mmap'ing that file and
accessing it.

If someone intends to let QEMU open+mmap a file read-only, better
create+resize+fill that file ahead of time outside of QEMU context.

We'll now fail with:
./qemu-system-x86_64 \
    -object memory-backend-file,id=ram0,mem-path=tmp,readonly=true,size=1g
qemu-system-x86_64: can't open backing store tmp for guest RAM: No such file or directory

All use cases of readonly files (R/O NVDIMMs, VM templating) work on
existing files, so silently creating new files might just hide user
errors when accidentally specifying a non-existent file.

Note that the only memory-backend-file will end up calling
memory_region_init_ram_from_file() -> qemu_ram_alloc_from_file() ->
file_ram_open().

Move error reporting to the single caller.

Message-ID: <20230906120503.359863-7-david@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

fallocate() will fail, let's print a nicer error message.

Message-ID: <20230906120503.359863-6-david@redhat.com>
Suggested-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

Let's remap with the proper protection that we can derive from
RAM_READONLY.

Message-ID: <20230906120503.359863-5-david@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: David Hildenbrand <david@redhat.com>

For now, "share=off,readonly=on" would always result in us opening the
file R/O and mmap'ing the opened file MAP_PRIVATE R/O -- effectively
turning it into ROM.

Especially for VM templating, "share=off" is a common use case. However,
that use case is impossible with files that lack write permissions,
because "share=off,readonly=on" will not give us writable RAM.

The sole user of ROM via memory-backend-file are R/O NVDIMMs, but as we
have users (Kata Containers) that rely on the existing behavior --
malicious VMs should not be able to consume COW memory for R/O NVDIMMs --
we cannot change the semantics of "share=off,readonly=on"

So let's add a new "rom" property with on/off/auto values. "auto" is
the default and what most people will use: for historical reasons, to not
change the old semantics, it defaults to the value of the "readonly"
property.

For VM templating, one can now use:
    -object memory-backend-file,share=off,readonly=on,rom=off,...

But we'll disallow:
    -object memory-backend-file,share=on,readonly=on,rom=off,...
because we would otherwise get an error when trying to mmap the R/O file
shared and writable. An explicit error message is cleaner.

We will also disallow for now:
    -object memory-backend-file,share=off,readonly=off,rom=on,...
    -object memory-backend-file,share=on,readonly=off,rom=on,...
It's not harmful, but also not really required for now.

Alternatives that were abandoned:
* Make "unarmed=on" for the NVDIMM set the memory region container
  readonly. We would still see a change of ROM->RAM and possibly run
  into memslot limits with vhost-user. Further, there might be use cases
  for "unarmed=on" that should still allow writing to that memory
  (temporary files, system RAM, ...).
* Add a new "readonly=on/off/auto" parameter for NVDIMMs. Similar issues
  as with "unarmed=on".
* Make "readonly" consume "on/off/file" instead of being a 'bool' type.
  This would slightly changes the behavior of the "readonly" parameter:
  values like true/false (as accepted by a 'bool'type) would no longer be
  accepted.

Message-ID: <20230906120503.359863-4-david@redhat.com>
Acked-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

There is a difference between how we open a file and how we mmap it,
and we want to support writable private mappings of readonly files. Let's
define RAM_READONLY and RAM_READONLY_FD flags, to replace the single
"readonly" parameter for file-related functions.

In memory_region_init_ram_from_fd() and memory_region_init_ram_from_file(),
initialize mr->readonly based on the new RAM_READONLY flag.

While at it, add some RAM_* flags we missed to add to the list of accepted
flags in the documentation of some functions.

No change in functionality intended. We'll make use of both flags next
and start setting them independently for memory-backend-file.

Message-ID: <20230906120503.359863-3-david@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

Currently, when using a true R/O NVDIMM (ROM memory backend) with a label
area, the VM can easily crash QEMU by trying to write to the label area,
because the ROM memory is mmap'ed without PROT_WRITE.

    [root@vm-0 ~]# ndctl disable-region region0
    disabled 1 region
    [root@vm-0 ~]# ndctl zero-labels nmem0
    -> QEMU segfaults

Let's remember whether we have a ROM memory backend and properly
reject the write request:

    [root@vm-0 ~]# ndctl disable-region region0
    disabled 1 region
    [root@vm-0 ~]# ndctl zero-labels nmem0
    zeroed 0 nmem

In comparison, on a system with a R/W NVDIMM:

    [root@vm-0 ~]# ndctl disable-region region0
    disabled 1 region
    [root@vm-0 ~]# ndctl zero-labels nmem0
    zeroed 1 nmem

For ACPI, just return "unsupported", like if no label exists. For spapr,
return "H_P2", similar to when no label area exists.

Could we rely on the "unarmed" property? Maybe, but it looks cleaner to
only disallow what certainly cannot work.

After all "unarmed=on" primarily means: cannot accept persistent writes. In
theory, there might be setups where devices with "unarmed=on" set could
be used to host non-persistent data (temporary files, system RAM, ...); for
example, in Linux, admins can overwrite the "readonly" setting and still
write to the device -- which will work as long as we're not using ROM.
Allowing writing label data in such configurations can make sense.

Message-ID: <20230906120503.359863-2-david@redhat.com>
Fixes: dbd730e8 ("nvdimm: check -object memory-backend-file, readonly=on option")
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: David Hildenbrand <david@redhat.com>

Unify implementation of carry-less multiply.
Accelerate carry-less multiply for 64x64->128.

# -----BEGIN PGP SIGNATURE-----
#
# iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmUEiPodHHJpY2hhcmQu
# aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV/akgf/XkiIeErWJr1YXSbS
# YPQtCsDAfIrqn3RiyQ2uwSn2eeuwVqTFFPGER04YegRDK8dyO874JBfvOwmBT70J
# I/aU8Z4BbRyNu9nfaCtFMlXQH9KArAKcAds1PnshfcnI5T2yBloZ1sAU97IuJFZk
# Uuz96H60+ohc4wzaUiPqPhXQStgZeSYwwAJB0s25DhCckdea0udRCAJ1tQTVpxkM
# wIFef1SHPoM6DtMzFKHLLUH6VivSlHjqx8GqFusa7pVqfQyDzNBfwvDl1F/bkE07
# yTocQEkV3QnZvIplhqUxAaZXIFZr9BNk7bDimMjHW6z3pNPN3T8zRn4trNjxbgPV
# jqzAtg==
# =8nnk
# -----END PGP SIGNATURE-----
# gpg: Signature made Fri 15 Sep 2023 12:40:26 EDT
# gpg:                using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg:                issuer "richard.henderson@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A  05C0 64DF 38E8 AF7E 215F

* tag 'pull-crypto-20230915' of https://gitlab.com/rth7680/qemu

:
  host/include/aarch64: Implement clmul.h
  host/include/i386: Implement clmul.h
  target/ppc: Use clmul_64
  target/s390x: Use clmul_64
  target/i386: Use clmul_64
  target/arm: Use clmul_64
  crypto: Add generic 64-bit carry-less multiply routine
  target/ppc: Use clmul_32* routines
  target/s390x: Use clmul_32* routines
  target/arm: Use clmul_32* routines
  crypto: Add generic 32-bit carry-less multiply routines
  target/ppc: Use clmul_16* routines
  target/s390x: Use clmul_16* routines
  target/arm: Use clmul_16* routines
  crypto: Add generic 16-bit carry-less multiply routines
  target/ppc: Use clmul_8* routines
  target/s390x: Use clmul_8* routines
  target/arm: Use clmul_8* routines
  crypto: Add generic 8-bit carry-less multiply routines

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Detect PMULL in cpuinfo; implement the accel hook.

Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Detect PCLMUL in cpuinfo; implement the accel hook.

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routine for 64-bit carry-less multiply.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use the generic routine for 64-bit carry-less multiply.
Remove our local version of galois_multiply64.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routine for 64-bit carry-less multiply.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routine for 64-bit carry-less multiply.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 32-bit carry-less multiply.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 32-bit carry-less multiply.
Remove our local version of galois_multiply32.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 32-bit carry-less multiply.
Remove our local version of pmull_d.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 16-bit carry-less multiply.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 16-bit carry-less multiply.
Remove our local version of galois_multiply16.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 16-bit carry-less multiply.
Remove our local version of pmull_w.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 8-bit carry-less multiply.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 8-bit carry-less multiply.
Remove our local version of galois_multiply8.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Use generic routines for 8-bit carry-less multiply.
Remove our local version of pmull_h.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

Merge tpm 2023/09/12 v3

# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCAAdFiEEuBi5yt+QicLVzsZrda1lgCoLQhEFAmUBrwgACgkQda1lgCoL
# QhG9PQgA5drE1s0dYGkAIZimOsRKvduMV/kqeTmqnhGSUBM9jnYLWssnuG7/nDAi
# IXTqoKOzw27TGZKNiKuCO7PvlKCeirPEk7KmHk2JrxjC/QjtExMZLF700eLemP9/
# RBKwHerT8mLAkVuIGFvFgU9nQRrg/YX6kSvOFBJEl4XBn4w/vyY7gp3QbJgqcl36
# jrL7qJXrxQnT0BRRy+NlmmG3WswIY6xZpURdYKWMAINeNSH2DW2JxiDov2+fUVWH
# jp7SKBzCsXvD/RjRz1WWRpsrz3EtC7LiaLiB685XZsMcavb1zy0Pj7pchjr6NkwF
# 2gTWFPr/YG/eYoodtix2r2ElG4hyJQ==
# =WBnS
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 13 Sep 2023 08:46:00 EDT
# gpg:                using RSA key B818B9CADF9089C2D5CEC66B75AD65802A0B4211
# gpg: Good signature from "Stefan Berger <stefanb@linux.vnet.ibm.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: B818 B9CA DF90 89C2 D5CE  C66B 75AD 6580 2A0B 4211

* tag 'pull-tpm-2023-09-12-3' of https://github.com/stefanberger/qemu-tpm

:
  tpm: fix crash when FD >= 1024 and unnecessary errors due to EINTR

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

* target/i386: fix non-optimized compilation on clang
* fix detection of Solaris/IllumOS

# -----BEGIN PGP SIGNATURE-----
#
# iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmUBj8cUHHBib256aW5p
# QHJlZGhhdC5jb20ACgkQv/vSX3jHroOP7QgApdNqHKH4zNbBRPk/cxYDZEd0maPl
# nolD0eBts5ZWDYnQk/fFzHflzh/b5F119xv9H3fB86i/D2JNUMdqFR8QmQr9ZwEW
# izjXe8CdWto4dsW2RQbxGihThjMGu5BTZucqKSvLiZcyTQhPhwZ917Jo9YM5k072
# /1ECrCZYmCr2RECyNG6/zRrph8hustz5O0QEL65YhqK8ztttr+7E33m3CJ1fGEDy
# nbXu/WKrUxG20ohQJJ7Slpt9XTBGQXlfUO5gSg3nxkS9xqOjc15sCh+yit4gvS8f
# IDi8xD2JTWP05xQppSv33plEvmi+KrCY8d965isRsVbzPh5qB2osBoAa/A==
# =bOr3
# -----END PGP SIGNATURE-----
# gpg: Signature made Wed 13 Sep 2023 06:32:39 EDT
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "pbonzini@redhat.com"
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full]
# gpg:                 aka "Paolo Bonzini <pbonzini@redhat.com>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* tag 'for-upstream' of https://gitlab.com/bonzini/qemu

:
  target/i386: Call accel-agnostic x86_cpu_get_supported_cpuid()
  target/i386: Drop accel_uses_host_cpuid before x86_cpu_get_supported_cpuid
  target/i386: Check kvm_hyperv_expand_features() return value
  meson: Fix targetos match for illumos and Solaris.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

hw/nvme updates

Two fixes for dynamic array allocation.

# -----BEGIN PGP SIGNATURE-----
#
# iQEzBAABCgAdFiEEUigzqnXi3OaiR2bATeGvMW1PDekFAmUAc8AACgkQTeGvMW1P
# DelwhQgAxD7imw85V89Dz58LgrFoq5XZz2cq6Q5BsudyZd8FW5r7lOn9c1i0Yu2x
# iiP93FX0b5LPQ9/8/liz3oHu1HZ7+hX+VeDZSQ1/bugfXM/eDSPA7lf7GG1np312
# 9lKRs8o+T4Di7v93kdiEi6G3b0jQSmZ722aMa54isk58hy1mcUTnGxvPZpVZutTP
# lYhwuElQIsnnKXB0jaRlpcDkpXdHJ1wwziaYLM7pus+tElMiSkFP05j2pX9iigKu
# 7g+Hs+DaqrOzdoF/6uu72IKygq3/5H8iou1No/7OICWbFti5Qhhra0OKQE6nrlKd
# 51fnWA6VjpO5g9+diwRRYbjEiOrkqQ==
# =wn4B
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 12 Sep 2023 10:20:48 EDT
# gpg:                using RSA key 522833AA75E2DCE6A24766C04DE1AF316D4F0DE9
# gpg: Good signature from "Klaus Jensen <its@irrelevant.dk>" [unknown]
# gpg:                 aka "Klaus Jensen <k.jensen@samsung.com>" [unknown]
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg:          There is no indication that the signature belongs to the owner.
# Primary key fingerprint: DDCA 4D9C 9EF9 31CC 3468  4272 63D5 6FC5 E55D A838
#      Subkey fingerprint: 5228 33AA 75E2 DCE6 A247  66C0 4DE1 AF31 6D4F 0DE9

* tag 'nvme-next-pull-request' of https://gitlab.com/birkelund/qemu

:
  hw/nvme: Avoid dynamic stack allocation
  hw/nvme: Use #define to avoid variable length array

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

Replace select() with poll() to fix a crash when QEMU has a large number
of FDs. Also use RETRY_ON_EINTR to avoid unnecessary errors due to EINTR.

Cc: qemu-stable@nongnu.org
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2020133


Fixes: 56a3c24f ("tpm: Probe for connected TPM 1.2 or TPM 2")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>

* Enable AP (crypto adapter) instructions for s390x PV-guests
* Allow NVME for s390x machines
* Update Linux headers to v6.6-rc1

# -----BEGIN PGP SIGNATURE-----
#
# iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmUATY8RHHRodXRoQHJl
# ZGhhdC5jb20ACgkQLtnXdP5wLbVjBhAAlfXhQuxFdSRkPLyPgSuAInGTZfsW7A56
# 6vunyzP3ZyY5G0WtbgKZ5ovDIfjzlNYvkxWmQ4m4PWEY2JaBKOqeS9+lFkdZmGD9
# Sj1u+EereQS5MsJ31Vg2LHDKv5QbtNbVOq4KIm30qpzj1OfhfZzzqU0tGnaDlz/T
# PW2bSQl4cGHExcYpprWx02cXsMnodWwGV2FTgtc9D42YyE1q5IDX8phjFFzUHfcQ
# p3cjM0S2M8KOGJ5+0w2/0C4DEKgLH0OuA/JY3W+f94O+jdqoYUJpom4m6FywIKrr
# 38c7UqQESh7r/te1UkgvxfVCbTlptsS21xQNbsa+TS/apP6IMU7VJI3N14Qshtba
# cqcP54aGC+9v5FRz7E5njCJWJQv9JWInrKYTEEtSTFCguGCQO2owulba70MNrQc8
# hQkBXOzqnqYVxdktcHkbnq6QZoKLfsGAxfarQPPJySNUyGgoaM0JFlzp3z0hjAHY
# aGRZdN4kU+hF7/0RQygYDN4AzTQhn3EMZ6q6o81xVeKzfbziA3fCLXX5J1bd+rO8
# 3LKPrmOuk3dadRVlVTyFrtlG9SEMRen8dh12oru28ebW2WTeYm71zQf7SCPGzaKE
# hJMtlN7B9ogGxDpLJvTDLHbKNbwyIcW00GjyWiUwBg88ACg63tulD2kpUxBs2PwF
# bVk/lIWMqL0=
# =zeRZ
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 12 Sep 2023 07:37:51 EDT
# gpg:                using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5
# gpg:                issuer "thuth@redhat.com"
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg:                 aka "Thomas Huth <thuth@redhat.com>" [full]
# gpg:                 aka "Thomas Huth <huth@tuxfamily.org>" [full]
# gpg:                 aka "Thomas Huth <th.huth@posteo.de>" [unknown]
# Primary key fingerprint: 27B8 8847 EEE0 2501 18F3  EAB9 2ED9 D774 FE70 2DB5

* tag 'pull-request-2023-09-12' of https://gitlab.com/thuth/qemu

:
  tests/qtest/pflash: Clean up local variable shadowing
  kconfig: Add NVME to s390x machines
  target/s390x: AP-passthrough for PV guests
  target/s390x/kvm: Refactor AP functionalities
  linux-headers: Update to Linux v6.6-rc1
  s390x: do a subsystem reset before the unprotect on reboot
  s390x/ap: fix missing subsystem reset registration

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

UI patch queue

- vhost-user-gpu: support dmabuf modifiers
- fix VNC crash when there are no active_console
- cleanups and refactoring in ui/vc code

# -----BEGIN PGP SIGNATURE-----
#
# iQJQBAABCAA6FiEEh6m9kz+HxgbSdvYt2ujhCXWWnOUFAmUAQX4cHG1hcmNhbmRy
# ZS5sdXJlYXVAcmVkaGF0LmNvbQAKCRDa6OEJdZac5Y4jD/4/whR7a1KZqHytl6sc
# cCQ0Xn0gpcPM8rn3tWItp2vAOlGmx8ACfAyXYa5QzO7pBOU/xoMJt8a99geNRXFu
# nN33UJ0NRAWW6V0/cF5AVe9clckzs1Vq4VX2ITP+VAG+c+kt4E3fgFn9o8nwnBrd
# zuiqYz4pO9yBVO/av/FZQcBY8s9/M8jrdraDNNhsY2O2k2zLTxt1xxNG5qeVvPUw
# 2RZyc/EOG7RzW8eUA55BW/NU8Olg5u7dxsB0jfYnWBQxknOy5c+wF9MTGJSKmdGk
# HmgfMns6intUdfHmmJuDpP1Tiy1sVK1lkrsMeeQ67M84lYZsrSI+kIG5+YbWN8vx
# mMB/qwDmNMVMnGiBN5/ktvAJwcilYBUqen0KFrEHBghTpGhqAVoBNCC1MT/9w/bO
# c3/E1viuCi8OamPixVu9LeqQsxuP2jK5qxjfyDYH87HdnljSY6wFbVzD/2zz5YNv
# 43JtEbP9bv1yyRRd+JTpD54vCK0IZK7MBR8MbJqfknpbEw1FSPofRQxCSe9BlSJ/
# nYamatH9I9i92kGg5eD573X+UcLX9eOPBw8gVNKxuttwSIW1cwjGKi12B9MiFMg7
# Z6jP3gvpe9DrYef+4Wojo1PAioyweZVG5IFtWIqXRZjPwAoIzzVgBcEtcq4qeZwX
# BAliXWeUcRGsbLorT3COx2DjBw==
# =Xsr0
# -----END PGP SIGNATURE-----
# gpg: Signature made Tue 12 Sep 2023 06:46:22 EDT
# gpg:                using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5
# gpg:                issuer "marcandre.lureau@redhat.com"
# gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full]
# gpg:                 aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full]
# Primary key fingerprint: 87A9 BD93 3F87 C606 D276  F62D DAE8 E109 7596 9CE5

* tag 'ui-pull-request' of https://gitlab.com/marcandre.lureau/qemu

:
  ui: add precondition for dpy_get_ui_info()
  ui: fix crash when there are no active_console
  virtio-gpu/win32: set the destroy function on load
  ui/console: move DisplaySurface to its own header
  ui/vc: split off the VC part from console.c
  ui/vc: preliminary QemuTextConsole changes before split
  ui/console: remove redundant format field
  ui/vc: rename kbd_put to qemu_text_console functions
  ui/vc: remove kbd_put_keysym() and update function calls
  vmmouse: use explicit code
  vmmouse: replace DPRINTF with tracing
  vhost-user-gpu: support dmabuf modifiers
  contrib/vhost-user-gpu: add support for sending dmabuf modifiers
  docs: vhost-user-gpu: add protocol changes for dmabuf modifiers

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

x86_cpu_get_supported_cpuid() is generic and handles the different
accelerators. Use it instead of kvm_arch_get_supported_cpuid().

That fixes a link failure introduced by commit 3adce820
("target/i386: Remove unused KVM stubs") when QEMU is configured
as:

  $ ./configure --cc=clang \
    --target-list=x86_64-linux-user,x86_64-softmmu \
    --enable-debug

We were getting:

  [71/71] Linking target qemu-x86_64
  FAILED: qemu-x86_64
  /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o: in function `cpu_x86_cpuid':
  cpu.c:(.text+0x1374): undefined reference to `kvm_arch_get_supported_cpuid'
  /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o: in function `x86_cpu_filter_features':
  cpu.c:(.text+0x81c2): undefined reference to `kvm_arch_get_supported_cpuid'
  /usr/bin/ld: cpu.c:(.text+0x81da): undefined reference to `kvm_arch_get_supported_cpuid'
  /usr/bin/ld: cpu.c:(.text+0x81f2): undefined reference to `kvm_arch_get_supported_cpuid'
  /usr/bin/ld: cpu.c:(.text+0x820a): undefined reference to `kvm_arch_get_supported_cpuid'
  /usr/bin/ld: libqemu-x86_64-linux-user.fa.p/target_i386_cpu.c.o:cpu.c:(.text+0x8225): more undefined references to `kvm_arch_get_supported_cpuid' follow
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  ninja: build stopped: subcommand failed.

For the record, this is because '--enable-debug' disables
optimizations (CFLAGS=-O0).

While at this (un)optimization level GCC eliminate the
following dead code (CPP output of mentioned build):

 static void x86_cpu_get_supported_cpuid(uint32_t func, uint32_t index,
                                         uint32_t *eax, uint32_t *ebx,
                                         uint32_t *ecx, uint32_t *edx)
 {
     if ((0)) {
         *eax = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EAX);
         *ebx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EBX);
         *ecx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_ECX);
         *edx = kvm_arch_get_supported_cpuid(kvm_state, func, index, R_EDX);
     } else if (0) {
         *eax = 0;
         *ebx = 0;
         *ecx = 0;
         *edx = 0;
     } else {
         *eax = 0;
         *ebx = 0;
         *ecx = 0;
         *edx = 0;
     }

Clang does not (see commit 2140cfa5 "i386: Fix build by
providing stub kvm_arch_get_supported_cpuid()").

Cc: qemu-stable@nongnu.org
Fixes: 3adce820 ("target/i386: Remove unused KVM stubs")
Reported-by: Kevin Wolf <kwolf@redhat.com>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20230913093009.83520-4-philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

x86_cpu_get_supported_cpuid() already checks for KVM/HVF
accelerators, so it is not needed to manually check it via
a call to accel_uses_host_cpuid() before calling it.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20230913093009.83520-3-philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

In case more code is added after the kvm_hyperv_expand_features()
call, check its return value (since it can fail).

Fixes: 071ce4b0 ("i386: expand Hyper-V features during CPU feature expansion time")
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20230913093009.83520-2-philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>