[PATCH v2] hw/s390x: Attach the sclpconsole to /machine/sclp/s390-sclp-event-facility

[Thomas Huth]

The sclpconsole currently does not have a proper parent in the QOM
tree, so it shows up under /machine/unattached - which is somewhat
ugly. We should rather attach it to /machine/sclp/s390-sclp-event-facility
where the other devices of type TYPE_SCLP_EVENT already reside.

Signed-off-by: Thomas Huth 
---
 hw/s390x/s390-virtio-ccw.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 5c83d1ea17..41be8bf857 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -242,11 +242,13 @@ static void s390_create_virtio_net(BusState *bus, const 
char *name)
 
 static void s390_create_sclpconsole(const char *type, Chardev *chardev)
 {
+BusState *ev_fac_bus = sclp_get_event_facility_bus();
 DeviceState *dev;
 
 dev = qdev_new(type);
+object_property_add_child(OBJECT(ev_fac_bus->parent), type, OBJECT(dev));
 qdev_prop_set_chr(dev, "chardev", chardev);
-qdev_realize_and_unref(dev, sclp_get_event_facility_bus(), _fatal);
+qdev_realize_and_unref(dev, ev_fac_bus, _fatal);
 }
 
 static void ccw_init(MachineState *machine)
-- 
2.44.0

Re: [PATCH] hw/s390x: Attach the sclpconsole to the /machine/sclp node

[Thomas Huth]

On 30/04/2024 16.24, Thomas Huth wrote:

On 30/04/2024 13.58, Cédric Le Goater wrote:

On 4/30/24 10:04, Thomas Huth wrote:

The sclpconsole currently does not have a proper parent in the QOM
tree, so it shows up under /machine/unattached - which is somewhat
ugly. Let's attach it to /machine/sclp instead.

Signed-off-by: Thomas Huth 
---
  include/hw/s390x/sclp.h    |  2 +-
  hw/s390x/s390-virtio-ccw.c | 11 +++
  hw/s390x/sclp.c    |  4 +++-
  3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h
index b405a387b6..abfd6d8868 100644
--- a/include/hw/s390x/sclp.h
+++ b/include/hw/s390x/sclp.h
@@ -222,7 +222,7 @@ static inline int sccb_data_len(SCCB *sccb)
  }
-void s390_sclp_init(void);
+Object *s390_sclp_init(void);
  void sclp_service_interrupt(uint32_t sccb);
  void raise_irq_cpu_hotplug(void);
  int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code);
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 4dcc213820..e2f9206ded 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -237,11 +237,13 @@ static void s390_create_virtio_net(BusState *bus, 
const char *name)

  }
  }
-static void s390_create_sclpconsole(const char *type, Chardev *chardev)
+static void s390_create_sclpconsole(Object *sclp, const char *type,
+    Chardev *chardev)
  {
  DeviceState *dev;
  dev = qdev_new(type);
+    object_property_add_child(sclp, type, OBJECT(dev));
  qdev_prop_set_chr(dev, "chardev", chardev);
  qdev_realize_and_unref(dev, sclp_get_event_facility_bus(), 
_fatal);

  }
@@ -252,8 +254,9 @@ static void ccw_init(MachineState *machine)
  int ret;
  VirtualCssBus *css_bus;
  DeviceState *dev;
+    Object *sclp;
-    s390_sclp_init();
+    sclp = s390_sclp_init();


I would simply drop s390_sclp_init(), same for :

   void s390_init_tod(void);
   void s390_init_ap(void);
   void s390_stattrib_init(void);
   void s390_skeys_init(void);
   void s390_flic_init(void);

These routines all do the same and are not very useful TBH, and I would
add pointers under the s390x MachineState possibly.


Some of them seem to do a little bit more things, like checking whether the 
feature is available or not, e.g. s390_init_ap() ... IMHO it makes sense to 
keep at least those?


But for s390_sclp_init ... it could be inlined, indeed, especially if we 
also switch the object_unref + qdev_realize in there into 
qdev_realize_and_unref. Let me try to do that in a v2 ...


Actually, after looking at the code a little bit longer, it seems to me like 
the sclpconsole should be attached to /machine/sclp/s390-sclp-event-facility
instead of just /machine/sclp, since the other devices of type 
TYPE_SCLP_EVENT are also located there. That makes the patch even easier 
since we already have the pointer from sclp_get_event_facility_bus() in that 
function.


 Thomas

Re: [PATCH] hw/s390x: Attach the sclpconsole to the /machine/sclp node

[Thomas Huth]

On 30/04/2024 13.58, Cédric Le Goater wrote:

On 4/30/24 10:04, Thomas Huth wrote:

The sclpconsole currently does not have a proper parent in the QOM
tree, so it shows up under /machine/unattached - which is somewhat
ugly. Let's attach it to /machine/sclp instead.

Signed-off-by: Thomas Huth 
---
  include/hw/s390x/sclp.h    |  2 +-
  hw/s390x/s390-virtio-ccw.c | 11 +++
  hw/s390x/sclp.c    |  4 +++-
  3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h
index b405a387b6..abfd6d8868 100644
--- a/include/hw/s390x/sclp.h
+++ b/include/hw/s390x/sclp.h
@@ -222,7 +222,7 @@ static inline int sccb_data_len(SCCB *sccb)
  }
-void s390_sclp_init(void);
+Object *s390_sclp_init(void);
  void sclp_service_interrupt(uint32_t sccb);
  void raise_irq_cpu_hotplug(void);
  int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code);
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 4dcc213820..e2f9206ded 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -237,11 +237,13 @@ static void s390_create_virtio_net(BusState *bus, 
const char *name)

  }
  }
-static void s390_create_sclpconsole(const char *type, Chardev *chardev)
+static void s390_create_sclpconsole(Object *sclp, const char *type,
+    Chardev *chardev)
  {
  DeviceState *dev;
  dev = qdev_new(type);
+    object_property_add_child(sclp, type, OBJECT(dev));
  qdev_prop_set_chr(dev, "chardev", chardev);
  qdev_realize_and_unref(dev, sclp_get_event_facility_bus(), 
_fatal);

  }
@@ -252,8 +254,9 @@ static void ccw_init(MachineState *machine)
  int ret;
  VirtualCssBus *css_bus;
  DeviceState *dev;
+    Object *sclp;
-    s390_sclp_init();
+    sclp = s390_sclp_init();


I would simply drop s390_sclp_init(), same for :

   void s390_init_tod(void);
   void s390_init_ap(void);
   void s390_stattrib_init(void);
   void s390_skeys_init(void);
   void s390_flic_init(void);

These routines all do the same and are not very useful TBH, and I would
add pointers under the s390x MachineState possibly.


Some of them seem to do a little bit more things, like checking whether the 
feature is available or not, e.g. s390_init_ap() ... IMHO it makes sense to 
keep at least those?


But for s390_sclp_init ... it could be inlined, indeed, especially if we 
also switch the object_unref + qdev_realize in there into 
qdev_realize_and_unref. Let me try to do that in a v2 ...


 Thomas

Re: [PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years

[Thomas Huth]

On 30/04/2024 11.55, Daniel P. Berrangé wrote:

On Tue, Apr 30, 2024 at 08:45:29AM +0200, Thomas Huth wrote:

Old machine types often have bugs or work-arounds that affect our
possibilities to move forward with the QEMU code base (see for example
https://gitlab.com/qemu-project/qemu/-/issues/2213 for a bug that likely
cannot be fixed without breaking live migration with old machine types,
or https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html or
commit ea985d235b86). So instead of going through the process of manually
deprecating old machine types again and again, let's rather add an entry
that can stay, which declares that machine types older than 6 years are
considered as deprecated automatically. Six years should be sufficient to
support the release cycles of most Linux distributions.


Reading this again, I think we're mixing two concepts here.

With this 6 year cut off, we're declaring the actual *removal* date,
not the deprecation date.

A deprecation is something that happens prior to removal normally,
to give people a warning of /future/ removal, as a suggestion
that they stop using it.

If we never set the 'deprecation_reason' on a machine type, then
unless someone reads this doc, they'll never realize they are on
a deprecated machine.

When it comes to machine types, I see deprecation as a way to tell
people they should not deploy a /new/ VM on a machine type, only
use it for back compat (incoming migration / restore from saved
image) with existing deployed VMs.

If we delete a machine on the 6 year anniversary, then users
don't want to be deploying /new/ VMs using that on the
5 year anniversary as it only gives a 1 year upgrade window.

So how long far back do we consider it reasonable for a user
to deploy a /new/ VM on an old machine type ? 1 year, 2 years,
3 years ?


How about picking the half way point ?  3 years ?

ie, set deprecation_reason for any machine that is 3 years
old, but declare that our deprecation cycle lasts for
3 years, instead of the normal 1 year, when applied to
machine types.

This would give a strong hint that users should get off the
old machine type, several years before its finally deleted.


Sounds like a good idea, too! Since I have to drop this patch here anyway, 
could you maybe write such a new patch? (or do you want me to try to 
formulate this?)


 Thomas

Re: [PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years

[Thomas Huth]

On 30/04/2024 11.55, Daniel P. Berrangé wrote:

On Tue, Apr 30, 2024 at 08:45:29AM +0200, Thomas Huth wrote:

Old machine types often have bugs or work-arounds that affect our
possibilities to move forward with the QEMU code base (see for example
https://gitlab.com/qemu-project/qemu/-/issues/2213 for a bug that likely
cannot be fixed without breaking live migration with old machine types,
or https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html or
commit ea985d235b86). So instead of going through the process of manually
deprecating old machine types again and again, let's rather add an entry
that can stay, which declares that machine types older than 6 years are
considered as deprecated automatically. Six years should be sufficient to
support the release cycles of most Linux distributions.


Reading this again, I think we're mixing two concepts here.

With this 6 year cut off, we're declaring the actual *removal* date,
not the deprecation date.

A deprecation is something that happens prior to removal normally,
to give people a warning of /future/ removal, as a suggestion
that they stop using it.

If we never set the 'deprecation_reason' on a machine type, then
unless someone reads this doc, they'll never realize they are on
a deprecated machine.

When it comes to machine types, I see deprecation as a way to tell
people they should not deploy a /new/ VM on a machine type, only
use it for back compat (incoming migration / restore from saved
image) with existing deployed VMs.

If we delete a machine on the 6 year anniversary, then users
don't want to be deploying /new/ VMs using that on the
5 year anniversary as it only gives a 1 year upgrade window.

So how long far back do we consider it reasonable for a user
to deploy a /new/ VM on an old machine type ? 1 year, 2 years,
3 years ?


How about picking the half way point ?  3 years ?

ie, set deprecation_reason for any machine that is 3 years
old, but declare that our deprecation cycle lasts for
3 years, instead of the normal 1 year, when applied to
machine types.

This would give a strong hint that users should get off the
old machine type, several years before its finally deleted.


Sounds like a good idea, too! Since I have to drop this patch here anyway, 
could you maybe write such a new patch? (or do you want me to try to 
formulate this?)


 Thomas
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: [PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years

[Thomas Huth]

On 30/04/2024 11.40, Philippe Mathieu-Daudé wrote:

Hi Thomas,

On 30/4/24 08:45, Thomas Huth wrote:

Old machine types often have bugs or work-arounds that affect our
possibilities to move forward with the QEMU code base (see for example
https://gitlab.com/qemu-project/qemu/-/issues/2213 for a bug that likely
cannot be fixed without breaking live migration with old machine types,
or https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html or
commit ea985d235b86). So instead of going through the process of manually
deprecating old machine types again and again, let's rather add an entry
that can stay, which declares that machine types older than 6 years are
considered as deprecated automatically. Six years should be sufficient to
support the release cycles of most Linux distributions.


Thanks for taking that out of my plate :)

IIRC 6 years was because of some old RHEL version, otherwise could
5 years be enough? (maybe it could be good enough for this old RHEL
version as of QEMU v10.0).


My thinking was like this:
1) We recently talked about marking all machine types up to 2.12 as 
deprecated recently. 2.12 has been released in 2018, so if we feel confident 
that those old machine types could go away now/soon, 2024 - 2018 = 6 years 
seem to be a good rule of thumb.
2) RHEL and OpenSuSE tend to provide feature updates in their enterprise 
distros for 5 (RHEL) or 6 (current OpenSuSE AFAIK) years, so keeping old 
machine types in upstream QEMU for that amount of time certainly also helps 
with downstream distros.



diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 6d595de3b6..fe69e2d44c 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -220,6 +220,17 @@ is a chance the code will bitrot without anyone 
noticing.

  System emulator machines
  
+Versioned machine types older than 6 years
+''
+
+Starting with the release of QEMU 10.0, versioned machine types older than


Why can't we start with QEMU 9.1?


If I put 9.1 now there, that would make it possible to immediately remove 
machines in 9.2, i.e. we would skip the 
must-be-marked-as-deprecated-for-two-releases rule here.


 Thomas

Re: [PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years

[Thomas Huth]

On 30/04/2024 11.40, Philippe Mathieu-Daudé wrote:

Hi Thomas,

On 30/4/24 08:45, Thomas Huth wrote:

Old machine types often have bugs or work-arounds that affect our
possibilities to move forward with the QEMU code base (see for example
https://gitlab.com/qemu-project/qemu/-/issues/2213 for a bug that likely
cannot be fixed without breaking live migration with old machine types,
or https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html or
commit ea985d235b86). So instead of going through the process of manually
deprecating old machine types again and again, let's rather add an entry
that can stay, which declares that machine types older than 6 years are
considered as deprecated automatically. Six years should be sufficient to
support the release cycles of most Linux distributions.


Thanks for taking that out of my plate :)

IIRC 6 years was because of some old RHEL version, otherwise could
5 years be enough? (maybe it could be good enough for this old RHEL
version as of QEMU v10.0).


My thinking was like this:
1) We recently talked about marking all machine types up to 2.12 as 
deprecated recently. 2.12 has been released in 2018, so if we feel confident 
that those old machine types could go away now/soon, 2024 - 2018 = 6 years 
seem to be a good rule of thumb.
2) RHEL and OpenSuSE tend to provide feature updates in their enterprise 
distros for 5 (RHEL) or 6 (current OpenSuSE AFAIK) years, so keeping old 
machine types in upstream QEMU for that amount of time certainly also helps 
with downstream distros.



diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 6d595de3b6..fe69e2d44c 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -220,6 +220,17 @@ is a chance the code will bitrot without anyone 
noticing.

  System emulator machines
  
+Versioned machine types older than 6 years
+''
+
+Starting with the release of QEMU 10.0, versioned machine types older than


Why can't we start with QEMU 9.1?


If I put 9.1 now there, that would make it possible to immediately remove 
machines in 9.2, i.e. we would skip the 
must-be-marked-as-deprecated-for-two-releases rule here.


 Thomas

___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: [PATCH] hw/s390x: Attach the sclpconsole to the /machine/sclp node

[Thomas Huth]

On 30/04/2024 10.19, David Hildenbrand wrote:

On 30.04.24 10:04, Thomas Huth wrote:

The sclpconsole currently does not have a proper parent in the QOM
tree, so it shows up under /machine/unattached - which is somewhat
ugly. Let's attach it to /machine/sclp instead.


IIRC, this should not affect migration



Yes, that's my understanding, too. I also did a quick check from one QEMU 
without this patch to a QEMU that includes this patch, and migration just 
succeeded fine.



Reviewed-by: David Hildenbrand 


Thanks!

 Thomas

[PATCH] hw/s390x: Attach the sclpconsole to the /machine/sclp node

[Thomas Huth]

The sclpconsole currently does not have a proper parent in the QOM
tree, so it shows up under /machine/unattached - which is somewhat
ugly. Let's attach it to /machine/sclp instead.

Signed-off-by: Thomas Huth 
---
 include/hw/s390x/sclp.h|  2 +-
 hw/s390x/s390-virtio-ccw.c | 11 +++
 hw/s390x/sclp.c|  4 +++-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h
index b405a387b6..abfd6d8868 100644
--- a/include/hw/s390x/sclp.h
+++ b/include/hw/s390x/sclp.h
@@ -222,7 +222,7 @@ static inline int sccb_data_len(SCCB *sccb)
 }
 
 
-void s390_sclp_init(void);
+Object *s390_sclp_init(void);
 void sclp_service_interrupt(uint32_t sccb);
 void raise_irq_cpu_hotplug(void);
 int sclp_service_call(S390CPU *cpu, uint64_t sccb, uint32_t code);
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 4dcc213820..e2f9206ded 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -237,11 +237,13 @@ static void s390_create_virtio_net(BusState *bus, const 
char *name)
 }
 }
 
-static void s390_create_sclpconsole(const char *type, Chardev *chardev)
+static void s390_create_sclpconsole(Object *sclp, const char *type,
+Chardev *chardev)
 {
 DeviceState *dev;
 
 dev = qdev_new(type);
+object_property_add_child(sclp, type, OBJECT(dev));
 qdev_prop_set_chr(dev, "chardev", chardev);
 qdev_realize_and_unref(dev, sclp_get_event_facility_bus(), _fatal);
 }
@@ -252,8 +254,9 @@ static void ccw_init(MachineState *machine)
 int ret;
 VirtualCssBus *css_bus;
 DeviceState *dev;
+Object *sclp;
 
-s390_sclp_init();
+sclp = s390_sclp_init();
 /* init memory + setup max page size. Required for the CPU model */
 s390_memory_init(machine->ram);
 
@@ -302,10 +305,10 @@ static void ccw_init(MachineState *machine)
 
 /* init consoles */
 if (serial_hd(0)) {
-s390_create_sclpconsole("sclpconsole", serial_hd(0));
+s390_create_sclpconsole(sclp, "sclpconsole", serial_hd(0));
 }
 if (serial_hd(1)) {
-s390_create_sclpconsole("sclplmconsole", serial_hd(1));
+s390_create_sclpconsole(sclp, "sclplmconsole", serial_hd(1));
 }
 
 /* init the TOD clock */
diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index 893e71a41b..75d45fb184 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -379,13 +379,15 @@ void sclp_service_interrupt(uint32_t sccb)
 
 /* qemu object creation and initialization functions */
 
-void s390_sclp_init(void)
+Object *s390_sclp_init(void)
 {
 Object *new = object_new(TYPE_SCLP);
 
 object_property_add_child(qdev_get_machine(), TYPE_SCLP, new);
 object_unref(new);
 qdev_realize(DEVICE(new), NULL, _fatal);
+
+return new;
 }
 
 static void sclp_realize(DeviceState *dev, Error **errp)
-- 
2.44.0

[PULL 19/19] .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs

[Thomas Huth]

During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.

Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.

Message-ID: <20240426113742.654748-1-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/cirrus.yml   | 37 ---
 .gitlab-ci.d/cirrus/kvm-build.yml | 31 --
 2 files changed, 68 deletions(-)
 delete mode 100644 .gitlab-ci.d/cirrus/kvm-build.yml

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 49f86fadaf..75df1273bc 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -91,40 +91,3 @@ aarch64-macos-14-base-build:
 PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
 TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
 QEMU_JOB_OPTIONAL: 1
-
-
-# The following jobs run VM-based tests via KVM on a Linux-based Cirrus-CI job
-.cirrus_kvm_job:
-  extends: .base_job_template
-  stage: build
-  image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:master
-  needs: []
-  timeout: 80m
-  script:
-- sed -e "s|[@]CI_REPOSITORY_URL@|$CI_REPOSITORY_URL|g"
-  -e "s|[@]CI_COMMIT_REF_NAME@|$CI_COMMIT_REF_NAME|g"
-  -e "s|[@]CI_COMMIT_SHA@|$CI_COMMIT_SHA|g"
-  -e "s|[@]NAME@|$NAME|g"
-  -e "s|[@]CONFIGURE_ARGS@|$CONFIGURE_ARGS|g"
-  -e "s|[@]TEST_TARGETS@|$TEST_TARGETS|g"
-  <.gitlab-ci.d/cirrus/kvm-build.yml >.gitlab-ci.d/cirrus/$NAME.yml
-- cat .gitlab-ci.d/cirrus/$NAME.yml
-- cirrus-run -v --show-build-log always .gitlab-ci.d/cirrus/$NAME.yml
-  variables:
-QEMU_JOB_CIRRUS: 1
-QEMU_JOB_OPTIONAL: 1
-
-
-x86-netbsd:
-  extends: .cirrus_kvm_job
-  variables:
-NAME: netbsd
-CONFIGURE_ARGS: --target-list=x86_64-softmmu,ppc64-softmmu,aarch64-softmmu
-TEST_TARGETS: check
-
-x86-openbsd:
-  extends: .cirrus_kvm_job
-  variables:
-NAME: openbsd
-CONFIGURE_ARGS: --target-list=i386-softmmu,riscv64-softmmu,mips64-softmmu
-TEST_TARGETS: check
diff --git a/.gitlab-ci.d/cirrus/kvm-build.yml 
b/.gitlab-ci.d/cirrus/kvm-build.yml
deleted file mode 100644
index a93881aa8b..00
--- a/.gitlab-ci.d/cirrus/kvm-build.yml
+++ /dev/null
@@ -1,31 +0,0 @@
-container:
-  image: fedora:35
-  cpu: 4
-  memory: 8Gb
-  kvm: true
-
-env:
-  CIRRUS_CLONE_DEPTH: 1
-  CI_REPOSITORY_URL: "@CI_REPOSITORY_URL@"
-  CI_COMMIT_REF_NAME: "@CI_COMMIT_REF_NAME@"
-  CI_COMMIT_SHA: "@CI_COMMIT_SHA@"
-
-@NAME@_task:
-  @NAME@_vm_cache:
-folder: $HOME/.cache/qemu-vm
-  install_script:
-- dnf update -y
-- dnf install -y git make openssh-clients qemu-img qemu-system-x86 wget 
meson
-  clone_script:
-- git clone --depth 100 "$CI_REPOSITORY_URL" .
-- git fetch origin "$CI_COMMIT_REF_NAME"
-- git reset --hard "$CI_COMMIT_SHA"
-  build_script:
-- if [ -f $HOME/.cache/qemu-vm/images/@NAME@.img ]; then
-make vm-build-@NAME@ J=$(getconf _NPROCESSORS_ONLN)
-  EXTRA_CONFIGURE_OPTS="@CONFIGURE_ARGS@"
-  BUILD_TARGET="@TEST_TARGETS@" ;
-  else
-make vm-build-@NAME@ J=$(getconf _NPROCESSORS_ONLN) BUILD_TARGET=help
-  EXTRA_CONFIGURE_OPTS="--disable-system --disable-user 
--disable-tools" ;
-  fi
-- 
2.44.0

[PULL 07/19] hw: misc: edu: fix 2 off-by-one errors

[Thomas Huth]

From: Chris Friedt 

In the case that size1 was zero, because of the explicit
'end1 > addr' check, the range check would fail and the error
message would read as shown below. The correct comparison
is 'end1 >= addr'.

EDU: DMA range 0x4-0x3 out of bounds (0x4-0x40fff)!

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1254
Signed-off-by: Chris Friedt 
[thuth: Adjust patch with regards to the "end1 <= end2" check]
Message-ID: <20221018122551.94567-1-cfri...@meta.com>
Signed-off-by: Thomas Huth 
---
 hw/misc/edu.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index 2a976ca2b1..14250e0ac3 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -103,19 +103,18 @@ static void edu_lower_irq(EduState *edu, uint32_t val)
 }
 }
 
-static bool within(uint64_t addr, uint64_t start, uint64_t end)
-{
-return start <= addr && addr < end;
-}
-
-static void edu_check_range(uint64_t addr, uint64_t size1, uint64_t start,
-uint64_t size2)
+static void edu_check_range(uint64_t addr, uint64_t size1,
+uint64_t start, uint64_t size2)
 {
 uint64_t end1 = addr + size1;
 uint64_t end2 = start + size2;
 
-if (within(addr, start, end2) &&
-end1 > addr && end1 <= end2) {
+/*
+ * 1. ensure we aren't overflowing
+ * 2. ensure that [addr, end1) is within [start, size2)
+ */
+if (end2 >= start && end1 >= addr &&
+addr >= start && end1 <= end2) {
 return;
 }
 
-- 
2.44.0

[PULL 18/19] .gitlab-ci.d/cirrus.yml: Shorten the runtime of the macOS and FreeBSD jobs

[Thomas Huth]

Cirrus-CI introduced limitations to the free CI minutes. To avoid that
we are consuming them too fast, let's drop the usual targets that are
not that important since they are either a subset of another target
(like i386 or ppc being a subset of x86_64 or ppc64 respectively), or
since there is still a similar target with the opposite endianness
(like xtensa/xtensael, microblaze/microblazeel etc.).

Message-ID: <20240429100113.53357-1-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/cirrus.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 4671f069c3..49f86fadaf 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -57,6 +57,7 @@ x64-freebsd-13-build:
 CIRRUS_VM_RAM: 8G
 UPDATE_COMMAND: pkg update; pkg upgrade -y
 INSTALL_COMMAND: pkg install -y
+CONFIGURE_ARGS: 
--target-list-exclude=arm-softmmu,i386-softmmu,microblaze-softmmu,mips64el-softmmu,mipsel-softmmu,mips-softmmu,ppc-softmmu,sh4eb-softmmu,xtensa-softmmu
 TEST_TARGETS: check
 
 aarch64-macos-13-base-build:
@@ -72,6 +73,7 @@ aarch64-macos-13-base-build:
 INSTALL_COMMAND: brew install
 PATH_EXTRA: /opt/homebrew/ccache/libexec:/opt/homebrew/gettext/bin
 PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
+CONFIGURE_ARGS: 
--target-list-exclude=arm-softmmu,i386-softmmu,microblazeel-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,ppc-softmmu,sh4-softmmu,xtensaeb-softmmu
 TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
 
 aarch64-macos-14-base-build:
-- 
2.44.0

[PULL 12/19] hw/char/stm32l4x5_usart: Fix memory corruption by adding correct class_size

[Thomas Huth]

"make check-qtest-aarch64" recently started failing on FreeBSD builds,
and valgrind on Linux also detected that there is something fishy with
the new stm32l4x5-usart: The code forgot to set the correct class_size
here, so the various class_init functions in this file wrote beyond
the allocated buffer when setting the subc->type field.

Fixes: 4fb37aea7e ("hw/char: Implement STM32L4x5 USART skeleton")
Message-ID: <20240429075908.36302-1-th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 hw/char/stm32l4x5_usart.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/char/stm32l4x5_usart.c b/hw/char/stm32l4x5_usart.c
index 2627aab832..02f666308c 100644
--- a/hw/char/stm32l4x5_usart.c
+++ b/hw/char/stm32l4x5_usart.c
@@ -617,6 +617,7 @@ static const TypeInfo stm32l4x5_usart_types[] = {
 .parent = TYPE_SYS_BUS_DEVICE,
 .instance_size  = sizeof(Stm32l4x5UsartBaseState),
 .instance_init  = stm32l4x5_usart_base_init,
+.class_size = sizeof(Stm32l4x5UsartBaseClass),
 .class_init = stm32l4x5_usart_base_class_init,
 .abstract   = true,
 }, {
-- 
2.44.0

[PULL 14/19] gitlab: migrate the s390x custom machine to 22.04

[Thomas Huth]

From: Alex Bennée 

20.04 is dead (from QEMU's point of view), long live 22.04!

Signed-off-by: Alex Bennée 
Reviewed-by: Thomas Huth 
Message-ID: <20240426153938.1707723-3-alex.ben...@linaro.org>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/custom-runners.yml   |  2 +-
 ...20.04-s390x.yml => ubuntu-22.04-s390x.yml} | 28 +--
 2 files changed, 15 insertions(+), 15 deletions(-)
 rename .gitlab-ci.d/custom-runners/{ubuntu-20.04-s390x.yml => 
ubuntu-22.04-s390x.yml} (88%)

diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml
index a0e79acd39..29e52df283 100644
--- a/.gitlab-ci.d/custom-runners.yml
+++ b/.gitlab-ci.d/custom-runners.yml
@@ -29,7 +29,7 @@
   junit: build/meson-logs/testlog.junit.xml
 
 include:
-  - local: '/.gitlab-ci.d/custom-runners/ubuntu-20.04-s390x.yml'
+  - local: '/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml'
   - local: '/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml'
   - local: '/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml'
   - local: '/.gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml'
diff --git a/.gitlab-ci.d/custom-runners/ubuntu-20.04-s390x.yml 
b/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
similarity index 88%
rename from .gitlab-ci.d/custom-runners/ubuntu-20.04-s390x.yml
rename to .gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
index cdae6c5212..85e2809573 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-20.04-s390x.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
@@ -1,13 +1,13 @@
-# All ubuntu-20.04 jobs should run successfully in an environment
+# All ubuntu-22.04 jobs should run successfully in an environment
 # setup by the scripts/ci/setup/build-environment.yml task
-# "Install basic packages to build QEMU on Ubuntu 20.04/20.04"
+# "Install basic packages to build QEMU on Ubuntu 22.04"
 
-ubuntu-20.04-s390x-all-linux-static:
+ubuntu-22.04-s390x-all-linux-static:
  extends: .custom_runner_template
  needs: []
  stage: build
  tags:
- - ubuntu_20.04
+ - ubuntu_22.04
  - s390x
  rules:
  - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ 
/^staging/'
@@ -23,12 +23,12 @@ ubuntu-20.04-s390x-all-linux-static:
  - make --output-sync check-tcg
  - make --output-sync -j`nproc` check
 
-ubuntu-20.04-s390x-all:
+ubuntu-22.04-s390x-all:
  extends: .custom_runner_template
  needs: []
  stage: build
  tags:
- - ubuntu_20.04
+ - ubuntu_22.04
  - s390x
  timeout: 75m
  rules:
@@ -42,12 +42,12 @@ ubuntu-20.04-s390x-all:
  - make --output-sync -j`nproc`
  - make --output-sync -j`nproc` check
 
-ubuntu-20.04-s390x-alldbg:
+ubuntu-22.04-s390x-alldbg:
  extends: .custom_runner_template
  needs: []
  stage: build
  tags:
- - ubuntu_20.04
+ - ubuntu_22.04
  - s390x
  rules:
  - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ 
/^staging/'
@@ -65,12 +65,12 @@ ubuntu-20.04-s390x-alldbg:
  - make --output-sync -j`nproc`
  - make --output-sync -j`nproc` check
 
-ubuntu-20.04-s390x-clang:
+ubuntu-22.04-s390x-clang:
  extends: .custom_runner_template
  needs: []
  stage: build
  tags:
- - ubuntu_20.04
+ - ubuntu_22.04
  - s390x
  rules:
  - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ 
/^staging/'
@@ -87,11 +87,11 @@ ubuntu-20.04-s390x-clang:
  - make --output-sync -j`nproc`
  - make --output-sync -j`nproc` check
 
-ubuntu-20.04-s390x-tci:
+ubuntu-22.04-s390x-tci:
  needs: []
  stage: build
  tags:
- - ubuntu_20.04
+ - ubuntu_22.04
  - s390x
  rules:
  - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ 
/^staging/'
@@ -107,12 +107,12 @@ ubuntu-20.04-s390x-tci:
|| { cat config.log meson-logs/meson-log.txt; exit 1; }
  - make --output-sync -j`nproc`
 
-ubuntu-20.04-s390x-notcg:
+ubuntu-22.04-s390x-notcg:
  extends: .custom_runner_template
  needs: []
  stage: build
  tags:
- - ubuntu_20.04
+ - ubuntu_22.04
  - s390x
  rules:
  - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ 
/^staging/'
-- 
2.44.0

[PULL 16/19] hw/ide/core.c (cmd_read_native_max): Avoid limited device parameters

[Thomas Huth]

From: Lev Kujawski 

Always use the native CHS device parameters for the ATA commands READ
NATIVE MAX ADDRESS and READ NATIVE MAX ADDRESS EXT, not those limited
by the ATA command INITIALIZE_DEVICE_PARAMETERS (introduced in patch
176e4961, hw/ide/core.c: Implement ATA INITIALIZE_DEVICE_PARAMETERS
command, 2022-07-07.)

As stated by the ATA/ATAPI specification, "[t]he native maximum is the
highest address accepted by the device in the factory default
condition."  Therefore this patch substitutes the native values in
drive_heads and drive_sectors before calling ide_set_sector().

One consequence of the prior behavior was that setting zero sectors
per track could lead to an FPE within ide_set_sector().  Thanks to
Alexander Bulekov for reporting this issue.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1243
Signed-off-by: Lev Kujawski 
Message-ID: <20221010085229.2431276-1-lku...@mailbox.org>
Signed-off-by: Thomas Huth 
---
 hw/ide/core.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/hw/ide/core.c b/hw/ide/core.c
index e8cb2dac92..08d9218455 100644
--- a/hw/ide/core.c
+++ b/hw/ide/core.c
@@ -1623,11 +1623,24 @@ static bool cmd_read_native_max(IDEState *s, uint8_t 
cmd)
 /* Refuse if no sectors are addressable (e.g. medium not inserted) */
 if (s->nb_sectors == 0) {
 ide_abort_command(s);
-return true;
-}
+} else {
+/*
+ * Save the active drive parameters, which may have been
+ * limited from their native counterparts by, e.g., INITIALIZE
+ * DEVICE PARAMETERS or SET MAX ADDRESS.
+ */
+const int aheads = s->heads;
+const int asectors = s->sectors;
 
-ide_cmd_lba48_transform(s, lba48);
-ide_set_sector(s, s->nb_sectors - 1);
+s->heads = s->drive_heads;
+s->sectors = s->drive_sectors;
+
+ide_cmd_lba48_transform(s, lba48);
+ide_set_sector(s, s->nb_sectors - 1);
+
+s->heads = aheads;
+s->sectors = asectors;
+}
 
 return true;
 }
-- 
2.44.0

[PULL 06/19] target/s390x/cpu_models_sysemu: Drop local @err in apply_cpu_model()

[Thomas Huth]

From: Zhao Liu 

Use @errp to fetch error information directly and drop the local
variable @err.

Signed-off-by: Zhao Liu 
Reviewed-by: Thomas Huth 
Message-ID: <20240425031232.1586401-8-zhao1@intel.com>
Signed-off-by: Thomas Huth 
---
 target/s390x/cpu_models_sysemu.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/target/s390x/cpu_models_sysemu.c b/target/s390x/cpu_models_sysemu.c
index bf855c659d..15be729c3d 100644
--- a/target/s390x/cpu_models_sysemu.c
+++ b/target/s390x/cpu_models_sysemu.c
@@ -389,7 +389,6 @@ CpuModelBaselineInfo 
*qmp_query_cpu_model_baseline(CpuModelInfo *infoa,
 
 void apply_cpu_model(const S390CPUModel *model, Error **errp)
 {
-Error *err = NULL;
 static S390CPUModel applied_model;
 static bool applied;
 
@@ -405,8 +404,7 @@ void apply_cpu_model(const S390CPUModel *model, Error 
**errp)
 }
 
 if (kvm_enabled()) {
-if (!kvm_s390_apply_cpu_model(model, )) {
-error_propagate(errp, err);
+if (!kvm_s390_apply_cpu_model(model, errp)) {
 return;
 }
 }
-- 
2.44.0

[PULL 13/19] build-environment: make some packages optional

[Thomas Huth]

From: Alex Bennée 

Upgrading the s390x runner exposed some packages are not available for
it. Add an additional optional stage we only enable for arm64/x86_64
for now.

Signed-off-by: Alex Bennée 
Reviewed-by: Thomas Huth 
Message-ID: <20240426153938.1707723-2-alex.ben...@linaro.org>
Signed-off-by: Thomas Huth 
---
 scripts/ci/setup/build-environment.yml | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/scripts/ci/setup/build-environment.yml 
b/scripts/ci/setup/build-environment.yml
index f344d1a850..de0d866a1e 100644
--- a/scripts/ci/setup/build-environment.yml
+++ b/scripts/ci/setup/build-environment.yml
@@ -95,7 +95,6 @@
   - libpam0g-dev
   - libpcre2-dev
   - libpixman-1-dev
-  - libpmem-dev
   - libpng-dev
   - libpulse-dev
   - librbd-dev
@@ -107,7 +106,6 @@
   - libslirp-dev
   - libsnappy-dev
   - libspice-protocol-dev
-  - libspice-server-dev
   - libssh-dev
   - libsystemd-dev
   - libtasn1-6-dev
@@ -119,7 +117,6 @@
   - libvdeplug-dev
   - libvirglrenderer-dev
   - libvte-2.91-dev
-  - libxen-dev
   - libxml2-dev
   - libzstd-dev
   - llvm
@@ -156,6 +153,19 @@
 - ansible_facts['distribution'] == 'Ubuntu'
 - ansible_facts['distribution_version'] == '22.04'
 
+# not all packages are available for all architectures
+- name: Install additional packages to build QEMU on Ubuntu 22.04
+  package:
+name:
+  - libpmem-dev
+  - libspice-server-dev
+  - libxen-dev
+state: present
+  when:
+- ansible_facts['distribution'] == 'Ubuntu'
+- ansible_facts['distribution_version'] == '22.04'
+- ansible_facts['architecture'] == 'aarch64' or 
ansible_facts['architecture'] == 'x86_64'
+
 - name: Install armhf cross-compile packages to build QEMU on AArch64 
Ubuntu 22.04
   package:
 name:
-- 
2.44.0

[PULL 11/19] qga: Re-enable the qga-ssh-test when running without fuzzing

[Thomas Huth]

According to the comment in qga/meson.build, the test got disabled
since there were problems with the fuzzing job. But instead of
disabling this test completely, we should still be fine running
it when fuzzing is disabled.

Message-ID: <20240426162348.684143-1-th...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Konstantin Kostiuk 
Signed-off-by: Thomas Huth 
---
 qga/meson.build | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/qga/meson.build b/qga/meson.build
index 1c3d2a3d1b..46c1d83d7f 100644
--- a/qga/meson.build
+++ b/qga/meson.build
@@ -181,12 +181,11 @@ test_env = environment()
 test_env.set('G_TEST_SRCDIR', meson.current_source_dir())
 test_env.set('G_TEST_BUILDDIR', meson.current_build_dir())
 
-# disable qga-ssh-test for now. glib's G_TEST_OPTION_ISOLATE_DIRS triggers
+# disable qga-ssh-test with fuzzing: glib's G_TEST_OPTION_ISOLATE_DIRS triggers
 # the leak detector in build-oss-fuzz Gitlab CI test. we should re-enable
 # this when an alternative is implemented or when the underlying glib
 # issue is identified/fix
-#if host_os != 'windows'
-if false
+if host_os != 'windows' and not get_option('fuzzing')
   srcs = [files('commands-posix-ssh.c')]
   i = 0
   foreach output: qga_qapi_outputs
-- 
2.44.0

[PULL 15/19] gitlab: remove stale s390x-all-linux-static conf hacks

[Thomas Huth]

From: Alex Bennée 

The libssh bug references 18.04 which we are no longer running. We
don't need to disable glusterfs because a linux-user build shouldn't
be trying to link to it anyway.

Signed-off-by: Alex Bennée 
Reviewed-by: Thomas Huth 
Message-ID: <20240426153938.1707723-4-alex.ben...@linaro.org>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml 
b/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
index 85e2809573..105981879f 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
@@ -13,11 +13,9 @@ ubuntu-22.04-s390x-all-linux-static:
  - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ 
/^staging/'
  - if: "$S390X_RUNNER_AVAILABLE"
  script:
- # --disable-libssh is needed because of 
https://bugs.launchpad.net/qemu/+bug/1838763
- # --disable-glusterfs is needed because there's no static version of those 
libs in distro supplied packages
  - mkdir build
  - cd build
- - ../configure --enable-debug --static --disable-system --disable-glusterfs 
--disable-libssh
+ - ../configure --enable-debug --static --disable-system
|| { cat config.log meson-logs/meson-log.txt; exit 1; }
  - make --output-sync -j`nproc`
  - make --output-sync check-tcg
-- 
2.44.0

[PULL 09/19] hw: misc: edu: use qemu_log_mask instead of hw_error

[Thomas Huth]

From: Chris Friedt 

Log a guest error instead of a hardware error when
the guest tries to DMA to / from an invalid address.

Signed-off-by: Chris Friedt 
Message-ID: <20221018122551.94567-3-cfri...@meta.com>
[thuth: Add missing #include statement, fix error reported by checkpatch.pl]
Signed-off-by: Thomas Huth 
---
 hw/misc/edu.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index e1cb443438..fa052c44db 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -23,6 +23,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/log.h"
 #include "qemu/units.h"
 #include "hw/pci/pci.h"
 #include "hw/hw.h"
@@ -118,9 +119,10 @@ static void edu_check_range(uint64_t xfer_start, uint64_t 
xfer_size,
 return;
 }
 
-hw_error("EDU: DMA range 0x%016"PRIx64"-0x%016"PRIx64
- " out of bounds (0x%016"PRIx64"-0x%016"PRIx64")!",
-xfer_start, xfer_end - 1, dma_start, dma_end - 1);
+qemu_log_mask(LOG_GUEST_ERROR,
+  "EDU: DMA range 0x%016"PRIx64"-0x%016"PRIx64
+  " out of bounds (0x%016"PRIx64"-0x%016"PRIx64")!",
+  xfer_start, xfer_end - 1, dma_start, dma_end - 1);
 }
 
 static dma_addr_t edu_clamp_addr(const EduState *edu, dma_addr_t addr)
@@ -128,7 +130,9 @@ static dma_addr_t edu_clamp_addr(const EduState *edu, 
dma_addr_t addr)
 dma_addr_t res = addr & edu->dma_mask;
 
 if (addr != res) {
-printf("EDU: clamping DMA %#.16"PRIx64" to %#.16"PRIx64"!\n", addr, 
res);
+qemu_log_mask(LOG_GUEST_ERROR,
+  "EDU: clamping DMA 0x%016"PRIx64" to 0x%016"PRIx64"!",
+  addr, res);
 }
 
 return res;
-- 
2.44.0

[PULL 05/19] target/s390x/cpu_models: Make kvm_s390_apply_cpu_model() return boolean

[Thomas Huth]

From: Zhao Liu 

As error.h suggested, the best practice for callee is to return
something to indicate success / failure.

So make kvm_s390_apply_cpu_model() return boolean and check the
returned boolean in apply_cpu_model() instead of accessing @err.

Signed-off-by: Zhao Liu 
Reviewed-by: Thomas Huth 
Message-ID: <20240425031232.1586401-7-zhao1@intel.com>
Signed-off-by: Thomas Huth 
---
 target/s390x/cpu_models.h|  2 +-
 target/s390x/cpu_models_sysemu.c |  3 +--
 target/s390x/kvm/kvm.c   | 15 ---
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/target/s390x/cpu_models.h b/target/s390x/cpu_models.h
index c14aff6c10..71d4bc2dd4 100644
--- a/target/s390x/cpu_models.h
+++ b/target/s390x/cpu_models.h
@@ -116,6 +116,6 @@ S390CPUDef const *s390_find_cpu_def(uint16_t type, uint8_t 
gen, uint8_t ec_ga,
 
 bool kvm_s390_cpu_models_supported(void);
 bool kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp);
-void kvm_s390_apply_cpu_model(const S390CPUModel *model,  Error **errp);
+bool kvm_s390_apply_cpu_model(const S390CPUModel *model,  Error **errp);
 
 #endif /* TARGET_S390X_CPU_MODELS_H */
diff --git a/target/s390x/cpu_models_sysemu.c b/target/s390x/cpu_models_sysemu.c
index 2d99218069..bf855c659d 100644
--- a/target/s390x/cpu_models_sysemu.c
+++ b/target/s390x/cpu_models_sysemu.c
@@ -405,8 +405,7 @@ void apply_cpu_model(const S390CPUModel *model, Error 
**errp)
 }
 
 if (kvm_enabled()) {
-kvm_s390_apply_cpu_model(model, );
-if (err) {
+if (!kvm_s390_apply_cpu_model(model, )) {
 error_propagate(errp, err);
 return;
 }
diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
index 2c3e05cae3..1b494ecc20 100644
--- a/target/s390x/kvm/kvm.c
+++ b/target/s390x/kvm/kvm.c
@@ -2543,7 +2543,7 @@ static void kvm_s390_configure_apie(bool interpret)
 }
 }
 
-void kvm_s390_apply_cpu_model(const S390CPUModel *model, Error **errp)
+bool kvm_s390_apply_cpu_model(const S390CPUModel *model, Error **errp)
 {
 struct kvm_s390_vm_cpu_processor prop  = {
 .fac_list = { 0 },
@@ -2560,11 +2560,11 @@ void kvm_s390_apply_cpu_model(const S390CPUModel 
*model, Error **errp)
 if (kvm_s390_cmma_available()) {
 kvm_s390_enable_cmma();
 }
-return;
+return true;
 }
 if (!kvm_s390_cpu_models_supported()) {
 error_setg(errp, "KVM doesn't support CPU models");
-return;
+return false;
 }
 prop.cpuid = s390_cpuid_from_cpu_model(model);
 prop.ibc = s390_ibc_from_cpu_model(model);
@@ -2574,19 +2574,19 @@ void kvm_s390_apply_cpu_model(const S390CPUModel 
*model, Error **errp)
 rc = kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, );
 if (rc) {
 error_setg(errp, "KVM: Error configuring the CPU model: %d", rc);
-return;
+return false;
 }
 /* configure cpu features indicated e.g. via SCLP */
 rc = configure_cpu_feat(model->features);
 if (rc) {
 error_setg(errp, "KVM: Error configuring CPU features: %d", rc);
-return;
+return false;
 }
 /* configure cpu subfunctions indicated via query / test bit */
 rc = configure_cpu_subfunc(model->features);
 if (rc) {
 error_setg(errp, "KVM: Error configuring CPU subfunctions: %d", rc);
-return;
+return false;
 }
 /* enable CMM via CMMA */
 if (test_bit(S390_FEAT_CMM, model->features)) {
@@ -2601,8 +2601,9 @@ void kvm_s390_apply_cpu_model(const S390CPUModel *model, 
Error **errp)
 rc = configure_uv_feat_guest(model->features);
 if (rc) {
 error_setg(errp, "KVM: Error configuring CPU UV features %d", rc);
-return;
+return false;
 }
+return true;
 }
 
 void kvm_s390_restart_interrupt(S390CPU *cpu)
-- 
2.44.0

[PULL 10/19] stubs: Add missing qga stubs

[Thomas Huth]

From: Konstantin Kostiuk 

Compilation QGA without system and user fails
./configure --disable-system --disable-user --enable-guest-agent

Link failure:
  /usr/bin/ld: libqemuutil.a.p/util_main-loop.c.o: in function
`os_host_main_loop_wait':
   ../util/main-loop.c:303: undefined reference to `replay_mutex_unlock'
   /usr/bin/ld: ../util/main-loop.c:307: undefined reference to
`replay_mutex_lock'
   /usr/bin/ld: libqemuutil.a.p/util_error-report.c.o: in function
`error_printf':
   ../util/error-report.c:38: undefined reference to `error_vprintf'
   /usr/bin/ld: libqemuutil.a.p/util_error-report.c.o: in function
`vreport':
   ../util/error-report.c:225: undefined reference to `error_vprintf'
   /usr/bin/ld: libqemuutil.a.p/util_qemu-timer.c.o: in function
`timerlist_run_timers':
   ../util/qemu-timer.c:562: undefined reference to `replay_checkpoint'
   /usr/bin/ld: ../util/qemu-timer.c:530: undefined reference to
`replay_checkpoint'
   /usr/bin/ld: ../util/qemu-timer.c:525: undefined reference to
`replay_checkpoint'
   ninja: build stopped: subcommand failed.

Fixes: 3a15604900 ("stubs: include stubs only if needed")

Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Konstantin Kostiuk 
Message-ID: <20240426121347.18843-2-kkost...@redhat.com>
Signed-off-by: Thomas Huth 
---
 stubs/meson.build | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/stubs/meson.build b/stubs/meson.build
index 8ee1fd5753..3b9d42023c 100644
--- a/stubs/meson.build
+++ b/stubs/meson.build
@@ -21,12 +21,12 @@ if have_block
   stub_ss.add(files('migr-blocker.c'))
   stub_ss.add(files('physmem.c'))
   stub_ss.add(files('ram-block.c'))
-  stub_ss.add(files('replay-tools.c'))
   stub_ss.add(files('runstate-check.c'))
   stub_ss.add(files('uuid.c'))
 endif
 
 if have_block or have_ga
+  stub_ss.add(files('replay-tools.c'))
   # stubs for hooks in util/main-loop.c, util/async.c etc.
   stub_ss.add(files('cpus-get-virtual-clock.c'))
   stub_ss.add(files('icount.c'))
@@ -45,6 +45,10 @@ if have_block or have_ga
   stub_ss.add(files('qmp-quit.c'))
 endif
 
+if have_ga
+  stub_ss.add(files('error-printf.c'))
+endif
+
 if have_block or have_user
   stub_ss.add(files('qtest.c'))
   stub_ss.add(files('vm-stop.c'))
-- 
2.44.0

[PULL 03/19] target/s390x/cpu_models: Make kvm_s390_get_host_cpu_model() return boolean

[Thomas Huth]

From: Zhao Liu 

As error.h suggested, the best practice for callee is to return
something to indicate success / failure.

So make kvm_s390_get_host_cpu_model() return boolean and check the
returned boolean in get_max_cpu_model() instead of accessing @err.

Signed-off-by: Zhao Liu 
Reviewed-by: Thomas Huth 
Message-ID: <20240425031232.1586401-5-zhao1@intel.com>
Signed-off-by: Thomas Huth 
---
 target/s390x/cpu_models.h |  2 +-
 target/s390x/cpu_models.c |  9 -
 target/s390x/kvm/kvm.c| 13 +++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/target/s390x/cpu_models.h b/target/s390x/cpu_models.h
index a89c2a15ab..c14aff6c10 100644
--- a/target/s390x/cpu_models.h
+++ b/target/s390x/cpu_models.h
@@ -115,7 +115,7 @@ S390CPUDef const *s390_find_cpu_def(uint16_t type, uint8_t 
gen, uint8_t ec_ga,
 S390FeatBitmap features);
 
 bool kvm_s390_cpu_models_supported(void);
-void kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp);
+bool kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp);
 void kvm_s390_apply_cpu_model(const S390CPUModel *model,  Error **errp);
 
 #endif /* TARGET_S390X_CPU_MODELS_H */
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 052540a866..a0e4acb707 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -560,16 +560,15 @@ S390CPUModel *get_max_cpu_model(Error **errp)
 }
 
 if (kvm_enabled()) {
-kvm_s390_get_host_cpu_model(_model, );
+if (!kvm_s390_get_host_cpu_model(_model, )) {
+error_propagate(errp, err);
+return NULL;
+}
 } else {
 max_model.def = s390_find_cpu_def(QEMU_MAX_CPU_TYPE, QEMU_MAX_CPU_GEN,
   QEMU_MAX_CPU_EC_GA, NULL);
 bitmap_copy(max_model.features, qemu_max_cpu_feat, S390_FEAT_MAX);
 }
-if (err) {
-error_propagate(errp, err);
-return NULL;
-}
 cached = true;
 return _model;
 }
diff --git a/target/s390x/kvm/kvm.c b/target/s390x/kvm/kvm.c
index 4dcd757cdc..2c3e05cae3 100644
--- a/target/s390x/kvm/kvm.c
+++ b/target/s390x/kvm/kvm.c
@@ -2375,7 +2375,7 @@ bool kvm_s390_cpu_models_supported(void)
  KVM_S390_VM_CPU_MACHINE_SUBFUNC);
 }
 
-void kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp)
+bool kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp)
 {
 struct kvm_s390_vm_cpu_machine prop = {};
 struct kvm_device_attr attr = {
@@ -2390,14 +2390,14 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, 
Error **errp)
 
 if (!kvm_s390_cpu_models_supported()) {
 error_setg(errp, "KVM doesn't support CPU models");
-return;
+return false;
 }
 
 /* query the basic cpu model properties */
 rc = kvm_vm_ioctl(kvm_state, KVM_GET_DEVICE_ATTR, );
 if (rc) {
 error_setg(errp, "KVM: Error querying host CPU model: %d", rc);
-return;
+return false;
 }
 
 cpu_type = cpuid_type(prop.cpuid);
@@ -2420,13 +2420,13 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, 
Error **errp)
 rc = query_cpu_feat(model->features);
 if (rc) {
 error_setg(errp, "KVM: Error querying CPU features: %d", rc);
-return;
+return false;
 }
 /* get supported cpu subfunctions indicated via query / test bit */
 rc = query_cpu_subfunc(model->features);
 if (rc) {
 error_setg(errp, "KVM: Error querying CPU subfunctions: %d", rc);
-return;
+return false;
 }
 
 /* PTFF subfunctions might be indicated although kernel support missing */
@@ -2482,7 +2482,7 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, 
Error **errp)
 }
 if (!model->def) {
 error_setg(errp, "KVM: host CPU model could not be identified");
-return;
+return false;
 }
 /* for now, we can only provide the AP feature with HW support */
 if (ap_available()) {
@@ -2506,6 +2506,7 @@ void kvm_s390_get_host_cpu_model(S390CPUModel *model, 
Error **errp)
 /* strip of features that are not part of the maximum model */
 bitmap_and(model->features, model->features, model->def->full_feat,
S390_FEAT_MAX);
+return true;
 }
 
 static int configure_uv_feat_guest(const S390FeatBitmap features)
-- 
2.44.0

[PULL 17/19] tests/qtest/ide-test: Verify READ NATIVE MAX ADDRESS is not limited

[Thomas Huth]

From: Lev Kujawski 

Verify that the ATA command READ NATIVE MAX ADDRESS returns the last
valid CHS tuple for the native device rather than any limit
established by INITIALIZE DEVICE PARAMETERS.

Signed-off-by: Lev Kujawski 
Message-ID: <20221010085229.2431276-2-lku...@mailbox.org>
Signed-off-by: Thomas Huth 
---
 tests/qtest/ide-test.c | 47 +-
 1 file changed, 46 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/ide-test.c b/tests/qtest/ide-test.c
index d6b4f6e36a..90ba6b298b 100644
--- a/tests/qtest/ide-test.c
+++ b/tests/qtest/ide-test.c
@@ -34,7 +34,8 @@
 #include "hw/pci/pci_ids.h"
 #include "hw/pci/pci_regs.h"
 
-#define TEST_IMAGE_SIZE 64 * 1024 * 1024
+/* Specified by ATA (physical) CHS geometry for ~64 MiB device.  */
+#define TEST_IMAGE_SIZE ((130 * 16 * 63) * 512)
 
 #define IDE_PCI_DEV 1
 #define IDE_PCI_FUNC1
@@ -88,11 +89,13 @@ enum {
 enum {
 CMD_DSM = 0x06,
 CMD_DIAGNOSE= 0x90,
+CMD_INIT_DP = 0x91,  /* INITIALIZE DEVICE PARAMETERS */
 CMD_READ_DMA= 0xc8,
 CMD_WRITE_DMA   = 0xca,
 CMD_FLUSH_CACHE = 0xe7,
 CMD_IDENTIFY= 0xec,
 CMD_PACKET  = 0xa0,
+CMD_READ_NATIVE = 0xf8,  /* READ NATIVE MAX ADDRESS */
 
 CMDF_ABORT  = 0x100,
 CMDF_NO_BM  = 0x200,
@@ -560,6 +563,46 @@ static void string_cpu_to_be16(uint16_t *s, size_t bytes)
 }
 }
 
+static void test_specify(void)
+{
+QTestState *qts;
+QPCIDevice *dev;
+QPCIBar bmdma_bar, ide_bar;
+uint16_t cyls;
+uint8_t heads, spt;
+
+qts = ide_test_start(
+"-blockdev driver=file,node-name=hda,filename=%s "
+"-device ide-hd,drive=hda,bus=ide.0,unit=0 ",
+tmp_path[0]);
+
+dev = get_pci_device(qts, _bar, _bar);
+
+/* Initialize drive with zero sectors per track and one head.  */
+qpci_io_writeb(dev, ide_bar, reg_nsectors, 0);
+qpci_io_writeb(dev, ide_bar, reg_device, 0);
+qpci_io_writeb(dev, ide_bar, reg_command, CMD_INIT_DP);
+
+/* READ NATIVE MAX ADDRESS (CHS mode).  */
+qpci_io_writeb(dev, ide_bar, reg_device, 0xa0);
+qpci_io_writeb(dev, ide_bar, reg_command, CMD_READ_NATIVE);
+
+heads = qpci_io_readb(dev, ide_bar, reg_device) & 0xf;
+++heads;
+g_assert_cmpint(heads, ==, 16);
+
+cyls = qpci_io_readb(dev, ide_bar, reg_lba_high) << 8;
+cyls |= qpci_io_readb(dev, ide_bar, reg_lba_middle);
+++cyls;
+g_assert_cmpint(cyls, ==, 130);
+
+spt = qpci_io_readb(dev, ide_bar, reg_lba_low);
+g_assert_cmpint(spt, ==, 63);
+
+ide_test_quit(qts);
+free_pci_device(dev);
+}
+
 static void test_identify(void)
 {
 QTestState *qts;
@@ -1077,6 +1120,8 @@ int main(int argc, char **argv)
 /* Run the tests */
 g_test_init(, , NULL);
 
+qtest_add_func("/ide/read_native", test_specify);
+
 qtest_add_func("/ide/identify", test_identify);
 
 qtest_add_func("/ide/diagnostic", test_diagnostic);
-- 
2.44.0

[PULL 01/19] target/s390x/cpu_model: Make check_compatibility() return boolean

[Thomas Huth]

From: Zhao Liu 

As error.h suggested, the best practice for callee is to return
something to indicate success / failure.

With returned boolean, there's no need to check @err.

Suggested-by: Thomas Huth 
Signed-off-by: Zhao Liu 
Reviewed-by: Thomas Huth 
Message-ID: <20240425031232.1586401-2-zhao1@intel.com>
Signed-off-by: Thomas Huth 
---
 target/s390x/cpu_models.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 8ed3bb6a27..8cb47d905f 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -510,7 +510,7 @@ static void check_compat_model_failed(Error **errp,
 return;
 }
 
-static void check_compatibility(const S390CPUModel *max_model,
+static bool check_compatibility(const S390CPUModel *max_model,
 const S390CPUModel *model, Error **errp)
 {
 ERRP_GUARD();
@@ -518,11 +518,11 @@ static void check_compatibility(const S390CPUModel 
*max_model,
 
 if (model->def->gen > max_model->def->gen) {
 check_compat_model_failed(errp, max_model, "Selected CPU generation is 
too new");
-return;
+return false;
 } else if (model->def->gen == max_model->def->gen &&
model->def->ec_ga > max_model->def->ec_ga) {
 check_compat_model_failed(errp, max_model, "Selected CPU GA level is 
too new");
-return;
+return false;
 }
 
 #ifndef CONFIG_USER_ONLY
@@ -530,14 +530,14 @@ static void check_compatibility(const S390CPUModel 
*max_model,
 error_setg(errp, "The unpack facility is not compatible with "
"the --only-migratable option. You must remove either "
"the 'unpack' facility or the --only-migratable option");
-return;
+return false;
 }
 #endif
 
 /* detect the missing features to properly report them */
 bitmap_andnot(missing, model->features, max_model->features, 
S390_FEAT_MAX);
 if (bitmap_empty(missing, S390_FEAT_MAX)) {
-return;
+return true;
 }
 
 error_setg(errp, " ");
@@ -546,6 +546,7 @@ static void check_compatibility(const S390CPUModel 
*max_model,
   "available in the current configuration: ");
 error_append_hint(errp,
   "Consider a different accelerator, QEMU, or kernel 
version\n");
+return false;
 }
 
 S390CPUModel *get_max_cpu_model(Error **errp)
@@ -605,8 +606,7 @@ void s390_realize_cpu_model(CPUState *cs, Error **errp)
 cpu->model->cpu_ver = max_model->cpu_ver;
 
 check_consistency(cpu->model);
-check_compatibility(max_model, cpu->model, );
-if (err) {
+if (!check_compatibility(max_model, cpu->model, )) {
 error_propagate(errp, err);
 return;
 }
-- 
2.44.0

[PULL 00/19] Misc patches (s390x clean-ups, fixes for crashes, ...)

[Thomas Huth]

 Hi Richard!

The following changes since commit 5fee33d97a7f2e95716417bd164f2f5264acd976:

  Merge tag 'samuel-thibault' of https://people.debian.org/~sthibault/qemu into 
staging (2024-04-29 14:34:25 -0700)

are available in the Git repository at:

  https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-30

for you to fetch changes up to cc6cb422e09592158586279fddeef107df05ecbb:

  .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs (2024-04-30 07:09:22 
+0200)


* Clean-ups for "errp" handling in s390x cpu_model code
* Fix a possible abort in the "edu" device
* Add missing qga stubs for stand-alone qga builds and re-enable qga-ssh-test
* Fix memory corruption caused by the stm32l4x5 uart device
* Update the s390x custom runner to Ubuntu 22.04
* Fix READ NATIVE MAX ADDRESS IDE commands to avoid a possible crash
* Shorten the runtime of Cirrus-CI jobs


Alex Bennée (3):
  build-environment: make some packages optional
  gitlab: migrate the s390x custom machine to 22.04
  gitlab: remove stale s390x-all-linux-static conf hacks

Chris Friedt (3):
  hw: misc: edu: fix 2 off-by-one errors
  hw: misc: edu: rename local vars in edu_check_range
  hw: misc: edu: use qemu_log_mask instead of hw_error

Konstantin Kostiuk (1):
  stubs: Add missing qga stubs

Lev Kujawski (2):
  hw/ide/core.c (cmd_read_native_max): Avoid limited device parameters
  tests/qtest/ide-test: Verify READ NATIVE MAX ADDRESS is not limited

Thomas Huth (4):
  qga: Re-enable the qga-ssh-test when running without fuzzing
  hw/char/stm32l4x5_usart: Fix memory corruption by adding correct 
class_size
  .gitlab-ci.d/cirrus.yml: Shorten the runtime of the macOS and FreeBSD jobs
  .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs

Zhao Liu (6):
  target/s390x/cpu_model: Make check_compatibility() return boolean
  target/s390x/cpu_model: Drop local @err in s390_realize_cpu_model()
  target/s390x/cpu_models: Make kvm_s390_get_host_cpu_model() return boolean
  target/s390x/cpu_models: Drop local @err in get_max_cpu_model()
  target/s390x/cpu_models: Make kvm_s390_apply_cpu_model() return boolean
  target/s390x/cpu_models_sysemu: Drop local @err in apply_cpu_model()

 target/s390x/cpu_models.h  |  4 +-
 hw/char/stm32l4x5_usart.c  |  1 +
 hw/ide/core.c  | 21 --
 hw/misc/edu.c  | 35 
 target/s390x/cpu_models.c  | 25 +---
 target/s390x/cpu_models_sysemu.c   |  5 +--
 target/s390x/kvm/kvm.c | 28 +++--
 tests/qtest/ide-test.c | 47 +-
 .gitlab-ci.d/cirrus.yml| 39 +-
 .gitlab-ci.d/cirrus/kvm-build.yml  | 31 --
 .gitlab-ci.d/custom-runners.yml|  2 +-
 ...untu-20.04-s390x.yml => ubuntu-22.04-s390x.yml} | 32 +++
 qga/meson.build|  5 +--
 scripts/ci/setup/build-environment.yml | 16 ++--
 stubs/meson.build  |  6 ++-
 15 files changed, 149 insertions(+), 148 deletions(-)
 delete mode 100644 .gitlab-ci.d/cirrus/kvm-build.yml
 rename .gitlab-ci.d/custom-runners/{ubuntu-20.04-s390x.yml => 
ubuntu-22.04-s390x.yml} (80%)

[PULL 04/19] target/s390x/cpu_models: Drop local @err in get_max_cpu_model()

[Thomas Huth]

From: Zhao Liu 

Use @errp to fetch error information directly and drop the local
variable @err.

Signed-off-by: Zhao Liu 
Reviewed-by: Thomas Huth 
Message-ID: <20240425031232.1586401-6-zhao1@intel.com>
Signed-off-by: Thomas Huth 
---
 target/s390x/cpu_models.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index a0e4acb707..aae452cfd3 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -551,7 +551,6 @@ static bool check_compatibility(const S390CPUModel 
*max_model,
 
 S390CPUModel *get_max_cpu_model(Error **errp)
 {
-Error *err = NULL;
 static S390CPUModel max_model;
 static bool cached;
 
@@ -560,8 +559,7 @@ S390CPUModel *get_max_cpu_model(Error **errp)
 }
 
 if (kvm_enabled()) {
-if (!kvm_s390_get_host_cpu_model(_model, )) {
-error_propagate(errp, err);
+if (!kvm_s390_get_host_cpu_model(_model, errp)) {
 return NULL;
 }
 } else {
-- 
2.44.0

[PULL 08/19] hw: misc: edu: rename local vars in edu_check_range

[Thomas Huth]

From: Chris Friedt 

This serves to make the local variables a bit less ambiguous.

The latter two arguments are named to match DMA_START, and
DMA_SIZE.

Signed-off-by: Chris Friedt 
Message-ID: <20221018122551.94567-2-cfri...@meta.com>
Signed-off-by: Thomas Huth 
---
 hw/misc/edu.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index 14250e0ac3..e1cb443438 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -103,24 +103,24 @@ static void edu_lower_irq(EduState *edu, uint32_t val)
 }
 }
 
-static void edu_check_range(uint64_t addr, uint64_t size1,
-uint64_t start, uint64_t size2)
+static void edu_check_range(uint64_t xfer_start, uint64_t xfer_size,
+uint64_t dma_start, uint64_t dma_size)
 {
-uint64_t end1 = addr + size1;
-uint64_t end2 = start + size2;
+uint64_t xfer_end = xfer_start + xfer_size;
+uint64_t dma_end = dma_start + dma_size;
 
 /*
  * 1. ensure we aren't overflowing
- * 2. ensure that [addr, end1) is within [start, size2)
+ * 2. ensure that xfer is within dma address range
  */
-if (end2 >= start && end1 >= addr &&
-addr >= start && end1 <= end2) {
+if (dma_end >= dma_start && xfer_end >= xfer_start &&
+xfer_start >= dma_start && xfer_end <= dma_end) {
 return;
 }
 
 hw_error("EDU: DMA range 0x%016"PRIx64"-0x%016"PRIx64
  " out of bounds (0x%016"PRIx64"-0x%016"PRIx64")!",
-addr, end1 - 1, start, end2 - 1);
+xfer_start, xfer_end - 1, dma_start, dma_end - 1);
 }
 
 static dma_addr_t edu_clamp_addr(const EduState *edu, dma_addr_t addr)
-- 
2.44.0

[PULL 02/19] target/s390x/cpu_model: Drop local @err in s390_realize_cpu_model()

[Thomas Huth]

From: Zhao Liu 

Use @errp to fetch error information directly and drop the local
variable @err.

Suggested-by: Thomas Huth 
Signed-off-by: Zhao Liu 
Reviewed-by: Thomas Huth 
Message-ID: <20240425031232.1586401-3-zhao1@intel.com>
Signed-off-by: Thomas Huth 
---
 target/s390x/cpu_models.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 8cb47d905f..052540a866 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -577,7 +577,6 @@ S390CPUModel *get_max_cpu_model(Error **errp)
 void s390_realize_cpu_model(CPUState *cs, Error **errp)
 {
 ERRP_GUARD();
-Error *err = NULL;
 S390CPUClass *xcc = S390_CPU_GET_CLASS(cs);
 S390CPU *cpu = S390_CPU(cs);
 const S390CPUModel *max_model;
@@ -606,8 +605,7 @@ void s390_realize_cpu_model(CPUState *cs, Error **errp)
 cpu->model->cpu_ver = max_model->cpu_ver;
 
 check_consistency(cpu->model);
-if (!check_compatibility(max_model, cpu->model, )) {
-error_propagate(errp, err);
+if (!check_compatibility(max_model, cpu->model, errp)) {
 return;
 }
 
-- 
2.44.0

[PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years

[Thomas Huth]

Old machine types often have bugs or work-arounds that affect our
possibilities to move forward with the QEMU code base (see for example
https://gitlab.com/qemu-project/qemu/-/issues/2213 for a bug that likely
cannot be fixed without breaking live migration with old machine types,
or https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html or
commit ea985d235b86). So instead of going through the process of manually
deprecating old machine types again and again, let's rather add an entry
that can stay, which declares that machine types older than 6 years are
considered as deprecated automatically. Six years should be sufficient to
support the release cycles of most Linux distributions.

Signed-off-by: Thomas Huth 
---
 docs/about/deprecated.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 6d595de3b6..fe69e2d44c 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -220,6 +220,17 @@ is a chance the code will bitrot without anyone noticing.
 System emulator machines
 
 
+Versioned machine types older than 6 years
+''
+
+Starting with the release of QEMU 10.0, versioned machine types older than
+6 years will automatically be considered as deprecated and might be due to
+removal without furthor notice. For example, this affects machine types like
+pc-i440fx-X.Y, pc-q35-X.Y, pseries-X.Y, s390-ccw-virtio-X.Y or virt-X.Y where
+X is the major number and Y is the minor number of the old QEMU version.
+If you are still using machine types from QEMU versions older than 6 years,
+please update your setting to use a newer versioned machine type instead.
+
 Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1)
 
 
-- 
2.44.0

[PATCH] docs/about: Automatically deprecate versioned machine types older than 6 years

[Thomas Huth]

Old machine types often have bugs or work-arounds that affect our
possibilities to move forward with the QEMU code base (see for example
https://gitlab.com/qemu-project/qemu/-/issues/2213 for a bug that likely
cannot be fixed without breaking live migration with old machine types,
or https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg04516.html or
commit ea985d235b86). So instead of going through the process of manually
deprecating old machine types again and again, let's rather add an entry
that can stay, which declares that machine types older than 6 years are
considered as deprecated automatically. Six years should be sufficient to
support the release cycles of most Linux distributions.

Signed-off-by: Thomas Huth 
---
 docs/about/deprecated.rst | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 6d595de3b6..fe69e2d44c 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -220,6 +220,17 @@ is a chance the code will bitrot without anyone noticing.
 System emulator machines
 
 
+Versioned machine types older than 6 years
+''
+
+Starting with the release of QEMU 10.0, versioned machine types older than
+6 years will automatically be considered as deprecated and might be due to
+removal without furthor notice. For example, this affects machine types like
+pc-i440fx-X.Y, pc-q35-X.Y, pseries-X.Y, s390-ccw-virtio-X.Y or virt-X.Y where
+X is the major number and Y is the minor number of the old QEMU version.
+If you are still using machine types from QEMU versions older than 6 years,
+please update your setting to use a newer versioned machine type instead.
+
 Arm ``virt`` machine ``dtb-kaslr-seed`` property (since 7.1)
 
 
-- 
2.44.0
___
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-le...@lists.libvirt.org

Re: [PULL 1/1] hw/ufs: Fix buffer overflow bug

[Thomas Huth]

On 30/04/2024 06.32, Thomas Huth wrote:

On 30/04/2024 02.17, Richard Henderson wrote:

On 4/28/24 20:25, Jeuk Kim wrote:

From: Jeuk Kim 

It fixes the buffer overflow vulnerability in the ufs device.
The bug was detected by sanitizers.

You can reproduce it by:

cat << EOF |\
qemu-system-x86_64 \
-display none -machine accel=qtest -m 512M -M q35 -nodefaults -drive \
file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \
ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio
outl 0xcf8 0x8810
outl 0xcfc 0xe000
outl 0xcf8 0x8804
outw 0xcfc 0x06
write 0xe058 0x1 0xa7
write 0xa 0x1 0x50
EOF

Resolves: #2299
Fixes: 329f16624499 ("hw/ufs: Support for Query Transfer Requests")
Reported-by: Zheyu Ma 
Signed-off-by: Jeuk Kim 
---
  hw/ufs/ufs.c | 8 
  1 file changed, 8 insertions(+)


For some reason this appears to cause failures on s390x:

   https://gitlab.com/qemu-project/qemu/-/jobs/6740883283

All of the timeouts are new with this patch alone applied,
and go away when reverted.

I wasn't aware that these tests used ufs, but I have no
other explanation...


I don't know for sure, but the test failure might instead be related to the 
problem that gets fixed by 
https://lore.kernel.org/qemu-devel/20240429075908.36302-1-th...@redhat.com/ 
... I'm preparing a pull request for that fix right now, so maybe you could 
try this ufs pull request afterwards again to see whether the problem is fixed?


Hmm, thinking about it twice, it cannot be the reason: That bug affects 
aarch64/arm only, and in above CI run, some other targets were failing. So 
the problem must be something else, indeed.


 Thomas

Re: [PULL 1/1] hw/ufs: Fix buffer overflow bug

[Thomas Huth]

On 30/04/2024 06.32, Thomas Huth wrote:

On 30/04/2024 02.17, Richard Henderson wrote:

On 4/28/24 20:25, Jeuk Kim wrote:

From: Jeuk Kim 

It fixes the buffer overflow vulnerability in the ufs device.
The bug was detected by sanitizers.

You can reproduce it by:

cat << EOF |\
qemu-system-x86_64 \
-display none -machine accel=qtest -m 512M -M q35 -nodefaults -drive \
file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \
ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio
outl 0xcf8 0x8810
outl 0xcfc 0xe000
outl 0xcf8 0x8804
outw 0xcfc 0x06
write 0xe058 0x1 0xa7
write 0xa 0x1 0x50
EOF

Resolves: #2299
Fixes: 329f16624499 ("hw/ufs: Support for Query Transfer Requests")
Reported-by: Zheyu Ma 
Signed-off-by: Jeuk Kim 
---
  hw/ufs/ufs.c | 8 
  1 file changed, 8 insertions(+)


For some reason this appears to cause failures on s390x:

   https://gitlab.com/qemu-project/qemu/-/jobs/6740883283

All of the timeouts are new with this patch alone applied,
and go away when reverted.

I wasn't aware that these tests used ufs, but I have no
other explanation...


I don't know for sure, but the test failure might instead be related to the 
problem that gets fixed by 
https://lore.kernel.org/qemu-devel/20240429075908.36302-1-th...@redhat.com/ 
... I'm preparing a pull request for that fix right now, so maybe you could 
try this ufs pull request afterwards again to see whether the problem is fixed?


Hmm, thinking about it twice, it cannot be the reason: That bug affects 
aarch64/arm only, and in above CI run, some other targets were failing. So 
the problem must be something else, indeed.


 Thomas

Re: [PULL 1/1] hw/ufs: Fix buffer overflow bug

[Thomas Huth]

On 30/04/2024 02.17, Richard Henderson wrote:

On 4/28/24 20:25, Jeuk Kim wrote:

From: Jeuk Kim 

It fixes the buffer overflow vulnerability in the ufs device.
The bug was detected by sanitizers.

You can reproduce it by:

cat << EOF |\
qemu-system-x86_64 \
-display none -machine accel=qtest -m 512M -M q35 -nodefaults -drive \
file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \
ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio
outl 0xcf8 0x8810
outl 0xcfc 0xe000
outl 0xcf8 0x8804
outw 0xcfc 0x06
write 0xe058 0x1 0xa7
write 0xa 0x1 0x50
EOF

Resolves: #2299
Fixes: 329f16624499 ("hw/ufs: Support for Query Transfer Requests")
Reported-by: Zheyu Ma 
Signed-off-by: Jeuk Kim 
---
  hw/ufs/ufs.c | 8 
  1 file changed, 8 insertions(+)


For some reason this appears to cause failures on s390x:

   https://gitlab.com/qemu-project/qemu/-/jobs/6740883283

All of the timeouts are new with this patch alone applied,
and go away when reverted.

I wasn't aware that these tests used ufs, but I have no
other explanation...


I don't know for sure, but the test failure might instead be related to the 
problem that gets fixed by 
https://lore.kernel.org/qemu-devel/20240429075908.36302-1-th...@redhat.com/ 
... I'm preparing a pull request for that fix right now, so maybe you could 
try this ufs pull request afterwards again to see whether the problem is fixed?


 Thomas

Re: [PULL 1/1] hw/ufs: Fix buffer overflow bug

[Thomas Huth]

On 30/04/2024 02.17, Richard Henderson wrote:

On 4/28/24 20:25, Jeuk Kim wrote:

From: Jeuk Kim 

It fixes the buffer overflow vulnerability in the ufs device.
The bug was detected by sanitizers.

You can reproduce it by:

cat << EOF |\
qemu-system-x86_64 \
-display none -machine accel=qtest -m 512M -M q35 -nodefaults -drive \
file=null-co://,if=none,id=disk0 -device ufs,id=ufs_bus -device \
ufs-lu,drive=disk0,bus=ufs_bus -qtest stdio
outl 0xcf8 0x8810
outl 0xcfc 0xe000
outl 0xcf8 0x8804
outw 0xcfc 0x06
write 0xe058 0x1 0xa7
write 0xa 0x1 0x50
EOF

Resolves: #2299
Fixes: 329f16624499 ("hw/ufs: Support for Query Transfer Requests")
Reported-by: Zheyu Ma 
Signed-off-by: Jeuk Kim 
---
  hw/ufs/ufs.c | 8 
  1 file changed, 8 insertions(+)


For some reason this appears to cause failures on s390x:

   https://gitlab.com/qemu-project/qemu/-/jobs/6740883283

All of the timeouts are new with this patch alone applied,
and go away when reverted.

I wasn't aware that these tests used ufs, but I have no
other explanation...


I don't know for sure, but the test failure might instead be related to the 
problem that gets fixed by 
https://lore.kernel.org/qemu-devel/20240429075908.36302-1-th...@redhat.com/ 
... I'm preparing a pull request for that fix right now, so maybe you could 
try this ufs pull request afterwards again to see whether the problem is fixed?


 Thomas

Re: [PATCH v2 1/1] stubs: Add missing qga stubs

[Thomas Huth]

On 29/04/2024 12.09, Konstantin Kostiuk wrote:

Hi Paolo,

Are you ok if I merge this patch with other QGA patches?
Or don't you agree with this version of the patch?


Phil asked me in IRC to pick this patch up, so I'll include it in my next 
pull request.


 Thomas

[PATCH] .gitlab-ci.d/cirrus.yml: Shorten the runtime of the macOS and FreeBSD jobs

[Thomas Huth]

Cirrus-CI introduced limitations to the free CI minutes. To avoid that
we are consuming them too fast, let's drop the usual targets that are
not that important since they are either a subset of another target
(like i386 or ppc being a subset of x86_64 or ppc64 respectively), or
since there is still a similar target with the opposite endianness
(like xtensa/xtensael, microblaze/microblazeel etc.).

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

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 74de2edbb4..75df1273bc 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -57,6 +57,7 @@ x64-freebsd-13-build:
 CIRRUS_VM_RAM: 8G
 UPDATE_COMMAND: pkg update; pkg upgrade -y
 INSTALL_COMMAND: pkg install -y
+CONFIGURE_ARGS: 
--target-list-exclude=arm-softmmu,i386-softmmu,microblaze-softmmu,mips64el-softmmu,mipsel-softmmu,mips-softmmu,ppc-softmmu,sh4eb-softmmu,xtensa-softmmu
 TEST_TARGETS: check
 
 aarch64-macos-13-base-build:
@@ -72,6 +73,7 @@ aarch64-macos-13-base-build:
 INSTALL_COMMAND: brew install
 PATH_EXTRA: /opt/homebrew/ccache/libexec:/opt/homebrew/gettext/bin
 PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
+CONFIGURE_ARGS: 
--target-list-exclude=arm-softmmu,i386-softmmu,microblazeel-softmmu,mips64-softmmu,mipsel-softmmu,mips-softmmu,ppc-softmmu,sh4-softmmu,xtensaeb-softmmu
 TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
 
 aarch64-macos-14-base-build:
-- 
2.44.0

[PATCH] hw/char/stm32l4x5_usart: Fix memory corruption by adding correct class_size

[Thomas Huth]

"make check-qtest-aarch64" recently started failing on FreeBSD builds,
and valgrind on Linux also detected that there is something fishy with
the new stm32l4x5-usart: The code forgot to set the correct class_size
here, so the various class_init functions in this file wrote beyond
the allocated buffer when setting the subc->type field.

Fixes: 4fb37aea7e ("hw/char: Implement STM32L4x5 USART skeleton")
Signed-off-by: Thomas Huth 
---
 hw/char/stm32l4x5_usart.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/char/stm32l4x5_usart.c b/hw/char/stm32l4x5_usart.c
index 2627aab832..02f666308c 100644
--- a/hw/char/stm32l4x5_usart.c
+++ b/hw/char/stm32l4x5_usart.c
@@ -617,6 +617,7 @@ static const TypeInfo stm32l4x5_usart_types[] = {
 .parent = TYPE_SYS_BUS_DEVICE,
 .instance_size  = sizeof(Stm32l4x5UsartBaseState),
 .instance_init  = stm32l4x5_usart_base_init,
+.class_size = sizeof(Stm32l4x5UsartBaseClass),
 .class_init = stm32l4x5_usart_base_class_init,
 .abstract   = true,
 }, {
-- 
2.44.0

[PATCH] qga: Re-enable the qga-ssh-test when running without fuzzing

[Thomas Huth]

According to the comment in qga/meson.build, the test got disabled
since there were problems with the fuzzing job. But instead of
disabling this test completely, we should still be fine running
it when fuzzing is disabled.

Signed-off-by: Thomas Huth 
---
 qga/meson.build | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/qga/meson.build b/qga/meson.build
index 1c3d2a3d1b..46c1d83d7f 100644
--- a/qga/meson.build
+++ b/qga/meson.build
@@ -181,12 +181,11 @@ test_env = environment()
 test_env.set('G_TEST_SRCDIR', meson.current_source_dir())
 test_env.set('G_TEST_BUILDDIR', meson.current_build_dir())
 
-# disable qga-ssh-test for now. glib's G_TEST_OPTION_ISOLATE_DIRS triggers
+# disable qga-ssh-test with fuzzing: glib's G_TEST_OPTION_ISOLATE_DIRS triggers
 # the leak detector in build-oss-fuzz Gitlab CI test. we should re-enable
 # this when an alternative is implemented or when the underlying glib
 # issue is identified/fix
-#if host_os != 'windows'
-if false
+if host_os != 'windows' and not get_option('fuzzing')
   srcs = [files('commands-posix-ssh.c')]
   i = 0
   foreach output: qga_qapi_outputs
-- 
2.44.0

Re: [PATCH] .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs

[Thomas Huth]

On 26/04/2024 15.46, Eldon Stegall wrote:

On Fri, Apr 26, 2024 at 02:47:20PM +0200, Thomas Huth wrote:

With regards to NetBSD and OpenBSD, this is not a step backward since these
gitlab jobs were never run anyway (they could only be triggered manually,
but hardly anybody did that AFAIK).

If we want to have proper support for those OSes, I think somebody would
need to set up a custom runner on a beefy KVM-capable server somewhere where
we could run the "make vm-build-*bsd" commands. By the way, are Eldon's CI
runners still around? IIRC they were capable of running KVM ?


My datacenter had a power outage recently, so I disable my runner, and
haven't prioritized bringing it back up until now. I am glad to get this
going again, I'll look at it this weekend.


It's not for me to decide, but IMHO it would be a great possibility to run 
some additional KVM-based tests (like the vm-build-*bsd tests) in QEMU's CI!



There should also be plenty of space to build *bsd VM's. Do pre-existing
upstream BSD images have an nocloud support so that we can build from a
stable updated base? Sorry I'm not super familiar with the BSD
ecosystems, but happy to try to fill in the gaps.


QEMU's test suite comes with a handy way of doing tests on OpenBSD, NetBSD 
and FreeBSD: If you've got a KVM-capable Linux host, you just have to type 
"make vm-build-freebsd J=$(nproc)" to build and test the QEMU sources in a 
FreeBSD VM. It will automatically fetch and install a VM image for you.


 Thomas

Re: [PATCH 3/3] gitlab: remove stale s390x-all-linux-static conf hacks

[Thomas Huth]

On 26/04/2024 17.39, Alex Bennée wrote:

The libssh bug references 18.04 which we are no longer running. We
don't need to disable glusterfs because a linux-user build shouldn't
be trying to link to it anyway.

Signed-off-by: Alex Bennée 
---
  .gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)


Reviewed-by: Thomas Huth 

Re: [PATCH 2/3] gitlab: migrate the s390x custom machine to 22.04

[Thomas Huth]

On 26/04/2024 17.39, Alex Bennée wrote:

20.04 is dead (from QEMU's point of view), long live 22.04!

Signed-off-by: Alex Bennée 
---
  .gitlab-ci.d/custom-runners.yml   |  2 +-
  ...20.04-s390x.yml => ubuntu-22.04-s390x.yml} | 28 +--
  2 files changed, 15 insertions(+), 15 deletions(-)
  rename .gitlab-ci.d/custom-runners/{ubuntu-20.04-s390x.yml => 
ubuntu-22.04-s390x.yml} (88%)


Reviewed-by: Thomas Huth 

Re: [PATCH 1/3] build-environment: make some packages optional

[Thomas Huth]

On 26/04/2024 17.39, Alex Bennée wrote:

Upgrading the s390x runner exposed some packages are not available for
it. Add an additional optional stage we only enable for arm64/x86_64
for now.

Signed-off-by: Alex Bennée 
---
  scripts/ci/setup/build-environment.yml | 16 +---
  1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/scripts/ci/setup/build-environment.yml 
b/scripts/ci/setup/build-environment.yml
index f344d1a850..de0d866a1e 100644
--- a/scripts/ci/setup/build-environment.yml
+++ b/scripts/ci/setup/build-environment.yml
@@ -95,7 +95,6 @@
- libpam0g-dev
- libpcre2-dev
- libpixman-1-dev
-  - libpmem-dev
- libpng-dev
- libpulse-dev
- librbd-dev
@@ -107,7 +106,6 @@
- libslirp-dev
- libsnappy-dev
- libspice-protocol-dev
-  - libspice-server-dev
- libssh-dev
- libsystemd-dev
- libtasn1-6-dev
@@ -119,7 +117,6 @@
- libvdeplug-dev
- libvirglrenderer-dev
- libvte-2.91-dev
-  - libxen-dev
- libxml2-dev
- libzstd-dev
- llvm
@@ -156,6 +153,19 @@
  - ansible_facts['distribution'] == 'Ubuntu'
  - ansible_facts['distribution_version'] == '22.04'
  
+# not all packages are available for all architectures

+- name: Install additional packages to build QEMU on Ubuntu 22.04
+  package:
+name:
+  - libpmem-dev
+  - libspice-server-dev
+  - libxen-dev
+state: present
+  when:
+- ansible_facts['distribution'] == 'Ubuntu'
+- ansible_facts['distribution_version'] == '22.04'
+- ansible_facts['architecture'] == 'aarch64' or 
ansible_facts['architecture'] == 'x86_64'
+
  - name: Install armhf cross-compile packages to build QEMU on AArch64 
Ubuntu 22.04
package:
  name:


Reviewed-by: Thomas Huth 

Re: [PATCH] .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs

[Thomas Huth]

On 26/04/2024 14.30, Peter Maydell wrote:

On Fri, 26 Apr 2024 at 12:38, Thomas Huth  wrote:


During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.

Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.


So what's the plan to keep BSD CI coverage? This seems
like a step backwards towards "the person handling the
pullreq merges has to do some local private ad-hoc testing
too" :-(


With regards to NetBSD and OpenBSD, this is not a step backward since these 
gitlab jobs were never run anyway (they could only be triggered manually, 
but hardly anybody did that AFAIK).


If we want to have proper support for those OSes, I think somebody would 
need to set up a custom runner on a beefy KVM-capable server somewhere where 
we could run the "make vm-build-*bsd" commands. By the way, are Eldon's CI 
runners still around? IIRC they were capable of running KVM ?


 Thomas

[PATCH v2] KVM: selftests: Use TAP interface in the set_memory_region test

[Thomas Huth]

Use the kselftest_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing. (Note: We are not using the KVM_ONE_VCPU_TEST_SUITE()
macro here since these tests are creating their VMs with the
vm_create_barebones() function, not with vm_create_with_one_vcpu())

Reviewed-by: Andrew Jones 
Signed-off-by: Thomas Huth 
---
 v2:
 - Rebase to linux-next branch
 - Make "loops" variable static
 - Added Andrew's Reviewed-by

 .../selftests/kvm/set_memory_region_test.c| 86 +--
 1 file changed, 42 insertions(+), 44 deletions(-)

diff --git a/tools/testing/selftests/kvm/set_memory_region_test.c 
b/tools/testing/selftests/kvm/set_memory_region_test.c
index 68c899d27561..a5c9bee5235a 100644
--- a/tools/testing/selftests/kvm/set_memory_region_test.c
+++ b/tools/testing/selftests/kvm/set_memory_region_test.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include "kselftest_harness.h"
 
 /*
  * s390x needs at least 1MB alignment, and the x86_64 MOVE/DELETE tests need a
@@ -38,6 +39,8 @@ extern const uint64_t final_rip_end;
 
 static sem_t vcpu_ready;
 
+static int loops;
+
 static inline uint64_t guest_spin_on_val(uint64_t spin_val)
 {
uint64_t val;
@@ -219,6 +222,13 @@ static void test_move_memory_region(void)
kvm_vm_free(vm);
 }
 
+TEST(move_in_use_region)
+{
+   ksft_print_msg("Testing MOVE of in-use region, %d loops\n", loops);
+   for (int i = 0; i < loops; i++)
+   test_move_memory_region();
+}
+
 static void guest_code_delete_memory_region(void)
 {
uint64_t val;
@@ -308,12 +318,19 @@ static void test_delete_memory_region(void)
kvm_vm_free(vm);
 }
 
-static void test_zero_memory_regions(void)
+TEST(delete_in_use_region)
+{
+   ksft_print_msg("Testing DELETE of in-use region, %d loops\n", loops);
+   for (int i = 0; i < loops; i++)
+   test_delete_memory_region();
+}
+
+TEST(zero_memory_regions)
 {
struct kvm_vcpu *vcpu;
struct kvm_vm *vm;
 
-   pr_info("Testing KVM_RUN with zero added memory regions\n");
+   ksft_print_msg("Testing KVM_RUN with zero added memory regions\n");
 
vm = vm_create_barebones();
vcpu = __vm_vcpu_add(vm, 0);
@@ -326,7 +343,7 @@ static void test_zero_memory_regions(void)
 }
 #endif /* __x86_64__ */
 
-static void test_invalid_memory_region_flags(void)
+TEST(invalid_memory_region_flags)
 {
uint32_t supported_flags = KVM_MEM_LOG_DIRTY_PAGES;
const uint32_t v2_only_flags = KVM_MEM_GUEST_MEMFD;
@@ -389,7 +406,7 @@ static void test_invalid_memory_region_flags(void)
  * Test it can be added memory slots up to KVM_CAP_NR_MEMSLOTS, then any
  * tentative to add further slots should fail.
  */
-static void test_add_max_memory_regions(void)
+TEST(add_max_memory_regions)
 {
int ret;
struct kvm_vm *vm;
@@ -408,13 +425,13 @@ static void test_add_max_memory_regions(void)
max_mem_slots = kvm_check_cap(KVM_CAP_NR_MEMSLOTS);
TEST_ASSERT(max_mem_slots > 0,
"KVM_CAP_NR_MEMSLOTS should be greater than 0");
-   pr_info("Allowed number of memory slots: %i\n", max_mem_slots);
+   ksft_print_msg("Allowed number of memory slots: %i\n", max_mem_slots);
 
vm = vm_create_barebones();
 
/* Check it can be added memory slots up to the maximum allowed */
-   pr_info("Adding slots 0..%i, each memory region with %dK size\n",
-   (max_mem_slots - 1), MEM_REGION_SIZE >> 10);
+   ksft_print_msg("Adding slots 0..%i, each memory region with %dK size\n",
+  (max_mem_slots - 1), MEM_REGION_SIZE >> 10);
 
mem = mmap(NULL, (size_t)max_mem_slots * MEM_REGION_SIZE + alignment,
   PROT_READ | PROT_WRITE,
@@ -455,12 +472,21 @@ static void test_invalid_guest_memfd(struct kvm_vm *vm, 
int memfd,
TEST_ASSERT(r == -1 && errno == EINVAL, "%s", msg);
 }
 
-static void test_add_private_memory_region(void)
+static bool has_cap_guest_memfd(void)
+{
+   return kvm_has_cap(KVM_CAP_GUEST_MEMFD) &&
+  (kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM));
+}
+
+TEST(add_private_memory_region)
 {
struct kvm_vm *vm, *vm2;
int memfd, i;
 
-   pr_info("Testing ADD of KVM_MEM_GUEST_MEMFD memory regions\n");
+   if (!has_cap_guest_memfd())
+   SKIP(return, "Missing KVM_MEM_GUEST_MEMFD / 
KVM_X86_SW_PROTECTED_VM");
+
+   ksft_print_msg("Testing ADD of KVM_MEM_GUEST_MEMFD memory regions\n");
 
vm = vm_create_barebones_type(KVM_X86_SW_PROTECTED_VM);
 
@@ -491,13 +517,16 @@ static void test_add_private_memory_region(void)
kvm_vm_free(vm);
 }
 
-static void test_add_overlapping_private_memory_regions(void)
+T

[PATCH] .gitlab-ci.d/cirrus: Remove the netbsd and openbsd jobs

[Thomas Huth]

During the past months, the netbsd and openbsd jobs in the Cirrus-CI
were broken most of the time - the setup to run a BSD in KVM on Cirrus-CI
from gitlab via the cirrus-run script was very fragile, and since the
jobs were not run by default, it used to bitrot very fast.

Now Cirrus-CI also introduce a limit on the amount of free CI minutes
that you get there, so it is not appealing at all anymore to run
these BSDs in this setup - it's better to run the checks locally via
"make vm-build-openbsd" and "make vm-build-netbsd" instead. Thus let's
remove these CI jobs now.

Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/cirrus.yml   | 37 ---
 .gitlab-ci.d/cirrus/kvm-build.yml | 31 --
 2 files changed, 68 deletions(-)
 delete mode 100644 .gitlab-ci.d/cirrus/kvm-build.yml

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 4671f069c3..74de2edbb4 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -89,40 +89,3 @@ aarch64-macos-14-base-build:
 PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
 TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
 QEMU_JOB_OPTIONAL: 1
-
-
-# The following jobs run VM-based tests via KVM on a Linux-based Cirrus-CI job
-.cirrus_kvm_job:
-  extends: .base_job_template
-  stage: build
-  image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:master
-  needs: []
-  timeout: 80m
-  script:
-- sed -e "s|[@]CI_REPOSITORY_URL@|$CI_REPOSITORY_URL|g"
-  -e "s|[@]CI_COMMIT_REF_NAME@|$CI_COMMIT_REF_NAME|g"
-  -e "s|[@]CI_COMMIT_SHA@|$CI_COMMIT_SHA|g"
-  -e "s|[@]NAME@|$NAME|g"
-  -e "s|[@]CONFIGURE_ARGS@|$CONFIGURE_ARGS|g"
-  -e "s|[@]TEST_TARGETS@|$TEST_TARGETS|g"
-  <.gitlab-ci.d/cirrus/kvm-build.yml >.gitlab-ci.d/cirrus/$NAME.yml
-- cat .gitlab-ci.d/cirrus/$NAME.yml
-- cirrus-run -v --show-build-log always .gitlab-ci.d/cirrus/$NAME.yml
-  variables:
-QEMU_JOB_CIRRUS: 1
-QEMU_JOB_OPTIONAL: 1
-
-
-x86-netbsd:
-  extends: .cirrus_kvm_job
-  variables:
-NAME: netbsd
-CONFIGURE_ARGS: --target-list=x86_64-softmmu,ppc64-softmmu,aarch64-softmmu
-TEST_TARGETS: check
-
-x86-openbsd:
-  extends: .cirrus_kvm_job
-  variables:
-NAME: openbsd
-CONFIGURE_ARGS: --target-list=i386-softmmu,riscv64-softmmu,mips64-softmmu
-TEST_TARGETS: check
diff --git a/.gitlab-ci.d/cirrus/kvm-build.yml 
b/.gitlab-ci.d/cirrus/kvm-build.yml
deleted file mode 100644
index a93881aa8b..00
--- a/.gitlab-ci.d/cirrus/kvm-build.yml
+++ /dev/null
@@ -1,31 +0,0 @@
-container:
-  image: fedora:35
-  cpu: 4
-  memory: 8Gb
-  kvm: true
-
-env:
-  CIRRUS_CLONE_DEPTH: 1
-  CI_REPOSITORY_URL: "@CI_REPOSITORY_URL@"
-  CI_COMMIT_REF_NAME: "@CI_COMMIT_REF_NAME@"
-  CI_COMMIT_SHA: "@CI_COMMIT_SHA@"
-
-@NAME@_task:
-  @NAME@_vm_cache:
-folder: $HOME/.cache/qemu-vm
-  install_script:
-- dnf update -y
-- dnf install -y git make openssh-clients qemu-img qemu-system-x86 wget 
meson
-  clone_script:
-- git clone --depth 100 "$CI_REPOSITORY_URL" .
-- git fetch origin "$CI_COMMIT_REF_NAME"
-- git reset --hard "$CI_COMMIT_SHA"
-  build_script:
-- if [ -f $HOME/.cache/qemu-vm/images/@NAME@.img ]; then
-make vm-build-@NAME@ J=$(getconf _NPROCESSORS_ONLN)
-  EXTRA_CONFIGURE_OPTS="@CONFIGURE_ARGS@"
-  BUILD_TARGET="@TEST_TARGETS@" ;
-  else
-make vm-build-@NAME@ J=$(getconf _NPROCESSORS_ONLN) BUILD_TARGET=help
-  EXTRA_CONFIGURE_OPTS="--disable-system --disable-user 
--disable-tools" ;
-  fi
-- 
2.44.0

Re: [PATCH] KVM: selftests: Use TAP interface in the set_memory_region test

[Thomas Huth]

On 26/04/2024 12.07, Muhammad Usama Anjum wrote:

On 4/26/24 1:55 PM, Thomas Huth wrote:

Use the kselftest_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing. (Note: We are not using the KVM_ONE_VCPU_TEST_SUITE()
macro here since these tests are creating their VMs with the
vm_create_barebones() function, not with vm_create_with_one_vcpu())

Thank you for the patch. I'm unable to apply the patch on next-20240426.


Ah, I was using the master branch ... it's a context conflict due to 
https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?id=dfc083a181bac ... 
I'll send a v2 rebased to the next branch.


 Thomas

[PATCH] KVM: selftests: Use TAP interface in the set_memory_region test

[Thomas Huth]

Use the kselftest_harness.h interface in this test to get TAP
output, so that it is easier for the user to see what the test
is doing. (Note: We are not using the KVM_ONE_VCPU_TEST_SUITE()
macro here since these tests are creating their VMs with the
vm_create_barebones() function, not with vm_create_with_one_vcpu())

Signed-off-by: Thomas Huth 
---
 .../selftests/kvm/set_memory_region_test.c| 86 +--
 1 file changed, 42 insertions(+), 44 deletions(-)

diff --git a/tools/testing/selftests/kvm/set_memory_region_test.c 
b/tools/testing/selftests/kvm/set_memory_region_test.c
index bd57d991e27d..4db6a66a3001 100644
--- a/tools/testing/selftests/kvm/set_memory_region_test.c
+++ b/tools/testing/selftests/kvm/set_memory_region_test.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include "kselftest_harness.h"
 
 /*
  * s390x needs at least 1MB alignment, and the x86_64 MOVE/DELETE tests need a
@@ -38,6 +39,8 @@ extern const uint64_t final_rip_end;
 
 static sem_t vcpu_ready;
 
+int loops;
+
 static inline uint64_t guest_spin_on_val(uint64_t spin_val)
 {
uint64_t val;
@@ -219,6 +222,13 @@ static void test_move_memory_region(void)
kvm_vm_free(vm);
 }
 
+TEST(move_in_use_region)
+{
+   ksft_print_msg("Testing MOVE of in-use region, %d loops\n", loops);
+   for (int i = 0; i < loops; i++)
+   test_move_memory_region();
+}
+
 static void guest_code_delete_memory_region(void)
 {
uint64_t val;
@@ -308,12 +318,19 @@ static void test_delete_memory_region(void)
kvm_vm_free(vm);
 }
 
-static void test_zero_memory_regions(void)
+TEST(delete_in_use_region)
+{
+   ksft_print_msg("Testing DELETE of in-use region, %d loops\n", loops);
+   for (int i = 0; i < loops; i++)
+   test_delete_memory_region();
+}
+
+TEST(zero_memory_regions)
 {
struct kvm_vcpu *vcpu;
struct kvm_vm *vm;
 
-   pr_info("Testing KVM_RUN with zero added memory regions\n");
+   ksft_print_msg("Testing KVM_RUN with zero added memory regions\n");
 
vm = vm_create_barebones();
vcpu = __vm_vcpu_add(vm, 0);
@@ -326,7 +343,7 @@ static void test_zero_memory_regions(void)
 }
 #endif /* __x86_64__ */
 
-static void test_invalid_memory_region_flags(void)
+TEST(invalid_memory_region_flags)
 {
uint32_t supported_flags = KVM_MEM_LOG_DIRTY_PAGES;
const uint32_t v2_only_flags = KVM_MEM_GUEST_MEMFD;
@@ -389,7 +406,7 @@ static void test_invalid_memory_region_flags(void)
  * Test it can be added memory slots up to KVM_CAP_NR_MEMSLOTS, then any
  * tentative to add further slots should fail.
  */
-static void test_add_max_memory_regions(void)
+TEST(add_max_memory_regions)
 {
int ret;
struct kvm_vm *vm;
@@ -408,13 +425,13 @@ static void test_add_max_memory_regions(void)
max_mem_slots = kvm_check_cap(KVM_CAP_NR_MEMSLOTS);
TEST_ASSERT(max_mem_slots > 0,
"KVM_CAP_NR_MEMSLOTS should be greater than 0");
-   pr_info("Allowed number of memory slots: %i\n", max_mem_slots);
+   ksft_print_msg("Allowed number of memory slots: %i\n", max_mem_slots);
 
vm = vm_create_barebones();
 
/* Check it can be added memory slots up to the maximum allowed */
-   pr_info("Adding slots 0..%i, each memory region with %dK size\n",
-   (max_mem_slots - 1), MEM_REGION_SIZE >> 10);
+   ksft_print_msg("Adding slots 0..%i, each memory region with %dK size\n",
+  (max_mem_slots - 1), MEM_REGION_SIZE >> 10);
 
mem = mmap(NULL, (size_t)max_mem_slots * MEM_REGION_SIZE + alignment,
   PROT_READ | PROT_WRITE,
@@ -455,12 +472,21 @@ static void test_invalid_guest_memfd(struct kvm_vm *vm, 
int memfd,
TEST_ASSERT(r == -1 && errno == EINVAL, "%s", msg);
 }
 
-static void test_add_private_memory_region(void)
+static bool has_cap_guest_memfd(void)
+{
+   return kvm_has_cap(KVM_CAP_GUEST_MEMFD) &&
+  (kvm_check_cap(KVM_CAP_VM_TYPES) & BIT(KVM_X86_SW_PROTECTED_VM));
+}
+
+TEST(add_private_memory_region)
 {
struct kvm_vm *vm, *vm2;
int memfd, i;
 
-   pr_info("Testing ADD of KVM_MEM_GUEST_MEMFD memory regions\n");
+   if (!has_cap_guest_memfd())
+   SKIP(return, "Missing KVM_MEM_GUEST_MEMFD / 
KVM_X86_SW_PROTECTED_VM");
+
+   ksft_print_msg("Testing ADD of KVM_MEM_GUEST_MEMFD memory regions\n");
 
vm = vm_create_barebones_protected_vm();
 
@@ -491,13 +517,16 @@ static void test_add_private_memory_region(void)
kvm_vm_free(vm);
 }
 
-static void test_add_overlapping_private_memory_regions(void)
+TEST(add_overlapping_private_memory_regions)
 {
struct kvm_vm *vm;
int memfd;
int r;
 
-   pr_info("Testing ADD of overlapping KVM_MEM_GUEST_MEMFD memory 
reg

Re: [PATCH 0/3] Make it possible to compile the x86 binaries without FDC

[Thomas Huth]

On 25/04/2024 22.56, Philippe Mathieu-Daudé wrote:

Hi Thomas,

On 25/4/24 20:43, Thomas Huth wrote:

For downstream versions of QEMU, we'd like to be able to compile QEMU
without the FDC code included (since it's not required for modern VMs
anymore and the FDC code has rather a bad reputation, see the VENOM CVE).


IIRC you still need to keep the i440fx+piix machine DS due to
migration compatibility, right?

Are you able to migrate a VM booted with FDC to a non-FDC one?


Migration from a machine with FDC to one without is likely not possible. But 
that's also not the purpose of this series. It's about having the 
possibility to build a QEMU binary without FDC at all in case you don't have 
to support old machine types with FDC anymore.



The q35 machine can already be instantiated without FDC, but for being
able to link a binary without the FDC code, the Kconfig file needs some
tweaks and there are two spots in the pc code that directly call functions
from the FDC code - those need to be disabled via #ifdefs.


Is it useful to you to have q35 without FDC but i440fx+piix with?
Or are you removing it from i440fx+piix due to shared code with q35?


I think it might get useful.

 Thomas

[PATCH 0/3] Make it possible to compile the x86 binaries without FDC

[Thomas Huth]

For downstream versions of QEMU, we'd like to be able to compile QEMU
without the FDC code included (since it's not required for modern VMs
anymore and the FDC code has rather a bad reputation, see the VENOM CVE).

The q35 machine can already be instantiated without FDC, but for being
able to link a binary without the FDC code, the Kconfig file needs some
tweaks and there are two spots in the pc code that directly call functions
from the FDC code - those need to be disabled via #ifdefs.

The third patch changes the i440fx and isapc machine types so that
they can work without the FDC device, too, in case it has not been
compiled into the binary. It's marked as RFC since I assume that the
FDC was originally a fix compononent of these motherboards, so I'm
unsure whether we should allow the disablement there. OTOH, it seems
to work fine, and the FDC is only disabled when it is not available
in the binary, so I hope this patch is fine, too.

Thomas Huth (3):
  hw/i386/pc: Allow to compile without CONFIG_FDC_ISA
  hw/i386/Kconfig: Allow to compile Q35 without FDC_ISA
  hw/i386: Add the possibility to use i440fx and isapc without FDC

 hw/i386/pc.c  | 13 +
 hw/i386/pc_piix.c |  6 --
 hw/i386/Kconfig   |  2 +-
 3 files changed, 14 insertions(+), 7 deletions(-)

-- 
2.44.0

[PATCH 2/3] hw/i386/Kconfig: Allow to compile Q35 without FDC_ISA

[Thomas Huth]

The q35 machine can be used without floppy disk controller (FDC),
but due to our current Kconfig setup, the FDC code is still always
included in the binary. To fix this, the "PC" config option should
only imply the "FDC_ISA" instead of always selecting it.

The i440fx and the isa-pc machine currently always instantiate
the FDC, so we have to add the select statements now there instead.

Signed-off-by: Thomas Huth 
---
 hw/i386/Kconfig | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index a6ee052f9a..0b08580862 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -32,7 +32,7 @@ config PC
 imply VGA_PCI
 imply VIRTIO_VGA
 imply NVDIMM
-select FDC_ISA
+imply FDC_ISA
 select I8259
 select I8254
 select PCKBD
@@ -70,6 +70,7 @@ config I440FX
 imply VMPORT
 imply VMMOUSE
 select ACPI_PIIX4
+select FDC_ISA
 select PC_PCI
 select PC_ACPI
 select PCI_I440FX
@@ -83,6 +84,7 @@ config ISAPC
 bool
 imply VGA_ISA
 select ISA_BUS
+select FDC_ISA
 select PC
 select IDE_ISA
 # FIXME: it is in the same file as i440fx, and does not compile
-- 
2.44.0

[PATCH 1/3] hw/i386/pc: Allow to compile without CONFIG_FDC_ISA

[Thomas Huth]

The q35 machine can work without FDC. But to be able to also link
a QEMU binary that does not include the FDC code, we have to make
it possible to disable the spots that call into the FDC code.

Signed-off-by: Thomas Huth 
---
 hw/i386/pc.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 08c7de416f..93c48f6747 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -439,16 +439,19 @@ static void pc_boot_set(void *opaque, const char 
*boot_device, Error **errp)
 
 static void pc_cmos_init_floppy(MC146818RtcState *rtc_state, ISADevice *floppy)
 {
-int val, nb, i;
+int val, nb;
 FloppyDriveType fd_type[2] = { FLOPPY_DRIVE_TYPE_NONE,
FLOPPY_DRIVE_TYPE_NONE };
 
+#ifdef CONFIG_FDC_ISA
 /* floppy type */
 if (floppy) {
-for (i = 0; i < 2; i++) {
+for (int i = 0; i < 2; i++) {
 fd_type[i] = isa_fdc_get_drive_type(floppy, i);
 }
 }
+#endif
+
 val = (cmos_get_fd_drive_type(fd_type[0]) << 4) |
 cmos_get_fd_drive_type(fd_type[1]);
 mc146818rtc_set_cmos_data(rtc_state, 0x10, val);
@@ -1132,7 +1135,7 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl,
 int i;
 DriveInfo *fd[MAX_FD];
 qemu_irq *a20_line;
-ISADevice *fdc, *i8042, *port92, *vmmouse;
+ISADevice *i8042, *port92, *vmmouse;
 
 serial_hds_isa_init(isa_bus, 0, MAX_ISA_SERIAL_PORTS);
 parallel_hds_isa_init(isa_bus, MAX_PARALLEL_PORTS);
@@ -1142,11 +1145,13 @@ static void pc_superio_init(ISABus *isa_bus, bool 
create_fdctrl,
 create_fdctrl |= !!fd[i];
 }
 if (create_fdctrl) {
-fdc = isa_new(TYPE_ISA_FDC);
+#ifdef CONFIG_FDC_ISA
+ISADevice *fdc = isa_new(TYPE_ISA_FDC);
 if (fdc) {
 isa_realize_and_unref(fdc, isa_bus, _fatal);
 isa_fdc_init_drives(fdc, fd);
 }
+#endif
 }
 
 if (!create_i8042) {
-- 
2.44.0

[RFC PATCH 3/3] hw/i386: Add the possibility to use i440fx and isapc without FDC

[Thomas Huth]

The i440fx and the isapc machines can be used in binaries without
FDC, too. We just have to make sure that they don't try to instantiate
the FDC when it is not available.

Signed-off-by: Thomas Huth 
---
 hw/i386/pc_piix.c | 6 --
 hw/i386/Kconfig   | 2 --
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 8850c49c66..99efb3c45c 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -317,8 +317,8 @@ static void pc_init1(MachineState *machine, const char 
*pci_type)
 }
 
 /* init basic PC hardware */
-pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc, true,
- 0x4);
+pc_basic_device_init(pcms, isa_bus, x86ms->gsi, x86ms->rtc,
+ !MACHINE_CLASS(pcmc)->no_floppy, 0x4);
 
 pc_nic_init(pcmc, isa_bus, pcms->pcibus);
 
@@ -501,6 +501,7 @@ static void pc_i440fx_machine_options(MachineClass *m)
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
 m->default_nic = "e1000";
+m->no_floppy = !module_object_class_by_name(TYPE_ISA_FDC);
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_RAMFB_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_VMBUS_BRIDGE);
@@ -931,6 +932,7 @@ static void isapc_machine_options(MachineClass *m)
 pcmc->has_reserved_memory = false;
 m->default_nic = "ne2k_isa";
 m->default_cpu_type = X86_CPU_TYPE_NAME("486");
+m->no_floppy = !module_object_class_by_name(TYPE_ISA_FDC);
 m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL);
 }
 
diff --git a/hw/i386/Kconfig b/hw/i386/Kconfig
index 0b08580862..f2ef6d1ef2 100644
--- a/hw/i386/Kconfig
+++ b/hw/i386/Kconfig
@@ -70,7 +70,6 @@ config I440FX
 imply VMPORT
 imply VMMOUSE
 select ACPI_PIIX4
-select FDC_ISA
 select PC_PCI
 select PC_ACPI
 select PCI_I440FX
@@ -84,7 +83,6 @@ config ISAPC
 bool
 imply VGA_ISA
 select ISA_BUS
-select FDC_ISA
 select PC
 select IDE_ISA
 # FIXME: it is in the same file as i440fx, and does not compile
-- 
2.44.0

Re: [PATCH v2 4/7] target/s390x/cpu_models: Make kvm_s390_get_host_cpu_model() return boolean

[Thomas Huth]

On 25/04/2024 05.12, Zhao Liu wrote:

As error.h suggested, the best practice for callee is to return
something to indicate success / failure.

So make kvm_s390_get_host_cpu_model() return boolean and check the
returned boolean in get_max_cpu_model() instead of accessing @err.

Signed-off-by: Zhao Liu 
---
  target/s390x/cpu_models.c |  9 -
  target/s390x/cpu_models.h |  2 +-
  target/s390x/kvm/kvm.c| 13 +++--
  3 files changed, 12 insertions(+), 12 deletions(-)


Reviewed-by: Thomas Huth 

Re: [PULL 00/17] CI job updates, header cleanups and other misc patches

[Thomas Huth]

On 25/04/2024 17.04, Richard Henderson wrote:

On 4/24/24 22:11, Thomas Huth wrote:

On 24/04/2024 18.21, Richard Henderson wrote:

On 4/24/24 00:57, Thomas Huth wrote:
The following changes since commit 
13b1e9667737132440f4d500c31cb69320c6b15a:


   Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into 
staging (2024-04-23 17:35:57 -0700)


are available in the Git repository at:

   https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-24

for you to fetch changes up to 8f29bab03ea22694a127ee33edeb4ce99eeb124e:

   target/s390x: Remove KVM stubs in cpu_models.h (2024-04-24 09:45:02 
+0200)



* Update OpenBSD CI image to 7.5
* Update/remove Ubuntu 20.04 CI jobs
* Update CentOS 8 CI jobs to CentOS 9
* Some clean-ups and improvements to travis.yml
* Minor test fixes
* s390x header clean-ups
* Doc updates


This introduces a failure in the migration-compat-x86_64 job:

https://gitlab.com/qemu-project/qemu/-/jobs/6707154868


It wasn't failing for me:

  https://gitlab.com/thuth/qemu/-/jobs/6702058896

And according to the diffstat of my pull request, it's only touching test 
files, docs, and s390x stuff, so I somehow fail to see how it could 
influence x86 migration at a first glance. It also looks like the job is 
running on opensuse, and not on CentOS or Ubuntu, so it should likely not 
be influenced by the changes in this PR.


Could you please hit the re-run button of that job? If it then passes, 
we're likely rather facing an intermitted failure that might have been 
introduced earlier already...


It did pass when re-run.


Ok, thanks! So it's likely and intermitted problem indeed...

I've now submitted a v2 of the pull request where I just dropped the other 
problematic patch that tried to update the custom CentOS runner ... I hope 
that PR should be fine now.


 Thomas

Re: [PATCH] ci: move external build environment setups to CentOS Stream 9

[Thomas Huth]

On 12/04/2024 12.37, Paolo Bonzini wrote:

RHEL 9 (and thus also the derivatives) are available since two years
now, so according to QEMU's support policy, we can drop the active
support for the previous major version 8 now.

Thus upgrade our CentOS Stream build environment playbooks to major
version 9 now.

Signed-off-by: Paolo Bonzini 
---
  .../stream/{8 => 9}/build-environment.yml | 31 ++---
  .../stream/{8 => 9}/x86_64/configure  |  4 +-
  .../stream/{8 => 9}/x86_64/test-avocado   |  0
  scripts/ci/setup/build-environment.yml| 44 +++
  4 files changed, 34 insertions(+), 45 deletions(-)
  rename scripts/ci/org.centos/stream/{8 => 9}/build-environment.yml (75%)
  rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/configure (98%)
  rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/test-avocado (100%)


 Hi Paolo!

Not sure whether you've seen my busted pull request, but anyway: It seems 
like this was not enough to update the custom runner. You also need to 
update .gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml for this.


By the way, who has access to the s390x custom runner and could update it to 
Ubuntu 22.04 now? It still seems to work with 20.04 which will be out of 
support from the QEMU POV next week...


 Thomas

[PULL v2 00/16] CI job updates, header cleanups and other misc patches

[Thomas Huth]

The following changes since commit 5da72194df36535d773c8bdc951529ecd5e31707:

  Merge tag 'pull-tcg-20240424' of https://gitlab.com/rth7680/qemu into staging 
(2024-04-24 15:51:49 -0700)

are available in the Git repository at:

  https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-25

for you to fetch changes up to 17523a38194d80f2955c6a8e0702e0fc86dd083d:

  target/s390x: Remove KVM stubs in cpu_models.h (2024-04-25 15:15:25 +0200)


* Update OpenBSD CI image to 7.5
* Update/remove Ubuntu 20.04 CI jobs
* Update (most) CentOS 8 CI jobs to CentOS 9
* Some clean-ups and improvements to travis.yml
* Minor test fixes
* s390x header clean-ups
* Doc updates

v2: Drop the problematic patch that updates the custom CentOS 8 runner


Brad Smith (1):
  tests/vm: update openbsd image to 7.5

Inès Varhol (1):
  tests/qtest : Use `g_assert_cmphex` instead of `g_assert_cmpuint`

Manos Pitsidianakis (1):
  docs/devel: fix minor typo in submitting-a-patch.rst

Peter Lieven (1):
  MAINTAINERS: update email of Peter Lieven

Philippe Mathieu-Daudé (3):
  hw/s390x: Include missing 'cpu.h' header
  tests/unit: Remove debug statements in test-nested-aio-poll.c
  target/s390x: Remove KVM stubs in cpu_models.h

Thomas Huth (8):
  Revert ".travis.yml: Cache Avocado cache"
  .travis.yml: Remove the unused UNRELIABLE environment variable
  .travis.yml: Update the jobs to Ubuntu 22.04
  .travis.yml: Do some more testing with Clang
  tests: Remove Ubuntu 20.04 container
  tests/lcitool/libvirt-ci: Update to the latest master branch
  tests/docker/dockerfiles: Run lcitool-refresh after the lcitool update
  tests: Update our CI to use CentOS Stream 9 instead of 8

Zhao Liu (1):
  docs: i386: pc: Update maximum CPU numbers for PC Q35

 MAINTAINERS|   6 +-
 docs/devel/submitting-a-patch.rst  |   2 +-
 docs/system/target-i386-desc.rst.inc   |   2 +-
 hw/s390x/s390-virtio-hcall.h   |   2 +
 target/s390x/cpu_models.h  |  15 --
 hw/s390x/s390-stattrib.c   |   1 +
 tests/qtest/aspeed_fsi-test.c  |  20 +--
 tests/qtest/cmsdk-apb-dualtimer-test.c |   2 +-
 tests/qtest/cmsdk-apb-watchdog-test.c  |   2 +-
 tests/qtest/erst-test.c|   2 +-
 tests/qtest/ivshmem-test.c |  10 +-
 tests/qtest/libqos/ahci.c  |   4 +-
 tests/qtest/microbit-test.c|  46 +++---
 tests/qtest/sse-timer-test.c   |   4 +-
 tests/qtest/stm32l4x5_exti-test.c  | 138 +-
 tests/qtest/stm32l4x5_syscfg-test.c|  74 +-
 tests/unit/test-nested-aio-poll.c  |   7 -
 .gitlab-ci.d/buildtest.yml |  16 +--
 .gitlab-ci.d/container-core.yml|   4 +-
 .travis.yml|  24 +---
 tests/docker/dockerfiles/alpine.docker |   3 +-
 .../dockerfiles/{centos8.docker => centos9.docker} |  35 ++---
 tests/docker/dockerfiles/debian-amd64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-arm64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-armel-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-armhf-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-i686-cross.docker  |   3 +-
 .../dockerfiles/debian-mips64el-cross.docker   |   3 +-
 .../docker/dockerfiles/debian-mipsel-cross.docker  |   3 +-
 .../docker/dockerfiles/debian-ppc64el-cross.docker |   3 +-
 .../docker/dockerfiles/debian-riscv64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-s390x-cross.docker |   3 +-
 tests/docker/dockerfiles/debian.docker |   1 +
 tests/docker/dockerfiles/fedora-win64-cross.docker |   3 +-
 tests/docker/dockerfiles/fedora.docker |   1 +
 tests/docker/dockerfiles/opensuse-leap.docker  |   1 +
 tests/docker/dockerfiles/ubuntu2004.docker | 157 -
 tests/docker/dockerfiles/ubuntu2204.docker |   1 +
 tests/lcitool/libvirt-ci   |   2 +-
 tests/lcitool/mappings.yml |  20 ---
 tests/lcitool/refresh  |   3 +-
 tests/vm/centos|   4 +-
 tests/vm/openbsd   |   6 +-
 43 files changed, 225 insertions(+), 423 deletions(-)
 rename tests/docker/dockerfiles/{centos8.docker => centos9.docker} (82%)
 delete mode 100644 tests/docker/dockerfiles/ubuntu2004.docker

Re: [PULL 00/17] CI job updates, header cleanups and other misc patches

[Thomas Huth]

On 24/04/2024 18.21, Richard Henderson wrote:

On 4/24/24 00:57, Thomas Huth wrote:

The following changes since commit 13b1e9667737132440f4d500c31cb69320c6b15a:

   Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into 
staging (2024-04-23 17:35:57 -0700)


are available in the Git repository at:

   https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-24

for you to fetch changes up to 8f29bab03ea22694a127ee33edeb4ce99eeb124e:

   target/s390x: Remove KVM stubs in cpu_models.h (2024-04-24 09:45:02 +0200)


* Update OpenBSD CI image to 7.5
* Update/remove Ubuntu 20.04 CI jobs
* Update CentOS 8 CI jobs to CentOS 9
* Some clean-ups and improvements to travis.yml
* Minor test fixes
* s390x header clean-ups
* Doc updates


This introduces a failure in the migration-compat-x86_64 job:

https://gitlab.com/qemu-project/qemu/-/jobs/6707154868


It wasn't failing for me:

 https://gitlab.com/thuth/qemu/-/jobs/6702058896

And according to the diffstat of my pull request, it's only touching test 
files, docs, and s390x stuff, so I somehow fail to see how it could 
influence x86 migration at a first glance. It also looks like the job is 
running on opensuse, and not on CentOS or Ubuntu, so it should likely not be 
influenced by the changes in this PR.


Could you please hit the re-run button of that job? If it then passes, we're 
likely rather facing an intermitted failure that might have been introduced 
earlier already...


 Thanks,
  Thomas

Re: [PULL 12/17] tests: Update our CI to use CentOS Stream 9 instead of 8

[Thomas Huth]

On 24/04/2024 18.19, Richard Henderson wrote:

On 4/24/24 00:57, Thomas Huth wrote:

RHEL 9 (and thus also the derivatives) have been available since two
years now, so according to QEMU's support policy, we can drop the active
support for the previous major version 8 now.

Another reason for doing this is that Centos Stream 8 will go EOL soon:

https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/

   "After May 31, 2024, CentOS Stream 8 will be archived
    and no further updates will be provided."

Thus upgrade our CentOS Stream container to major version 9 now.

Reviewed-by: Daniel P. Berrangé
Message-ID:<20240418101056.302103-5-th...@redhat.com>
Signed-off-by: Thomas Huth
---
  .gitlab-ci.d/buildtest.yml    | 16 -
  .gitlab-ci.d/container-core.yml   |  4 +--
  .../{centos8.docker => centos9.docker}    | 34 +++
  tests/lcitool/mappings.yml    | 20 ---
  tests/lcitool/refresh |  2 +-
  tests/vm/centos   |  4 +--
  6 files changed, 26 insertions(+), 54 deletions(-)
  rename tests/docker/dockerfiles/{centos8.docker => centos9.docker} (82%)


This has missed a bit, since the centos-stream-8-x86_64 job still exists, 
but now fails.


https://gitlab.com/qemu-project/qemu/-/jobs/6707154779


It's not this patch, it's rather the "ci: move external build environment 
setups to CentOS Stream 9" patch that is missing an update to 
.gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml ... however, blindly 
updating the 8s in that file to 9s likely also doesn't work since there are 
runner tags involved here.
So what's the right way to update that custom runner to CentOS 9? Paolo, 
Alex, Cleber, do you know?


 Thomas

Re: [PATCH v2 1/2] net: Provide MemReentrancyGuard * to qemu_new_nic()

[Thomas Huth]

On 24/04/2024 12.41, Prasad Pandit wrote:

On Wednesday, 24 April, 2024 at 03:36:01 pm IST, Philippe Mathieu-Daudé wrote:

On 1/6/23 05:18, Akihiko Odaki wrote:

Recently MemReentrancyGuard was added to DeviceState to record that the
device is engaging in I/O. The network device backend needs to update it
when delivering a packet to a device.
  
In preparation for such a change, add MemReentrancyGuard * as a

parameter of qemu_new_nic().


An user on IRC asked if this patch is related/fixing CVE-2021-20255,
any clue?


* CVE-2021-20255 bug: infinite recursion is pointing at a different fix patch.
   -> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2021-20255

* And the this patch below has different issue tagged
   -> https://lists.nongnu.org/archive/html/qemu-devel/2023-05/msg08312.html
   Fixes: CVE-2023-3019


* They look different, former is an infinite recursion issue and the latter is 
a use-after-free one.


I assume the eepro reentrancy issue has been fixed with:

 https://gitlab.com/qemu-project/qemu/-/issues/556
 i.e.:
 https://gitlab.com/qemu-project/qemu/-/commit/c40ca2301c7603524eaddb5308a3

 HTH,
  Thomas

Re: [PATCH] vfio/ccw: Use g_autofree variable

[Thomas Huth]

On 24/04/2024 14.54, Cédric Le Goater wrote:

Also change the return value of vfio_ccw_register_irq_notifier() to be
a bool since it takes and 'Error **' argument. See the qapi/error.h
Rules section.

Signed-off-by: Cédric Le Goater 
---
  hw/vfio/ccw.c | 25 +++--
  1 file changed, 11 insertions(+), 14 deletions(-)


Reviewed-by: Thomas Huth 

Re: [PATCH v2 1/2] net: Provide MemReentrancyGuard * to qemu_new_nic()

[Thomas Huth]

On 24/04/2024 12.41, Prasad Pandit wrote:

On Wednesday, 24 April, 2024 at 03:36:01 pm IST, Philippe Mathieu-Daudé wrote:

On 1/6/23 05:18, Akihiko Odaki wrote:

Recently MemReentrancyGuard was added to DeviceState to record that the
device is engaging in I/O. The network device backend needs to update it
when delivering a packet to a device.
  
In preparation for such a change, add MemReentrancyGuard * as a

parameter of qemu_new_nic().


An user on IRC asked if this patch is related/fixing CVE-2021-20255,
any clue?


* CVE-2021-20255 bug: infinite recursion is pointing at a different fix patch.
   -> https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2021-20255

* And the this patch below has different issue tagged
   -> https://lists.nongnu.org/archive/html/qemu-devel/2023-05/msg08312.html
   Fixes: CVE-2023-3019


* They look different, former is an infinite recursion issue and the latter is 
a use-after-free one.


I assume the eepro reentrancy issue has been fixed with:

 https://gitlab.com/qemu-project/qemu/-/issues/556
 i.e.:
 https://gitlab.com/qemu-project/qemu/-/commit/c40ca2301c7603524eaddb5308a3

 HTH,
  Thomas

Re: [PATCH 2/2] checkpatch.pl: forbid strerrorname_np()

[Thomas Huth]

On 24/04/2024 11.47, Daniel Henrique Barboza wrote:

Commit d424db2354 removed an instance of strerrorname_np() because it
was breaking building with musl libc. A recent RISC-V patch ended up
re-introducing it again by accident.

Put this function in the baddies list in checkpatch.pl to avoid this
situation again. This is what it will look like next time:

  $ ./scripts/checkpatch.pl 0001-temp-test.patch
  ERROR: use strerror() instead of strerrorname_np()
  #22: FILE: target/riscv/kvm/kvm-cpu.c:1058:
  + strerrorname_np(errno));

  total: 1 errors, 0 warnings, 10 lines checked

Signed-off-by: Daniel Henrique Barboza 
---
  scripts/checkpatch.pl | 4 
  1 file changed, 4 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 7026895074..be0982246d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3056,6 +3056,10 @@ sub process {
}
}
  
+	if ($line =~ /\bstrerrorname_np\(/) {

+   ERROR("use strerror() instead of strerrorname_np()\n" . 
$herecurr);
+   }
+
  # check for non-portable libc calls that have portable alternatives in QEMU
if ($line =~ /\bffs\(/) {
ERROR("use ctz32() instead of ffs()\n" . $herecurr);


Reviewed-by: Thomas Huth 

Re: [PATCH 1/2] target/riscv/kvm: remove sneaky strerrorname_np() instance

[Thomas Huth]

On 24/04/2024 11.46, Daniel Henrique Barboza wrote:

Commit d424db2354 excluded some strerrorname_np() instances because they
break musl libc builds. Another instance happened to slip by via commit
d4ff3da8f4.

Remove it before it causes trouble again.

Fixes: d4ff3da8f4 (target/riscv/kvm: initialize 'vlenb' via get-reg-list)
Signed-off-by: Daniel Henrique Barboza 
---
  target/riscv/kvm/kvm-cpu.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/riscv/kvm/kvm-cpu.c b/target/riscv/kvm/kvm-cpu.c
index 6a6c6cae80..ee69ea9785 100644
--- a/target/riscv/kvm/kvm-cpu.c
+++ b/target/riscv/kvm/kvm-cpu.c
@@ -1054,8 +1054,8 @@ static void kvm_riscv_read_vlenb(RISCVCPU *cpu, 
KVMScratchCPU *kvmcpu,
  
  ret = ioctl(kvmcpu->cpufd, KVM_GET_ONE_REG, );

  if (ret != 0) {
-error_report("Unable to read vlenb register, error code: %s",
- strerrorname_np(errno));
+error_report("Unable to read vlenb register, error code: %d",
+ errno);
  exit(EXIT_FAILURE);
      }
  


Reviewed-by: Thomas Huth 

[PULL 12/17] tests: Update our CI to use CentOS Stream 9 instead of 8

[Thomas Huth]

RHEL 9 (and thus also the derivatives) have been available since two
years now, so according to QEMU's support policy, we can drop the active
support for the previous major version 8 now.

Another reason for doing this is that Centos Stream 8 will go EOL soon:

https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/

  "After May 31, 2024, CentOS Stream 8 will be archived
   and no further updates will be provided."

Thus upgrade our CentOS Stream container to major version 9 now.

Reviewed-by: Daniel P. Berrangé 
Message-ID: <20240418101056.302103-5-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .gitlab-ci.d/buildtest.yml| 16 -
 .gitlab-ci.d/container-core.yml   |  4 +--
 .../{centos8.docker => centos9.docker}| 34 +++
 tests/lcitool/mappings.yml| 20 ---
 tests/lcitool/refresh |  2 +-
 tests/vm/centos   |  4 +--
 6 files changed, 26 insertions(+), 54 deletions(-)
 rename tests/docker/dockerfiles/{centos8.docker => centos9.docker} (82%)

diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index cfdff175c3..9f34c650d6 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -158,9 +158,9 @@ build-system-centos:
 - .native_build_job_template
 - .native_build_artifact_template
   needs:
-job: amd64-centos8-container
+job: amd64-centos9-container
   variables:
-IMAGE: centos8
+IMAGE: centos9
 CONFIGURE_ARGS: --disable-nettle --enable-gcrypt --enable-vfio-user-server
   --enable-modules --enable-trace-backends=dtrace --enable-docs
 TARGETS: ppc64-softmmu or1k-softmmu s390x-softmmu
@@ -242,7 +242,7 @@ check-system-centos:
 - job: build-system-centos
   artifacts: true
   variables:
-IMAGE: centos8
+IMAGE: centos9
 MAKE_CHECK_ARGS: check
 
 avocado-system-centos:
@@ -251,7 +251,7 @@ avocado-system-centos:
 - job: build-system-centos
   artifacts: true
   variables:
-IMAGE: centos8
+IMAGE: centos9
 MAKE_CHECK_ARGS: check-avocado
 AVOCADO_TAGS: arch:ppc64 arch:or1k arch:s390x arch:x86_64 arch:rx
   arch:sh4 arch:nios2
@@ -327,9 +327,9 @@ avocado-system-flaky:
 build-tcg-disabled:
   extends: .native_build_job_template
   needs:
-job: amd64-centos8-container
+job: amd64-centos9-container
   variables:
-IMAGE: centos8
+IMAGE: centos9
   script:
 - mkdir build
 - cd build
@@ -651,9 +651,9 @@ build-tci:
 build-without-defaults:
   extends: .native_build_job_template
   needs:
-job: amd64-centos8-container
+job: amd64-centos9-container
   variables:
-IMAGE: centos8
+IMAGE: centos9
 CONFIGURE_ARGS:
   --without-default-devices
   --without-default-features
diff --git a/.gitlab-ci.d/container-core.yml b/.gitlab-ci.d/container-core.yml
index 08f8450fa1..5459447676 100644
--- a/.gitlab-ci.d/container-core.yml
+++ b/.gitlab-ci.d/container-core.yml
@@ -1,10 +1,10 @@
 include:
   - local: '/.gitlab-ci.d/container-template.yml'
 
-amd64-centos8-container:
+amd64-centos9-container:
   extends: .container_job_template
   variables:
-NAME: centos8
+NAME: centos9
 
 amd64-fedora-container:
   extends: .container_job_template
diff --git a/tests/docker/dockerfiles/centos8.docker 
b/tests/docker/dockerfiles/centos9.docker
similarity index 82%
rename from tests/docker/dockerfiles/centos8.docker
rename to tests/docker/dockerfiles/centos9.docker
index ea618bf352..6cf47ce786 100644
--- a/tests/docker/dockerfiles/centos8.docker
+++ b/tests/docker/dockerfiles/centos9.docker
@@ -1,15 +1,14 @@
 # THIS FILE WAS AUTO-GENERATED
 #
-#  $ lcitool dockerfile --layers all centos-stream-8 qemu
+#  $ lcitool dockerfile --layers all centos-stream-9 qemu
 #
 # https://gitlab.com/libvirt/libvirt-ci
 
-FROM quay.io/centos/centos:stream8
+FROM quay.io/centos/centos:stream9
 
 RUN dnf distro-sync -y && \
 dnf install 'dnf-command(config-manager)' -y && \
-dnf config-manager --set-enabled -y powertools && \
-dnf install -y centos-release-advanced-virtualization && \
+dnf config-manager --set-enabled -y crb && \
 dnf install -y epel-release && \
 dnf install -y epel-next-release && \
 dnf install -y \
@@ -42,7 +41,6 @@ RUN dnf distro-sync -y && \
 glib2-static \
 glibc-langpack-en \
 glibc-static \
-glusterfs-api-devel \
 gnutls-devel \
 gtk3-devel \
 hostname \
@@ -82,6 +80,7 @@ RUN dnf distro-sync -y && \
 lzo-devel \
 make \
 mesa-libgbm-devel \
+meson \
 mtools \
 ncurses-devel \
 nettle-devel \
@@ -95,25 +94,25 @@ RUN dnf distro-sync -y && \
 pixman-devel \
 pkgconfig \
 pulseaudio-libs-devel \
-python38 \
-  

[PULL 06/17] .travis.yml: Remove the unused UNRELIABLE environment variable

[Thomas Huth]

This variable was used to allow jobs to fail without spoiling the
overall result. But the required "allow_failures:" hunk has been
accidentally removed in commit 9d03f5abed ("travis.yml: Remove the
"Release tarball" job"), and it was anyway only useful while we
still had the x86 jobs here around that were our main CI jobs.
Thus let's simply remove this useless variable now.

Message-ID: <20240320104144.823425-6-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .travis.yml | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 8da88c4360..196725d5a3 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -113,7 +113,6 @@ jobs:
 - TEST_CMD="make check check-tcg V=1"
 - CONFIG="--disable-containers --enable-fdt=system
   --target-list=${MAIN_SYSTEM_TARGETS} --cxx=/bin/false"
-- UNRELIABLE=true
 
 - name: "[ppc64] GCC check-tcg"
   arch: ppc64le
@@ -184,7 +183,6 @@ jobs:
 - TEST_CMD="make check check-tcg V=1"
 - CONFIG="--disable-containers
 
--target-list=hppa-softmmu,mips64-softmmu,ppc64-softmmu,riscv64-softmmu,s390x-softmmu,x86_64-softmmu"
-- UNRELIABLE=true
   script:
 - BUILD_RC=0 && make -j${JOBS} || BUILD_RC=$?
 - |
@@ -274,4 +272,3 @@ jobs:
 - TEST_CMD="make check-unit"
 - CONFIG="--disable-containers --disable-tcg --enable-kvm 
--disable-tools
   --enable-fdt=system --host-cc=clang --cxx=clang++"
-- UNRELIABLE=true
-- 
2.44.0

[PULL 15/17] docs/devel: fix minor typo in submitting-a-patch.rst

[Thomas Huth]

From: Manos Pitsidianakis 

s/Resolved:/Resolves:/

Signed-off-by: Manos Pitsidianakis 
Message-ID: <20240422124128.4034482-1-manos.pitsidiana...@linaro.org>
Reviewed-by: Peter Maydell 
Signed-off-by: Thomas Huth 
---
 docs/devel/submitting-a-patch.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/devel/submitting-a-patch.rst 
b/docs/devel/submitting-a-patch.rst
index c641d948f1..83e9092b8c 100644
--- a/docs/devel/submitting-a-patch.rst
+++ b/docs/devel/submitting-a-patch.rst
@@ -177,7 +177,7 @@ add an additional line with "Fixes: 

 
 If your patch fixes a bug in the gitlab bug tracker, please add a line
 with "Resolves: " to the commit message, too. Gitlab can
-close bugs automatically once commits with the "Resolved:" keyword get
+close bugs automatically once commits with the "Resolves:" keyword get
 merged into the master branch of the project. And if your patch addresses
 a bug in another public bug tracker, you can also use a line with
 "Buglink: " for reference here, too.
-- 
2.44.0

[PULL 02/17] tests/qtest : Use `g_assert_cmphex` instead of `g_assert_cmpuint`

[Thomas Huth]

From: Inès Varhol 

The messages for assertions using hexadecimal numbers will be
easier to understand with `g_assert_cmphex`.

Cases changed : "cmpuint.*0x", "cmpuint.*<<"

Signed-off-by: Inès Varhol 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Ninad Palsule 
Message-ID: <20240414173349.31194-1-ines.var...@telecom-paris.fr>
Signed-off-by: Thomas Huth 
---
 tests/qtest/aspeed_fsi-test.c  |  20 ++--
 tests/qtest/cmsdk-apb-dualtimer-test.c |   2 +-
 tests/qtest/cmsdk-apb-watchdog-test.c  |   2 +-
 tests/qtest/erst-test.c|   2 +-
 tests/qtest/ivshmem-test.c |  10 +-
 tests/qtest/libqos/ahci.c  |   4 +-
 tests/qtest/microbit-test.c|  46 -
 tests/qtest/sse-timer-test.c   |   4 +-
 tests/qtest/stm32l4x5_exti-test.c  | 138 -
 tests/qtest/stm32l4x5_syscfg-test.c|  74 ++---
 10 files changed, 151 insertions(+), 151 deletions(-)

diff --git a/tests/qtest/aspeed_fsi-test.c b/tests/qtest/aspeed_fsi-test.c
index b3020dd821..f5ab269972 100644
--- a/tests/qtest/aspeed_fsi-test.c
+++ b/tests/qtest/aspeed_fsi-test.c
@@ -63,22 +63,22 @@ static void test_fsi_setup(QTestState *s, uint32_t 
base_addr)
 /* Unselect FSI1 */
 aspeed_fsi_writel(s, ASPEED_FSI_OPB1_BUS_SELECT, 0x0);
 curval = aspeed_fsi_readl(s, ASPEED_FSI_OPB1_BUS_SELECT);
-g_assert_cmpuint(curval, ==, 0x0);
+g_assert_cmphex(curval, ==, 0x0);
 
 /* Select FSI0 */
 aspeed_fsi_writel(s, ASPEED_FSI_OPB0_BUS_SELECT, 0x1);
 curval = aspeed_fsi_readl(s, ASPEED_FSI_OPB0_BUS_SELECT);
-g_assert_cmpuint(curval, ==, 0x1);
+g_assert_cmphex(curval, ==, 0x1);
 } else if (base_addr == AST2600_OPB_FSI1_BASE_ADDR) {
 /* Unselect FSI0 */
 aspeed_fsi_writel(s, ASPEED_FSI_OPB0_BUS_SELECT, 0x0);
 curval = aspeed_fsi_readl(s, ASPEED_FSI_OPB0_BUS_SELECT);
-g_assert_cmpuint(curval, ==, 0x0);
+g_assert_cmphex(curval, ==, 0x0);
 
 /* Select FSI1 */
 aspeed_fsi_writel(s, ASPEED_FSI_OPB1_BUS_SELECT, 0x1);
 curval = aspeed_fsi_readl(s, ASPEED_FSI_OPB1_BUS_SELECT);
-g_assert_cmpuint(curval, ==, 0x1);
+g_assert_cmphex(curval, ==, 0x1);
 } else {
 g_assert_not_reached();
 }
@@ -145,11 +145,11 @@ static void test_fsi0_getcfam_addr0(const void *data)
 aspeed_fsi_writel(s, ASPEED_FSI_ENGINER_TRIGGER, 0x1);
 
 curval = aspeed_fsi_readl(s, ASPEED_FSI_INTRRUPT_STATUS);
-g_assert_cmpuint(curval, ==, 0x1);
+g_assert_cmphex(curval, ==, 0x1);
 curval = aspeed_fsi_readl(s, ASPEED_FSI_OPB0_BUS_STATUS);
-g_assert_cmpuint(curval, ==, 0x0);
+g_assert_cmphex(curval, ==, 0x0);
 curval = aspeed_fsi_readl(s, ASPEED_FSI_OPB0_READ_DATA);
-g_assert_cmpuint(curval, ==, 0x152d02c0);
+g_assert_cmphex(curval, ==, 0x152d02c0);
 }
 
 static void test_fsi1_getcfam_addr0(const void *data)
@@ -168,11 +168,11 @@ static void test_fsi1_getcfam_addr0(const void *data)
 aspeed_fsi_writel(s, ASPEED_FSI_ENGINER_TRIGGER, 0x1);
 
 curval = aspeed_fsi_readl(s, ASPEED_FSI_INTRRUPT_STATUS);
-g_assert_cmpuint(curval, ==, 0x2);
+g_assert_cmphex(curval, ==, 0x2);
 curval = aspeed_fsi_readl(s, ASPEED_FSI_OPB1_BUS_STATUS);
-g_assert_cmpuint(curval, ==, 0x0);
+g_assert_cmphex(curval, ==, 0x0);
 curval = aspeed_fsi_readl(s, ASPEED_FSI_OPB1_READ_DATA);
-g_assert_cmpuint(curval, ==, 0x152d02c0);
+g_assert_cmphex(curval, ==, 0x152d02c0);
 }
 
 int main(int argc, char **argv)
diff --git a/tests/qtest/cmsdk-apb-dualtimer-test.c 
b/tests/qtest/cmsdk-apb-dualtimer-test.c
index ad6a758289..3b89bed97d 100644
--- a/tests/qtest/cmsdk-apb-dualtimer-test.c
+++ b/tests/qtest/cmsdk-apb-dualtimer-test.c
@@ -69,7 +69,7 @@ static void test_dualtimer(void)
  * tick VALUE should have wrapped round to 0x.
  */
 clock_step(40);
-g_assert_cmpuint(readl(TIMER_BASE + TIMER1VALUE), ==, 0x);
+g_assert_cmphex(readl(TIMER_BASE + TIMER1VALUE), ==, 0x);
 
 /* Check that any write to INTCLR clears interrupt */
 writel(TIMER_BASE + TIMER1INTCLR, 1);
diff --git a/tests/qtest/cmsdk-apb-watchdog-test.c 
b/tests/qtest/cmsdk-apb-watchdog-test.c
index 2710cb17b8..00b5dbbc81 100644
--- a/tests/qtest/cmsdk-apb-watchdog-test.c
+++ b/tests/qtest/cmsdk-apb-watchdog-test.c
@@ -88,7 +88,7 @@ static void test_clock_change(void)
 
 /* Rewrite RCC.SYSDIV from 16 to 8, so the clock is now 40ns per tick */
 rcc = readl(SSYS_BASE + RCC);
-g_assert_cmpuint(extract32(rcc, SYSDIV_SHIFT, SYSDIV_LENGTH), ==, 0xf);
+g_assert_cmphex(extract32(rcc, SYSDIV_SHIFT, SYSDIV_LENGTH), ==, 0xf);
 rcc = deposit32(rcc, SYSDIV_SHIFT, SYSDIV_LENGTH, 7);
 writel(SSYS_BASE + RCC, rcc);
 
diff --git a/tests/qtest/erst-test.c b/tests/qtest/erst-test.c
index c45bee7f05..36bbe122ab 100644
--- a/tests/qtest/erst-test.c
+++ b/tests/qt

[PULL 03/17] docs: i386: pc: Update maximum CPU numbers for PC Q35

[Thomas Huth]

From: Zhao Liu 

Commit e4e98c7eebfa ("pc: q35: Bump max_cpus to 4096 vcpus") increases
the supported CPUs for PC Q35 machine.

Update maximum CPU numbers for PC Q35 in the document.

Signed-off-by: Zhao Liu 
Message-ID: <20240412085358.731560-1-zhao1@linux.intel.com>
Signed-off-by: Thomas Huth 
---
 docs/system/target-i386-desc.rst.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/system/target-i386-desc.rst.inc 
b/docs/system/target-i386-desc.rst.inc
index 5ebbcda9db..319e540573 100644
--- a/docs/system/target-i386-desc.rst.inc
+++ b/docs/system/target-i386-desc.rst.inc
@@ -36,7 +36,7 @@ The QEMU PC System emulator simulates the following 
peripherals:
 -  PCI UHCI, OHCI, EHCI or XHCI USB controller and a virtual USB-1.1
hub.
 
-SMP is supported with up to 255 CPUs.
+SMP is supported with up to 255 CPUs (and 4096 CPUs for PC Q35 machine).
 
 QEMU uses the PC BIOS from the Seabios project and the Plex86/Bochs LGPL
 VGA BIOS.
-- 
2.44.0

[PULL 13/17] ci: move external build environment setups to CentOS Stream 9

[Thomas Huth]

From: Paolo Bonzini 

RHEL 9 (and thus also the derivatives) are available since two years
now, so according to QEMU's support policy, we can drop the active
support for the previous major version 8 now.

Thus upgrade our CentOS Stream build environment playbooks to major
version 9 now.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Thomas Huth 
Message-ID: <20240412103708.27650-1-pbonz...@redhat.com>
Reviewed-by: Daniel P. Berrangé 
Message-ID: <20240418101056.302103-7-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .../stream/{8 => 9}/build-environment.yml | 31 ++---
 .../stream/{8 => 9}/x86_64/configure  |  4 +-
 .../stream/{8 => 9}/x86_64/test-avocado   |  0
 scripts/ci/setup/build-environment.yml| 44 +++
 4 files changed, 34 insertions(+), 45 deletions(-)
 rename scripts/ci/org.centos/stream/{8 => 9}/build-environment.yml (75%)
 rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/configure (98%)
 rename scripts/ci/org.centos/stream/{8 => 9}/x86_64/test-avocado (100%)

diff --git a/scripts/ci/org.centos/stream/8/build-environment.yml 
b/scripts/ci/org.centos/stream/9/build-environment.yml
similarity index 75%
rename from scripts/ci/org.centos/stream/8/build-environment.yml
rename to scripts/ci/org.centos/stream/9/build-environment.yml
index 1ead77e2cb..cd29fe6f27 100644
--- a/scripts/ci/org.centos/stream/8/build-environment.yml
+++ b/scripts/ci/org.centos/stream/9/build-environment.yml
@@ -2,32 +2,32 @@
 - name: Installation of extra packages to build QEMU
   hosts: all
   tasks:
-- name: Extra check for CentOS Stream 8
+- name: Extra check for CentOS Stream 9
   lineinfile:
 path: /etc/redhat-release
-line: CentOS Stream release 8
+line: CentOS Stream release 9
 state: present
   check_mode: yes
-  register: centos_stream_8
+  register: centos_stream_9
 
-- name: Enable EPEL repo on CentOS Stream 8
+- name: Enable EPEL repo on CentOS Stream 9
   dnf:
 name:
   - epel-release
 state: present
   when:
-- centos_stream_8
+- centos_stream_9
 
-- name: Enable PowerTools repo on CentOS Stream 8
+- name: Enable CRB repo on CentOS Stream 9
   ini_file:
-path: /etc/yum.repos.d/CentOS-Stream-PowerTools.repo
-section: powertools
+path: /etc/yum.repos.d/centos.repo
+section: crb
 option: enabled
 value: "1"
   when:
-- centos_stream_8
+- centos_stream_9
 
-- name: Install basic packages to build QEMU on CentOS Stream 8
+- name: Install basic packages to build QEMU on CentOS Stream 9
   dnf:
 name:
   - bzip2
@@ -42,7 +42,6 @@
   - gettext
   - git
   - glib2-devel
-  - glusterfs-api-devel
   - gnutls-devel
   - libaio-devel
   - libcap-ng-devel
@@ -61,22 +60,24 @@
   - lzo-devel
   - make
   - mesa-libEGL-devel
+  - meson
   - nettle-devel
   - ninja-build
   - nmap-ncat
   - numactl-devel
   - pixman-devel
-  - python38
+  - python3
+  - python3-pip
   - python3-sphinx
+  - python3-sphinx_rtd_theme
+  - python3-tomli
   - rdma-core-devel
   - redhat-rpm-config
   - snappy-devel
-  - spice-glib-devel
-  - spice-server-devel
   - systemd-devel
   - systemtap-sdt-devel
   - tar
   - zlib-devel
 state: present
   when:
-- centos_stream_8
+- centos_stream_9
diff --git a/scripts/ci/org.centos/stream/8/x86_64/configure 
b/scripts/ci/org.centos/stream/9/x86_64/configure
similarity index 98%
rename from scripts/ci/org.centos/stream/8/x86_64/configure
rename to scripts/ci/org.centos/stream/9/x86_64/configure
index 76781f17f4..1b6f40fd78 100755
--- a/scripts/ci/org.centos/stream/8/x86_64/configure
+++ b/scripts/ci/org.centos/stream/9/x86_64/configure
@@ -16,7 +16,7 @@
 # that patches adding downstream specific devices are not available.
 #
 ../configure \
---python=/usr/bin/python3.8 \
+--python=/usr/bin/python3.9 \
 --prefix="/usr" \
 --libdir="/usr/lib64" \
 --datadir="/usr/share" \
@@ -157,7 +157,6 @@
 --enable-docs \
 --enable-fdt \
 --enable-gcrypt \
---enable-glusterfs \
 --enable-gnutls \
 --enable-guest-agent \
 --enable-iconv \
@@ -180,7 +179,6 @@
 --enable-seccomp \
 --enable-snappy \
 --enable-smartcard \
---enable-spice \
 --enable-system \
 --enable-tcg \
 --enable-tools \
diff --git a/scripts/ci/org.centos/stream/8/x86_64/test-avocado 
b/scripts/ci/org.centos/stream/9/x86_64/test-avocado
similarity index 100%
rename from scripts/ci/org.centos/stream/8/x86_64/test-avocado
rename to scripts/ci/org.centos/stream/9/x86_64/test-avocado
diff --git a/scripts/ci/setup/build-environment.yml 
b/scripts/ci/setup/buil

[PULL 16/17] tests/unit: Remove debug statements in test-nested-aio-poll.c

[Thomas Huth]

From: Philippe Mathieu-Daudé 

We have been running this test for almost a year; it
is safe to remove its debug statements, which clutter
CI jobs output:

  ▶  88/100 /nested-aio-poll  OK
  io_read 0x16bb26158
  io_poll_true 0x16bb26158
  > io_poll_ready
  io_read 0x16bb26164
  < io_poll_ready
  io_poll_true 0x16bb26158
  io_poll_false 0x16bb26164
  > io_poll_ready
  io_poll_false 0x16bb26164
  io_poll_false 0x16bb26164
  io_poll_false 0x16bb26164
  io_poll_false 0x16bb26164
  io_poll_false 0x16bb26164
  io_poll_false 0x16bb26164
  io_poll_false 0x16bb26164
  io_poll_false 0x16bb26164
  io_poll_false 0x16bb26164
  io_read 0x16bb26164
  < io_poll_ready
  88/100 qemu:unit / test-nested-aio-pollOK

Reviewed-by: Eric Blake 
Reviewed-by: Richard Henderson 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Stefan Hajnoczi 
Message-ID: <20240422112246.83812-1-phi...@linaro.org>
Signed-off-by: Thomas Huth 
---
 tests/unit/test-nested-aio-poll.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/tests/unit/test-nested-aio-poll.c 
b/tests/unit/test-nested-aio-poll.c
index db33742af3..d8fd92c43b 100644
--- a/tests/unit/test-nested-aio-poll.c
+++ b/tests/unit/test-nested-aio-poll.c
@@ -30,19 +30,16 @@ typedef struct {
 
 static void io_read(EventNotifier *notifier)
 {
-fprintf(stderr, "%s %p\n", __func__, notifier);
 event_notifier_test_and_clear(notifier);
 }
 
 static bool io_poll_true(void *opaque)
 {
-fprintf(stderr, "%s %p\n", __func__, opaque);
 return true;
 }
 
 static bool io_poll_false(void *opaque)
 {
-fprintf(stderr, "%s %p\n", __func__, opaque);
 return false;
 }
 
@@ -50,8 +47,6 @@ static void io_poll_ready(EventNotifier *notifier)
 {
 TestData *td = container_of(notifier, TestData, poll_notifier);
 
-fprintf(stderr, "> %s\n", __func__);
-
 g_assert(!td->nested);
 td->nested = true;
 
@@ -62,8 +57,6 @@ static void io_poll_ready(EventNotifier *notifier)
 g_assert(aio_poll(td->ctx, true));
 
 td->nested = false;
-
-fprintf(stderr, "< %s\n", __func__);
 }
 
 /* dummy_notifier never triggers */
-- 
2.44.0

[PULL 11/17] tests/docker/dockerfiles: Run lcitool-refresh after the lcitool update

[Thomas Huth]

This update adds the removing of the EXTERNALLY-MANAGED marker files
that has been added to the lcitool recently.

Quoting Daniel:
"For those who don't know, python now commonly blocks the ability to
run 'pip install' outside of a venv. This generally makes sense for
a precious installation environment. Our containers are disposable
though, so a venv has no benefit. Removing the 'EXTERNALLY-MANAGED'
allows the historical arbitrary use of 'pip' outside a venv.
lcitool just does this unconditionally given the containers are
not precious."

Reviewed-by: Daniel P. Berrangé 
Message-ID: <20240418101056.302103-4-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 tests/docker/dockerfiles/alpine.docker| 3 ++-
 tests/docker/dockerfiles/centos8.docker   | 1 +
 tests/docker/dockerfiles/debian-amd64-cross.docker| 3 ++-
 tests/docker/dockerfiles/debian-arm64-cross.docker| 3 ++-
 tests/docker/dockerfiles/debian-armel-cross.docker| 3 ++-
 tests/docker/dockerfiles/debian-armhf-cross.docker| 3 ++-
 tests/docker/dockerfiles/debian-i686-cross.docker | 3 ++-
 tests/docker/dockerfiles/debian-mips64el-cross.docker | 3 ++-
 tests/docker/dockerfiles/debian-mipsel-cross.docker   | 3 ++-
 tests/docker/dockerfiles/debian-ppc64el-cross.docker  | 3 ++-
 tests/docker/dockerfiles/debian-riscv64-cross.docker  | 3 ++-
 tests/docker/dockerfiles/debian-s390x-cross.docker| 3 ++-
 tests/docker/dockerfiles/debian.docker| 1 +
 tests/docker/dockerfiles/fedora-win64-cross.docker| 3 ++-
 tests/docker/dockerfiles/fedora.docker| 1 +
 tests/docker/dockerfiles/opensuse-leap.docker | 1 +
 tests/docker/dockerfiles/ubuntu2204.docker| 1 +
 17 files changed, 29 insertions(+), 12 deletions(-)

diff --git a/tests/docker/dockerfiles/alpine.docker 
b/tests/docker/dockerfiles/alpine.docker
index 42f6928627..cd9d7af1ce 100644
--- a/tests/docker/dockerfiles/alpine.docker
+++ b/tests/docker/dockerfiles/alpine.docker
@@ -116,7 +116,8 @@ RUN apk update && \
 zlib-static \
 zstd \
 zstd-dev && \
-apk list | sort > /packages.txt && \
+rm -f /usr/lib*/python3*/EXTERNALLY-MANAGED && \
+apk list --installed | sort > /packages.txt && \
 mkdir -p /usr/libexec/ccache-wrappers && \
 ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/c++ && \
 ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/cc && \
diff --git a/tests/docker/dockerfiles/centos8.docker 
b/tests/docker/dockerfiles/centos8.docker
index d97c30e96a..ea618bf352 100644
--- a/tests/docker/dockerfiles/centos8.docker
+++ b/tests/docker/dockerfiles/centos8.docker
@@ -123,6 +123,7 @@ RUN dnf distro-sync -y && \
 zstd && \
 dnf autoremove -y && \
 dnf clean all -y && \
+rm -f /usr/lib*/python3*/EXTERNALLY-MANAGED && \
 rpm -qa | sort > /packages.txt && \
 mkdir -p /usr/libexec/ccache-wrappers && \
 ln -s /usr/bin/ccache /usr/libexec/ccache-wrappers/c++ && \
diff --git a/tests/docker/dockerfiles/debian-amd64-cross.docker 
b/tests/docker/dockerfiles/debian-amd64-cross.docker
index 00bdc06021..d0b0e9778e 100644
--- a/tests/docker/dockerfiles/debian-amd64-cross.docker
+++ b/tests/docker/dockerfiles/debian-amd64-cross.docker
@@ -64,7 +64,8 @@ RUN export DEBIAN_FRONTEND=noninteractive && \
 eatmydata apt-get autoremove -y && \
 eatmydata apt-get autoclean -y && \
 sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \
-dpkg-reconfigure locales
+dpkg-reconfigure locales && \
+rm -f /usr/lib*/python3*/EXTERNALLY-MANAGED
 
 ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers"
 ENV LANG "en_US.UTF-8"
diff --git a/tests/docker/dockerfiles/debian-arm64-cross.docker 
b/tests/docker/dockerfiles/debian-arm64-cross.docker
index 2dae3777f7..8cb225740e 100644
--- a/tests/docker/dockerfiles/debian-arm64-cross.docker
+++ b/tests/docker/dockerfiles/debian-arm64-cross.docker
@@ -64,7 +64,8 @@ RUN export DEBIAN_FRONTEND=noninteractive && \
 eatmydata apt-get autoremove -y && \
 eatmydata apt-get autoclean -y && \
 sed -Ei 's,^# (en_US\.UTF-8 .*)$,\1,' /etc/locale.gen && \
-dpkg-reconfigure locales
+dpkg-reconfigure locales && \
+rm -f /usr/lib*/python3*/EXTERNALLY-MANAGED
 
 ENV CCACHE_WRAPPERSDIR "/usr/libexec/ccache-wrappers"
 ENV LANG "en_US.UTF-8"
diff --git a/tests/docker/dockerfiles/debian-armel-cross.docker 
b/tests/docker/dockerfiles/debian-armel-cross.docker
index 75342c09b0..e6f37418ed 100644
--- a/tests/docker/dockerfiles/debian-armel-cross.docker
+++ b/tests/docker/dockerfiles/debian-armel-cross.docker
@@ -65,7 +65,8 @@ RUN export DEBIAN_FRONTEND=noninteractive && \
 eatmydata apt-get autoremove -y &

[PULL 14/17] hw/s390x: Include missing 'cpu.h' header

[Thomas Huth]

From: Philippe Mathieu-Daudé 

"cpu.h" is implicitly included. Include it explicitly to
avoid the following error when refactoring headers:

  hw/s390x/s390-stattrib.c:86:40: error: use of undeclared identifier 
'TARGET_PAGE_SIZE'
  len = sac->peek_stattr(sas, addr / TARGET_PAGE_SIZE, buflen, vals);
 ^
  hw/s390x/s390-stattrib.c:94:58: error: use of undeclared identifier 
'TARGET_PAGE_MASK'
 addr / TARGET_PAGE_SIZE, len, addr & ~TARGET_PAGE_MASK);
 ^
  hw/s390x/s390-stattrib.c:224:40: error: use of undeclared identifier 
'TARGET_PAGE_BITS'
  qemu_put_be64(f, (start_gfn << TARGET_PAGE_BITS) | STATTR_FLAG_MORE);
 ^
  In file included from hw/s390x/s390-virtio-ccw.c:17:
  hw/s390x/s390-virtio-hcall.h:22:27: error: unknown type name 'CPUS390XState'
  int s390_virtio_hypercall(CPUS390XState *env);
^

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Thomas Huth 
Acked-by: Eric Farman 
Message-ID: <20240322162822.7391-1-phi...@linaro.org>
Signed-off-by: Thomas Huth 
---
 hw/s390x/s390-virtio-hcall.h | 2 ++
 hw/s390x/s390-stattrib.c | 1 +
 2 files changed, 3 insertions(+)

diff --git a/hw/s390x/s390-virtio-hcall.h b/hw/s390x/s390-virtio-hcall.h
index 9800c4b351..3ae6d6ae3a 100644
--- a/hw/s390x/s390-virtio-hcall.h
+++ b/hw/s390x/s390-virtio-hcall.h
@@ -13,6 +13,7 @@
 #define HW_S390_VIRTIO_HCALL_H
 
 #include "standard-headers/asm-s390/virtio-ccw.h"
+#include "cpu.h"
 
 /* The only thing that we need from the old kvm_virtio.h file */
 #define KVM_S390_VIRTIO_NOTIFY 0
@@ -20,4 +21,5 @@
 typedef int (*s390_virtio_fn)(const uint64_t *args);
 void s390_register_virtio_hypercall(uint64_t code, s390_virtio_fn fn);
 int s390_virtio_hypercall(CPUS390XState *env);
+
 #endif /* HW_S390_VIRTIO_HCALL_H */
diff --git a/hw/s390x/s390-stattrib.c b/hw/s390x/s390-stattrib.c
index c483b62a9b..aaf48ac73f 100644
--- a/hw/s390x/s390-stattrib.c
+++ b/hw/s390x/s390-stattrib.c
@@ -19,6 +19,7 @@
 #include "exec/ram_addr.h"
 #include "qapi/error.h"
 #include "qapi/qmp/qdict.h"
+#include "cpu.h"
 
 /* 512KiB cover 2GB of guest memory */
 #define CMMA_BLOCK_SIZE  (512 * KiB)
-- 
2.44.0

[PULL 05/17] Revert ".travis.yml: Cache Avocado cache"

[Thomas Huth]

This reverts commit c1073e44b46490133e16420e1784dec7bcd4e030.

The Avocado tests have been removed from Travis a long time ago with
commit c5008c76ee ("gitlab: add acceptance testing to system builds"),
so we don't need to cache the avocado files here anymore.

Message-ID: <20240320104144.823425-4-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .travis.yml | 2 --
 1 file changed, 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 8a3ae76a7c..8da88c4360 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -12,8 +12,6 @@ cache:
   timeout: 1200
   ccache: true
   pip: true
-  directories:
-  - $HOME/avocado/data/cache
 
 
 # The channel name "irc.oftc.net#qemu" is encrypted against qemu/qemu
-- 
2.44.0

[PULL 17/17] target/s390x: Remove KVM stubs in cpu_models.h

[Thomas Huth]

From: Philippe Mathieu-Daudé 

Since the calls are elided when KVM is not available,
we can remove the stubs (which are never compiled).

Signed-off-by: Philippe Mathieu-Daudé 
Message-ID: <20240419090631.48055-1-phi...@linaro.org>
Signed-off-by: Thomas Huth 
---
 target/s390x/cpu_models.h | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/target/s390x/cpu_models.h b/target/s390x/cpu_models.h
index d7b8912989..a89c2a15ab 100644
--- a/target/s390x/cpu_models.h
+++ b/target/s390x/cpu_models.h
@@ -114,23 +114,8 @@ static inline uint64_t s390_cpuid_from_cpu_model(const 
S390CPUModel *model)
 S390CPUDef const *s390_find_cpu_def(uint16_t type, uint8_t gen, uint8_t ec_ga,
 S390FeatBitmap features);
 
-#ifdef CONFIG_KVM
 bool kvm_s390_cpu_models_supported(void);
 void kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp);
 void kvm_s390_apply_cpu_model(const S390CPUModel *model,  Error **errp);
-#else
-static inline void kvm_s390_get_host_cpu_model(S390CPUModel *model,
-   Error **errp)
-{
-}
-static inline void kvm_s390_apply_cpu_model(const S390CPUModel *model,
-Error **errp)
-{
-}
-static inline bool kvm_s390_cpu_models_supported(void)
-{
-return false;
-}
-#endif
 
 #endif /* TARGET_S390X_CPU_MODELS_H */
-- 
2.44.0

[PULL 01/17] MAINTAINERS: update email of Peter Lieven

[Thomas Huth]

From: Peter Lieven 

I will leave KAMP in the next days. Update email to stay reachable.

Signed-off-by: Peter Lieven 
Message-ID: <20230105095039.182718-1...@kamp.de>
Signed-off-by: Thomas Huth 
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f1f6922025..b8b058909b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3818,7 +3818,7 @@ F: block/vmdk.c
 
 RBD
 M: Ilya Dryomov 
-R: Peter Lieven 
+R: Peter Lieven 
 L: qemu-bl...@nongnu.org
 S: Supported
 F: block/rbd.c
@@ -3844,7 +3844,7 @@ F: block/blkio.c
 iSCSI
 M: Ronnie Sahlberg 
 M: Paolo Bonzini 
-M: Peter Lieven 
+M: Peter Lieven 
 L: qemu-bl...@nongnu.org
 S: Odd Fixes
 F: block/iscsi.c
@@ -3867,7 +3867,7 @@ T: git https://repo.or.cz/qemu/ericb.git nbd
 T: git https://gitlab.com/vsementsov/qemu.git block
 
 NFS
-M: Peter Lieven 
+M: Peter Lieven 
 L: qemu-bl...@nongnu.org
 S: Maintained
 F: block/nfs.c
-- 
2.44.0

[PULL 08/17] .travis.yml: Do some more testing with Clang

[Thomas Huth]

We are doing a lot of cross-compilation tests with GCC in the gitlab-CI
already, so we could get some more test coverage by using Clang in the
Travis-CI instead. Thus let's switch two additional jobs to use Clang
for compilation.

Message-ID: <20240320104144.823425-7-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .travis.yml | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 7527f71c05..cef0308952 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -113,8 +113,9 @@ jobs:
 - CONFIG="--disable-containers --enable-fdt=system
   --target-list=${MAIN_SYSTEM_TARGETS} --cxx=/bin/false"
 
-- name: "[ppc64] GCC check-tcg"
+- name: "[ppc64] Clang check-tcg"
   arch: ppc64le
+  compiler: clang
   addons:
 apt_packages:
   - libaio-dev
@@ -190,8 +191,9 @@ jobs:
   $(exit $BUILD_RC);
   fi
 
-- name: "[s390x] GCC (other-system)"
+- name: "[s390x] Clang (other-system)"
   arch: s390x
+  compiler: clang
   addons:
 apt_packages:
   - libaio-dev
-- 
2.44.0

[PULL 10/17] tests/lcitool/libvirt-ci: Update to the latest master branch

[Thomas Huth]

We need the latest fixes for the lcitool to be able to properly
update our CentOS docker file to CentOS Stream 9.

Reviewed-by: Daniel P. Berrangé 
Message-ID: <20240418101056.302103-3-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 tests/lcitool/libvirt-ci | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/lcitool/libvirt-ci b/tests/lcitool/libvirt-ci
index 77c800186f..cec6703971 16
--- a/tests/lcitool/libvirt-ci
+++ b/tests/lcitool/libvirt-ci
@@ -1 +1 @@
-Subproject commit 77c800186f34b21be7660750577cc5582a914deb
+Subproject commit cec67039719becbfbab866f9c23574f389cf9559
-- 
2.44.0

[PULL 04/17] tests/vm: update openbsd image to 7.5

[Thomas Huth]

From: Brad Smith 

tests/vm: update openbsd to release 7.5

Signed-off-by: Brad Smith 
Message-ID: 
Signed-off-by: Thomas Huth 
---
 tests/vm/openbsd | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/vm/openbsd b/tests/vm/openbsd
index 85c9863633..5e646f7c51 100755
--- a/tests/vm/openbsd
+++ b/tests/vm/openbsd
@@ -22,8 +22,8 @@ class OpenBSDVM(basevm.BaseVM):
 name = "openbsd"
 arch = "x86_64"
 
-link = "https://cdn.openbsd.org/pub/OpenBSD/7.4/amd64/install74.iso;
-csum = "a1001736ed9fe2307965b5fcdb426ae11f9b80d26eb21e404a705144a0a224a0"
+link = "https://cdn.openbsd.org/pub/OpenBSD/7.5/amd64/install75.iso;
+csum = "034435c6e27405d5a7fafb058162943c194eb793dafdc412c08d49bb56b3892a"
 size = "20G"
 pkgs = [
 # tools
@@ -124,7 +124,7 @@ class OpenBSDVM(basevm.BaseVM):
 self.console_wait_send("Allow root ssh login","yes\n")
 self.console_wait_send("timezone","UTC\n")
 self.console_wait_send("root disk",   "\n")
-self.console_wait_send("Encrypt the root disk with a passphrase", 
"no\n")
+self.console_wait_send("Encrypt the root disk with a (p)assphrase", 
"no\n")
 self.console_wait_send("(W)hole disk","\n")
 self.console_wait_send("(A)uto layout",   "c\n")
 
-- 
2.44.0

[PULL 07/17] .travis.yml: Update the jobs to Ubuntu 22.04

[Thomas Huth]

According to our support policy, we'll soon drop our official support
for Ubuntu 20.04 ("Focal Fossa") in QEMU. Thus we should update the
Travis jobs now to a newer release (Ubuntu 22.04 - "Jammy Jellyfish")
for future testing. Since all jobs are using this release now, we
can drop the entries from the individual jobs and use the global
setting again.

Reviewed-by: Daniel P. Berrangé 
Message-ID: <20240418101056.302103-6-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 .travis.yml | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index 196725d5a3..7527f71c05 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,5 +1,5 @@
 os: linux
-dist: focal
+dist: jammy
 language: c
 compiler:
   - gcc
@@ -7,7 +7,7 @@ cache:
   # There is one cache per branch and compiler version.
   # characteristics of each job are used to identify the cache:
   # - OS name (currently only linux)
-  # - OS distribution (for Linux, bionic or focal)
+  # - OS distribution (e.g. "jammy" for Linux)
   # - Names and values of visible environment variables set in .travis.yml or 
Settings panel
   timeout: 1200
   ccache: true
@@ -81,7 +81,6 @@ jobs:
 
 - name: "[aarch64] GCC check-tcg"
   arch: arm64
-  dist: focal
   addons:
 apt_packages:
   - libaio-dev
@@ -116,7 +115,6 @@ jobs:
 
 - name: "[ppc64] GCC check-tcg"
   arch: ppc64le
-  dist: focal
   addons:
 apt_packages:
   - libaio-dev
@@ -151,7 +149,6 @@ jobs:
 
 - name: "[s390x] GCC check-tcg"
   arch: s390x
-  dist: focal
   addons:
 apt_packages:
   - libaio-dev
@@ -195,7 +192,6 @@ jobs:
 
 - name: "[s390x] GCC (other-system)"
   arch: s390x
-  dist: focal
   addons:
 apt_packages:
   - libaio-dev
@@ -225,7 +221,6 @@ jobs:
 
 - name: "[s390x] GCC (user)"
   arch: s390x
-  dist: focal
   addons:
 apt_packages:
   - libgcrypt20-dev
@@ -240,8 +235,7 @@ jobs:
 
 - name: "[s390x] Clang (disable-tcg)"
   arch: s390x
-  dist: focal
-  compiler: clang-10
+  compiler: clang
   addons:
 apt_packages:
   - libaio-dev
@@ -267,7 +261,6 @@ jobs:
   - libvdeplug-dev
   - libvte-2.91-dev
   - ninja-build
-  - clang-10
   env:
 - TEST_CMD="make check-unit"
 - CONFIG="--disable-containers --disable-tcg --enable-kvm 
--disable-tools
-- 
2.44.0

[PULL 09/17] tests: Remove Ubuntu 20.04 container

[Thomas Huth]

Since Ubuntu 22.04 has now been available for more than two years, we
can stop actively supporting the previous LTS version of Ubuntu now.

Reviewed-by: Philippe Mathieu-Daudé 
Message-ID: <20240418101056.302103-2-th...@redhat.com>
Signed-off-by: Thomas Huth 
---
 tests/docker/dockerfiles/ubuntu2004.docker | 157 -
 tests/lcitool/refresh  |   1 -
 2 files changed, 158 deletions(-)
 delete mode 100644 tests/docker/dockerfiles/ubuntu2004.docker

diff --git a/tests/docker/dockerfiles/ubuntu2004.docker 
b/tests/docker/dockerfiles/ubuntu2004.docker
deleted file mode 100644
index d3e212060c..00
--- a/tests/docker/dockerfiles/ubuntu2004.docker
+++ /dev/null
@@ -1,157 +0,0 @@
-# THIS FILE WAS AUTO-GENERATED
-#
-#  $ lcitool dockerfile --layers all ubuntu-2004 qemu
-#
-# https://gitlab.com/libvirt/libvirt-ci
-
-FROM docker.io/library/ubuntu:20.04
-
-RUN export DEBIAN_FRONTEND=noninteractive && \
-apt-get update && \
-apt-get install -y eatmydata && \
-eatmydata apt-get dist-upgrade -y && \
-eatmydata apt-get install --no-install-recommends -y \
-  bash \
-  bc \
-  bison \
-  bsdmainutils \
-  bzip2 \
-  ca-certificates \
-  ccache \
-  clang \
-  dbus \
-  debianutils \
-  diffutils \
-  exuberant-ctags \
-  findutils \
-  flex \
-  g++ \
-  gcc \
-  gcovr \
-  gettext \
-  git \
-  hostname \
-  libaio-dev \
-  libasan6 \
-  libasound2-dev \
-  libattr1-dev \
-  libbrlapi-dev \
-  libbz2-dev \
-  libc6-dev \
-  libcacard-dev \
-  libcap-ng-dev \
-  libcapstone-dev \
-  libcmocka-dev \
-  libcurl4-gnutls-dev \
-  libdaxctl-dev \
-  libdrm-dev \
-  libepoxy-dev \
-  libfdt-dev \
-  libffi-dev \
-  libfuse3-dev \
-  libgbm-dev \
-  libgcrypt20-dev \
-  libglib2.0-dev \
-  libglusterfs-dev \
-  libgnutls28-dev \
-  libgtk-3-dev \
-  libibumad-dev \
-  libibverbs-dev \
-  libiscsi-dev \
-  libjemalloc-dev \
-  libjpeg-turbo8-dev \
-  libjson-c-dev \
-  liblttng-ust-dev \
-  liblzo2-dev \
-  libncursesw5-dev \
-  libnfs-dev \
-  libnuma-dev \
-  libpam0g-dev \
-  libpcre2-dev \
-  libpixman-1-dev \
-  libpmem-dev \
-  libpng-dev \
-  libpulse-dev \
-  librbd-dev \
-  librdmacm-dev \
-  libsasl2-dev \
-  libsdl2-dev \
-  libsdl2-image-dev \
-  libseccomp-dev \
-  libselinux1-dev \
-  libslirp-dev \
-  libsnappy-dev \
-  libsndio-dev \
-  libspice-protocol-dev \
-  libspice-server-dev \
-  libssh-dev \
-  libsystemd-dev \
-  libtasn1-6-dev \
-  libubsan1 \
-  libudev-dev \
-  libusb-1.0-0-dev \
-  libusbredirhost-dev \
-  libvdeplug-dev \
-  libvirglrenderer-dev \
-  libvte-2.91-dev \
-  libxen-dev \
-  libzstd-dev \
-  llvm \
-  locales \
-  make \
-  mtools \
-  multipath-tools \
-  ncat \
-  nettle-dev \
-  ninja-build \
-  openssh-client \
-  pkgconf \
-  python3 \
-  python3-numpy \
-  python3-opencv \
-  python3-pillow \
-  python3-pip \
-  python3-setuptools \
-  python3-sphinx \
-

[PULL 00/17] CI job updates, header cleanups and other misc patches

[Thomas Huth]

The following changes since commit 13b1e9667737132440f4d500c31cb69320c6b15a:

  Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging 
(2024-04-23 17:35:57 -0700)

are available in the Git repository at:

  https://gitlab.com/thuth/qemu.git tags/pull-request-2024-04-24

for you to fetch changes up to 8f29bab03ea22694a127ee33edeb4ce99eeb124e:

  target/s390x: Remove KVM stubs in cpu_models.h (2024-04-24 09:45:02 +0200)


* Update OpenBSD CI image to 7.5
* Update/remove Ubuntu 20.04 CI jobs
* Update CentOS 8 CI jobs to CentOS 9
* Some clean-ups and improvements to travis.yml
* Minor test fixes
* s390x header clean-ups
* Doc updates


Brad Smith (1):
  tests/vm: update openbsd image to 7.5

Inès Varhol (1):
  tests/qtest : Use `g_assert_cmphex` instead of `g_assert_cmpuint`

Manos Pitsidianakis (1):
  docs/devel: fix minor typo in submitting-a-patch.rst

Paolo Bonzini (1):
  ci: move external build environment setups to CentOS Stream 9

Peter Lieven (1):
  MAINTAINERS: update email of Peter Lieven

Philippe Mathieu-Daudé (3):
  hw/s390x: Include missing 'cpu.h' header
  tests/unit: Remove debug statements in test-nested-aio-poll.c
  target/s390x: Remove KVM stubs in cpu_models.h

Thomas Huth (8):
  Revert ".travis.yml: Cache Avocado cache"
  .travis.yml: Remove the unused UNRELIABLE environment variable
  .travis.yml: Update the jobs to Ubuntu 22.04
  .travis.yml: Do some more testing with Clang
  tests: Remove Ubuntu 20.04 container
  tests/lcitool/libvirt-ci: Update to the latest master branch
  tests/docker/dockerfiles: Run lcitool-refresh after the lcitool update
  tests: Update our CI to use CentOS Stream 9 instead of 8

Zhao Liu (1):
  docs: i386: pc: Update maximum CPU numbers for PC Q35

 MAINTAINERS|   6 +-
 docs/devel/submitting-a-patch.rst  |   2 +-
 docs/system/target-i386-desc.rst.inc   |   2 +-
 hw/s390x/s390-virtio-hcall.h   |   2 +
 target/s390x/cpu_models.h  |  15 --
 hw/s390x/s390-stattrib.c   |   1 +
 tests/qtest/aspeed_fsi-test.c  |  20 +--
 tests/qtest/cmsdk-apb-dualtimer-test.c |   2 +-
 tests/qtest/cmsdk-apb-watchdog-test.c  |   2 +-
 tests/qtest/erst-test.c|   2 +-
 tests/qtest/ivshmem-test.c |  10 +-
 tests/qtest/libqos/ahci.c  |   4 +-
 tests/qtest/microbit-test.c|  46 +++---
 tests/qtest/sse-timer-test.c   |   4 +-
 tests/qtest/stm32l4x5_exti-test.c  | 138 +-
 tests/qtest/stm32l4x5_syscfg-test.c|  74 +-
 tests/unit/test-nested-aio-poll.c  |   7 -
 .gitlab-ci.d/buildtest.yml |  16 +--
 .gitlab-ci.d/container-core.yml|   4 +-
 .travis.yml|  24 +---
 .../stream/{8 => 9}/build-environment.yml  |  31 ++--
 .../ci/org.centos/stream/{8 => 9}/x86_64/configure |   4 +-
 .../org.centos/stream/{8 => 9}/x86_64/test-avocado |   0
 scripts/ci/setup/build-environment.yml |  44 +++---
 tests/docker/dockerfiles/alpine.docker |   3 +-
 .../dockerfiles/{centos8.docker => centos9.docker} |  35 ++---
 tests/docker/dockerfiles/debian-amd64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-arm64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-armel-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-armhf-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-i686-cross.docker  |   3 +-
 .../dockerfiles/debian-mips64el-cross.docker   |   3 +-
 .../docker/dockerfiles/debian-mipsel-cross.docker  |   3 +-
 .../docker/dockerfiles/debian-ppc64el-cross.docker |   3 +-
 .../docker/dockerfiles/debian-riscv64-cross.docker |   3 +-
 tests/docker/dockerfiles/debian-s390x-cross.docker |   3 +-
 tests/docker/dockerfiles/debian.docker |   1 +
 tests/docker/dockerfiles/fedora-win64-cross.docker |   3 +-
 tests/docker/dockerfiles/fedora.docker |   1 +
 tests/docker/dockerfiles/opensuse-leap.docker  |   1 +
 tests/docker/dockerfiles/ubuntu2004.docker | 157 -
 tests/docker/dockerfiles/ubuntu2204.docker |   1 +
 tests/lcitool/libvirt-ci   |   2 +-
 tests/lcitool/mappings.yml |  20 ---
 tests/lcitool/refresh  |   3 +-
 tests/vm/centos|   4 +-
 tests/vm/openbsd   |   6 +-
 47 files changed, 259 insertions(+), 468 deletions(-)
 rename scripts/ci/org.centos/stream/{8 => 9}/build-envi

[PATCH] .gitlab-ci.d/cirrus.yml: Fix the NetBSD and OpenBSD Cirrus-CI KVM jobs

[Thomas Huth]

Pulling the "master" libvirt-ci containers does not work anymore,
so we have to switch to the "latest" instead. See also:
https://gitlab.com/libvirt/libvirt/-/commit/5d591421220c850aa64a640
https://gitlab.com/libvirt/libvirt-ci/-/commit/6e3c5ccac77714be70c0

The effects were dormant for a year as the old ':master' tags were
not removed until some weeks ago.

The other Cirrus-CI jobs were already fixed in commit 1d2f2b35bc86b7a1
("gitlab-ci/cirrus: switch from 'master' to 'latest'"), but apparently
nobody noticed the KVM jobs so far that need to be triggered manually.

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

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 4671f069c3..8b45f72910 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -95,7 +95,7 @@ aarch64-macos-14-base-build:
 .cirrus_kvm_job:
   extends: .base_job_template
   stage: build
-  image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:master
+  image: registry.gitlab.com/libvirt/libvirt-ci/cirrus-run:latest
   needs: []
   timeout: 80m
   script:
-- 
2.44.0

Re: [PATCH 0/3] Remove useless architecture prefix from the CPU list

[Thomas Huth]

On 22/04/2024 10.03, Daniel P. Berrangé wrote:

On Sat, Apr 20, 2024 at 07:46:03AM +0200, Thomas Huth wrote:

Printing an architecture prefix in front of each CPU name is not helpful
at all: It is confusing for the users since they don't know whether they
have to specify these letters for the "-cpu" parameter, too, and it also
takes some precious space in the dense output of the CPU entries. Let's
simply remove those now.


Could it be said that this arch prefix is about to finally become useful
with Philippe's patches to add a 'qemu-system-any' command covering
multiple arches ?


I don't think so: In that case we'd rather print it once at the beginning of 
a list ("Available x86 CPUs:") instead of printing it in each and every line.


 Thomas

[PATCH 3/3] target/ppc/cpu_init: Remove "PowerPC" prefix from the CPU list

[Thomas Huth]

Printing a "PowerPC" in front of each CPU name is not helpful at all:
It is confusing for the users since they don't know whether they
have to specify these letters for the "-cpu" parameter, too, and
it also takes some precious space in the dense output of the CPU
entries. Let's simply remove this now and use two spaces at the
beginning of the lines for the indentation of the entries instead,
and add a "Available CPUs" in the very first line, like most other
target architectures are doing it for their CPU help output already.

Signed-off-by: Thomas Huth 
---
 target/ppc/cpu_init.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 6241de62ce..8b932dccfb 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -7063,7 +7063,7 @@ static void ppc_cpu_list_entry(gpointer data, gpointer 
user_data)
 }
 
 name = cpu_model_from_type(typename);
-qemu_printf("PowerPC %-16s PVR %08x\n", name, pcc->pvr);
+qemu_printf("  %-16s PVR %08x\n", name, pcc->pvr);
 for (i = 0; ppc_cpu_aliases[i].alias != NULL; i++) {
 PowerPCCPUAlias *alias = _cpu_aliases[i];
 ObjectClass *alias_oc = ppc_cpu_class_by_name(alias->model);
@@ -7076,10 +7076,10 @@ static void ppc_cpu_list_entry(gpointer data, gpointer 
user_data)
  * avoid printing the wrong alias here and use "preferred" instead
  */
 if (strcmp(alias->alias, family->desc) == 0) {
-qemu_printf("PowerPC %-16s (alias for preferred %s CPU)\n",
+qemu_printf("  %-16s (alias for preferred %s CPU)\n",
 alias->alias, family->desc);
 } else {
-qemu_printf("PowerPC %-16s (alias for %s)\n",
+qemu_printf("  %-16s (alias for %s)\n",
 alias->alias, name);
 }
 }
@@ -7090,6 +7090,7 @@ void ppc_cpu_list(void)
 {
 GSList *list;
 
+qemu_printf("Available CPUs:\n");
 list = object_class_get_list(TYPE_POWERPC_CPU, false);
 list = g_slist_sort(list, ppc_cpu_list_compare);
 g_slist_foreach(list, ppc_cpu_list_entry, NULL);
@@ -7097,7 +7098,7 @@ void ppc_cpu_list(void)
 
 #ifdef CONFIG_KVM
 qemu_printf("\n");
-qemu_printf("PowerPC %s\n", "host");
+qemu_printf("  %s\n", "host");
 #endif
 }
 
-- 
2.44.0

[PATCH 1/3] target/i386/cpu: Remove "x86" prefix from the CPU list

[Thomas Huth]

Printing an "x86" in front of each CPU name is not helpful at all:
It is confusing for the users since they don't know whether they
have to specify these letters for the "-cpu" parameter, too, and
it also takes some precious space in the dense output of the CPU
entries. Let's simply remove this now and use two spaces at the
beginning of the lines for the indentation of the entries instead,
like most other target architectures are doing it for their CPU help
output already.

Signed-off-by: Thomas Huth 
---
 target/i386/cpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 33760a2ee1..fd46e264a2 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -5572,7 +5572,7 @@ static void x86_cpu_list_entry(gpointer data, gpointer 
user_data)
 desc = g_strdup_printf("%s (deprecated)", olddesc);
 }
 
-qemu_printf("x86 %-20s  %s\n", name, desc);
+qemu_printf("  %-20s  %s\n", name, desc);
 }
 
 /* list available CPU models and flags */
-- 
2.44.0

[PATCH 0/3] Remove useless architecture prefix from the CPU list

[Thomas Huth]

Printing an architecture prefix in front of each CPU name is not helpful
at all: It is confusing for the users since they don't know whether they
have to specify these letters for the "-cpu" parameter, too, and it also
takes some precious space in the dense output of the CPU entries. Let's
simply remove those now.

Thomas Huth (3):
  target/i386/cpu: Remove "x86" prefix from the CPU list
  target/s390x/cpu_models: Rework the output of "-cpu help"
  target/ppc/cpu_init: Remove "PowerPC" prefix from the CPU list

 target/i386/cpu.c | 2 +-
 target/ppc/cpu_init.c | 9 +
 target/s390x/cpu_models.c | 9 +
 3 files changed, 11 insertions(+), 9 deletions(-)

-- 
2.44.0

[PATCH 2/3] target/s390x/cpu_models: Rework the output of "-cpu help"

[Thomas Huth]

Printing an "s390x" in front of each CPU name is not helpful at all:
It is confusing for the users since they don't know whether they
have to specify these letters for the "-cpu" parameter, too, and
it also takes some precious space in the dense output of the CPU
entries. Let's simply remove this now!

While we're at it, use two spaces at the beginning of the lines for
the indentation of the entries, and add a "Available CPUs" in the
very first line, like most other target architectures are doing it
for their "-cpu help" output already.

Signed-off-by: Thomas Huth 
---
 target/s390x/cpu_models.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 8ed3bb6a27..58c58f05a0 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -355,9 +355,9 @@ static void s390_print_cpu_model_list_entry(gpointer data, 
gpointer user_data)
 /* strip off the -s390x-cpu */
 g_strrstr(name, "-" TYPE_S390_CPU)[0] = 0;
 if (details->len) {
-qemu_printf("s390 %-15s %-35s (%s)\n", name, scc->desc, details->str);
+qemu_printf("  %-15s %-35s (%s)\n", name, scc->desc, details->str);
 } else {
-qemu_printf("s390 %-15s %-35s\n", name, scc->desc);
+qemu_printf("  %-15s %-35s\n", name, scc->desc);
 }
 g_free(name);
 }
@@ -402,6 +402,7 @@ void s390_cpu_list(void)
 S390Feat feat;
 GSList *list;
 
+qemu_printf("Available CPUs:\n");
 list = object_class_get_list(TYPE_S390_CPU, false);
 list = g_slist_sort(list, s390_cpu_list_compare);
 g_slist_foreach(list, s390_print_cpu_model_list_entry, NULL);
@@ -411,14 +412,14 @@ void s390_cpu_list(void)
 for (feat = 0; feat < S390_FEAT_MAX; feat++) {
 const S390FeatDef *def = s390_feat_def(feat);
 
-qemu_printf("%-20s %s\n", def->name, def->desc);
+qemu_printf("  %-20s %s\n", def->name, def->desc);
 }
 
 qemu_printf("\nRecognized feature groups:\n");
 for (group = 0; group < S390_FEAT_GROUP_MAX; group++) {
 const S390FeatGroupDef *def = s390_feat_group_def(group);
 
-qemu_printf("%-20s %s\n", def->name, def->desc);
+qemu_printf("  %-20s %s\n", def->name, def->desc);
 }
 }
 
-- 
2.44.0

[PATCH v2 2/4] target/sparc/cpu: Avoid spaces by default in the CPU names

[Thomas Huth]

The output of "-cpu help" is currently rather confusing to the users:
It might not be fully clear which part of the output defines the CPU
names since the CPU names contain white spaces (which we later have to
convert into dashes internally). At best it's at least a nuisance since
the users might need to specify the CPU names with quoting on the command
line if they are not aware of the fact that the CPU names could be written
with dashes instead. So let's finally clean up this mess by using dashes
instead of white spaces for the CPU names, like we're doing it internally
later (and like we're doing it in most other targets of QEMU).
Note that it is still possible to pass the CPU names with spaces to the
"-cpu" option, since sparc_cpu_type_name() still translates those to "-".

Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2141
Reviewed-by: Richard Henderson 
Reviewed-by: Mark Cave-Ayland 
Signed-off-by: Thomas Huth 
---
 target/sparc/cpu.c | 56 +++---
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/target/sparc/cpu.c b/target/sparc/cpu.c
index 774e234e09..593c8d6867 100644
--- a/target/sparc/cpu.c
+++ b/target/sparc/cpu.c
@@ -206,7 +206,7 @@ void cpu_sparc_set_id(CPUSPARCState *env, unsigned int cpu)
 static const sparc_def_t sparc_defs[] = {
 #ifdef TARGET_SPARC64
 {
-.name = "Fujitsu Sparc64",
+.name = "Fujitsu-Sparc64",
 .iu_version = ((0x04ULL << 48) | (0x02ULL << 32) | (0ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -215,7 +215,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "Fujitsu Sparc64 III",
+.name = "Fujitsu-Sparc64-III",
 .iu_version = ((0x04ULL << 48) | (0x03ULL << 32) | (0ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -224,7 +224,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "Fujitsu Sparc64 IV",
+.name = "Fujitsu-Sparc64-IV",
 .iu_version = ((0x04ULL << 48) | (0x04ULL << 32) | (0ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -233,7 +233,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "Fujitsu Sparc64 V",
+.name = "Fujitsu-Sparc64-V",
 .iu_version = ((0x04ULL << 48) | (0x05ULL << 32) | (0x51ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -242,7 +242,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "TI UltraSparc I",
+.name = "TI-UltraSparc-I",
 .iu_version = ((0x17ULL << 48) | (0x10ULL << 32) | (0x40ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -251,7 +251,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "TI UltraSparc II",
+.name = "TI-UltraSparc-II",
 .iu_version = ((0x17ULL << 48) | (0x11ULL << 32) | (0x20ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -260,7 +260,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "TI UltraSparc IIi",
+.name = "TI-UltraSparc-IIi",
 .iu_version = ((0x17ULL << 48) | (0x12ULL << 32) | (0x91ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -269,7 +269,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "TI UltraSparc IIe",
+.name = "TI-UltraSparc-IIe",
 .iu_version = ((0x17ULL << 48) | (0x13ULL << 32) | (0x14ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -278,7 +278,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "Sun UltraSparc III",
+.name = "Sun-UltraSparc-III",
 .iu_version = ((0x3eULL << 48) | (0x14ULL << 32) | (0x34ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -287,7 +287,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "Sun UltraSparc III Cu",
+.name = "Sun-UltraSparc-III-Cu",
 .iu_version = ((0x3eULL << 48) | (0x15ULL << 32

[PATCH v2 0/4] Sparc CPU naming and help text improvements

[Thomas Huth]

The Sparc CPU naming and the corresponding help text is somewhat
confusing for the users. We should avoid spaces in the Names and
provide clear information to the users what can be passed to the
"-cpu" option.
While we're at it, also remove the "+" from two of the CPU names
since this character is now not allowed in device names anymore
(and was worked around with an ugly hack in qom/object.c so far).

v2:
- Use "Sun-UltraSparc-IIIi-plus" and "Sun-UltraSparc-IV-plus"
  instead of just adding a "p" at the end
- Drop the sentence about NetBSD and OpenBSD in the docs since
  these problems are likely fixed since a long time already
- Added Reviewed-bys from earlier series and updated the patch
  descriptions a little bit

Thomas Huth (4):
  target/sparc/cpu: Rename the CPU models with a "+" in their names
  target/sparc/cpu: Avoid spaces by default in the CPU names
  docs/system/target-sparc: Improve the Sparc documentation
  docs/about: Deprecate the old "UltraSparc" CPU names that contain a
"+"

 docs/about/deprecated.rst|  9 +
 docs/system/target-sparc.rst | 12 ---
 qom/object.c |  8 -
 target/sparc/cpu.c   | 66 +---
 4 files changed, 54 insertions(+), 41 deletions(-)

-- 
2.44.0

[PATCH v2 4/4] docs/about: Deprecate the old "UltraSparc" CPU names that contain a "+"

[Thomas Huth]

For consistency we should drop the names with a "+" in it in the
long run.

Reviewed-by: Mark Cave-Ayland 
Signed-off-by: Thomas Huth 
---
 docs/about/deprecated.rst | 9 +
 1 file changed, 9 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 6b932961bc..70026c3c11 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -206,6 +206,15 @@ in the QEMU object model anymore. ``power5+``, 
``power5+_v2.1``,
 an alias, but for consistency these will get removed in a future
 release, too. Use ``power5p_v2.1`` and ``power7p_v2.1`` instead.
 
+``Sun-UltraSparc-IIIi+`` and ``Sun-UltraSparc-IV+`` CPU names (since 9.1)
+'
+
+The character "+" in device (and thus also CPU) names is not allowed
+in the QEMU object model anymore. ``Sun-UltraSparc-IIIi+`` and
+``Sun-UltraSparc-IV+`` are currently still supported via a workaround,
+but for consistency these will get removed in a future release, too.
+Use ``Sun-UltraSparc-IIIi-plus`` and ``Sun-UltraSparc-IV-plus`` instead.
+
 CRIS CPU architecture (since 9.0)
 '
 
-- 
2.44.0

[PATCH v2 3/4] docs/system/target-sparc: Improve the Sparc documentation

[Thomas Huth]

Add some words about how to enable or disable boolean features,
and remove the note about a Linux kernel being available on the
QEMU website (they have been removed long ago already), and the
note about NetBSD and OpenBSD still having issues (they should
work fine nowadays).

Fixes: https://gitlab.com/qemu-project/qemu/-/issues/2141
Signed-off-by: Thomas Huth 
---
 docs/system/target-sparc.rst | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/docs/system/target-sparc.rst b/docs/system/target-sparc.rst
index 9ec8c90c14..54bd8b6ead 100644
--- a/docs/system/target-sparc.rst
+++ b/docs/system/target-sparc.rst
@@ -27,6 +27,11 @@ architecture machines:
 The emulation is somewhat complete. SMP up to 16 CPUs is supported, but
 Linux limits the number of usable CPUs to 4.
 
+The list of available CPUs can be viewed by starting QEMU with ``-cpu help``.
+Optional boolean features can be added with a "+" in front of the feature name,
+or disabled with a "-" in front of the name, for example
+``-cpu TI-SuperSparc-II,+float128``.
+
 QEMU emulates the following sun4m peripherals:
 
 -  IOMMU
@@ -55,8 +60,5 @@ OpenBIOS is a free (GPL v2) portable firmware implementation. 
The goal
 is to implement a 100% IEEE 1275-1994 (referred to as Open Firmware)
 compliant firmware.
 
-A sample Linux 2.6 series kernel and ram disk image are available on the
-QEMU web site. There are still issues with NetBSD and OpenBSD, but most
-kernel versions work. Please note that currently older Solaris kernels
-don't work probably due to interface issues between OpenBIOS and
-Solaris.
+Please note that currently older Solaris kernels don't work probably due
+to interface issues between OpenBIOS and Solaris.
-- 
2.44.0

[PATCH v2 1/4] target/sparc/cpu: Rename the CPU models with a "+" in their names

[Thomas Huth]

Commit b447378e12 ("qom/object: Limit type names to alphanumerical ...")
cut down the amount of allowed characters for QOM types to a saner set.
The "+" character was meant to be included in this set, so we had to
add a hack there to still allow the legacy names of POWER and Sparc64
CPUs. However, instead of putting such a hack in the common QOM code,
there is a much better place to do this: The sparc_cpu_class_by_name()
function which is used to look up the names of all Sparc CPUs.
Thus let's finally get rid of the "+" in the Sparc CPU names, and provide
backward compatibility for the old names via some simple checks in the
sparc_cpu_class_by_name() function.

Reviewed-by: Mark Cave-Ayland 
Signed-off-by: Thomas Huth 
---
 qom/object.c   |  8 
 target/sparc/cpu.c | 14 --
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/qom/object.c b/qom/object.c
index d4a001cf41..759e194972 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -158,14 +158,6 @@ static bool type_name_is_valid(const char *name)
 "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
 "0123456789-_.");
 
-/* Allow some legacy names with '+' in it for compatibility reasons */
-if (name[plen] == '+') {
-if (plen >= 17 && g_str_has_prefix(name, "Sun-UltraSparc-I")) {
-/* Allow "Sun-UltraSparc-IV+" and "Sun-UltraSparc-IIIi+" */
-return true;
-}
-}
-
 return plen == slen;
 }
 
diff --git a/target/sparc/cpu.c b/target/sparc/cpu.c
index e820f50acf..774e234e09 100644
--- a/target/sparc/cpu.c
+++ b/target/sparc/cpu.c
@@ -314,7 +314,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES,
 },
 {
-.name = "Sun UltraSparc IV+",
+.name = "Sun UltraSparc IV plus",
 .iu_version = ((0x3eULL << 48) | (0x19ULL << 32) | (0x22ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_12,
@@ -323,7 +323,7 @@ static const sparc_def_t sparc_defs[] = {
 .features = CPU_DEFAULT_FEATURES | CPU_FEATURE_CMT,
 },
 {
-.name = "Sun UltraSparc IIIi+",
+.name = "Sun UltraSparc IIIi plus",
 .iu_version = ((0x3eULL << 48) | (0x22ULL << 32) | (0ULL << 24)),
 .fpu_version = 0x,
 .mmu_version = mmu_us_3,
@@ -762,6 +762,16 @@ static ObjectClass *sparc_cpu_class_by_name(const char 
*cpu_model)
 char *typename;
 
 typename = sparc_cpu_type_name(cpu_model);
+
+/* Fix up legacy names with '+' in it */
+if (g_str_equal(typename, SPARC_CPU_TYPE_NAME("Sun-UltraSparc-IV+"))) {
+g_free(typename);
+typename = g_strdup(SPARC_CPU_TYPE_NAME("Sun-UltraSparc-IV-plus"));
+} else if (g_str_equal(typename, 
SPARC_CPU_TYPE_NAME("Sun-UltraSparc-IIIi+"))) {
+g_free(typename);
+typename = g_strdup(SPARC_CPU_TYPE_NAME("Sun-UltraSparc-IIIi-plus"));
+}
+
 oc = object_class_by_name(typename);
 g_free(typename);
 return oc;
-- 
2.44.0

Re: [PATCH 6/6] target/s390x/cpu_models_sysemu: Drop local @err in apply_cpu_model()

[Thomas Huth]

On 19/04/2024 08.57, Zhao Liu wrote:

From: Zhao Liu 

Use @errp to fetech error information directly and drop the local
virable @err.


With the typos fixed:

Reviewed-by: Thomas Huth 

Re: [PATCH 5/6] target/s390x/cpu_models: Make kvm_s390_apply_cpu_model() return boolean

[Thomas Huth]

On 19/04/2024 08.57, Zhao Liu wrote:

From: Zhao Liu 

As error.h suggested, the best practice for callee is to return
something to indicate success / failure.

So make kvm_s390_apply_cpu_model() return boolean and check the
returned boolean in apply_cpu_model() instead of accessing @err.

Signed-off-by: Zhao Liu 
---
  target/s390x/cpu_models.h|  5 +++--
  target/s390x/cpu_models_sysemu.c |  3 +--
  target/s390x/kvm/kvm.c   | 15 ---
  3 files changed, 12 insertions(+), 11 deletions(-)


Reviewed-by: Thomas Huth 

Re: [PATCH 4/6] target/s390x/cpu_models: Drop local @err in get_max_cpu_model()

[Thomas Huth]

On 19/04/2024 08.57, Zhao Liu wrote:

From: Zhao Liu 

Use @errp to fetech error information directly and drop the local
virable @err.


Copy-n-paste of the same typos as in patch 2 ;-)


Signed-off-by: Zhao Liu 
---
  target/s390x/cpu_models.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index a0e4acb707d7..aae452cfd3fc 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -551,7 +551,6 @@ static bool check_compatibility(const S390CPUModel 
*max_model,
  
  S390CPUModel *get_max_cpu_model(Error **errp)

  {
-Error *err = NULL;
  static S390CPUModel max_model;
  static bool cached;
  
@@ -560,8 +559,7 @@ S390CPUModel *get_max_cpu_model(Error **errp)

  }
  
  if (kvm_enabled()) {

-if (!kvm_s390_get_host_cpu_model(_model, )) {
-error_propagate(errp, err);
+if (!kvm_s390_get_host_cpu_model(_model, errp)) {
  return NULL;
  }
  } else {


With the typos fixed:
Reviewed-by: Thomas Huth 

Re: [PATCH 3/6] target/s390x/cpu_models: Make kvm_s390_get_host_cpu_model() return boolean

[Thomas Huth]

On 19/04/2024 08.57, Zhao Liu wrote:

From: Zhao Liu 

As error.h suggested, the best practice for callee is to return
something to indicate success / failure.

So make kvm_s390_get_host_cpu_model() return boolean and check the
returned boolean in get_max_cpu_model() instead of accessing @err.

Additionally, since now get_max_cpu_model() returns directly if
kvm_s390_get_host_cpu_model() fills @err, so make
kvm_s390_get_host_cpu_model() return true by default for the non-KVM
case in target/s390x/cpu_models.h.


You could also argue the other way round that there should be something in 
*model if it returns "true" ... anyway, the stub should never be executed, 
so it likely doesn't matter too much, but I'd still prefer if we'd rather 
return "false" in the non-KVM stub instead.



index d7b89129891a..5041c1e10fed 100644
--- a/target/s390x/cpu_models.h
+++ b/target/s390x/cpu_models.h
@@ -116,12 +116,13 @@ S390CPUDef const *s390_find_cpu_def(uint16_t type, 
uint8_t gen, uint8_t ec_ga,
  
  #ifdef CONFIG_KVM

  bool kvm_s390_cpu_models_supported(void);
-void kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp);
+bool kvm_s390_get_host_cpu_model(S390CPUModel *model, Error **errp);
  void kvm_s390_apply_cpu_model(const S390CPUModel *model,  Error **errp);
  #else
-static inline void kvm_s390_get_host_cpu_model(S390CPUModel *model,
+static inline bool kvm_s390_get_host_cpu_model(S390CPUModel *model,
 Error **errp)
  {
+return true;
  }


 Thomas

Re: [PATCH 2/6] target/s390x/cpu_model: Drop local @err in s390_realize_cpu_model()

[Thomas Huth]

On 19/04/2024 08.57, Zhao Liu wrote:

From: Zhao Liu 

Use @errp to fetech error information directly and drop the local


s/fetech/fetch/


virable @err.


s/virable/variable/


Suggested-by: Thomas Huth 
Signed-off-by: Zhao Liu 
---
  target/s390x/cpu_models.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)


With the typos fixed:
Reviewed-by: Thomas Huth 

Re: [PATCH 1/6] target/s390x/cpu_model: Make check_compatibility() return boolean

[Thomas Huth]

On 19/04/2024 08.57, Zhao Liu wrote:

From: Zhao Liu 

As error.h suggested, the best practice for callee is to return
something to indicate success / failure.

With returned boolean, there's no need to check @err.

Suggested-by: Thomas Huth 
Signed-off-by: Zhao Liu 
---
  target/s390x/cpu_models.c | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)


Reviewed-by: Thomas Huth 

Re: [PATCH 4/5] docs/system/target-sparc: Improve the Sparc documentation

[Thomas Huth]

On 18/04/2024 22.27, Mark Cave-Ayland wrote:

On 07/03/2024 17:43, Thomas Huth wrote:


Add some words about how to enable or disable boolean features,
and remove the note about a Linux kernel being available on the
QEMU website (they have been removed long ago already).

Signed-off-by: Thomas Huth 
---
  docs/system/target-sparc.rst | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/docs/system/target-sparc.rst b/docs/system/target-sparc.rst
index 9ec8c90c14..9f418b9d3e 100644
--- a/docs/system/target-sparc.rst
+++ b/docs/system/target-sparc.rst
@@ -27,6 +27,11 @@ architecture machines:
  The emulation is somewhat complete. SMP up to 16 CPUs is supported, but
  Linux limits the number of usable CPUs to 4.
+The list of available CPUs can be viewed by starting QEMU with ``-cpu 
help``.
+Optional boolean features can be added with a "+" in front of the feature 
name,

+or disabled with a "-" in front of the name, for example
+``-cpu TI-SuperSparc-II,+float128``.
+
  QEMU emulates the following sun4m peripherals:
  -  IOMMU
@@ -55,8 +60,7 @@ OpenBIOS is a free (GPL v2) portable firmware 
implementation. The goal

  is to implement a 100% IEEE 1275-1994 (referred to as Open Firmware)
  compliant firmware.
-A sample Linux 2.6 series kernel and ram disk image are available on the
-QEMU web site. There are still issues with NetBSD and OpenBSD, but most
+There are still issues with NetBSD and OpenBSD, but most
  kernel versions work. Please note that currently older Solaris kernels
  don't work probably due to interface issues between OpenBIOS and
  Solaris.


Just curious as to what current issues exist with NetBSD and OpenBSD? At 
least both my NetBSD and OpenBSD test images survive a casual boot test here 
with latest git.


Maybe it's also about a long fixed bug ... shall I remove that sentence 
while I'm at it?


 Thomas