Re: [PATCH 00/76] target/arm: Implement FEAT_AFP and FEAT_RPRES

2025-01-28 Thread Peter Maydell
On Fri, 24 Jan 2025 at 16:28, Peter Maydell  wrote:
>
> This patchset implements emulation of the Arm FEAT_AFP and FEAT_RPRES
> extensions, which are floating-point related.

I plan to take into target-arm.next the following patches
from the start of this series: 3-21, 25, 26. (Paolo has
already picked up 1 and 2.)

I'm making the renaming of the FPCR_* constants RTH suggested
as I do that (i.e. not reposting the series just for that).
I'm also making the correction to the is_ebf() function
discussed in the review subthread on patch 7.

Handling the review comments on the rest of the series
will take a bit more time/work, but at least this way
v2 will be a bit smaller...

thanks
-- PMM



Re: [PATCH 02/11] acpi/ghes: add a firmware file with HEST address

2025-01-28 Thread Jonathan Cameron via
On Tue, 28 Jan 2025 11:00:34 +0100
Mauro Carvalho Chehab  wrote:

> Em Thu, 23 Jan 2025 10:02:17 +
> Jonathan Cameron  escreveu:
> 
> > On Wed, 22 Jan 2025 16:46:19 +0100
> > Mauro Carvalho Chehab  wrote:
> >   
> > > Store HEST table address at GPA, placing its content at
> > > hest_addr_le variable.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > > Reviewed-by: Jonathan Cameron 
> > > 
> > A few trivial things inline.
> > 
> > Jonathan
> >   
> > > ---
> > > 
> > > Change from v8:
> > > - hest_addr_lr is now pointing to the error source size and data.
> > > 
> > > Signed-off-by: Mauro Carvalho Chehab 
> > Bonus.  I guess you really like this patch :)  
> > > ---
> > >  hw/acpi/ghes.c | 17 -
> > >  include/hw/acpi/ghes.h |  1 +
> > >  2 files changed, 17 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/hw/acpi/ghes.c b/hw/acpi/ghes.c
> > > index 3f519ccab90d..34e3364d3fd8 100644
> > > --- a/hw/acpi/ghes.c
> > > +++ b/hw/acpi/ghes.c
> > > @@ -30,6 +30,7 @@
> > >  
> > >  #define ACPI_HW_ERROR_FW_CFG_FILE   "etc/hardware_errors"
> > >  #define ACPI_HW_ERROR_ADDR_FW_CFG_FILE  "etc/hardware_errors_addr"
> > > +#define ACPI_HEST_ADDR_FW_CFG_FILE  "etc/acpi_table_hest_addr"
> > >  
> > >  /* The max size in bytes for one error block */
> > >  #define ACPI_GHES_MAX_RAW_DATA_LENGTH   (1 * KiB)
> > > @@ -261,7 +262,7 @@ static void build_ghes_error_table(GArray 
> > > *hardware_errors, BIOSLinker *linker,
> > >  }
> > >  
> > >  /*
> > > - * tell firmware to write hardware_errors GPA into
> > > + * Tell firmware to write hardware_errors GPA into
> > 
> > Sneaky tidy up.  No problem with it in general but adding noise here, so if 
> > there
> > are others in the series maybe gather them up in a cleanup patch.  
> 
> There are no other cleanups pending. Besides, as you noticed, this
> aligns with the comment below. So, I'm opting to add a note at the
> patch's description.

ok.


> 
> > > + * once initialized.
> > > + */
> > > +bios_linker_loader_write_pointer(linker,
> > > + ACPI_HEST_ADDR_FW_CFG_FILE, 0,
> > 
> > Could wrap less and stay under 80 chars as both lines above add up to 70 
> > something  
> 
> Why? This follows QEMU coding style and lines aren't longer than 80
> columns. Besides, at least for my eyes and some experience doing 
> maintainership
> on other projects over the years, it is a lot quicker to identify function
> parameters if they're properly aligned with the parenthesis.
Ah. I didn't state this clearly enough.
   bios_linker_loader_write_pointer(linker, ACPI_HEST_ADDR_FW_CFG_FILE, 0,  
  
is also under 80 chars.


> 
> Thanks,
> Mauro




Re: [PATCH 09/21] hw/arm/fsl-imx8mp: Add PCIe support

2025-01-28 Thread Peter Maydell
On Mon, 20 Jan 2025 at 20:38, Bernhard Beschow  wrote:
>
> Linux checks for the PLLs in the PHY to be locked, so implement a model
> emulating that.
>
> Signed-off-by: Bernhard Beschow 

> diff --git a/docs/system/arm/imx8mp-evk.rst b/docs/system/arm/imx8mp-evk.rst
> index 1514bc5864..8d48580cb4 100644
> --- a/docs/system/arm/imx8mp-evk.rst
> +++ b/docs/system/arm/imx8mp-evk.rst
> @@ -14,6 +14,7 @@ The ``imx8mp-evk`` machine implements the following devices:
>   * Generic Interrupt Controller (GICv3)
>   * 4 UARTs
>   * 3 USDHC Storage Controllers
> + * 1 Designware PCI Express Controller
>   * Secure Non-Volatile Storage (SNVS) including an RTC
>   * Clock Tree
>
> @@ -62,3 +63,15 @@ Now that everything is prepared the newly built image can 
> be run in the QEMU
>-dtb imx8mp-evk-patched.dtb \
>-append "root=/dev/mmcblk2p2" \
>-drive file=sdcard.img,if=sd,bus=2,format=raw,id=mmcblk2
> +
> +Using PCI Devices
> +-
> +
> +The PCI Express controller spawns two PCI buses, of which only one can be 
> used.
> +By default QEMU assigns the wrong bus, so the correct one has to be specified
> +manually by adding ``bus=dw-pcie``. For example, when adding an Intel e1000
> +network card, the command line looks like:
> +
> +.. code-block:: bash
> +
> +  $ qemu-system-aarch64 -M imximp-evk ... -device virtio-net-pci,bus=dw-pcie

Why does this happen? Isn't there some way to make QEMU default to
using the right bus? Otherwise there's likely to be a lot of
user confusion because PCI "doesn't work"...

thanks
-- PMM



Re: [PATCH 21/21] hw/gpio/imx_gpio: Don't clear input GPIO values upon reset

2025-01-28 Thread Gustavo Romero

Hi,

On 1/20/25 17:37, Bernhard Beschow wrote:

Input GPIO values such as a present SD card may get notified before the GPIO
controller itself gets reset. Claring the input values thus loses data. Assuming


^- nit: Clearing


Cheers,
Gustavo


that input GPIO events are only fired when the state changes, the input values
shouldn't be reset.

Signed-off-by: Bernhard Beschow 
---
  hw/gpio/imx_gpio.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/hw/gpio/imx_gpio.c b/hw/gpio/imx_gpio.c
index 549a281ed7..25546221e0 100644
--- a/hw/gpio/imx_gpio.c
+++ b/hw/gpio/imx_gpio.c
@@ -298,7 +298,6 @@ static void imx_gpio_reset(DeviceState *dev)
  
  s->dr   = 0;

  s->gdir = 0;
-s->psr  = 0;
  s->icr  = 0;
  s->imr  = 0;
  s->isr  = 0;





Re: [PATCH 06/21] hw/arm/fsl-imx8mp: Implement clock tree

2025-01-28 Thread Peter Maydell
On Mon, 20 Jan 2025 at 20:38, Bernhard Beschow  wrote:
>
> Fixes quite a few stack traces during the Linux boot process. Also provides 
> the
> clocks for devices added later, e.g. enet1.
>
> Signed-off-by: Bernhard Beschow 
> ---
>  MAINTAINERS|   2 +
>  docs/system/arm/imx8mp-evk.rst |   1 +
>  include/hw/arm/fsl-imx8mp.h|   3 +
>  include/hw/misc/imx8mp_ccm.h   |  97 ++
>  hw/arm/fsl-imx8mp.c|  20 +++
>  hw/misc/imx8mp_ccm.c   | 315 +
>  hw/misc/meson.build|   1 +
>  7 files changed, 439 insertions(+)
>  create mode 100644 include/hw/misc/imx8mp_ccm.h
>  create mode 100644 hw/misc/imx8mp_ccm.c
> diff --git a/include/hw/misc/imx8mp_ccm.h b/include/hw/misc/imx8mp_ccm.h
> new file mode 100644
> index 00..2378c157de
> --- /dev/null
> +++ b/include/hw/misc/imx8mp_ccm.h
> @@ -0,0 +1,97 @@
> +/*
> + * Copyright (c) 2025 Bernhard Beschow 
> + *
> + * i.MX8MP CCM, ANALOG IP blocks emulation code
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef IMX8MP_CCM_H
> +#define IMX8MP_CCM_H
> +
> +#include "hw/misc/imx_ccm.h"
> +#include "qom/object.h"
> +
> +enum IMX8MPAnalogRegisters {
> +ANALOG_AUDIO_PLL1_GEN_CTRL = 0x000 / 4,
> +ANALOG_AUDIO_PLL1_FDIV_CTL0 = 0x004 / 4,
> +ANALOG_AUDIO_PLL1_FDIV_CTL1 = 0x008 / 4,
> +ANALOG_AUDIO_PLL1_SSCG_CTRL = 0x00c / 4,
> +ANALOG_AUDIO_PLL1_MNIT_CTRL = 0x010 / 4,
> +ANALOG_AUDIO_PLL2_GEN_CTRL = 0x014 / 4,
> +ANALOG_AUDIO_PLL2_FDIV_CTL0 = 0x018 / 4,
> +ANALOG_AUDIO_PLL2_FDIV_CTL1 = 0x01c / 4,
> +ANALOG_AUDIO_PLL2_SSCG_CTRL = 0x020 / 4,
> +ANALOG_AUDIO_PLL2_MNIT_CTRL = 0x024 / 4,
> +ANALOG_VIDEO_PLL1_GEN_CTRL = 0x028 / 4,
> +ANALOG_VIDEO_PLL1_FDIV_CTL0 = 0x02c / 4,
> +ANALOG_VIDEO_PLL1_FDIV_CTL1 = 0x030 / 4,
> +ANALOG_VIDEO_PLL1_SSCG_CTRL = 0x034 / 4,
> +ANALOG_VIDEO_PLL1_MNIT_CTRL = 0x038 / 4,
> +ANALOG_DRAM_PLL_GEN_CTRL = 0x050 / 4,
> +ANALOG_DRAM_PLL_FDIV_CTL0 = 0x054 / 4,
> +ANALOG_DRAM_PLL_FDIV_CTL1 = 0x058 / 4,
> +ANALOG_DRAM_PLL_SSCG_CTRL = 0x05c / 4,
> +ANALOG_DRAM_PLL_MNIT_CTRL = 0x060 / 4,
> +ANALOG_GPU_PLL_GEN_CTRL = 0x064 / 4,
> +ANALOG_GPU_PLL_FDIV_CTL0 = 0x068 / 4,
> +ANALOG_GPU_PLL_LOCKD_CTRL = 0x06c / 4,
> +ANALOG_GPU_PLL_MNIT_CTRL = 0x070 / 4,
> +ANALOG_VPU_PLL_GEN_CTRL = 0x074 / 4,
> +ANALOG_VPU_PLL_FDIV_CTL0 = 0x078 / 4,
> +ANALOG_VPU_PLL_LOCKD_CTRL = 0x07c / 4,
> +ANALOG_VPU_PLL_MNIT_CTRL = 0x080 / 4,
> +ANALOG_ARM_PLL_GEN_CTRL = 0x084 / 4,
> +ANALOG_ARM_PLL_FDIV_CTL0 = 0x088 / 4,
> +ANALOG_ARM_PLL_LOCKD_CTRL = 0x08c / 4,
> +ANALOG_ARM_PLL_MNIT_CTRL = 0x090 / 4,
> +ANALOG_SYS_PLL1_GEN_CTRL = 0x094 / 4,
> +ANALOG_SYS_PLL1_FDIV_CTL0 = 0x098 / 4,
> +ANALOG_SYS_PLL1_LOCKD_CTRL = 0x09c / 4,
> +ANALOG_SYS_PLL1_MNIT_CTRL = 0x100 / 4,
> +ANALOG_SYS_PLL2_GEN_CTRL = 0x104 / 4,
> +ANALOG_SYS_PLL2_FDIV_CTL0 = 0x108 / 4,
> +ANALOG_SYS_PLL2_LOCKD_CTRL = 0x10c / 4,
> +ANALOG_SYS_PLL2_MNIT_CTRL = 0x110 / 4,
> +ANALOG_SYS_PLL3_GEN_CTRL = 0x114 / 4,
> +ANALOG_SYS_PLL3_FDIV_CTL0 = 0x118 / 4,
> +ANALOG_SYS_PLL3_LOCKD_CTRL = 0x11c / 4,
> +ANALOG_SYS_PLL3_MNIT_CTRL = 0x120 / 4,
> +ANALOG_OSC_MISC_CFG = 0x124 / 4,
> +ANALOG_ANAMIX_PLL_MNIT_CTL = 0x128 / 4,
> +
> +ANALOG_DIGPROG = 0x800 / 4,
> +ANALOG_MAX,
> +};
> +
> +enum IMX8MPCCMRegisters {
> +CCM_MAX = 0xc6fc / sizeof(uint32_t) + 1,
> +};
> +
> +#define TYPE_IMX8MP_CCM "imx8mp.ccm"
> +OBJECT_DECLARE_SIMPLE_TYPE(IMX8MPCCMState, IMX8MP_CCM)
> +
> +struct IMX8MPCCMState {
> +IMXCCMState parent_obj;
> +
> +MemoryRegion iomem;
> +
> +uint32_t ccm[CCM_MAX];
> +};
> +
> +
> +#define TYPE_IMX8MP_ANALOG "imx8mp.analog"
> +OBJECT_DECLARE_SIMPLE_TYPE(IMX8MPAnalogState, IMX8MP_ANALOG)
> +
> +struct IMX8MPAnalogState {
> +IMXCCMState parent_obj;
> +
> +struct {
> +MemoryRegion container;
> +MemoryRegion analog;
> +} mmio;
> +
> +uint32_t analog[ANALOG_MAX];
> +};
> +
> +#endif /* IMX8MP_CCM_H */

This seems to be implementing two separate devices in a single
source file. Generally we prefer one device per file. Is
there a reason they can't be split?

thanks
-- PMM



Re: [PATCH 1/5] tests/functional: Add a decorator for skipping long running tests

2025-01-28 Thread Thomas Huth

On 24/01/2025 16.28, Daniel P. Berrangé wrote:

On Fri, Jan 24, 2025 at 03:15:25PM +0100, Thomas Huth wrote:

Some tests have a very long runtime and might run into timeout
issues e.g. when QEMU has been compiled with --enable-debug.
Add a decorator for marking them more easily and document the
corresponding environment variable that is used to enable the
tests.

Signed-off-by: Thomas Huth 
---
  docs/devel/testing/functional.rst|  8 
  tests/functional/qemu_test/__init__.py   |  2 +-
  tests/functional/qemu_test/decorators.py | 14 ++
  tests/functional/test_arm_quanta_gsj.py  |  5 +++--
  4 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/docs/devel/testing/functional.rst 
b/docs/devel/testing/functional.rst
index ae238ed3fc..7d9396b696 100644
--- a/docs/devel/testing/functional.rst
+++ b/docs/devel/testing/functional.rst
@@ -351,5 +351,13 @@ the code snippet below:
  Tests should not live in this state forever and should either be fixed
  or eventually removed.
  
+QEMU_TEST_TIMEOUT_EXPECTED

+^^
+Tests that have a very long runtime and might run into timeout issues
+e.g. if the QEMU binary has been compiled with debugging options enabled.
+To avoid these timeout issues by default and to save some precious CPU
+cycles during normal testing, such tests are disabled by default unless
+the QEMU_TEST_TIMEOUT_EXPECTED environment variable has been set.
+
  
  .. _unittest: https://docs.python.org/3/library/unittest.html

diff --git a/tests/functional/qemu_test/__init__.py 
b/tests/functional/qemu_test/__init__.py
index da1830286d..b1a19d2a4b 100644
--- a/tests/functional/qemu_test/__init__.py
+++ b/tests/functional/qemu_test/__init__.py
@@ -14,7 +14,7 @@
  from .testcase import QemuBaseTest, QemuUserTest, QemuSystemTest
  from .linuxkernel import LinuxKernelTest
  from .decorators import skipIfMissingCommands, skipIfNotMachine, \
-skipFlakyTest, skipUntrustedTest, skipBigDataTest, \
+skipFlakyTest, skipUntrustedTest, skipBigDataTest, skipLongRuntime, \


s/Runtime/RunningTime/, but actually in terms of naming
convention, 'skipSlowTest' would fit better.


Ack, that sounds better, indeed.




diff --git a/tests/functional/qemu_test/decorators.py 
b/tests/functional/qemu_test/decorators.py
index df088bc090..8f311e5309 100644
--- a/tests/functional/qemu_test/decorators.py
+++ b/tests/functional/qemu_test/decorators.py
@@ -86,6 +86,20 @@ def skipBigDataTest():
  return skipUnless(os.getenv('QEMU_TEST_ALLOW_LARGE_STORAGE'),
'Test requires large host storage space')
  
+'''

+Decorator to skip execution of tests which have a really long
+runtime (and might e.g. time out if QEMU has been compiled with
+debugging enabled) unless the $QEMU_TEST_TIMEOUT_EXPECTED
+environment variable is set
+
+Example:
+
+  @skipLongRuntime()
+'''
+def skipLongRuntime():
+return skipUnless(os.getenv('QEMU_TEST_TIMEOUT_EXPECTED'),
+  'Test has a very long runtime and might time out')
+


You're preserving the existnig env var which is good,
but I have a little niggling desire to unify the
naming conventions:

   skipFlakyTest -> $QEMU_TEST_ALLOW_FLAKY
   skipUntrustedTest -> $QEMU_TEST_ALLOW_UNTRUSTED
   skipBigDataTest   -> $QEMU_TEST_ALLOW_BIG_DATA
   skipSlowTest  -> $QEMU_TEST_ALLOW_SLOW

Could be a separate patch though if you like the idea.


I like the idea, some of the others are already starting with 
QEMU_TEST_ALLOW_, so the renaming makes sense to me, too. I'll change this 
patch in v2, but I'll leave the others for now - feel free to send a patch 
for them, if not I'll tackle them sometime later.


 Thomas




Re: [PATCH v5] target/arm: Always add pmu property for Armv7-A/R+

2025-01-28 Thread Peter Maydell
On Sat, 4 Jan 2025 at 07:10, Akihiko Odaki  wrote:
>
> kvm-steal-time and sve properties are added for KVM even if the
> corresponding features are not available. Always add pmu property for
> Armv7+. Note that the property is added only for Armv7-A/R+ as QEMU
> currently emulates PMU only for such versions, and a different
> version may have a different definition of PMU or may not have one at
> all.

This isn't how we generally handle CPU properties corresponding
to features. The standard setup is:
 * if the CPU can't have feature foo, no property
 * if the CPU does have feature foo, define a property, so the
   user can turn it off

See also my longer explanation in reply to this patch in v4:

https://lore.kernel.org/all/CAFEAcA_HWfCU09NfZDf6EC=rpvhn148avyscztq8pqpbmfx...@mail.gmail.com/

> Signed-off-by: Akihiko Odaki 
> ---
> The "pmu" property is added only when the PMU is available. This makes
> tests/qtest/arm-cpu-features.c fail as it reads the property to check
> the availability. Always add the property when the architecture defines
> the PMU even if it's not available to fix this.

This seems to me like a bug in the test.

> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index dcedadc89eaf..e76d42398eb2 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -1761,6 +1761,10 @@ void arm_cpu_post_init(Object *obj)
>
>  if (!arm_feature(&cpu->env, ARM_FEATURE_M)) {
>  qdev_property_add_static(DEVICE(obj), 
> &arm_cpu_reset_hivecs_property);
> +
> +if (arm_feature(&cpu->env, ARM_FEATURE_V7)) {
> +object_property_add_bool(obj, "pmu", arm_get_pmu, arm_set_pmu);
> +}
>  }
>
>  if (arm_feature(&cpu->env, ARM_FEATURE_V8)) {
> @@ -1790,7 +1794,6 @@ void arm_cpu_post_init(Object *obj)
>
>  if (arm_feature(&cpu->env, ARM_FEATURE_PMU)) {
>  cpu->has_pmu = true;
> -object_property_add_bool(obj, "pmu", arm_get_pmu, arm_set_pmu);
>  }
>
>  /*

This would allow the user to enable the PMU on a CPU that
says it doesn't have one. We don't generally permit that.

thanks
-- PMM



Re: [PATCH 07/76] target/arm: Use vfp.fp_status_a64 in A64-only helper functions

2025-01-28 Thread Richard Henderson

On 1/28/25 04:35, Peter Maydell wrote:

On Sat, 25 Jan 2025 at 15:16, Richard Henderson
 wrote:


On 1/24/25 08:27, Peter Maydell wrote:

@@ -2808,7 +2808,7 @@ bool is_ebf(CPUARMState *env, float_status *statusp, 
float_status *oddstatusp)
*/
   bool ebf = is_a64(env) && env->vfp.fpcr & FPCR_EBF;

-*statusp = env->vfp.fp_status;
+*statusp = env->vfp.fp_status_a64;
   set_default_nan_mode(true, statusp);

   if (ebf) {


Is this really correct?  !ebf includes aa32.


Whoops, yes. I'll drop this hunk of the patch and put in this
patch afterwards:

Author: Peter Maydell 
Date:   Tue Jan 28 11:40:13 2025 +

 target/arm: Use fp_status_a64 or fp_status_a32 in is_ebf()

 In is_ebf(), we might be called for A64 or A32, but we have
 the CPUARMState* so we can select fp_status_a64 or
 fp_status_a32 accordingly.

 Signed-off-by: Peter Maydell 

diff --git a/target/arm/tcg/vec_helper.c b/target/arm/tcg/vec_helper.c
index 011726a72d4..2ba1f7cb32e 100644
--- a/target/arm/tcg/vec_helper.c
+++ b/target/arm/tcg/vec_helper.c
@@ -2808,7 +2808,7 @@ bool is_ebf(CPUARMState *env, float_status
*statusp, float_status *oddstatusp)
   */
  bool ebf = is_a64(env) && env->vfp.fpcr & FPCR_EBF;

-*statusp = env->vfp.fp_status;
+*statusp = is_a64(env) ? env->vfp.fp_status_a64 : env->vfp.fp_status_a32;
  set_default_nan_mode(true, statusp);


That'll do.

Reviewed-by: Richard Henderson 


r~



Re: [PULL 00/48] i386, rust changes for 2024-01-24

2025-01-28 Thread Stefan Hajnoczi
On Tue, Jan 28, 2025 at 6:25 AM Paolo Bonzini  wrote:
>
> The following changes since commit d6430c17d7113d3c38480dc34e59d00b0504e2f7:
>
>   Merge tag 'pull-riscv-to-apply-20250119-1' of 
> https://github.com/alistair23/qemu into staging (2025-01-19 08:55:46 -0500)
>
> are available in the Git repository at:
>
>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 021d8e747907d4a2226557bf9885d4c0fa6abd8b:
>
>   rust: qemu-api: add sub-subclass to the integration tests (2025-01-28 
> 12:22:54 +0100)

CI is hitting the following failure (see default.log):

thread '' panicked at 'already borrowed',
rust/qemu-api/libqemu_api.rlib.p/structured/cell.rs:450:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5

https://gitlab.com/qemu-project/qemu/-/jobs/8972076251/artifacts/browse/build/tests/functional/arm/test_arm_tuxrun.TuxRunArmTest.test_armv7be/

Do you want to include a patch that sets RUST_BACKTRACE=1 in the test
environment so the backtrace is captured in the logs?

Thanks,
Stefan

>
> 
> * target/i386: optimize string instructions
> * target/i386: new Sierra Forest and Clearwater Forest models
> * rust: type-safe vmstate implementation
> * rust: use interior mutability for PL011
> * rust: clean ups
> * memtxattrs: remove usage of bitfields from MEMTXATTRS_UNSPECIFIED
>
> 
> Paolo Bonzini (37):
>   rust: pl011: fix repr(C) for PL011Class
>   target/i386: inline gen_jcc into sole caller
>   target/i386: remove trailing 1 from gen_{j, cmov, set}cc1
>   target/i386: unify REP and REPZ/REPNZ generation
>   target/i386: unify choice between single and repeated string 
> instructions
>   target/i386: reorganize ops emitted by do_gen_rep, drop repz_opt
>   target/i386: tcg: move gen_set/reset_* earlier in the file
>   target/i386: fix RF handling for string instructions
>   target/i386: make cc_op handling more explicit for repeated string 
> instructions.
>   target/i386: do not use gen_op_jz_ecx for repeated string operations
>   target/i386: optimize CX handling in repeated string operations
>   target/i386: execute multiple REP/REPZ iterations without leaving TB
>   target/i386: pull computation of string update value out of loop
>   target/i386: extract common bits of gen_repz/gen_repz_nz
>   target/i386: avoid using s->tmp0 for add to implicit registers
>   rust: vmstate: add new type safe implementation
>   rust: vmstate: implement VMState for non-leaf types
>   rust: vmstate: add varray support to vmstate_of!
>   rust: vmstate: implement Zeroable for VMStateField
>   rust: vmstate: implement VMState for scalar types
>   rust: vmstate: add public utility macros to implement VMState
>   rust: qemu_api: add vmstate_struct
>   rust: pl011: switch vmstate to new-style macros
>   rust: vmstate: remove translation of C vmstate macros
>   rust: vmstate: make order of parameters consistent in vmstate_clock
>   rust: prefer NonNull::new to assertions
>   rust: pl011: remove unnecessary "extern crate"
>   rust: pl011: hide unnecessarily "pub" items from outside pl011::device
>   rust: pl011: extract conversion to RegisterOffset
>   rust: pl011: extract CharBackend receive logic into a separate function
>   rust: pl011: pull interrupt updates out of read/write ops
>   rust: pl011: extract PL011Registers
>   rust: pl011: wrap registers with BqlRefCell
>   rust: pl011: remove duplicate definitions
>   rust: pl011: pull device-specific code out of MemoryRegionOps callbacks
>   rust: pl011: drop use of ControlFlow
>   rust: qdev: make reset take a shared reference
>
> Tao Su (4):
>   target/i386: Introduce SierraForest-v2 model
>   target/i386: Export BHI_NO bit to guests
>   target/i386: Add new CPU model ClearwaterForest
>   docs: Add GNR, SRF and CWF CPU models
>
> Zhao Liu (7):
>   stub: Fix build failure with --enable-user --disable-system 
> --enable-tools
>   rust/qdev: Make REALIZE safe
>   rust/pl011: Avoid bindings::*
>   memattrs: Convert unspecified member to bool
>   memattrs: Check the size of MemTxAttrs
>   rust/zeroable: Implement Zeroable with const_zero macro
>   rust: qemu-api: add sub-subclass to the integration tests
>
>  docs/system/cpu-models-x86.rst.inc |  50 ++-
>  include/exec/memattrs.h|  21 +-
>  target/i386/cpu.h  |  33 +-
>  target/i386/cpu.c  | 156 +++-
>  target/i386/tcg/translate.c| 363 ++---
>  target/i386/tcg/emit.c.inc |  55 +--
>  rust/hw/char/pl011/src/device.rs   | 509 +---
>  rust/hw/char/pl011/src/device_class.rs |  73 ++--
> 

Re: [PATCH 0/7] tests/qtest/migration: Update framework to allow using HVF accelerator

2025-01-28 Thread Philippe Mathieu-Daudé

On 28/1/25 14:54, Philippe Mathieu-Daudé wrote:

Hi,

This series modify few bits of the migration QTest framework
to allow running the tests using the HVF framework (also
leaving the possibilty for other ones, removing the KVM/TCG
restriction).


Forgot to mention:
Based-on: <20250128111821.93767-1-phi...@linaro.org>
  "tests/qtest: Make qtest_has_accel() generic"


Philippe Mathieu-Daudé (7):
   migration/dirtyrate: Do not unlock cpu_list lock twice
   tests/qtest/migration: Make 'has_dirty_ring' generic
   tests/qtest/migration: Initialize MigrationTestEnv::arch early
   tests/qtest/migration: Pass accelerator arguments as machine option
   tests/qtest/migration: Add MigrationTestEnv::has_hvf field
   tests/qtest/migration: Run aarch64/HVF tests using GICv2
   tests/qtest/migration: Allow using accelerators different of TCG / KVM





[PATCH 4/7] tests/qtest/migration: Pass accelerator arguments as machine option

2025-01-28 Thread Philippe Mathieu-Daudé
The '-accel' CLI option is handler as sugar property as
'-machine,accel='. Replace the migration tests command
line, only using the best accelerator available (first
hardware, then software).

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/qtest/migration/framework.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/tests/qtest/migration/framework.c 
b/tests/qtest/migration/framework.c
index 38a0a1a5264..e567296b014 100644
--- a/tests/qtest/migration/framework.c
+++ b/tests/qtest/migration/framework.c
@@ -214,8 +214,9 @@ int migrate_start(QTestState **from, QTestState **to, const 
char *uri,
 const gchar *ignore_stderr;
 g_autofree char *shmem_opts = NULL;
 g_autofree char *shmem_path = NULL;
-const char *kvm_opts = NULL;
-const char *arch = qtest_get_arch();
+const char *accel_args = NULL;
+const MigrationTestEnv *env = migration_get_env();
+const char *arch = env->arch;
 const char *memory_size;
 const char *machine_alias, *machine_opts = "";
 g_autofree char *machine = NULL;
@@ -296,8 +297,15 @@ int migrate_start(QTestState **from, QTestState **to, 
const char *uri,
 memory_size, shmem_path);
 }
 
-if (args->use_dirty_ring) {
-kvm_opts = ",dirty-ring-size=4096";
+if (env->has_kvm) {
+if (args->use_dirty_ring) {
+accel_args = "kvm,dirty-ring-size=4096";
+} else {
+accel_args = "kvm";
+}
+} else {
+assert(env->has_tcg);
+accel_args = "tcg";
 }
 
 if (!qtest_has_machine(machine_alias)) {
@@ -311,14 +319,12 @@ int migrate_start(QTestState **from, QTestState **to, 
const char *uri,
 
 g_test_message("Using machine type: %s", machine);
 
-cmd_source = g_strdup_printf("-accel kvm%s -accel tcg "
- "-machine %s,%s "
+cmd_source = g_strdup_printf("-machine %s,%s,accel=%s "
  "-name source,debug-threads=on "
  "-m %s "
  "-serial file:%s/src_serial "
  "%s %s %s %s",
- kvm_opts ? kvm_opts : "",
- machine, machine_opts,
+ machine, machine_opts, accel_args,
  memory_size, tmpfs,
  arch_opts ? arch_opts : "",
  shmem_opts ? shmem_opts : "",
@@ -332,15 +338,13 @@ int migrate_start(QTestState **from, QTestState **to, 
const char *uri,
  &src_state);
 }
 
-cmd_target = g_strdup_printf("-accel kvm%s -accel tcg "
- "-machine %s,%s "
+cmd_target = g_strdup_printf("-machine %s,%s,accel=%s "
  "-name target,debug-threads=on "
  "-m %s "
  "-serial file:%s/dest_serial "
  "-incoming %s "
  "%s %s %s %s",
- kvm_opts ? kvm_opts : "",
- machine, machine_opts,
+ machine, machine_opts, accel_args,
  memory_size, tmpfs, uri,
  arch_opts ? arch_opts : "",
  shmem_opts ? shmem_opts : "",
-- 
2.47.1




[PATCH 1/7] migration/dirtyrate: Do not unlock cpu_list lock twice

2025-01-28 Thread Philippe Mathieu-Daudé
&qemu_cpu_list_lock is locked within the WITH_QEMU_LOCK_GUARD()
context, then unlocked. No need to manually unlock it.

Fixes: 370ed600296 ("cpu: expose qemu_cpu_list_lock for lock-guard use")
Signed-off-by: Philippe Mathieu-Daudé 
---
 migration/dirtyrate.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/migration/dirtyrate.c b/migration/dirtyrate.c
index 7c955894e47..4b94dd7c500 100644
--- a/migration/dirtyrate.c
+++ b/migration/dirtyrate.c
@@ -174,7 +174,6 @@ retry:
 if (gen_id != cpu_list_generation_id_get()) {
 g_free(records);
 g_free(stat->rates);
-cpu_list_unlock();
 goto retry;
 }
 vcpu_dirty_stat_collect(records, false);
-- 
2.47.1




[PATCH 2/7] tests/qtest/migration: Make 'has_dirty_ring' generic

2025-01-28 Thread Philippe Mathieu-Daudé
Keep accelerator knowledge limited within MigrationTestEnv,
expose a generic %has_dirty_ring value, only checking for
KVM when initializing it in migration_get_env().

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/qtest/migration/framework.c | 2 +-
 tests/qtest/migration/precopy-tests.c | 6 ++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/tests/qtest/migration/framework.c 
b/tests/qtest/migration/framework.c
index 4550cda129c..a3bd92a9519 100644
--- a/tests/qtest/migration/framework.c
+++ b/tests/qtest/migration/framework.c
@@ -946,7 +946,7 @@ MigrationTestEnv *migration_get_env(void)
 return env;
 }
 
-env->has_dirty_ring = kvm_dirty_ring_supported();
+env->has_dirty_ring = env->has_kvm && kvm_dirty_ring_supported();
 env->has_uffd = ufd_version_check(&env->uffd_feature_thread_id);
 env->arch = qtest_get_arch();
 env->is_x86 = !strcmp(env->arch, "i386") || !strcmp(env->arch, "x86_64");
diff --git a/tests/qtest/migration/precopy-tests.c 
b/tests/qtest/migration/precopy-tests.c
index 23599b29ee2..8dcd0ad2660 100644
--- a/tests/qtest/migration/precopy-tests.c
+++ b/tests/qtest/migration/precopy-tests.c
@@ -983,8 +983,7 @@ void migration_test_add_precopy(MigrationTestEnv *env)
 if (g_test_slow()) {
 migration_test_add("/migration/auto_converge",
test_auto_converge);
-if (g_str_equal(env->arch, "x86_64") &&
-env->has_kvm && env->has_dirty_ring) {
+if (g_str_equal(env->arch, "x86_64") && env->has_dirty_ring) {
 migration_test_add("/dirty_limit",
test_dirty_limit);
 }
@@ -999,8 +998,7 @@ void migration_test_add_precopy(MigrationTestEnv *env)
test_multifd_tcp_no_zero_page);
 migration_test_add("/migration/multifd/tcp/plain/cancel",
test_multifd_tcp_cancel);
-if (g_str_equal(env->arch, "x86_64")
-&& env->has_kvm && env->has_dirty_ring) {
+if (g_str_equal(env->arch, "x86_64") && env->has_dirty_ring) {
 
 migration_test_add("/migration/dirty_ring",
test_precopy_unix_dirty_ring);
-- 
2.47.1




[PATCH 3/7] tests/qtest/migration: Initialize MigrationTestEnv::arch early

2025-01-28 Thread Philippe Mathieu-Daudé
Some tests expect MigrationTestEnv::arch to be set. Initialize
it early enough to avoid SIGSEGV, for example like the following
g_str_equal() call in migration/precopy-tests.c:

   954 void migration_test_add_precopy(MigrationTestEnv *env)
   955 {
   ...
  1001 if (g_str_equal(env->arch, "x86_64") && env->has_dirty_ring) {
  1002
  1003 migration_test_add("/migration/dirty_ring",
  1004test_precopy_unix_dirty_ring);

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

diff --git a/tests/qtest/migration/framework.c 
b/tests/qtest/migration/framework.c
index a3bd92a9519..38a0a1a5264 100644
--- a/tests/qtest/migration/framework.c
+++ b/tests/qtest/migration/framework.c
@@ -938,6 +938,8 @@ MigrationTestEnv *migration_get_env(void)
 exit(1);
 }
 
+env->arch = qtest_get_arch();
+
 env->has_kvm = qtest_has_accel("kvm");
 env->has_tcg = qtest_has_accel("tcg");
 
@@ -948,7 +950,6 @@ MigrationTestEnv *migration_get_env(void)
 
 env->has_dirty_ring = env->has_kvm && kvm_dirty_ring_supported();
 env->has_uffd = ufd_version_check(&env->uffd_feature_thread_id);
-env->arch = qtest_get_arch();
 env->is_x86 = !strcmp(env->arch, "i386") || !strcmp(env->arch, "x86_64");
 
 env->tmpfs = g_dir_make_tmp("migration-test-XX", &err);
-- 
2.47.1




[PATCH 7/7] tests/qtest/migration: Allow using accelerators different of TCG / KVM

2025-01-28 Thread Philippe Mathieu-Daudé
There is no particular reason to restrict all the framework
to TCG or KVM, since we can check on a per-test basis which
accelerator is available (via MigrationTestEnv::has_$ACCEL).

Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/qtest/migration/framework.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/tests/qtest/migration/framework.c 
b/tests/qtest/migration/framework.c
index 30808de14e0..e5f0712c266 100644
--- a/tests/qtest/migration/framework.c
+++ b/tests/qtest/migration/framework.c
@@ -950,11 +950,6 @@ MigrationTestEnv *migration_get_env(void)
 env->has_hvf = qtest_has_accel("hvf");
 env->has_tcg = qtest_has_accel("tcg");
 
-if (!env->has_tcg && !env->has_kvm) {
-g_test_skip("No KVM or TCG accelerator available");
-return env;
-}
-
 env->has_dirty_ring = env->has_kvm && kvm_dirty_ring_supported();
 env->has_uffd = ufd_version_check(&env->uffd_feature_thread_id);
 env->is_x86 = !strcmp(env->arch, "i386") || !strcmp(env->arch, "x86_64");
-- 
2.47.1




[PATCH 0/7] tests/qtest/migration: Update framework to allow using HVF accelerator

2025-01-28 Thread Philippe Mathieu-Daudé
Hi,

This series modify few bits of the migration QTest framework
to allow running the tests using the HVF framework (also
leaving the possibilty for other ones, removing the KVM/TCG
restriction).

Philippe Mathieu-Daudé (7):
  migration/dirtyrate: Do not unlock cpu_list lock twice
  tests/qtest/migration: Make 'has_dirty_ring' generic
  tests/qtest/migration: Initialize MigrationTestEnv::arch early
  tests/qtest/migration: Pass accelerator arguments as machine option
  tests/qtest/migration: Add MigrationTestEnv::has_hvf field
  tests/qtest/migration: Run aarch64/HVF tests using GICv2
  tests/qtest/migration: Allow using accelerators different of TCG / KVM

 tests/qtest/migration/framework.h |  1 +
 migration/dirtyrate.c |  1 -
 tests/qtest/migration/framework.c | 43 ++-
 tests/qtest/migration/precopy-tests.c |  6 ++--
 4 files changed, 26 insertions(+), 25 deletions(-)

-- 
2.47.1




Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE

2025-01-28 Thread Philippe Mathieu-Daudé

On 28/1/25 13:57, BALATON Zoltan wrote:

On Tue, 28 Jan 2025, Peter Maydell wrote:

On Tue, 28 Jan 2025 at 10:42, Gerd Hoffmann  wrote:


On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote:

Some SysBus devices can optionally be dynamically plugged onto
the sysbus-platform-bus (then virtual guests are aware of
mmio mapping and IRQs via device tree / ACPI rules).


Do we have some sane way to have user-pluggable sysbus devices on arm?


The answer in a general sense is "no, because user pluggable
sysbus is a weird idea". "sysbus" means "it's wired into a
specific bit of the memory map and to specific IRQs, and whoever
does that needs to know what IRQs and bits of memory are usable,
and the guest OS needs to know it's there". "user-pluggable" means
"it's all automatic and the guest can just do some kind of
probing for what is or isn't present". All the platform bus stuff
is a nasty mess that's working around the things people want
to plug in not being clean devices on probeable buses :-(
And the platform bus is only supported on the "virt" board,
because that's the only one where QEMU is generating its
own dtb or ACPI tables where it can tell the guest "hey,
there's some device here".


There are some SoCs that have memory mapped devices but different 
versions in the same family have different devices. Either older ones 
missing some devices or have less USB or network ports while newer SoCs 
have more of those or they have PCIe instead of PCI. Modelling these 
could use pluggable sysbus devices so one could add the devices needed 
for a SoC version without having to write or modify a board code. I 
think Bernhard's attempt to try creating e500 SoCs from a device tree 
goes in that direction too. We could also model this by having a SoC 
that can instantiate devices based on some properties but maybe 
pluggable devices could be more generic for this. The issue seems to be 
how to tell the board or SoC where to map it and what IRQ to connect it 
as this is done by the board and not the device so properties on the 
device to set these does not really help unless the board can somehow 
query it and instantiate the devices based on that. Otherwise whatever 
handles the -device option to create the device would need knowledge 
about the board. (E.g. the e500 devices are mapped in the CCSR memory 
region so one can't just use system address space for them.)


IIRC Bernard's series takes a DTB as input and create the machine
matching this DTB.

As Peter explained, sysbus-platform-bus fits TYPE_DYNAMIC_SYS_BUS_DEVICE
in free slots, then generates the corresponding ACPI/DTB.

What you describe seems closer to the QEMU Dynamic Machine project,
following Damien's idea:
https://lore.kernel.org/qemu-devel/20220223090706.4888-1-damien.he...@greensocs.com/
We are not quite there yet...



[PATCH] MAINTAINERS: Add myself as HPPA maintainer

2025-01-28 Thread deller
From: Helge Deller 

Since I contribute quite some code to hppa, I'd like to step up and
become the secondary maintainer for HPPA beside Richard.
Additionally change status of hppa machines to maintained as I will
take care of them.

Signed-off-by: Helge Deller 
---
 MAINTAINERS | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index c5e2d6b636..62b851f766 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -251,6 +251,7 @@ F: target/hexagon/gen_idef_parser_funcs.py
 
 HPPA (PA-RISC) TCG CPUs
 M: Richard Henderson 
+M: Helge Deller 
 S: Maintained
 F: target/hppa/
 F: disas/hppa.c
@@ -1188,8 +1189,8 @@ HP-PARISC Machines
 --
 HP B160L, HP C3700
 M: Richard Henderson 
-R: Helge Deller 
-S: Odd Fixes
+M: Helge Deller 
+S: Maintained
 F: configs/devices/hppa-softmmu/default.mak
 F: hw/char/diva-gsp.c
 F: hw/display/artist.c
-- 
2.47.0




Re: [PATCH 01/11] hw/sd/omap_mmc: Do a minimal conversion to QDev

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

+static const TypeInfo omap_mmc_info = {
+.name = TYPE_OMAP_MMC,
+.parent = TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(OMAPMMCState),
+.instance_init = omap_mmc_initfn,
+.class_init = omap_mmc_class_init,
+};
+
+static void omap_mmc_register_types(void)
+{
+type_register_static(&omap_mmc_info);
+}
+
+type_init(omap_mmc_register_types)


Phil seems to be moving everything to DEFINE_TYPES now.

Otherwise,
Reviewed-by: Richard Henderson 


r~



[PATCH v2 1/2] virtio-mem-pci: Allow setting nvectors, so we can use MSI-X

2025-01-28 Thread David Hildenbrand
Let's do it similar as virtio-balloon-pci. With this change, we can
use virtio-mem-pci on s390x, although plugging will still fail until
properly wired up in the machine.

No need to worry about transitional/non_transitional devices, because they
don't exist for virtio-mem.

Signed-off-by: David Hildenbrand 
---
 hw/core/machine.c  |  1 +
 hw/virtio/virtio-mem-pci.c | 12 
 2 files changed, 13 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 8f396ef803..7b74cde10a 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -41,6 +41,7 @@ GlobalProperty hw_compat_9_2[] = {
 { "virtio-balloon-pci", "vectors", "0" },
 { "virtio-balloon-pci-transitional", "vectors", "0" },
 { "virtio-balloon-pci-non-transitional", "vectors", "0" },
+{ "virtio-mem-pci", "vectors", "0" },
 };
 const size_t hw_compat_9_2_len = G_N_ELEMENTS(hw_compat_9_2);
 
diff --git a/hw/virtio/virtio-mem-pci.c b/hw/virtio/virtio-mem-pci.c
index 1b4e9a3284..6cc5f0fd3b 100644
--- a/hw/virtio/virtio-mem-pci.c
+++ b/hw/virtio/virtio-mem-pci.c
@@ -22,6 +22,10 @@ static void virtio_mem_pci_realize(VirtIOPCIProxy *vpci_dev, 
Error **errp)
 VirtIOMEMPCI *mem_pci = VIRTIO_MEM_PCI(vpci_dev);
 DeviceState *vdev = DEVICE(&mem_pci->vdev);
 
+if (vpci_dev->nvectors == DEV_NVECTORS_UNSPECIFIED) {
+vpci_dev->nvectors = 2;
+}
+
 virtio_pci_force_virtio_1(vpci_dev);
 qdev_realize(vdev, BUS(&vpci_dev->bus), errp);
 }
@@ -152,6 +156,13 @@ static void virtio_mem_pci_set_requested_size(Object *obj, 
Visitor *v,
 object_property_set(OBJECT(&pci_mem->vdev), name, v, errp);
 }
 
+static const Property virtio_mem_pci_class_properties[] = {
+DEFINE_PROP_BIT("ioeventfd", VirtIOPCIProxy, flags,
+VIRTIO_PCI_FLAG_USE_IOEVENTFD_BIT, true),
+DEFINE_PROP_UINT32("vectors", VirtIOPCIProxy, nvectors,
+   DEV_NVECTORS_UNSPECIFIED),
+};
+
 static void virtio_mem_pci_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -164,6 +175,7 @@ static void virtio_mem_pci_class_init(ObjectClass *klass, 
void *data)
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
 pcidev_k->revision = VIRTIO_PCI_ABI_VERSION;
 pcidev_k->class_id = PCI_CLASS_OTHERS;
+device_class_set_props(dc, virtio_mem_pci_class_properties);
 
 mdc->get_addr = virtio_mem_pci_get_addr;
 mdc->set_addr = virtio_mem_pci_set_addr;
-- 
2.48.1




[PATCH v2 2/2] s390x/s390-virtio-ccw: Support plugging PCI-based virtio memory devices

2025-01-28 Thread David Hildenbrand
Let's just wire it up, unlocking virtio-mem-pci support on s390x.

While at it, drop the "return;" in s390_machine_device_unplug_request(),
to make it look like the other handlers.

Reviewed-by: Thomas Huth 
Signed-off-by: David Hildenbrand 
---
 hw/s390x/s390-virtio-ccw.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 3af613d4e9..71f3443a53 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -554,8 +554,7 @@ static void s390_machine_device_pre_plug(HotplugHandler 
*hotplug_dev,
 if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) {
 virtio_ccw_md_pre_plug(VIRTIO_MD_CCW(dev), MACHINE(hotplug_dev), errp);
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_PCI)) {
-error_setg(errp,
-   "PCI-attached virtio based memory devices not supported");
+virtio_md_pci_pre_plug(VIRTIO_MD_PCI(dev), MACHINE(hotplug_dev), errp);
 }
 }
 
@@ -566,7 +565,8 @@ static void s390_machine_device_plug(HotplugHandler 
*hotplug_dev,
 
 if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 s390_cpu_plug(hotplug_dev, dev, errp);
-} else if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) {
+} else if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW) ||
+   object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_PCI)) {
 /*
  * At this point, the device is realized and set all memdevs mapped, so
  * qemu_maxrampagesize() will pick up the page sizes of these memdevs
@@ -580,7 +580,11 @@ static void s390_machine_device_plug(HotplugHandler 
*hotplug_dev,
" initial memory");
 return;
 }
-virtio_ccw_md_plug(VIRTIO_MD_CCW(dev), MACHINE(hotplug_dev), errp);
+if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) {
+virtio_ccw_md_plug(VIRTIO_MD_CCW(dev), MACHINE(hotplug_dev), errp);
+} else {
+virtio_md_pci_plug(VIRTIO_MD_PCI(dev), MACHINE(hotplug_dev), errp);
+}
 }
 }
 
@@ -589,10 +593,12 @@ static void 
s390_machine_device_unplug_request(HotplugHandler *hotplug_dev,
 {
 if (object_dynamic_cast(OBJECT(dev), TYPE_CPU)) {
 error_setg(errp, "CPU hot unplug not supported on this machine");
-return;
 } else if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) {
 virtio_ccw_md_unplug_request(VIRTIO_MD_CCW(dev), MACHINE(hotplug_dev),
  errp);
+} else if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_PCI)) {
+virtio_md_pci_unplug_request(VIRTIO_MD_PCI(dev), MACHINE(hotplug_dev),
+ errp);
 }
 }
 
@@ -601,7 +607,9 @@ static void s390_machine_device_unplug(HotplugHandler 
*hotplug_dev,
 {
 if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_CCW)) {
 virtio_ccw_md_unplug(VIRTIO_MD_CCW(dev), MACHINE(hotplug_dev), errp);
- }
+} else if (object_dynamic_cast(OBJECT(dev), TYPE_VIRTIO_MD_PCI)) {
+virtio_md_pci_unplug(VIRTIO_MD_PCI(dev), MACHINE(hotplug_dev), errp);
+}
  }
 
 static CpuInstanceProperties s390_cpu_index_to_props(MachineState *ms,
-- 
2.48.1




[PATCH v2 0/2] s390x: support virtio-mem-pci

2025-01-28 Thread David Hildenbrand
This is based-on [1], which adds MSI-X support to virtio-balloon-pci,
but can be applied independently.

Turns out it is fairly easy to get virtio-mem-pci running on s390x. We
only have to add MSI-X support to virtio-mem-pci, and wire-up the
(un)plugging in the machine.

Tried some simple stuff (hotplug/hotunplug/resize/reboot), and all seems
to be working as expected.

The kernel in the VM needs both, CONFIG_VIRTIO_PCI and CONFIG_VIRTIO_MEM
for it to work.

[1] https://lkml.kernel.org/r/20250115161425.246348-1-ar...@linux.ibm.com

v1 -> v2:
* There are no transitional/non_transitional devices for virtio-mem
* Spell out removal of "return;" in second patch

Cc: Eduardo Habkost 
Cc: Marcel Apfelbaum 
Cc: Richard Henderson 
Cc: David Hildenbrand 
Cc: Ilya Leoshkevich 
Cc: Halil Pasic 
Cc: Christian Borntraeger 
Cc: Eric Farman 
Cc: Thomas Huth 
Cc: "Michael S. Tsirkin" 
Cc: Cornelia Huck 
Cc: Boris Fiuczynski 
Cc: Michal Privoznik 
Cc: Mario Casquero 

David Hildenbrand (2):
  virtio-mem-pci: Allow setting nvectors, so we can use MSI-X
  s390x/s390-virtio-ccw: Support plugging PCI-based virtio memory
devices

 hw/core/machine.c  |  1 +
 hw/s390x/s390-virtio-ccw.c | 20 ++--
 hw/virtio/virtio-mem-pci.c | 12 
 3 files changed, 27 insertions(+), 6 deletions(-)

-- 
2.48.1




Re: [PATCH 02/11] hw/sd/omap_mmc: Convert remaining 'struct omap_mmc_s' uses to OMAPMMCState

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

Mechanically convert the remaining uses of 'struct omap_mmc_s' to
'OMAPMMCState'.

Signed-off-by: Peter Maydell
---
  include/hw/arm/omap.h |  2 +-
  hw/sd/omap_mmc.c  | 20 ++--
  2 files changed, 11 insertions(+), 11 deletions(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 03/11] hw/sd/omap_mmc: Convert output qemu_irqs to gpio and sysbus IRQ APIs

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

The omap_mmc device has three outbound qemu_irq lines:
  * one actual interrupt line
  * two which connect to the DMA controller and are signalled for
TX and RX DMA

Convert these to a sysbus IRQ and two named GPIO outputs.

Signed-off-by: Peter Maydell
---
  hw/sd/omap_mmc.c | 20 +---
  1 file changed, 13 insertions(+), 7 deletions(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 3/5] target/hppa: Implement CPU diagnose registers for 64-bit HP-UX

2025-01-28 Thread Richard Henderson

On 1/28/25 08:14, del...@kernel.org wrote:

From: Helge Deller 

PA-RISC CPUs have diagnose registers (%dr). Those are mostly
undocumented and control cache behaviour, memory behaviour, reset button
management and many other related internal CPU things.

The Linux kernel turns space-register hashing off unconditionally at
bootup.  That code was provided by HP at the beginning of the PA-RISC
Linux porting effort, and I don't know why it was decided then why Linux
should not use space register hashing.
32-bit HP-UX versions seem to not use space register hashing either.
But for 64-bit HP-UX versions, Sven Schnelle noticed that space register
hashing needs to be enabled and is required, otherwise the HP-UX kernel
will crash badly.

On 64-bit CPUs space register hashing is controlled by a bit in diagnose
register %dr2.  Since we want to support Linux and 32- and 64-bit HP-UX,
we need to fully emulate the diagnose registers and handle specifically
the content of %dr2.

Furthermore it turned out that commit 3bdf20819e68 seems wrong and
conflicts with the general space register diagnose register, so it is
partly reverted here.

Signed-off-by: Helge Deller 
Suggested-by: Sven Schnelle 
Fixes: 3bdf20819e68 ("target/hppa: Add diag instructions to set/restore shadow 
registers")
---
  hw/hppa/machine.c|  5 +
  target/hppa/cpu.c|  3 ++-
  target/hppa/cpu.h| 24 
  target/hppa/helper.c |  4 ++--
  target/hppa/insns.decode |  6 --
  target/hppa/int_helper.c |  6 +++---
  target/hppa/machine.c|  5 +++--
  target/hppa/sys_helper.c |  2 +-
  target/hppa/translate.c  | 24 +---
  9 files changed, 53 insertions(+), 26 deletions(-)


This does too much at once.

Adding the dr registers should be separate from any of the space hashing.  Translator 
changes can be separate from everything else.  Etc.



diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 0dd1908214..d5de793b62 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -662,6 +662,11 @@ static void hppa_machine_reset(MachineState *ms, ResetType 
type)
  cpu_set_pc(cs, firmware_entry);
  cpu[i]->env.psw = PSW_Q;
  cpu[i]->env.gr[5] = CPU_HPA + i * 0x1000;
+
+/* 64-bit machines start with space-register hashing enabled in %dr2 */
+if (hppa_is_pa20(&cpu[0]->env)) {
+cpu[i]->env.dr[2] = HPPA64_DIAG_SPHASH_ENABLE; /* (bit 54) */
+}
  }


Why in hw/?  I would expect this in hppa_cpu_reset_hold.


diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index beea42d105..64e60a3980 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -25,6 +25,7 @@
  #include "qemu/cpu-float.h"
  #include "qemu/interval-tree.h"
  #include "hw/registerfields.h"
+#include "hw/hppa/hppa_hardware.h"


Ideally this would never be in cpu.h.


@@ -319,27 +321,33 @@ void hppa_translate_code(CPUState *cs, TranslationBlock 
*tb,
  
  #define CPU_RESOLVING_TYPE TYPE_HPPA_CPU
  
-static inline uint64_t gva_offset_mask(target_ulong psw)

+static inline uint64_t gva_offset_mask(CPUHPPAState *env, target_ulong psw)
  {
-return (psw & PSW_W
-? MAKE_64BIT_MASK(0, 62)
-: MAKE_64BIT_MASK(0, 32));
+if (psw & PSW_W) {
+return (env->dr[2] & HPPA64_DIAG_SPHASH_ENABLE)
+? MAKE_64BIT_MASK(0, 62) &
+~((uint64_t)HPPA64_PDC_CACHE_RET_SPID_VAL << 48)
+: MAKE_64BIT_MASK(0, 62);
+} else {
+return MAKE_64BIT_MASK(0, 32);
+}
  }


This is getting pretty complicated now.  I think perhaps we should cache the mask based on 
current cpu state (updated with writes to psw or dr2).


This would also move the HPPA64_DIAG_SPHASH_ENABLE reference out of cpu.h.

  
-static inline target_ulong hppa_form_gva_psw(target_ulong psw, uint64_t spc,

- target_ulong off)
+static inline target_ulong hppa_form_gva_psw(CPUHPPAState *env,
+ target_ulong psw,
+ uint64_t spc, target_ulong off)


Which means this would take the cached mask as argument, not env + psw.
Might rename as hppa_form_gva_mask() at the same time to emphasize the
change in arguments.


diff --git a/target/hppa/insns.decode b/target/hppa/insns.decode
index 71074a64c1..4eaac750ea 100644
--- a/target/hppa/insns.decode
+++ b/target/hppa/insns.decode
@@ -644,10 +644,12 @@ xmpyu   001110 . . 010 .0111 .00 t:5
r1=%ra64 r2=%rb64
  # For 32-bit PA-7300LC (PCX-L2)
  diag_getshadowregs_pa1  000101 00   0001 1010  
  diag_putshadowregs_pa1  000101 00   0001 1010 0100 
+diag_mfdiag 000101 dr:5  rt:5    0110  
+diag_mtdiag 000101 dr:5  r1:5   0001 0110  
  
  # For 64-bit PA8700 (PCX-W2)

-diag_getshadowregs_pa2  000101 00 0111 1000 0001 1000 0100 
-diag_putshadowregs_pa2  000101 00 0111 

Re: [PATCH 2/2] plugin: extend API with qemu_plugin_tb_size

2025-01-28 Thread Pierrick Bouvier

Hi Luke,

On 1/27/25 12:17, Luke Craig wrote:

---
  include/qemu/qemu-plugin.h | 10 ++
  plugins/api.c  |  5 +
  2 files changed, 15 insertions(+)

diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
index a1c478c54f..1fa656da82 100644
--- a/include/qemu/qemu-plugin.h
+++ b/include/qemu/qemu-plugin.h
@@ -476,6 +476,16 @@ void qemu_plugin_register_vcpu_insn_exec_inline_per_vcpu(
  QEMU_PLUGIN_API
  size_t qemu_plugin_tb_n_insns(const struct qemu_plugin_tb *tb);
  
+/**

+ * qemu_plugin_tb_size() - query helper for size of TB
+ * @tb: opaque handle to TB passed to callback
+ *
+ * Returns: size of block in bytes
+ */
+
+QEMU_PLUGIN_API
+size_t qemu_plugin_tb_size(const struct qemu_plugin_tb *tb);
+
  /**
   * qemu_plugin_tb_vaddr() - query helper for vaddr of TB start
   * @tb: opaque handle to TB passed to callback
diff --git a/plugins/api.c b/plugins/api.c
index 7ff5e1c1bd..177f0ac9b6 100644
--- a/plugins/api.c
+++ b/plugins/api.c
@@ -241,6 +241,11 @@ size_t qemu_plugin_tb_n_insns(const struct qemu_plugin_tb 
*tb)
  return tb->n;
  }
  
+size_t qemu_plugin_tb_size(const struct qemu_plugin_tb *tb){

+const DisasContextBase *db = tcg_ctx->plugin_db;
+return db->size;
+}
+
  uint64_t qemu_plugin_tb_vaddr(const struct qemu_plugin_tb *tb)
  {
  const DisasContextBase *db = tcg_ctx->plugin_db;


by tb size, do you mean the size, in bytes, of all (original) 
instructions of the tb?


If yes, you can get it by fetching first and last instruction, and 
compute the difference between last->vaddr + last->len -  first->vaddr.


Regards,
Pierrick



Re: [PATCH 07/11] hw/sd/omap_mmc: Remove unused coverswitch qemu_irq

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

The coverswitch qemu_irq is never connected to anything, and the only thing
we do with it is set it in omap_mmc_reset(). Remove it.

Signed-off-by: Peter Maydell 
---
  hw/sd/omap_mmc.c | 2 --
  1 file changed, 2 deletions(-)


Reviewed-by: Richard Henderson 


r~




Re: [PATCH 06/11] hw/arm/omap1: Inline creation of MMC

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

Our style for other conversions of OMAP devices to qdev has been to
inline the creation and wiring into omap310_mpu_init() -- see for
instance the handling of omap-intc, omap-gpio and omap_i2c. Do
the same for omap-mmc.

Signed-off-by: Peter Maydell
---
  hw/arm/omap1.c   | 15 +++
  hw/sd/omap_mmc.c | 22 --
  2 files changed, 11 insertions(+), 26 deletions(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 08/11] hw/sd/omap_mmc: Untabify

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

This is a very old source file, and still has some lingering
hard-coded tabs; untabify it.

Signed-off-by: Peter Maydell
---
I don't propose to try to bring the whole file up to modern
coding style, but hard-coded tabs are a particular wart.
---
  hw/sd/omap_mmc.c | 124 +++
  1 file changed, 62 insertions(+), 62 deletions(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 10/11] hw/sd: Remove unused legacy functions, stop killing mammoths

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

The sdcard_legacy.h header defines function prototypes for the "legacy"
SD card API, which was used by non-qdevified SD controller models.
We've now converted the only remaining non-qdev SD controller, so
we can drop the legacy API.

Entirely unused functions:
   sd_init(), sd_set_cb(), sd_enable()

Functions which now become static inside sd.c (they are the
underlying implementations of methods on SDCardClass):
   sd_do_command(), sd_write_byte(), sd_read_byte()

Removal of sd_init() means that we can also remove the
me_no_qdev_me_kill_mammoth_with_rocks flag, the codepaths that were
only reachable when it was set, and the inserted_cb and readonly_cb
qemu_irq lines that went with that.

Signed-off-by: Peter Maydell
---
  include/hw/sd/sdcard_legacy.h | 50 ---
  hw/sd/omap_mmc.c  |  2 +-
  hw/sd/sd.c| 77 ---
  3 files changed, 9 insertions(+), 120 deletions(-)
  delete mode 100644 include/hw/sd/sdcard_legacy.h


Reviewed-by: Richard Henderson 

r~



Re: [PATCH] tests/functional: Add a ppc64 mac99 test

2025-01-28 Thread Thomas Huth

On 28/01/2025 19.35, Cédric Le Goater wrote:

On 1/28/25 19:20, Thomas Huth wrote:

On 28/01/2025 19.07, Cédric Le Goater wrote:

The test sequence boots from disk a mac99 machine in 64-bit mode, in
which case the CPU is a PPC 970.

The buildroot rootfs is built with config :

BR2_powerpc64=y
BR2_powerpc_970=y

and the kernel with the g5 deconfig.

Signed-off-by: Cédric Le Goater 
---
  MAINTAINERS  |  1 +
  tests/functional/meson.build |  2 ++
  tests/functional/test_ppc64_mac99.py | 45 
  3 files changed, 48 insertions(+)
  create mode 100644 tests/functional/test_ppc64_mac99.py

diff --git a/MAINTAINERS b/MAINTAINERS
index 3a2291d17d7e..ebf249173f00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1446,6 +1446,7 @@ F: include/hw/pci-host/uninorth.h
  F: include/hw/input/adb*
  F: pc-bios/qemu_vga.ndrv
  F: tests/functional/test_ppc_mac.py
+F: tests/functional/test_ppc64_mac99.py
  Old World (g3beige)
  M: Mark Cave-Ayland 
diff --git a/tests/functional/meson.build b/tests/functional/meson.build
index 01a87b03e553..821a0a7c49ac 100644
--- a/tests/functional/meson.build
+++ b/tests/functional/meson.build
@@ -41,6 +41,7 @@ test_timeouts = {
    'ppc64_powernv' : 480,
    'ppc64_pseries' : 480,
    'ppc64_tuxrun' : 420,
+  'ppc64_mac99' : 120,
    'riscv64_tuxrun' : 120,
    's390x_ccw_virtio' : 420,
    'sh4_tuxrun' : 240,
@@ -181,6 +182,7 @@ tests_ppc64_system_thorough = [
    'ppc64_powernv',
    'ppc64_pseries',
    'ppc64_tuxrun',
+  'ppc64_mac99',
  ]
  tests_riscv32_system_quick = [
diff --git a/tests/functional/test_ppc64_mac99.py b/tests/functional/ 
test_ppc64_mac99.py

new file mode 100644
index ..ba582d267dae
--- /dev/null
+++ b/tests/functional/test_ppc64_mac99.py
@@ -0,0 +1,45 @@
+#!/usr/bin/env python3
+#
+# Functional test that boots a mac99 machine with a PPC970 CPU
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+from qemu_test import LinuxKernelTest, Asset
+from qemu_test import exec_command_and_wait_for_pattern
+
+class mac99Test(LinuxKernelTest):
+
+    ASSET_BR2_MAC99_LINUX = Asset(
+    'https://github.com/legoater/qemu-ppc-boot/raw/refs/heads/main/ 
buildroot/qemu_ppc64_mac99-2023.11-8-gdcd9f0f6eb-20240105/vmlinux',

+    'd59307437e4365f2cced0bbd1b04949f7397b282ef349b7cafd894d74aadfbff')
+
+    ASSET_BR2_MAC99_ROOTFS = Asset(
+    'https://github.com/legoater/qemu-ppc-boot/raw/refs/heads/main// 
buildroot/qemu_ppc64_mac99-2023.11-8-gdcd9f0f6eb-20240105/rootfs.ext2',

+    'bbd5fd8af62f580bc4e585f326fe584e22856572633a8333178ea6d4ed4955a4')
+
+    def test_ppc64_mac99_buildroot(self):
+    self.require_netdev('user')
+
+    linux_path = self.ASSET_BR2_MAC99_LINUX.fetch()
+    rootfs_path = self.ASSET_BR2_MAC99_ROOTFS.fetch()
+
+    self.set_machine('mac99')


Nit: Move the set_machine to the top of the function, so that the assets 
don't have to be fetched in case the machine is not available.


With that nit fixed:
Reviewed-by: Thomas Huth 



+    self.vm.set_console()
+
+    self.vm.add_args('-kernel', linux_path,
+ '-append', 'root=/dev/sda',
+ '-drive', f'file={rootfs_path},format=raw',
+ '-net', 'nic,model=sungem', '-net', 'user',
+ '-snapshot', '-nographic')


I just also noticed that we already have "-display none" in python/qemu/ 
machine/machine.py, so you likely don't need the -nographic here (but 
looks like we've got that wrong in a bunch of tests already).


I think we need -nographic else OpenBIOS crashes.  I will check.


Oh, you're right, OpenBIOS hangs with "milliseconds isn't unique" when 
running "qemu-system-ppc64 -M mac99 -display none -serial stdio" ... that's 
weird... so you need to keep the -nographic here, indeed!


 Thomas




Re: [PATCH] tests/functional: Add a ppc64 mac99 test

2025-01-28 Thread Cédric Le Goater

On 1/28/25 19:20, Thomas Huth wrote:

On 28/01/2025 19.07, Cédric Le Goater wrote:

The test sequence boots from disk a mac99 machine in 64-bit mode, in
which case the CPU is a PPC 970.

The buildroot rootfs is built with config :

BR2_powerpc64=y
BR2_powerpc_970=y

and the kernel with the g5 deconfig.

Signed-off-by: Cédric Le Goater 
---
  MAINTAINERS  |  1 +
  tests/functional/meson.build |  2 ++
  tests/functional/test_ppc64_mac99.py | 45 
  3 files changed, 48 insertions(+)
  create mode 100644 tests/functional/test_ppc64_mac99.py

diff --git a/MAINTAINERS b/MAINTAINERS
index 3a2291d17d7e..ebf249173f00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1446,6 +1446,7 @@ F: include/hw/pci-host/uninorth.h
  F: include/hw/input/adb*
  F: pc-bios/qemu_vga.ndrv
  F: tests/functional/test_ppc_mac.py
+F: tests/functional/test_ppc64_mac99.py
  Old World (g3beige)
  M: Mark Cave-Ayland 
diff --git a/tests/functional/meson.build b/tests/functional/meson.build
index 01a87b03e553..821a0a7c49ac 100644
--- a/tests/functional/meson.build
+++ b/tests/functional/meson.build
@@ -41,6 +41,7 @@ test_timeouts = {
    'ppc64_powernv' : 480,
    'ppc64_pseries' : 480,
    'ppc64_tuxrun' : 420,
+  'ppc64_mac99' : 120,
    'riscv64_tuxrun' : 120,
    's390x_ccw_virtio' : 420,
    'sh4_tuxrun' : 240,
@@ -181,6 +182,7 @@ tests_ppc64_system_thorough = [
    'ppc64_powernv',
    'ppc64_pseries',
    'ppc64_tuxrun',
+  'ppc64_mac99',
  ]
  tests_riscv32_system_quick = [
diff --git a/tests/functional/test_ppc64_mac99.py 
b/tests/functional/test_ppc64_mac99.py
new file mode 100644
index ..ba582d267dae
--- /dev/null
+++ b/tests/functional/test_ppc64_mac99.py
@@ -0,0 +1,45 @@
+#!/usr/bin/env python3
+#
+# Functional test that boots a mac99 machine with a PPC970 CPU
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+from qemu_test import LinuxKernelTest, Asset
+from qemu_test import exec_command_and_wait_for_pattern
+
+class mac99Test(LinuxKernelTest):
+
+    ASSET_BR2_MAC99_LINUX = Asset(
+    
'https://github.com/legoater/qemu-ppc-boot/raw/refs/heads/main/buildroot/qemu_ppc64_mac99-2023.11-8-gdcd9f0f6eb-20240105/vmlinux',
+    'd59307437e4365f2cced0bbd1b04949f7397b282ef349b7cafd894d74aadfbff')
+
+    ASSET_BR2_MAC99_ROOTFS = Asset(
+    
'https://github.com/legoater/qemu-ppc-boot/raw/refs/heads/main//buildroot/qemu_ppc64_mac99-2023.11-8-gdcd9f0f6eb-20240105/rootfs.ext2',
+    'bbd5fd8af62f580bc4e585f326fe584e22856572633a8333178ea6d4ed4955a4')
+
+    def test_ppc64_mac99_buildroot(self):
+    self.require_netdev('user')
+
+    linux_path = self.ASSET_BR2_MAC99_LINUX.fetch()
+    rootfs_path = self.ASSET_BR2_MAC99_ROOTFS.fetch()
+
+    self.set_machine('mac99')


Nit: Move the set_machine to the top of the function, so that the assets don't 
have to be fetched in case the machine is not available.

With that nit fixed:
Reviewed-by: Thomas Huth 



+    self.vm.set_console()
+
+    self.vm.add_args('-kernel', linux_path,
+ '-append', 'root=/dev/sda',
+ '-drive', f'file={rootfs_path},format=raw',
+ '-net', 'nic,model=sungem', '-net', 'user',
+ '-snapshot', '-nographic')


I just also noticed that we already have "-display none" in 
python/qemu/machine/machine.py, so you likely don't need the -nographic here (but looks 
like we've got that wrong in a bunch of tests already).


I think we need -nographic else OpenBIOS crashes.  I will check.


Thanks,

C.







+    self.vm.launch()
+
+    self.wait_for_console_pattern('>> OpenBIOS')
+    self.wait_for_console_pattern('Linux version')
+    self.wait_for_console_pattern('/init as init process')
+    self.wait_for_console_pattern('gem :f0:0e.0 eth0: Link is up at 
100 Mbps')
+    self.wait_for_console_pattern('buildroot login:')
+    exec_command_and_wait_for_pattern(self, 'root', '#')
+    exec_command_and_wait_for_pattern(self, 'poweroff', 'Power down')
+
+if __name__ == '__main__':
+    LinuxKernelTest.main()







Re: [PATCH 3/5] target/hppa: Implement CPU diagnose registers for 64-bit HP-UX

2025-01-28 Thread Helge Deller

On 1/28/25 19:19, Richard Henderson wrote:

On 1/28/25 08:14, del...@kernel.org wrote:

From: Helge Deller 

PA-RISC CPUs have diagnose registers (%dr). Those are mostly
undocumented and control cache behaviour, memory behaviour, reset button
management and many other related internal CPU things.

The Linux kernel turns space-register hashing off unconditionally at
bootup.  That code was provided by HP at the beginning of the PA-RISC
Linux porting effort, and I don't know why it was decided then why Linux
should not use space register hashing.
32-bit HP-UX versions seem to not use space register hashing either.
But for 64-bit HP-UX versions, Sven Schnelle noticed that space register
hashing needs to be enabled and is required, otherwise the HP-UX kernel
will crash badly.

On 64-bit CPUs space register hashing is controlled by a bit in diagnose
register %dr2.  Since we want to support Linux and 32- and 64-bit HP-UX,
we need to fully emulate the diagnose registers and handle specifically
the content of %dr2.

Furthermore it turned out that commit 3bdf20819e68 seems wrong and
conflicts with the general space register diagnose register, so it is
partly reverted here.

Signed-off-by: Helge Deller 
Suggested-by: Sven Schnelle 
Fixes: 3bdf20819e68 ("target/hppa: Add diag instructions to set/restore shadow 
registers")
---
  hw/hppa/machine.c    |  5 +
  target/hppa/cpu.c    |  3 ++-
  target/hppa/cpu.h    | 24 
  target/hppa/helper.c |  4 ++--
  target/hppa/insns.decode |  6 --
  target/hppa/int_helper.c |  6 +++---
  target/hppa/machine.c    |  5 +++--
  target/hppa/sys_helper.c |  2 +-
  target/hppa/translate.c  | 24 +---
  9 files changed, 53 insertions(+), 26 deletions(-)


This does too much at once.

Adding the dr registers should be separate from any of the space hashing.  
Translator changes can be separate from everything else.  Etc.


Ok.



diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 0dd1908214..d5de793b62 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -662,6 +662,11 @@ static void hppa_machine_reset(MachineState *ms, ResetType 
type)
  cpu_set_pc(cs, firmware_entry);
  cpu[i]->env.psw = PSW_Q;
  cpu[i]->env.gr[5] = CPU_HPA + i * 0x1000;
+
+    /* 64-bit machines start with space-register hashing enabled in %dr2 */
+    if (hppa_is_pa20(&cpu[0]->env)) {
+    cpu[i]->env.dr[2] = HPPA64_DIAG_SPHASH_ENABLE; /* (bit 54) */
+    }
  }


Why in hw/?  I would expect this in hppa_cpu_reset_hold.


Ok.
 

diff --git a/target/hppa/cpu.h b/target/hppa/cpu.h
index beea42d105..64e60a3980 100644
--- a/target/hppa/cpu.h
+++ b/target/hppa/cpu.h
@@ -25,6 +25,7 @@
  #include "qemu/cpu-float.h"
  #include "qemu/interval-tree.h"
  #include "hw/registerfields.h"
+#include "hw/hppa/hppa_hardware.h"


Ideally this would never be in cpu.h.


@@ -319,27 +321,33 @@ void hppa_translate_code(CPUState *cs, TranslationBlock 
*tb,
  #define CPU_RESOLVING_TYPE TYPE_HPPA_CPU
-static inline uint64_t gva_offset_mask(target_ulong psw)
+static inline uint64_t gva_offset_mask(CPUHPPAState *env, target_ulong psw)
  {
-    return (psw & PSW_W
-    ? MAKE_64BIT_MASK(0, 62)
-    : MAKE_64BIT_MASK(0, 32));
+    if (psw & PSW_W) {
+    return (env->dr[2] & HPPA64_DIAG_SPHASH_ENABLE)
+    ? MAKE_64BIT_MASK(0, 62) &
+    ~((uint64_t)HPPA64_PDC_CACHE_RET_SPID_VAL << 48)
+    : MAKE_64BIT_MASK(0, 62);
+    } else {
+    return MAKE_64BIT_MASK(0, 32);
+    }
  }


This is getting pretty complicated now.  I think perhaps we should cache the 
mask based on current cpu state (updated with writes to psw or dr2).


Good idea. Will try to rewrite.


This would also move the HPPA64_DIAG_SPHASH_ENABLE reference out of cpu.h.


-static inline target_ulong hppa_form_gva_psw(target_ulong psw, uint64_t spc,
- target_ulong off)
+static inline target_ulong hppa_form_gva_psw(CPUHPPAState *env,
+ target_ulong psw,
+ uint64_t spc, target_ulong off)


Which means this would take the cached mask as argument, not env + psw.
Might rename as hppa_form_gva_mask() at the same time to emphasize the
change in arguments.


diff --git a/target/hppa/insns.decode b/target/hppa/insns.decode
index 71074a64c1..4eaac750ea 100644
--- a/target/hppa/insns.decode
+++ b/target/hppa/insns.decode
@@ -644,10 +644,12 @@ xmpyu   001110 . . 010 .0111 .00 t:5    
r1=%ra64 r2=%rb64
  # For 32-bit PA-7300LC (PCX-L2)
  diag_getshadowregs_pa1  000101 00   0001 1010  
  diag_putshadowregs_pa1  000101 00   0001 1010 0100 
+    diag_mfdiag 000101 dr:5  rt:5    0110  
+    diag_mtdiag 000101 dr:5  r1:5   0001 0110  
  # For 64-bit PA8700 (PCX-W2)
-    diag_getshadowregs_pa2  000101 

Re: [PATCH v5 1/6] system/physmem: handle hugetlb correctly in qemu_ram_remap()

2025-01-28 Thread David Hildenbrand

On 27.01.25 22:16, William Roche wrote:

On 1/14/25 15:02, David Hildenbrand wrote:

On 10.01.25 22:14, “William Roche wrote:

From: William Roche 

The list of hwpoison pages used to remap the memory on reset
is based on the backend real page size. When dealing with
hugepages, we create a single entry for the entire page.

To correctly handle hugetlb, we must mmap(MAP_FIXED) a complete
hugetlb page; hugetlb pages cannot be partially mapped.

Co-developed-by: David Hildenbrand 
Signed-off-by: William Roche 
---


See my comments to v4 version and my patch proposal.


I'm copying and answering your comments here:


On 1/14/25 14:56, David Hildenbrand wrote:

On 10.01.25 21:56, William Roche wrote:

On 1/8/25 22:34, David Hildenbrand wrote:

On 14.12.24 14:45, “William Roche wrote:

From: William Roche 
[...]
@@ -1286,6 +1286,10 @@ static void kvm_unpoison_all(void *param)
void kvm_hwpoison_page_add(ram_addr_t ram_addr)
{
HWPoisonPage *page;
+size_t page_size = qemu_ram_pagesize_from_addr(ram_addr);
+
+if (page_size > TARGET_PAGE_SIZE)
+ram_addr = QEMU_ALIGN_DOWN(ram_addr, page_size);


Is that part still required? I thought it would be sufficient (at least
in the context of this patch) to handle it all in qemu_ram_remap().

qemu_ram_remap() will calculate the range to process based on the
RAMBlock page size. IOW, the QEMU_ALIGN_DOWN() we do now in
qemu_ram_remap().

Or am I missing something?

(sorry if we discussed that already; if there is a good reason it might
make sense to state it in the patch description)


You are right, but at this patch level we still need to round up the


s/round up/align_down/


address and doing it here is small enough.


Let me explain.

qemu_ram_remap() in this patch here doesn't need an aligned addr. It
will compute the offset into the block and align that down.

The only case where we need the addr besides from that is the
error_report(), where I am not 100% sure if that is actually what we
want to print. We want to print something like ram_block_discard_range().


Note that ram_addr_t is a weird, separate address space. The alignment
does not have any guarantees / semantics there.


See ram_block_add() where we set
  new_block->offset = find_ram_offset(new_block->max_length);

independent of any other RAMBlock properties.

The only alignment we do is
  candidate = ROUND_UP(candidate, BITS_PER_LONG << TARGET_PAGE_BITS);

There is no guarantee that new_block->offset will be aligned to 1 GiB with
a 1 GiB hugetlb mapping.


Note that there is another conceptual issue in this function: offset
should be of type uint64_t, it's not really ram_addr_t, but an
offset into the RAMBlock.


Ok.




Of course, the code changes on patch 3/7 where we change both x86 and
ARM versions of the code to align the memory pointer correctly in both
cases.


Thinking about it more, we should never try aligning ram_addr_t, only
the offset into the memory block or the virtual address.

So please remove this from this ram_addr_t alignment from this patch,
and look into
aligning the virtual address / offset for the other user. Again, aligning
ram_addr_t is not guaranteed to work correctly.



Thanks for the technical details.

The ram_addr_t value alignment on the beginning of the page was useful
to create a single entry in the hwpoison_page_list for a large page, but
I understand that this use of ram_addr alignment may not be always accurate.
Removing this alignment (without replacing it with something else) will
end up creating several page entries in this list for the same hugetlb
page. Because when we loose a large page, we can receive several MCEs
for the sub-page locations touched on this large page before the VM crashes.


Right, although the kernel will currently only a single event IIRC. At 
least for hugetlb.



So the recovery phase on reset will go through the list to discard/remap
all the entries, and the same hugetlb page can be treated several times.
But when we had a single entry for a large page, this multiple
discard/remap does not occur.

Now, it could be technically acceptable to discard/remap a hugetlb page
several times. Other than not being optimal and taking time, the same
page being mapped or discarded multiple times doesn't seem to be a problem.
So we can leave the code like that  without complicating it with a block
and offset attributes to the hwpoison_page_list entries for example.


Right, this is something to optimize when it really becomes a problem I 
think.


--
Cheers,

David / dhildenb




Re: [PATCH] tests/functional: Add a ppc64 mac99 test

2025-01-28 Thread Thomas Huth

On 28/01/2025 19.07, Cédric Le Goater wrote:

The test sequence boots from disk a mac99 machine in 64-bit mode, in
which case the CPU is a PPC 970.

The buildroot rootfs is built with config :

BR2_powerpc64=y
BR2_powerpc_970=y

and the kernel with the g5 deconfig.

Signed-off-by: Cédric Le Goater 
---
  MAINTAINERS  |  1 +
  tests/functional/meson.build |  2 ++
  tests/functional/test_ppc64_mac99.py | 45 
  3 files changed, 48 insertions(+)
  create mode 100644 tests/functional/test_ppc64_mac99.py

diff --git a/MAINTAINERS b/MAINTAINERS
index 3a2291d17d7e..ebf249173f00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1446,6 +1446,7 @@ F: include/hw/pci-host/uninorth.h
  F: include/hw/input/adb*
  F: pc-bios/qemu_vga.ndrv
  F: tests/functional/test_ppc_mac.py
+F: tests/functional/test_ppc64_mac99.py
  
  Old World (g3beige)

  M: Mark Cave-Ayland 
diff --git a/tests/functional/meson.build b/tests/functional/meson.build
index 01a87b03e553..821a0a7c49ac 100644
--- a/tests/functional/meson.build
+++ b/tests/functional/meson.build
@@ -41,6 +41,7 @@ test_timeouts = {
'ppc64_powernv' : 480,
'ppc64_pseries' : 480,
'ppc64_tuxrun' : 420,
+  'ppc64_mac99' : 120,
'riscv64_tuxrun' : 120,
's390x_ccw_virtio' : 420,
'sh4_tuxrun' : 240,
@@ -181,6 +182,7 @@ tests_ppc64_system_thorough = [
'ppc64_powernv',
'ppc64_pseries',
'ppc64_tuxrun',
+  'ppc64_mac99',
  ]
  
  tests_riscv32_system_quick = [

diff --git a/tests/functional/test_ppc64_mac99.py 
b/tests/functional/test_ppc64_mac99.py
new file mode 100644
index ..ba582d267dae
--- /dev/null
+++ b/tests/functional/test_ppc64_mac99.py
@@ -0,0 +1,45 @@
+#!/usr/bin/env python3
+#
+# Functional test that boots a mac99 machine with a PPC970 CPU
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+from qemu_test import LinuxKernelTest, Asset
+from qemu_test import exec_command_and_wait_for_pattern
+
+class mac99Test(LinuxKernelTest):
+
+ASSET_BR2_MAC99_LINUX = Asset(
+
'https://github.com/legoater/qemu-ppc-boot/raw/refs/heads/main/buildroot/qemu_ppc64_mac99-2023.11-8-gdcd9f0f6eb-20240105/vmlinux',
+'d59307437e4365f2cced0bbd1b04949f7397b282ef349b7cafd894d74aadfbff')
+
+ASSET_BR2_MAC99_ROOTFS = Asset(
+
'https://github.com/legoater/qemu-ppc-boot/raw/refs/heads/main//buildroot/qemu_ppc64_mac99-2023.11-8-gdcd9f0f6eb-20240105/rootfs.ext2',
+'bbd5fd8af62f580bc4e585f326fe584e22856572633a8333178ea6d4ed4955a4')
+
+def test_ppc64_mac99_buildroot(self):
+self.require_netdev('user')
+
+linux_path = self.ASSET_BR2_MAC99_LINUX.fetch()
+rootfs_path = self.ASSET_BR2_MAC99_ROOTFS.fetch()
+
+self.set_machine('mac99')


Nit: Move the set_machine to the top of the function, so that the assets 
don't have to be fetched in case the machine is not available.


With that nit fixed:
Reviewed-by: Thomas Huth 



+self.vm.set_console()
+
+self.vm.add_args('-kernel', linux_path,
+ '-append', 'root=/dev/sda',
+ '-drive', f'file={rootfs_path},format=raw',
+ '-net', 'nic,model=sungem', '-net', 'user',
+ '-snapshot', '-nographic')


I just also noticed that we already have "-display none" in 
python/qemu/machine/machine.py, so you likely don't need the -nographic here 
(but looks like we've got that wrong in a bunch of tests already).



+self.vm.launch()
+
+self.wait_for_console_pattern('>> OpenBIOS')
+self.wait_for_console_pattern('Linux version')
+self.wait_for_console_pattern('/init as init process')
+self.wait_for_console_pattern('gem :f0:0e.0 eth0: Link is up at 
100 Mbps')
+self.wait_for_console_pattern('buildroot login:')
+exec_command_and_wait_for_pattern(self, 'root', '#')
+exec_command_and_wait_for_pattern(self, 'poweroff', 'Power down')
+
+if __name__ == '__main__':
+LinuxKernelTest.main()





Re: [PATCH] MAINTAINERS: Add myself as HPPA maintainer

2025-01-28 Thread Richard Henderson

On 1/28/25 09:09, del...@kernel.org wrote:

From: Helge Deller 

Since I contribute quite some code to hppa, I'd like to step up and
become the secondary maintainer for HPPA beside Richard.
Additionally change status of hppa machines to maintained as I will
take care of them.

Signed-off-by: Helge Deller 
---



Reviewed-by: Richard Henderson 

r~




Re: [PATCH] tests/functional: Add a ppc64 mac99 test

2025-01-28 Thread Philippe Mathieu-Daudé

On 28/1/25 19:20, Thomas Huth wrote:

On 28/01/2025 19.07, Cédric Le Goater wrote:

The test sequence boots from disk a mac99 machine in 64-bit mode, in
which case the CPU is a PPC 970.

The buildroot rootfs is built with config :

BR2_powerpc64=y
BR2_powerpc_970=y

and the kernel with the g5 deconfig.

Signed-off-by: Cédric Le Goater 
---
  MAINTAINERS  |  1 +
  tests/functional/meson.build |  2 ++
  tests/functional/test_ppc64_mac99.py | 45 
  3 files changed, 48 insertions(+)
  create mode 100644 tests/functional/test_ppc64_mac99.py

diff --git a/MAINTAINERS b/MAINTAINERS
index 3a2291d17d7e..ebf249173f00 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1446,6 +1446,7 @@ F: include/hw/pci-host/uninorth.h
  F: include/hw/input/adb*
  F: pc-bios/qemu_vga.ndrv
  F: tests/functional/test_ppc_mac.py
+F: tests/functional/test_ppc64_mac99.py
  Old World (g3beige)
  M: Mark Cave-Ayland 
diff --git a/tests/functional/meson.build b/tests/functional/meson.build
index 01a87b03e553..821a0a7c49ac 100644
--- a/tests/functional/meson.build
+++ b/tests/functional/meson.build
@@ -41,6 +41,7 @@ test_timeouts = {
    'ppc64_powernv' : 480,
    'ppc64_pseries' : 480,
    'ppc64_tuxrun' : 420,
+  'ppc64_mac99' : 120,
    'riscv64_tuxrun' : 120,
    's390x_ccw_virtio' : 420,
    'sh4_tuxrun' : 240,
@@ -181,6 +182,7 @@ tests_ppc64_system_thorough = [
    'ppc64_powernv',
    'ppc64_pseries',
    'ppc64_tuxrun',
+  'ppc64_mac99',
  ]
  tests_riscv32_system_quick = [
diff --git a/tests/functional/test_ppc64_mac99.py b/tests/functional/ 
test_ppc64_mac99.py

new file mode 100644
index ..ba582d267dae
--- /dev/null
+++ b/tests/functional/test_ppc64_mac99.py
@@ -0,0 +1,45 @@
+#!/usr/bin/env python3
+#
+# Functional test that boots a mac99 machine with a PPC970 CPU
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+from qemu_test import LinuxKernelTest, Asset
+from qemu_test import exec_command_and_wait_for_pattern
+
+class mac99Test(LinuxKernelTest):
+
+    ASSET_BR2_MAC99_LINUX = Asset(
+    'https://github.com/legoater/qemu-ppc-boot/raw/refs/heads/ 
main/buildroot/qemu_ppc64_mac99-2023.11-8-gdcd9f0f6eb-20240105/vmlinux',
+
'd59307437e4365f2cced0bbd1b04949f7397b282ef349b7cafd894d74aadfbff')

+
+    ASSET_BR2_MAC99_ROOTFS = Asset(
+    'https://github.com/legoater/qemu-ppc-boot/raw/refs/heads/ 
main//buildroot/qemu_ppc64_mac99-2023.11-8-gdcd9f0f6eb-20240105/ 
rootfs.ext2',
+
'bbd5fd8af62f580bc4e585f326fe584e22856572633a8333178ea6d4ed4955a4')

+
+    def test_ppc64_mac99_buildroot(self):
+    self.require_netdev('user')
+
+    linux_path = self.ASSET_BR2_MAC99_LINUX.fetch()
+    rootfs_path = self.ASSET_BR2_MAC99_ROOTFS.fetch()
+
+    self.set_machine('mac99')


Nit: Move the set_machine to the top of the function, so that the assets 
don't have to be fetched in case the machine is not available.


Nice to know, this is not obvious. Should we check for unset machine
in fetch()? Or add fetch_for_machine()... Nitpicking yet more :p



With that nit fixed:
Reviewed-by: Thomas Huth 



+    self.vm.set_console()
+
+    self.vm.add_args('-kernel', linux_path,
+ '-append', 'root=/dev/sda',
+ '-drive', f'file={rootfs_path},format=raw',
+ '-net', 'nic,model=sungem', '-net', 'user',
+ '-snapshot', '-nographic')


I just also noticed that we already have "-display none" in python/qemu/ 
machine/machine.py, so you likely don't need the -nographic here (but 
looks like we've got that wrong in a bunch of tests already).


Maybe warn in QEMUMachine::_pre_launch() if "-display none" && '-nographic'?




+    self.vm.launch()




Re: [PATCH v5 3/6] accel/kvm: Report the loss of a large memory page

2025-01-28 Thread David Hildenbrand

Yes, we can collect the information from the block associated to this
ram_addr. But instead of duplicating the necessary code into both i386
and ARM, I came back to adding the change into the
kvm_hwpoison_page_add() function called from both i386 and ARM specific
code.

I also needed a new possibility to retrieve the information while we are
dealing with the SIGBUS signal, and created a new function to gather the
information from the RAMBlock:
qemu_ram_block_location_info_from_addr(ram_addr_t ram_addr,
 struct RAMBlockInfo *b_info)
with the associated struct.

So that we can use the RCU_READ_LOCK_GUARD() and retrieve all the data.


Makes sense.




Note about ARM failing on large pages:
--=--
I could test that ARM VMs impacted by memory errors on a large
underlying memory page, can end up looping on reporting the error:
The VM encountering an error has a high probability to crash and can try
to save a vmcore with a kdump phase.


Yeah, that's what I thought. If you rip out 1 GiB of memory, your VM is 
going to have a bad time :/




This fix introduces qemu messages reporting errors when they are relayed
to the VM.
A large page being poisoned by an error on ARM can make a VM loop on the
vmcore collection phase and the console would show messages like that
appearing every 10 seconds (before the change):

   vvv
   Starting Kdump Vmcore Save Service...
[3.095399] kdump[445]: Kdump is using the default log level(3).
[3.173998] kdump[481]: saving to
/sysroot/var/crash/127.0.0.1-2025-01-27-20:17:40/
[3.189683] kdump[486]: saving vmcore-dmesg.txt to
/sysroot/var/crash/127.0.0.1-2025-01-27-20:17:40/
[3.213584] kdump[492]: saving vmcore-dmesg.txt complete
[3.220295] kdump[494]: saving vmcore
[   10.029515] EDAC MC0: 1 UE unknown on unknown memory ( page:0x116c60
offset:0x0 grain:1 - APEI location: )
[   10.033647] [Firmware Warn]: GHES: Invalid address in generic error
data: 0x116c6
[   10.036974] {2}[Hardware Error]: Hardware error from APEI Generic
Hardware Error Source: 0
[   10.040514] {2}[Hardware Error]: event severity: recoverable
[   10.042911] {2}[Hardware Error]:  Error 0, type: recoverable
[   10.045310] {2}[Hardware Error]:   section_type: memory error
[   10.047666] {2}[Hardware Error]:   physical_address: 0x000116c6
[   10.050486] {2}[Hardware Error]:   error_type: 0, unknown
[   20.053205] EDAC MC0: 1 UE unknown on unknown memory ( page:0x116c60
offset:0x0 grain:1 - APEI location: )
[   20.057416] [Firmware Warn]: GHES: Invalid address in generic error
data: 0x116c6
[   20.060781] {3}[Hardware Error]: Hardware error from APEI Generic
Hardware Error Source: 0
[   20.065472] {3}[Hardware Error]: event severity: recoverable
[   20.067878] {3}[Hardware Error]:  Error 0, type: recoverable
[   20.070273] {3}[Hardware Error]:   section_type: memory error
[   20.072686] {3}[Hardware Error]:   physical_address: 0x000116c6
[   20.075590] {3}[Hardware Error]:   error_type: 0, unknown
   ^^^

with the fix, we now have a flood of messages like:

   vvv
qemu-system-aarch64: Memory Error on large page from
ram-node1:d5e0+0 +20
qemu-system-aarch64: Guest Memory Error at QEMU addr 0x35c79000 and
GUEST addr 0x115e79000 of type BUS_MCEERR_AR injected
qemu-system-aarch64: Memory Error on large page from
ram-node1:d5e0+0 +20
qemu-system-aarch64: Guest Memory Error at QEMU addr 0x35c79000 and
GUEST addr 0x115e79000 of type BUS_MCEERR_AR injected
qemu-system-aarch64: Memory Error on large page from
ram-node1:d5e0+0 +20
qemu-system-aarch64: Guest Memory Error at QEMU addr 0x35c79000 and
GUEST addr 0x115e79000 of type BUS_MCEERR_AR injected
   ^^^


In both cases, this situation loops indefinitely !

I'm just informing of a change of behavior, fixing this issue would most
probably require VM kernel modifications  or a work-around in qemu when
errors are reported too often, but is out of the scope of this current
qemu fix.


Agreed. I think one problem is that kdump cannot really cope with new 
memory errors (it tries to not touch pages that had a memory error in 
the old kernel).


Maybe this is also due to the fact that we inform the kernel only about 
a single page vanishing, whereby actually a whole 1 GiB is vanishing.


--
Cheers,

David / dhildenb




Re: [PATCH 11/11] hw/sd: Remove unused SDState::enable

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

Now that sd_enable() has been removed,SD::enable is set to true in
sd_instance_init() and then never changed. So we can remove it.

Note that the VMSTATE_UNUSED() size argument should be '1', not
'sizeof(bool)', as noted in the CAUTION comment in vmstate.h.

Signed-off-by: Peter Maydell
---
  hw/sd/sd.c | 16 
  1 file changed, 8 insertions(+), 8 deletions(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 3/7] tests/qtest/migration: Initialize MigrationTestEnv::arch early

2025-01-28 Thread Richard Henderson

On 1/28/25 05:54, Philippe Mathieu-Daudé wrote:

Some tests expectMigrationTestEnv::arch to be set. Initialize
it early enough to avoid SIGSEGV, for example like the following
g_str_equal() call in migration/precopy-tests.c:

954 void migration_test_add_precopy(MigrationTestEnv *env)
955 {
...
   1001 if (g_str_equal(env->arch, "x86_64") && env->has_dirty_ring) {
   1002
   1003 migration_test_add("/migration/dirty_ring",
   1004test_precopy_unix_dirty_ring);

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


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 09/11] hw/sd: Remove unused 'enable' method from SDCardClass

2025-01-28 Thread Richard Henderson

On 1/28/25 02:45, Peter Maydell wrote:

The SDCardClass has an 'enable' method, but nothing actually invokes it.
The underlying implementation is sd_enable(), which is documented
in sdcard_legacy.h as something that should not be used and was only
present for the benefit of the now-removed nseries boards. Unlike
all the other method pointers in SDCardClass, this one doesn't have
an sdbus_foo() function wrapper in hw/sd/core.c.

Remove the unused method.

Signed-off-by: Peter Maydell
---
  include/hw/sd/sd.h | 1 -
  hw/sd/sd.c | 1 -
  2 files changed, 2 deletions(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 1/7] migration/dirtyrate: Do not unlock cpu_list lock twice

2025-01-28 Thread Richard Henderson

On 1/28/25 05:54, Philippe Mathieu-Daudé wrote:

&qemu_cpu_list_lock is locked within the WITH_QEMU_LOCK_GUARD()
context, then unlocked. No need to manually unlock it.

Fixes: 370ed600296 ("cpu: expose qemu_cpu_list_lock for lock-guard use")
Signed-off-by: Philippe Mathieu-Daudé
---
  migration/dirtyrate.c | 1 -
  1 file changed, 1 deletion(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 4/7] tests/qtest/migration: Pass accelerator arguments as machine option

2025-01-28 Thread Richard Henderson

On 1/28/25 05:54, Philippe Mathieu-Daudé wrote:

The '-accel' CLI option is handler as sugar property as
'-machine,accel='. Replace the migration tests command
line, only using the best accelerator available (first
hardware, then software).


Is that really true?  I thought -accel was split from -machine explicitly because of the 
introduction of accelerator parameters, just like dirty-ring-size.  Otherwise you risk 
confusing accelerator parameters and machine parameters.



r~



Re: [PATCH 7/7] tests/qtest/migration: Allow using accelerators different of TCG / KVM

2025-01-28 Thread Richard Henderson

On 1/28/25 05:54, Philippe Mathieu-Daudé wrote:

There is no particular reason to restrict all the framework
to TCG or KVM, since we can check on a per-test basis which
accelerator is available (viaMigrationTestEnv::has_$ACCEL).

Signed-off-by: Philippe Mathieu-Daudé
---
  tests/qtest/migration/framework.c | 5 -
  1 file changed, 5 deletions(-)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 5/7] tests/qtest/migration: Add MigrationTestEnv::has_hvf field

2025-01-28 Thread Richard Henderson

On 1/28/25 05:54, Philippe Mathieu-Daudé wrote:

Allow tests to tune their parameters when running on HVF.

Signed-off-by: Philippe Mathieu-Daudé
---
  tests/qtest/migration/framework.h | 1 +
  tests/qtest/migration/framework.c | 1 +
  2 files changed, 2 insertions(+)


Reviewed-by: Richard Henderson 

r~



Re: [PATCH 7/7] tests/qtest/migration: Allow using accelerators different of TCG / KVM

2025-01-28 Thread Richard Henderson

On 1/28/25 07:04, Fabiano Rosas wrote:

Philippe Mathieu-Daudé  writes:


There is no particular reason to restrict all the framework
to TCG or KVM, since we can check on a per-test basis which
accelerator is available (via MigrationTestEnv::has_$ACCEL).


The reason is:

CONFIG_KVM=n
CONFIG_TCG=n

The check is about "there is no accelerator at all".


We perform the no accelerator check in meson.build on a per-target basis.
So you'll never have a qemu-system-foo binary with zero accelerators.


r~



Re: [RFC PATCH 1/9] accel/tcg: Simplify use of &first_cpu in rr_cpu_thread_fn()

2025-01-28 Thread Richard Henderson

On 1/28/25 06:21, Philippe Mathieu-Daudé wrote:

Let vCPUs wait for themselves being ready first, then other ones.
This allows the first thread to starts without the global vcpu
queue (thus &first_cpu) being populated.

Signed-off-by: Philippe Mathieu-Daudé 
---
  accel/tcg/tcg-accel-ops-rr.c | 15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/accel/tcg/tcg-accel-ops-rr.c b/accel/tcg/tcg-accel-ops-rr.c
index 028b385af9a..5ad3d617bce 100644
--- a/accel/tcg/tcg-accel-ops-rr.c
+++ b/accel/tcg/tcg-accel-ops-rr.c
@@ -197,20 +197,21 @@ static void *rr_cpu_thread_fn(void *arg)
  qemu_guest_random_seed_thread_part2(cpu->random_seed);
  
  /* wait for initial kick-off after machine start */

-while (first_cpu->stopped) {
-qemu_cond_wait_bql(first_cpu->halt_cond);
+while (cpu->stopped) {
+CPUState *iter_cpu;
+
+qemu_cond_wait_bql(cpu->halt_cond);
  
  /* process any pending work */

-CPU_FOREACH(cpu) {
-current_cpu = cpu;
-qemu_wait_io_event_common(cpu);
+CPU_FOREACH(iter_cpu) {
+current_cpu = iter_cpu;
+qemu_wait_io_event_common(iter_cpu);
  }
  }
  
+g_assert(first_cpu);

  rr_start_kick_timer();
  
-cpu = first_cpu;


This final line seems to be unrelated.

I'm not saying it's wrong, but it's certainly a change in behaviour.  We no longer execute 
from first_cpu first.



r~



Re: [PATCH 7/7] tests/qtest/migration: Allow using accelerators different of TCG / KVM

2025-01-28 Thread Fabiano Rosas
Richard Henderson  writes:

> On 1/28/25 07:04, Fabiano Rosas wrote:
>> Philippe Mathieu-Daudé  writes:
>> 
>>> There is no particular reason to restrict all the framework
>>> to TCG or KVM, since we can check on a per-test basis which
>>> accelerator is available (via MigrationTestEnv::has_$ACCEL).
>> 
>> The reason is:
>> 
>> CONFIG_KVM=n
>> CONFIG_TCG=n
>> 
>> The check is about "there is no accelerator at all".
>
> We perform the no accelerator check in meson.build on a per-target basis.
> So you'll never have a qemu-system-foo binary with zero accelerators.
>

Ok, the issue was not zero accelerators, but Xen. On aarch64, this
produces a binary with no TCG nor KVM:

--target-list=x86_64-softmmu --disable-tcg --enable-xen 



[Stable-9.1.3 32/58] meson.build: Disallow libnfs v6 to fix the broken macOS build

2025-01-28 Thread Michael Tokarev
The macOS builds in our CI (and possibly other very recent distros)
are currently broken since the update to libnfs version 6 there.
That version apparently comes with a big API breakage. v5.0.3 was
the final release of the old API (see the libnfs commit here:
https://github.com/sahlberg/libnfs/commit/4379837 ).

Disallow version 6.x for now to get the broken CI job working
again. Once somebody had enough time to adapt our code in
block/nfs.c, we can revert this change again.

Message-ID: <20241218065157.209020-1-th...@redhat.com>
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
(cherry picked from commit e2d98f257138b83b6a492d1da5847a7fe0930d10)
Signed-off-by: Michael Tokarev 

diff --git a/meson.build b/meson.build
index aa7ea85d0b..b3080c3a8a 100644
--- a/meson.build
+++ b/meson.build
@@ -1056,7 +1056,7 @@ endif
 
 libnfs = not_found
 if not get_option('libnfs').auto() or have_block
-  libnfs = dependency('libnfs', version: '>=1.9.3',
+  libnfs = dependency('libnfs', version: ['>=1.9.3', '<6.0.0'],
   required: get_option('libnfs'),
   method: 'pkg-config')
 endif
-- 
2.39.5




[Stable-9.1.3 33/58] vhost-user: fix shared object return values

2025-01-28 Thread Michael Tokarev
VHOST_USER_BACKEND_SHARED_OBJECT_ADD and
VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE state
in the spec that they return 0 for successful
operations, non-zero otherwise. However,
implementation relies on the return types
of the virtio-dmabuf library, with opposite
semantics (true if everything is correct,
false otherwise). Therefore, current
implementation violates the specification.

Revert the logic so that the implementation
of the vhost-user handling methods matches
the specification.

Fixes: 043e127a126bb3ceb5fc753deee27d261fd0c5ce
Fixes: 160947666276c5b7f6bca4d746bcac2966635d79
Reviewed-by: Stefano Garzarella 
Signed-off-by: Albert Esteve 
Message-Id: <20241022124615.585596-1-aest...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit eea5aeef84e1b74f515b474d3a86377701f93750)
Signed-off-by: Michael Tokarev 

diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
index 00561daa06..96c5e6b95f 100644
--- a/hw/virtio/vhost-user.c
+++ b/hw/virtio/vhost-user.c
@@ -1607,9 +1607,14 @@ vhost_user_backend_handle_shared_object_add(struct 
vhost_dev *dev,
 QemuUUID uuid;
 
 memcpy(uuid.data, object->uuid, sizeof(object->uuid));
-return virtio_add_vhost_device(&uuid, dev);
+return !virtio_add_vhost_device(&uuid, dev);
 }
 
+/*
+ * Handle VHOST_USER_BACKEND_SHARED_OBJECT_REMOVE backend requests.
+ *
+ * Return: 0 on success, 1 on error.
+ */
 static int
 vhost_user_backend_handle_shared_object_remove(struct vhost_dev *dev,
VhostUserShared *object)
@@ -1623,16 +1628,16 @@ vhost_user_backend_handle_shared_object_remove(struct 
vhost_dev *dev,
 struct vhost_dev *owner = virtio_lookup_vhost_device(&uuid);
 if (dev != owner) {
 /* Not allowed to remove non-owned entries */
-return 0;
+return 1;
 }
 break;
 }
 default:
 /* Not allowed to remove non-owned entries */
-return 0;
+return 1;
 }
 
-return virtio_remove_resource(&uuid);
+return !virtio_remove_resource(&uuid);
 }
 
 static bool vhost_user_send_resp(QIOChannel *ioc, VhostUserHeader *hdr,
-- 
2.39.5




[Stable-8.2.9 17/45] hw/nvme: take a reference on the subsystem on vf realization

2025-01-28 Thread Michael Tokarev
Make sure we grab a reference on the subsystem when a VF is realized.
Otherwise, the subsytem will be unrealized automatically when the VFs
are unregistered and unreffed.

This fixes a latent bug but was not exposed until commit 08f632848008
("pcie: Release references of virtual functions"). This was then fixed
(or rather, hidden) by commit c613ad25125b ("pcie_sriov: Do not manually
unrealize"), but that was then reverted (due to other issues) in commit
b0fdaee5d1ed, exposing the bug yet again.

Cc: qemu-sta...@nongnu.org
Fixes: 08f632848008 ("pcie: Release references of virtual functions")
Reviewed-by: Jesper Wendel Devantier 
Signed-off-by: Klaus Jensen 
(cherry picked from commit 6651f8f2e5051f6750c2534ab3151339b3c476a2)
Signed-off-by: Michael Tokarev 

diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index 94a37a3aef..4c400aa005 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -8346,6 +8346,13 @@ static void nvme_realize(PCIDevice *pci_dev, Error 
**errp)
  */
 n->params.serial = g_strdup(pn->params.serial);
 n->subsys = pn->subsys;
+
+/*
+ * Assigning this link (strong link) causes an `object_unref` later in
+ * `object_release_link_property`. Increment the refcount to balance
+ * this out.
+ */
+object_ref(OBJECT(pn->subsys));
 }
 
 if (!nvme_check_params(n, errp)) {
-- 
2.39.5




[Stable-8.2.9 34/45] target/loongarch: Use actual operand size with vbsrl check

2025-01-28 Thread Michael Tokarev
Hardcoded 32 bytes is used for vbsrl emulation check, there is
problem when options lsx=on,lasx=off is used for vbsrl.v instruction
in TCG mode. It injects LASX exception rather LSX exception.

Here actual operand size is used.

Cc: qemu-sta...@nongnu.org
Fixes: df97f338076 ("target/loongarch: Implement xvreplve xvinsve0 xvpickve")
Signed-off-by: Bibo Mao 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
(cherry picked from commit d41989e7548397b469ec9c7be4cee699321a317e)
Signed-off-by: Michael Tokarev 

diff --git a/target/loongarch/insn_trans/trans_vec.c.inc 
b/target/loongarch/insn_trans/trans_vec.c.inc
index 92b1d22e28..ba5ca98a33 100644
--- a/target/loongarch/insn_trans/trans_vec.c.inc
+++ b/target/loongarch/insn_trans/trans_vec.c.inc
@@ -5126,7 +5126,7 @@ static bool do_vbsrl_v(DisasContext *ctx, arg_vv_i *a, 
uint32_t oprsz)
 {
 int i, ofs;
 
-if (!check_vec(ctx, 32)) {
+if (!check_vec(ctx, oprsz)) {
 return true;
 }
 
-- 
2.39.5




[Stable-9.1.3 07/58] ssh: Do not switch session to non-blocking mode

2025-01-28 Thread Michael Tokarev
The libssh does not handle non-blocking mode in SFTP correctly. The
driver code already changes the mode to blocking for the SFTP
initialization, but for some reason changes to non-blocking mode.
This used to work accidentally until libssh in 0.11 branch merged
the patch to avoid infinite looping in case of network errors:

https://gitlab.com/libssh/libssh-mirror/-/merge_requests/498

Since then, the ssh driver in qemu fails to read files over SFTP
as the first SFTP messages exchanged after switching the session
to non-blocking mode return SSH_AGAIN, but that message is lost
int the SFTP internals and interpretted as SSH_ERROR, which is
returned to the caller:

https://gitlab.com/libssh/libssh-mirror/-/issues/280

This is indeed an issue in libssh that we should address in the
long term, but it will require more work on the internals. For
now, the SFTP is not supported in non-blocking mode.

Fixes: https://gitlab.com/libssh/libssh-mirror/-/issues/280
Signed-off-by: Jakub Jelen 
Signed-off-by: Richard W.M. Jones 
Message-ID: <20241113125526.2495731-1-rjo...@redhat.com>
Reviewed-by: Kevin Wolf 
Signed-off-by: Kevin Wolf 
(cherry picked from commit fbdea3d6c13d5a75895c287a004c6f1a6bf6c164)
Signed-off-by: Michael Tokarev 

diff --git a/block/ssh.c b/block/ssh.c
index 27d582e0e3..5c16ff4fb6 100644
--- a/block/ssh.c
+++ b/block/ssh.c
@@ -865,9 +865,6 @@ static int ssh_open(BlockDriverState *bs, QDict *options, 
int bdrv_flags,
 goto err;
 }
 
-/* Go non-blocking. */
-ssh_set_blocking(s->session, 0);
-
 if (s->attrs->type == SSH_FILEXFER_TYPE_REGULAR) {
 bs->supported_truncate_flags = BDRV_REQ_ZERO_WRITE;
 }
-- 
2.39.5




Re: [PATCH] tests/functional/test_mips_malta: Fix comment about endianness of the test

2025-01-28 Thread Philippe Mathieu-Daudé

On 27/1/25 19:41, Thomas Huth wrote:

This test is for the big endian MIPS target, not for the little endian
target.

Signed-off-by: Thomas Huth 
---
  tests/functional/test_mips_malta.py | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/functional/test_mips_malta.py 
b/tests/functional/test_mips_malta.py
index 3b15038d89..eaf372255b 100755
--- a/tests/functional/test_mips_malta.py
+++ b/tests/functional/test_mips_malta.py
@@ -1,6 +1,6 @@
  #!/usr/bin/env python3
  #
-# Functional tests for the little-endian 32-bit MIPS Malta board
+# Functional tests for the big-endian 32-bit MIPS Malta board
  #
  # Copyright (c) Philippe Mathieu-Daudé 
  #


Oops

Fixes: 79cb4a14cb6 ("tests/functional: Convert mips32eb 4Kc Malta tests")

Reviewed-by: Philippe Mathieu-Daudé 




[Stable-9.1.3 56/58] pci: acpi: Windows 'PCI Label Id' bug workaround

2025-01-28 Thread Michael Tokarev
Current versions of Windows call _DSM(func=7) regardless
of whether it is supported or not. It leads to NICs having bogus
'PCI Label Id = 0', where none should be set at all.

Also presence of 'PCI Label Id' triggers another Windows bug
on localized versions that leads to hangs. The later bug is fixed
in latest updates for 'Windows Server' but not in consumer
versions of Windows (and there is no plans to fix it
as far as I'm aware).

Given it's easy, implement Microsoft suggested workaround
(return invalid Package) so that affected Windows versions
could boot on QEMU.
This would effectvely remove bogus 'PCI Label Id's on NICs,
but MS teem confirmed that flipping 'PCI Label Id' should not
change 'Network Connection' ennumeration, so it should be safe
for QEMU to change _DSM without any compat code.

Smoke tested with WinXP and WS2022
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/774
Signed-off-by: Igor Mammedov 
Message-Id: <20250115125342.3883374-3-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit 0b053391985abcc40b16ac8fc4a7f6588d1d95c1)
Signed-off-by: Michael Tokarev 

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 5d4bd2b710..a64ffbb0c2 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -655,6 +655,7 @@ static Aml *aml_pci_pdsm(void)
 Aml *acpi_index = aml_local(2);
 Aml *zero = aml_int(0);
 Aml *one = aml_int(1);
+Aml *not_supp = aml_int(0x);
 Aml *func = aml_arg(2);
 Aml *params = aml_arg(4);
 Aml *bnum = aml_derefof(aml_index(params, aml_int(0)));
@@ -679,7 +680,7 @@ static Aml *aml_pci_pdsm(void)
  */
 ifctx1 = aml_if(aml_lnot(
  aml_or(aml_equal(acpi_index, zero),
-aml_equal(acpi_index, aml_int(0x)), NULL)
+aml_equal(acpi_index, not_supp), NULL)
  ));
 {
 /* have supported functions */
@@ -705,18 +706,30 @@ static Aml *aml_pci_pdsm(void)
 {
Aml *pkg = aml_package(2);
 
-   aml_append(pkg, zero);
-   /*
-* optional, if not impl. should return null string
-*/
-   aml_append(pkg, aml_string("%s", ""));
-   aml_append(ifctx, aml_store(pkg, ret));
-
aml_append(ifctx, aml_store(aml_call2("AIDX", bnum, sunum), 
acpi_index));
+   aml_append(ifctx, aml_store(pkg, ret));
/*
-* update acpi-index to actual value
+* Windows calls func=7 without checking if it's available,
+* as workaround Microsoft has suggested to return invalid for func7
+* Package, so return 2 elements package but only initialize elements
+* when acpi_index is supported and leave them uninitialized, which
+* leads elements to being Uninitialized ObjectType and should trip
+* Windows into discarding result as an unexpected and prevent setting
+* bogus 'PCI Label' on the device.
 */
-   aml_append(ifctx, aml_store(acpi_index, aml_index(ret, zero)));
+   ifctx1 = aml_if(aml_lnot(aml_lor(
+aml_equal(acpi_index, zero), aml_equal(acpi_index, 
not_supp)
+)));
+   {
+   aml_append(ifctx1, aml_store(acpi_index, aml_index(ret, zero)));
+   /*
+* optional, if not impl. should return null string
+*/
+   aml_append(ifctx1, aml_store(aml_string("%s", ""),
+aml_index(ret, one)));
+   }
+   aml_append(ifctx, ifctx1);
+
aml_append(ifctx, aml_return(ret));
 }
 
-- 
2.39.5




[Stable-9.1.3 55/58] tests: acpi: whitelist expected blobs

2025-01-28 Thread Michael Tokarev
Signed-off-by: Igor Mammedov 
Message-Id: <20250115125342.3883374-2-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit 1ad32644fe4c9fb25086be15a66dde1d55d3410f)
Signed-off-by: Michael Tokarev 
(Mjt: remove q35/DSDT.acpihmat-generic-x which is not present in 9.1)

diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..3eab70014c 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1 +1,40 @@
 /* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/x86/pc/DSDT",
+"tests/data/acpi/x86/pc/DSDT.acpierst",
+"tests/data/acpi/x86/pc/DSDT.acpihmat",
+"tests/data/acpi/x86/pc/DSDT.bridge",
+"tests/data/acpi/x86/pc/DSDT.cphp",
+"tests/data/acpi/x86/pc/DSDT.dimmpxm",
+"tests/data/acpi/x86/pc/DSDT.hpbridge",
+"tests/data/acpi/x86/pc/DSDT.ipmikcs",
+"tests/data/acpi/x86/pc/DSDT.memhp",
+"tests/data/acpi/x86/pc/DSDT.nohpet",
+"tests/data/acpi/x86/pc/DSDT.numamem",
+"tests/data/acpi/x86/pc/DSDT.roothp",
+"tests/data/acpi/x86/q35/DSDT",
+"tests/data/acpi/x86/q35/DSDT.acpierst",
+"tests/data/acpi/x86/q35/DSDT.acpihmat",
+"tests/data/acpi/x86/q35/DSDT.acpihmat-noinitiator",
+"tests/data/acpi/x86/q35/DSDT.applesmc",
+"tests/data/acpi/x86/q35/DSDT.bridge",
+"tests/data/acpi/x86/q35/DSDT.core-count",
+"tests/data/acpi/x86/q35/DSDT.core-count2",
+"tests/data/acpi/x86/q35/DSDT.cphp",
+"tests/data/acpi/x86/q35/DSDT.cxl",
+"tests/data/acpi/x86/q35/DSDT.dimmpxm",
+"tests/data/acpi/x86/q35/DSDT.ipmibt",
+"tests/data/acpi/x86/q35/DSDT.ipmismbus",
+"tests/data/acpi/x86/q35/DSDT.ivrs",
+"tests/data/acpi/x86/q35/DSDT.memhp",
+"tests/data/acpi/x86/q35/DSDT.mmio64",
+"tests/data/acpi/x86/q35/DSDT.multi-bridge",
+"tests/data/acpi/x86/q35/DSDT.nohpet",
+"tests/data/acpi/x86/q35/DSDT.numamem",
+"tests/data/acpi/x86/q35/DSDT.pvpanic-isa",
+"tests/data/acpi/x86/q35/DSDT.thread-count",
+"tests/data/acpi/x86/q35/DSDT.thread-count2",
+"tests/data/acpi/x86/q35/DSDT.tis.tpm12",
+"tests/data/acpi/x86/q35/DSDT.tis.tpm2",
+"tests/data/acpi/x86/q35/DSDT.type4-count",
+"tests/data/acpi/x86/q35/DSDT.viot",
+"tests/data/acpi/x86/q35/DSDT.xapic",
-- 
2.39.5




[Stable-8.2.9 45/45] hw/cxl: Fix msix_notify: Assertion `vector < dev->msix_entries_nr`

2025-01-28 Thread Michael Tokarev
This assertion always happens when we sanitize the CXL memory device.
$ echo 1 > /sys/bus/cxl/devices/mem0/security/sanitize

It is incorrect to register an MSIX number beyond the device's capability.

Increase the device's MSIX number to cover the mailbox msix number(9).

Fixes: 43efb0bfad2b ("hw/cxl/mbox: Wire up interrupts for background 
completion")
Signed-off-by: Li Zhijian 
Message-Id: <20250115075834.167504-1-lizhij...@fujitsu.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit 1ce979e7269a34d19ea1a65808df014d8b2acbf6)
Signed-off-by: Michael Tokarev 

diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
index 52647b4ac7..72d9371347 100644
--- a/hw/mem/cxl_type3.c
+++ b/hw/mem/cxl_type3.c
@@ -685,7 +685,7 @@ static void ct3_realize(PCIDevice *pci_dev, Error **errp)
 ComponentRegisters *regs = &cxl_cstate->crb;
 MemoryRegion *mr = ®s->component_registers;
 uint8_t *pci_conf = pci_dev->config;
-unsigned short msix_num = 6;
+unsigned short msix_num = 10;
 int i, rc;
 
 QTAILQ_INIT(&ct3d->error_list);
-- 
2.39.5




[Stable-9.1.3 52/58] hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec

2025-01-28 Thread Michael Tokarev
QEMU would crash with a failed assertion if the XHCI controller
attempted to raise the interrupt on an interrupter corresponding
to a MSI vector with a higher index than the highest configured
for the device by the guest driver.

This behaviour is correct on the MSI/PCI side: per PCI 3.0 spec,
devices must ensure they do not send MSI notifications for
vectors beyond the range of those allocated by the system/driver
software. Unlike MSI-X, there is no generic way for handling
aliasing in the case of fewer allocated vectors than requested,
so the specifics are up to device implementors. (Section
6.8.3.4. "Sending Messages")

It turns out the XHCI spec (Implementation Note in section 4.17,
"Interrupters") requires that the host controller signal the MSI
vector with the number computed by taking the interrupter number
modulo the number of enabled MSI vectors.

This change introduces that modulo calculation, fixing the
failed assertion. This makes the device work correctly in MSI mode
with macOS's XHCI driver, which only allocates a single vector.

Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Philippe Mathieu-Daudé 
Message-ID: <20250112210056.16658-2-p...@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé 
(cherry picked from commit bb5b7fced6b5d3334ab20702fc846e47bb1fb731)
Signed-off-by: Michael Tokarev 

diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 264d7ebb77..831ba31277 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -74,6 +74,7 @@ static bool xhci_pci_intr_raise(XHCIState *xhci, int n, bool 
level)
 }
 
 if (msi_enabled(pci_dev) && level) {
+n %= msi_nr_vectors_allocated(pci_dev);
 msi_notify(pci_dev, n);
 return true;
 }
-- 
2.39.5




[Stable-9.1.3 02/58] bitops.h: Define bit operations on 'uint32_t' arrays

2025-01-28 Thread Michael Tokarev
Currently bitops.h defines a set of operations that work on
arbitrary-length bit arrays.  However (largely because they
originally came from the Linux kernel) the bit array storage is an
array of 'unsigned long'.  This is OK for the kernel and even for
parts of QEMU where we don't really care about the underlying storage
format, but it is not good for devices, where we often want to expose
the storage to the guest and so need a type that is not
variably-sized between host OSes.

We already have a workaround for this in the GICv3 model:
arm_gicv3_common.h defines equivalents of the bit operations that
work on uint32_t.  It turns out that we should also be using
something similar in hw/intc/loongarch_extioi.c, which currently
casts a pointer to a uint32_t array to 'unsigned long *' in
extio_setirq(), which is both undefined behaviour and not correct on
a big-endian host.

Define equivalents of the set_bit() function family which work
with a uint32_t array.

(Cc stable because we're about to provide a bugfix to
loongarch_extioi which will depend on this commit.)

Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
Message-id: 20241108135514.4006953-2-peter.mayd...@linaro.org
(cherry picked from commit 3d7680fb18c7b17701730589d241a32e85f763a3)
Signed-off-by: Michael Tokarev 

diff --git a/include/qemu/bitmap.h b/include/qemu/bitmap.h
index 1cf288445f..0044333cb5 100644
--- a/include/qemu/bitmap.h
+++ b/include/qemu/bitmap.h
@@ -69,6 +69,14 @@
 #define DECLARE_BITMAP(name,bits)  \
 unsigned long name[BITS_TO_LONGS(bits)]
 
+/*
+ * This is for use with the bit32 versions of set_bit() etc;
+ * we don't currently support the full range of bitmap operations
+ * on bitmaps backed by an array of uint32_t.
+ */
+#define DECLARE_BITMAP32(name, bits)\
+uint32_t name[BITS_TO_U32S(bits)]
+
 #define small_nbits(nbits)  \
 ((nbits) <= BITS_PER_LONG)
 
diff --git a/include/qemu/bitops.h b/include/qemu/bitops.h
index 2c0a2fe751..c7b838a628 100644
--- a/include/qemu/bitops.h
+++ b/include/qemu/bitops.h
@@ -18,16 +18,47 @@
 
 #define BITS_PER_BYTE   CHAR_BIT
 #define BITS_PER_LONG   (sizeof (unsigned long) * BITS_PER_BYTE)
+#define BITS_TO_LONGS(nr)   DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
+#define BITS_TO_U32S(nr)DIV_ROUND_UP(nr, BITS_PER_BYTE * 
sizeof(uint32_t))
 
 #define BIT(nr) (1UL << (nr))
 #define BIT_ULL(nr) (1ULL << (nr))
-#define BIT_MASK(nr)(1UL << ((nr) % BITS_PER_LONG))
-#define BIT_WORD(nr)((nr) / BITS_PER_LONG)
-#define BITS_TO_LONGS(nr)   DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
 
 #define MAKE_64BIT_MASK(shift, length) \
 (((~0ULL) >> (64 - (length))) << (shift))
 
+/**
+ * DOC: Functions operating on arrays of bits
+ *
+ * We provide a set of functions which work on arbitrary-length arrays of
+ * bits. These come in several flavours which vary in what the type of the
+ * underlying storage for the bits is:
+ *
+ * - Bits stored in an array of 'unsigned long': set_bit(), clear_bit(), etc
+ * - Bits stored in an array of 'uint32_t': set_bit32(), clear_bit32(), etc
+ *
+ * Because the 'unsigned long' type has a size which varies between
+ * host systems, the versions using 'uint32_t' are often preferable.
+ * This is particularly the case in a device model where there may
+ * be some guest-visible register view of the bit array.
+ *
+ * We do not currently implement uint32_t versions of find_last_bit(),
+ * find_next_bit(), find_next_zero_bit(), find_first_bit() or
+ * find_first_zero_bit(), because we haven't yet needed them. If you
+ * need them you should implement them similarly to the 'unsigned long'
+ * versions.
+ *
+ * You can declare a bitmap to be used with these functions via the
+ * DECLARE_BITMAP and DECLARE_BITMAP32 macros in bitmap.h.
+ */
+
+/**
+ * DOC:  'unsigned long' bit array APIs
+ */
+
+#define BIT_MASK(nr)(1UL << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr)((nr) / BITS_PER_LONG)
+
 /**
  * set_bit - Set a bit in memory
  * @nr: the bit to set
@@ -224,6 +255,141 @@ static inline unsigned long find_first_zero_bit(const 
unsigned long *addr,
 return find_next_zero_bit(addr, size, 0);
 }
 
+/**
+ * DOC:  'uint32_t' bit array APIs
+ */
+
+#define BIT32_MASK(nr)(1UL << ((nr) % 32))
+#define BIT32_WORD(nr)((nr) / 32)
+
+/**
+ * set_bit32 - Set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ */
+static inline void set_bit32(long nr, uint32_t *addr)
+{
+uint32_t mask = BIT32_MASK(nr);
+uint32_t *p = addr + BIT32_WORD(nr);
+
+*p  |= mask;
+}
+
+/**
+ * set_bit32_atomic - Set a bit in memory atomically
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ */
+static inline void set_bit32_atomic(long nr, uint32_t *addr)
+{
+uint32_t mask = BIT32_MASK(nr);
+ui

[Stable-9.1.3 27/58] tcg/riscv: Fix StoreStore barrier generation

2025-01-28 Thread Michael Tokarev
On RISC-V to StoreStore barrier corresponds
`fence w, w` not `fence r, r`

Cc: qemu-sta...@nongnu.org
Fixes: efbea94c76b ("tcg/riscv: Add slowpath load and store instructions")
Reviewed-by: Richard Henderson 
Signed-off-by: Denis Tomashev 
Signed-off-by: Roman Artemev 
Message-ID: 
Signed-off-by: Richard Henderson 
(cherry picked from commit b438362a142527b97b638b7f0f35ebe11911a8d5)
Signed-off-by: Michael Tokarev 

diff --git a/tcg/riscv/tcg-target.c.inc b/tcg/riscv/tcg-target.c.inc
index d334857226..73bbb4cd67 100644
--- a/tcg/riscv/tcg-target.c.inc
+++ b/tcg/riscv/tcg-target.c.inc
@@ -1149,7 +1149,7 @@ static void tcg_out_mb(TCGContext *s, TCGArg a0)
 insn |= 0x0210;
 }
 if (a0 & TCG_MO_ST_ST) {
-insn |= 0x0220;
+insn |= 0x0110;
 }
 tcg_out32(s, insn);
 }
-- 
2.39.5




[Stable-9.1.3 36/58] s390x/s390-virtio-ccw: don't crash on weird RAM sizes

2025-01-28 Thread Michael Tokarev
KVM is not happy when starting a VM with weird RAM sizes:

  # qemu-system-s390x --enable-kvm --nographic -m 1234K
  qemu-system-s390x: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION
failed, slot=0, start=0x0, size=0x244000: Invalid argument
  kvm_set_phys_mem: error registering slot: Invalid argument
  Aborted (core dumped)

Let's handle that in a better way by rejecting such weird RAM sizes
right from the start:

  # qemu-system-s390x --enable-kvm --nographic -m 1234K
  qemu-system-s390x: ram size must be multiples of 1 MiB

Message-ID: <20241219144115.2820241-2-da...@redhat.com>
Acked-by: Michael S. Tsirkin 
Reviewed-by: Eric Farman 
Reviewed-by: Thomas Huth 
Acked-by: Janosch Frank 
Signed-off-by: David Hildenbrand 
(cherry picked from commit 14e568ab4836347481af2e334009c385f456a734)
Signed-off-by: Michael Tokarev 

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index c483ff8064..5b055a8b25 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -180,6 +180,17 @@ static void s390_memory_init(MemoryRegion *ram)
 {
 MemoryRegion *sysmem = get_system_memory();
 
+if (!QEMU_IS_ALIGNED(memory_region_size(ram), 1 * MiB)) {
+/*
+ * SCLP cannot possibly expose smaller granularity right now and KVM
+ * cannot handle smaller granularity. As we don't support NUMA, the
+ * region size directly corresponds to machine->ram_size, and the 
region
+ * is a single RAM memory region.
+ */
+error_report("ram size must be multiples of 1 MiB");
+exit(EXIT_FAILURE);
+}
+
 /* allocate RAM for core */
 memory_region_add_subregion(sysmem, 0, ram);
 
-- 
2.39.5




[Stable-8.2.9 35/45] docs: Correct release of TCG trace-events removal

2025-01-28 Thread Michael Tokarev
TCG trace-events were deprecated before the v6.2 release,
and removed for v7.0.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Alex Bennée 
Reviewed-by: Michael Tokarev 
Signed-off-by: Michael Tokarev 
(cherry picked from commit b4859e8f33a7d9c793a60395f792c10190cb4f78)
Signed-off-by: Michael Tokarev 

diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index f04036987b..82c861d0de 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -787,8 +787,8 @@ reason the maintainers strongly suspected no one actually 
used it.
 TCG introspection features
 --
 
-TCG trace-events (since 6.2)
-
+TCG trace-events (removed in 7.0)
+'
 
 The ability to add new TCG trace points had bit rotted and as the
 feature can be replicated with TCG plugins it was removed. If
-- 
2.39.5




[Stable-8.2.9 41/45] pci/msix: Fix msix pba read vector poll end calculation

2025-01-28 Thread Michael Tokarev
The end vector calculation has a bug that results in polling fewer
than required vectors when reading at a non-zero offset in PBA memory.

Fixes: bbef882cc193 ("msi: add API to get notified about pending bit poll")
Signed-off-by: Nicholas Piggin 
Message-Id: <20241212120402.1475053-1-npig...@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit 42e2a7a0ab23784e44fcb18369e06067abc89305)
Signed-off-by: Michael Tokarev 

diff --git a/hw/pci/msix.c b/hw/pci/msix.c
index cd817f4ca8..057a1305cd 100644
--- a/hw/pci/msix.c
+++ b/hw/pci/msix.c
@@ -250,7 +250,7 @@ static uint64_t msix_pba_mmio_read(void *opaque, hwaddr 
addr,
 PCIDevice *dev = opaque;
 if (dev->msix_vector_poll_notifier) {
 unsigned vector_start = addr * 8;
-unsigned vector_end = MIN(addr + size * 8, dev->msix_entries_nr);
+unsigned vector_end = MIN((addr + size) * 8, dev->msix_entries_nr);
 dev->msix_vector_poll_notifier(dev, vector_start, vector_end);
 }
 
-- 
2.39.5




[Stable-9.1.3 22/58] hw/nvme: take a reference on the subsystem on vf realization

2025-01-28 Thread Michael Tokarev
Make sure we grab a reference on the subsystem when a VF is realized.
Otherwise, the subsytem will be unrealized automatically when the VFs
are unregistered and unreffed.

This fixes a latent bug but was not exposed until commit 08f632848008
("pcie: Release references of virtual functions"). This was then fixed
(or rather, hidden) by commit c613ad25125b ("pcie_sriov: Do not manually
unrealize"), but that was then reverted (due to other issues) in commit
b0fdaee5d1ed, exposing the bug yet again.

Cc: qemu-sta...@nongnu.org
Fixes: 08f632848008 ("pcie: Release references of virtual functions")
Reviewed-by: Jesper Wendel Devantier 
Signed-off-by: Klaus Jensen 
(cherry picked from commit 6651f8f2e5051f6750c2534ab3151339b3c476a2)
Signed-off-by: Michael Tokarev 

diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index fc03a70979..3b5850beda 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -8629,6 +8629,13 @@ static void nvme_realize(PCIDevice *pci_dev, Error 
**errp)
  */
 n->params.serial = g_strdup(pn->params.serial);
 n->subsys = pn->subsys;
+
+/*
+ * Assigning this link (strong link) causes an `object_unref` later in
+ * `object_release_link_property`. Increment the refcount to balance
+ * this out.
+ */
+object_ref(OBJECT(pn->subsys));
 }
 
 if (!nvme_check_params(n, errp)) {
-- 
2.39.5




[Stable-9.1.3 30/58] pc-bios: add missing riscv64 descriptor

2025-01-28 Thread Michael Tokarev
Without descriptor libvirt cannot discover the EDK II binaries via
the qemu:///system connection.

Signed-off-by: Heinrich Schuchardt 
Message-ID: <20241212090059.94167-1-heinrich.schucha...@canonical.com>
Signed-off-by: Gerd Hoffmann 
(cherry picked from commit 74dc38d0c6c15fd57a5dee94125d13ac5b00491d)
Signed-off-by: Michael Tokarev 
(Mjt: context fix in pc-bios/descriptors/meson.build due to missing
 v9.1.0-337-gb883fb93db "roms: Support compile the efi bios for loongarch")

diff --git a/pc-bios/descriptors/60-edk2-riscv64.json 
b/pc-bios/descriptors/60-edk2-riscv64.json
new file mode 100644
index 00..14811ca307
--- /dev/null
+++ b/pc-bios/descriptors/60-edk2-riscv64.json
@@ -0,0 +1,31 @@
+{
+"description": "UEFI firmware for riscv64",
+"interface-types": [
+"uefi"
+],
+"mapping": {
+"device": "flash",
+"executable": {
+"filename": "@DATADIR@/edk2-riscv-code.fd",
+"format": "raw"
+},
+"nvram-template": {
+"filename": "@DATADIR@/edk2-riscv-vars.fd",
+"format": "raw"
+}
+},
+"targets": [
+{
+"architecture": "riscv64",
+"machines": [
+"virt*"
+]
+}
+],
+"features": [
+
+],
+"tags": [
+
+]
+}
diff --git a/pc-bios/descriptors/meson.build b/pc-bios/descriptors/meson.build
index 66f85d01c4..18a584e5e3 100644
--- a/pc-bios/descriptors/meson.build
+++ b/pc-bios/descriptors/meson.build
@@ -5,7 +5,8 @@ if unpack_edk2_blobs and get_option('install_blobs')
 '60-edk2-aarch64.json',
 '60-edk2-arm.json',
 '60-edk2-i386.json',
-'60-edk2-x86_64.json'
+'60-edk2-x86_64.json',
+'60-edk2-riscv64.json'
   ]
 configure_file(input: files(f),
output: f,
-- 
2.39.5




Re: [RFC 2/4] spdm: add spdm storage transport virtual header

2025-01-28 Thread Klaus Jensen
On Jan 15 02:16, Wilfred Mallawa wrote:
> On Fri, 2025-01-10 at 10:04 +0100, Klaus Jensen wrote:
> > On Jan  7 15:29, Wilfred Mallawa via wrote:
> > > This header contains the transport encoding for an SPDM message
> > > that
> > > uses the SPDM over Storage transport as defined by the DMTF
> > > DSP0286.
> > > 
> > > Signed-off-by: Wilfred Mallawa 
> > > ---
> > >  include/system/spdm-socket.h | 12 
> > >  1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/include/system/spdm-socket.h b/include/system/spdm-
> > > socket.h
> > > index 2b7d03f82d..fc007e5b48 100644
> > > --- a/include/system/spdm-socket.h
> > > +++ b/include/system/spdm-socket.h
> > > @@ -88,6 +88,18 @@ bool spdm_socket_send(const int socket, uint32_t
> > > socket_cmd,
> > >   */
> > >  void spdm_socket_close(const int socket, uint32_t transport_type);
> > >  
> > > +/*
> > > + * Defines the transport encoding for SPDM, this information shall
> > > be passed
> > > + * down to the SPDM server, when conforming to the SPDM over
> > > Storage standard
> > > + * as defined by DSP0286.
> > > + */
> > > +typedef struct QEMU_PACKED {
> > > +    uint8_t security_protocol;
> > > +    uint16_t security_protocol_specific;
> > > +    bool inc_512;
> > > +    uint32_t length;
> > > +} StorageSpdmTransportHeader;
> > 
> > Does it make sense to pack a bool? Is this defined by the SPDM server
> > in
> > use? I can't find the definition of this header anywhere.
> > 
> This is essentially a virtual header containing essential storage
> transport data as per DSP0286. For example, this is defined in the
> upstream effort for 
> `libspmd` to add storage binding support [1] and in DSP0286 [2], this
> is defined in section 5.1.1.
> 
> Current implementation of the SPDM server (i.e in `spdm-utils` only one
> to have support for storage), will just pass this header to `libspdm`
> to be decoded. Once decoded by `libspdm`, `spdm-utils`/server will
> contextually check for validity of the message.
> 

OK, understood.

> As for inc_512, it just need to be yes or no, is there a better way to
> represent that here?

It's a byte, right? Then I think using uint8_t is more clear here.


signature.asc
Description: PGP signature


[Stable-7.2.16 26/31] hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec

2025-01-28 Thread Michael Tokarev
QEMU would crash with a failed assertion if the XHCI controller
attempted to raise the interrupt on an interrupter corresponding
to a MSI vector with a higher index than the highest configured
for the device by the guest driver.

This behaviour is correct on the MSI/PCI side: per PCI 3.0 spec,
devices must ensure they do not send MSI notifications for
vectors beyond the range of those allocated by the system/driver
software. Unlike MSI-X, there is no generic way for handling
aliasing in the case of fewer allocated vectors than requested,
so the specifics are up to device implementors. (Section
6.8.3.4. "Sending Messages")

It turns out the XHCI spec (Implementation Note in section 4.17,
"Interrupters") requires that the host controller signal the MSI
vector with the number computed by taking the interrupter number
modulo the number of enabled MSI vectors.

This change introduces that modulo calculation, fixing the
failed assertion. This makes the device work correctly in MSI mode
with macOS's XHCI driver, which only allocates a single vector.

Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Philippe Mathieu-Daudé 
Message-ID: <20250112210056.16658-2-p...@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé 
(cherry picked from commit bb5b7fced6b5d3334ab20702fc846e47bb1fb731)
Signed-off-by: Michael Tokarev 

diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 643d4643e4..560ce582b2 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -74,6 +74,7 @@ static bool xhci_pci_intr_raise(XHCIState *xhci, int n, bool 
level)
 }
 
 if (msi_enabled(pci_dev) && level) {
+n %= msi_nr_vectors_allocated(pci_dev);
 msi_notify(pci_dev, n);
 return true;
 }
-- 
2.39.5




[Stable-8.2.9 38/45] backends/cryptodev-vhost-user: Fix local_error leaks

2025-01-28 Thread Michael Tokarev
Do not propagate error to the upper, directly output the error
to avoid leaks.

Fixes: 2fda101de07 ("virtio-crypto: Support asynchronous mode")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2714
Signed-off-by: Gabriel Barrantes 
Reviewed-by: zhenwei pi 
Message-Id: 

Signed-off-by: Philippe Mathieu-Daudé 
(cherry picked from commit 78b0c15a563ac4be5afb0375602ca0a3adc6c442)
Signed-off-by: Michael Tokarev 

diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c
index c3283ba84a..b8e95ca8b4 100644
--- a/backends/cryptodev-vhost-user.c
+++ b/backends/cryptodev-vhost-user.c
@@ -281,8 +281,7 @@ static int cryptodev_vhost_user_create_session(
 break;
 
 default:
-error_setg(&local_error, "Unsupported opcode :%" PRIu32 "",
-   sess_info->op_code);
+error_report("Unsupported opcode :%" PRIu32 "", sess_info->op_code);
 return -VIRTIO_CRYPTO_NOTSUPP;
 }
 
-- 
2.39.5




[Stable-8.2.9 40/45] pci: ensure valid link status bits for downstream ports

2025-01-28 Thread Michael Tokarev
PCI hotplug for downstream endpoints on arm fails because Linux'
PCIe hotplug driver doesn't like the QEMU provided LNKSTA:

  pcieport :08:01.0: pciehp: Slot(2): Card present
  pcieport :08:01.0: pciehp: Slot(2): Link Up
  pcieport :08:01.0: pciehp: Slot(2): Cannot train link: status 0x2000

There's 2 cases where LNKSTA isn't setup properly:
* the downstream device has no express capability
* max link width of the bridge is 0

Move the sanity checks added via 88c869198aa63
("pci: Sanity test minimum downstream LNKSTA") outside of the
branch to make sure downstream ports always have a valid LNKSTA.

Signed-off-by: Sebastian Ott 
Tested-by: Zhenyu Zhang 
Message-Id: <20241203121928.14861-1-seb...@redhat.com>
Reviewed-by: Alex Williamson 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit 694632fd44987cc4618612a38ad151047524a590)
Signed-off-by: Michael Tokarev 

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 6db0cf69cd..949b2f87f3 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -1016,18 +1016,22 @@ void pcie_sync_bridge_lnk(PCIDevice *bridge_dev)
 if ((lnksta & PCI_EXP_LNKSTA_NLW) > (lnkcap & PCI_EXP_LNKCAP_MLW)) {
 lnksta &= ~PCI_EXP_LNKSTA_NLW;
 lnksta |= lnkcap & PCI_EXP_LNKCAP_MLW;
-} else if (!(lnksta & PCI_EXP_LNKSTA_NLW)) {
-lnksta |= QEMU_PCI_EXP_LNKSTA_NLW(QEMU_PCI_EXP_LNK_X1);
 }
 
 if ((lnksta & PCI_EXP_LNKSTA_CLS) > (lnkcap & PCI_EXP_LNKCAP_SLS)) {
 lnksta &= ~PCI_EXP_LNKSTA_CLS;
 lnksta |= lnkcap & PCI_EXP_LNKCAP_SLS;
-} else if (!(lnksta & PCI_EXP_LNKSTA_CLS)) {
-lnksta |= QEMU_PCI_EXP_LNKSTA_CLS(QEMU_PCI_EXP_LNK_2_5GT);
 }
 }
 
+if (!(lnksta & PCI_EXP_LNKSTA_NLW)) {
+lnksta |= QEMU_PCI_EXP_LNKSTA_NLW(QEMU_PCI_EXP_LNK_X1);
+}
+
+if (!(lnksta & PCI_EXP_LNKSTA_CLS)) {
+lnksta |= QEMU_PCI_EXP_LNKSTA_CLS(QEMU_PCI_EXP_LNK_2_5GT);
+}
+
 pci_word_test_and_clear_mask(exp_cap + PCI_EXP_LNKSTA,
  PCI_EXP_LNKSTA_CLS | PCI_EXP_LNKSTA_NLW);
 pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKSTA, lnksta &
-- 
2.39.5




[Stable-9.1.3 11/58] ppc/spapr: fix drc index mismatch for partially enabled vcpus

2025-01-28 Thread Michael Tokarev
In case when vcpus are explicitly enabled/disabled in a non-consecutive
order within a libvirt xml, it results in a drc index mismatch during
vcpu hotplug later because the existing logic uses vcpu id to derive the
corresponding drc index which is not correct. Use env->core_index to
derive a vcpu's drc index as appropriate to fix this issue.

For ex, for the given libvirt xml config:
  








  

We see below error on guest console with "virsh setvcpus  5" :

pseries-hotplug-cpu: CPU with drc index 1002 already exists

This patch fixes the issue by using correct drc index for explicitly
enabled vcpus during init.

Reported-by: Anushree Mathur 
Tested-by: Anushree Mathur 
Signed-off-by: Harsh Prateek Bora 
Reviewed-by: Nicholas Piggin 
Signed-off-by: Nicholas Piggin 
(cherry picked from commit e8185fdc63e1db1efba695aae568fae8a075a815)
Signed-off-by: Michael Tokarev 

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 370d7c35d3..0307953fe5 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -758,7 +758,7 @@ static void spapr_dt_cpu(CPUState *cs, void *fdt, int 
offset,
 uint32_t radix_AP_encodings[PPC_PAGE_SIZES_MAX_SZ];
 int i;
 
-drc = spapr_drc_by_id(TYPE_SPAPR_DRC_CPU, index);
+drc = spapr_drc_by_id(TYPE_SPAPR_DRC_CPU, env->core_index);
 if (drc) {
 drc_index = spapr_drc_index(drc);
 _FDT((fdt_setprop_cell(fdt, offset, "ibm,my-drc-index", drc_index)));
-- 
2.39.5




[Stable-9.1.3 51/58] backends/cryptodev-vhost-user: Fix local_error leaks

2025-01-28 Thread Michael Tokarev
Do not propagate error to the upper, directly output the error
to avoid leaks.

Fixes: 2fda101de07 ("virtio-crypto: Support asynchronous mode")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2714
Signed-off-by: Gabriel Barrantes 
Reviewed-by: zhenwei pi 
Message-Id: 

Signed-off-by: Philippe Mathieu-Daudé 
(cherry picked from commit 78b0c15a563ac4be5afb0375602ca0a3adc6c442)
Signed-off-by: Michael Tokarev 

diff --git a/backends/cryptodev-vhost-user.c b/backends/cryptodev-vhost-user.c
index c3283ba84a..b8e95ca8b4 100644
--- a/backends/cryptodev-vhost-user.c
+++ b/backends/cryptodev-vhost-user.c
@@ -281,8 +281,7 @@ static int cryptodev_vhost_user_create_session(
 break;
 
 default:
-error_setg(&local_error, "Unsupported opcode :%" PRIu32 "",
-   sess_info->op_code);
+error_report("Unsupported opcode :%" PRIu32 "", sess_info->op_code);
 return -VIRTIO_CRYPTO_NOTSUPP;
 }
 
-- 
2.39.5




[Stable-9.1.3 03/58] hw/intc/loongarch_extioi: Use set_bit32() and clear_bit32() for s->isr

2025-01-28 Thread Michael Tokarev
In extioi_setirq() we try to operate on a bit array stored as an
array of uint32_t using the set_bit() and clear_bit() functions
by casting the pointer to 'unsigned long *'.
This has two problems:
 * the alignment of 'uint32_t' is less than that of 'unsigned long'
   so we pass an insufficiently aligned pointer, which is
   undefined behaviour
 * on big-endian hosts the 64-bit 'unsigned long' will have
   its two halves the wrong way around, and we will produce
   incorrect results

The undefined behaviour is shown by the clang undefined-behaviour
sanitizer when running the loongarch64-virt functional test:

/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:5: runtime 
error: store to misaligned address 0x59745d9c for type 'unsigned long', 
which requires 8 byte alignment
0x59745d9c: note: pointer points here
  ff ff ff ff 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 
00 00 00 00 00 00 00
  ^
#0 0x56fb81c4 in set_bit 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:9
#1 0x56fb81c4 in extioi_setirq 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_extioi.c:65:9
#2 0x56fb6e90 in pch_pic_irq_handler 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_pch_pic.c:75:5
#3 0x56710265 in serial_ioport_write 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/char/serial.c

Fix these problems by using set_bit32() and clear_bit32(),
which work with bit arrays stored as an array of uint32_t.

Cc: qemu-sta...@nongnu.org
Fixes: cbff2db1e92f8759 ("hw/intc: Add LoongArch extioi interrupt 
controller(EIOINTC)")
Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Bibo Mao 
Message-id: 20241108135514.4006953-4-peter.mayd...@linaro.org
(cherry picked from commit 335be5bc44aa6800a9e3ba5859ea3833cfe5a7bc)
Signed-off-by: Michael Tokarev 

diff --git a/hw/intc/loongarch_extioi.c b/hw/intc/loongarch_extioi.c
index 1e8e0114dc..498da96122 100644
--- a/hw/intc/loongarch_extioi.c
+++ b/hw/intc/loongarch_extioi.c
@@ -57,14 +57,9 @@ static void extioi_setirq(void *opaque, int irq, int level)
 LoongArchExtIOI *s = LOONGARCH_EXTIOI(opaque);
 trace_loongarch_extioi_setirq(irq, level);
 if (level) {
-/*
- * s->isr should be used in vmstate structure,
- * but it not support 'unsigned long',
- * so we have to switch it.
- */
-set_bit(irq, (unsigned long *)s->isr);
+set_bit32(irq, s->isr);
 } else {
-clear_bit(irq, (unsigned long *)s->isr);
+clear_bit32(irq, s->isr);
 }
 extioi_update_irq(s, irq, level);
 }
@@ -154,7 +149,7 @@ static inline void extioi_update_sw_coremap(LoongArchExtIOI 
*s, int irq,
 continue;
 }
 
-if (notify && test_bit(irq + i, (unsigned long *)s->isr)) {
+if (notify && test_bit32(irq + i, s->isr)) {
 /*
  * lower irq at old cpu and raise irq at new cpu
  */
-- 
2.39.5




[Stable-8.2.9 39/45] hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec

2025-01-28 Thread Michael Tokarev
QEMU would crash with a failed assertion if the XHCI controller
attempted to raise the interrupt on an interrupter corresponding
to a MSI vector with a higher index than the highest configured
for the device by the guest driver.

This behaviour is correct on the MSI/PCI side: per PCI 3.0 spec,
devices must ensure they do not send MSI notifications for
vectors beyond the range of those allocated by the system/driver
software. Unlike MSI-X, there is no generic way for handling
aliasing in the case of fewer allocated vectors than requested,
so the specifics are up to device implementors. (Section
6.8.3.4. "Sending Messages")

It turns out the XHCI spec (Implementation Note in section 4.17,
"Interrupters") requires that the host controller signal the MSI
vector with the number computed by taking the interrupter number
modulo the number of enabled MSI vectors.

This change introduces that modulo calculation, fixing the
failed assertion. This makes the device work correctly in MSI mode
with macOS's XHCI driver, which only allocates a single vector.

Signed-off-by: Phil Dennis-Jordan 
Reviewed-by: Philippe Mathieu-Daudé 
Message-ID: <20250112210056.16658-2-p...@philjordan.eu>
Signed-off-by: Philippe Mathieu-Daudé 
(cherry picked from commit bb5b7fced6b5d3334ab20702fc846e47bb1fb731)
Signed-off-by: Michael Tokarev 

diff --git a/hw/usb/hcd-xhci-pci.c b/hw/usb/hcd-xhci-pci.c
index 643d4643e4..560ce582b2 100644
--- a/hw/usb/hcd-xhci-pci.c
+++ b/hw/usb/hcd-xhci-pci.c
@@ -74,6 +74,7 @@ static bool xhci_pci_intr_raise(XHCIState *xhci, int n, bool 
level)
 }
 
 if (msi_enabled(pci_dev) && level) {
+n %= msi_nr_vectors_allocated(pci_dev);
 msi_notify(pci_dev, n);
 return true;
 }
-- 
2.39.5




[Stable-9.1.3 54/58] pci/msix: Fix msix pba read vector poll end calculation

2025-01-28 Thread Michael Tokarev
The end vector calculation has a bug that results in polling fewer
than required vectors when reading at a non-zero offset in PBA memory.

Fixes: bbef882cc193 ("msi: add API to get notified about pending bit poll")
Signed-off-by: Nicholas Piggin 
Message-Id: <20241212120402.1475053-1-npig...@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit 42e2a7a0ab23784e44fcb18369e06067abc89305)
Signed-off-by: Michael Tokarev 

diff --git a/hw/pci/msix.c b/hw/pci/msix.c
index 487e49834e..cc6e79ec67 100644
--- a/hw/pci/msix.c
+++ b/hw/pci/msix.c
@@ -250,7 +250,7 @@ static uint64_t msix_pba_mmio_read(void *opaque, hwaddr 
addr,
 PCIDevice *dev = opaque;
 if (dev->msix_vector_poll_notifier) {
 unsigned vector_start = addr * 8;
-unsigned vector_end = MIN(addr + size * 8, dev->msix_entries_nr);
+unsigned vector_end = MIN((addr + size) * 8, dev->msix_entries_nr);
 dev->msix_vector_poll_notifier(dev, vector_start, vector_end);
 }
 
-- 
2.39.5




[Stable-7.2.16 31/31] tests: acpi: update expected blobs

2025-01-28 Thread Michael Tokarev
_DSM function 7 AML should have followig change:

   If ((Arg2 == 0x07))
   {
  -Local0 = Package (0x02)
  -{
  -Zero,
  -""
  -}
   Local2 = AIDX (DerefOf (Arg4 [Zero]), DerefOf (Arg4 [One]
   ))
  -Local0 [Zero] = Local2
  +Local0 = Package (0x02) {}
  +If (!((Local2 == Zero) || (Local2 == 0x)))
  +{
  +Local0 [Zero] = Local2
  +Local0 [One] = ""
  +}
  +
   Return (Local0)
   }
   }

Signed-off-by: Igor Mammedov 
Message-Id: <20250115125342.3883374-4-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit 9fb1c9a1bb26e111ee5fa5538070cd684de14c08)
Signed-off-by: Michael Tokarev 

diff --git a/tests/data/acpi/pc/DSDT b/tests/data/acpi/pc/DSDT
index b688686dc3..246bcadaa7 100644
Binary files a/tests/data/acpi/pc/DSDT and b/tests/data/acpi/pc/DSDT differ
diff --git a/tests/data/acpi/pc/DSDT.acpierst b/tests/data/acpi/pc/DSDT.acpierst
index 86259be9d1..3074cecb6c 100644
Binary files a/tests/data/acpi/pc/DSDT.acpierst and 
b/tests/data/acpi/pc/DSDT.acpierst differ
diff --git a/tests/data/acpi/pc/DSDT.acpihmat b/tests/data/acpi/pc/DSDT.acpihmat
index e2cc2a6fc9..0a32881d58 100644
Binary files a/tests/data/acpi/pc/DSDT.acpihmat and 
b/tests/data/acpi/pc/DSDT.acpihmat differ
diff --git a/tests/data/acpi/pc/DSDT.bridge b/tests/data/acpi/pc/DSDT.bridge
index 75016fd4b7..95c12aa316 100644
Binary files a/tests/data/acpi/pc/DSDT.bridge and 
b/tests/data/acpi/pc/DSDT.bridge differ
diff --git a/tests/data/acpi/pc/DSDT.cphp b/tests/data/acpi/pc/DSDT.cphp
index 53eb0dd7d4..ac40cbc595 100644
Binary files a/tests/data/acpi/pc/DSDT.cphp and b/tests/data/acpi/pc/DSDT.cphp 
differ
diff --git a/tests/data/acpi/pc/DSDT.dimmpxm b/tests/data/acpi/pc/DSDT.dimmpxm
index 9089d994e0..b8b62cf9e9 100644
Binary files a/tests/data/acpi/pc/DSDT.dimmpxm and 
b/tests/data/acpi/pc/DSDT.dimmpxm differ
diff --git a/tests/data/acpi/pc/DSDT.hpbridge b/tests/data/acpi/pc/DSDT.hpbridge
index 86259be9d1..3074cecb6c 100644
Binary files a/tests/data/acpi/pc/DSDT.hpbridge and 
b/tests/data/acpi/pc/DSDT.hpbridge differ
diff --git a/tests/data/acpi/pc/DSDT.ipmikcs b/tests/data/acpi/pc/DSDT.ipmikcs
index 39427103aa..40edcc0f94 100644
Binary files a/tests/data/acpi/pc/DSDT.ipmikcs and 
b/tests/data/acpi/pc/DSDT.ipmikcs differ
diff --git a/tests/data/acpi/pc/DSDT.memhp b/tests/data/acpi/pc/DSDT.memhp
index 987a263339..b2a7fd0dbd 100644
Binary files a/tests/data/acpi/pc/DSDT.memhp and 
b/tests/data/acpi/pc/DSDT.memhp differ
diff --git a/tests/data/acpi/pc/DSDT.nohpet b/tests/data/acpi/pc/DSDT.nohpet
index fc7598b762..713aae4d8a 100644
Binary files a/tests/data/acpi/pc/DSDT.nohpet and 
b/tests/data/acpi/pc/DSDT.nohpet differ
diff --git a/tests/data/acpi/pc/DSDT.numamem b/tests/data/acpi/pc/DSDT.numamem
index 85af400cdb..70b44ec476 100644
Binary files a/tests/data/acpi/pc/DSDT.numamem and 
b/tests/data/acpi/pc/DSDT.numamem differ
diff --git a/tests/data/acpi/pc/DSDT.roothp b/tests/data/acpi/pc/DSDT.roothp
index 545512adfa..1030c94cc5 100644
Binary files a/tests/data/acpi/pc/DSDT.roothp and 
b/tests/data/acpi/pc/DSDT.roothp differ
diff --git a/tests/data/acpi/q35/DSDT b/tests/data/acpi/q35/DSDT
index 2771bcea89..5c2b505163 100644
Binary files a/tests/data/acpi/q35/DSDT and b/tests/data/acpi/q35/DSDT differ
diff --git a/tests/data/acpi/q35/DSDT.acpierst 
b/tests/data/acpi/q35/DSDT.acpierst
index b45abca7c2..1fd50e1c8b 100644
Binary files a/tests/data/acpi/q35/DSDT.acpierst and 
b/tests/data/acpi/q35/DSDT.acpierst differ
diff --git a/tests/data/acpi/q35/DSDT.acpihmat 
b/tests/data/acpi/q35/DSDT.acpihmat
index d90fd4723a..c224736325 100644
Binary files a/tests/data/acpi/q35/DSDT.acpihmat and 
b/tests/data/acpi/q35/DSDT.acpihmat differ
diff --git a/tests/data/acpi/q35/DSDT.acpihmat-noinitiator 
b/tests/data/acpi/q35/DSDT.acpihmat-noinitiator
index 279fafa821..ecdb94cc67 100644
Binary files a/tests/data/acpi/q35/DSDT.acpihmat-noinitiator and 
b/tests/data/acpi/q35/DSDT.acpihmat-noinitiator differ
diff --git a/tests/data/acpi/q35/DSDT.applesmc 
b/tests/data/acpi/q35/DSDT.applesmc
index fdf6d14428..241a02dcf4 100644
Binary files a/tests/data/acpi/q35/DSDT.applesmc and 
b/tests/data/acpi/q35/DSDT.applesmc differ
diff --git a/tests/data/acpi/q35/DSDT.bridge b/tests/data/acpi/q35/DSDT.bridge
index b41a4dddc0..bb41a3c218 100644
Binary files a/tests/data/acpi/q35/DSDT.bridge and 
b/tests/data/acpi/q35/DSDT.bridge differ
diff --git a/tests/data/acpi/q35/DSDT.core-count2 
b/tests/data/acpi/q35/DSDT.core-count2
index 375aceed6b..5e0da94644 100644
Binary files a/tests/data/acpi/q35/DSDT.core-count2 and 
b/tests/data/acpi/q35/DSDT.core-count2 differ
diff --git a/tests/data/acpi/q35/DSDT.cphp b/te

[Stable-9.1.3 41/58] migration: Add more error handling to analyze-migration.py

2025-01-28 Thread Michael Tokarev
The analyze-migration script was seen failing in s390x in misterious
ways. It seems we're reaching the VMSDFieldStruct constructor without
any fields, which would indicate an empty .subsection entry, a
VMSTATE_STRUCT with no fields or a vmsd with no fields. We don't have
any of those, at least not without the unmigratable flag set, so this
should never happen.

Add some debug statements so that we can see what's going on the next
time the issue happens.

Reviewed-by: Peter Xu 
Message-Id: <20250109185249.23952-2-faro...@suse.de>
Signed-off-by: Fabiano Rosas 
(cherry picked from commit 86bee9e0c761a3d0e67c43b44001fd752f894cb0)
Signed-off-by: Michael Tokarev 

diff --git a/scripts/analyze-migration.py b/scripts/analyze-migration.py
index 8a254a5b6a..f2457b1dde 100755
--- a/scripts/analyze-migration.py
+++ b/scripts/analyze-migration.py
@@ -429,6 +429,9 @@ def __init__(self, desc, file):
 super(VMSDFieldStruct, self).__init__(desc, file)
 self.data = collections.OrderedDict()
 
+if 'fields' not in self.desc['struct']:
+raise Exception("No fields in struct. VMSD:\n%s" % self.desc)
+
 # When we see compressed array elements, unfold them here
 new_fields = []
 for field in self.desc['struct']['fields']:
@@ -477,6 +480,10 @@ def read(self):
 raise Exception("Subsection %s not found at offset %x" % ( 
subsection['vmsd_name'], self.file.tell()))
 name = self.file.readstr()
 version_id = self.file.read32()
+
+if not subsection:
+raise Exception("Empty description for subsection: %s" % 
name)
+
 self.data[name] = VMSDSection(self.file, version_id, 
subsection, (name, 0))
 self.data[name].read()
 
@@ -574,10 +581,13 @@ def __init__(self, filename):
 }
 self.filename = filename
 self.vmsd_desc = None
+self.vmsd_json = ""
 
-def read(self, desc_only = False, dump_memory = False, write_memory = 
False):
+def read(self, desc_only = False, dump_memory = False,
+ write_memory = False):
 # Read in the whole file
 file = MigrationFile(self.filename)
+self.vmsd_json = file.read_migration_debug_json()
 
 # File magic
 data = file.read32()
@@ -635,9 +645,11 @@ def read(self, desc_only = False, dump_memory = False, 
write_memory = False):
 file.close()
 
 def load_vmsd_json(self, file):
-vmsd_json = file.read_migration_debug_json()
-self.vmsd_desc = json.loads(vmsd_json, 
object_pairs_hook=collections.OrderedDict)
+self.vmsd_desc = json.loads(self.vmsd_json,
+object_pairs_hook=collections.OrderedDict)
 for device in self.vmsd_desc['devices']:
+if 'fields' not in device:
+raise Exception("vmstate for device %s has no fields" % 
device['name'])
 key = (device['name'], device['instance_id'])
 value = ( VMSDSection, device )
 self.section_classes[key] = value
@@ -666,31 +678,34 @@ def default(self, o):
 
 jsonenc = JSONEncoder(indent=4, separators=(',', ': '))
 
-if args.extract:
-dump = MigrationDump(args.file)
+if not any([args.extract, args.dump == "state", args.dump == "desc"]):
+raise Exception("Please specify either -x, -d state or -d desc")
 
-dump.read(desc_only = True)
-print("desc.json")
-f = open("desc.json", "w")
-f.truncate()
-f.write(jsonenc.encode(dump.vmsd_desc))
-f.close()
-
-dump.read(write_memory = True)
-dict = dump.getDict()
-print("state.json")
-f = open("state.json", "w")
-f.truncate()
-f.write(jsonenc.encode(dict))
-f.close()
-elif args.dump == "state":
-dump = MigrationDump(args.file)
-dump.read(dump_memory = args.memory)
-dict = dump.getDict()
-print(jsonenc.encode(dict))
-elif args.dump == "desc":
+try:
 dump = MigrationDump(args.file)
-dump.read(desc_only = True)
-print(jsonenc.encode(dump.vmsd_desc))
-else:
-raise Exception("Please specify either -x, -d state or -d desc")
+
+if args.extract:
+dump.read(desc_only = True)
+
+print("desc.json")
+f = open("desc.json", "w")
+f.truncate()
+f.write(jsonenc.encode(dump.vmsd_desc))
+f.close()
+
+dump.read(write_memory = True)
+dict = dump.getDict()
+print("state.json")
+f = open("state.json", "w")
+f.truncate()
+f.write(jsonenc.encode(dict))
+f.close()
+elif args.dump == "state":
+dump.read(dump_memory = args.memory)
+dict = dump.getDict()
+print(jsonenc.encode(dict))
+elif args.dump == "desc":
+dump.read(desc_only = True)
+print(jsonenc.encode(dump.vmsd_desc))
+except Exception:
+raise Exception("Full JSON dump:\n%s", dump.vmsd_json)
-- 
2.39.5




[Stable-8.2.9 10/45] tests/9p: add missing Rgetattr response name

2025-01-28 Thread Michael Tokarev
'Tgetattr' 9p request and its 'Rgetattr' response types are already used
by test client, however this response type is yet missing in function
rmessage_name(), so add it.

Fixes: a6821b828404 ("tests/9pfs: compare QIDs in fs_walk_none() test")
Signed-off-by: Christian Schoenebeck 
Reviewed-by: Greg Kurz 
Message-Id: 

(cherry picked from commit 4ec984965079b51a9afce339af75edea6de973a2)
Signed-off-by: Michael Tokarev 

diff --git a/tests/qtest/libqos/virtio-9p-client.c 
b/tests/qtest/libqos/virtio-9p-client.c
index c61632fcd3..98b77db51d 100644
--- a/tests/qtest/libqos/virtio-9p-client.c
+++ b/tests/qtest/libqos/virtio-9p-client.c
@@ -235,6 +235,7 @@ static const char *rmessage_name(uint8_t id)
 id == P9_RMKDIR ? "RMKDIR" :
 id == P9_RLCREATE ? "RLCREATE" :
 id == P9_RSYMLINK ? "RSYMLINK" :
+id == P9_RGETATTR ? "RGETATTR" :
 id == P9_RLINK ? "RLINK" :
 id == P9_RUNLINKAT ? "RUNLINKAT" :
 id == P9_RFLUSH ? "RFLUSH" :
-- 
2.39.5




[Stable-9.1.3 23/58] hw/openrisc/openrisc_sim: keep serial@90000000 as default

2025-01-28 Thread Michael Tokarev
We used to only have a single UART on the platform and it was located at
address 0x9000. When the number of UARTs was increased to 4, the
first UART remained at it's location, but instead of being the first one
to be registered, it became the last.

This caused QEMU to pick 0x9300 as the default UART, which broke
software that hardcoded the address of 0x9000 and expected it's
output to be visible when the user configured only a single console.

This caused regressions[1] in the barebox test suite when updating to a
newer QEMU. As there seems to be no good reason to register the UARTs in
inverse order, let's register them by ascending address, so existing
software can remain oblivious to the additional UART ports.

Changing the order of uart registration alone breaks Linux which
was choosing the UART at 0x9300 as the default for ttyS0.  To fix
Linux we fix three things in the device tree:

 1. Define stdout-path only one time for the first registered UART
instead of incorrectly defining for each UART.
 2. Change the UART alias name from 'uart0' to 'serial0' as almost all
Linux tty drivers look for an alias starting with "serial".
 3. Add the UART nodes so they appear in the final DTB in the
order starting with the lowest address and working upwards.

In summary these changes mean that the QEMU default UART (serial_hd(0))
is now setup where:

 * serial_hd(0) is the lowest-address UART
 * serial_hd(0) is listed first in the DTB
 * serial_hd(0) is the /chosen/stdout-path one
 * the /aliases/serial0 alias points at serial_hd(0)

[1]: 
https://lore.barebox.org/barebox/707e7c50-aad1-4459-8796-0cc54bab3...@pengutronix.de/T/#m5da26e8a799033301489a938b5d5667b81cef6ad

Fixes: 84bda468 ("hw/openrisc: support 4 serial ports in or1ksim")
Cc: qemu-sta...@nongnu.org
Signed-off-by: Ahmad Fatoum 
[stafford: Change to serial0 alias and update change message, reverse
 uart registration order]
Signed-off-by: Stafford Horne 
Reviewed-by: Peter Maydell 
(cherry picked from commit 26dcf2be7e153defa289d20317707af034aca692)
Signed-off-by: Michael Tokarev 

diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c
index bffd6f721f..85032b9313 100644
--- a/hw/openrisc/openrisc_sim.c
+++ b/hw/openrisc/openrisc_sim.c
@@ -250,7 +250,7 @@ static void openrisc_sim_serial_init(Or1ksimState *state, 
hwaddr base,
 void *fdt = state->fdt;
 char *nodename;
 qemu_irq serial_irq;
-char alias[sizeof("uart0")];
+char alias[sizeof("serial0")];
 int i;
 
 if (num_cpus > 1) {
@@ -265,7 +265,7 @@ static void openrisc_sim_serial_init(Or1ksimState *state, 
hwaddr base,
 serial_irq = get_cpu_irq(cpus, 0, irq_pin);
 }
 serial_mm_init(get_system_memory(), base, 0, serial_irq, 115200,
-   serial_hd(OR1KSIM_UART_COUNT - uart_idx - 1),
+   serial_hd(uart_idx),
DEVICE_NATIVE_ENDIAN);
 
 /* Add device tree node for serial. */
@@ -277,10 +277,13 @@ static void openrisc_sim_serial_init(Or1ksimState *state, 
hwaddr base,
 qemu_fdt_setprop_cell(fdt, nodename, "clock-frequency", OR1KSIM_CLK_MHZ);
 qemu_fdt_setprop(fdt, nodename, "big-endian", NULL, 0);
 
-/* The /chosen node is created during fdt creation. */
-qemu_fdt_setprop_string(fdt, "/chosen", "stdout-path", nodename);
-snprintf(alias, sizeof(alias), "uart%d", uart_idx);
+if (uart_idx == 0) {
+/* The /chosen node is created during fdt creation. */
+qemu_fdt_setprop_string(fdt, "/chosen", "stdout-path", nodename);
+}
+snprintf(alias, sizeof(alias), "serial%d", uart_idx);
 qemu_fdt_setprop_string(fdt, "/aliases", alias, nodename);
+
 g_free(nodename);
 }
 
@@ -326,11 +329,22 @@ static void openrisc_sim_init(MachineState *machine)
 smp_cpus, cpus, OR1KSIM_OMPIC_IRQ);
 }
 
-for (n = 0; n < OR1KSIM_UART_COUNT; ++n)
+/*
+ * We create the UART nodes starting with the highest address and
+ * working downwards, because in QEMU the DTB nodes end up in the
+ * DTB in reverse order of creation. Correctly-written guest software
+ * will not care about the node order (it will look at stdout-path
+ * or the alias nodes), but for the benefit of guest software which
+ * just looks for the first UART node in the DTB, make sure the
+ * lowest-address UART (which is QEMU's first serial port) appears
+ * first in the DTB.
+ */
+for (n = OR1KSIM_UART_COUNT - 1; n >= 0; n--) {
 openrisc_sim_serial_init(state, or1ksim_memmap[OR1KSIM_UART].base +
 or1ksim_memmap[OR1KSIM_UART].size * n,
  or1ksim_memmap[OR1KSIM_UART].size,
  smp_cpus, cpus, OR1KSIM_UART_IRQ, n);
+}
 
 load_addr = openrisc_load_kernel(ram_size, kernel_filename,
  &boot_info.bootstrap_pc);
-- 
2.39.5




[Stable-9.1.3 01/58] hw/intc/openpic: Avoid taking address of out-of-bounds array index

2025-01-28 Thread Michael Tokarev
The clang sanitizer complains about the code in the EOI handling
of openpic_cpu_write_internal():

UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 ./build/clang/qemu-system-ppc -M 
mac99,graphics=off -display none -kernel day15/invaders.elf
../../hw/intc/openpic.c:1034:16: runtime error: index -1 out of bounds for type 
'IRQSource[264]' (aka 'struct IRQSource[264]')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
../../hw/intc/openpic.c:1034:16 in

This is because we do
  src = &opp->src[n_IRQ];
when n_IRQ may be -1.  This is in practice harmless because if n_IRQ
is -1 then we don't do anything with the src pointer, but it is
undefined behaviour. (This has been present since this device
was first added to QEMU.)

Rearrange the code so we only do the array index when n_IRQ is not -1.

Cc: qemu-sta...@nongnu.org
Fixes: e9df014c0b ("Implement embedded IRQ controller for PowerPC 6xx/740 & 75")
Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Reviewed-by: Mark Cave-Ayland 
Message-id: 20241105180205.3074071-1-peter.mayd...@linaro.org
(cherry picked from commit 3bf7dcd47a3da0e86a9347ce5b2b5d5a1dcb5857)
Signed-off-by: Michael Tokarev 

diff --git a/hw/intc/openpic.c b/hw/intc/openpic.c
index 9792a11224..b35b1ee6f7 100644
--- a/hw/intc/openpic.c
+++ b/hw/intc/openpic.c
@@ -1032,13 +1032,14 @@ static void openpic_cpu_write_internal(void *opaque, 
hwaddr addr,
 s_IRQ = IRQ_get_next(opp, &dst->servicing);
 /* Check queued interrupts. */
 n_IRQ = IRQ_get_next(opp, &dst->raised);
-src = &opp->src[n_IRQ];
-if (n_IRQ != -1 &&
-(s_IRQ == -1 ||
- IVPR_PRIORITY(src->ivpr) > dst->servicing.priority)) {
-DPRINTF("Raise OpenPIC INT output cpu %d irq %d",
-idx, n_IRQ);
-qemu_irq_raise(opp->dst[idx].irqs[OPENPIC_OUTPUT_INT]);
+if (n_IRQ != -1) {
+src = &opp->src[n_IRQ];
+if (s_IRQ == -1 ||
+IVPR_PRIORITY(src->ivpr) > dst->servicing.priority) {
+DPRINTF("Raise OpenPIC INT output cpu %d irq %d",
+idx, n_IRQ);
+qemu_irq_raise(opp->dst[idx].irqs[OPENPIC_OUTPUT_INT]);
+}
 }
 break;
 default:
-- 
2.39.5




[Stable-9.1.3 24/58] target/riscv: Avoid bad shift in riscv_cpu_do_interrupt()

2025-01-28 Thread Michael Tokarev
In riscv_cpu_do_interrupt() we use the 'cause' value we got out of
cs->exception as a shift value.  However this value can be larger
than 31, which means that "1 << cause" is undefined behaviour,
because we do the shift on an 'int' type.

This causes the undefined behaviour sanitizer to complain
on one of the check-tcg tests:

$ UBSAN_OPTIONS=print_stacktrace=1:abort_on_error=1:halt_on_error=1 
./build/clang/qemu-system-riscv64 -M virt -semihosting -display none -device 
loader,file=build/clang/tests/tcg/riscv64-softmmu/issue1060
../../target/riscv/cpu_helper.c:1805:38: runtime error: shift exponent 63 is 
too large for 32-bit type 'int'
#0 0x55f2dc026703 in riscv_cpu_do_interrupt 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../target/riscv/cpu_helper.c:1805:38
#1 0x55f2dc3d170e in cpu_handle_exception 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../accel/tcg/cpu-exec.c:752:9

In this case cause is RISCV_EXCP_SEMIHOST, which is 0x3f.

Use 1ULL instead to ensure that the shift is in range.

Signed-off-by: Peter Maydell 
Fixes: 1697837ed9 ("target/riscv: Add M-mode virtual interrupt and IRQ 
filtering support.")
Fixes: 40336d5b1d ("target/riscv: Add HS-mode virtual interrupt and IRQ 
filtering support.")
Reviewed-by: Daniel Henrique Barboza 
Reviewed-by: Richard Henderson 
Reviewed-by: Alistair Francis 
Message-ID: <20241128103831.3452572-1-peter.mayd...@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé 
(cherry picked from commit 5311599cdc48337f2f27b1b51a80d46d75b05ed0)
Signed-off-by: Michael Tokarev 

diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 395a1d9140..6e8ce87d74 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1662,10 +1662,10 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 bool async = !!(cs->exception_index & RISCV_EXCP_INT_FLAG);
 target_ulong cause = cs->exception_index & RISCV_EXCP_INT_MASK;
 uint64_t deleg = async ? env->mideleg : env->medeleg;
-bool s_injected = env->mvip & (1 << cause) & env->mvien &&
-!(env->mip & (1 << cause));
-bool vs_injected = env->hvip & (1 << cause) & env->hvien &&
-!(env->mip & (1 << cause));
+bool s_injected = env->mvip & (1ULL << cause) & env->mvien &&
+!(env->mip & (1ULL << cause));
+bool vs_injected = env->hvip & (1ULL << cause) & env->hvien &&
+!(env->mip & (1ULL << cause));
 target_ulong tval = 0;
 target_ulong tinst = 0;
 target_ulong htval = 0;
-- 
2.39.5




[Stable-9.1.3 53/58] pci: ensure valid link status bits for downstream ports

2025-01-28 Thread Michael Tokarev
PCI hotplug for downstream endpoints on arm fails because Linux'
PCIe hotplug driver doesn't like the QEMU provided LNKSTA:

  pcieport :08:01.0: pciehp: Slot(2): Card present
  pcieport :08:01.0: pciehp: Slot(2): Link Up
  pcieport :08:01.0: pciehp: Slot(2): Cannot train link: status 0x2000

There's 2 cases where LNKSTA isn't setup properly:
* the downstream device has no express capability
* max link width of the bridge is 0

Move the sanity checks added via 88c869198aa63
("pci: Sanity test minimum downstream LNKSTA") outside of the
branch to make sure downstream ports always have a valid LNKSTA.

Signed-off-by: Sebastian Ott 
Tested-by: Zhenyu Zhang 
Message-Id: <20241203121928.14861-1-seb...@redhat.com>
Reviewed-by: Alex Williamson 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
(cherry picked from commit 694632fd44987cc4618612a38ad151047524a590)
Signed-off-by: Michael Tokarev 

diff --git a/hw/pci/pcie.c b/hw/pci/pcie.c
index 4b2f0805c6..9cb137c30f 100644
--- a/hw/pci/pcie.c
+++ b/hw/pci/pcie.c
@@ -1080,18 +1080,22 @@ void pcie_sync_bridge_lnk(PCIDevice *bridge_dev)
 if ((lnksta & PCI_EXP_LNKSTA_NLW) > (lnkcap & PCI_EXP_LNKCAP_MLW)) {
 lnksta &= ~PCI_EXP_LNKSTA_NLW;
 lnksta |= lnkcap & PCI_EXP_LNKCAP_MLW;
-} else if (!(lnksta & PCI_EXP_LNKSTA_NLW)) {
-lnksta |= QEMU_PCI_EXP_LNKSTA_NLW(QEMU_PCI_EXP_LNK_X1);
 }
 
 if ((lnksta & PCI_EXP_LNKSTA_CLS) > (lnkcap & PCI_EXP_LNKCAP_SLS)) {
 lnksta &= ~PCI_EXP_LNKSTA_CLS;
 lnksta |= lnkcap & PCI_EXP_LNKCAP_SLS;
-} else if (!(lnksta & PCI_EXP_LNKSTA_CLS)) {
-lnksta |= QEMU_PCI_EXP_LNKSTA_CLS(QEMU_PCI_EXP_LNK_2_5GT);
 }
 }
 
+if (!(lnksta & PCI_EXP_LNKSTA_NLW)) {
+lnksta |= QEMU_PCI_EXP_LNKSTA_NLW(QEMU_PCI_EXP_LNK_X1);
+}
+
+if (!(lnksta & PCI_EXP_LNKSTA_CLS)) {
+lnksta |= QEMU_PCI_EXP_LNKSTA_CLS(QEMU_PCI_EXP_LNK_2_5GT);
+}
+
 pci_word_test_and_clear_mask(exp_cap + PCI_EXP_LNKSTA,
  PCI_EXP_LNKSTA_CLS | PCI_EXP_LNKSTA_NLW);
 pci_word_test_and_set_mask(exp_cap + PCI_EXP_LNKSTA, lnksta &
-- 
2.39.5




[Stable-9.1.3 21/58] hw/nvme: fix msix_uninit with exclusive bar

2025-01-28 Thread Michael Tokarev
Commit fa905f65c554 introduced a machine compatibility parameter to
enable an exclusive bar for msix. It failed to account for this when
cleaning up. Make sure that if an exclusive bar is enabled, we use the
proper cleanup routine.

Cc: qemu-sta...@nongnu.org
Fixes: fa905f65c554 ("hw/nvme: add machine compatibility parameter to enable 
msix exclusive bar")
Reviewed-by: Jesper Wendel Devantier 
Signed-off-by: Klaus Jensen 
(cherry picked from commit 9162f101257639cc4c7e20f72f77268b1256dd79)
Signed-off-by: Michael Tokarev 

diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index fe822f63b3..fc03a70979 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -8699,7 +8699,12 @@ static void nvme_exit(PCIDevice *pci_dev)
 pcie_sriov_pf_exit(pci_dev);
 }
 
-msix_uninit(pci_dev, &n->bar0, &n->bar0);
+if (n->params.msix_exclusive_bar && !pci_is_vf(pci_dev)) {
+msix_uninit_exclusive_bar(pci_dev);
+} else {
+msix_uninit(pci_dev, &n->bar0, &n->bar0);
+}
+
 memory_region_del_subregion(&n->bar0, &n->iomem);
 }
 
-- 
2.39.5




[Stable-9.1.3 40/58] target/i386/cpu: Fix notes for CPU models

2025-01-28 Thread Michael Tokarev
Fixes: 644e3c5d812 ("missing vmx features for Skylake-Server and 
Cascadelake-Server")
Signed-off-by: Han Han 
Reviewed-by: Chenyi Qiang 
Reviewed-by: Michael Tokarev 
Signed-off-by: Michael Tokarev 
(cherry picked from commit 93dcc9390e5ad0696ae7e9b7b3a5b08c2d1b6de6)
Signed-off-by: Michael Tokarev 

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 85ef7452c0..5494250bf8 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -3623,6 +3623,7 @@ static const X86CPUDefinition builtin_x86_defs[] = {
 },
 {
 .version = 4,
+.note = "IBRS, EPT switching, no TSX",
 .props = (PropValue[]) {
 { "vmx-eptp-switching", "on" },
 { /* end of list */ }
@@ -3757,7 +3758,7 @@ static const X86CPUDefinition builtin_x86_defs[] = {
   },
 },
 { .version = 4,
-  .note = "ARCH_CAPABILITIES, no TSX",
+  .note = "ARCH_CAPABILITIES, EPT switching, no TSX",
   .props = (PropValue[]) {
   { "vmx-eptp-switching", "on" },
   { /* end of list */ }
-- 
2.39.5




Re: [PATCH 0/1] meson: Deprecate 32-bit host systems

2025-01-28 Thread Daniel P . Berrangé
On Tue, Jan 28, 2025 at 09:02:48AM +, Alex Bennée wrote:
> Thomas Huth  writes:
> 
> > On 28/01/2025 01.42, Richard Henderson wrote:
> >> Time for our biennial attempt to kill ancient hosts.
> >> I've been re-working the tcg code generator a bit over the holidays.
> >> One place that screams for a bit of cleanup is with 64-bit guest
> >> addresses on 32-bit hosts.  Of course the best "cleanup" is to not
> >> have to handle such silliness at all.
> >> Two years after Thomas' last attempt,
> >>
> >> https://lore.kernel.org/qemu-devel/20230130114428.1297295-1-th...@redhat.com/
> >> which resulted only in deprecation of i686 host for system
> >> emulation.
> >> By itself, this just isn't enough for large-scale cleanups.
> >> I'll note that we've separately deprecated mips32, set to expire
> >> with the end of Debian bookworm, set to enter LTS in June 2026.
> >> I'll note that there is *already* no Debian support for ppc32,
> >> and that I am currently unable to cross-compile that host at all.
> >
> > IIRC the biggest pushback that I got two years ago was with regards to
> > 32-bit arm: The recommended version of Raspberry Pi OS is still
> > 32-bit:
> >
> >  
> > https://lore.kernel.org/qemu-devel/f852c238-77b8-4e24-9494-8d060eb78...@livius.net/
> >
> > And looking at https://www.raspberrypi.com/software/operating-systems/
> > this still seems to be the case...
> >
> > So I guess the main question is now: Would it be ok to kill support
> > for 32-bit Raspberry Pi OS nowadays?
> 
> I would argue yes for a few reasons.
> 
>   - you can't buy 32 bit only Pi's AFAICT, even the Pi Zero 2W can work
> with a 64 bit OS.
> 
>   - It's not like the versions shipping in bullseye and bookworm will
> stop working.
> 
>   - Even if we deprecate now there will likely be one more Debian
> release cycle that gets 32 bit host support.
> 
> >> Showing my hand a bit, I am willing to limit deprecation to
> >> 64-bit guests on 32-bit hosts.  But I'd prefer to go the whole hog:
> >> unconditional support for TCG_TYPE_I64 would remove a *lot* of
> >> 32-bit fallback code.
> 
> I support going the whole hog. I would be curious what use cases still
> exist for an up to date 32-on-32 QEMU based emulation?

Last time we discussed this, we distinguished between system emulation
and linux-user. I believe Richard is proposing to deprecated *both*,
but lets call that out explicitly in any deprecation message to avoid
mis-understandings.

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




Re: [PATCH 2/2] plugin: extend API with qemu_plugin_tb_size

2025-01-28 Thread Alex Bennée
Luke Craig  writes:

> ---
>  include/qemu/qemu-plugin.h | 10 ++
>  plugins/api.c  |  5 +
>  2 files changed, 15 insertions(+)
>
> diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
> index a1c478c54f..1fa656da82 100644
> --- a/include/qemu/qemu-plugin.h
> +++ b/include/qemu/qemu-plugin.h
> @@ -476,6 +476,16 @@ void qemu_plugin_register_vcpu_insn_exec_inline_per_vcpu(
>  QEMU_PLUGIN_API
>  size_t qemu_plugin_tb_n_insns(const struct qemu_plugin_tb *tb);
>  
> +/**
> + * qemu_plugin_tb_size() - query helper for size of TB
> + * @tb: opaque handle to TB passed to callback
> + * 
> + * Returns: size of block in bytes
> + */
> +
> +QEMU_PLUGIN_API
> +size_t qemu_plugin_tb_size(const struct qemu_plugin_tb *tb);
> +
>  /**
>   * qemu_plugin_tb_vaddr() - query helper for vaddr of TB start
>   * @tb: opaque handle to TB passed to callback
> diff --git a/plugins/api.c b/plugins/api.c
> index 7ff5e1c1bd..177f0ac9b6 100644
> --- a/plugins/api.c
> +++ b/plugins/api.c
> @@ -241,6 +241,11 @@ size_t qemu_plugin_tb_n_insns(const struct 
> qemu_plugin_tb *tb)
>  return tb->n;
>  }
>  
> +size_t qemu_plugin_tb_size(const struct qemu_plugin_tb *tb){
> +const DisasContextBase *db = tcg_ctx->plugin_db;
> +return db->size;
> +}
> +

FAILED: libqemu-aarch64-linux-user.a.p/plugins_api.c.o 
cc -m64 -Ilibqemu-aarch64-linux-user.a.p -I. -I../.. -Itarget/arm 
-I../../target/arm -I../../common-user/host/x86_64 
-I../../linux-user/include/host/x86_64 -I../../linux-user/include -Ilinux-user 
-I../../linux-user -Ilinux-user/aarch64 -I../../linux-user/aarch64 -Iqapi 
-Itrace -Iui -Iui/shader -I/usr/include/capstone -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fdiagnostics-color=auto -Wall 
-Winvalid-pch -Werror -std=gnu11 -O2 -g -fstack-protector-strong -Wempty-body 
-Wendif-labels -Wexpansion-to-defined -Wformat-security -Wformat-y2k 
-Wignored-qualifiers -Wimplicit-fallthrough=2 -Winit-self 
-Wmissing-format-attribute -Wmissing-prototypes -Wnested-externs 
-Wold-style-declaration -Wold-style-definition -Wredundant-decls -Wshadow=local 
-Wstrict-prototypes -Wtype-limits -Wundef -Wvla -Wwrite-strings 
-Wno-missing-include-dirs -Wno-psabi -Wno-shift-negative-value -isystem 
/home/alex/lsrc/qemu.git/linux-headers -isystem linux-headers -iquote . -iquote 
/home/alex/lsrc/qemu.git -iquote /home/alex/lsrc/qemu.git/include -iquote 
/home/alex/lsrc/qemu.git/host/include/x86_64 -iquote 
/home/alex/lsrc/qemu.git/host/include/generic -iquote 
/home/alex/lsrc/qemu.git/tcg/i386 -pthread -mcx16 -msse2 -D_GNU_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common 
-fwrapv -ftrivial-auto-var-init=zero -fzero-call-used-regs=used-gpr -fPIE 
-isystem../../linux-headers -isystemlinux-headers -DCOMPILING_PER_TARGET 
'-DCONFIG_TARGET="aarch64-linux-user-config-target.h"' -MD -MQ 
libqemu-aarch64-linux-user.a.p/plugins_api.c.o -MF 
libqemu-aarch64-linux-user.a.p/plugins_api.c.o.d -o 
libqemu-aarch64-linux-user.a.p/plugins_api.c.o -c ../../plugins/api.c
../../plugins/api.c: In function ‘qemu_plugin_tb_size’:
../../plugins/api.c:246:14: error: ‘DisasContextBase’ has no member named ‘size’
  246 | return db->size;
  |  ^~

But the general comment is this is an example of tying the plugin API
too deeply with the internals of the translator. Why does a plugin need
to know what is an implementation detail?

>  uint64_t qemu_plugin_tb_vaddr(const struct qemu_plugin_tb *tb)
>  {
>  const DisasContextBase *db = tcg_ctx->plugin_db;

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



[Stable-8.2.9 29/45] roms: re-add edk2-basetools target

2025-01-28 Thread Michael Tokarev
Needed to build ipxe nic roms.

Reported-by: Liu Jaloo 
Fixes: 22e11539e167 ("edk2: replace build scripts")
Signed-off-by: Gerd Hoffmann 
Message-ID: <20241212084408.1390728-1-kra...@redhat.com>
(cherry picked from commit 0f5715e4b5706b31b3550d8e6b88871e029c7823)
Signed-off-by: Michael Tokarev 

diff --git a/roms/Makefile b/roms/Makefile
index 3caae36bbb..cd454cd9a4 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -156,6 +156,11 @@ edk2-version: edk2
touch $@; \
fi
 
+edk2-basetools: edk2-version
+   $(PYTHON) edk2-build.py --config edk2-build.config \
+   --silent --no-logs \
+   --match none # build only basetools
+
 efi: edk2-version
$(PYTHON) edk2-build.py --config edk2-build.config \
--version-override "$(EDK2_STABLE)-for-qemu" \
-- 
2.39.5




Re: [PATCH 0/9] hw/sysbus/platform-bus: Introduce TYPE_DYNAMIC_SYS_BUS_DEVICE

2025-01-28 Thread Gerd Hoffmann
On Sat, Jan 25, 2025 at 07:13:34PM +0100, Philippe Mathieu-Daudé wrote:
> Some SysBus devices can optionally be dynamically plugged onto
> the sysbus-platform-bus (then virtual guests are aware of
> mmio mapping and IRQs via device tree / ACPI rules).

Do we have some sane way to have user-pluggable sysbus devices on arm?

I've played around with that a bit, with the uefi variable service I'm
working on.  Specifically I'd prefer to *not* have a patch wiring things
up in machine type code like this ...

https://lore.kernel.org/qemu-devel/20250107153353.1144978-20-kra...@redhat.com/

... and just use 'qemu -device uefi-vars-sysbus' instead.

Something like AcpiDevAmlIfClass but for device tree seems to not exist
though.  Also apparently AcpiDevAmlIfClass is not used.

take care,
  Gerd




[PATCH 02/11] hw/sd/omap_mmc: Convert remaining 'struct omap_mmc_s' uses to OMAPMMCState

2025-01-28 Thread Peter Maydell
Mechanically convert the remaining uses of 'struct omap_mmc_s' to
'OMAPMMCState'.

Signed-off-by: Peter Maydell 
---
 include/hw/arm/omap.h |  2 +-
 hw/sd/omap_mmc.c  | 20 ++--
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/include/hw/arm/omap.h b/include/hw/arm/omap.h
index 6339c5a581e..7d1a1afc4f8 100644
--- a/include/hw/arm/omap.h
+++ b/include/hw/arm/omap.h
@@ -530,7 +530,7 @@ struct omap_lcd_panel_s *omap_lcdc_init(MemoryRegion 
*sysmem,
 
 /* omap_mmc.c */
 #define TYPE_OMAP_MMC "omap-mmc"
-OBJECT_DECLARE_SIMPLE_TYPE(omap_mmc_s, OMAP_MMC)
+OBJECT_DECLARE_SIMPLE_TYPE(OMAPMMCState, OMAP_MMC)
 
 DeviceState *omap_mmc_init(hwaddr base,
MemoryRegion *sysmem,
diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c
index 9cba437f74e..dd45abc075e 100644
--- a/hw/sd/omap_mmc.c
+++ b/hw/sd/omap_mmc.c
@@ -27,7 +27,7 @@
 #include "hw/arm/omap.h"
 #include "hw/sd/sdcard_legacy.h"
 
-typedef struct omap_mmc_s {
+typedef struct OMAPMMCState {
 SysBusDevice parent_obj;
 
 qemu_irq irq;
@@ -72,12 +72,12 @@ typedef struct omap_mmc_s {
 qemu_irq cdet;
 } OMAPMMCState;
 
-static void omap_mmc_interrupts_update(struct omap_mmc_s *s)
+static void omap_mmc_interrupts_update(OMAPMMCState *s)
 {
 qemu_set_irq(s->irq, !!(s->status & s->mask));
 }
 
-static void omap_mmc_fifolevel_update(struct omap_mmc_s *host)
+static void omap_mmc_fifolevel_update(OMAPMMCState *host)
 {
 if (!host->transfer && !host->fifo_len) {
 host->status &= 0xf3ff;
@@ -125,7 +125,7 @@ typedef enum {
 SD_TYPE_ADTC = 3,   /* addressed with data transfer */
 } MMCCmdType;
 
-static void omap_mmc_command(struct omap_mmc_s *host, int cmd, int dir,
+static void omap_mmc_command(OMAPMMCState *host, int cmd, int dir,
  MMCCmdType type, int busy,
  sd_rsp_type_t resptype, int init)
 {
@@ -234,7 +234,7 @@ static void omap_mmc_command(struct omap_mmc_s *host, int 
cmd, int dir,
 host->status |= 0x0001;
 }
 
-static void omap_mmc_transfer(struct omap_mmc_s *host)
+static void omap_mmc_transfer(OMAPMMCState *host)
 {
 uint8_t value;
 
@@ -289,19 +289,19 @@ static void omap_mmc_transfer(struct omap_mmc_s *host)
 
 static void omap_mmc_update(void *opaque)
 {
-struct omap_mmc_s *s = opaque;
+OMAPMMCState *s = opaque;
 omap_mmc_transfer(s);
 omap_mmc_fifolevel_update(s);
 omap_mmc_interrupts_update(s);
 }
 
-static void omap_mmc_pseudo_reset(struct omap_mmc_s *host)
+static void omap_mmc_pseudo_reset(OMAPMMCState *host)
 {
 host->status = 0;
 host->fifo_len = 0;
 }
 
-static void omap_mmc_reset(struct omap_mmc_s *host)
+static void omap_mmc_reset(OMAPMMCState *host)
 {
 host->last_cmd = 0;
 memset(host->rsp, 0, sizeof(host->rsp));
@@ -340,7 +340,7 @@ static void omap_mmc_reset(struct omap_mmc_s *host)
 static uint64_t omap_mmc_read(void *opaque, hwaddr offset, unsigned size)
 {
 uint16_t i;
-struct omap_mmc_s *s = opaque;
+OMAPMMCState *s = opaque;
 
 if (size != 2) {
 return omap_badwidth_read16(opaque, offset);
@@ -433,7 +433,7 @@ static void omap_mmc_write(void *opaque, hwaddr offset,
uint64_t value, unsigned size)
 {
 int i;
-struct omap_mmc_s *s = opaque;
+OMAPMMCState *s = opaque;
 
 if (size != 2) {
 omap_badwidth_write16(opaque, offset, value);
-- 
2.34.1




[PATCH 06/11] hw/arm/omap1: Inline creation of MMC

2025-01-28 Thread Peter Maydell
Our style for other conversions of OMAP devices to qdev has been to
inline the creation and wiring into omap310_mpu_init() -- see for
instance the handling of omap-intc, omap-gpio and omap_i2c. Do
the same for omap-mmc.

Signed-off-by: Peter Maydell 
---
 hw/arm/omap1.c   | 15 +++
 hw/sd/omap_mmc.c | 22 --
 2 files changed, 11 insertions(+), 26 deletions(-)

diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c
index 15ba0a0d0c4..ca2eb0d1576 100644
--- a/hw/arm/omap1.c
+++ b/hw/arm/omap1.c
@@ -3981,10 +3981,17 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion 
*dram,
 if (!dinfo && !qtest_enabled()) {
 warn_report("missing SecureDigital device");
 }
-s->mmc = omap_mmc_init(0xfffb7800, system_memory,
-   qdev_get_gpio_in(s->ih[1], OMAP_INT_OQN),
-   &s->drq[OMAP_DMA_MMC_TX],
-omap_findclk(s, "mmc_ck"));
+
+s->mmc = qdev_new(TYPE_OMAP_MMC);
+sysbus_realize_and_unref(SYS_BUS_DEVICE(s->mmc), &error_fatal);
+omap_mmc_set_clk(s->mmc, omap_findclk(s, "mmc_ck"));
+
+memory_region_add_subregion(system_memory, 0xfffb7800,
+sysbus_mmio_get_region(SYS_BUS_DEVICE(s->mmc), 
0));
+qdev_connect_gpio_out_named(s->mmc, "dma-tx", 0, s->drq[OMAP_DMA_MMC_TX]);
+qdev_connect_gpio_out_named(s->mmc, "dma-rx", 0, s->drq[OMAP_DMA_MMC_RX]);
+sysbus_connect_irq(SYS_BUS_DEVICE(s->mmc), 0,
+   qdev_get_gpio_in(s->ih[1], OMAP_INT_OQN));
 
 if (dinfo) {
 DeviceState *card = qdev_new(TYPE_SD_CARD);
diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c
index fcec2899afb..dacbea13aad 100644
--- a/hw/sd/omap_mmc.c
+++ b/hw/sd/omap_mmc.c
@@ -590,28 +590,6 @@ void omap_mmc_set_clk(DeviceState *dev, omap_clk clk)
 s->clk = clk;
 }
 
-DeviceState *omap_mmc_init(hwaddr base,
-   MemoryRegion *sysmem,
-   qemu_irq irq, qemu_irq dma[], omap_clk clk)
-{
-DeviceState *dev;
-OMAPMMCState *s;
-
-dev = qdev_new(TYPE_OMAP_MMC);
-s = OMAP_MMC(dev);
-sysbus_realize_and_unref(SYS_BUS_DEVICE(s), &error_fatal);
-
-omap_mmc_set_clk(dev, clk);
-
-memory_region_add_subregion(sysmem, base,
-sysbus_mmio_get_region(SYS_BUS_DEVICE(s), 0));
-qdev_connect_gpio_out_named(dev, "dma-tx", 0, dma[0]);
-qdev_connect_gpio_out_named(dev, "dma-rx", 0, dma[1]);
-sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, irq);
-
-return dev;
-}
-
 static void omap_mmc_reset_hold(Object *obj, ResetType type)
 {
 OMAPMMCState *s = OMAP_MMC(obj);
-- 
2.34.1




[PATCH 01/11] hw/sd/omap_mmc: Do a minimal conversion to QDev

2025-01-28 Thread Peter Maydell
Do a minimal conversion of the omap_mmc device model to QDev.

In this commit we do the bare minimum to produce a working device:
 * add the SysBusDevice parent_obj and the usual type boilerplate
 * omap_mmc_init() now returns a DeviceState*
 * reset is handled by sysbus reset, so the SoC reset function
   doesn't need to call omap_mmc_reset() any more
 * code that should obviously be in init/realize is moved there
   from omap_mmc_init()

We leave various pieces of cleanup to later commits:
 * rationalizing 'struct omap_mmc_s *' to 'OMAPMMCState *'
 * using gpio lines rather than having omap_mmc_init() directly
   set s->irq, s->dma
 * switching away from the legacy SD API and instead having
   the SD card plugged into a bus

Signed-off-by: Peter Maydell 
---
 include/hw/arm/omap.h | 15 
 hw/arm/omap1.c|  1 -
 hw/sd/omap_mmc.c  | 83 +++
 3 files changed, 76 insertions(+), 23 deletions(-)

diff --git a/include/hw/arm/omap.h b/include/hw/arm/omap.h
index 420ed1d5735..6339c5a581e 100644
--- a/include/hw/arm/omap.h
+++ b/include/hw/arm/omap.h
@@ -529,12 +529,13 @@ struct omap_lcd_panel_s *omap_lcdc_init(MemoryRegion 
*sysmem,
 omap_clk clk);
 
 /* omap_mmc.c */
-struct omap_mmc_s;
-struct omap_mmc_s *omap_mmc_init(hwaddr base,
-MemoryRegion *sysmem,
-BlockBackend *blk,
-qemu_irq irq, qemu_irq dma[], omap_clk clk);
-void omap_mmc_reset(struct omap_mmc_s *s);
+#define TYPE_OMAP_MMC "omap-mmc"
+OBJECT_DECLARE_SIMPLE_TYPE(omap_mmc_s, OMAP_MMC)
+
+DeviceState *omap_mmc_init(hwaddr base,
+   MemoryRegion *sysmem,
+   BlockBackend *blk,
+   qemu_irq irq, qemu_irq dma[], omap_clk clk);
 
 /* omap_i2c.c */
 I2CBus *omap_i2c_bus(DeviceState *omap_i2c);
@@ -601,7 +602,7 @@ struct omap_mpu_state_s {
 /* MPU public TIPB peripherals */
 struct omap_32khz_timer_s *os_timer;
 
-struct omap_mmc_s *mmc;
+DeviceState *mmc;
 
 struct omap_mpuio_s *mpuio;
 
diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c
index f3a0ac40e48..ea07b9aa31e 100644
--- a/hw/arm/omap1.c
+++ b/hw/arm/omap1.c
@@ -3716,7 +3716,6 @@ static void omap1_mpu_reset(void *opaque)
 omap_uart_reset(mpu->uart[0]);
 omap_uart_reset(mpu->uart[1]);
 omap_uart_reset(mpu->uart[2]);
-omap_mmc_reset(mpu->mmc);
 omap_mpuio_reset(mpu->mpuio);
 omap_uwire_reset(mpu->microwire);
 omap_pwl_reset(mpu->pwl);
diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c
index 1d4e30e6b7b..9cba437f74e 100644
--- a/hw/sd/omap_mmc.c
+++ b/hw/sd/omap_mmc.c
@@ -21,11 +21,15 @@
 
 #include "qemu/osdep.h"
 #include "qemu/log.h"
+#include "qapi/error.h"
 #include "hw/irq.h"
+#include "hw/sysbus.h"
 #include "hw/arm/omap.h"
 #include "hw/sd/sdcard_legacy.h"
 
-struct omap_mmc_s {
+typedef struct omap_mmc_s {
+SysBusDevice parent_obj;
+
 qemu_irq irq;
 qemu_irq *dma;
 qemu_irq coverswitch;
@@ -66,7 +70,7 @@ struct omap_mmc_s {
 int cdet_enable;
 int cdet_state;
 qemu_irq cdet;
-};
+} OMAPMMCState;
 
 static void omap_mmc_interrupts_update(struct omap_mmc_s *s)
 {
@@ -297,7 +301,7 @@ static void omap_mmc_pseudo_reset(struct omap_mmc_s *host)
 host->fifo_len = 0;
 }
 
-void omap_mmc_reset(struct omap_mmc_s *host)
+static void omap_mmc_reset(struct omap_mmc_s *host)
 {
 host->last_cmd = 0;
 memset(host->rsp, 0, sizeof(host->rsp));
@@ -328,7 +332,9 @@ void omap_mmc_reset(struct omap_mmc_s *host)
  * into any bus, and we must reset it manually. When omap_mmc is
  * QOMified this must move into the QOM reset function.
  */
-device_cold_reset(DEVICE(host->card));
+if (host->card) {
+device_cold_reset(DEVICE(host->card));
+}
 }
 
 static uint64_t omap_mmc_read(void *opaque, hwaddr offset, unsigned size)
@@ -583,29 +589,76 @@ static const MemoryRegionOps omap_mmc_ops = {
 .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
-struct omap_mmc_s *omap_mmc_init(hwaddr base,
-MemoryRegion *sysmem,
-BlockBackend *blk,
-qemu_irq irq, qemu_irq dma[], omap_clk clk)
+DeviceState *omap_mmc_init(hwaddr base,
+   MemoryRegion *sysmem,
+   BlockBackend *blk,
+   qemu_irq irq, qemu_irq dma[], omap_clk clk)
 {
-struct omap_mmc_s *s = g_new0(struct omap_mmc_s, 1);
+DeviceState *dev;
+OMAPMMCState *s;
+
+dev = qdev_new(TYPE_OMAP_MMC);
+s = OMAP_MMC(dev);
+sysbus_realize_and_unref(SYS_BUS_DEVICE(s), &error_fatal);
 
 s->irq = irq;
 s->dma = dma;
 s->clk = clk;
-s->lines = 1;  /* TODO: needs to be settable per-board */
-s->rev = 1;
 
-memory_region_init_io(&s->iomem, NULL, &omap_mmc_ops, s, "omap.mmc", 
0x800);
-memory_region_add_subregion(sysmem, base, &s->iomem);
+memory_region_add_subregion(sysmem, base,
+

[PATCH 10/11] hw/sd: Remove unused legacy functions, stop killing mammoths

2025-01-28 Thread Peter Maydell
The sdcard_legacy.h header defines function prototypes for the "legacy"
SD card API, which was used by non-qdevified SD controller models.
We've now converted the only remaining non-qdev SD controller, so
we can drop the legacy API.

Entirely unused functions:
  sd_init(), sd_set_cb(), sd_enable()

Functions which now become static inside sd.c (they are the
underlying implementations of methods on SDCardClass):
  sd_do_command(), sd_write_byte(), sd_read_byte()

Removal of sd_init() means that we can also remove the
me_no_qdev_me_kill_mammoth_with_rocks flag, the codepaths that were
only reachable when it was set, and the inserted_cb and readonly_cb
qemu_irq lines that went with that.

Signed-off-by: Peter Maydell 
---
 include/hw/sd/sdcard_legacy.h | 50 ---
 hw/sd/omap_mmc.c  |  2 +-
 hw/sd/sd.c| 77 ---
 3 files changed, 9 insertions(+), 120 deletions(-)
 delete mode 100644 include/hw/sd/sdcard_legacy.h

diff --git a/include/hw/sd/sdcard_legacy.h b/include/hw/sd/sdcard_legacy.h
deleted file mode 100644
index 0dc38895551..000
--- a/include/hw/sd/sdcard_legacy.h
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
- * SD Memory Card emulation (deprecated legacy API)
- *
- * Copyright (c) 2006 Andrzej Zaborowski  
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the following disclaimer in
- *the documentation and/or other materials provided with the
- *distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS''
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
- * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
- * PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR
- * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
- * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
- * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
- * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
- * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-#ifndef HW_SDCARD_LEGACY_H
-#define HW_SDCARD_LEGACY_H
-
-#include "hw/sd/sd.h"
-
-/* Legacy functions to be used only by non-qdevified callers */
-SDState *sd_init(BlockBackend *blk, bool is_spi);
-int sd_do_command(SDState *card, SDRequest *request, uint8_t *response);
-void sd_write_byte(SDState *card, uint8_t value);
-uint8_t sd_read_byte(SDState *card);
-void sd_set_cb(SDState *card, qemu_irq readonly, qemu_irq insert);
-
-/* sd_enable should not be used -- it is only used on the nseries boards,
- * where it is part of a broken implementation of the MMC card slot switch
- * (there should be two card slots which are multiplexed to a single MMC
- * controller, but instead we model it with one card and controller and
- * disable the card when the second slot is selected, so it looks like the
- * second slot is always empty).
- */
-void sd_enable(SDState *card, bool enable);
-
-#endif /* HW_SDCARD_LEGACY_H */
diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c
index c1598135f44..d31456ad236 100644
--- a/hw/sd/omap_mmc.c
+++ b/hw/sd/omap_mmc.c
@@ -25,7 +25,7 @@
 #include "hw/irq.h"
 #include "hw/sysbus.h"
 #include "hw/arm/omap.h"
-#include "hw/sd/sdcard_legacy.h"
+#include "hw/sd/sd.h"
 
 typedef struct OMAPMMCState {
 SysBusDevice parent_obj;
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index f781fd1641d..74bb7f39bbf 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -39,7 +39,6 @@
 #include "hw/registerfields.h"
 #include "system/block-backend.h"
 #include "hw/sd/sd.h"
-#include "hw/sd/sdcard_legacy.h"
 #include "migration/vmstate.h"
 #include "qapi/error.h"
 #include "qemu/bitmap.h"
@@ -120,10 +119,6 @@ typedef struct SDProto {
 struct SDState {
 DeviceState parent_obj;
 
-/* If true, created by sd_init() for a non-qdevified caller */
-/* TODO purge them with fire */
-bool me_no_qdev_me_kill_mammoth_with_rocks;
-
 /* SD Memory Card Registers */
 uint32_t ocr;
 uint8_t scr[8];
@@ -177,8 +172,6 @@ struct SDState {
 uint32_t data_offset;
 size_t data_size;
 uint8_t data[512];
-qemu_irq readonly_cb;
-qemu_irq inserted_cb;
 QEMUTimer *ocr_power_timer;
 bool enable;
 uint8_t dat_lines;
@@ -892,17 +885,10 @@ static void sd_cardchange(void *opaque, bool load, Error 
**errp)
 trace_sdcard_ejected();
 }
 
-if (sd->me_no_qdev_me_kill_mammoth_with_rocks) {
-qemu_set

[PATCH 04/11] hw/sd/omap_mmc: Convert to SDBus API

2025-01-28 Thread Peter Maydell
Convert the OMAP MMC controller to the new SDBus API:
 * the controller creates an SDBus bus
 * instead of sd_foo functions on the SDState object, call
   sdbus_foo functions on the SDBus
 * the board code creates a proper TYPE_SD_CARD object and attaches
   it to the controller's SDBus, instead of the controller creating
   a card directly via sd_init() that never gets attached to any bus
 * because the SD card object is on a bus, it gets reset automatically
   by the "traverse the qbus tree resetting things" code, and we don't
   need to manually reset the card from the controller reset function

Signed-off-by: Peter Maydell 
---
 include/hw/arm/omap.h |  1 -
 hw/arm/omap1.c| 10 +-
 hw/sd/omap_mmc.c  | 30 ++
 3 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/include/hw/arm/omap.h b/include/hw/arm/omap.h
index 7d1a1afc4f8..d20c55a8957 100644
--- a/include/hw/arm/omap.h
+++ b/include/hw/arm/omap.h
@@ -534,7 +534,6 @@ OBJECT_DECLARE_SIMPLE_TYPE(OMAPMMCState, OMAP_MMC)
 
 DeviceState *omap_mmc_init(hwaddr base,
MemoryRegion *sysmem,
-   BlockBackend *blk,
qemu_irq irq, qemu_irq dma[], omap_clk clk);
 
 /* omap_i2c.c */
diff --git a/hw/arm/omap1.c b/hw/arm/omap1.c
index ea07b9aa31e..15ba0a0d0c4 100644
--- a/hw/arm/omap1.c
+++ b/hw/arm/omap1.c
@@ -29,6 +29,7 @@
 #include "hw/qdev-properties.h"
 #include "hw/arm/boot.h"
 #include "hw/arm/omap.h"
+#include "hw/sd/sd.h"
 #include "system/blockdev.h"
 #include "system/system.h"
 #include "hw/arm/soc_dma.h"
@@ -3981,11 +3982,18 @@ struct omap_mpu_state_s *omap310_mpu_init(MemoryRegion 
*dram,
 warn_report("missing SecureDigital device");
 }
 s->mmc = omap_mmc_init(0xfffb7800, system_memory,
-   dinfo ? blk_by_legacy_dinfo(dinfo) : NULL,
qdev_get_gpio_in(s->ih[1], OMAP_INT_OQN),
&s->drq[OMAP_DMA_MMC_TX],
 omap_findclk(s, "mmc_ck"));
 
+if (dinfo) {
+DeviceState *card = qdev_new(TYPE_SD_CARD);
+qdev_prop_set_drive_err(card, "drive", blk_by_legacy_dinfo(dinfo),
+&error_fatal);
+qdev_realize_and_unref(card, qdev_get_child_bus(s->mmc, "sd-bus"),
+   &error_fatal);
+}
+
 s->mpuio = omap_mpuio_init(system_memory, 0xfffb5000,
qdev_get_gpio_in(s->ih[1], OMAP_INT_KEYBOARD),
qdev_get_gpio_in(s->ih[1], OMAP_INT_MPUIO),
diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c
index d497e31a6c5..46fdeac1121 100644
--- a/hw/sd/omap_mmc.c
+++ b/hw/sd/omap_mmc.c
@@ -30,13 +30,14 @@
 typedef struct OMAPMMCState {
 SysBusDevice parent_obj;
 
+SDBus sdbus;
+
 qemu_irq irq;
 qemu_irq dma_tx_gpio;
 qemu_irq dma_rx_gpio;
 qemu_irq coverswitch;
 MemoryRegion iomem;
 omap_clk clk;
-SDState *card;
 uint16_t last_cmd;
 uint16_t sdio;
 uint16_t rsp[8];
@@ -158,7 +159,7 @@ static void omap_mmc_command(OMAPMMCState *host, int cmd, 
int dir,
 request.arg = host->arg;
 request.crc = 0; /* FIXME */
 
-rsplen = sd_do_command(host->card, &request, response);
+rsplen = sdbus_do_command(&host->sdbus, &request, response);
 
 /* TODO: validate CRCs */
 switch (resptype) {
@@ -247,10 +248,10 @@ static void omap_mmc_transfer(OMAPMMCState *host)
 if (host->fifo_len > host->af_level)
 break;
 
-value = sd_read_byte(host->card);
+value = sdbus_read_byte(&host->sdbus);
 host->fifo[(host->fifo_start + host->fifo_len) & 31] = value;
 if (-- host->blen_counter) {
-value = sd_read_byte(host->card);
+value = sdbus_read_byte(&host->sdbus);
 host->fifo[(host->fifo_start + host->fifo_len) & 31] |=
 value << 8;
 host->blen_counter --;
@@ -262,10 +263,10 @@ static void omap_mmc_transfer(OMAPMMCState *host)
 break;
 
 value = host->fifo[host->fifo_start] & 0xff;
-sd_write_byte(host->card, value);
+sdbus_write_byte(&host->sdbus, value);
 if (-- host->blen_counter) {
 value = host->fifo[host->fifo_start] >> 8;
-sd_write_byte(host->card, value);
+sdbus_write_byte(&host->sdbus, value);
 host->blen_counter --;
 }
 
@@ -328,14 +329,6 @@ static void omap_mmc_reset(OMAPMMCState *host)
 host->clkdiv = 0;
 
 omap_mmc_pseudo_reset(host);
-
-/* Since we're still using the legacy SD API the card is not plugged
- * into any bus, and we must reset it manually. When omap_mmc is
- * QOMified this must move into the QOM reset function.
- */
-if (host->card) {
-device_cold_reset(DEVICE(host->card));
-}
 }
 
 static uint64_t oma

[PATCH 07/11] hw/sd/omap_mmc: Remove unused coverswitch qemu_irq

2025-01-28 Thread Peter Maydell
The coverswitch qemu_irq is never connected to anything, and the only thing
we do with it is set it in omap_mmc_reset(). Remove it.

Signed-off-by: Peter Maydell 
---
 hw/sd/omap_mmc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c
index dacbea13aad..07d47421bc8 100644
--- a/hw/sd/omap_mmc.c
+++ b/hw/sd/omap_mmc.c
@@ -35,7 +35,6 @@ typedef struct OMAPMMCState {
 qemu_irq irq;
 qemu_irq dma_tx_gpio;
 qemu_irq dma_rx_gpio;
-qemu_irq coverswitch;
 MemoryRegion iomem;
 omap_clk clk;
 uint16_t last_cmd;
@@ -325,7 +324,6 @@ static void omap_mmc_reset(OMAPMMCState *host)
 host->transfer = 0;
 host->cdet_wakeup = 0;
 host->cdet_enable = 0;
-qemu_set_irq(host->coverswitch, host->cdet_state);
 host->clkdiv = 0;
 
 omap_mmc_pseudo_reset(host);
-- 
2.34.1




[PATCH 08/11] hw/sd/omap_mmc: Untabify

2025-01-28 Thread Peter Maydell
This is a very old source file, and still has some lingering
hard-coded tabs; untabify it.

Signed-off-by: Peter Maydell 
---
I don't propose to try to bring the whole file up to modern
coding style, but hard-coded tabs are a particular wart.
---
 hw/sd/omap_mmc.c | 124 +++
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c
index 07d47421bc8..c1598135f44 100644
--- a/hw/sd/omap_mmc.c
+++ b/hw/sd/omap_mmc.c
@@ -110,11 +110,11 @@ static void omap_mmc_fifolevel_update(OMAPMMCState *host)
 
 /* These must match the encoding of the MMC_CMD Response field */
 typedef enum {
-sd_nore = 0,   /* no response */
-sd_r1, /* normal response command */
-sd_r2, /* CID, CSD registers */
-sd_r3, /* OCR register */
-sd_r6 = 6, /* Published RCA response */
+sd_nore = 0,/* no response */
+sd_r1,  /* normal response command */
+sd_r2,  /* CID, CSD registers */
+sd_r3,  /* OCR register */
+sd_r6 = 6,  /* Published RCA response */
 sd_r1b = -1,
 } sd_rsp_type_t;
 
@@ -230,7 +230,7 @@ static void omap_mmc_command(OMAPMMCState *host, int cmd, 
int dir,
 if (timeout)
 host->status |= 0x0080;
 else if (cmd == 12)
-host->status |= 0x0005;/* Makes it more real */
+host->status |= 0x0005; /* Makes it more real */
 else
 host->status |= 0x0001;
 }
@@ -339,32 +339,32 @@ static uint64_t omap_mmc_read(void *opaque, hwaddr 
offset, unsigned size)
 }
 
 switch (offset) {
-case 0x00: /* MMC_CMD */
+case 0x00:  /* MMC_CMD */
 return s->last_cmd;
 
-case 0x04: /* MMC_ARGL */
+case 0x04:  /* MMC_ARGL */
 return s->arg & 0x;
 
-case 0x08: /* MMC_ARGH */
+case 0x08:  /* MMC_ARGH */
 return s->arg >> 16;
 
-case 0x0c: /* MMC_CON */
+case 0x0c:  /* MMC_CON */
 return (s->dw << 15) | (s->mode << 12) | (s->enable << 11) | 
 (s->be << 10) | s->clkdiv;
 
-case 0x10: /* MMC_STAT */
+case 0x10:  /* MMC_STAT */
 return s->status;
 
-case 0x14: /* MMC_IE */
+case 0x14:  /* MMC_IE */
 return s->mask;
 
-case 0x18: /* MMC_CTO */
+case 0x18:  /* MMC_CTO */
 return s->cto;
 
-case 0x1c: /* MMC_DTO */
+case 0x1c:  /* MMC_DTO */
 return s->dto;
 
-case 0x20: /* MMC_DATA */
+case 0x20:  /* MMC_DATA */
 /* TODO: support 8-bit access */
 i = s->fifo[s->fifo_start];
 if (s->fifo_len == 0) {
@@ -379,42 +379,42 @@ static uint64_t omap_mmc_read(void *opaque, hwaddr 
offset, unsigned size)
 omap_mmc_interrupts_update(s);
 return i;
 
-case 0x24: /* MMC_BLEN */
+case 0x24:  /* MMC_BLEN */
 return s->blen_counter;
 
-case 0x28: /* MMC_NBLK */
+case 0x28:  /* MMC_NBLK */
 return s->nblk_counter;
 
-case 0x2c: /* MMC_BUF */
+case 0x2c:  /* MMC_BUF */
 return (s->rx_dma << 15) | (s->af_level << 8) |
 (s->tx_dma << 7) | s->ae_level;
 
-case 0x30: /* MMC_SPI */
+case 0x30:  /* MMC_SPI */
 return 0x;
-case 0x34: /* MMC_SDIO */
+case 0x34:  /* MMC_SDIO */
 return (s->cdet_wakeup << 2) | (s->cdet_enable) | s->sdio;
-case 0x38: /* MMC_SYST */
+case 0x38:  /* MMC_SYST */
 return 0x;
 
-case 0x3c: /* MMC_REV */
+case 0x3c:  /* MMC_REV */
 return s->rev;
 
-case 0x40: /* MMC_RSP0 */
-case 0x44: /* MMC_RSP1 */
-case 0x48: /* MMC_RSP2 */
-case 0x4c: /* MMC_RSP3 */
-case 0x50: /* MMC_RSP4 */
-case 0x54: /* MMC_RSP5 */
-case 0x58: /* MMC_RSP6 */
-case 0x5c: /* MMC_RSP7 */
+case 0x40:  /* MMC_RSP0 */
+case 0x44:  /* MMC_RSP1 */
+case 0x48:  /* MMC_RSP2 */
+case 0x4c:  /* MMC_RSP3 */
+case 0x50:  /* MMC_RSP4 */
+case 0x54:  /* MMC_RSP5 */
+case 0x58:  /* MMC_RSP6 */
+case 0x5c:  /* MMC_RSP7 */
 return s->rsp[(offset - 0x40) >> 2];
 
 /* OMAP2-specific */
-case 0x60: /* MMC_IOSR */
-case 0x64: /* MMC_SYSC */
+case 0x60:  /* MMC_IOSR */
+case 0x64:  /* MMC_SYSC */
 return 0;
-case 0x68: /* MMC_SYSS */
-return 1;  /* RSTD */
+case 0x68:  /* MMC_SYSS */
+return 1;   /* RSTD */
 }
 
 OMAP_BAD_REG(offset);
@@ -433,7 +433,7 @@ static void omap_mmc_write(void *opaque, hwaddr offset,
 }
 
 switch (offset) {
-case 0x00: /* MMC_CMD */
+case 0x00:  /* MMC_CMD */
 if (!s->enable)
 break;
 
@@ -448,17 +448,17 @@ static void omap_mmc_write(void *opaque, hwaddr offset,
 omap_mmc_update(s);
 break;
 
-case 0x04: /* MMC_ARGL */
+case 0x04:  /* MMC_ARGL */
 s->arg &= 0x;
 s->arg |= 0x0

[PATCH 09/11] hw/sd: Remove unused 'enable' method from SDCardClass

2025-01-28 Thread Peter Maydell
The SDCardClass has an 'enable' method, but nothing actually invokes it.
The underlying implementation is sd_enable(), which is documented
in sdcard_legacy.h as something that should not be used and was only
present for the benefit of the now-removed nseries boards. Unlike
all the other method pointers in SDCardClass, this one doesn't have
an sdbus_foo() function wrapper in hw/sd/core.c.

Remove the unused method.

Signed-off-by: Peter Maydell 
---
 include/hw/sd/sd.h | 1 -
 hw/sd/sd.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/include/hw/sd/sd.h b/include/hw/sd/sd.h
index f2458f37b3c..d6bad175131 100644
--- a/include/hw/sd/sd.h
+++ b/include/hw/sd/sd.h
@@ -119,7 +119,6 @@ struct SDCardClass {
 void (*set_voltage)(SDState *sd, uint16_t millivolts);
 uint8_t (*get_dat_lines)(SDState *sd);
 bool (*get_cmd_line)(SDState *sd);
-void (*enable)(SDState *sd, bool enable);
 bool (*get_inserted)(SDState *sd);
 bool (*get_readonly)(SDState *sd);
 void (*set_cid)(SDState *sd);
diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 0330d432fd0..f781fd1641d 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -2831,7 +2831,6 @@ static void sdmmc_common_class_init(ObjectClass *klass, 
void *data)
 sc->read_byte = sd_read_byte;
 sc->receive_ready = sd_receive_ready;
 sc->data_ready = sd_data_ready;
-sc->enable = sd_enable;
 sc->get_inserted = sd_get_inserted;
 sc->get_readonly = sd_get_readonly;
 }
-- 
2.34.1




[PATCH 00/11] hw/sd: QOMify omap-mmc, remove legacy APIs

2025-01-28 Thread Peter Maydell
This series QOMifies the omap-mmc device. The main reason for
this is that this device is now the only remaining in-tree
user of the legacy SD APIs defined in sdcard_legacy.h.
The first 8 patches QOMify the device and do some minor
cleanup on it. Patches 9 to 11 then remove the unused
legacy APIs, deleting sdcard_legacy.h entirely. This includes
letting us get rid of the me_no_qdev_me_kill_mammoth_with_rocks
codepaths in sd.c.

thanks
-- PMM

Peter Maydell (11):
  hw/sd/omap_mmc: Do a minimal conversion to QDev
  hw/sd/omap_mmc: Convert remaining 'struct omap_mmc_s' uses to
OMAPMMCState
  hw/sd/omap_mmc: Convert output qemu_irqs to gpio and sysbus IRQ APIs
  hw/sd/omap_mmc: Convert to SDBus API
  hw/sd/omap_mmc: Use similar API for "wire up omap_clk" to other OMAP
devices
  hw/arm/omap1: Inline creation of MMC
  hw/sd/omap_mmc: Remove unused coverswitch qemu_irq
  hw/sd/omap_mmc: Untabify
  hw/sd: Remove unused 'enable' method from SDCardClass
  hw/sd: Remove unused legacy functions, stop killing mammoths
  hw/sd: Remove unused SDState::enable

 include/hw/arm/omap.h |  17 ++-
 include/hw/sd/sd.h|   1 -
 include/hw/sd/sdcard_legacy.h |  50 ---
 hw/arm/omap1.c|  26 +++-
 hw/sd/omap_mmc.c  | 256 +++---
 hw/sd/sd.c|  94 +++--
 6 files changed, 190 insertions(+), 254 deletions(-)
 delete mode 100644 include/hw/sd/sdcard_legacy.h

-- 
2.34.1




[PATCH 03/11] hw/sd/omap_mmc: Convert output qemu_irqs to gpio and sysbus IRQ APIs

2025-01-28 Thread Peter Maydell
The omap_mmc device has three outbound qemu_irq lines:
 * one actual interrupt line
 * two which connect to the DMA controller and are signalled for
   TX and RX DMA

Convert these to a sysbus IRQ and two named GPIO outputs.

Signed-off-by: Peter Maydell 
---
 hw/sd/omap_mmc.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/hw/sd/omap_mmc.c b/hw/sd/omap_mmc.c
index dd45abc075e..d497e31a6c5 100644
--- a/hw/sd/omap_mmc.c
+++ b/hw/sd/omap_mmc.c
@@ -31,7 +31,8 @@ typedef struct OMAPMMCState {
 SysBusDevice parent_obj;
 
 qemu_irq irq;
-qemu_irq *dma;
+qemu_irq dma_tx_gpio;
+qemu_irq dma_rx_gpio;
 qemu_irq coverswitch;
 MemoryRegion iomem;
 omap_clk clk;
@@ -87,22 +88,22 @@ static void omap_mmc_fifolevel_update(OMAPMMCState *host)
 if (host->fifo_len > host->af_level && host->ddir) {
 if (host->rx_dma) {
 host->status &= 0xfbff;
-qemu_irq_raise(host->dma[1]);
+qemu_irq_raise(host->dma_rx_gpio);
 } else
 host->status |= 0x0400;
 } else {
 host->status &= 0xfbff;
-qemu_irq_lower(host->dma[1]);
+qemu_irq_lower(host->dma_rx_gpio);
 }
 
 if (host->fifo_len < host->ae_level && !host->ddir) {
 if (host->tx_dma) {
 host->status &= 0xf7ff;
-qemu_irq_raise(host->dma[0]);
+qemu_irq_raise(host->dma_tx_gpio);
 } else
 host->status |= 0x0800;
 } else {
-qemu_irq_lower(host->dma[0]);
+qemu_irq_lower(host->dma_tx_gpio);
 host->status &= 0xf7ff;
 }
 }
@@ -601,12 +602,13 @@ DeviceState *omap_mmc_init(hwaddr base,
 s = OMAP_MMC(dev);
 sysbus_realize_and_unref(SYS_BUS_DEVICE(s), &error_fatal);
 
-s->irq = irq;
-s->dma = dma;
 s->clk = clk;
 
 memory_region_add_subregion(sysmem, base,
 sysbus_mmio_get_region(SYS_BUS_DEVICE(s), 0));
+qdev_connect_gpio_out_named(dev, "dma-tx", 0, dma[0]);
+qdev_connect_gpio_out_named(dev, "dma-rx", 0, dma[1]);
+sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, irq);
 
 /* Instantiate the storage */
 s->card = sd_init(blk, false);
@@ -633,6 +635,10 @@ static void omap_mmc_initfn(Object *obj)
 
 memory_region_init_io(&s->iomem, obj, &omap_mmc_ops, s, "omap.mmc", 0x800);
 sysbus_init_mmio(SYS_BUS_DEVICE(s), &s->iomem);
+
+sysbus_init_irq(SYS_BUS_DEVICE(obj), &s->irq);
+qdev_init_gpio_out_named(DEVICE(obj), &s->dma_tx_gpio, "dma-tx", 1);
+qdev_init_gpio_out_named(DEVICE(obj), &s->dma_rx_gpio, "dma-rx", 1);
 }
 
 static void omap_mmc_realize(DeviceState *dev, Error **errp)
-- 
2.34.1




[PATCH 11/11] hw/sd: Remove unused SDState::enable

2025-01-28 Thread Peter Maydell
Now that sd_enable() has been removed, SD::enable is set to true in
sd_instance_init() and then never changed. So we can remove it.

Note that the VMSTATE_UNUSED() size argument should be '1', not
'sizeof(bool)', as noted in the CAUTION comment in vmstate.h.

Signed-off-by: Peter Maydell 
---
 hw/sd/sd.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 74bb7f39bbf..e541c57f8c3 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -173,7 +173,6 @@ struct SDState {
 size_t data_size;
 uint8_t data[512];
 QEMUTimer *ocr_power_timer;
-bool enable;
 uint8_t dat_lines;
 bool cmd_line;
 };
@@ -292,12 +291,12 @@ static const char *sd_acmd_name(SDState *sd, uint8_t cmd)
 
 static uint8_t sd_get_dat_lines(SDState *sd)
 {
-return sd->enable ? sd->dat_lines : 0;
+return sd->dat_lines;
 }
 
 static bool sd_get_cmd_line(SDState *sd)
 {
-return sd->enable ? sd->cmd_line : false;
+return sd->cmd_line;
 }
 
 static void sd_set_voltage(SDState *sd, uint16_t millivolts)
@@ -976,7 +975,7 @@ static const VMStateDescription sd_vmstate = {
 VMSTATE_UINT32(data_offset, SDState),
 VMSTATE_UINT8_ARRAY(data, SDState, 512),
 VMSTATE_UNUSED_V(1, 512),
-VMSTATE_BOOL(enable, SDState),
+VMSTATE_UNUSED(1),
 VMSTATE_END_OF_LIST()
 },
 .subsections = (const VMStateDescription * const []) {
@@ -2146,7 +2145,7 @@ static int sd_do_command(SDState *sd, SDRequest *req,
 sd_rsp_type_t rtype;
 int rsplen;
 
-if (!sd->blk || !blk_is_inserted(sd->blk) || !sd->enable) {
+if (!sd->blk || !blk_is_inserted(sd->blk)) {
 return 0;
 }
 
@@ -2297,8 +2296,9 @@ static void sd_write_byte(SDState *sd, uint8_t value)
 {
 int i;
 
-if (!sd->blk || !blk_is_inserted(sd->blk) || !sd->enable)
+if (!sd->blk || !blk_is_inserted(sd->blk)) {
 return;
+}
 
 if (sd->state != sd_receivingdata_state) {
 qemu_log_mask(LOG_GUEST_ERROR,
@@ -2429,8 +2429,9 @@ static uint8_t sd_read_byte(SDState *sd)
 uint8_t ret;
 uint32_t io_len;
 
-if (!sd->blk || !blk_is_inserted(sd->blk) || !sd->enable)
+if (!sd->blk || !blk_is_inserted(sd->blk)) {
 return dummy_byte;
+}
 
 if (sd->state != sd_sendingdata_state) {
 qemu_log_mask(LOG_GUEST_ERROR,
@@ -2664,7 +2665,6 @@ static void sd_instance_init(Object *obj)
 
 sd->proto = sc->proto;
 sd->last_cmd_name = "UNSET";
-sd->enable = true;
 sd->ocr_power_timer = timer_new_ns(QEMU_CLOCK_VIRTUAL, sd_ocr_powerup, sd);
 }
 
-- 
2.34.1




[Stable-8.2.9 03/45] hw/intc/loongarch_extioi: Use set_bit32() and clear_bit32() for s->isr

2025-01-28 Thread Michael Tokarev
In extioi_setirq() we try to operate on a bit array stored as an
array of uint32_t using the set_bit() and clear_bit() functions
by casting the pointer to 'unsigned long *'.
This has two problems:
 * the alignment of 'uint32_t' is less than that of 'unsigned long'
   so we pass an insufficiently aligned pointer, which is
   undefined behaviour
 * on big-endian hosts the 64-bit 'unsigned long' will have
   its two halves the wrong way around, and we will produce
   incorrect results

The undefined behaviour is shown by the clang undefined-behaviour
sanitizer when running the loongarch64-virt functional test:

/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:5: runtime 
error: store to misaligned address 0x59745d9c for type 'unsigned long', 
which requires 8 byte alignment
0x59745d9c: note: pointer points here
  ff ff ff ff 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 
00 00 00 00 00 00 00
  ^
#0 0x56fb81c4 in set_bit 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:9
#1 0x56fb81c4 in extioi_setirq 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_extioi.c:65:9
#2 0x56fb6e90 in pch_pic_irq_handler 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_pch_pic.c:75:5
#3 0x56710265 in serial_ioport_write 
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/char/serial.c

Fix these problems by using set_bit32() and clear_bit32(),
which work with bit arrays stored as an array of uint32_t.

Cc: qemu-sta...@nongnu.org
Fixes: cbff2db1e92f8759 ("hw/intc: Add LoongArch extioi interrupt 
controller(EIOINTC)")
Signed-off-by: Peter Maydell 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Bibo Mao 
Message-id: 20241108135514.4006953-4-peter.mayd...@linaro.org
(cherry picked from commit 335be5bc44aa6800a9e3ba5859ea3833cfe5a7bc)
Signed-off-by: Michael Tokarev 
(Mjt: drop hunk in hw/intc/loongarch_extioi.c:extioi_update_sw_coremap()
 due to missing v8.2.0-548-g428a6ef4396a "hw/intc/loongarch_extioi: Add vmstate 
post_load support")

diff --git a/hw/intc/loongarch_extioi.c b/hw/intc/loongarch_extioi.c
index 24fb3af8cc..332286be5b 100644
--- a/hw/intc/loongarch_extioi.c
+++ b/hw/intc/loongarch_extioi.c
@@ -56,14 +56,9 @@ static void extioi_setirq(void *opaque, int irq, int level)
 LoongArchExtIOI *s = LOONGARCH_EXTIOI(opaque);
 trace_loongarch_extioi_setirq(irq, level);
 if (level) {
-/*
- * s->isr should be used in vmstate structure,
- * but it not support 'unsigned long',
- * so we have to switch it.
- */
-set_bit(irq, (unsigned long *)s->isr);
+set_bit32(irq, s->isr);
 } else {
-clear_bit(irq, (unsigned long *)s->isr);
+clear_bit32(irq, s->isr);
 }
 extioi_update_irq(s, irq, level);
 }
-- 
2.39.5




[Stable-9.1.3 04/58] linux-user: Fix strace output for s390x mmap()

2025-01-28 Thread Michael Tokarev
print_mmap() assumes that mmap() receives arguments via memory if
mmap2() is present. s390x (as opposed to s390) does not fit this
pattern: it does not have mmap2(), but mmap() still receives arguments
via memory.

Fix by sharing the detection logic between syscall.c and strace.c.

Cc: qemu-sta...@nongnu.org
Fixes: d971040c2d16 ("linux-user: Fix strace output for old_mmap")
Suggested-by: Richard Henderson 
Signed-off-by: Ilya Leoshkevich 
Message-ID: <20241120212717.246186-1-...@linux.ibm.com>
Reviewed-by: Richard Henderson 
Signed-off-by: Richard Henderson 
(cherry picked from commit d95fd9838b540e69da9b07538ec8ad6ab9eab260)
Signed-off-by: Michael Tokarev 
(Mjt: compensate for chris architecture removal by v9.1.0-282-gbff4b02ca1f4
 "linux-user: Remove support for CRIS target")

diff --git a/linux-user/strace.c b/linux-user/strace.c
index b4d1098170..4dabe0bd42 100644
--- a/linux-user/strace.c
+++ b/linux-user/strace.c
@@ -3823,7 +3823,7 @@ print_mmap(CPUArchState *cpu_env, const struct 
syscallname *name,
 {
 return print_mmap_both(cpu_env, name, arg0, arg1, arg2, arg3,
arg4, arg5,
-#if defined(TARGET_NR_mmap2)
+#ifdef TARGET_ARCH_WANT_SYS_OLD_MMAP
 true
 #else
 false
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index c393ca6716..900872a741 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -10496,10 +10496,7 @@ static abi_long do_syscall1(CPUArchState *cpu_env, int 
num, abi_long arg1,
 return ret;
 #ifdef TARGET_NR_mmap
 case TARGET_NR_mmap:
-#if (defined(TARGET_I386) && defined(TARGET_ABI32)) || \
-(defined(TARGET_ARM) && defined(TARGET_ABI32)) || \
-defined(TARGET_M68K) || defined(TARGET_CRIS) || defined(TARGET_MICROBLAZE) 
\
-|| defined(TARGET_S390X)
+#ifdef TARGET_ARCH_WANT_SYS_OLD_MMAP
 {
 abi_ulong *v;
 abi_ulong v1, v2, v3, v4, v5, v6;
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index a00b617cae..7ca5972296 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -2754,4 +2754,11 @@ struct target_sched_param {
 abi_int sched_priority;
 };
 
+#if (defined(TARGET_I386) && defined(TARGET_ABI32)) || \
+(defined(TARGET_ARM) && defined(TARGET_ABI32)) || \
+defined(TARGET_M68K) || defined(TARGET_CRIS) || defined(TARGET_MICROBLAZE) 
\
+|| defined(TARGET_S390X)
+#define TARGET_ARCH_WANT_SYS_OLD_MMAP
+#endif
+
 #endif
-- 
2.39.5




  1   2   3   4   5   >