RE: [PATCH v7 1/7] docs/migration: add qpl compression feature

2024-06-06 Thread Liu, Yuan1
> -Original Message-
> From: Fabiano Rosas 
> Sent: Thursday, June 6, 2024 4:00 AM
> To: Liu, Yuan1 ; pet...@redhat.com;
> pbonz...@redhat.com; marcandre.lur...@redhat.com; berra...@redhat.com;
> th...@redhat.com; phi...@linaro.org
> Cc: qemu-devel@nongnu.org; Liu, Yuan1 ; Zou, Nanhai
> ; shameerali.kolothum.th...@huawei.com
> Subject: Re: [PATCH v7 1/7] docs/migration: add qpl compression feature
> 
> Yuan Liu  writes:
> 
> > add Intel Query Processing Library (QPL) compression method
> > introduction
> >
> > Signed-off-by: Yuan Liu 
> > Reviewed-by: Nanhai Zou 
> 
> Just some nits if you need to respin. Otherwise I can touch up in the
> migration tree.
> 
> Reviewed-by: Fabiano Rosas 

Thank you very much, there is nothing I need to change for this patch, 
if this set of patches needs the next version, I will fix the nits
according to your suggestions.

> > ---
> >  docs/devel/migration/features.rst|   1 +
> >  docs/devel/migration/qpl-compression.rst | 262 +++
> >  2 files changed, 263 insertions(+)
> >  create mode 100644 docs/devel/migration/qpl-compression.rst
> >
> > diff --git a/docs/devel/migration/features.rst
> b/docs/devel/migration/features.rst
> > index d5ca7b86d5..bc98b65075 100644
> > --- a/docs/devel/migration/features.rst
> > +++ b/docs/devel/migration/features.rst
> > @@ -12,3 +12,4 @@ Migration has plenty of features to support different
> use cases.
> > virtio
> > mapped-ram
> > CPR
> > +   qpl-compression
> > diff --git a/docs/devel/migration/qpl-compression.rst
> b/docs/devel/migration/qpl-compression.rst
> > new file mode 100644
> > index 00..13fb7a67b1
> > --- /dev/null
> > +++ b/docs/devel/migration/qpl-compression.rst
> > @@ -0,0 +1,262 @@
> > +===
> > +QPL Compression
> > +===
> > +The Intel Query Processing Library (Intel ``QPL``) is an open-source
> library to
> > +provide compression and decompression features and it is based on
> deflate
> > +compression algorithm (RFC 1951).
> > +
> > +The ``QPL`` compression relies on Intel In-Memory Analytics
> Accelerator(``IAA``)
> > +and Shared Virtual Memory(``SVM``) technology, they are new features
> supported
> > +from Intel 4th Gen Intel Xeon Scalable processors, codenamed Sapphire
> Rapids
> > +processor(``SPR``).
> > +
> > +For more ``QPL`` introduction, please refer to `QPL Introduction
> >
> + .html>`_
> > +
> > +QPL Compression Framework
> > +=
> > +
> > +::
> > +
> > +  ++   +--+
> > +  | MultiFD Thread |   |accel-config tool |
> > +  +---++   ++-+
> > +  | |
> > +  | |
> > +  |compress/decompress  |
> > +  +---++| Setup IAA
> > +  |  QPL library   || Resources
> > +  +---+---++|
> > +  |   | |
> > +  |   +-+---+
> > +  |   Open IAA  |
> > +  |   Devices +-+-+
> > +  |   |idxd driver|
> > +  |   +-+-+
> > +  | |
> > +  | |
> > +  |   +-+-+
> > +  +---+IAA Devices|
> > +  Submit jobs +---+
> > +  via enqcmd
> > +
> > +
> > +QPL Build And Installation
> > +--
> > +
> > +.. code-block:: shell
> > +
> > +  $git clone --recursive https://github.com/intel/qpl.git qpl
> > +  $mkdir qpl/build
> > +  $cd qpl/build
> > +  $cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr -
> DQPL_LIBRARY_TYPE=SHARED ..
> > +  $sudo cmake --build . --target install
> > +
> > +For more details about ``QPL`` installation, please refer to `QPL
> Installation
> >
> + html>`_
> > +
> > +IAA Device Management
> > +-
> > +
> > +The number of ``IAA`` devices will vary depending on the Xeon product
> model.
> > +On a ``SPR`` server, there can be a maximum of 8 ``IAA`` devices, with
> up to
> > +4 devices per socket.
> > +
> > +By default, all ``IAA`` devices are disabled and need to be configured
> and
> > +enabled by users manually.
> > +
> > +Check the number of devices through the following command
> > +
> > +.. code-block:: shell
> > +
> > +  #lspci -d 8086:0cfe
> > +  6a:02.0 System peripheral: Intel Corporation Device 0cfe
> > +  6f:02.0 System peripheral: Intel Corporation Device 0cfe
> > +  74:02.0 System peripheral: Intel Corporation Device 0cfe
> > +  79:02.0 System peripheral: Intel Corporation Device 0cfe
> > +  e7:02.0 System peripheral: Intel Corporation Device 0cfe
> > +  ec:02.0 System peripheral: Intel Corporation Device 0cfe
> > +  f1:02.0 System peripheral: Intel Corporation Device 0cfe
> > +  f6:02.0 S

RE: [PATCH 5/7] migration/multifd: Add UADK based compression and decompression

2024-06-06 Thread Shameerali Kolothum Thodi via



> -Original Message-
> From: Fabiano Rosas 
> Sent: Wednesday, June 5, 2024 7:57 PM
> To: Shameerali Kolothum Thodi ;
> pet...@redhat.com; yuan1@intel.com
> Cc: qemu-devel@nongnu.org; Linuxarm ; linwenkai
> (C) ; zhangfei@linaro.org; huangchenghai
> 
> Subject: Re: [PATCH 5/7] migration/multifd: Add UADK based compression
> and decompression
> 
> Shameer Kolothum via  writes:
> 
> > Uses UADK wd_do_comp_sync() API to (de)compress a normal page using
> > hardware accelerator.
> >
> > Signed-off-by: Shameer Kolothum
> 
> 
> A couple of comments below.
> 
> Reviewed-by: Fabiano Rosas 
> > ---
> >  migration/multifd-uadk.c | 132
> ++-
> >  1 file changed, 130 insertions(+), 2 deletions(-)
> >
> > diff --git a/migration/multifd-uadk.c b/migration/multifd-uadk.c
> > index 3172e4d5ca..3329819bd4 100644
> > --- a/migration/multifd-uadk.c
> > +++ b/migration/multifd-uadk.c
> > @@ -13,6 +13,7 @@
> >  #include "qemu/osdep.h"
> >  #include "qemu/module.h"
> >  #include "qapi/error.h"
> > +#include "exec/ramblock.h"
> >  #include "migration.h"
> >  #include "multifd.h"
> >  #include "options.h"
> > @@ -140,6 +141,15 @@ static void
> multifd_uadk_send_cleanup(MultiFDSendParams *p, Error **errp)
> >  p->compress_data = NULL;
> >  }
> >
> > +static inline void prepare_next_iov(MultiFDSendParams *p, void *base,
> > +uint32_t len)
> > +{
> > +p->iov[p->iovs_num].iov_base = (uint8_t *)base;
> > +p->iov[p->iovs_num].iov_len = len;
> > +p->next_packet_size += len;
> > +p->iovs_num++;
> > +}
> > +
> >  /**
> >   * multifd_uadk_send_prepare: prepare data to be able to send
> >   *
> > @@ -153,7 +163,56 @@ static void
> multifd_uadk_send_cleanup(MultiFDSendParams *p, Error **errp)
> >   */
> >  static int multifd_uadk_send_prepare(MultiFDSendParams *p, Error
> **errp)
> >  {
> > -return -1;
> > +struct wd_data *uadk_data = p->compress_data;
> > +uint32_t hdr_size;
> > +uint8_t *buf = uadk_data->buf;
> > +int ret = 0;
> > +
> > +if (!multifd_send_prepare_common(p)) {
> > +goto out;
> > +}
> > +
> > +hdr_size = p->pages->normal_num * sizeof(uint32_t);
> > +/* prepare the header that stores the lengths of all compressed data */
> > +prepare_next_iov(p, uadk_data->buf_hdr, hdr_size);
> > +
> > +for (int i = 0; i < p->pages->normal_num; i++) {
> > +struct wd_comp_req creq = {
> > +.op_type = WD_DIR_COMPRESS,
> > +.src = p->pages->block->host + p->pages->offset[i],
> > +.src_len = p->page_size,
> > +.dst = buf,
> > +/* Set dst_len to double the src to take care of -ve 
> > compression */
> 
> What's -ve compression?

Just meant the case where output is > input. I can reword this.

> 
> > +.dst_len = p->page_size * 2,
> > +};
> > +
> > +ret = wd_do_comp_sync(uadk_data->handle, &creq);
> > +if (ret || creq.status) {
> > +error_setg(errp, "multifd %u: failed wd_do_comp_sync, ret %d
> status %d",
> > +   p->id, ret, creq.status);
> > +return -1;
> > +}
> > +if (creq.dst_len < p->page_size) {
> > +uadk_data->buf_hdr[i] = cpu_to_be32(creq.dst_len);
> > +prepare_next_iov(p, buf, creq.dst_len);
> > +buf += creq.dst_len;
> > +} else {
> > +/*
> > + * Send raw data if compressed out >= page_size. We might be
> better
> > + * off sending raw data if output is slightly less than 
> > page_size
> > + * as well because at the receive end we can skip the
> decompression.
> > + * But it is tricky to find the right number here.
> > + */
> > +uadk_data->buf_hdr[i] = cpu_to_be32(p->page_size);
> > +prepare_next_iov(p, p->pages->block->host + 
> > p->pages->offset[i],
> > + p->page_size);
> > +buf += p->page_size;
> > +}
> > +}
> > +out:
> > +p->flags |= MULTIFD_FLAG_UADK;
> > +multifd_send_fill_packet(p);
> > +return 0;
> >  }
> >
> >  /**
> > @@ -206,7 +265,76 @@ static void
> multifd_uadk_recv_cleanup(MultiFDRecvParams *p)
> >   */
> >  static int multifd_uadk_recv(MultiFDRecvParams *p, Error **errp)
> >  {
> > -return -1;
> > +struct wd_data *uadk_data = p->compress_data;
> > +uint32_t in_size = p->next_packet_size;
> > +uint32_t flags = p->flags & MULTIFD_FLAG_COMPRESSION_MASK;
> > +uint32_t hdr_len = p->normal_num * sizeof(uint32_t);
> > +uint32_t data_len = 0;
> > +uint8_t *buf = uadk_data->buf;
> > +int ret = 0;
> > +
> > +if (flags != MULTIFD_FLAG_UADK) {
> > +error_setg(errp, "multifd %u: flags received %x flags expected %x",
> > +   p->id, flags, MULTIFD_FLAG_ZLIB);
> > +return -1;
> > +}
> > +
> > +multifd_recv_zero_page_process(p);
> > +  

Re: [PULL 07/20] virtio-net: Do not propagate ebpf-rss-fds errors

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 05:14:20AM +0900, Akihiko Odaki wrote:
> On 2024/06/05 19:23, Daniel P. Berrangé wrote:
> > On Tue, Jun 04, 2024 at 03:37:42PM +0800, Jason Wang wrote:
> > > From: Akihiko Odaki 
> > > 
> > > Propagating ebpf-rss-fds errors has several problems.
> > > 
> > > First, it makes device realization fail and disables the fallback to the
> > > conventional eBPF loading.
> > 
> > AFAICT, this is not a bug - this is desired behaviour.
> > 
> > If the user/mgmt app has told QEMU to use FDs it has passed
> > in, then any failure to do this *MUST* be treated as a fatal
> > error. Falling back to other codepaths is ignoring a direct
> > user request.
> 
> The FD options are more like an assistance rather than a request. When QEMU
> does not have a permission to load eBPF programs, a user can get the eBPF
> programs with the request-ebpf command of QMP, load it, and pass the FDs to
> QEMU.

That still doesn't alter the fact that if the user has chosen to pass FDs
and QEMU fails to use them, it *MUST* report that error back to the user.

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




Re: [PULL 07/20] virtio-net: Do not propagate ebpf-rss-fds errors

2024-06-06 Thread Akihiko Odaki

On 2024/06/06 16:14, Daniel P. Berrangé wrote:

On Thu, Jun 06, 2024 at 05:14:20AM +0900, Akihiko Odaki wrote:

On 2024/06/05 19:23, Daniel P. Berrangé wrote:

On Tue, Jun 04, 2024 at 03:37:42PM +0800, Jason Wang wrote:

From: Akihiko Odaki 

Propagating ebpf-rss-fds errors has several problems.

First, it makes device realization fail and disables the fallback to the
conventional eBPF loading.


AFAICT, this is not a bug - this is desired behaviour.

If the user/mgmt app has told QEMU to use FDs it has passed
in, then any failure to do this *MUST* be treated as a fatal
error. Falling back to other codepaths is ignoring a direct
user request.


The FD options are more like an assistance rather than a request. When QEMU
does not have a permission to load eBPF programs, a user can get the eBPF
programs with the request-ebpf command of QMP, load it, and pass the FDs to
QEMU.


That still doesn't alter the fact that if the user has chosen to pass FDs
and QEMU fails to use them, it *MUST* report that error back to the user.


The user should be more interested in whether the eBPF functionality is 
successfully enabled or not, and that is irrelevant from whether the 
eBPF program is loaded by QEMU or someone else. It is being worked on 
with another patch series:

https://patchew.org/QEMU/20240428-auto-v1-0-7b012216a...@daynix.com/

Regards,
Akihiko Odaki



Re: [PATCH v4 0/5] backends/hostmem: Report more errors on failures

2024-06-06 Thread Paolo Bonzini
Queued, thanks.

Paolo




Re: [PATCH] scsi-disk: Don't silently truncate serial number

2024-06-06 Thread Paolo Bonzini
Queued, thanks.

Paolo




Re: [PATCH] stubs/meson: Fix qemuutil build when --disable-system

2024-06-06 Thread Paolo Bonzini

On 6/5/24 17:25, Zhao Liu wrote:

Compiling without system, user, tools or guest-agent fails with the
following error message:

./configure --disable-system --disable-user --disable-tools \
--disable-guest-agent

error message:

/usr/bin/ld: libqemuutil.a.p/util_error-report.c.o: in function `error_printf':
/media/liuzhao/data/qemu-cook/build/../util/error-report.c:38: undefined 
reference to `error_vprintf'
/usr/bin/ld: libqemuutil.a.p/util_error-report.c.o: in function `vreport':
/media/liuzhao/data/qemu-cook/build/../util/error-report.c:215: undefined 
reference to `error_vprintf'
collect2: error: ld returned 1 exit status

This is because tests/bench and tests/unit both need qemuutil, which
requires error_vprintf stub when system is disabled.

Add error_vprintf stub into stub_ss for all cases other than disabling
system.


Should be "other than enabled system emulation", but...


-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'))
stub_ss.add(files('vmstate.c'))
-
-  # more symbols provided by the monitor
-  stub_ss.add(files('error-printf.c'))
  endif


... these should be left in, since it's possible to build with 
--enable-guest-agent --enable-system.


The best and easiest solution is simply to move error-printf.c to the 
unconditional section at the top of the file.  I queued the patch with 
that change.


Paolo


  if have_user
@@ -76,6 +69,9 @@ if have_system
stub_ss.add(files('target-monitor-defs.c'))
stub_ss.add(files('win32-kbd-hook.c'))
stub_ss.add(files('xen-hw-stub.c'))
+else
+  # more symbols provided by the monitor
+  stub_ss.add(files('error-printf.c'))
  endif
  
  if have_system or have_user





Re: [PATCH] stubs/meson: Fix qemuutil build when --disable-system

2024-06-06 Thread Zhao Liu
On Thu, Jun 06, 2024 at 09:41:47AM +0200, Paolo Bonzini wrote:
> Date: Thu, 6 Jun 2024 09:41:47 +0200
> From: Paolo Bonzini 
> Subject: Re: [PATCH] stubs/meson: Fix qemuutil build when --disable-system
> 
> On 6/5/24 17:25, Zhao Liu wrote:
> > Compiling without system, user, tools or guest-agent fails with the
> > following error message:
> > 
> > ./configure --disable-system --disable-user --disable-tools \
> > --disable-guest-agent
> > 
> > error message:
> > 
> > /usr/bin/ld: libqemuutil.a.p/util_error-report.c.o: in function 
> > `error_printf':
> > /media/liuzhao/data/qemu-cook/build/../util/error-report.c:38: undefined 
> > reference to `error_vprintf'
> > /usr/bin/ld: libqemuutil.a.p/util_error-report.c.o: in function `vreport':
> > /media/liuzhao/data/qemu-cook/build/../util/error-report.c:215: undefined 
> > reference to `error_vprintf'
> > collect2: error: ld returned 1 exit status
> > 
> > This is because tests/bench and tests/unit both need qemuutil, which
> > requires error_vprintf stub when system is disabled.
> > 
> > Add error_vprintf stub into stub_ss for all cases other than disabling
> > system.
> 
> Should be "other than enabled system emulation", but...
> 
> > -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'))
> > stub_ss.add(files('vmstate.c'))
> > -
> > -  # more symbols provided by the monitor
> > -  stub_ss.add(files('error-printf.c'))
> >   endif
> 
> ... these should be left in, since it's possible to build with
> --enable-guest-agent --enable-system.
> 
> The best and easiest solution is simply to move error-printf.c to the
> unconditional section at the top of the file.  I queued the patch with that
> change.

Thanks!! I can delete my v2 branch now. :-)




Re: [PULL 07/20] virtio-net: Do not propagate ebpf-rss-fds errors

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 04:19:11PM +0900, Akihiko Odaki wrote:
> On 2024/06/06 16:14, Daniel P. Berrangé wrote:
> > On Thu, Jun 06, 2024 at 05:14:20AM +0900, Akihiko Odaki wrote:
> > > On 2024/06/05 19:23, Daniel P. Berrangé wrote:
> > > > On Tue, Jun 04, 2024 at 03:37:42PM +0800, Jason Wang wrote:
> > > > > From: Akihiko Odaki 
> > > > > 
> > > > > Propagating ebpf-rss-fds errors has several problems.
> > > > > 
> > > > > First, it makes device realization fail and disables the fallback to 
> > > > > the
> > > > > conventional eBPF loading.
> > > > 
> > > > AFAICT, this is not a bug - this is desired behaviour.
> > > > 
> > > > If the user/mgmt app has told QEMU to use FDs it has passed
> > > > in, then any failure to do this *MUST* be treated as a fatal
> > > > error. Falling back to other codepaths is ignoring a direct
> > > > user request.
> > > 
> > > The FD options are more like an assistance rather than a request. When 
> > > QEMU
> > > does not have a permission to load eBPF programs, a user can get the eBPF
> > > programs with the request-ebpf command of QMP, load it, and pass the FDs 
> > > to
> > > QEMU.
> > 
> > That still doesn't alter the fact that if the user has chosen to pass FDs
> > and QEMU fails to use them, it *MUST* report that error back to the user.
> 
> The user should be more interested in whether the eBPF functionality is
> successfully enabled or not, and that is irrelevant from whether the eBPF
> program is loaded by QEMU or someone else.

No, this is wrong. A mgmt application or user will have made a decision
about *how* it wants QEMU to configure a particular feature. QEMU must
always honour the mgmt application's request, and not try to do something
different.

If the mgmt app did not want the FDs to be used, it would not have
passed them to QEMU in the first place. Ignoring the FDs is not likely
to work, because QEMU is unlikely to have permission to open the FDs
itself.

Ignoring the errors when creating the FDs, makes it much much harder
to detect and diagnose deployment problems, because the root cause
error is being discarded, and replaced by a later error which misleads
the app managing QEMU.

Always honouring the user requested config, or giving an error back
when it fails, is standard QEMU practice.

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




RE: [PATCH v3] mem/cxl_type3: support 3, 6, 12 and 16 interleave ways

2024-06-06 Thread Xingtao Yao (Fujitsu)
ping again.

> -Original Message-
> From: Yao, Xingtao/姚 幸涛 
> Sent: Friday, May 24, 2024 5:31 PM
> To: Yao, Xingtao/姚 幸涛 ;
> jonathan.came...@huawei.com; fan...@samsung.com
> Cc: qemu-devel@nongnu.org
> Subject: RE: [PATCH v3] mem/cxl_type3: support 3, 6, 12 and 16 interleave ways
> 
> ping.
> 
> > -Original Message-
> > From: Yao Xingtao 
> > Sent: Wednesday, May 8, 2024 8:53 AM
> > To: jonathan.came...@huawei.com; fan...@samsung.com
> > Cc: qemu-devel@nongnu.org; Yao, Xingtao/姚 幸涛 
> > Subject: [PATCH v3] mem/cxl_type3: support 3, 6, 12 and 16 interleave ways
> >
> > Since the kernel does not check the interleave capability, a
> > 3-way, 6-way, 12-way or 16-way region can be create normally.
> >
> > Applications can access the memory of 16-way region normally because
> > qemu can convert hpa to dpa correctly for the power of 2 interleave
> > ways, after kernel implementing the check, this kind of region will
> > not be created any more.
> >
> > For non power of 2 interleave ways, applications could not access the
> > memory normally and may occur some unexpected behaviors, such as
> > segmentation fault.
> >
> > So implements this feature is needed.
> >
> > Link:
> >
> https://lore.kernel.org/linux-cxl/3e84b919-7631-d1db-3e1d-33000f3f3868@fujits
> > u.com/
> > Signed-off-by: Yao Xingtao 
> > ---
> >  hw/cxl/cxl-component-utils.c |  9 +++--
> >  hw/mem/cxl_type3.c   | 15 +++
> >  2 files changed, 18 insertions(+), 6 deletions(-)
> >
> > diff --git a/hw/cxl/cxl-component-utils.c b/hw/cxl/cxl-component-utils.c
> > index cd116c0401..473895948b 100644
> > --- a/hw/cxl/cxl-component-utils.c
> > +++ b/hw/cxl/cxl-component-utils.c
> > @@ -243,8 +243,13 @@ static void hdm_init_common(uint32_t *reg_state,
> > uint32_t *write_msk,
> >  ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> > INTERLEAVE_4K, 1);
> >  ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> >   POISON_ON_ERR_CAP, 0);
> > -ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> > 3_6_12_WAY, 0);
> > -ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> 16_WAY,
> > 0);
> > +if (type == CXL2_TYPE3_DEVICE) {
> > +ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> > 3_6_12_WAY, 1);
> > +ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> > 16_WAY, 1);
> > +} else {
> > +ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> > 3_6_12_WAY, 0);
> > +ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> > 16_WAY, 0);
> > +}
> >  ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY, UIO,
> 0);
> >  ARRAY_FIELD_DP32(reg_state, CXL_HDM_DECODER_CAPABILITY,
> >   UIO_DECODER_COUNT, 0);
> > diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
> > index 3e42490b6c..b755318838 100644
> > --- a/hw/mem/cxl_type3.c
> > +++ b/hw/mem/cxl_type3.c
> > @@ -804,10 +804,17 @@ static bool cxl_type3_dpa(CXLType3Dev *ct3d, hwaddr
> > host_addr, uint64_t *dpa)
> >  continue;
> >  }
> >
> > -*dpa = dpa_base +
> > -((MAKE_64BIT_MASK(0, 8 + ig) & hpa_offset) |
> > - ((MAKE_64BIT_MASK(8 + ig + iw, 64 - 8 - ig - iw) & hpa_offset)
> > -  >> iw));
> > +if (iw < 8) {
> > +*dpa = dpa_base +
> > +((MAKE_64BIT_MASK(0, 8 + ig) & hpa_offset) |
> > + ((MAKE_64BIT_MASK(8 + ig + iw, 64 - 8 - ig - iw) &
> hpa_offset)
> > +  >> iw));
> > +} else {
> > +*dpa = dpa_base +
> > +((MAKE_64BIT_MASK(0, 8 + ig) & hpa_offset) |
> > + MAKE_64BIT_MASK(ig + iw, 64 - ig - iw) & hpa_offset)
> > +   >> (ig + iw)) / 3) << (ig + 8)));
> > +}
> >
> >  return true;
> >  }
> > --
> > 2.37.3




Re: [PATCH 01/20] qga: drop blocking of guest-get-memory-block-size command

2024-06-06 Thread Manos Pitsidianakis

On Tue, 04 Jun 2024 16:49, "Daniel P. Berrangé"  wrote:

This command has never existed in tree, since it was renamed to
guest-get-memory-block-info before being merged.

Signed-off-by: Daniel P. Berrangé 
---


Reviewed-by: Manos Pitsidianakis 


qga/commands-posix.c | 2 +-
qga/commands-win32.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 7f05996495..76af98ba32 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -3099,7 +3099,7 @@ GList *ga_command_init_blockedrpcs(GList *blockedrpcs)
"guest-suspend-disk", "guest-suspend-ram",
"guest-suspend-hybrid", "guest-get-vcpus", "guest-set-vcpus",
"guest-get-memory-blocks", "guest-set-memory-blocks",
-"guest-get-memory-block-size", "guest-get-memory-block-info",
+"guest-get-memory-block-info",
NULL};
char **p = (char **)list;

diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 0d1b836e87..9fe670d5b4 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -1995,7 +1995,7 @@ GList *ga_command_init_blockedrpcs(GList *blockedrpcs)
"guest-suspend-hybrid",
"guest-set-vcpus",
"guest-get-memory-blocks", "guest-set-memory-blocks",
-"guest-get-memory-block-size", "guest-get-memory-block-info",
+"guest-get-memory-block-info",
NULL};
char **p = (char **)list_unsupported;

--
2.45.1






[PATCH 0/2] python: expect a working python3-tomli package for Python <3.11

2024-06-06 Thread Paolo Bonzini
pythondeps.toml is parsed using either Python's embedded tomllib parser
new in Python 3.11, or the external tomli library for older versions.
The latter however was absent in Ubuntu 20.04, so we include a copy of
the wheel in python/wheels.  (For Debian bullseye, it is included in
the backports repository).

Now that Ubuntu 20.04 is not supported anymore, it can be dropped;
and with it the "ensure" subcommand of mkvenv.py, which was only
needed to bootstrap the venv with the TOML parser needed by
"ensuregroup".

Back when mkvenv.py was implemented, John and I had an idea of an
"isolated mode" that does not use any system packages.  With these
patches this means that, as things stand, the isolated mode can only
work with Python 3.11+; older versions would need special code in
mkvenv.py to install tomli from PyPI if system_site_packages==False[1].
Since the isolated mode does not exist yet, this is left for the future
comtemplation.

Paolo

[1] isolated mode probably would benefit from installing distlib instead
of using the pip._vendor.distlib hack; therefore, adding tomli would
not be a huge deal anyway.

Paolo Bonzini (2):
  Revert "python: use vendored tomli"
  python: mkvenv: remove ensure command

 docs/devel/build-system.rst|  13 ++-
 configure  |   4 -
 python/scripts/mkvenv.py   | 105 -
 python/scripts/vendor.py   |   3 -
 python/wheels/tomli-2.0.1-py3-none-any.whl | Bin 12757 -> 0 bytes
 5 files changed, 6 insertions(+), 119 deletions(-)
 delete mode 100644 python/wheels/tomli-2.0.1-py3-none-any.whl

-- 
2.45.1




[PATCH 2/2] python: mkvenv: remove ensure command

2024-06-06 Thread Paolo Bonzini
This was used to bootstrap the venv with a TOML parser, after which
ensuregroup is used.  Now that we expect it to be present as a system
package (either tomli or, for Python 3.11, tomllib), it is not needed
anymore.

Note that this means that, when implemented, the hypothetical "isolated"
mode that does not use any system packages will only work with Python
3.11+.

Signed-off-by: Paolo Bonzini 
---
 python/scripts/mkvenv.py | 105 ---
 1 file changed, 105 deletions(-)

diff --git a/python/scripts/mkvenv.py b/python/scripts/mkvenv.py
index d0b9c215ca2..f2526af0a04 100644
--- a/python/scripts/mkvenv.py
+++ b/python/scripts/mkvenv.py
@@ -13,7 +13,6 @@
 createcreate a venv
 post_init
   post-venv initialization
-ensureEnsure that the specified package is installed.
 ensuregroup
   Ensure that the specified package group is installed.
 
@@ -36,18 +35,6 @@
 
 --
 
-usage: mkvenv ensure [-h] [--online] [--dir DIR] dep_spec...
-
-positional arguments:
-  dep_specPEP 508 Dependency specification, e.g. 'meson>=0.61.5'
-
-options:
-  -h, --help  show this help message and exit
-  --onlineInstall packages from PyPI, if necessary.
-  --dir DIR   Path to vendored packages where we may install from.
-
---
-
 usage: mkvenv ensuregroup [-h] [--online] [--dir DIR] file group...
 
 positional arguments:
@@ -726,57 +713,6 @@ def _do_ensure(
 return None
 
 
-def ensure(
-dep_specs: Sequence[str],
-online: bool = False,
-wheels_dir: Optional[Union[str, Path]] = None,
-prog: Optional[str] = None,
-) -> None:
-"""
-Use pip to ensure we have the package specified by @dep_specs.
-
-If the package is already installed, do nothing. If online and
-wheels_dir are both provided, prefer packages found in wheels_dir
-first before connecting to PyPI.
-
-:param dep_specs:
-PEP 508 dependency specifications. e.g. ['meson>=0.61.5'].
-:param online: If True, fall back to PyPI.
-:param wheels_dir: If specified, search this path for packages.
-:param prog:
-If specified, use this program name for error diagnostics that will
-be presented to the user. e.g., 'sphinx-build' can be used as a
-bellwether for the presence of 'sphinx'.
-"""
-
-if not HAVE_DISTLIB:
-raise Ouch("a usable distlib could not be found, please install it")
-
-# Convert the depspecs to a dictionary, as if they came
-# from a section in a pythondeps.toml file
-group: Dict[str, Dict[str, str]] = {}
-for spec in dep_specs:
-name = distlib.version.LegacyMatcher(spec).name
-group[name] = {}
-
-spec = spec.strip()
-pos = len(name)
-ver = spec[pos:].strip()
-if ver:
-group[name]["accepted"] = ver
-
-if prog:
-group[name]["canary"] = prog
-prog = None
-
-result = _do_ensure(group, online, wheels_dir)
-if result:
-# Well, that's not good.
-if result[1]:
-raise Ouch(result[0])
-raise SystemExit(f"\n{result[0]}\n\n")
-
-
 def _parse_groups(file: str) -> Dict[str, Dict[str, Any]]:
 if not HAVE_TOMLLIB:
 if sys.version_info < (3, 11):
@@ -888,39 +824,6 @@ def _add_ensuregroup_subcommand(subparsers: Any) -> None:
 )
 
 
-def _add_ensure_subcommand(subparsers: Any) -> None:
-subparser = subparsers.add_parser(
-"ensure", help="Ensure that the specified package is installed."
-)
-subparser.add_argument(
-"--online",
-action="store_true",
-help="Install packages from PyPI, if necessary.",
-)
-subparser.add_argument(
-"--dir",
-type=str,
-action="store",
-help="Path to vendored packages where we may install from.",
-)
-subparser.add_argument(
-"--diagnose",
-type=str,
-action="store",
-help=(
-"Name of a shell utility to use for "
-"diagnostics if this command fails."
-),
-)
-subparser.add_argument(
-"dep_specs",
-type=str,
-action="store",
-help="PEP 508 Dependency specification, e.g. 'meson>=0.61.5'",
-nargs="+",
-)
-
-
 def main() -> int:
 """CLI interface to make_qemu_venv. See module docstring."""
 if os.environ.get("DEBUG") or os.environ.get("GITLAB_CI"):
@@ -944,7 +847,6 @@ def main() -> int:
 
 _add_create_subcommand(subparsers)
 _add_post_init_subcommand(subparsers)
-_add_ensure_subcommand(subparsers)
 _add_ensuregroup_subcommand(subparsers)
 
 args = parser.parse_args()
@@ -957,13 +859,6 @@ def main() -> int:
 )
 if args.command == "post_init":
 post_venv_setup()
-if args.command == "ensure":
-ensure(
-dep_specs=args.dep_specs,
-  

[PATCH 1/2] Revert "python: use vendored tomli"

2024-06-06 Thread Paolo Bonzini
Now that Ubuntu 20.04 is not included anymore, there is no need to ship
it as part of QEMU; Ubuntu 22.04 includes it and Leap users anyway
need to install all the required dependencies from PyPI.

This mostly reverts commit ec77ee7634de123b7c899739711000fd21dab68b,
with just some changes to the wording.

Signed-off-by: Paolo Bonzini 
---
 docs/devel/build-system.rst|  13 ++---
 configure  |   4 
 python/scripts/vendor.py   |   3 ---
 python/wheels/tomli-2.0.1-py3-none-any.whl | Bin 12757 -> 0 bytes
 4 files changed, 6 insertions(+), 14 deletions(-)
 delete mode 100644 python/wheels/tomli-2.0.1-py3-none-any.whl

diff --git a/docs/devel/build-system.rst b/docs/devel/build-system.rst
index f00adad3181..e01896d01c1 100644
--- a/docs/devel/build-system.rst
+++ b/docs/devel/build-system.rst
@@ -185,14 +185,13 @@ Bundled Python packages
 
 Python packages that are **mandatory** dependencies to build QEMU,
 but are not available in all supported distros, are bundled with the
-QEMU sources.  Currently this includes Meson (outdated in CentOS 8
-and derivatives, Ubuntu 20.04 and 22.04, and openSUSE Leap) and tomli
-(absent in Ubuntu 20.04).
+QEMU sources.  The only one is currently Meson (outdated in Ubuntu
+22.04 and openSUSE Leap).
 
-If you need to update these, please do so by modifying and rerunning
-``python/scripts/vendor.py``.  This script embeds the sha256 hash of
-package sources and checks it.  The pypi.org web site provides an easy
-way to retrieve the sha256 hash of the sources.
+In order to include a new or updated wheel, modify and rerun the
+``python/scripts/vendor.py`` script.  The script embeds the
+sha256 hash of package sources and checks it.  The pypi.org web site
+provides an easy way to retrieve the sha256 hash of the sources.
 
 
 Stage 2: Meson
diff --git a/configure b/configure
index 34027e3ccef..2a4d898da12 100755
--- a/configure
+++ b/configure
@@ -955,10 +955,6 @@ mkvenv="$python ${source_path}/python/scripts/mkvenv.py"
 
 # Finish preparing the virtual environment using vendored .whl files
 
-if $python -c 'import sys; sys.exit(sys.version_info >= (3,11))'; then
-$mkvenv ensure --dir "${source_path}/python/wheels" \
-'tomli>=1.2.0' || exit 1
-fi
 $mkvenv ensuregroup --dir "${source_path}/python/wheels" \
  ${source_path}/pythondeps.toml meson || exit 1
 
diff --git a/python/scripts/vendor.py b/python/scripts/vendor.py
index 1038b14ae0c..07aff97ccad 100755
--- a/python/scripts/vendor.py
+++ b/python/scripts/vendor.py
@@ -43,9 +43,6 @@ def main() -> int:
 packages = {
 "meson==1.2.3":
 "4533a43c34548edd1f63a276a42690fce15bde9409bcf20c4b8fa3d7e4d7cac1",
-
-"tomli==2.0.1":
-"939de3e7a6161af0c887ef91b7d41a53e7c5a1ca976325f429cb46ea9bc30ecc",
 }
 
 vendor_dir = Path(__file__, "..", "..", "wheels").resolve()
diff --git a/python/wheels/tomli-2.0.1-py3-none-any.whl 
b/python/wheels/tomli-2.0.1-py3-none-any.whl
deleted file mode 100644
index 
29670b98d16e2bc770d4fea718582e1dc0dd8aca..
GIT binary patch
literal 0
HcmV?d1

literal 12757
zcmZ{qW00mz)~%nar);aswyiF^x@_AQ|AI3o%P$utD{T6m2He0&NN|So~F^_w(VNn?R|;@
zxLMsg!)!(b77VNv?zz%6ElC@r!ak;`AYoCt71eEUY;AM-Sw9oL{)u4+y&|=ZD0ai)
z&HTJ?7>~`QFv{>OYkF`m)G0?T;R6}$wJ{RUkZ$o7+9c?ih_0D6_;R>j3Ix1nMh@z=ExC(w4EkK284SmJbdL
zZOS$YqC+Viuc-f1zK`DVdjHuH*wA~dFpfCvgm2PEyffyP6-!a2w)YT9cu;ct$^>nj
zvKsW=80hNd<~2yJJ2>F?k-ohNjvSlY2F7Zp@ta@ATi>1a82WC-0@p;6aiW3KU|>Dy
z4xR9QwlSPjW*Npepl*n#u
zn@T_2Ry5_pVNz-FW<#rHcd~@k$1SrLb`uQ0oPFS=Zo~(gn86*__o5EgZs<6{3w}oQ
zygS2wv3cI`rVY34Iy7O{*o*(H4AP81F4Sx(A#(b-CyIV(Iw|Evnj>dt;AN3H+&aEp`TTP(m<0EsmK`6{eLCdu(>~y{3}sCl<7D
zw__;g^=9PkcVr?~CA?3Q+nCHRX0V5kk&_;_xqSar3vY&pz+QNF2vjDMnnSRQ>A-cu
zf$b@OSbLO<|}R1AcJr|`CqsD8ymkfLEgs@5fQ)6?y)?{7ThjhHms9QRli57rg5-ri@$!z
zcOv$2(sSlyL}RqimYIXiI}D9ip=_RYnIC#eqPVqWlHt;t7Opqj2^iO3-qx8%Hp~&@
zu8opk|A7CrPgiU(tEI0>M(k0V3xC>(J@!f@b(ni$VE8?>eC3D36T=dPHA0~;2-^74
z2TJ?F`{=}aMJs`g9<*pA;ApK?YW=hva=CxJoU@!VWZC;uUfbjTl7N
zKV{nLxop7o^Xh}hdL)i{)98d*=Ue(=dU=H@K5zkp&#)%}S33iNVznko$CZt>-4XJv
z6z9vWPdaLsz)LNU_O%PYaylI?QT?c-^i#pNypstifUFAa&$Jqt!C-K5aiEhSofRrP(da0%FY@5n-L`H
zLghTi^(5xNSN6LP2*-pGfGi$5zB$=h~HE}C{Xuj*_
z#f`^aKkv)w&8qiFfJwg4Jp;hP)1zKdAQ(w_kRp50-p6mDJ*uEUzoUq?1fX7ki%>6k
zx7d=N!$k?3PhfWk7y`M7;3&ary*Eedg`Wj)_vJ}H*}{Cww6)9(P@Q1tgcfg={JrkJ{^W%{
zfC&N!-vAweH`wCI%5NYKMk!8pVN@b1NY=~`%%pa)19njSVlQ#G(o3yf?{)JJfL9mw
zEg7ywIs--@FsB2_0IN3BffN+Rh7@lCuItxQl{K!+pFtYM&&
zA9=RLOHd`{fx(Sn3`kZY@7;spG4q|GVpJYP3b2OD@kAQXEC&M7A<9eV1<5BTzcvaH
zCQmS*0rqAzcF{-iE4<<149>#
z?A^cLEgfR0FQW5o0~42>ElpPhufRtr*gjQj>mcjmPdHw@0)JO*D;UI)W3?Zs@4<-+
zRFD!70A8#}WCqtG)^ca@EH+r_m#wrxB-i2Ofyno&4Wt#NE&$x;Ha&6^eGvS&)qMVd
z^a~FlFC$+H-zTJ^j4?Gi6LnIL6@+Lz$B-)W$+J_8f;ji!&AxSMl
zr6}?M@jlzSGjw^7!HcFA@=JPRmMNpGdRIw2;I}9(Y;jD+0gV?B))*rOea^_oh=_>W
z7sR0V?~FrSLc`Yr7gAtgq(~lN%1h%ij~i;1itLQ>`m;C5J{-3~TEw!mp=Et6Ibr|AnL=rvf2|4;|B+dL}M8tgGv>x
za%Qw{ckdghh%VGB9Q}d;=LTnp@r!1>&8Y7rjTrN_I_F*8>%j|3Trr|h$pE2F28M

Re: [PATCH 02/20] qga: move linux vcpu command impls to commands-linux.c

2024-06-06 Thread Manos Pitsidianakis

On Tue, 04 Jun 2024 16:49, "Daniel P. Berrangé"  wrote:

The qmp_guest_set_vcpus and qmp_guest_get_vcpus command impls in
commands-posix.c are surrounded by '#ifdef __linux__' so should
instead live in commands-linux.c

Signed-off-by: Daniel P. Berrangé 
---



Reviewed-by: Manos Pitsidianakis 


qga/commands-linux.c | 141 +++
qga/commands-posix.c | 139 --
2 files changed, 141 insertions(+), 139 deletions(-)

diff --git a/qga/commands-linux.c b/qga/commands-linux.c
index 214e408fcd..78580ac39d 100644
--- a/qga/commands-linux.c
+++ b/qga/commands-linux.c
@@ -13,6 +13,7 @@

#include "qemu/osdep.h"
#include "qapi/error.h"
+#include "qga-qapi-commands.h"
#include "commands-common.h"
#include "cutils.h"
#include 
@@ -284,3 +285,143 @@ int qmp_guest_fsfreeze_do_thaw(Error **errp)
return i;
}
#endif /* CONFIG_FSFREEZE */
+
+/* Transfer online/offline status between @vcpu and the guest system.
+ *
+ * On input either @errp or *@errp must be NULL.
+ *
+ * In system-to-@vcpu direction, the following @vcpu fields are accessed:
+ * - R: vcpu->logical_id
+ * - W: vcpu->online
+ * - W: vcpu->can_offline
+ *
+ * In @vcpu-to-system direction, the following @vcpu fields are accessed:
+ * - R: vcpu->logical_id
+ * - R: vcpu->online
+ *
+ * Written members remain unmodified on error.
+ */
+static void transfer_vcpu(GuestLogicalProcessor *vcpu, bool sys2vcpu,
+  char *dirpath, Error **errp)
+{
+int fd;
+int res;
+int dirfd;
+static const char fn[] = "online";
+
+dirfd = open(dirpath, O_RDONLY | O_DIRECTORY);
+if (dirfd == -1) {
+error_setg_errno(errp, errno, "open(\"%s\")", dirpath);
+return;
+}
+
+fd = openat(dirfd, fn, sys2vcpu ? O_RDONLY : O_RDWR);
+if (fd == -1) {
+if (errno != ENOENT) {
+error_setg_errno(errp, errno, "open(\"%s/%s\")", dirpath, fn);
+} else if (sys2vcpu) {
+vcpu->online = true;
+vcpu->can_offline = false;
+} else if (!vcpu->online) {
+error_setg(errp, "logical processor #%" PRId64 " can't be "
+   "offlined", vcpu->logical_id);
+} /* otherwise pretend successful re-onlining */
+} else {
+unsigned char status;
+
+res = pread(fd, &status, 1, 0);
+if (res == -1) {
+error_setg_errno(errp, errno, "pread(\"%s/%s\")", dirpath, fn);
+} else if (res == 0) {
+error_setg(errp, "pread(\"%s/%s\"): unexpected EOF", dirpath,
+   fn);
+} else if (sys2vcpu) {
+vcpu->online = (status != '0');
+vcpu->can_offline = true;
+} else if (vcpu->online != (status != '0')) {
+status = '0' + vcpu->online;
+if (pwrite(fd, &status, 1, 0) == -1) {
+error_setg_errno(errp, errno, "pwrite(\"%s/%s\")", dirpath,
+ fn);
+}
+} /* otherwise pretend successful re-(on|off)-lining */
+
+res = close(fd);
+g_assert(res == 0);
+}
+
+res = close(dirfd);
+g_assert(res == 0);
+}
+
+GuestLogicalProcessorList *qmp_guest_get_vcpus(Error **errp)
+{
+GuestLogicalProcessorList *head, **tail;
+const char *cpu_dir = "/sys/devices/system/cpu";
+const gchar *line;
+g_autoptr(GDir) cpu_gdir = NULL;
+Error *local_err = NULL;
+
+head = NULL;
+tail = &head;
+cpu_gdir = g_dir_open(cpu_dir, 0, NULL);
+
+if (cpu_gdir == NULL) {
+error_setg_errno(errp, errno, "failed to list entries: %s", cpu_dir);
+return NULL;
+}
+
+while (local_err == NULL && (line = g_dir_read_name(cpu_gdir)) != NULL) {
+GuestLogicalProcessor *vcpu;
+int64_t id;
+if (sscanf(line, "cpu%" PRId64, &id)) {
+g_autofree char *path = g_strdup_printf("/sys/devices/system/cpu/"
+"cpu%" PRId64 "/", id);
+vcpu = g_malloc0(sizeof *vcpu);
+vcpu->logical_id = id;
+vcpu->has_can_offline = true; /* lolspeak ftw */
+transfer_vcpu(vcpu, true, path, &local_err);
+QAPI_LIST_APPEND(tail, vcpu);
+}
+}
+
+if (local_err == NULL) {
+/* there's no guest with zero VCPUs */
+g_assert(head != NULL);
+return head;
+}
+
+qapi_free_GuestLogicalProcessorList(head);
+error_propagate(errp, local_err);
+return NULL;
+}
+
+int64_t qmp_guest_set_vcpus(GuestLogicalProcessorList *vcpus, Error **errp)
+{
+int64_t processed;
+Error *local_err = NULL;
+
+processed = 0;
+while (vcpus != NULL) {
+char *path = g_strdup_printf("/sys/devices/system/cpu/cpu%" PRId64 "/",
+ vcpus->value->logical_id);
+
+transfer_vcpu(vcpus->value, false, path, &local_err);
+g_free(path);
+if (local_err != NULL) {
+break;

Re: [PATCH 03/20] qga: move linux suspend command impls to commands-linux.c

2024-06-06 Thread Manos Pitsidianakis

On Tue, 04 Jun 2024 16:49, "Daniel P. Berrangé"  wrote:

The qmp_guest_suspend_{disk,ram,hybrid} command impls in
commands-posix.c are surrounded by '#ifdef __linux__' so should
instead live in commands-linux.c

Signed-off-by: Daniel P. Berrangé 
---


Reviewed-by: Manos Pitsidianakis 



qga/commands-linux.c | 265 +++
qga/commands-posix.c | 265 ---
2 files changed, 265 insertions(+), 265 deletions(-)

diff --git a/qga/commands-linux.c b/qga/commands-linux.c
index 78580ac39d..3fabf54882 100644
--- a/qga/commands-linux.c
+++ b/qga/commands-linux.c
@@ -286,6 +286,271 @@ int qmp_guest_fsfreeze_do_thaw(Error **errp)
}
#endif /* CONFIG_FSFREEZE */

+
+#define LINUX_SYS_STATE_FILE "/sys/power/state"
+#define SUSPEND_SUPPORTED 0
+#define SUSPEND_NOT_SUPPORTED 1
+
+typedef enum {
+SUSPEND_MODE_DISK = 0,
+SUSPEND_MODE_RAM = 1,
+SUSPEND_MODE_HYBRID = 2,
+} SuspendMode;
+
+/*
+ * Executes a command in a child process using g_spawn_sync,
+ * returning an int >= 0 representing the exit status of the
+ * process.
+ *
+ * If the program wasn't found in path, returns -1.
+ *
+ * If a problem happened when creating the child process,
+ * returns -1 and errp is set.
+ */
+static int run_process_child(const char *command[], Error **errp)
+{
+int exit_status, spawn_flag;
+GError *g_err = NULL;
+bool success;
+
+spawn_flag = G_SPAWN_SEARCH_PATH | G_SPAWN_STDOUT_TO_DEV_NULL |
+ G_SPAWN_STDERR_TO_DEV_NULL;
+
+success =  g_spawn_sync(NULL, (char **)command, NULL, spawn_flag,
+NULL, NULL, NULL, NULL,
+&exit_status, &g_err);
+
+if (success) {
+return WEXITSTATUS(exit_status);
+}
+
+if (g_err && (g_err->code != G_SPAWN_ERROR_NOENT)) {
+error_setg(errp, "failed to create child process, error '%s'",
+   g_err->message);
+}
+
+g_error_free(g_err);
+return -1;
+}
+
+static bool systemd_supports_mode(SuspendMode mode, Error **errp)
+{
+const char *systemctl_args[3] = {"systemd-hibernate", "systemd-suspend",
+ "systemd-hybrid-sleep"};
+const char *cmd[4] = {"systemctl", "status", systemctl_args[mode], NULL};
+int status;
+
+status = run_process_child(cmd, errp);
+
+/*
+ * systemctl status uses LSB return codes so we can expect
+ * status > 0 and be ok. To assert if the guest has support
+ * for the selected suspend mode, status should be < 4. 4 is
+ * the code for unknown service status, the return value when
+ * the service does not exist. A common value is status = 3
+ * (program is not running).
+ */
+if (status > 0 && status < 4) {
+return true;
+}
+
+return false;
+}
+
+static void systemd_suspend(SuspendMode mode, Error **errp)
+{
+Error *local_err = NULL;
+const char *systemctl_args[3] = {"hibernate", "suspend", "hybrid-sleep"};
+const char *cmd[3] = {"systemctl", systemctl_args[mode], NULL};
+int status;
+
+status = run_process_child(cmd, &local_err);
+
+if (status == 0) {
+return;
+}
+
+if ((status == -1) && !local_err) {
+error_setg(errp, "the helper program 'systemctl %s' was not found",
+   systemctl_args[mode]);
+return;
+}
+
+if (local_err) {
+error_propagate(errp, local_err);
+} else {
+error_setg(errp, "the helper program 'systemctl %s' returned an "
+   "unexpected exit status code (%d)",
+   systemctl_args[mode], status);
+}
+}
+
+static bool pmutils_supports_mode(SuspendMode mode, Error **errp)
+{
+Error *local_err = NULL;
+const char *pmutils_args[3] = {"--hibernate", "--suspend",
+   "--suspend-hybrid"};
+const char *cmd[3] = {"pm-is-supported", pmutils_args[mode], NULL};
+int status;
+
+status = run_process_child(cmd, &local_err);
+
+if (status == SUSPEND_SUPPORTED) {
+return true;
+}
+
+if ((status == -1) && !local_err) {
+return false;
+}
+
+if (local_err) {
+error_propagate(errp, local_err);
+} else {
+error_setg(errp,
+   "the helper program '%s' returned an unexpected exit"
+   " status code (%d)", "pm-is-supported", status);
+}
+
+return false;
+}
+
+static void pmutils_suspend(SuspendMode mode, Error **errp)
+{
+Error *local_err = NULL;
+const char *pmutils_binaries[3] = {"pm-hibernate", "pm-suspend",
+   "pm-suspend-hybrid"};
+const char *cmd[2] = {pmutils_binaries[mode], NULL};
+int status;
+
+status = run_process_child(cmd, &local_err);
+
+if (status == 0) {
+return;
+}
+
+if ((status == -1) && !local_err) {
+error_setg(errp, "the helper program '%s' was not found",
+   pmutils_binaries[mode]

Re: [PATCH 04/20] qga: move linux fs/disk command impls to commands-linux.c

2024-06-06 Thread Manos Pitsidianakis

On Tue, 04 Jun 2024 16:49, "Daniel P. Berrangé"  wrote:

The qmp_guest_{fstrim, get_fsinfo, get_disks} command impls in
commands-posix.c are surrounded by '#ifdef __linux__' so should
instead live in commands-linux.c

Signed-off-by: Daniel P. Berrangé 
---



Reviewed-by: Manos Pitsidianakis 


qga/commands-linux.c | 904 ++
qga/commands-posix.c | 909 ---
2 files changed, 904 insertions(+), 909 deletions(-)

diff --git a/qga/commands-linux.c b/qga/commands-linux.c
index 3fabf54882..084e6c9e85 100644
--- a/qga/commands-linux.c
+++ b/qga/commands-linux.c
@@ -14,10 +14,21 @@
#include "qemu/osdep.h"
#include "qapi/error.h"
#include "qga-qapi-commands.h"
+#include "qapi/error.h"
+#include "qapi/qmp/qerror.h"
#include "commands-common.h"
#include "cutils.h"
#include 
#include 
+#include 
+#include 
+#include "block/nvme.h"
+
+#ifdef CONFIG_LIBUDEV
+#include 
+#endif
+
+#include 

#if defined(CONFIG_FSFREEZE) || defined(CONFIG_FSTRIM)
static int dev_major_minor(const char *devpath,
@@ -286,6 +297,899 @@ int qmp_guest_fsfreeze_do_thaw(Error **errp)
}
#endif /* CONFIG_FSFREEZE */

+#if defined(CONFIG_FSFREEZE)
+
+static char *get_pci_driver(char const *syspath, int pathlen, Error **errp)
+{
+char *path;
+char *dpath;
+char *driver = NULL;
+char buf[PATH_MAX];
+ssize_t len;
+
+path = g_strndup(syspath, pathlen);
+dpath = g_strdup_printf("%s/driver", path);
+len = readlink(dpath, buf, sizeof(buf) - 1);
+if (len != -1) {
+buf[len] = 0;
+driver = g_path_get_basename(buf);
+}
+g_free(dpath);
+g_free(path);
+return driver;
+}
+
+static int compare_uint(const void *_a, const void *_b)
+{
+unsigned int a = *(unsigned int *)_a;
+unsigned int b = *(unsigned int *)_b;
+
+return a < b ? -1 : a > b ? 1 : 0;
+}
+
+/* Walk the specified sysfs and build a sorted list of host or ata numbers */
+static int build_hosts(char const *syspath, char const *host, bool ata,
+   unsigned int *hosts, int hosts_max, Error **errp)
+{
+char *path;
+DIR *dir;
+struct dirent *entry;
+int i = 0;
+
+path = g_strndup(syspath, host - syspath);
+dir = opendir(path);
+if (!dir) {
+error_setg_errno(errp, errno, "opendir(\"%s\")", path);
+g_free(path);
+return -1;
+}
+
+while (i < hosts_max) {
+entry = readdir(dir);
+if (!entry) {
+break;
+}
+if (ata && sscanf(entry->d_name, "ata%d", hosts + i) == 1) {
+++i;
+} else if (!ata && sscanf(entry->d_name, "host%d", hosts + i) == 1) {
+++i;
+}
+}
+
+qsort(hosts, i, sizeof(hosts[0]), compare_uint);
+
+g_free(path);
+closedir(dir);
+return i;
+}
+
+/*
+ * Store disk device info for devices on the PCI bus.
+ * Returns true if information has been stored, or false for failure.
+ */
+static bool build_guest_fsinfo_for_pci_dev(char const *syspath,
+   GuestDiskAddress *disk,
+   Error **errp)
+{
+unsigned int pci[4], host, hosts[8], tgt[3];
+int i, nhosts = 0, pcilen;
+GuestPCIAddress *pciaddr = disk->pci_controller;
+bool has_ata = false, has_host = false, has_tgt = false;
+char *p, *q, *driver = NULL;
+bool ret = false;
+
+p = strstr(syspath, "/devices/pci");
+if (!p || sscanf(p + 12, "%*x:%*x/%x:%x:%x.%x%n",
+ pci, pci + 1, pci + 2, pci + 3, &pcilen) < 4) {
+g_debug("only pci device is supported: sysfs path '%s'", syspath);
+return false;
+}
+
+p += 12 + pcilen;
+while (true) {
+driver = get_pci_driver(syspath, p - syspath, errp);
+if (driver && (g_str_equal(driver, "ata_piix") ||
+   g_str_equal(driver, "sym53c8xx") ||
+   g_str_equal(driver, "virtio-pci") ||
+   g_str_equal(driver, "ahci") ||
+   g_str_equal(driver, "nvme") ||
+   g_str_equal(driver, "xhci_hcd") ||
+   g_str_equal(driver, "ehci-pci"))) {
+break;
+}
+
+g_free(driver);
+if (sscanf(p, "/%x:%x:%x.%x%n",
+  pci, pci + 1, pci + 2, pci + 3, &pcilen) == 4) {
+p += pcilen;
+continue;
+}
+
+g_debug("unsupported driver or sysfs path '%s'", syspath);
+return false;
+}
+
+p = strstr(syspath, "/target");
+if (p && sscanf(p + 7, "%*u:%*u:%*u/%*u:%u:%u:%u",
+tgt, tgt + 1, tgt + 2) == 3) {
+has_tgt = true;
+}
+
+p = strstr(syspath, "/ata");
+if (p) {
+q = p + 4;
+has_ata = true;
+} else {
+p = strstr(syspath, "/host");
+q = p + 5;
+}
+if (p && sscanf(q, "%u", &host) == 1) {
+has_host = true;
+nhosts = build_hosts(syspat

Re: [PATCH v3 0/7] hvf x86 correctness and efficiency improvements

2024-06-06 Thread Paolo Bonzini
Queued, thanks.

Thanks for persisting!  It sucks that the hv_vcpu_interrupt() API docs
are not clear, but your tests are great.  The self-interrupt one is
the case that I was most worried about, and you're covering it.
Sorry for being a pain for nothing, at least retrospectively.

Paolo




Re: linux-user emulation hangs during fork

2024-06-06 Thread Andreas Schwab
Which ruby?

$ ruby --version
ruby 3.3.1 (2024-04-23 revision c56cd86388) [x86_64-linux-gnu]

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."



Re: [PATCH v3 3/3] ui+display: rename is_buffer_shared() -> surface_is_allocated()

2024-06-06 Thread Paul Durrant

On 05/06/2024 14:14, Gerd Hoffmann wrote:

Boolean return value is reversed, to align with QEMU_ALLOCATED_FLAG, so
all callers must be adapted.  Also rename share_surface variable in
vga_draw_graphic() to reduce confusion.

No functional change.

Suggested-by: Marc-André Lureau 
Signed-off-by: Gerd Hoffmann 
---
  include/ui/surface.h|  4 ++--
  hw/display/qxl-render.c |  2 +-
  hw/display/vga.c| 20 ++--
  hw/display/xenfb.c  |  5 +++--
  ui/console.c|  3 ++-
  5 files changed, 18 insertions(+), 16 deletions(-)



Reviewed-by: Paul Durrant 




[PATCH] docs: i386: pc: Avoid mentioning limit of maximum vCPUs

2024-06-06 Thread Zhao Liu
Different versions of PC machine support different maximum vCPUs, and
even different features have limits on the maximum number of vCPUs (
For example, if x2apic is not enabled in the TCG case, the maximum of
255 vCPUs are supported).

It is difficult to list the maximum vCPUs under all restrictions. Thus,
to avoid confusion, avoid mentioning specific maximum vCPU number
limitations here.

Suggested-by: Daniel P. Berrangé 
Signed-off-by: Zhao Liu 
---
 docs/system/target-i386-desc.rst.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/system/target-i386-desc.rst.inc 
b/docs/system/target-i386-desc.rst.inc
index 319e540573d3..ae312b1c1e61 100644
--- a/docs/system/target-i386-desc.rst.inc
+++ b/docs/system/target-i386-desc.rst.inc
@@ -36,7 +36,8 @@ 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 (and 4096 CPUs for PC Q35 machine).
+SMP is supported with a large number of virtual CPUs (upper limit is
+configuration dependent).
 
 QEMU uses the PC BIOS from the Seabios project and the Plex86/Bochs LGPL
 VGA BIOS.
-- 
2.34.1




kvm crash with virtiofs

2024-06-06 Thread Miklos Szeredi
Hi,

I get the below crash when running virtio-fs on fedora 39.

Note: weirdly this makes chrome running on the host also crash.

Eric Sandeen also reported some bad behavior of virtio-fs on fc39,
which might be related.

Versions:
kernel-6.8.4-200.fc39.x86_64
qemu-kvm-8.1.3-5.fc39.x86_64
virtiofsd-1.10.1-1.fc39.x86_64

Thanks,
Miklos

/usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu --shared-dir /home &

qemu-system-x86_64 -enable-kvm -s -serial none -parallel none -kernel
/home/mszeredi/git/linux/arch/x86_64/boot/bzImage -drive
format=raw,file=/home/mszeredi/root_fs,index=0,if=virtio -drive
format=raw,file=/home/mszeredi/images/ubd1,index=1,if=virtio -chardev
stdio,id=virtiocon0,signal=off -device virtio-serial -device
virtconsole,chardev=virtiocon0 -cpu host -m 16G -smp 8 -object
memory-backend-file,id=mem,size=16G,mem-path=/dev/shm,share=on -numa
node,memdev=mem -net user -net nic,model=virtio-net-pci -fsdev
local,security_model=none,id=fsdev0,path=/home -device virtio-rng-pci
-chardev socket,id=char0,path=/tmp/vhostqemu -device
vhost-user-fs-pci,queue-size=1024,chardev=char0,tag=myfs -device
virtio-9p-pci,fsdev=fsdev0,mount_tag=hostshare -append "root=/dev/vda
console=hvc0 "
[...]
root@kvm:~# time md5sum /host/mszeredi/images/ubd1
error: kvm run failed Bad address
RAX= RBX=888100044240 RCX=
RDX=888420c59ff0
RSI=0020 RDI=888420c59ff8 RBP=
RSP=c900016d3898
R8 =888420c59da8 R9 =0040 R10=00036140
R11=0005
R12=888420c59ff0 R13=000d R14=ea0010831600
R15=888420c59da8
RIP=82168d80 RFL=00010046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   00c0
CS =0010   00a09b00 DPL=0 CS64 [-RA]
SS =0018   00c09300 DPL=0 DS   [-WA]
DS =   00c0
FS = 7fb83cea8740  00c0
GS = 88842fd4  00c0
LDT=   00c0
TR =0040 fe12a000 4087 8b00 DPL=0 TSS64-busy
GDT= fe128000 007f
IDT= fe00 0fff
CR0=80050033 CR2=7f2d3bd9b0f0 CR3=0001036ee005 CR4=00770ef0
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=0d01
Code=90 90 90 90 48 c7 07 00 00 00 00 48 89 fa 48 8d 7f 08 31 c0 <48>
c7 87 30 02 00 00 00 00 00 00 48 89 d1 48 83 e7 f8 48 29 f9 81 c1 40
02 00 00 c1 e9 03




Re: [PATCH] docs: i386: pc: Avoid mentioning limit of maximum vCPUs

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 04:54:36PM +0800, Zhao Liu wrote:
> Different versions of PC machine support different maximum vCPUs, and
> even different features have limits on the maximum number of vCPUs (
> For example, if x2apic is not enabled in the TCG case, the maximum of
> 255 vCPUs are supported).
> 
> It is difficult to list the maximum vCPUs under all restrictions. Thus,
> to avoid confusion, avoid mentioning specific maximum vCPU number
> limitations here.
> 
> Suggested-by: Daniel P. Berrangé 
> Signed-off-by: Zhao Liu 
> ---
>  docs/system/target-i386-desc.rst.inc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Reviewed-by: Daniel P. Berrangé 


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




Re: [PATCH v3 0/7] hvf x86 correctness and efficiency improvements

2024-06-06 Thread Phil Dennis-Jordan
On Thu, 6 Jun 2024 at 10:24, Paolo Bonzini  wrote:
> Queued, thanks.

Thanks - also for reviewing, etc.!

> Thanks for persisting!  It sucks that the hv_vcpu_interrupt() API docs
> are not clear, but your tests are great.  The self-interrupt one is
> the case that I was most worried about, and you're covering it.
> Sorry for being a pain for nothing, at least retrospectively.

No worries - the concern is understandable, especially in the face of
the unfortunate apparent regression which turned out to be the dirty
page tracking bug.

And I agree, the hv_vcpu_interrupt docs, along with the rest of
Hypervisor.framework's, are terrible. There does not appear to have
been any thought about what a developer using that API might care
about. I've been working on integrating the HVF APIC/PIC/IOAPIC
implementations, and there are ambiguities and edge cases galore.
Unfortunately (?), the perf improvement is worth the trouble of trial
& error…


Phil



Re: [PATCH v3 4/6] target/i386: add support for VMX FRED controls

2024-06-06 Thread Paolo Bonzini

On 11/9/23 08:20, Xin Li wrote:

Add VMX FRED controls used to enable save/load of FRED MSRs.

Tested-by: Shan Kang 
Signed-off-by: Xin Li 
---
  scripts/kvm/vmxcap | 3 +++
  target/i386/cpu.c  | 2 +-
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/kvm/vmxcap b/scripts/kvm/vmxcap
index 7da1e00ca8..44898d73c2 100755
--- a/scripts/kvm/vmxcap
+++ b/scripts/kvm/vmxcap
@@ -229,6 +229,8 @@ controls = [
  Allowed1Control(
  name = 'secondary VM-Exit controls',
  bits = {
+0: 'Save IA32 FRED MSRs',
+1: 'Load IA32 FRED MSRs',
  },
  cap_msr = MSR_IA32_VMX_EXIT_CTLS2,
  ),
@@ -246,6 +248,7 @@ controls = [
  16: 'Load IA32_BNDCFGS',
  17: 'Conceal VM entries from PT',
  18: 'Load IA32_RTIT_CTL',
+23: 'Load IA32 FRED MSRs',
  },
  cap_msr = MSR_IA32_VMX_ENTRY_CTLS,
  true_cap_msr = MSR_IA32_VMX_TRUE_ENTRY_CTLS,
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 227ee1c759..dcf914a7ec 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1285,7 +1285,7 @@ FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
  NULL, "vmx-entry-ia32e-mode", NULL, NULL,
  NULL, "vmx-entry-load-perf-global-ctrl", "vmx-entry-load-pat", 
"vmx-entry-load-efer",
  "vmx-entry-load-bndcfgs", NULL, "vmx-entry-load-rtit-ctl", NULL,
-NULL, NULL, "vmx-entry-load-pkrs", NULL,
+NULL, NULL, "vmx-entry-load-pkrs", "vmx-entry-load-fred",
  NULL, NULL, NULL, NULL,
  NULL, NULL, NULL, NULL,
  },


The bits in the secondary vmexit controls are not supported, and in 
general the same is true for the secondary vmexit case.  I think it's 
better to not include the vmx-entry-load-fred bit either, and only do 
the vmxcap changes.


Also, in patch 1 there should be a dependency from LM to FRED.

I applied these changes and queued the series, thanks.

Paolo




Re: [PATCH] docs: i386: pc: Avoid mentioning limit of maximum vCPUs

2024-06-06 Thread Paolo Bonzini
Queued, thanks.

Paolo




Re: [PATCH v2 0/6] target/i386: Misc cleanup on KVM PV defs and outdated comments

2024-06-06 Thread Zhao Liu
Hi Paolo,

Just a ping for this cleanup series.

Thanks,
Zhao

On Mon, May 06, 2024 at 04:51:47PM +0800, Zhao Liu wrote:
> Date: Mon, 6 May 2024 16:51:47 +0800
> From: Zhao Liu 
> Subject: [PATCH v2 0/6] target/i386: Misc cleanup on KVM PV defs and
>  outdated comments
> X-Mailer: git-send-email 2.34.1
> 
> Hi,
> 
> This is my v2 cleanup series. Compared with v1 [1], only tags (R/b, S/b)
> updates, and a typo fix, no code change.
> 
> This series picks cleanup from my previous kvmclock [2] (as other
> renaming attempts were temporarily put on hold).
> 
> In addition, this series also include the cleanup on a historically
> workaround and recent comment of coco interface [3].
> 
> Avoiding the fragmentation of these misc cleanups, I consolidated them
> all in one series and was able to tackle them in one go!
> 
> [1]: 
> https://lore.kernel.org/qemu-devel/20240426100716.2111688-1-zhao1@intel.com/
> [2]: 
> https://lore.kernel.org/qemu-devel/20240329101954.3954987-1-zhao1@linux.intel.com/
> [3]: 
> https://lore.kernel.org/qemu-devel/2815f0f1-9e20-4985-849c-d74c6cdc9...@intel.com/
> 
> Thanks and Best Regards,
> Zhao
> ---
> Zhao Liu (6):
>   target/i386/kvm: Add feature bit definitions for KVM CPUID
>   target/i386/kvm: Remove local MSR_KVM_WALL_CLOCK and
> MSR_KVM_SYSTEM_TIME definitions
>   target/i386/kvm: Only save/load kvmclock MSRs when kvmclock enabled
>   target/i386/kvm: Save/load MSRs of kvmclock2
> (KVM_FEATURE_CLOCKSOURCE2)
>   target/i386/kvm: Drop workaround for KVM_X86_DISABLE_EXITS_HTL typo
>   target/i386/confidential-guest: Fix comment of
> x86_confidential_guest_kvm_type()
> 
>  hw/i386/kvm/clock.c  |  5 +--
>  target/i386/confidential-guest.h |  2 +-
>  target/i386/cpu.h| 25 +
>  target/i386/kvm/kvm.c| 63 +++-
>  4 files changed, 66 insertions(+), 29 deletions(-)
> 
> -- 
> 2.34.1
> 



Re: [PATCH v5 0/3] Fix MCE handling on AMD hosts

2024-06-06 Thread Paolo Bonzini
Queued, thanks.  I added a note to the commit message in the third patch:

By the time the MCE reaches the guest, the overflow has been handled
by the host and has not caused a shutdown, so include the bit 
unconditionally.

Advertising of SUCCOR and OVERFLOW_RECOV in KVM would still be nice. :)

Paolo




Re: [PATCH v6 09/19] vfio/iommufd: Implement HostIOMMUDeviceClass::realize() handler

2024-06-06 Thread Eric Auger
Hi Zhenzhong,
On 6/3/24 08:10, Zhenzhong Duan wrote:
> It calls iommufd_backend_get_device_info() to get host IOMMU
> related information and translate it into HostIOMMUDeviceCaps
> for query with .get_cap().
>
> Introduce macro VTD_MGAW_FROM_CAP to get MGAW which equals to
> (aw_bits - 1).
>
> Signed-off-by: Zhenzhong Duan 
> ---
>  include/hw/i386/intel_iommu.h |  1 +
>  hw/vfio/iommufd.c | 37 +++
>  2 files changed, 38 insertions(+)
>
> diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
> index 7fa0a695c8..7d694b0813 100644
> --- a/include/hw/i386/intel_iommu.h
> +++ b/include/hw/i386/intel_iommu.h
> @@ -47,6 +47,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(IntelIOMMUState, 
> INTEL_IOMMU_DEVICE)
>  #define VTD_HOST_AW_48BIT   48
>  #define VTD_HOST_ADDRESS_WIDTH  VTD_HOST_AW_39BIT
>  #define VTD_HAW_MASK(aw)((1ULL << (aw)) - 1)
> +#define VTD_MGAW_FROM_CAP(cap)  ((cap >> 16) & 0x3fULL)
>  
>  #define DMAR_REPORT_F_INTR  (1)
>  
> diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
> index e4a507d55c..9d2e95e20e 100644
> --- a/hw/vfio/iommufd.c
> +++ b/hw/vfio/iommufd.c
> @@ -25,6 +25,7 @@
>  #include "qemu/cutils.h"
>  #include "qemu/chardev_open.h"
>  #include "pci.h"
> +#include "hw/i386/intel_iommu_internal.h"
>  
>  static int iommufd_cdev_map(const VFIOContainerBase *bcontainer, hwaddr iova,
>  ram_addr_t size, void *vaddr, bool readonly)
> @@ -619,6 +620,41 @@ static void vfio_iommu_iommufd_class_init(ObjectClass 
> *klass, void *data)
>  vioc->pci_hot_reset = iommufd_cdev_pci_hot_reset;
>  };
>  
> +static bool hiod_iommufd_vfio_realize(HostIOMMUDevice *hiod, void *opaque,
> +  Error **errp)
> +{
> +VFIODevice *vdev = opaque;
I think it would make sense to store vdev in hiod. This would allow to
postpone some computations in the HostIOMMUDevice ops instead of doing
everything in the realize.
For instance to retrieve the usable iova_ranges I will need to access
the base container in the associated ops.

Thanks

Eric
> +HostIOMMUDeviceCaps *caps = &hiod->caps;
> +enum iommu_hw_info_type type;
> +union {
> +struct iommu_hw_info_vtd vtd;
> +} data;
> +
> +if (!iommufd_backend_get_device_info(vdev->iommufd, vdev->devid,
> + &type, &data, sizeof(data), errp)) {
> +return false;
> +}
> +
> +caps->type = type;
> +
> +switch (type) {
> +case IOMMU_HW_INFO_TYPE_INTEL_VTD:
> +caps->aw_bits = VTD_MGAW_FROM_CAP(data.vtd.cap_reg) + 1;
> +break;
> +case IOMMU_HW_INFO_TYPE_NONE:
> +break;
> +}
> +
> +return true;
> +}
> +
> +static void hiod_iommufd_vfio_class_init(ObjectClass *oc, void *data)
> +{
> +HostIOMMUDeviceClass *hiodc = HOST_IOMMU_DEVICE_CLASS(oc);
> +
> +hiodc->realize = hiod_iommufd_vfio_realize;
> +};
> +
>  static const TypeInfo types[] = {
>  {
>  .name = TYPE_VFIO_IOMMU_IOMMUFD,
> @@ -627,6 +663,7 @@ static const TypeInfo types[] = {
>  }, {
>  .name = TYPE_HOST_IOMMU_DEVICE_IOMMUFD_VFIO,
>  .parent = TYPE_HOST_IOMMU_DEVICE_IOMMUFD,
> +.class_init = hiod_iommufd_vfio_class_init,
>  }
>  };
>  




Re: [PATCH qemu ] hw/acpi: Fix big endian host creation of Generic Port Affinity Structures

2024-06-06 Thread Jonathan Cameron via
On Wed, 5 Jun 2024 19:38:18 -0400
"Michael S. Tsirkin"  wrote:

> On Wed, Jun 05, 2024 at 07:04:55PM +0100, Jonathan Cameron wrote:
> > Treating the HID as an integer caused it to get bit reversed
> > on big endian hosts running little endian guests.  Treat it
> > as a character array instead.
> > 
> > Fixes hw/acpi: Generic Port Affinity Structure Support
> > Tested-by: Richard Henderson 
> > Signed-off-by: Jonathan Cameron 
> > 
> > ---
> > Richard ran the version posted in the thread on an s390 instance.
> > Thanks for the help!
> > 
> > Difference from version in thread:
> > - Instantiate i in the for loop.
> > 
> > Sending out now so Michael can decide whether to fold this in, or
> > drop the GP series for now from his pull request (in which case
> > I'll do an updated version with this and Markus' docs feedback
> > folded in.)  
> 
> 
> Dropped for now.
> 
> 
> > ---
> >  include/hw/acpi/acpi_generic_initiator.h | 2 +-
> >  hw/acpi/acpi_generic_initiator.c | 4 +++-
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/hw/acpi/acpi_generic_initiator.h 
> > b/include/hw/acpi/acpi_generic_initiator.h
> > index 1a899af30f..5baefda33a 100644
> > --- a/include/hw/acpi/acpi_generic_initiator.h
> > +++ b/include/hw/acpi/acpi_generic_initiator.h
> > @@ -61,7 +61,7 @@ typedef struct PCIDeviceHandle {
> >  uint16_t bdf;
> >  };
> >  struct {
> > -uint64_t hid;
> > +char hid[8];
> >  uint32_t uid;
> >  };
> >  };  
> 
> I think there is another issue:
> 
> +memcpy(&dev_handle.hid, hid, sizeof(dev_handle.hid));
> 
> not nice since there is no check that 8 will hold all of
> +const char *hid = "ACPI0016";
> and won't access buffer out of range.
> 

I think, in theory, that won't ever happen unless someone is using
an invalid ACPI ID as they 'must' be 8 chars (or a uint64_t which
would also be fine).  A bit of defensive programming seems
sensible though as there are known buggy real firmware's
that have invalid IDs so maybe one day someone will add one
of those to QEMU when we aren't paying attention.

I'll add a sanity check and treat such a value as an error.
It'll also act as documentation of the requirement.

if (strlen(hid) != sizeof(dev_handle.hid)) {
error_printf("ACPI ID for generic port is not the expected 8 characters");
exit(-1);   
}



> 
> 
> 
> > diff --git a/hw/acpi/acpi_generic_initiator.c 
> > b/hw/acpi/acpi_generic_initiator.c
> > index 78b80dcf08..f064753b67 100644
> > --- a/hw/acpi/acpi_generic_initiator.c
> > +++ b/hw/acpi/acpi_generic_initiator.c
> > @@ -151,7 +151,9 @@ build_srat_generic_node_affinity(GArray *table_data, 
> > int node,
> >  build_append_int_noprefix(table_data, 0, 12);
> >  } else {
> >  /* Device Handle - ACPI */
> > -build_append_int_noprefix(table_data, handle->hid, 8);
> > +for (int i = 0; i < sizeof(handle->hid); i++) {
> > +build_append_int_noprefix(table_data, handle->hid[i], 1);
> > +}
> >  build_append_int_noprefix(table_data, handle->uid, 4);
> >  build_append_int_noprefix(table_data, 0, 4);
> >  }
> > -- 
> > 2.39.2  
> 
> 




Re: [PATCH v6 09/19] vfio/iommufd: Implement HostIOMMUDeviceClass::realize() handler

2024-06-06 Thread Eric Auger



On 6/6/24 11:26, Eric Auger wrote:
> Hi Zhenzhong,
> On 6/3/24 08:10, Zhenzhong Duan wrote:
>> It calls iommufd_backend_get_device_info() to get host IOMMU
>> related information and translate it into HostIOMMUDeviceCaps
>> for query with .get_cap().
>>
>> Introduce macro VTD_MGAW_FROM_CAP to get MGAW which equals to
>> (aw_bits - 1).
>>
>> Signed-off-by: Zhenzhong Duan 
>> ---
>>  include/hw/i386/intel_iommu.h |  1 +
>>  hw/vfio/iommufd.c | 37 +++
>>  2 files changed, 38 insertions(+)
>>
>> diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
>> index 7fa0a695c8..7d694b0813 100644
>> --- a/include/hw/i386/intel_iommu.h
>> +++ b/include/hw/i386/intel_iommu.h
>> @@ -47,6 +47,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(IntelIOMMUState, 
>> INTEL_IOMMU_DEVICE)
>>  #define VTD_HOST_AW_48BIT   48
>>  #define VTD_HOST_ADDRESS_WIDTH  VTD_HOST_AW_39BIT
>>  #define VTD_HAW_MASK(aw)((1ULL << (aw)) - 1)
>> +#define VTD_MGAW_FROM_CAP(cap)  ((cap >> 16) & 0x3fULL)
>>  
>>  #define DMAR_REPORT_F_INTR  (1)
>>  
>> diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
>> index e4a507d55c..9d2e95e20e 100644
>> --- a/hw/vfio/iommufd.c
>> +++ b/hw/vfio/iommufd.c
>> @@ -25,6 +25,7 @@
>>  #include "qemu/cutils.h"
>>  #include "qemu/chardev_open.h"
>>  #include "pci.h"
>> +#include "hw/i386/intel_iommu_internal.h"
>>  
>>  static int iommufd_cdev_map(const VFIOContainerBase *bcontainer, hwaddr 
>> iova,
>>  ram_addr_t size, void *vaddr, bool readonly)
>> @@ -619,6 +620,41 @@ static void vfio_iommu_iommufd_class_init(ObjectClass 
>> *klass, void *data)
>>  vioc->pci_hot_reset = iommufd_cdev_pci_hot_reset;
>>  };
>>  
>> +static bool hiod_iommufd_vfio_realize(HostIOMMUDevice *hiod, void *opaque,
>> +  Error **errp)
>> +{
>> +VFIODevice *vdev = opaque;
> I think it would make sense to store vdev in hiod. This would allow to
> postpone some computations in the HostIOMMUDevice ops instead of doing
> everything in the realize.
> For instance to retrieve the usable iova_ranges I will need to access
> the base container in the associated ops.

this would need to be opaque since the agent device can be either
VFIODevice or VDPA object though

Eric
> 
> Thanks
> 
> Eric
>> +HostIOMMUDeviceCaps *caps = &hiod->caps;
>> +enum iommu_hw_info_type type;
>> +union {
>> +struct iommu_hw_info_vtd vtd;
>> +} data;
>> +
>> +if (!iommufd_backend_get_device_info(vdev->iommufd, vdev->devid,
>> + &type, &data, sizeof(data), errp)) 
>> {
>> +return false;
>> +}
>> +
>> +caps->type = type;
>> +
>> +switch (type) {
>> +case IOMMU_HW_INFO_TYPE_INTEL_VTD:
>> +caps->aw_bits = VTD_MGAW_FROM_CAP(data.vtd.cap_reg) + 1;
>> +break;
>> +case IOMMU_HW_INFO_TYPE_NONE:
>> +break;
>> +}
>> +
>> +return true;
>> +}
>> +
>> +static void hiod_iommufd_vfio_class_init(ObjectClass *oc, void *data)
>> +{
>> +HostIOMMUDeviceClass *hiodc = HOST_IOMMU_DEVICE_CLASS(oc);
>> +
>> +hiodc->realize = hiod_iommufd_vfio_realize;
>> +};
>> +
>>  static const TypeInfo types[] = {
>>  {
>>  .name = TYPE_VFIO_IOMMU_IOMMUFD,
>> @@ -627,6 +663,7 @@ static const TypeInfo types[] = {
>>  }, {
>>  .name = TYPE_HOST_IOMMU_DEVICE_IOMMUFD_VFIO,
>>  .parent = TYPE_HOST_IOMMU_DEVICE_IOMMUFD,
>> +.class_init = hiod_iommufd_vfio_class_init,
>>  }
>>  };
>>  
> 




[PATCH] machine, hostmem: improve error messages for unsupported features

2024-06-06 Thread Paolo Bonzini
Detect early unsupported MADV_MERGEABLE and MADV_DONTDUMP, and print a clearer
error message that points to the deficiency of the host.

Cc: Michal Privoznik 
Signed-off-by: Paolo Bonzini 
---
 backends/hostmem.c | 16 
 hw/core/machine.c  |  9 +
 2 files changed, 25 insertions(+)

diff --git a/backends/hostmem.c b/backends/hostmem.c
index 4d6c69fe4de..584ee160f9c 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -170,6 +170,14 @@ static void host_memory_backend_set_merge(Object *obj, 
bool value, Error **errp)
 {
 HostMemoryBackend *backend = MEMORY_BACKEND(obj);
 
+if (QEMU_MADV_MERGEABLE == QEMU_MADV_INVALID) {
+if (value) {
+error_setg(errp, "Memory merging is not supported on this host\n");
+}
+assert(!backend->merge);
+return;
+}
+
 if (!host_memory_backend_mr_inited(backend)) {
 backend->merge = value;
 return;
@@ -202,6 +210,14 @@ static void host_memory_backend_set_dump(Object *obj, bool 
value, Error **errp)
 {
 HostMemoryBackend *backend = MEMORY_BACKEND(obj);
 
+if (QEMU_MADV_DONTDUMP == QEMU_MADV_INVALID) {
+if (!value) {
+error_setg(errp, "Dumping guest memory cannot be disabled on this 
host\n");
+}
+assert(backend->dump);
+return;
+}
+
 if (!host_memory_backend_mr_inited(backend)) {
 backend->dump = value;
 return;
diff --git a/hw/core/machine.c b/hw/core/machine.c
index c31a672051c..2ac1250f575 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -17,6 +17,7 @@
 #include "hw/loader.h"
 #include "qapi/error.h"
 #include "qapi/qapi-visit-machine.h"
+#include "qemu/madvise.h"
 #include "qom/object_interfaces.h"
 #include "sysemu/cpus.h"
 #include "sysemu/sysemu.h"
@@ -427,6 +428,10 @@ static void machine_set_dump_guest_core(Object *obj, bool 
value, Error **errp)
 {
 MachineState *ms = MACHINE(obj);
 
+if (!value && QEMU_MADV_DONTDUMP == QEMU_MADV_INVALID) {
+error_setg(errp, "Dumping guest memory cannot be disabled on this 
host\n");
+return;
+}
 ms->dump_guest_core = value;
 }
 
@@ -441,6 +446,10 @@ static void machine_set_mem_merge(Object *obj, bool value, 
Error **errp)
 {
 MachineState *ms = MACHINE(obj);
 
+if (value && QEMU_MADV_MERGEABLE == QEMU_MADV_INVALID) {
+error_setg(errp, "Memory merging is not supported on this host\n");
+return;
+}
 ms->mem_merge = value;
 }
 
-- 
2.45.1




[PATCH] hostmem: simplify the code

2024-06-06 Thread Paolo Bonzini
No semantic change, just simpler control flow.

Signed-off-by: Paolo Bonzini 
---
 backends/hostmem.c | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/backends/hostmem.c b/backends/hostmem.c
index 37be93c8bb3..33baca6a974 100644
--- a/backends/hostmem.c
+++ b/backends/hostmem.c
@@ -178,12 +178,8 @@ static void host_memory_backend_set_merge(Object *obj, 
bool value, Error **errp)
 return;
 }
 
-if (!host_memory_backend_mr_inited(backend)) {
-backend->merge = value;
-return;
-}
-
-if (value != backend->merge) {
+if (!host_memory_backend_mr_inited(backend) &&
+value != backend->merge) {
 void *ptr = memory_region_get_ram_ptr(&backend->mr);
 uint64_t sz = memory_region_size(&backend->mr);
 
@@ -194,9 +190,9 @@ static void host_memory_backend_set_merge(Object *obj, bool 
value, Error **errp)
  object_get_typename(obj));
 return;
 }
-
-backend->merge = value;
 }
+
+backend->merge = value;
 }
 
 static bool host_memory_backend_get_dump(Object *obj, Error **errp)
@@ -218,12 +214,8 @@ static void host_memory_backend_set_dump(Object *obj, bool 
value, Error **errp)
 return;
 }
 
-if (!host_memory_backend_mr_inited(backend)) {
-backend->dump = value;
-return;
-}
-
-if (value != backend->dump) {
+if (host_memory_backend_mr_inited(backend) &&
+value != backend->dump) {
 void *ptr = memory_region_get_ram_ptr(&backend->mr);
 uint64_t sz = memory_region_size(&backend->mr);
 
@@ -234,9 +226,9 @@ static void host_memory_backend_set_dump(Object *obj, bool 
value, Error **errp)
  object_get_typename(obj));
 return;
 }
-
-backend->dump = value;
 }
+
+backend->dump = value;
 }
 
 static bool host_memory_backend_get_prealloc(Object *obj, Error **errp)
-- 
2.45.1




Re: [PATCH v2 1/9] tcg: Introduce INDEX_op_plugin_pc

2024-06-06 Thread Alex Bennée
Richard Henderson  writes:

> Add an opcode to find a code address within the current insn,
> for later use with unwinding.  Generate the code generically
> using tcg_reg_alloc_do_movi.
>
> Reviewed-by: Pierrick Bouvier 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



Re: [PATCH v2 2/9] accel/tcg: Set CPUState.plugin_ra before all plugin callbacks

2024-06-06 Thread Alex Bennée
Richard Henderson  writes:

> Store a host code address to use with the tcg unwinder when called
> from a plugin.  Generate one such store per guest insn that uses
> a plugin callback.
>
> Reviewed-by: Pierrick Bouvier 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



Re: [PATCH v2 3/9] accel/tcg: Return the TranslationBlock from cpu_unwind_state_data

2024-06-06 Thread Alex Bennée
Richard Henderson  writes:

> Adjust the i386 get_memio_eip function to use tb->cflags instead
> of tcg_cflags_has, which is technically more correct.
>
> Reviewed-by: Pierrick Bouvier 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



Re: [PATCH v2 4/9] plugins: Introduce TCGCPUOps callbacks for mid-tb register reads

2024-06-06 Thread Alex Bennée
Richard Henderson  writes:

> Certain target registers are not updated continuously within
> the translation block.  For normal exception handling we use
> unwind info to re-generate the correct value when required.
> Leverage that same info for reading those registers for plugins.
>
> All targets will need updating for these new callbacks.
>
> Reviewed-by: Pierrick Bouvier 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



Re: [PATCH 3/3] hw/riscv/virt-acpi-build.c: Update the HID of RISC-V UART

2024-06-06 Thread Sunil V L
Hi Igor,
On Wed, Jun 05, 2024 at 04:48:14PM +0200, Igor Mammedov wrote:
> On Tue, 28 May 2024 13:01:03 +0530
> Sunil V L  wrote:
> 
> > RISC-V is going to use new HID RSCV0003 for generi UART. So, update the
> > HID.
> 
> where does it come from?
> 
> > 
> > Signed-off-by: Sunil V L 
> > ---
> >  hw/riscv/virt-acpi-build.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/hw/riscv/virt-acpi-build.c b/hw/riscv/virt-acpi-build.c
> > index 47ec78e432..7f80368415 100644
> > --- a/hw/riscv/virt-acpi-build.c
> > +++ b/hw/riscv/virt-acpi-build.c
> > @@ -192,7 +192,7 @@ acpi_dsdt_add_uart(Aml *scope, const MemMapEntry 
> > *uart_memmap,
> >  uint32_t uart_irq)
> >  {
> >  Aml *dev = aml_device("COM0");
> > -aml_append(dev, aml_name_decl("_HID", aml_string("PNP0501")));
> > +aml_append(dev, aml_name_decl("_HID", aml_string("RSCV0003")));
> 
> the only place I've found (that could serve as justification)
>   https://github.com/riscv-non-isa/riscv-brs/blame/main/acpi.adoc
> 
> which mentions _CID and not _HID as it is in this patch
> 
Right, this is the requirement.

Yes, _CID says device is compatible. But different vendors may have
different _HID. For qemu, _CID value is used as _HID since it is not
vendor specific. This is something similar to how ARMH0011 is used (qemu
vs RPi) in ARM world.

I am checking with Andrei to see if we can relax to make it either _HID
or _CID.

Thanks,
Sunil




Re: [PATCH v2 7/9] target/i386: Implement TCGCPUOps for plugin register reads

2024-06-06 Thread Alex Bennée
Richard Henderson  writes:

> Reviewed-by: Pierrick Bouvier 
> Signed-off-by: Richard Henderson 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



[PATCH 3/4] target/i386: fix SP when taking a memory fault during POP

2024-06-06 Thread Mark Cave-Ayland
When OS/2 Warp configures its segment descriptors, many of them are configured 
with
the P flag clear to allow for a fault-on-demand implementation. In the case 
where
the stack value is POPped into the segment registers, the SP is incremented 
before
calling gen_helper_load_seg() to validate the segment descriptor:

IN:
0xffef2c0c:  66 07popl %es

OP:
 ld_i32 loc9,env,$0xfff8
 sub_i32 loc9,loc9,$0x1
 brcond_i32 loc9,$0x0,lt,$L0
 st16_i32 loc9,env,$0xfff8
 st8_i32 $0x1,env,$0xfffc

  0c0c 
 ext16u_i64 loc0,rsp
 add_i64 loc0,loc0,ss_base
 ext32u_i64 loc0,loc0
 qemu_ld_a64_i64 loc0,loc0,noat+un+leul,5
 add_i64 loc3,rsp,$0x4
 deposit_i64 rsp,rsp,loc3,$0x0,$0x10
 extrl_i64_i32 loc5,loc0
 call load_seg,$0x0,$0,env,$0x0,loc5
 add_i64 rip,rip,$0x2
 ext16u_i64 rip,rip
 exit_tb $0x0
 set_label $L0
 exit_tb $0x7fff5843

If helper_load_seg() generates a fault when validating the segment descriptor 
then as
the SP has already been incremented, the topmost word of the stack is 
overwritten by
the arguments pushed onto the stack by the CPU before taking the fault handler. 
As a
consequence things rapidly go wrong upon return from the fault handler due to 
the
corrupted stack.

Update the logic for the existing writeback condition so that a POP into the 
segment
registers also calls helper_load_seg() first before incrementing the SP, so 
that if a
fault occurs the SP remains unaltered.

Signed-off-by: Mark Cave-Ayland 
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2198
---
 target/i386/tcg/emit.c.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/tcg/emit.c.inc b/target/i386/tcg/emit.c.inc
index 2d5dc11548..f905a67380 100644
--- a/target/i386/tcg/emit.c.inc
+++ b/target/i386/tcg/emit.c.inc
@@ -2567,7 +2567,7 @@ static void gen_POP(DisasContext *s, CPUX86State *env, 
X86DecodedInsn *decode)
 X86DecodedOp *op = &decode->op[0];
 MemOp ot = gen_pop_T0(s);
 
-if (op->has_ea) {
+if (op->has_ea || op->unit == X86_OP_SEG) {
 /* NOTE: order is important for MMU exceptions */
 gen_writeback(s, decode, 0, s->T0);
 op->unit = X86_OP_SKIP;
-- 
2.39.2




[PATCH 1/4] target/i386: use local X86DecodedOp in gen_POP()

2024-06-06 Thread Mark Cave-Ayland
This will make subsequent changes a little easier to read.

Signed-off-by: Mark Cave-Ayland 
---
 target/i386/tcg/emit.c.inc | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/i386/tcg/emit.c.inc b/target/i386/tcg/emit.c.inc
index e990141454..a89f8e0ebb 100644
--- a/target/i386/tcg/emit.c.inc
+++ b/target/i386/tcg/emit.c.inc
@@ -2564,11 +2564,13 @@ static void gen_PMOVMSKB(DisasContext *s, CPUX86State 
*env, X86DecodedInsn *deco
 
 static void gen_POP(DisasContext *s, CPUX86State *env, X86DecodedInsn *decode)
 {
+X86DecodedOp *op = &decode->op[0];
 MemOp ot = gen_pop_T0(s);
-if (decode->op[0].has_ea) {
+
+if (op->has_ea) {
 /* NOTE: order is important for MMU exceptions */
 gen_op_st_v(s, ot, s->T0, s->A0);
-decode->op[0].unit = X86_OP_SKIP;
+op->unit = X86_OP_SKIP;
 }
 /* NOTE: writing back registers after update is important for pop %sp */
 gen_pop_update(s, ot);
-- 
2.39.2




[PATCH 4/4] target/i386: fix size of EBP writeback in gen_enter()

2024-06-06 Thread Mark Cave-Ayland
The calculation of FrameTemp is done using the size indicated by mo_pushpop()
before being written back to EBP, but the final writeback to EBP is done using
the size indicated by mo_stacksize().

In the case where mo_pushpop() is MO_32 and mo_stacksize() is MO_16 then the
final writeback to EBP is done using MO_16 which can leave junk in the top
16-bits of EBP after executing ENTER.

Change the writeback of EBP to use the same size indicated by mo_pushpop() to
ensure that the full value is written back.

Signed-off-by: Mark Cave-Ayland 
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2198
---
 target/i386/tcg/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index 0486ab6911..0716ca35d5 100644
--- a/target/i386/tcg/translate.c
+++ b/target/i386/tcg/translate.c
@@ -2125,7 +2125,7 @@ static void gen_enter(DisasContext *s, int esp_addend, 
int level)
 }
 
 /* Copy the FrameTemp value to EBP.  */
-gen_op_mov_reg_v(s, a_ot, R_EBP, s->T1);
+gen_op_mov_reg_v(s, d_ot, R_EBP, s->T1);
 
 /* Compute the final value of ESP.  */
 tcg_gen_subi_tl(s->T1, s->T1, esp_addend + size * level);
-- 
2.39.2




[PATCH 2/4] target/i386: use gen_writeback() within gen_POP()

2024-06-06 Thread Mark Cave-Ayland
Instead of directly implementing the writeback using gen_op_st_v(), use the
existing gen_writeback() function.

Suggested-by: Paolo Bonzini 
Signed-off-by: Mark Cave-Ayland 
---
 target/i386/tcg/emit.c.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/tcg/emit.c.inc b/target/i386/tcg/emit.c.inc
index a89f8e0ebb..2d5dc11548 100644
--- a/target/i386/tcg/emit.c.inc
+++ b/target/i386/tcg/emit.c.inc
@@ -2569,7 +2569,7 @@ static void gen_POP(DisasContext *s, CPUX86State *env, 
X86DecodedInsn *decode)
 
 if (op->has_ea) {
 /* NOTE: order is important for MMU exceptions */
-gen_op_st_v(s, ot, s->T0, s->A0);
+gen_writeback(s, decode, 0, s->T0);
 op->unit = X86_OP_SKIP;
 }
 /* NOTE: writing back registers after update is important for pop %sp */
-- 
2.39.2




[PATCH 0/4] target/i386: fixes for OS/2 Warp

2024-06-06 Thread Mark Cave-Ayland
This series contains two fixes which allow booting OS/2 Warp in QEMU with TCG
(currently it only boots with KVM).

Patches 1 and 2 are tidy-ups which prepare for the POP SP fix in patch 3, whilst
patch 4 is the final fix for ENTER that allows my test image to boot
successfully.

Signed-off-by: Mark Cave-Ayland 


Mark Cave-Ayland (4):
  target/i386: use local X86DecodedOp in gen_POP()
  target/i386: use gen_writeback() within gen_POP()
  target/i386: fix SP when taking a memory fault during POP
  target/i386: fix size of EBP writeback in gen_enter()

 target/i386/tcg/emit.c.inc  | 8 +---
 target/i386/tcg/translate.c | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.39.2




Re: [PATCH] hostmem: simplify the code

2024-06-06 Thread Philippe Mathieu-Daudé

On 6/6/24 11:37, Paolo Bonzini wrote:

No semantic change, just simpler control flow.

Signed-off-by: Paolo Bonzini 
---
  backends/hostmem.c | 24 
  1 file changed, 8 insertions(+), 16 deletions(-)


Reviewed-by: Philippe Mathieu-Daudé 




Re: Unexpected error in rme_configure_one() at ../target/arm/kvm-rme.c:159

2024-06-06 Thread Gavin Shan



On 6/6/24 15:05, Gavin Shan wrote:

Even the edk2 for the guest can be built successfully, but I'm not able to try 
it
because I'm unable to bring up the host now. I tried to rebuild the environment
from scratch, the host runs into crash inside EDK2 unfortunately...

   TF-RMM:   https://git.codelinaro.org/linaro/dcap/rmm.git 
  (branch: cca/v2)
   EDK2: g...@github.com:tianocore/edk2.git 
   (tag:    edk2-stable202402)
   TF-A: https://git.codelinaro.org/linaro/dcap/tf-a/trusted-firmware-a.git 
  (branch: cca/v2)
   QEMU: https://git.qemu.org/git/qemu.git  
  (branch: master)
   KERNEL:   https://git.gitlab.arm.com/linux-arm/linux-cca.git 
  (branch: cca-full/v2)
   BuildRoot: 

arm64-server# home/gavin/sandbox/qemu.main/build/qemu-system-aarch64  \
   -M virt,virtualization=on,secure=on,gic-version=3,acpi=off  \
   -cpu max,x-rme=on -m 8G -smp 8  \
   -monitor none -serial mon:stdio -nographic -nodefaults  \
   -bios /home/gavin/sandbox/CCA/tf-a/flash.bin    \
   -kernel /home/gavin/sandbox/CCA/linux/arch/arm64/boot/Image \
   -append console=ttyAMA0 root=/dev/vda   \
   -drive 
format=raw,if=none,file=/home/gavin/sandbox/CCA/buildroot/output/images/rootfs.ext4,id=hd0
 \
   -device virtio-blk-pci,drive=hd0    \
   -netdev 
tap,id=tap0,vhost=false,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
   -device virtio-net-pci,netdev=tap0,mac=52:54:00:f1:26:b0 
 \
   -fsdev 
local,security_model=none,path=/home/gavin/sandbox/CCA,id=shr0 \
   -device virtio-9p-device,fsdev=shr0,mount_tag=shr0
  :
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.10.0(debug):99e0b97aa-dirty
NOTICE:  BL1: Built : 23:14:56, Jun  5 2024
INFO:    BL1: RAM 0xe0ee000 - 0xe0f7000
INFO:    BL1: Loading BL2
INFO:    Loading image id=1 at address 0xe06b000
INFO:    Image id=1 loaded: 0xe06b000 - 0xe0742d1
NOTICE:  BL1: Booting BL2
INFO:    Entry point address = 0xe06b000
INFO:    SPSR = 0x3cd
INFO:    [GPT] Boot Configuration
INFO:  PPS/T: 0x2/40
INFO:  PGS/P: 0x0/12
INFO:  L0GPTSZ/S: 0x0/30
INFO:  PAS count: 0x6
INFO:  L0 base:   0xedfe000
INFO:    [GPT] PAS[0]: base 0xe001000, size 0xff000, GPI 0xa, type 0x1
INFO:    [GPT] PAS[1]: base 0xe10, size 0xcfe000, GPI 0x8, type 0x1
INFO:    [GPT] PAS[2]: base 0xedfe000, size 0x202000, GPI 0xa, type 0x1
INFO:    [GPT] PAS[3]: base 0x4000, size 0x10, GPI 0x9, type 0x1
INFO:    [GPT] PAS[4]: base 0x4010, size 0x280, GPI 0xb, type 0x1
INFO:    [GPT] PAS[5]: base 0x4290, size 0x1fd70, GPI 0x9, type 0x1
INFO:    Enabling Granule Protection Checks
NOTICE:  BL2: v2.10.0(debug):99e0b97aa-dirty
NOTICE:  BL2: Built : 23:14:56, Jun  5 2024
INFO:    BL2: Doing platform setup
INFO:    Reserved RMM memory [0x4010, 0x428f] in Device tree
INFO:    BL2: Loading image id 3
INFO:    Loading image id=3 at address 0xe0a
INFO:    Image id=3 loaded: 0xe0a - 0xe0b10c4
INFO:    BL2: Loading image id 35
INFO:    Loading image id=35 at address 0x4010
INFO:    Image id=35 loaded: 0x4010 - 0x403033b0
INFO:    BL2: Loading image id 5
INFO:    Loading image id=5 at address 0x6000
INFO:    Image id=5 loaded: 0x6000 - 0x6020
NOTICE:  BL2: Booting BL31
INFO:    Entry point address = 0xe0a
INFO:    SPSR = 0x3cd
NOTICE:  BL31: v2.10.0(debug):99e0b97aa-dirty
NOTICE:  BL31: Built : 23:14:56, Jun  5 2024
INFO:    GICv3 without legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    Maximum SPI INTID supported: 287
INFO:    BL31: Initializing runtime services
INFO:    RMM setup done.
INFO:    BL31: Initializing RMM
INFO:    RMM init start.
Booting RMM v.0.4.0(debug) 17924bc Built with GCC 11.4.1
RMM-EL3 Interface v.0.2
Boot Manifest Interface v.0.3
RMI/RSI ABI v.1.0/1.0 built: Jun  5 2024 23:03:00
INFO:    RMM init end.
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x6000
INFO:    SPSR = 0x3c9
Loading driver at 0x00060009160 EntryPoint=0x000
ArmVirtGetMemoryMap: Dumping System DRAM Memory Map:
 PhysicalBase: 0x4000
 VirtualBase: 0x4000
 Length: 0x2
UEFI firmware (version  built at 23:28:51 on Jun  5 2024)
PlatformPeim: PL011 UART (console) @ 0x900
PlatformPeim: PL011 UART (debug) @ 0x900
   :
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable
SetMemoryAttributes: BaseAddress == 0x22DC0, Length == 0x1CE, 
Attributes == 0x2
SetMemoryAttributes: BaseAddress == 0x22F8E, Length == 0xE5, Attributes 
== 0x4000
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services...
EFI stub: 

RE: [PATCH v6 09/19] vfio/iommufd: Implement HostIOMMUDeviceClass::realize() handler

2024-06-06 Thread Duan, Zhenzhong
Hi Eric,

>-Original Message-
>From: Eric Auger 
>Subject: Re: [PATCH v6 09/19] vfio/iommufd: Implement
>HostIOMMUDeviceClass::realize() handler
>
>
>
>On 6/6/24 11:26, Eric Auger wrote:
>> Hi Zhenzhong,
>> On 6/3/24 08:10, Zhenzhong Duan wrote:
>>> It calls iommufd_backend_get_device_info() to get host IOMMU
>>> related information and translate it into HostIOMMUDeviceCaps
>>> for query with .get_cap().
>>>
>>> Introduce macro VTD_MGAW_FROM_CAP to get MGAW which equals to
>>> (aw_bits - 1).
>>>
>>> Signed-off-by: Zhenzhong Duan 
>>> ---
>>>  include/hw/i386/intel_iommu.h |  1 +
>>>  hw/vfio/iommufd.c | 37
>+++
>>>  2 files changed, 38 insertions(+)
>>>
>>> diff --git a/include/hw/i386/intel_iommu.h
>b/include/hw/i386/intel_iommu.h
>>> index 7fa0a695c8..7d694b0813 100644
>>> --- a/include/hw/i386/intel_iommu.h
>>> +++ b/include/hw/i386/intel_iommu.h
>>> @@ -47,6 +47,7 @@ OBJECT_DECLARE_SIMPLE_TYPE(IntelIOMMUState,
>INTEL_IOMMU_DEVICE)
>>>  #define VTD_HOST_AW_48BIT   48
>>>  #define VTD_HOST_ADDRESS_WIDTH  VTD_HOST_AW_39BIT
>>>  #define VTD_HAW_MASK(aw)((1ULL << (aw)) - 1)
>>> +#define VTD_MGAW_FROM_CAP(cap)  ((cap >> 16) & 0x3fULL)
>>>
>>>  #define DMAR_REPORT_F_INTR  (1)
>>>
>>> diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
>>> index e4a507d55c..9d2e95e20e 100644
>>> --- a/hw/vfio/iommufd.c
>>> +++ b/hw/vfio/iommufd.c
>>> @@ -25,6 +25,7 @@
>>>  #include "qemu/cutils.h"
>>>  #include "qemu/chardev_open.h"
>>>  #include "pci.h"
>>> +#include "hw/i386/intel_iommu_internal.h"
>>>
>>>  static int iommufd_cdev_map(const VFIOContainerBase *bcontainer,
>hwaddr iova,
>>>  ram_addr_t size, void *vaddr, bool readonly)
>>> @@ -619,6 +620,41 @@ static void
>vfio_iommu_iommufd_class_init(ObjectClass *klass, void *data)
>>>  vioc->pci_hot_reset = iommufd_cdev_pci_hot_reset;
>>>  };
>>>
>>> +static bool hiod_iommufd_vfio_realize(HostIOMMUDevice *hiod, void
>*opaque,
>>> +  Error **errp)
>>> +{
>>> +VFIODevice *vdev = opaque;
>> I think it would make sense to store vdev in hiod. This would allow to
>> postpone some computations in the HostIOMMUDevice ops instead of
>doing
>> everything in the realize.
>> For instance to retrieve the usable iova_ranges I will need to access
>> the base container in the associated ops.
>
>this would need to be opaque since the agent device can be either
>VFIODevice or VDPA object though

This will give vIOMMU access to all VFIODevice or VDPA object elements
and I'm not sure if VDPA supports iova_ranges.
What about exposing only what we need, like below.
If VDPA doesn't support iova_ranges, get_cap() should return 0.

--- a/include/sysemu/host_iommu_device.h
+++ b/include/sysemu/host_iommu_device.h
@@ -32,6 +32,7 @@ typedef struct HostIOMMUDeviceCaps {
 bool nesting;
 bool fs1gp;
 uint32_t errata;
+GList *iova_ranges;
 } HostIOMMUDeviceCaps;

 #define TYPE_HOST_IOMMU_DEVICE "host-iommu-device"
@@ -96,6 +97,7 @@ struct HostIOMMUDeviceClass {
 #define HOST_IOMMU_DEVICE_CAP_NESTING   2
 #define HOST_IOMMU_DEVICE_CAP_FS1GP 3
 #define HOST_IOMMU_DEVICE_CAP_ERRATA4
+#define HOST_IOMMU_DEVICE_CAP_IOVA_RANGES   5

 /**
  * enum host_iommu_device_iommu_hw_info_type - IOMMU Hardware Info Types
diff --git a/hw/vfio/container.c b/hw/vfio/container.c
index 26e6f7fb4f..4c3e9e45c3 100644
--- a/hw/vfio/container.c
+++ b/hw/vfio/container.c
@@ -1145,6 +1145,7 @@ static bool hiod_legacy_vfio_realize(HostIOMMUDevice 
*hiod, void *opaque,

 hiod->name = g_strdup(vdev->name);
 hiod->caps.aw_bits = vfio_device_get_aw_bits(vdev);
+hiod->caps.iova_ranges = vdev->bcontainer->iova_ranges;

 return true;
 }
@@ -1157,6 +1158,8 @@ static int hiod_legacy_vfio_get_cap(HostIOMMUDevice 
*hiod, int cap,
 switch (cap) {
 case HOST_IOMMU_DEVICE_CAP_AW_BITS:
 return caps->aw_bits;
+case HOST_IOMMU_DEVICE_CAP_IOVA_RANGES:
+return 1;
 default:
 error_setg(errp, "%s: unsupported capability %x", hiod->name, cap);
 return -EINVAL;

Thanks
Zhenzhong


Re: [PATCH v2 4/9] plugins: Introduce TCGCPUOps callbacks for mid-tb register reads

2024-06-06 Thread Alex Bennée
Alex Bennée  writes:

> Richard Henderson  writes:
>
>> Certain target registers are not updated continuously within
>> the translation block.  For normal exception handling we use
>> unwind info to re-generate the correct value when required.
>> Leverage that same info for reading those registers for plugins.
>>
>> All targets will need updating for these new callbacks.
>>
>> Reviewed-by: Pierrick Bouvier 
>> Signed-off-by: Richard Henderson 
>
> Reviewed-by: Alex Bennée 

I'll note there is a minor merge conflict coming against:

  plugins: Ensure register handles are not NULL

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



[PATCH v11 1/2] virtio-pci: only reset pm state during resetting

2024-06-06 Thread Jiqian Chen
Fix bug imported by 27ce0f3afc9dd ("fix Power Management Control Register for 
PCI Express virtio devices"
After this change, observe that QEMU may erroneously clear the power status of 
the device,
or may erroneously clear non writable registers, such as NO_SOFT_RESET, etc.

Only state of PM_CTRL is writable.
Only when flag VIRTIO_PCI_FLAG_INIT_PM is set, need to reset state.

Fixes: 27ce0f3afc9dd ("fix Power Management Control Register for PCI Express 
virtio devices"

Signed-off-by: Jiqian Chen 
---
 hw/virtio/virtio-pci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index b1d02f4b3de0..1b63bcb3f15c 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -2300,10 +2300,16 @@ static void virtio_pci_bus_reset_hold(Object *obj, 
ResetType type)
 virtio_pci_reset(qdev);
 
 if (pci_is_express(dev)) {
+VirtIOPCIProxy *proxy = VIRTIO_PCI(dev);
+
 pcie_cap_deverr_reset(dev);
 pcie_cap_lnkctl_reset(dev);
 
-pci_set_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL, 0);
+if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
+pci_word_test_and_clear_mask(
+dev->config + dev->exp.pm_cap + PCI_PM_CTRL,
+PCI_PM_CTRL_STATE_MASK);
+}
 }
 }
 
-- 
2.34.1




[PATCH] tracetool: Remove unused vcpu.py script

2024-06-06 Thread Philippe Mathieu-Daudé
vcpu.py is pointless since commit 89aafcf2a7 ("trace:
remove code that depends on setting vcpu"), remote it.

Signed-off-by: Philippe Mathieu-Daudé 
---
 meson.build   |  1 -
 scripts/tracetool/__init__.py |  8 +
 scripts/tracetool/vcpu.py | 59 ---
 3 files changed, 1 insertion(+), 67 deletions(-)
 delete mode 100644 scripts/tracetool/vcpu.py

diff --git a/meson.build b/meson.build
index d80203f1cd..0c45c948d0 100644
--- a/meson.build
+++ b/meson.build
@@ -3226,7 +3226,6 @@ tracetool_depends = files(
   'scripts/tracetool/format/log_stap.py',
   'scripts/tracetool/format/stap.py',
   'scripts/tracetool/__init__.py',
-  'scripts/tracetool/vcpu.py'
 )
 
 qemu_version_cmd = [find_program('scripts/qemu-version.sh'),
diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index b887540a55..7237abe0e8 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -306,13 +306,7 @@ def build(line_str, lineno, filename):
 fmt = [fmt_trans, fmt]
 args = Arguments.build(groups["args"])
 
-event = Event(name, props, fmt, args, lineno, filename)
-
-# add implicit arguments when using the 'vcpu' property
-import tracetool.vcpu
-event = tracetool.vcpu.transform_event(event)
-
-return event
+return Event(name, props, fmt, args, lineno, filename)
 
 def __repr__(self):
 """Evaluable string representation for this object."""
diff --git a/scripts/tracetool/vcpu.py b/scripts/tracetool/vcpu.py
deleted file mode 100644
index d232cb1d06..00
--- a/scripts/tracetool/vcpu.py
+++ /dev/null
@@ -1,59 +0,0 @@
-# -*- coding: utf-8 -*-
-
-"""
-Generic management for the 'vcpu' property.
-
-"""
-
-__author__ = "Lluís Vilanova "
-__copyright__  = "Copyright 2016, Lluís Vilanova "
-__license__= "GPL version 2 or (at your option) any later version"
-
-__maintainer__ = "Stefan Hajnoczi"
-__email__  = "stefa...@redhat.com"
-
-
-from tracetool import Arguments, try_import
-
-
-def transform_event(event):
-"""Transform event to comply with the 'vcpu' property (if present)."""
-if "vcpu" in event.properties:
-event.args = Arguments([("void *", "__cpu"), event.args])
-fmt = "\"cpu=%p \""
-event.fmt = fmt + event.fmt
-return event
-
-
-def transform_args(format, event, *args, **kwargs):
-"""Transforms the arguments to suit the specified format.
-
-The format module must implement function 'vcpu_args', which receives the
-implicit arguments added by the 'vcpu' property, and must return suitable
-arguments for the given format.
-
-The function is only called for events with the 'vcpu' property.
-
-Parameters
-==
-format : str
-Format module name.
-event : Event
-args, kwargs
-Passed to 'vcpu_transform_args'.
-
-Returns
-===
-Arguments
-The transformed arguments, including the non-implicit ones.
-
-"""
-if "vcpu" in event.properties:
-ok, func = try_import("tracetool.format." + format,
-  "vcpu_transform_args")
-assert ok
-assert func
-return Arguments([func(event.args[:1], *args, **kwargs),
-  event.args[1:]])
-else:
-return event.args
-- 
2.41.0




[PATCH v11 0/2] S3 support

2024-06-06 Thread Jiqian Chen
Hi all,
This is the v11 patch to support S3.
v11 makes below changes:
* patch#1 no changes.
* patch#2 add "x-" prefix to pcie-pm-no-soft-reset and add old machine 
compability.


Best regards,
Jiqian Chen



v10 makes below changes:
* patch#1 change the description of commit message.
* patch#2 no changes.


v9 makes below changes:
* patch#1 no changes
* patch#2 remove unnecessary parentheses.
  add some comments to remind we may need to consider SUSPEND bit in 
future.
  change the commit message to describe which virtio device was tested.
  keep No_Soft_Reset bit false by default for safety.


v8 makes below changes:
* Add a new patch#1 to fix a problem import by 
27ce0f3afc9dd25d21b43bbce505157afd93d111,
  the right action is that only the state of PM_CTRL can be clear when 
resetting.
* patch#2 is the original patch to implement No_Soft_Reset bit, and in this 
version, I
  rename function and change some condition sequence.


v7 makes below changes:
* Tested this patch with Qemu on Xen hypervisor. Depending on kernel
  patch (virtio: Add support for no-reset virtio PCI PM:
  https://lore.kernel.org/lkml/20231208070754.3132339-1-steve...@chromium.org/)
* Changed the default value of flag VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT to 
false
* Fixed coding style violation
* Modified the content of the comments.
* Removed useless flag PCI_PM_CTRL_DATA_SCALE_MASK.


V6:
In current code, when guest does S3, virtio devices are reset during that 
process, that
causes the display resources of virtio-gpu are destroyed, then the display 
can't come
back after resuming.
This v6 patch implement the No_Soft_Reset bit of PCI_PM_CTRL register, when 
this bit is
set, the resetting will not be done, so that the display can work after 
resuming.
This version abandons all previous version implementations and is a new 
different
solution according to the outcome of the discussion and suggestions in the 
mailing
thread of virtio-spec.
(https://lists.oasis-open.org/archives/virtio-comment/202401/msg00077.html)


V5:
v5 makes below changes:
* Since this series patches add a new mechanism that let virtgpu and Qemu can 
negotiate
  their reset behavior, and other guys hope me can improve this mechanism to 
virtio pci
  level, so that other virtio devices can also benefit from it. So instead of 
adding
  new feature flag VIRTIO_GPU_F_FREEZE_S3 only serves for virtgpu, v5 add a new 
parameter
  named freeze_mode to struct VirtIODevice, when guest begin suspending, set 
freeze_mode
  to VIRTIO_PCI_FREEZE_MODE_FREEZE_S3, and then all virtio devices can get this 
status,
  and notice that guest is suspending, then they can change their reset 
behavior . See
  the new commit "virtio-pci: Add freeze_mode case for virtio pci"
* The second commit is just for virtgpu, when freeze_mode is 
VIRTIO_PCI_FREEZE_MODE_FREEZE_S3,
  prevent Qemu destroying render resources, so that the display can come back 
after resuming.
V5 of kernel patch:
https://lore.kernel.org/lkml/20230919104607.2282248-1-jiqian.c...@amd.com/T/#t
The link to trace this issue:
https://gitlab.com/qemu-project/qemu/-/issues/1860


v4:
Thanks for Gerd Hoffmann's advice. V4 makes below changes:
* Use enum for freeze mode, so this can be extended with more
  modes in the future.
* Rename functions and paratemers with "_S3" postfix.
And no functional changes.
Link:
https://lore.kernel.org/qemu-devel/20230720120816.8751-1-jiqian.c...@amd.com/
No v4 patch on kernel side.


v3:
Thanks for Michael S. Tsirkin's advice. V3 makes below changes:
* Remove changes in file include/standard-headers/linux/virtio_gpu.h
  I am not supposed to edit this file and it will be imported after
  the patches of linux kernel was merged.
Link:
https://lore.kernel.org/qemu-devel/20230719074726.1613088-1-jiqian.c...@amd.com/T/#t
V3 of kernel patch:
https://lore.kernel.org/lkml/20230720115805.8206-1-jiqian.c...@amd.com/T/#t


v2:
makes below changes:
* Change VIRTIO_CPU_CMD_STATUS_FREEZING to 0x0400 (<0x1000)
* Add virtio_gpu_device_unrealize to destroy resources to solve
  potential memory leak problem. This also needs hot-plug support.
* Add a new feature flag VIRTIO_GPU_F_FREEZING, so that guest and
  host can negotiate whenever freezing is supported or not.
Link:
https://lore.kernel.org/qemu-devel/20230630070016.841459-1-jiqian.c...@amd.com/T/#t
V2 of kernel patch:
https://lore.kernel.org/lkml/20230630073448.842767-1-jiqian.c...@amd.com/T/#t


v1:
Hi all,
I am working to implement virtgpu S3 function on Xen.

Currently on Xen, if we start a guest who enables virtgpu, and then run
"echo mem > /sys/power/state" to suspend guest. And run "sudo xl trigger  s3resume"
to resume guest. We can find that the guest kernel comes back, but the display 
doesn't.
It just shown a black screen.

Through reading codes, I founded that when guest was during suspending, it 
called into Qemu
to call virtio_gpu_gl_reset. In virtio_gpu_gl_reset, it destroyed all resources 
and reset
renderer. This ma

[PATCH v11 2/2] virtio-pci: implement No_Soft_Reset bit

2024-06-06 Thread Jiqian Chen
In current code, when guest does S3, virtio-gpu are reset due to the
bit No_Soft_Reset is not set. After resetting, the display resources
of virtio-gpu are destroyed, then the display can't come back and only
show blank after resuming.

Implement No_Soft_Reset bit of PCI_PM_CTRL register, then guest can check
this bit, if this bit is set, the devices resetting will not be done, and
then the display can work after resuming.

No_Soft_Reset bit is implemented for all virtio devices, and was tested
only on virtio-gpu device. Set it false by default for safety.

Signed-off-by: Jiqian Chen 
---
 hw/core/machine.c  |  1 +
 hw/virtio/virtio-pci.c | 29 +
 include/hw/virtio/virtio-pci.h |  5 +
 3 files changed, 35 insertions(+)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 77a356f232f5..b6af94edcd0a 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -36,6 +36,7 @@
 GlobalProperty hw_compat_9_0[] = {
 {"arm-cpu", "backcompat-cntfrq", "true" },
 {"vfio-pci", "skip-vsc-check", "false" },
+{ "virtio-pci", "x-pcie-pm-no-soft-reset", "off" },
 };
 const size_t hw_compat_9_0_len = G_N_ELEMENTS(hw_compat_9_0);
 
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 1b63bcb3f15c..c881f853253c 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -2230,6 +2230,11 @@ static void virtio_pci_realize(PCIDevice *pci_dev, Error 
**errp)
 pcie_cap_lnkctl_init(pci_dev);
 }
 
+if (proxy->flags & VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET) {
+pci_set_word(pci_dev->config + pos + PCI_PM_CTRL,
+ PCI_PM_CTRL_NO_SOFT_RESET);
+}
+
 if (proxy->flags & VIRTIO_PCI_FLAG_INIT_PM) {
 /* Init Power Management Control Register */
 pci_set_word(pci_dev->wmask + pos + PCI_PM_CTRL,
@@ -2292,11 +2297,33 @@ static void virtio_pci_reset(DeviceState *qdev)
 }
 }
 
+static bool virtio_pci_no_soft_reset(PCIDevice *dev)
+{
+uint16_t pmcsr;
+
+if (!pci_is_express(dev) || !dev->exp.pm_cap) {
+return false;
+}
+
+pmcsr = pci_get_word(dev->config + dev->exp.pm_cap + PCI_PM_CTRL);
+
+/*
+ * When No_Soft_Reset bit is set and the device
+ * is in D3hot state, don't reset device
+ */
+return (pmcsr & PCI_PM_CTRL_NO_SOFT_RESET) &&
+   (pmcsr & PCI_PM_CTRL_STATE_MASK) == 3;
+}
+
 static void virtio_pci_bus_reset_hold(Object *obj, ResetType type)
 {
 PCIDevice *dev = PCI_DEVICE(obj);
 DeviceState *qdev = DEVICE(obj);
 
+if (virtio_pci_no_soft_reset(dev)) {
+return;
+}
+
 virtio_pci_reset(qdev);
 
 if (pci_is_express(dev)) {
@@ -2336,6 +2363,8 @@ static Property virtio_pci_properties[] = {
 VIRTIO_PCI_FLAG_INIT_LNKCTL_BIT, true),
 DEFINE_PROP_BIT("x-pcie-pm-init", VirtIOPCIProxy, flags,
 VIRTIO_PCI_FLAG_INIT_PM_BIT, true),
+DEFINE_PROP_BIT("x-pcie-pm-no-soft-reset", VirtIOPCIProxy, flags,
+VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT, false),
 DEFINE_PROP_BIT("x-pcie-flr-init", VirtIOPCIProxy, flags,
 VIRTIO_PCI_FLAG_INIT_FLR_BIT, true),
 DEFINE_PROP_BIT("aer", VirtIOPCIProxy, flags,
diff --git a/include/hw/virtio/virtio-pci.h b/include/hw/virtio/virtio-pci.h
index 59d88018c16a..9e67ba38c748 100644
--- a/include/hw/virtio/virtio-pci.h
+++ b/include/hw/virtio/virtio-pci.h
@@ -43,6 +43,7 @@ enum {
 VIRTIO_PCI_FLAG_INIT_FLR_BIT,
 VIRTIO_PCI_FLAG_AER_BIT,
 VIRTIO_PCI_FLAG_ATS_PAGE_ALIGNED_BIT,
+VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT,
 };
 
 /* Need to activate work-arounds for buggy guests at vmstate load. */
@@ -79,6 +80,10 @@ enum {
 /* Init Power Management */
 #define VIRTIO_PCI_FLAG_INIT_PM (1 << VIRTIO_PCI_FLAG_INIT_PM_BIT)
 
+/* Init The No_Soft_Reset bit of Power Management */
+#define VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET \
+  (1 << VIRTIO_PCI_FLAG_PM_NO_SOFT_RESET_BIT)
+
 /* Init Function Level Reset capability */
 #define VIRTIO_PCI_FLAG_INIT_FLR (1 << VIRTIO_PCI_FLAG_INIT_FLR_BIT)
 
-- 
2.34.1




[PATCH] target/s390x: Fix tracing header path in TCG mem_helper.c

2024-06-06 Thread Philippe Mathieu-Daudé
Commit c9274b6bf0 ("target/s390x: start moving TCG-only code
to tcg/") moved mem_helper.c, but the trace-events file is
still in the parent directory, so is the generated trace.h.

Signed-off-by: Philippe Mathieu-Daudé 
---
Ideally we should only use trace events from current directory.
---
 target/s390x/tcg/mem_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/s390x/tcg/mem_helper.c b/target/s390x/tcg/mem_helper.c
index 6a308c5553..1fb6cbb6cf 100644
--- a/target/s390x/tcg/mem_helper.c
+++ b/target/s390x/tcg/mem_helper.c
@@ -30,7 +30,7 @@
 #include "hw/core/tcg-cpu-ops.h"
 #include "qemu/int128.h"
 #include "qemu/atomic128.h"
-#include "trace.h"
+#include "../trace.h"
 
 #if !defined(CONFIG_USER_ONLY)
 #include "hw/s390x/storage-keys.h"
-- 
2.41.0




[PATCH 0/5] trace: Remove and forbid newline characters in event format

2024-06-06 Thread Philippe Mathieu-Daudé
Trace events aren't designed to be multi-lines.
Few format use the newline character: remove it
and forbid further uses.

Philippe Mathieu-Daudé (5):
  backends/tpm: Remove newline character in trace event
  hw/sh4: Remove newline character in trace events
  hw/usb: Remove newline character in trace events
  hw/vfio: Remove newline character in trace events
  tracetool: Forbid newline character in event format

 backends/tpm/tpm_util.c   | 5 +++--
 backends/tpm/trace-events | 3 ++-
 hw/sh4/trace-events   | 4 ++--
 hw/usb/trace-events   | 6 +++---
 hw/vfio/trace-events  | 4 ++--
 scripts/tracetool/__init__.py | 2 ++
 6 files changed, 14 insertions(+), 10 deletions(-)

-- 
2.41.0




[PATCH 1/5] backends/tpm: Remove newline character in trace event

2024-06-06 Thread Philippe Mathieu-Daudé
Split the 'tpm_util_show_buffer' event in two to avoid
using a newline character.

Signed-off-by: Philippe Mathieu-Daudé 
---
 backends/tpm/tpm_util.c   | 5 +++--
 backends/tpm/trace-events | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/backends/tpm/tpm_util.c b/backends/tpm/tpm_util.c
index 1856589c3b..cf138551df 100644
--- a/backends/tpm/tpm_util.c
+++ b/backends/tpm/tpm_util.c
@@ -339,10 +339,11 @@ void tpm_util_show_buffer(const unsigned char *buffer,
 size_t len, i;
 char *line_buffer, *p;
 
-if (!trace_event_get_state_backends(TRACE_TPM_UTIL_SHOW_BUFFER)) {
+if (!trace_event_get_state_backends(TRACE_TPM_UTIL_SHOW_BUFFER_CONTENT)) {
 return;
 }
 len = MIN(tpm_cmd_get_size(buffer), buffer_size);
+trace_tpm_util_show_buffer_header(string, len);
 
 /*
  * allocate enough room for 3 chars per buffer entry plus a
@@ -356,7 +357,7 @@ void tpm_util_show_buffer(const unsigned char *buffer,
 }
 p += sprintf(p, "%.2X ", buffer[i]);
 }
-trace_tpm_util_show_buffer(string, len, line_buffer);
+trace_tpm_util_show_buffer_content(line_buffer);
 
 g_free(line_buffer);
 }
diff --git a/backends/tpm/trace-events b/backends/tpm/trace-events
index 1ecef42a07..cb5cfa6510 100644
--- a/backends/tpm/trace-events
+++ b/backends/tpm/trace-events
@@ -10,7 +10,8 @@ tpm_util_get_buffer_size_len(uint32_t len, size_t expected) 
"tpm_resp->len = %u,
 tpm_util_get_buffer_size_hdr_len2(uint32_t len, size_t expected) 
"tpm2_resp->hdr.len = %u, expected = %zu"
 tpm_util_get_buffer_size_len2(uint32_t len, size_t expected) "tpm2_resp->len = 
%u, expected = %zu"
 tpm_util_get_buffer_size(size_t len) "buffersize of device: %zu"
-tpm_util_show_buffer(const char *direction, size_t len, const char *buf) 
"direction: %s len: %zu\n%s"
+tpm_util_show_buffer_header(const char *direction, size_t len) "direction: %s 
len: %zu"
+tpm_util_show_buffer_content(const char *buf) "%s"
 
 # tpm_emulator.c
 tpm_emulator_set_locality(uint8_t locty) "setting locality to %d"
-- 
2.41.0




[PATCH 4/5] hw/vfio: Remove newline character in trace events

2024-06-06 Thread Philippe Mathieu-Daudé
Trace events aren't designed to be multi-lines.
Remove the newline characters.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/vfio/trace-events | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/vfio/trace-events b/hw/vfio/trace-events
index 64161bf6f4..e16179b507 100644
--- a/hw/vfio/trace-events
+++ b/hw/vfio/trace-events
@@ -19,7 +19,7 @@ vfio_msix_fixup(const char *name, int bar, uint64_t start, 
uint64_t end) " (%s)
 vfio_msix_relo(const char *name, int bar, uint64_t offset) " (%s) BAR %d 
offset 0x%"PRIx64""
 vfio_msi_enable(const char *name, int nr_vectors) " (%s) Enabled %d MSI 
vectors"
 vfio_msi_disable(const char *name) " (%s)"
-vfio_pci_load_rom(const char *name, unsigned long size, unsigned long offset, 
unsigned long flags) "Device %s ROM:\n  size: 0x%lx, offset: 0x%lx, flags: 
0x%lx"
+vfio_pci_load_rom(const char *name, unsigned long size, unsigned long offset, 
unsigned long flags) "Device '%s' ROM: size: 0x%lx, offset: 0x%lx, flags: 0x%lx"
 vfio_rom_read(const char *name, uint64_t addr, int size, uint64_t data) " (%s, 
0x%"PRIx64", 0x%x) = 0x%"PRIx64
 vfio_pci_size_rom(const char *name, int size) "%s ROM size 0x%x"
 vfio_vga_write(uint64_t addr, uint64_t data, int size) " (0x%"PRIx64", 
0x%"PRIx64", %d)"
@@ -35,7 +35,7 @@ vfio_pci_hot_reset(const char *name, const char *type) " (%s) 
%s"
 vfio_pci_hot_reset_has_dep_devices(const char *name) "%s: hot reset dependent 
devices:"
 vfio_pci_hot_reset_dep_devices(int domain, int bus, int slot, int function, 
int group_id) "\t%04x:%02x:%02x.%x group %d"
 vfio_pci_hot_reset_result(const char *name, const char *result) "%s hot reset: 
%s"
-vfio_populate_device_config(const char *name, unsigned long size, unsigned 
long offset, unsigned long flags) "Device %s config:\n  size: 0x%lx, offset: 
0x%lx, flags: 0x%lx"
+vfio_populate_device_config(const char *name, unsigned long size, unsigned 
long offset, unsigned long flags) "Device '%s' config: size: 0x%lx, offset: 
0x%lx, flags: 0x%lx"
 vfio_populate_device_get_irq_info_failure(const char *errstr) 
"VFIO_DEVICE_GET_IRQ_INFO failure: %s"
 vfio_attach_device(const char *name, int group_id) " (%s) group %d"
 vfio_detach_device(const char *name, int group_id) " (%s) group %d"
-- 
2.41.0




[PATCH 5/5] tracetool: Forbid newline character in event format

2024-06-06 Thread Philippe Mathieu-Daudé
Events aren't designed to be multi-lines. Multiple events
can be used instead. Prevent that format using multi-lines
by forbidding the newline character.

Signed-off-by: Philippe Mathieu-Daudé 
---
 scripts/tracetool/__init__.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/tracetool/__init__.py b/scripts/tracetool/__init__.py
index 7237abe0e8..bc03238c0f 100644
--- a/scripts/tracetool/__init__.py
+++ b/scripts/tracetool/__init__.py
@@ -301,6 +301,8 @@ def build(line_str, lineno, filename):
 if fmt.endswith(r'\n"'):
 raise ValueError("Event format must not end with a newline "
  "character")
+if '\\n' in fmt:
+raise ValueError("Event format must not use new line character")
 
 if len(fmt_trans) > 0:
 fmt = [fmt_trans, fmt]
-- 
2.41.0




[PATCH 3/5] hw/usb: Remove newline character in trace events

2024-06-06 Thread Philippe Mathieu-Daudé
Trace events aren't designed to be multi-lines.
Remove the newline characters.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/usb/trace-events | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/hw/usb/trace-events b/hw/usb/trace-events
index fd7b90d70c..46732717a9 100644
--- a/hw/usb/trace-events
+++ b/hw/usb/trace-events
@@ -15,7 +15,7 @@ usb_ohci_exit(const char *s) "%s"
 
 # hcd-ohci.c
 usb_ohci_iso_td_read_failed(uint32_t addr) "ISO_TD read error at 0x%x"
-usb_ohci_iso_td_head(uint32_t head, uint32_t tail, uint32_t flags, uint32_t 
bp, uint32_t next, uint32_t be, uint32_t framenum, uint32_t startframe, 
uint32_t framecount, int rel_frame_num) "ISO_TD ED head 0x%.8x tailp 
0x%.8x\n0x%.8x 0x%.8x 0x%.8x 0x%.8x\nframe_number 0x%.8x starting_frame 
0x%.8x\nframe_count  0x%.8x relative %d"
+usb_ohci_iso_td_head(uint32_t head, uint32_t tail, uint32_t flags, uint32_t 
bp, uint32_t next, uint32_t be, uint32_t framenum, uint32_t startframe, 
uint32_t framecount, int rel_frame_num) "ISO_TD ED head 0x%.8x tailp 0x%.8x, 
flags 0x%.8x bp 0x%.8x next 0x%.8x be 0x%.8x, frame_number 0x%.8x 
starting_frame 0x%.8x, frame_count 0x%.8x relative %d"
 usb_ohci_iso_td_head_offset(uint32_t o0, uint32_t o1, uint32_t o2, uint32_t 
o3, uint32_t o4, uint32_t o5, uint32_t o6, uint32_t o7) "0x%.8x 0x%.8x 0x%.8x 
0x%.8x 0x%.8x 0x%.8x 0x%.8x 0x%.8x"
 usb_ohci_iso_td_relative_frame_number_neg(int rel) "ISO_TD R=%d < 0"
 usb_ohci_iso_td_relative_frame_number_big(int rel, int count) "ISO_TD R=%d > 
FC=%d"
@@ -23,7 +23,7 @@ usb_ohci_iso_td_bad_direction(int dir) "Bad direction %d"
 usb_ohci_iso_td_bad_bp_be(uint32_t bp, uint32_t be) "ISO_TD bp 0x%.8x be 
0x%.8x"
 usb_ohci_iso_td_bad_cc_not_accessed(uint32_t start, uint32_t next) "ISO_TD cc 
!= not accessed 0x%.8x 0x%.8x"
 usb_ohci_iso_td_bad_cc_overrun(uint32_t start, uint32_t next) "ISO_TD 
start_offset=0x%.8x > next_offset=0x%.8x"
-usb_ohci_iso_td_so(uint32_t so, uint32_t eo, uint32_t s, uint32_t e, const 
char *str, ssize_t len, int ret) "0x%.8x eo 0x%.8x\nsa 0x%.8x ea 0x%.8x\ndir %s 
len %zu ret %d"
+usb_ohci_iso_td_so(uint32_t so, uint32_t eo, uint32_t s, uint32_t e, const 
char *str, ssize_t len, int ret) "0x%.8x eo 0x%.8x sa 0x%.8x ea 0x%.8x dir %s 
len %zu ret %d"
 usb_ohci_iso_td_data_overrun(int ret, ssize_t len) "DataOverrun %d > %zu"
 usb_ohci_iso_td_data_underrun(int ret) "DataUnderrun %d"
 usb_ohci_iso_td_nak(int ret) "got NAK/STALL %d"
@@ -55,7 +55,7 @@ usb_ohci_td_pkt_full(const char *dir, const char *buf) "%s 
data: %s"
 usb_ohci_td_too_many_pending(int ep) "ep=%d"
 usb_ohci_td_packet_status(int status) "status=%d"
 usb_ohci_ed_read_error(uint32_t addr) "ED read error at 0x%x"
-usb_ohci_ed_pkt(uint32_t cur, int h, int c, uint32_t head, uint32_t tail, 
uint32_t next) "ED @ 0x%.8x h=%u c=%u\n  head=0x%.8x tailp=0x%.8x next=0x%.8x"
+usb_ohci_ed_pkt(uint32_t cur, int h, int c, uint32_t head, uint32_t tail, 
uint32_t next) "ED @ 0x%.8x h=%u c=%u head=0x%.8x tailp=0x%.8x next=0x%.8x"
 usb_ohci_ed_pkt_flags(uint32_t fa, uint32_t en, uint32_t d, int s, int k, int 
f, uint32_t mps) "fa=%u en=%u d=%u s=%u k=%u f=%u mps=%u"
 usb_ohci_hcca_read_error(uint32_t addr) "HCCA read error at 0x%x"
 usb_ohci_mem_read(uint32_t size, const char *name, uint32_t addr, uint32_t 
offs, uint32_t val) "%d %s 0x%x %d -> 0x%x"
-- 
2.41.0




[PATCH 2/5] hw/sh4: Remove newline character in trace events

2024-06-06 Thread Philippe Mathieu-Daudé
Trace events aren't designed to be multi-lines. Remove
the newline character which doesn't bring much value.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/sh4/trace-events | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/sh4/trace-events b/hw/sh4/trace-events
index 4b61cd56c8..6bfd7eebc4 100644
--- a/hw/sh4/trace-events
+++ b/hw/sh4/trace-events
@@ -1,3 +1,3 @@
 # sh7750.c
-sh7750_porta(uint16_t prev, uint16_t cur, uint16_t pdtr, uint16_t pctr) "porta 
changed from 0x%04x to 0x%04x\npdtra=0x%04x, pctra=0x%08x"
-sh7750_portb(uint16_t prev, uint16_t cur, uint16_t pdtr, uint16_t pctr) "portb 
changed from 0x%04x to 0x%04x\npdtrb=0x%04x, pctrb=0x%08x"
+sh7750_porta(uint16_t prev, uint16_t cur, uint16_t pdtr, uint16_t pctr) "porta 
changed from 0x%04x to 0x%04x (pdtra=0x%04x, pctra=0x%08x)"
+sh7750_portb(uint16_t prev, uint16_t cur, uint16_t pdtr, uint16_t pctr) "portb 
changed from 0x%04x to 0x%04x (pdtrb=0x%04x, pctrb=0x%08x)"
-- 
2.41.0




Re: [PATCH 0/3] virtio-gpu: Enable virglrenderer backend for rutabaga

2024-06-06 Thread Alex Bennée
Weifeng Liu  writes:

> Greetings,
>
> I'd like to introduce you my attempt to enable virglrenderer backend for
> rutabaga empowered virtio-gpu device.  I am aware that there have been
> effort in supporting venus in virtio-gpu-virgl.c [1], but there is no
> reason to prevent us from leveraging the virglrenderer component in
> rutabaga_gfx, especially it being not very hard to add this
> functionality.
>
> Generally, the gap is the polling capability, i.e., virglrenderer
> requires the main thread (namely the GPU command handling thread) to
> poll virglrenderer at proper moments, which is not yet supported in
> virtio-gpu-rutabaga device. This patch set try to add this so that
> virglrenderer backend (including virgl and venus) can work as expected.
>
> Slight change to rutabaga_gfx_ffi is also a requirement, which is
> included in [2].
>
> Further effort is required to tune the performance, since copying is
> present before the rendered images get displayed. But I still think this
> patch set could be a good starting point for the pending work.
>
> For those interested in setting up environment and playing around with
> this patch set, here is guideline in brief:
>
> 1. Clone the master/main branch of virglrenderer, compile and install it.
>
>   git clone https://gitlab.freedesktop.org/virgl/virglrenderer
>   cd virglrenderer
>   meson setup builddir \
> --prefix=$INSTALL_DIR/virglrenderer \
> -Dvenus=true
>   ninja -C builddir install
>
> 2. Clone the patched CrosVM, build and install rutabaga_gfx_ffi.
>
>   git clone -b rutabaga_ffi_virgl https://github.com/phreer/crosvm.git
>   cd crosvm/rutabaga_gfx/ffi
>   export PKG_CONFIG_PATH=$INSTALL_DIR/virglrenderer/lib64/pkgconfig/
>   meson setup builddir/ \
> --prefix $HOME/install/rutabaga_gfx/rutabaga_gfx_ffi/ \
> -Dvirglrenderer=true
>   ninja -C builddir install

Is there a PR going in for this? The moving parts for rutabaga are
complex enough I think we need support upstream before merging this.

Is this branch where I should be getting the poll helpers from?

  cc -m64 @qemu-system-arm.rsp
  /usr/bin/ld: libcommon.fa.p/hw_display_virtio-gpu-rutabaga.c.o: in function 
`virtio_gpu_fence_poll':
  
/home/alex/lsrc/qemu.git/builds/vulkan/../../hw/display/virtio-gpu-rutabaga.c:909:
 undefined reference to `rutabaga_poll'
  /usr/bin/ld: libcommon.fa.p/hw_display_virtio-gpu-rutabaga.c.o: in function 
`virtio_gpu_rutabaga_init':
  
/home/alex/lsrc/qemu.git/builds/vulkan/../../hw/display/virtio-gpu-rutabaga.c:1122:
 undefined reference to `rutabaga_poll_descriptor'
  collect2: error: ld returned 1 exit status
  ninja: build stopped: subcommand failed.


> 3. Applied this patch set to QEMU, build and install it:
>
>   cd qemu 
>   # Apply this patch set atop main branch ...
>   mkdir builddir; cd builddir
>   ../configure --prefix=$INSTALL_DIR/qemu \
> --target-list=x86_64-softmmu \
> --disable-virglrenderer \
> --enable-rutabaga_gfx
>   ninja -C builddir install
>
> 4. If you are lucky and everything goes fine, you are prepared to launch
>VM with virglrenderer backed virtio-gpu-rutabaga device:
>
>   export 
> LD_LIBRARY_PATH=$INSTALL_DIR/virglrenderer/lib64/:$LD_LIBRARY_PATH
>   export 
> LD_LIBRARY_PATH=$INSTALL_DIR/rutabaga_gfx_ffi/lib64/:$LD_LIBRARY_PATH
>   $INSTALL_DIR/qemu/bin/qemu-system-x86_64
>   $QEMU -d guest_errors -enable-kvm -M q35 -smp 4 -m $MEM \
> -object memory-backend-memfd,id=mem1,size=$MEM \
> -machine memory-backend=mem1 \
> -device 
> virtio-vga-rutabaga,venus=on,virgl2=on,wsi=surfaceless,hostmem=$MEM \
>

This should go into docs/system/devices/virtio-gpu.rst with some
explanation. Is there anything we need on the guest side or does this
skip the encapsulating requirements of wayland?

> Note:
>
> - You might need this patch set [3] to avoid KVM bad address error when
>   you are running on a GPU using TTM for memory management.
>
> [1] 
> https://lore.kernel.org/all/dba6eb97-e1d1-4694-bfb6-e72db9571...@daynix.com/T/
> [2] https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5599645/1
> [3] https://lore.kernel.org/kvm/20240229025759.1187910-1-steve...@google.com/
>
> Weifeng Liu (3):
>   virtio-gpu: rutabaga: Properly set stride when copying resources
>   virtio-gpu: rutabaga: Poll rutabaga upon events
>   virtio-gpu: rutabaga: Add options to enable virgl and venus contexts
>
>  hw/display/virtio-gpu-rutabaga.c | 104 ++-
>  include/hw/virtio/virtio-gpu.h   |   1 +
>  2 files changed, 104 insertions(+), 1 deletion(-)

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro



Re: [PATCH v5 25/65] i386/tdx: Add property sept-ve-disable for tdx-guest object

2024-06-06 Thread Daniel P . Berrangé
Copying  Zhenzhong Duan as my point relates to the proposed libvirt
TDX patches.

On Thu, Feb 29, 2024 at 01:36:46AM -0500, Xiaoyao Li wrote:
> Bit 28 of TD attribute, named SEPT_VE_DISABLE. When set to 1, it disables
> EPT violation conversion to #VE on guest TD access of PENDING pages.
> 
> Some guest OS (e.g., Linux TD guest) may require this bit as 1.
> Otherwise refuse to boot.
> 
> Add sept-ve-disable property for tdx-guest object, for user to configure
> this bit.
> 
> Signed-off-by: Xiaoyao Li 
> Acked-by: Gerd Hoffmann 
> Acked-by: Markus Armbruster 
> ---
> Changes in v4:
> - collect Acked-by from Markus
> 
> Changes in v3:
> - update the comment of property @sept-ve-disable to make it more
>   descriptive and use new format. (Daniel and Markus)
> ---
>  qapi/qom.json |  7 ++-
>  target/i386/kvm/tdx.c | 24 
>  2 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/qapi/qom.json b/qapi/qom.json
> index 220cc6c98d4b..89ed89b9b46e 100644
> --- a/qapi/qom.json
> +++ b/qapi/qom.json
> @@ -900,10 +900,15 @@
>  #
>  # Properties for tdx-guest objects.
>  #
> +# @sept-ve-disable: toggle bit 28 of TD attributes to control disabling
> +# of EPT violation conversion to #VE on guest TD access of PENDING
> +# pages.  Some guest OS (e.g., Linux TD guest) may require this to
> +# be set, otherwise they refuse to boot.
> +#
>  # Since: 9.0
>  ##
>  { 'struct': 'TdxGuestProperties',
> -  'data': { }}
> +  'data': { '*sept-ve-disable': 'bool' } }

So this exposes a single boolean property that gets mapped into one
specific bit in the TD attributes:

> +
> +static void tdx_guest_set_sept_ve_disable(Object *obj, bool value, Error 
> **errp)
> +{
> +TdxGuest *tdx = TDX_GUEST(obj);
> +
> +if (value) {
> +tdx->attributes |= TDX_TD_ATTRIBUTES_SEPT_VE_DISABLE;
> +} else {
> +tdx->attributes &= ~TDX_TD_ATTRIBUTES_SEPT_VE_DISABLE;
> +}
> +}

If I look at the documentation for TD attributes

  
https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf

Section "A.3.4. TD Attributes"

I see "TD attributes" is a 64-bit int, with 5 bits currently
defined "DEBUG", "SEPT_VE_DISABLE", "PKS", "PL", "PERFMON",
and the rest currently reserved for future use. This makes me
wonder about our modelling approach into the future ?

For the AMD SEV equivalent we've just directly exposed the whole
field as an int:

 'policy' : 'uint32',

For the proposed SEV-SNP patches, the same has been done again

https://lists.nongnu.org/archive/html/qemu-devel/2024-06/msg00536.html

 '*policy': 'uint64',


The advantage of exposing individual booleans is that it is
self-documenting at the QAPI level, but the disadvantage is
that every time we want to expose ability to control a new
bit in the policy we have to modify QEMU, libvirt, the mgmt
app above libvirt, and whatever tools the end user has to
talk to the mgmt app.

If we expose a policy int, then newly defined bits only require
a change in QEMU, and everything above QEMU will already be
capable of setting it.

In fact if I look at the proposed libvirt patches, they have
proposed just exposing a policy "int" field in the XML, which
then has to be unpacked to set the individual QAPI booleans

  
https://lists.libvirt.org/archives/list/de...@lists.libvirt.org/message/WXWXEESYUA77DP7YIBP55T2OPSVKV5QW/

On balance, I think it would be better if QEMU just exposed
the raw TD attributes policy as an uint64 at QAPI, instead
of trying to unpack it to discrete bool fields. This gives
consistency with SEV and SEV-SNP, and with what's proposed
at the libvirt level, and minimizes future changes when
more policy bits are defined.

> +
>  /* tdx guest */
>  OBJECT_DEFINE_TYPE_WITH_INTERFACES(TdxGuest,
> tdx_guest,
> @@ -529,6 +549,10 @@ static void tdx_guest_init(Object *obj)
>  qemu_mutex_init(&tdx->lock);
>  
>  tdx->attributes = 0;
> +
> +object_property_add_bool(obj, "sept-ve-disable",
> + tdx_guest_get_sept_ve_disable,
> + tdx_guest_set_sept_ve_disable);
>  }
>  
>  static void tdx_guest_finalize(Object *obj)
> -- 
> 2.34.1
> 

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




[PATCH RFC] hw/arm/virt: Avoid unexpected warning from Linux guest on host with Fujitsu CPUs

2024-06-06 Thread Zhenyu Zhang
Multiple warning messages and corresponding backtraces are observed when Linux
guest is booted on the host with Fujitsu CPUs. One of them is shown as below.

[0.032443] [ cut here ]
[0.032446] uart-pl011 900.pl011: ARCH_DMA_MINALIGN smaller than 
CTR_EL0.CWG (128 < 256)
[0.032454] WARNING: CPU: 0 PID: 1 at arch/arm64/mm/dma-mapping.c:54 
arch_setup_dma_ops+0xbc/0xcc
[0.032470] Modules linked in:
[0.032475] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-452.el9.aarch64 
#1
[0.032481] Hardware name: linux,dummy-virt (DT)
[0.032484] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[0.032490] pc : arch_setup_dma_ops+0xbc/0xcc
[0.032496] lr : arch_setup_dma_ops+0xbc/0xcc
[0.032501] sp : 80008003b860
[0.032503] x29: 80008003b860 x28:  x27: aae4b949049c
[0.032510] x26:  x25:  x24: 
[0.032517] x23: 0100 x22:  x21: 
[0.032523] x20: 0001 x19: 2f06c02ea400 x18: 
[0.032529] x17: 208a5f76 x16: 6589dbcb x15: aae4ba071c89
[0.032535] x14:  x13: aae4ba071c84 x12: 455f525443206e61
[0.032541] x11: 68742072656c6c61 x10: 0029 x9 : aae4b7d21da4
[0.032547] x8 : 0029 x7 : 4c414e494d5f414d x6 : 0029
[0.032553] x5 : 000f x4 : aae4b9617a00 x3 : 0001
[0.032558] x2 :  x1 :  x0 : 2f06c029be40
[0.032564] Call trace:
[0.032566]  arch_setup_dma_ops+0xbc/0xcc
[0.032572]  of_dma_configure_id+0x138/0x300
[0.032591]  amba_dma_configure+0x34/0xc0
[0.032600]  really_probe+0x78/0x3dc
[0.032614]  __driver_probe_device+0x108/0x160
[0.032619]  driver_probe_device+0x44/0x114
[0.032624]  __device_attach_driver+0xb8/0x14c
[0.032629]  bus_for_each_drv+0x88/0xe4
[0.032634]  __device_attach+0xb0/0x1e0
[0.032638]  device_initial_probe+0x18/0x20
[0.032643]  bus_probe_device+0xa8/0xb0
[0.032648]  device_add+0x4b4/0x6c0
[0.032652]  amba_device_try_add.part.0+0x48/0x360
[0.032657]  amba_device_add+0x104/0x144
[0.032662]  of_amba_device_create.isra.0+0x100/0x1c4
[0.032666]  of_platform_bus_create+0x294/0x35c
[0.032669]  of_platform_populate+0x5c/0x150
[0.032672]  of_platform_default_populate_init+0xd0/0xec
[0.032697]  do_one_initcall+0x4c/0x2e0
[0.032701]  do_initcalls+0x100/0x13c
[0.032707]  kernel_init_freeable+0x1c8/0x21c
[0.032712]  kernel_init+0x28/0x140
[0.032731]  ret_from_fork+0x10/0x20
[0.032735] ---[ end trace  ]---

In Linux, a check is applied to every device which is exposed through 
device-tree
node. The warning message is raised when the device isn't DMA coherent and the
cache line size is larger than ARCH_DMA_MINALIGN (128 bytes). The cache line is
sorted from CTR_EL0[CWG], which corresponds to 256 bytes on the guest CPUs. 
The DMA coherent capability is claimed through 'dma-coherent' in their
device-tree nodes.

I don't see those devices need to be DMA incoherent necessarily and those 
devices
will do DMA operations in practice. So lets add 'dma-coherent' property to their
device-tree nodes to avoid the unexpected warnings in the Linux guest.

Signed-off-by: Zhenyu Zhang 
---
 hw/arm/boot.c| 1 +
 hw/arm/virt.c| 4 
 hw/core/sysbus-fdt.c | 1 +
 3 files changed, 6 insertions(+)

diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index d480a7da02..cdf99966e6 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -509,6 +509,7 @@ static void fdt_add_psci_node(void *fdt)
 qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", cpu_off_fn);
 qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", cpu_on_fn);
 qemu_fdt_setprop_cell(fdt, "/psci", "migrate", migrate_fn);
+qemu_fdt_setprop(fdt, "/psci", "dma-coherent", NULL, 0);
 }
 
 int arm_load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 3c93c0c0a6..d3e5f512e2 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -652,6 +652,7 @@ static void fdt_add_pmu_nodes(const VirtMachineState *vms)
 qemu_fdt_setprop_cells(ms->fdt, "/pmu", "interrupts",
GIC_FDT_IRQ_TYPE_PPI,
INTID_TO_PPI(VIRTUAL_PMU_IRQ), irqflags);
+qemu_fdt_setprop(ms->fdt, "/pmu", "dma-coherent", NULL, 0);
 }
 }
 
@@ -936,6 +937,7 @@ static void create_uart(const VirtMachineState *vms, int 
uart,
vms->clock_phandle, vms->clock_phandle);
 qemu_fdt_setprop(ms->fdt, nodename, "clock-names",
  clocknames, sizeof(clocknames));
+qemu_fdt_setprop(ms->fdt, nodename, "dma-coherent", NULL, 0);
 
 if (uart == VIRT_UART) {
 qemu_fdt_setprop_string(ms->fdt, "/chosen", "stdout-path", nodename);
@@ -972,6 +974,7 @@ sta

Re: Unexpected error in rme_configure_one() at ../target/arm/kvm-rme.c:159

2024-06-06 Thread Jean-Philippe Brucker
On Thu, Jun 06, 2024 at 03:05:02PM +1000, Gavin Shan wrote:
> > This commit moves the page tables from .rodata to .data. When linking
> > IdMap.obj into ArmPlatformPrePeiCore.dll, the alignment of the .text
> > section changes from 0x1000 to 0x800. This change comes from the linker
> > script putting .rodata into .text. I don't know why the included .rodata
> > alignment affects the .text alignment, but I don't think it matters here.
> > 
> > In GenFw, ScanSections64() calculates a mCoffAlignment as the max
> > .text/.data/.hii section alignement. Since with this commit, .data
> > alignement (0x1000) becomes larger than .text (0x800), it picks 0x1000 as
> > the output text offset, and then WriteSections64() complains that this
> > offset isn't equal to the input .text alignment modulo 0x1000.
> > 
> > The linker script says:
> > 
> >/*
> > * The alignment of the .data section should be less than or equal to the
> > * alignment of the .text section. This ensures that the relative offset
> > * between these sections is the same in the ELF and the PE/COFF 
> > versions of
> > * this binary.
> > */
> > 
> > but that's not what we're getting. I don't have a fix yet, other than
> > forcing the .text and .data alignment to 4k.
> > 
> 
> Jean, thanks for your explanation. Right, the issue is caused by mismatched
> alignments for ELF and PE/COFF sections. I ever dumped the variables at the
> failing point, showing the mismatched alignments (0x800 vs 0x1000). Apart from
> that, the virtual address of 'text' section is aligned to 0x800 instead of
> 0x1000 after ArmPlatformPrePeiCore.dll is dumped by 'readelf'.
> 
> SecHdr->sh_addr:0x800  <<< Mismatched 
> alignment between ELF and PE/COFF
> SecOffset:  0x1000
> SymShdr->sh_addr:   0x800
> mCoffSectionsOffset[Sym->st_shndx]: 0x1000
> GenFw: ERROR 3000: Invalid
>   WriteSections64(): 
> /home/gavin/sandbox/CCA/edk2-guest/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore/DEBUG/ArmPlatformPrePeiCore.dll
>  AARCH64 small code model requires identical ELF and PE/COFF section offsets 
> modulo 4 KB.
> 
> # readelf -S 
> Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/ArmPlatformPkg/PrePeiCore/PrePeiCoreUniCore/DEBUG/ArmPlatformPrePeiCore.dll
> Section Headers:
>   [Nr] Name  Type Address   Offset
>Size  EntSize  Flags  Link  Info  Align
>   [ 0]   NULL   
>     0 0 0
>   [ 1] .text PROGBITS 0800  0800   
> <<< Aligned to 0x800
>51b8    AX   0 0 2048
> 
> With the following changes, I'm able to build the firmware successfully. I 
> don't
> see how COMMONPAGESIZE is sorted out because I don't find its definition in 
> the
> source code.

It's a ld builtin, set on the command-line with "-z common-page-size=X" by
Conf/tools_def.txt, in this case I believe DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS. 

> 
> diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
> index 9f27e83bb0..5463df47a9 100644
> --- a/BaseTools/Scripts/GccBase.lds
> +++ b/BaseTools/Scripts/GccBase.lds
> @@ -20,7 +20,8 @@ SECTIONS {
> */
>. = PECOFF_HEADER_SIZE;
> -  .text : ALIGN(CONSTANT(COMMONPAGESIZE)) {
> +  /* .text : ALIGN(CONSTANT(COMMONPAGESIZE)) { */^M
> +  .text : ALIGN(4096) {^M

Build (after clean) fails for me if I only change the .text 
alignment, I need .data as well. So changing Conf/tools_def.txt is easier.
I'll try to find a proper fix but it will take me some time to understand
GenFw.


> > > > Note that the guest edk2 is optional and experimental, you can use 
> > > > direct
> > > > kernel boot to get a working demo quicker.
> > > > 
> > > 
> > > I never did this before. Could you please provide the detailed steps on 
> > > this?
> > 
> > Removing the -bios parameter to QEMU should be enough. You can also add
> > 'earlycon' to -append to show early boot errors.
> > 
> 
> I didn't get a chance to try this yet since the host can't be brought up now.
> I will try this later. I originally thought some sort of boot wrapper is 
> needed
> so that the kernel image has the capability to boot itself. For example, Mark
> Rutland's boot wrapper [1] can be leveraged in this case. I don't think Image 
> has
> the capability to boot itself, right?

Yes QEMU can set up everything so that the Image boots on its own. What
the boot-wrapper does is minimal hardware initialization, handling PSCI
calls and passing the DTB pointer in x0. But that's only needed when using
the Arm FastModel (boot-wrapper is a lightweight firmware specifically for
the FastModel). QEMU can do all that itself so you can boot a kernel
without any firmware.

Using edk2 in the Realm guest will be needed for example to boot a distro
ima

Re: [PATCH] hw/net: cadence_gem: fix: type2_compare_x_word_0 error

2024-06-06 Thread Edgar E. Iglesias
On Thu, Jun 6, 2024 at 12:00 PM Andrew.Yuan 
wrote:

> In the Cadence IP for Gigabit Ethernet MAC Part Number: IP7014 IP
> Rev: R1p12 - Doc Rev: 1.3 User Guide, the specification for the
> type2_compare_x_word_0 register is as follows:
> The byte stored in bits [23:16] is compared against the byte in
> the received frame from the selected offset+0, and the byte stored in bits
> [31:24] is compared against the byte in
> the received frame from the selected offset+1.
>
> However, there is an implementation error in the cadence_gem model
> in qemu:
> the byte stored in bits [31:24] is compared against the byte in
> the received frame from the selected offset+0
>
> Now, the error code is as follows:
> rx_cmp = rxbuf_ptr[offset] << 8 | rxbuf_ptr[offset];
>
> and needs to be corrected to:
> rx_cmp = rxbuf_ptr[offset + 1] << 8 | rxbuf_ptr[offset];
>
> Signed-off-by: Andrew.Yuan 
>


LGTM:
Reviewed-by: Edgar E. Iglesias 

At some point it would be nice to add the missing logic for the
DISABLE_MASK bit that
extends the compare range from 16 to 32-bits.

Cheers,
Edgar



> ---
>  hw/net/cadence_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/net/cadence_gem.c b/hw/net/cadence_gem.c
> index ec7bf562e5..9c73ded0d3 100644
> --- a/hw/net/cadence_gem.c
> +++ b/hw/net/cadence_gem.c
> @@ -946,7 +946,7 @@ static int get_queue_from_screen(CadenceGEMState *s,
> uint8_t *rxbuf_ptr,
>  break;
>  }
>
> -rx_cmp = rxbuf_ptr[offset] << 8 | rxbuf_ptr[offset];
> +rx_cmp = rxbuf_ptr[offset + 1] << 8 | rxbuf_ptr[offset];
>  mask = FIELD_EX32(cr0, TYPE2_COMPARE_0_WORD_0, MASK_VALUE);
>  compare = FIELD_EX32(cr0, TYPE2_COMPARE_0_WORD_0,
> COMPARE_VALUE);
>
> --
> 2.37.0.windows.1
>
>


Re: [PATCH] tracetool: Remove unused vcpu.py script

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 12:26:31PM +0200, Philippe Mathieu-Daudé wrote:
> vcpu.py is pointless since commit 89aafcf2a7 ("trace:
> remove code that depends on setting vcpu"), remote it.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  meson.build   |  1 -
>  scripts/tracetool/__init__.py |  8 +
>  scripts/tracetool/vcpu.py | 59 ---
>  3 files changed, 1 insertion(+), 67 deletions(-)
>  delete mode 100644 scripts/tracetool/vcpu.py

Reviewed-by: Daniel P. Berrangé 


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




Re: [PATCH 1/5] backends/tpm: Remove newline character in trace event

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 12:39:39PM +0200, Philippe Mathieu-Daudé wrote:
> Split the 'tpm_util_show_buffer' event in two to avoid
> using a newline character.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  backends/tpm/tpm_util.c   | 5 +++--
>  backends/tpm/trace-events | 3 ++-
>  2 files changed, 5 insertions(+), 3 deletions(-)

Reviewed-by: Daniel P. Berrangé 


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




Re: [PATCH 2/5] hw/sh4: Remove newline character in trace events

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 12:39:40PM +0200, Philippe Mathieu-Daudé wrote:
> Trace events aren't designed to be multi-lines. Remove
> the newline character which doesn't bring much value.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/sh4/trace-events | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Daniel P. Berrangé 


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




Re: [PATCH 3/5] hw/usb: Remove newline character in trace events

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 12:39:41PM +0200, Philippe Mathieu-Daudé wrote:
> Trace events aren't designed to be multi-lines.
> Remove the newline characters.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/usb/trace-events | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Daniel P. Berrangé 


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




Re: [PATCH 4/5] hw/vfio: Remove newline character in trace events

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 12:39:42PM +0200, Philippe Mathieu-Daudé wrote:
> Trace events aren't designed to be multi-lines.
> Remove the newline characters.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/vfio/trace-events | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Reviewed-by: Daniel P. Berrangé 


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




Re: [PATCH 5/5] tracetool: Forbid newline character in event format

2024-06-06 Thread Daniel P . Berrangé
On Thu, Jun 06, 2024 at 12:39:43PM +0200, Philippe Mathieu-Daudé wrote:
> Events aren't designed to be multi-lines. Multiple events
> can be used instead. Prevent that format using multi-lines
> by forbidding the newline character.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  scripts/tracetool/__init__.py | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Daniel P. Berrangé 

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




Re: [PATCH] spapr: Migrate ail-mode-3 spapr cap

2024-06-06 Thread Michael Tokarev

06.05.2024 14:56, Nicholas Piggin wrote:

This cap did not add the migration code when it was introduced. This
results in migration failure when changing the default using the
command line.

Cc: qemu-sta...@nongnu.org
Fixes: ccc5a4c5e10 ("spapr: Add SPAPR_CAP_AIL_MODE_3 for AIL mode 3 support for 
H_SET_MODE hcall")
Signed-off-by: Nicholas Piggin 
---
  include/hw/ppc/spapr.h | 1 +
  hw/ppc/spapr.c | 1 +
  hw/ppc/spapr_caps.c| 1 +
  3 files changed, 3 insertions(+)


Hi!

Has this change been forgotten?  It's aimed at -stable, so must be
fixing a real issue.

Thanks,

/mjt
--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E  9D8B E14E 3F2A 9DD7 9199  28F1 61AD 3D98 
ECDF 2C8E
Old key: rsa2048/457CE0A0804465C5  6EE1 95D1 886E 8FFB 810D  4324 457C E0A0 
8044 65C5
Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt




Re: [PATCH 0/6] refactor RDMA live migration based on rsocket API

2024-06-06 Thread Leon Romanovsky
On Wed, Jun 05, 2024 at 10:00:24AM +, Gonglei (Arei) wrote:
> 
> 
> > -Original Message-
> > From: Michael S. Tsirkin [mailto:m...@redhat.com]
> > Sent: Wednesday, June 5, 2024 3:57 PM
> > To: Gonglei (Arei) 
> > Cc: qemu-devel@nongnu.org; pet...@redhat.com; yu.zh...@ionos.com;
> > mgal...@akamai.com; elmar.ger...@ionos.com; zhengchuan
> > ; berra...@redhat.com; arm...@redhat.com;
> > lizhij...@fujitsu.com; pbonz...@redhat.com; Xiexiangyou
> > ; linux-r...@vger.kernel.org; lixiao (H)
> > ; jinpu.w...@ionos.com; Wangjialin
> > 
> > Subject: Re: [PATCH 0/6] refactor RDMA live migration based on rsocket API
> > 
> > On Tue, Jun 04, 2024 at 08:14:06PM +0800, Gonglei wrote:
> > > From: Jialin Wang 
> > >
> > > Hi,
> > >
> > > This patch series attempts to refactor RDMA live migration by
> > > introducing a new QIOChannelRDMA class based on the rsocket API.
> > >
> > > The /usr/include/rdma/rsocket.h provides a higher level rsocket API
> > > that is a 1-1 match of the normal kernel 'sockets' API, which hides
> > > the detail of rdma protocol into rsocket and allows us to add support
> > > for some modern features like multifd more easily.
> > >
> > > Here is the previous discussion on refactoring RDMA live migration
> > > using the rsocket API:
> > >
> > > https://lore.kernel.org/qemu-devel/20240328130255.52257-1-philmd@linar
> > > o.org/
> > >
> > > We have encountered some bugs when using rsocket and plan to submit
> > > them to the rdma-core community.
> > >
> > > In addition, the use of rsocket makes our programming more convenient,
> > > but it must be noted that this method introduces multiple memory
> > > copies, which can be imagined that there will be a certain performance
> > > degradation, hoping that friends with RDMA network cards can help verify,
> > thank you!
> > 
> > So you didn't test it with an RDMA card?
> 
> Yep, we tested it by Soft-ROCE.

Does Soft-RoCE (RXE) support live migration?

Thanks



[PULL 02/12] docs/devel: update references to centos to non-versioned container

2024-06-06 Thread Alex Bennée
>From the website:

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

We have updated a few bits but there are still references that need
fixing. Rather than bump I've replaced them with references to the
Debian image so we don't have to bump at the next update.

Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-3-alex.ben...@linaro.org>

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index fa28e3ecb2..23d3f44f52 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -387,9 +387,9 @@ make target):
 
 .. code::
 
-  make docker-test-build@centos8
+  make docker-test-build@debian
 
-This will create a container instance using the ``centos8`` image (the image
+This will create a container instance using the ``debian`` image (the image
 is downloaded and initialized automatically), in which the ``test-build`` job
 is executed.
 
@@ -410,8 +410,8 @@ locally by using the ``NOCACHE`` build option:
 Images
 ~~
 
-Along with many other images, the ``centos8`` image is defined in a Dockerfile
-in ``tests/docker/dockerfiles/``, called ``centos8.docker``. ``make 
docker-help``
+Along with many other images, the ``debian`` image is defined in a Dockerfile
+in ``tests/docker/dockerfiles/``, called ``debian.docker``. ``make 
docker-help``
 command will list all the available images.
 
 A ``.pre`` script can be added beside the ``.docker`` file, which will be
-- 
2.39.2




[PULL 05/12] scripts/ci: remove CentOS bits from common build-environment

2024-06-06 Thread Alex Bennée
Although I've just removed the CentOS specific build-environment its
probably a bit too confusing to have multiple distros mixed up in one
place. Prior to moving clean-up what will be just for ubuntu.

Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-6-alex.ben...@linaro.org>

diff --git a/scripts/ci/setup/build-environment.yml 
b/scripts/ci/setup/build-environment.yml
index de0d866a1e..e82097b465 100644
--- a/scripts/ci/setup/build-environment.yml
+++ b/scripts/ci/setup/build-environment.yml
@@ -184,101 +184,3 @@
 - ansible_facts['distribution_version'] == '22.04'
 - ansible_facts['architecture'] == 'aarch64'
 
-- name: Enable EPEL repo on EL8
-  dnf:
-name:
-  - epel-release
-state: present
-  when:
-- ansible_facts['distribution_file_variety'] in ['RedHat', 'CentOS']
-- ansible_facts['distribution_major_version'] == '8'
-
-- name: Enable PowerTools repo on CentOS 8
-  ini_file:
-path: /etc/yum.repos.d/CentOS-Stream-PowerTools.repo
-section: powertools
-option: enabled
-value: "1"
-  when:
-- ansible_facts['distribution_file_variety'] == 'CentOS'
-- ansible_facts['distribution_major_version'] == '8'
-
-- name: Install basic packages to build QEMU on EL8
-  dnf:
-# This list of packages start with 
tests/docker/dockerfiles/centos8.docker
-# but only include files that are common to all distro variants and 
present
-# in the standard repos (no add-ons)
-name:
-  - bzip2
-  - bzip2-devel
-  - capstone-devel
-  - dbus-daemon
-  - device-mapper-multipath-devel
-  - diffutils
-  - gcc
-  - gcc-c++
-  - genisoimage
-  - gettext
-  - git
-  - glib2-devel
-  - glusterfs-api-devel
-  - gnutls-devel
-  - libaio-devel
-  - libcap-ng-devel
-  - libcurl-devel
-  - libepoxy-devel
-  - libfdt-devel
-  - libgcrypt-devel
-  - libiscsi-devel
-  - libpmem-devel
-  - librados-devel
-  - librbd-devel
-  - libseccomp-devel
-  - libssh-devel
-  - libxkbcommon-devel
-  - lzo-devel
-  - make
-  - mesa-libEGL-devel
-  - nettle-devel
-  - ninja-build
-  - nmap-ncat
-  - numactl-devel
-  - pixman-devel
-  - python38
-  - python3-sphinx
-  - rdma-core-devel
-  - redhat-rpm-config
-  - snappy-devel
-  - spice-glib-devel
-  - systemd-devel
-  - systemtap-sdt-devel
-  - tar
-  - zlib-devel
-state: present
-  when:
-- ansible_facts['distribution_file_variety'] in ['RedHat', 'CentOS']
-- ansible_facts['distribution_version'] == '8'
-
-- name: Install packages only available on x86 and aarch64
-  dnf:
-# Spice server not available in ppc64le
-name:
-  - spice-server
-  - spice-server-devel
-state: present
-  when:
-- ansible_facts['distribution_file_variety'] in ['RedHat', 'CentOS']
-- ansible_facts['distribution_version'] == '8'
-- ansible_facts['architecture'] == 'aarch64' or 
ansible_facts['architecture'] == 'x86_64'
-
-- name: Check whether the Python runtime version is managed by alternatives
-  stat:
-path: /etc/alternatives/python3
-  register: python3
-
-- name: Set default Python runtime to 3.8 on EL8
-  command: alternatives --set python3 /usr/bin/python3.8
-  when:
-- ansible_facts['distribution_file_variety'] in ['RedHat', 'CentOS']
-- ansible_facts['distribution_version'] == '8'
-- python3.stat.islnk and python3.stat.lnk_target != 
'/usr/bin/python3.8'
-- 
2.39.2




[PULL 08/12] .gitlab-ci.d/buildtest.yml: Use -fno-sanitize=function in the clang-system job

2024-06-06 Thread Alex Bennée
From: Thomas Huth 

The latest version of Clang (version 18 from Fedora 40) now reports
bad function pointer casts as undefined behavior. Unfortunately, we are
still doing this in quite a lot of places in the QEMU code and some of
them are not easy to fix. So for the time being, temporarily switch this
off in the failing clang-system job until all spots in the QEMU sources
have been tackled.

Signed-off-by: Thomas Huth 
Reviewed-by: Daniel P. Berrangé 
Message-Id: <20240601070543.37786-4-th...@redhat.com>
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-9-alex.ben...@linaro.org>

diff --git a/.gitlab-ci.d/buildtest.yml b/.gitlab-ci.d/buildtest.yml
index 91c57efded..0eec570310 100644
--- a/.gitlab-ci.d/buildtest.yml
+++ b/.gitlab-ci.d/buildtest.yml
@@ -432,6 +432,7 @@ clang-system:
 IMAGE: fedora
 CONFIGURE_ARGS: --cc=clang --cxx=clang++
   --extra-cflags=-fsanitize=undefined 
--extra-cflags=-fno-sanitize-recover=undefined
+  --extra-cflags=-fno-sanitize=function
 TARGETS: alpha-softmmu arm-softmmu m68k-softmmu mips64-softmmu 
s390x-softmmu
 MAKE_CHECK_ARGS: check-qtest check-tcg
 
-- 
2.39.2




[PULL 04/12] tests/vm: remove plain centos image

2024-06-06 Thread Alex Bennée
This isn't really used and we have lighter weight docker containers
for testing this stuff directly.

Reviewed-by: Thomas Huth 
Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-5-alex.ben...@linaro.org>

diff --git a/tests/vm/Makefile.include b/tests/vm/Makefile.include
index ac56824a87..13ed80f72d 100644
--- a/tests/vm/Makefile.include
+++ b/tests/vm/Makefile.include
@@ -45,7 +45,6 @@ vm-help vm-test:
@echo "  vm-build-netbsd - Build QEMU in NetBSD VM"
@echo "  vm-build-openbsd- Build QEMU in OpenBSD VM"
 ifneq ($(GENISOIMAGE),)
-   @echo "  vm-build-centos - Build QEMU in CentOS VM, 
with Docker"
 ifneq ($(EFI_AARCH64),)
@echo "  vm-build-ubuntu.aarch64 - Build QEMU in ubuntu aarch64 
VM"
@echo "  vm-build-centos.aarch64 - Build QEMU in CentOS aarch64 
VM"
diff --git a/tests/vm/centos b/tests/vm/centos
deleted file mode 100755
index d25c8f8b5b..00
--- a/tests/vm/centos
+++ /dev/null
@@ -1,51 +0,0 @@
-#!/usr/bin/env python3
-#
-# CentOS 8 Stream image
-#
-# Copyright 2018, 2022 Red Hat Inc.
-#
-# Authors:
-#  Fam Zheng 
-#
-# This code is licensed under the GPL version 2 or later.  See
-# the COPYING file in the top-level directory.
-#
-
-import os
-import sys
-import subprocess
-import basevm
-import time
-
-class CentosVM(basevm.BaseVM):
-name = "centos"
-arch = "x86_64"
-BUILD_SCRIPT = """
-set -e;
-cd $(mktemp -d);
-export SRC_ARCHIVE=/dev/vdb;
-sudo chmod a+r $SRC_ARCHIVE;
-tar -xf $SRC_ARCHIVE;
-make docker-test-block@centos9 {verbose} J={jobs} NETWORK=1;
-make docker-test-quick@centos9 {verbose} J={jobs} NETWORK=1;
-"""
-
-def build_image(self, img):
-cimg = 
self._download_with_cache("https://cloud.centos.org/centos/8-stream/x86_64/images/CentOS-Stream-GenericCloud-8-20220125.1.x86_64.qcow2";)
-img_tmp = img + ".tmp"
-subprocess.check_call(['cp', '-f', cimg, img_tmp])
-self.exec_qemu_img("resize", img_tmp, "50G")
-self.boot(img_tmp, extra_args = ["-cdrom", self.gen_cloud_init_iso()])
-self.wait_ssh()
-self.ssh_root_check("touch /etc/cloud/cloud-init.disabled")
-self.ssh_root_check("dnf update -y")
-self.ssh_root_check("dnf install -y dnf-plugins-core")
-self.ssh_root_check("dnf config-manager --set-enabled powertools")
-self.ssh_root_check("dnf install -y podman make ninja-build git 
python3")
-self.ssh_root("poweroff")
-self.wait()
-os.rename(img_tmp, img)
-return 0
-
-if __name__ == "__main__":
-sys.exit(basevm.main(CentosVM))
-- 
2.39.2




[PULL 06/12] docs/ci: clean-up references for consistency

2024-06-06 Thread Alex Bennée
Document we have split up build-environment by distro and update the
references that exist in the code base to be correct.

Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-7-alex.ben...@linaro.org>

diff --git a/docs/devel/ci-runners.rst.inc b/docs/devel/ci-runners.rst.inc
index 7817001fb2..67b23d3719 100644
--- a/docs/devel/ci-runners.rst.inc
+++ b/docs/devel/ci-runners.rst.inc
@@ -41,19 +41,18 @@ those hosts.  This would look like::
 Build environment
 ~
 
-The ``scripts/ci/setup/build-environment.yml`` Ansible playbook will
-set up machines with the environment needed to perform builds and run
-QEMU tests.  This playbook consists on the installation of various
-required packages (and a general package update while at it).  It
-currently covers a number of different Linux distributions, but it can
-be expanded to cover other systems.
+The ``scripts/ci/setup/$DISTRO/build-environment.yml`` Ansible
+playbook will set up machines with the environment needed to perform
+builds and run QEMU tests. This playbook consists on the installation
+of various required packages (and a general package update while at
+it).
 
 The minimum required version of Ansible successfully tested in this
 playbook is 2.8.0 (a version check is embedded within the playbook
 itself).  To run the playbook, execute::
 
   cd scripts/ci/setup
-  ansible-playbook -i inventory build-environment.yml
+  ansible-playbook -i inventory $DISTRO/build-environment.yml
 
 Please note that most of the tasks in the playbook require superuser
 privileges, such as those from the ``root`` account or those obtained
diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml 
b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml
index b8a0d75162..8727687e2b 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch32.yml
@@ -1,5 +1,5 @@
 # All ubuntu-22.04 jobs should run successfully in an environment
-# setup by the scripts/ci/setup/qemu/build-environment.yml task
+# setup by the scripts/ci/setup/ubuntu/build-environment.yml task
 # "Install basic packages to build QEMU on Ubuntu 22.04"
 
 ubuntu-22.04-aarch32-all:
diff --git a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml 
b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
index 374b0956c3..263a3c2140 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-aarch64.yml
@@ -1,5 +1,5 @@
 # All ubuntu-22.04 jobs should run successfully in an environment
-# setup by the scripts/ci/setup/qemu/build-environment.yml task
+# setup by the scripts/ci/setup/ubuntu/build-environment.yml task
 # "Install basic packages to build QEMU on Ubuntu 22.04"
 
 ubuntu-22.04-aarch64-all-linux-static:
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 25935048e2..69ddd3e7d5 100644
--- a/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
+++ b/.gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml
@@ -1,5 +1,5 @@
 # All ubuntu-22.04 jobs should run successfully in an environment
-# setup by the scripts/ci/setup/build-environment.yml task
+# setup by the scripts/ci/setup/ubuntu/build-environment.yml task
 # "Install basic packages to build QEMU on Ubuntu 22.04"
 
 ubuntu-22.04-s390x-all-linux:
diff --git a/scripts/ci/setup/build-environment.yml 
b/scripts/ci/setup/ubuntu/build-environment.yml
similarity index 100%
rename from scripts/ci/setup/build-environment.yml
rename to scripts/ci/setup/ubuntu/build-environment.yml
-- 
2.39.2




[PULL 09/12] tests/lcitool: Bump to latest libvirt-ci and update Fedora and Alpine version

2024-06-06 Thread Alex Bennée
From: Thomas Huth 

Update to the latest version of lcitool. It dropped support for Fedora 38
and Alpine 3.18, so we have to update these to newer versions here, too.

Python 3.12 dropped the "imp" module which we still need for running
Avocado. Fortunately Fedora 40 still ships with a work-around package
that we can use until somebody updates our Avocado to a newer version.

Signed-off-by: Thomas Huth 
Message-Id: <20240601070543.37786-3-th...@redhat.com>
[AJB: regen on rebase]
Reviewed-by: Daniel P. Berrangé 
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-10-alex.ben...@linaro.org>

diff --git a/tests/docker/dockerfiles/alpine.docker 
b/tests/docker/dockerfiles/alpine.docker
index 554464f31e..b079a83fe2 100644
--- a/tests/docker/dockerfiles/alpine.docker
+++ b/tests/docker/dockerfiles/alpine.docker
@@ -1,10 +1,10 @@
 # THIS FILE WAS AUTO-GENERATED
 #
-#  $ lcitool dockerfile --layers all alpine-318 qemu
+#  $ lcitool dockerfile --layers all alpine-319 qemu
 #
 # https://gitlab.com/libvirt/libvirt-ci
 
-FROM docker.io/library/alpine:3.18
+FROM docker.io/library/alpine:3.19
 
 RUN apk update && \
 apk upgrade && \
diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker 
b/tests/docker/dockerfiles/fedora-win64-cross.docker
index 0f78711876..fef846d5a6 100644
--- a/tests/docker/dockerfiles/fedora-win64-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win64-cross.docker
@@ -1,10 +1,10 @@
 # THIS FILE WAS AUTO-GENERATED
 #
-#  $ lcitool dockerfile --layers all --cross-arch mingw64 fedora-38 
qemu,qemu-win-installer
+#  $ lcitool dockerfile --layers all --cross-arch mingw64 fedora-40 
qemu,qemu-win-installer
 #
 # https://gitlab.com/libvirt/libvirt-ci
 
-FROM registry.fedoraproject.org/fedora:38
+FROM registry.fedoraproject.org/fedora:40
 
 RUN dnf install -y nosync && \
 printf '#!/bin/sh\n\
@@ -51,6 +51,7 @@ exec "$@"\n' > /usr/bin/nosync && \
python3-pip \
python3-sphinx \
python3-sphinx_rtd_theme \
+   python3-zombie-imp \
sed \
socat \
sparse \
diff --git a/tests/docker/dockerfiles/fedora.docker 
b/tests/docker/dockerfiles/fedora.docker
index 098c894d10..44f239c088 100644
--- a/tests/docker/dockerfiles/fedora.docker
+++ b/tests/docker/dockerfiles/fedora.docker
@@ -1,10 +1,10 @@
 # THIS FILE WAS AUTO-GENERATED
 #
-#  $ lcitool dockerfile --layers all fedora-38 qemu
+#  $ lcitool dockerfile --layers all fedora-40 qemu
 #
 # https://gitlab.com/libvirt/libvirt-ci
 
-FROM registry.fedoraproject.org/fedora:38
+FROM registry.fedoraproject.org/fedora:40
 
 RUN dnf install -y nosync && \
 printf '#!/bin/sh\n\
@@ -110,6 +110,7 @@ exec "$@"\n' > /usr/bin/nosync && \
python3-pip \
python3-sphinx \
python3-sphinx_rtd_theme \
+   python3-zombie-imp \
rdma-core-devel \
sed \
snappy-devel \
diff --git a/tests/lcitool/libvirt-ci b/tests/lcitool/libvirt-ci
index cec6703971..0e9490cebc 16
--- a/tests/lcitool/libvirt-ci
+++ b/tests/lcitool/libvirt-ci
@@ -1 +1 @@
-Subproject commit cec67039719becbfbab866f9c23574f389cf9559
+Subproject commit 0e9490cebc726ef772b6c9e27dac32e7ae99f9b2
diff --git a/tests/lcitool/projects/qemu.yml b/tests/lcitool/projects/qemu.yml
index 7511ec7ccb..070d7f4706 100644
--- a/tests/lcitool/projects/qemu.yml
+++ b/tests/lcitool/projects/qemu.yml
@@ -89,6 +89,7 @@ packages:
  - pkg-config
  - pulseaudio
  - python3
+ - python3-imp
  - python3-numpy
  - python3-opencv
  - python3-pillow
diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index 789acefb75..9d8e9c6a4a 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -124,11 +124,11 @@ try:
 #
 # Standard native builds
 #
-generate_dockerfile("alpine", "alpine-318")
+generate_dockerfile("alpine", "alpine-319")
 generate_dockerfile("centos9", "centos-stream-9")
 generate_dockerfile("debian", "debian-12",
 trailer="".join(debian12_extras))
-generate_dockerfile("fedora", "fedora-38")
+generate_dockerfile("fedora", "fedora-40")
 generate_dockerfile("opensuse-leap", "opensuse-leap-15")
 generate_dockerfile("ubuntu2204", "ubuntu-2204")
 
@@ -191,7 +191,7 @@ try:
 trailer=cross_build("s390x-linux-gnu-",
 "s390x-softmmu,s390x-linux-user"))
 
-generate_dockerfile("fedora-win64-cross", "fedora-38",
+generate_dockerfile("fedora-win64-cross", "fedora-40",
 project='qemu,qemu-win-installer',
 cross="mingw64",
 trailer=cross_build("x86_64-w64-mingw32-",
-- 
2.39.2




[PULL 01/12] ci: remove centos-steam-8 customer runner

2024-06-06 Thread Alex Bennée
This broke since eef0bae3a7 (migration: Remove block migration) but
even after that was addressed it still fails to complete. As it will
shortly be EOL lets to remove the runner definition and the related
ansible setup bits.

We still have centos9 docker images build and test.

Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-2-alex.ben...@linaro.org>

diff --git a/docs/devel/ci-jobs.rst.inc b/docs/devel/ci-jobs.rst.inc
index be06322279..3756bbe355 100644
--- a/docs/devel/ci-jobs.rst.inc
+++ b/docs/devel/ci-jobs.rst.inc
@@ -182,13 +182,6 @@ If you've got access to an IBM Z host that can be used as 
a gitlab-CI
 runner, you can set this variable to enable the tests that require this
 kind of host. The runner should be tagged with "s390x".
 
-CENTOS_STREAM_8_x86_64_RUNNER_AVAILABLE
-~~~
-If you've got access to a CentOS Stream 8 x86_64 host that can be
-used as a gitlab-CI runner, you can set this variable to enable the
-tests that require this kind of host. The runner should be tagged with
-both "centos_stream_8" and "x86_64".
-
 CCACHE_DISABLE
 ~~
 The jobs are configured to use "ccache" by default since this typically
diff --git a/.gitlab-ci.d/custom-runners.yml b/.gitlab-ci.d/custom-runners.yml
index 29e52df283..1aa3c60efe 100644
--- a/.gitlab-ci.d/custom-runners.yml
+++ b/.gitlab-ci.d/custom-runners.yml
@@ -32,4 +32,3 @@ include:
   - 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/centos-stream-8-x86_64.yml 
b/.gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml
deleted file mode 100644
index 367424db78..00
--- a/.gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml
+++ /dev/null
@@ -1,24 +0,0 @@
-# All centos-stream-8 jobs should run successfully in an environment
-# setup by the scripts/ci/setup/stream/8/build-environment.yml task
-# "Installation of extra packages to build QEMU"
-
-centos-stream-8-x86_64:
- extends: .custom_runner_template
- allow_failure: true
- needs: []
- stage: build
- tags:
- - centos_stream_8
- - x86_64
- rules:
- - if: '$CI_PROJECT_NAMESPACE == "qemu-project" && $CI_COMMIT_BRANCH =~ 
/^staging/'
- - if: "$CENTOS_STREAM_8_x86_64_RUNNER_AVAILABLE"
- before_script:
- - JOBS=$(expr $(nproc) + 1)
- script:
- - mkdir build
- - cd build
- - ../scripts/ci/org.centos/stream/8/x86_64/configure
-   || { cat config.log meson-logs/meson-log.txt; exit 1; }
- - make -j"$JOBS"
- - make NINJA=":" check check-avocado
diff --git a/scripts/ci/org.centos/stream/8/build-environment.yml 
b/scripts/ci/org.centos/stream/8/build-environment.yml
deleted file mode 100644
index 1ead77e2cb..00
--- a/scripts/ci/org.centos/stream/8/build-environment.yml
+++ /dev/null
@@ -1,82 +0,0 @@

-- name: Installation of extra packages to build QEMU
-  hosts: all
-  tasks:
-- name: Extra check for CentOS Stream 8
-  lineinfile:
-path: /etc/redhat-release
-line: CentOS Stream release 8
-state: present
-  check_mode: yes
-  register: centos_stream_8
-
-- name: Enable EPEL repo on CentOS Stream 8
-  dnf:
-name:
-  - epel-release
-state: present
-  when:
-- centos_stream_8
-
-- name: Enable PowerTools repo on CentOS Stream 8
-  ini_file:
-path: /etc/yum.repos.d/CentOS-Stream-PowerTools.repo
-section: powertools
-option: enabled
-value: "1"
-  when:
-- centos_stream_8
-
-- name: Install basic packages to build QEMU on CentOS Stream 8
-  dnf:
-name:
-  - bzip2
-  - bzip2-devel
-  - capstone-devel
-  - dbus-daemon
-  - device-mapper-multipath-devel
-  - diffutils
-  - gcc
-  - gcc-c++
-  - genisoimage
-  - gettext
-  - git
-  - glib2-devel
-  - glusterfs-api-devel
-  - gnutls-devel
-  - libaio-devel
-  - libcap-ng-devel
-  - libcurl-devel
-  - libepoxy-devel
-  - libfdt-devel
-  - libgcrypt-devel
-  - libiscsi-devel
-  - libpmem-devel
-  - librados-devel
-  - librbd-devel
-  - libseccomp-devel
-  - libslirp-devel
-  - libssh-devel
-  - libxkbcommon-devel
-  - lzo-devel
-  - make
-  - mesa-libEGL-devel
-  - nettle-devel
-  - ninja-build
-  - nmap-ncat
-  - numactl-devel
-  - pixman-devel
-  - python38
-  - python3-sphinx
-  - rdma-core-devel
-  - redhat-rpm-config
-  - snappy-devel
-  - spice-glib-devel
-  - spice-server-devel
-  - systemd-devel
-  - sys

[PULL 00/12] testing cleanups (ci, vm, lcitool, ansible)

2024-06-06 Thread Alex Bennée
The following changes since commit db2feb2df8d19592c9859efb3f682404e0052957:

  Merge tag 'pull-misc-20240605' of https://gitlab.com/rth7680/qemu into 
staging (2024-06-05 14:17:01 -0700)

are available in the Git repository at:

  https://gitlab.com/stsquad/qemu.git tags/pull-maintainer-june24-060624-1

for you to fetch changes up to c99064d03fc574254ab098562798c937a4761161:

  scripts/ci: drive ubuntu/build-environment.yml from lcitool (2024-06-06 
10:26:22 +0100)


testing cleanups (ci, vm, lcitool, ansible):

  - clean up left over Centos 8 references
  - use -fno-sanitize=function to avoid non-useful errors
  - bump lcitool and update images (alpine, fedora)
  - make sure we have mingw-w64-tools for windows builds
  - drive ansible scripts with lcitool package lists


Alex Bennée (8):
  ci: remove centos-steam-8 customer runner
  docs/devel: update references to centos to non-versioned container
  tests/vm: update centos.aarch64 image to 9
  tests/vm: remove plain centos image
  scripts/ci: remove CentOS bits from common build-environment
  docs/ci: clean-up references for consistency
  tests/lcitool: generate package lists for ansible
  scripts/ci: drive ubuntu/build-environment.yml from lcitool

Thomas Huth (4):
  tests/lcitool: Delete obsolete centos-stream-8.yml file
  .gitlab-ci.d/buildtest.yml: Use -fno-sanitize=function in the 
clang-system job
  tests/lcitool: Bump to latest libvirt-ci and update Fedora and Alpine 
version
  tests/lcitool: Install mingw-w64-tools for the Windows cross-builds

 docs/devel/ci-jobs.rst.inc |   7 -
 docs/devel/ci-runners.rst.inc  |  13 +-
 docs/devel/testing.rst |   8 +-
 .gitlab-ci.d/buildtest.yml |   1 +
 .gitlab-ci.d/custom-runners.yml|   1 -
 .../custom-runners/centos-stream-8-x86_64.yml  |  24 --
 .../custom-runners/ubuntu-22.04-aarch32.yml|   2 +-
 .../custom-runners/ubuntu-22.04-aarch64.yml|   2 +-
 .gitlab-ci.d/custom-runners/ubuntu-22.04-s390x.yml |   2 +-
 .../ci/org.centos/stream/8/build-environment.yml   |  82 --
 scripts/ci/org.centos/stream/8/x86_64/configure| 198 --
 scripts/ci/org.centos/stream/8/x86_64/test-avocado |  65 -
 scripts/ci/org.centos/stream/README|  17 --
 scripts/ci/setup/build-environment.yml | 284 -
 scripts/ci/setup/ubuntu/build-environment.yml  |  69 +
 scripts/ci/setup/ubuntu/ubuntu-2204-aarch64.yaml   | 127 +
 .../ci/setup/ubuntu/ubuntu-2204-armhf-cross.yml| 127 +
 scripts/ci/setup/ubuntu/ubuntu-2204-s390x.yaml | 125 +
 tests/docker/dockerfiles/alpine.docker |   4 +-
 tests/docker/dockerfiles/fedora-win64-cross.docker |   6 +-
 tests/docker/dockerfiles/fedora.docker |   5 +-
 tests/lcitool/libvirt-ci   |   2 +-
 tests/lcitool/projects/qemu-win-installer.yml  |   1 +
 tests/lcitool/projects/qemu.yml|   1 +
 tests/lcitool/refresh  |  22 +-
 tests/lcitool/targets/centos-stream-8.yml  |   3 -
 tests/vm/Makefile.include  |   1 -
 tests/vm/centos|  51 
 tests/vm/centos.aarch64|  10 +-
 29 files changed, 497 insertions(+), 763 deletions(-)
 delete mode 100644 .gitlab-ci.d/custom-runners/centos-stream-8-x86_64.yml
 delete mode 100644 scripts/ci/org.centos/stream/8/build-environment.yml
 delete mode 100755 scripts/ci/org.centos/stream/8/x86_64/configure
 delete mode 100755 scripts/ci/org.centos/stream/8/x86_64/test-avocado
 delete mode 100644 scripts/ci/org.centos/stream/README
 delete mode 100644 scripts/ci/setup/build-environment.yml
 create mode 100644 scripts/ci/setup/ubuntu/build-environment.yml
 create mode 100644 scripts/ci/setup/ubuntu/ubuntu-2204-aarch64.yaml
 create mode 100644 scripts/ci/setup/ubuntu/ubuntu-2204-armhf-cross.yml
 create mode 100644 scripts/ci/setup/ubuntu/ubuntu-2204-s390x.yaml
 delete mode 100644 tests/lcitool/targets/centos-stream-8.yml
 delete mode 100755 tests/vm/centos

-- 
2.39.2




[PULL 12/12] scripts/ci: drive ubuntu/build-environment.yml from lcitool

2024-06-06 Thread Alex Bennée
Now lcitool can write the package list for us we no longer need to
duplicate the information directly in build-environment.

Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-13-alex.ben...@linaro.org>

diff --git a/scripts/ci/setup/ubuntu/build-environment.yml 
b/scripts/ci/setup/ubuntu/build-environment.yml
index e82097b465..edf1900b3e 100644
--- a/scripts/ci/setup/ubuntu/build-environment.yml
+++ b/scripts/ci/setup/ubuntu/build-environment.yml
@@ -32,135 +32,18 @@
   when:
 - ansible_facts['distribution'] == 'Ubuntu'
 
-# lcitool variables -f json ubuntu-2204 qemu | jq -r '.pkgs[]' | xargs -n 
1 echo "-"
-- name: Install basic packages to build QEMU on Ubuntu 22.04
-  package:
-name:
-  - bash
-  - bc
-  - bison
-  - bsdextrautils
-  - bzip2
-  - ca-certificates
-  - ccache
-  - clang
-  - dbus
-  - debianutils
-  - diffutils
-  - exuberant-ctags
-  - findutils
-  - flex
-  - g++
-  - gcc
-  - gcovr
-  - genisoimage
-  - gettext
-  - git
-  - hostname
-  - libaio-dev
-  - libasan5
-  - libasound2-dev
-  - libattr1-dev
-  - libbpf-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
-  - 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
-  - libpng-dev
-  - libpulse-dev
-  - librbd-dev
-  - librdmacm-dev
-  - libsasl2-dev
-  - libsdl2-dev
-  - libsdl2-image-dev
-  - libseccomp-dev
-  - libslirp-dev
-  - libsnappy-dev
-  - libspice-protocol-dev
-  - libssh-dev
-  - libsystemd-dev
-  - libtasn1-6-dev
-  - libubsan1
-  - libudev-dev
-  - liburing-dev
-  - libusb-1.0-0-dev
-  - libusbredirhost-dev
-  - libvdeplug-dev
-  - libvirglrenderer-dev
-  - libvte-2.91-dev
-  - libxml2-dev
-  - libzstd-dev
-  - llvm
-  - locales
-  - make
-  - meson
-  - multipath-tools
-  - ncat
-  - nettle-dev
-  - ninja-build
-  - openssh-client
-  - pkgconf
-  - python3
-  - python3-numpy
-  - python3-opencv
-  - python3-pillow
-  - python3-pip
-  - python3-sphinx
-  - python3-sphinx-rtd-theme
-  - python3-venv
-  - python3-yaml
-  - rpm2cpio
-  - sed
-  - sparse
-  - systemtap-sdt-dev
-  - tar
-  - tesseract-ocr
-  - tesseract-ocr-eng
-  - texinfo
-  - xfslibs-dev
-  - zlib1g-dev
-state: present
+# the package lists are updated by "make lcitool-refresh"
+- name: Include package lists based on OS and architecture
+  include_vars:
+file: "ubuntu-2204-{{ ansible_facts['architecture'] }}.yaml"
   when:
 - ansible_facts['distribution'] == 'Ubuntu'
 - ansible_facts['distribution_version'] == '22.04'
+- ansible_facts['architecture'] == 'aarch64' or 
ansible_facts['architecture'] == 'x86_64'
 
-# not all packages are available for all architectures
-- name: Install additional packages to build QEMU on Ubuntu 22.04
+- name: Install packages for QEMU on Ubuntu 22.04
   package:
-name:
-  - libpmem-dev
-  - libspice-server-dev
-  - libxen-dev
-state: present
+name: "{{ packages }}"
   when:
 - ansible_facts['distribution'] == 'Ubuntu'
 - ansible_facts['distribution_version'] == '22.04'
-- 
2.39.2




[PULL 11/12] tests/lcitool: generate package lists for ansible

2024-06-06 Thread Alex Bennée
With the new ability to output YAML we can build the package list for
our ansible setup scripts. We will integrate them in the next commit.

Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-12-alex.ben...@linaro.org>

diff --git a/scripts/ci/setup/ubuntu/ubuntu-2204-aarch64.yaml 
b/scripts/ci/setup/ubuntu/ubuntu-2204-aarch64.yaml
new file mode 100644
index 00..8d7d8725fb
--- /dev/null
+++ b/scripts/ci/setup/ubuntu/ubuntu-2204-aarch64.yaml
@@ -0,0 +1,127 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool variables --host-arch aarch64 ubuntu-2204 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
+packages:
+  - bash
+  - bc
+  - bison
+  - bsdextrautils
+  - bzip2
+  - ca-certificates
+  - ccache
+  - clang
+  - dbus
+  - debianutils
+  - diffutils
+  - exuberant-ctags
+  - findutils
+  - flex
+  - gcc
+  - gcovr
+  - gettext
+  - git
+  - hostname
+  - libaio-dev
+  - libasan6
+  - libasound2-dev
+  - libattr1-dev
+  - libbpf-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
+  - libpipewire-0.3-dev
+  - libpixman-1-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
+  - liburing-dev
+  - libusb-1.0-0-dev
+  - libusbredirhost-dev
+  - libvdeplug-dev
+  - libvirglrenderer-dev
+  - libvte-2.91-dev
+  - libxen-dev
+  - libzstd-dev
+  - llvm
+  - locales
+  - make
+  - meson
+  - mtools
+  - multipath-tools
+  - ncat
+  - nettle-dev
+  - ninja-build
+  - openssh-client
+  - pkgconf
+  - python3
+  - python3-numpy
+  - python3-opencv
+  - python3-pillow
+  - python3-pip
+  - python3-sphinx
+  - python3-sphinx-rtd-theme
+  - python3-tomli
+  - python3-venv
+  - python3-yaml
+  - rpm2cpio
+  - sed
+  - socat
+  - sparse
+  - swtpm
+  - systemtap-sdt-dev
+  - tar
+  - tesseract-ocr
+  - tesseract-ocr-eng
+  - xorriso
+  - zlib1g-dev
+  - zstd
+
diff --git a/scripts/ci/setup/ubuntu/ubuntu-2204-armhf-cross.yml 
b/scripts/ci/setup/ubuntu/ubuntu-2204-armhf-cross.yml
new file mode 100644
index 00..0cc34cd10b
--- /dev/null
+++ b/scripts/ci/setup/ubuntu/ubuntu-2204-armhf-cross.yml
@@ -0,0 +1,127 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool variables --cross-arch armv7l ubuntu-2204 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
+packages:
+  - bash
+  - bc
+  - bison
+  - bsdextrautils
+  - bzip2
+  - ca-certificates
+  - ccache
+  - dbus
+  - debianutils
+  - diffutils
+  - exuberant-ctags
+  - findutils
+  - flex
+  - gcc
+  - gcovr
+  - gettext
+  - git
+  - hostname
+  - libglib2.0-dev
+  - libpcre2-dev
+  - libsndio-dev
+  - libspice-protocol-dev
+  - llvm
+  - locales
+  - make
+  - meson
+  - mtools
+  - ncat
+  - ninja-build
+  - openssh-client
+  - pkgconf
+  - python3
+  - python3-numpy
+  - python3-opencv
+  - python3-pillow
+  - python3-pip
+  - python3-sphinx
+  - python3-sphinx-rtd-theme
+  - python3-tomli
+  - python3-venv
+  - python3-yaml
+  - rpm2cpio
+  - sed
+  - socat
+  - sparse
+  - swtpm
+  - tar
+  - tesseract-ocr
+  - tesseract-ocr-eng
+  - xorriso
+  - zstd
+  - gcc-arm-linux-gnueabihf
+  - libaio-dev:armhf
+  - libasan6:armhf
+  - libasound2-dev:armhf
+  - libattr1-dev:armhf
+  - libbpf-dev:armhf
+  - libbrlapi-dev:armhf
+  - libbz2-dev:armhf
+  - libc6-dev:armhf
+  - libcacard-dev:armhf
+  - libcap-ng-dev:armhf
+  - libcapstone-dev:armhf
+  - libcmocka-dev:armhf
+  - libcurl4-gnutls-dev:armhf
+  - libdaxctl-dev:armhf
+  - libdrm-dev:armhf
+  - libepoxy-dev:armhf
+  - libfdt-dev:armhf
+  - libffi-dev:armhf
+  - libfuse3-dev:armhf
+  - libgbm-dev:armhf
+  - libgcrypt20-dev:armhf
+  - libglib2.0-dev:armhf
+  - libglusterfs-dev:armhf
+  - libgnutls28-dev:armhf
+  - libgtk-3-dev:armhf
+  - libibumad-dev:armhf
+  - libibverbs-dev:armhf
+  - libiscsi-dev:armhf
+  - libjemalloc-dev:armhf
+  - libjpeg-turbo8-dev:armhf
+  - libjson-c-dev:armhf
+  - liblttng-ust-dev:armhf
+  - liblzo2-dev:armhf
+  - libncursesw5-dev:armhf
+  - libnfs-dev:armhf
+  - libnuma-dev:armhf
+  - libpam0g-dev:armhf
+  - libpipewire-0.3-dev:armhf
+  - libpixman-1-dev:armhf
+  - libpng-dev:armhf
+  - libpulse-dev:armhf
+  - librbd-dev:armhf
+  - librdmacm-dev:armhf
+  - libsasl2-dev:armhf
+  - libsdl2-dev:armhf

[PULL 10/12] tests/lcitool: Install mingw-w64-tools for the Windows cross-builds

2024-06-06 Thread Alex Bennée
From: Thomas Huth 

Beside g++ we also need the mingw-w64-tools for properly building
the code in qga/vss-win32/ , so let's install that package now, too.

Signed-off-by: Thomas Huth 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Daniel P. Berrangé 
Message-Id: <20240601070543.37786-5-th...@redhat.com>
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-11-alex.ben...@linaro.org>

diff --git a/tests/docker/dockerfiles/fedora-win64-cross.docker 
b/tests/docker/dockerfiles/fedora-win64-cross.docker
index fef846d5a6..007e1574bd 100644
--- a/tests/docker/dockerfiles/fedora-win64-cross.docker
+++ b/tests/docker/dockerfiles/fedora-win64-cross.docker
@@ -75,6 +75,7 @@ ENV NINJA "/usr/bin/ninja"
 ENV PYTHON "/usr/bin/python3"
 
 RUN nosync dnf install -y \
+   mingw-w64-tools \
mingw32-nsis \
mingw64-SDL2 \
mingw64-SDL2_image \
diff --git a/tests/lcitool/projects/qemu-win-installer.yml 
b/tests/lcitool/projects/qemu-win-installer.yml
index 86aa22297c..f3663ba030 100644
--- a/tests/lcitool/projects/qemu-win-installer.yml
+++ b/tests/lcitool/projects/qemu-win-installer.yml
@@ -2,3 +2,4 @@
 ---
 packages:
  - g++
+ - mingw-w64-tools
-- 
2.39.2




[PULL 03/12] tests/vm: update centos.aarch64 image to 9

2024-06-06 Thread Alex Bennée
As Centos Stream 8 goes out of support we need to update. To do this
powertools is replaced by crb and we don't over specify the python3 we
want.

Reviewed-by: Richard Henderson 
Reviewed-by: Thomas Huth 
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-4-alex.ben...@linaro.org>

diff --git a/tests/vm/centos.aarch64 b/tests/vm/centos.aarch64
index 3f58de1e64..fcf9e08c87 100755
--- a/tests/vm/centos.aarch64
+++ b/tests/vm/centos.aarch64
@@ -25,9 +25,9 @@ DEFAULT_CONFIG = {
 'cpu'  : "max",
 'machine'  : "virt,gic-version=max",
 'install_cmds' : (
-"dnf config-manager --set-enabled powertools, "
+"dnf config-manager --enable crb, "
 "dnf config-manager 
--add-repo=https://download.docker.com/linux/centos/docker-ce.repo, "
-"dnf install -y make ninja-build git python38 gcc gcc-c++ flex bison "\
+"dnf install -y make ninja-build git python3 gcc gcc-c++ flex bison "\
 "glib2-devel pixman-devel zlib-devel docker-ce.aarch64, "
 "systemctl enable docker, "
 ),
@@ -38,10 +38,10 @@ DEFAULT_CONFIG = {
 
 
 class CentosAarch64VM(basevm.BaseVM):
-name = "centos8.aarch64"
+name = "centos9.aarch64"
 arch = "aarch64"
-image_name = "CentOS-Stream-GenericCloud-8-20220125.1.aarch64.qcow2"
-image_link = "https://cloud.centos.org/centos/8-stream/aarch64/images/";
+image_name = "CentOS-Stream-GenericCloud-9-20230501.0.aarch64.qcow2"
+image_link = "https://cloud.centos.org/centos/9-stream/aarch64/images/";
 image_link += image_name
 BUILD_SCRIPT = """
 set -e;
-- 
2.39.2




[PULL 07/12] tests/lcitool: Delete obsolete centos-stream-8.yml file

2024-06-06 Thread Alex Bennée
From: Thomas Huth 

We've missed to delete this file when removing support for CentOS 8.
Since the current upstream version of the lcitool removed support
for CentOS 8 now, too, we have to remove the file before updating.

Signed-off-by: Thomas Huth 
Reviewed-by: Daniel P. Berrangé 
Message-Id: <20240601070543.37786-2-th...@redhat.com>
Signed-off-by: Alex Bennée 
Message-Id: <20240603175328.3823123-8-alex.ben...@linaro.org>

diff --git a/tests/lcitool/targets/centos-stream-8.yml 
b/tests/lcitool/targets/centos-stream-8.yml
deleted file mode 100644
index 6b11160fd1..00
--- a/tests/lcitool/targets/centos-stream-8.yml
+++ /dev/null
@@ -1,3 +0,0 @@
-paths:
-  pip3: /usr/bin/pip3.8
-  python: /usr/bin/python3.8
-- 
2.39.2




Re: [PATCH v2 1/3] hw/dma: Enhance error handling in loading description

2024-06-06 Thread Edgar E. Iglesias
On Tue, Jun 4, 2024 at 9:10 AM Fea.Wang  wrote:

> Loading a description from memory may cause a bus-error. In this
> case, the DMA should stop working, set the error flag, and return
> the failure value.
>
> When calling the loading a description function, it should be noticed
> that the function may return a failure value. Breaking the loop in this
> case is one of the possible ways to handle it.
>
> Signed-off-by: Fea.Wang 
> Reviewed-by: Frank Chang 
>

Thanks!
Reviewed-by: Edgar E. Iglesias 



---
>  hw/dma/xilinx_axidma.c | 30 ++
>  1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/hw/dma/xilinx_axidma.c b/hw/dma/xilinx_axidma.c
> index 0ae056ed06..ad307994c2 100644
> --- a/hw/dma/xilinx_axidma.c
> +++ b/hw/dma/xilinx_axidma.c
> @@ -71,8 +71,11 @@ enum {
>  enum {
>  DMASR_HALTED = 1,
>  DMASR_IDLE  = 2,
> +DMASR_SLVERR = 1 << 5,
> +DMASR_DECERR = 1 << 6,
>  DMASR_IOC_IRQ  = 1 << 12,
>  DMASR_DLY_IRQ  = 1 << 13,
> +DMASR_ERR_IRQ  = 1 << 14,
>
>  DMASR_IRQ_MASK = 7 << 12
>  };
> @@ -190,17 +193,32 @@ static inline int streamid_from_addr(hwaddr addr)
>  return sid;
>  }
>
> -static void stream_desc_load(struct Stream *s, hwaddr addr)
> +static MemTxResult stream_desc_load(struct Stream *s, hwaddr addr)
>  {
>  struct SDesc *d = &s->desc;
>
> -address_space_read(&s->dma->as, addr, MEMTXATTRS_UNSPECIFIED, d,
> sizeof *d);
> +MemTxResult result = address_space_read(&s->dma->as,
> +addr, MEMTXATTRS_UNSPECIFIED,
> +d, sizeof *d);
> +if (result != MEMTX_OK) {
> +if (result == MEMTX_DECODE_ERROR) {
> +s->regs[R_DMASR] |= DMASR_DECERR;
> +} else {
> +s->regs[R_DMASR] |= DMASR_SLVERR;
> +}
> +
> +s->regs[R_DMACR] &= ~DMACR_RUNSTOP;
> +s->regs[R_DMASR] |= DMASR_HALTED;
> +s->regs[R_DMASR] |= DMASR_ERR_IRQ;
> +return result;
> +}
>
>  /* Convert from LE into host endianness.  */
>  d->buffer_address = le64_to_cpu(d->buffer_address);
>  d->nxtdesc = le64_to_cpu(d->nxtdesc);
>  d->control = le32_to_cpu(d->control);
>  d->status = le32_to_cpu(d->status);
> +return result;
>  }
>
>  static void stream_desc_store(struct Stream *s, hwaddr addr)
> @@ -279,7 +297,9 @@ static void stream_process_mem2s(struct Stream *s,
> StreamSink *tx_data_dev,
>  }
>
>  while (1) {
> -stream_desc_load(s, s->regs[R_CURDESC]);
> +if (MEMTX_OK != stream_desc_load(s, s->regs[R_CURDESC])) {
> +break;
> +}
>
>  if (s->desc.status & SDESC_STATUS_COMPLETE) {
>  s->regs[R_DMASR] |= DMASR_HALTED;
> @@ -336,7 +356,9 @@ static size_t stream_process_s2mem(struct Stream *s,
> unsigned char *buf,
>  }
>
>  while (len) {
> -stream_desc_load(s, s->regs[R_CURDESC]);
> +if (MEMTX_OK != stream_desc_load(s, s->regs[R_CURDESC])) {
> +break;
> +}
>
>  if (s->desc.status & SDESC_STATUS_COMPLETE) {
>  s->regs[R_DMASR] |= DMASR_HALTED;
> --
> 2.34.1
>
>


Re: [PATCH RFC] hw/arm/virt: Avoid unexpected warning from Linux guest on host with Fujitsu CPUs

2024-06-06 Thread Peter Maydell
On Thu, 6 Jun 2024 at 11:48, Zhenyu Zhang  wrote:
>
> Multiple warning messages and corresponding backtraces are observed when Linux
> guest is booted on the host with Fujitsu CPUs. One of them is shown as below.
>
> [0.032443] [ cut here ]
> [0.032446] uart-pl011 900.pl011: ARCH_DMA_MINALIGN smaller than 
> CTR_EL0.CWG (128 < 256)
> [0.032454] WARNING: CPU: 0 PID: 1 at arch/arm64/mm/dma-mapping.c:54 
> arch_setup_dma_ops+0xbc/0xcc
> [0.032470] Modules linked in:
> [0.032475] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> 5.14.0-452.el9.aarch64 #1
> [0.032481] Hardware name: linux,dummy-virt (DT)
> [0.032484] pstate: 6045 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [0.032490] pc : arch_setup_dma_ops+0xbc/0xcc
> [0.032496] lr : arch_setup_dma_ops+0xbc/0xcc
> [0.032501] sp : 80008003b860
> [0.032503] x29: 80008003b860 x28:  x27: 
> aae4b949049c
> [0.032510] x26:  x25:  x24: 
> 
> [0.032517] x23: 0100 x22:  x21: 
> 
> [0.032523] x20: 0001 x19: 2f06c02ea400 x18: 
> 
> [0.032529] x17: 208a5f76 x16: 6589dbcb x15: 
> aae4ba071c89
> [0.032535] x14:  x13: aae4ba071c84 x12: 
> 455f525443206e61
> [0.032541] x11: 68742072656c6c61 x10: 0029 x9 : 
> aae4b7d21da4
> [0.032547] x8 : 0029 x7 : 4c414e494d5f414d x6 : 
> 0029
> [0.032553] x5 : 000f x4 : aae4b9617a00 x3 : 
> 0001
> [0.032558] x2 :  x1 :  x0 : 
> 2f06c029be40
> [0.032564] Call trace:
> [0.032566]  arch_setup_dma_ops+0xbc/0xcc
> [0.032572]  of_dma_configure_id+0x138/0x300
> [0.032591]  amba_dma_configure+0x34/0xc0
> [0.032600]  really_probe+0x78/0x3dc
> [0.032614]  __driver_probe_device+0x108/0x160
> [0.032619]  driver_probe_device+0x44/0x114
> [0.032624]  __device_attach_driver+0xb8/0x14c
> [0.032629]  bus_for_each_drv+0x88/0xe4
> [0.032634]  __device_attach+0xb0/0x1e0
> [0.032638]  device_initial_probe+0x18/0x20
> [0.032643]  bus_probe_device+0xa8/0xb0
> [0.032648]  device_add+0x4b4/0x6c0
> [0.032652]  amba_device_try_add.part.0+0x48/0x360
> [0.032657]  amba_device_add+0x104/0x144
> [0.032662]  of_amba_device_create.isra.0+0x100/0x1c4
> [0.032666]  of_platform_bus_create+0x294/0x35c
> [0.032669]  of_platform_populate+0x5c/0x150
> [0.032672]  of_platform_default_populate_init+0xd0/0xec
> [0.032697]  do_one_initcall+0x4c/0x2e0
> [0.032701]  do_initcalls+0x100/0x13c
> [0.032707]  kernel_init_freeable+0x1c8/0x21c
> [0.032712]  kernel_init+0x28/0x140
> [0.032731]  ret_from_fork+0x10/0x20
> [0.032735] ---[ end trace  ]---
>
> In Linux, a check is applied to every device which is exposed through 
> device-tree
> node. The warning message is raised when the device isn't DMA coherent and the
> cache line size is larger than ARCH_DMA_MINALIGN (128 bytes). The cache line 
> is
> sorted from CTR_EL0[CWG], which corresponds to 256 bytes on the guest CPUs.
> The DMA coherent capability is claimed through 'dma-coherent' in their
> device-tree nodes.

For QEMU emulated all our DMA is always coherent, so where we
have DMA-capable devices we should definitely tell the kernel
that that DMA is coherent.

Our pl011 does not do DMA, though (we do not set the dmas property), so
it's kind of bogus for the kernel to complain about that.

So I think we should take these changes where they refer to DMA
capable devices and ask the kernel folks to fix the warnings
where they refer to devices that aren't doing DMA. Looking through
the patch, though, my initial impression is that all these are
in the latter category...

> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> index d480a7da02..cdf99966e6 100644
> --- a/hw/arm/boot.c
> +++ b/hw/arm/boot.c
> @@ -509,6 +509,7 @@ static void fdt_add_psci_node(void *fdt)
>  qemu_fdt_setprop_cell(fdt, "/psci", "cpu_off", cpu_off_fn);
>  qemu_fdt_setprop_cell(fdt, "/psci", "cpu_on", cpu_on_fn);
>  qemu_fdt_setprop_cell(fdt, "/psci", "migrate", migrate_fn);
> +qemu_fdt_setprop(fdt, "/psci", "dma-coherent", NULL, 0);

The PSCI node is describing the firmware interface for
HVC or SMC calls -- I don't think it makes any sense
to think of this as doing DMA. So I would query the kernel
folks about this warning.

>  }
>
>  int arm_load_dtb(hwaddr addr, const struct arm_boot_info *binfo,
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 3c93c0c0a6..d3e5f512e2 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -652,6 +652,7 @@ static void fdt_add_pmu_nodes(const VirtMachineState *vms)
>  qemu_fdt_setprop_cells(ms->fdt, "/pmu", "interrupts",
> GIC_FDT_IRQ_TYPE_PPI,
>  

Re: [PATCH] target/s390x: Fix tracing header path in TCG mem_helper.c

2024-06-06 Thread Ilya Leoshkevich
On Thu, 2024-06-06 at 12:30 +0200, Philippe Mathieu-Daudé wrote:
> Commit c9274b6bf0 ("target/s390x: start moving TCG-only code
> to tcg/") moved mem_helper.c, but the trace-events file is
> still in the parent directory, so is the generated trace.h.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Ideally we should only use trace events from current directory.
> ---
>  target/s390x/tcg/mem_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Ilya Leoshkevich 



Re: [PATCH] hw/net: cadence_gem: fix: type2_compare_x_word_0 error

2024-06-06 Thread Peter Maydell
On Thu, 6 Jun 2024 at 12:04, Edgar E. Iglesias  wrote:
>
> On Thu, Jun 6, 2024 at 12:00 PM Andrew.Yuan  
> wrote:
>>
>> In the Cadence IP for Gigabit Ethernet MAC Part Number: IP7014 IP 
>> Rev: R1p12 - Doc Rev: 1.3 User Guide, the specification for the 
>> type2_compare_x_word_0 register is as follows:
>> The byte stored in bits [23:16] is compared against the byte in the 
>> received frame from the selected offset+0, and the byte stored in bits 
>> [31:24] is compared against the byte in
>> the received frame from the selected offset+1.
>>
>> However, there is an implementation error in the cadence_gem model 
>> in qemu:
>> the byte stored in bits [31:24] is compared against the byte in the 
>> received frame from the selected offset+0
>>
>> Now, the error code is as follows:
>> rx_cmp = rxbuf_ptr[offset] << 8 | rxbuf_ptr[offset];
>>
>> and needs to be corrected to:
>> rx_cmp = rxbuf_ptr[offset + 1] << 8 | rxbuf_ptr[offset];
>>
>> Signed-off-by: Andrew.Yuan 
>
>
>
> LGTM:
> Reviewed-by: Edgar E. Iglesias 
>
> At some point it would be nice to add the missing logic for the DISABLE_MASK 
> bit that
> extends the compare range from 16 to 32-bits.

I had a look at this device's code, and I'm trying to
figure out how we know at this point that there really are
two bytes pointed to by rxbuf_ptr.
 * The get_queue_from_screen() function takes a rxbufsize
   argument, but it never uses it...
 * the callsite in gem_receive() will (in the "strip FCS" case)
   pass its buf argument as rxbuf_ptr, but it will use a
   rxbufsize argument which has been raised to at least
   GEM_DMACFG_RBUFSZ_MUL, even if the input size argument
   is smaller, so even if get_queue_from_screen() honoured
   its rxbufsize argument it wouldn't help

Would somebody who understands the device like to have a look ?

This is a separate issue from the incorrect array offset
argument this patch fixes, though.

thanks
-- PMM



Re: [PATCH] target/s390x: Fix tracing header path in TCG mem_helper.c

2024-06-06 Thread Peter Maydell
On Thu, 6 Jun 2024 at 11:30, Philippe Mathieu-Daudé  wrote:
>
> Commit c9274b6bf0 ("target/s390x: start moving TCG-only code
> to tcg/") moved mem_helper.c, but the trace-events file is
> still in the parent directory, so is the generated trace.h.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> Ideally we should only use trace events from current directory.

Mmm, I was wondering if maybe that would be the better approach.

A quick grep suggests the only other place doing a "../trace.h"
include is in include/hw/xen/interface/hvm/hvm_op.h, which is
unrelated, because it's pulling in the non-autogenerated
include/hw/xen/interface/trace.h.

-- PMM



[PATCH v5 5/5] target/ppc: Fix regression due to Power10 and Power11 having same PCR

2024-06-06 Thread Aditya Gupta
Power11 has the same PCR (Processor Compatibility Register) value, as
Power10.

Due to this, QEMU considers Power11 as a valid compat-mode for Power10,
ie. earlier it was possible to run QEMU with '-M 
pseries,max-compat-mode=power11 --cpu power10'

Same PCR also introduced a regression where `-M pseries --cpu power10`
boots as Power11 (ie. logical PVR is of Power11, even though PVR is Power10).
The regression was due to 'do_client_architecture_support' checking for
valid compat modes and finding Power11 to be a valid compat mode for
Power10 (it happens even without passing 'max-compat-mode' explicitly).

Fix compat-mode issue and regression, by ensuring a future Power
processor (with a higher logical_pvr value, eg. P11) cannot be valid
compat-mode for an older Power processor (eg. P10)

Cc: Cédric Le Goater 
Cc: Daniel Henrique Barboza 
Cc: Harsh Prateek Bora 
Cc: Mahesh J Salgaonkar 
Cc: Madhavan Srinivasan 
Cc: Nicholas Piggin 
Signed-off-by: Aditya Gupta 
---
 target/ppc/compat.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/ppc/compat.c b/target/ppc/compat.c
index 12dd8ae290ca..168a3c06316f 100644
--- a/target/ppc/compat.c
+++ b/target/ppc/compat.c
@@ -139,6 +139,10 @@ static bool pcc_compat(PowerPCCPUClass *pcc, uint32_t 
compat_pvr,
 /* Outside specified range */
 return false;
 }
+if (compat->pvr > pcc->logical_pvr) {
+/* Older CPU cannot support a newer processor's compat mode */
+return false;
+}
 if (!(pcc->pcr_supported & compat->pcr_level)) {
 /* Not supported by this CPU */
 return false;
-- 
2.45.1




[PATCH v5 1/5] target/ppc: reduce code duplication across Power9/10 init code

2024-06-06 Thread Aditya Gupta
From: Harsh Prateek Bora 

Power9/10 initialization code consists of a lot of logical OR of
various flag bits as supported by respective Power platform during its
initialization, most of which is duplicated and only selected bits are
added or removed as needed with each new platform support being added.
Remove the duplicate code and share using common macros.

Signed-off-by: Harsh Prateek Bora 
---
 target/ppc/cpu_init.c | 124 +-
 target/ppc/cpu_init.h |  78 ++
 2 files changed, 93 insertions(+), 109 deletions(-)
 create mode 100644 target/ppc/cpu_init.h

diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 01e358a4a5ac..3d8a112935ae 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -51,6 +51,7 @@
 #include "kvm_ppc.h"
 #endif
 
+#include "cpu_init.h"
 /* #define PPC_DEBUG_SPR */
 /* #define USE_APPLE_GDB */
 
@@ -6508,58 +6509,15 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
 dc->fw_name = "PowerPC,POWER9";
 dc->desc = "POWER9";
 pcc->pvr_match = ppc_pvr_match_power9;
-pcc->pcr_mask = PCR_COMPAT_2_05 | PCR_COMPAT_2_06 | PCR_COMPAT_2_07;
-pcc->pcr_supported = PCR_COMPAT_3_00 | PCR_COMPAT_2_07 | PCR_COMPAT_2_06 |
- PCR_COMPAT_2_05;
+pcc->pcr_mask = POWERPC_POWER9_PCC_PCR_MASK;
+pcc->pcr_supported = POWERPC_POWER9_PCC_PCR_SUPPORTED;
 pcc->init_proc = init_proc_POWER9;
 pcc->check_pow = check_pow_nocheck;
 pcc->check_attn = check_attn_hid0_power9;
-pcc->insns_flags = PPC_INSNS_BASE | PPC_ISEL | PPC_STRING | PPC_MFTB |
-   PPC_FLOAT | PPC_FLOAT_FSEL | PPC_FLOAT_FRES |
-   PPC_FLOAT_FSQRT | PPC_FLOAT_FRSQRTE |
-   PPC_FLOAT_FRSQRTES |
-   PPC_FLOAT_STFIWX |
-   PPC_FLOAT_EXT |
-   PPC_CACHE | PPC_CACHE_ICBI | PPC_CACHE_DCBZ |
-   PPC_MEM_SYNC | PPC_MEM_EIEIO |
-   PPC_MEM_TLBIE | PPC_MEM_TLBSYNC |
-   PPC_64B | PPC_64H | PPC_64BX | PPC_ALTIVEC |
-   PPC_SEGMENT_64B | PPC_SLBI |
-   PPC_POPCNTB | PPC_POPCNTWD |
-   PPC_CILDST;
-pcc->insns_flags2 = PPC2_VSX | PPC2_VSX207 | PPC2_DFP | PPC2_DBRX |
-PPC2_PERM_ISA206 | PPC2_DIVE_ISA206 |
-PPC2_ATOMIC_ISA206 | PPC2_FP_CVT_ISA206 |
-PPC2_FP_TST_ISA206 | PPC2_BCTAR_ISA207 |
-PPC2_LSQ_ISA207 | PPC2_ALTIVEC_207 |
-PPC2_ISA205 | PPC2_ISA207S | PPC2_FP_CVT_S64 |
-PPC2_TM | PPC2_ISA300 | PPC2_PRCNTL | PPC2_MEM_LWSYNC |
-PPC2_BCDA_ISA206;
-pcc->msr_mask = (1ull << MSR_SF) |
-(1ull << MSR_HV) |
-(1ull << MSR_TM) |
-(1ull << MSR_VR) |
-(1ull << MSR_VSX) |
-(1ull << MSR_EE) |
-(1ull << MSR_PR) |
-(1ull << MSR_FP) |
-(1ull << MSR_ME) |
-(1ull << MSR_FE0) |
-(1ull << MSR_SE) |
-(1ull << MSR_DE) |
-(1ull << MSR_FE1) |
-(1ull << MSR_IR) |
-(1ull << MSR_DR) |
-(1ull << MSR_PMM) |
-(1ull << MSR_RI) |
-(1ull << MSR_LE);
-pcc->lpcr_mask = LPCR_VPM1 | LPCR_ISL | LPCR_KBV | LPCR_DPFD |
-(LPCR_PECE_U_MASK & LPCR_HVEE) | LPCR_ILE | LPCR_AIL |
-LPCR_UPRT | LPCR_EVIRT | LPCR_ONL | LPCR_HR | LPCR_LD |
-(LPCR_PECE_L_MASK & (LPCR_PDEE | LPCR_HDEE | LPCR_EEE |
- LPCR_DEE | LPCR_OEE))
-| LPCR_MER | LPCR_GTSE | LPCR_TC |
-LPCR_HEIC | LPCR_LPES0 | LPCR_HVICE | LPCR_HDICE;
+pcc->insns_flags = POWERPC_FAMILY_POWER9_INSNS_FLAGS;
+pcc->insns_flags2 = POWERPC_FAMILY_POWER9_INSNS_FLAGS2;
+pcc->msr_mask = POWERPC_POWER9_PCC_MSR_MASK;
+pcc->lpcr_mask = POWERPC_POWER9_PCC_LPCR_MASK;
 pcc->lpcr_pm = LPCR_PDEE | LPCR_HDEE | LPCR_EEE | LPCR_DEE | LPCR_OEE;
 pcc->mmu_model = POWERPC_MMU_3_00;
 #if !defined(CONFIG_USER_ONLY)
@@ -6572,10 +6530,7 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
 pcc->excp_model = POWERPC_EXCP_POWER9;
 pcc->bus_model = PPC_FLAGS_INPUT_POWER9;
 pcc->bfd_mach = bfd_mach_ppc64;
-pcc->flags = POWERPC_FLAG_VRE | POWERPC_FLAG_SE |
- POWERPC_FLAG_BE | POWERPC_FLAG_PMM |
- POWERPC_FLAG_BUS_CLK | POWERPC_FLAG_CFAR |
- POWERPC_FLAG_VSX | POWERPC_FLAG_TM | POWERPC_FLAG_SCV;
+pcc->flags = POWERPC_POWER9_PCC_FLAGS;
 pcc->l1_dcache_size = 0x8000;
 pcc->l1_icache_size = 0x8000;
 }
@@ -6688,60 +6643,15 @@ POWERPC_FAMILY(POWER10)(ObjectClass *oc, void *data)
 dc->fw_name = "PowerPC,POWER10";
 dc->desc = "POWER

[PATCH v5 3/5] ppc/pseries: Add Power11 cpu type

2024-06-06 Thread Aditya Gupta
Add sPAPR CPU Core definition for Power11

Cc: David Gibson  (reviewer:sPAPR (pseries))
Cc: Harsh Prateek Bora  (reviewer:sPAPR (pseries))
Cc: Cédric Le Goater 
Cc: Daniel Henrique Barboza 
Cc: Frédéric Barrat 
Cc: Harsh Prateek Bora 
Cc: Mahesh J Salgaonkar 
Cc: Madhavan Srinivasan 
Cc: Nicholas Piggin 
Reviewed-by: Harsh Prateek Bora 
Signed-off-by: Aditya Gupta 
---
 docs/system/ppc/pseries.rst | 17 +
 hw/ppc/spapr_cpu_core.c |  1 +
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/docs/system/ppc/pseries.rst b/docs/system/ppc/pseries.rst
index a876d897b6e4..bbc51aa7fcdb 100644
--- a/docs/system/ppc/pseries.rst
+++ b/docs/system/ppc/pseries.rst
@@ -14,10 +14,19 @@ virtualization capabilities.
 Supported devices
 =
 
- * Multi processor support for many Power processors generations: POWER7,
-   POWER7+, POWER8, POWER8NVL, POWER9, and Power10. Support for POWER5+ exists,
-   but its state is unknown.
- * Interrupt Controller, XICS (POWER8) and XIVE (POWER9 and Power10)
+ * Multi processor support for many Power processors generations:
+   - POWER7, POWER7+
+   - POWER8, POWER8NVL
+   - POWER9
+   - Power10
+   - Power11
+   - Support for POWER5+ also exists, works with correct kernel/userspace
+ * Interrupt Controller
+- XICS (POWER8)
+- XIVE (Supported by below:)
+- POWER9
+- Power10
+- Power11
  * vPHB PCIe Host bridge.
  * vscsi and vnet devices, compatible with the same devices available on a
PowerVM hypervisor with VIOS managing LPARs.
diff --git a/hw/ppc/spapr_cpu_core.c b/hw/ppc/spapr_cpu_core.c
index e7c9edd033c8..62416b7e0a7e 100644
--- a/hw/ppc/spapr_cpu_core.c
+++ b/hw/ppc/spapr_cpu_core.c
@@ -401,6 +401,7 @@ static const TypeInfo spapr_cpu_core_type_infos[] = {
 DEFINE_SPAPR_CPU_CORE_TYPE("power9_v2.0"),
 DEFINE_SPAPR_CPU_CORE_TYPE("power9_v2.2"),
 DEFINE_SPAPR_CPU_CORE_TYPE("power10_v2.0"),
+DEFINE_SPAPR_CPU_CORE_TYPE("power11_v2.0"),
 #ifdef CONFIG_KVM
 DEFINE_SPAPR_CPU_CORE_TYPE("host"),
 #endif
-- 
2.45.1




[PATCH v5 0/5] Power11 support for QEMU [PSeries]

2024-06-06 Thread Aditya Gupta
Overview


Split "Power11 support for QEMU" into 2 patch series: pseries & powernv.

This patch series is for pseries support for Power11.

As Power11 core is same as Power10, hence much of the code has been reused from
Power10.

Power11 was added in Linux in:
  commit c2ed087ed35c ("powerpc: Add Power11 architected and raw mode")

Git Tree for Testing


QEMU: https://github.com/adi-g15-ibm/qemu/tree/p11-v5-pseries

Has been tested with following cases:
* '-M pseries' / '-M pseries -cpu Power11'
* '-smp' option tested
* with compat mode: 'max-cpu-compat=power10' and 'max-cpu-compat=power9'
* with/without device 'virtio-scsi-pci'
* with/without -kernel and -drive with qcow_file

Linux with Power11 support: https://github.com/torvalds/linux, since v6.9-rc1

Changelog
=
v5:
  + split patch series into pseries+powernv
  + patch #1: apply harsh's patch to reduce duplication
  + patch #2: simplified, by removing duplication
  + patch #3: update docs, according to harsh's suggestion
  + patch #4: no functional change, #define used for P9 & P10 pcr_supported
  + patch #5: no change

v4:
  + patch #5: fix memory leak in pnv_chip_power10_quad_realize
  - no change in other patches

v3:
  + patch #1: version power11 as power11_v2.0
  + patch #2: split target hw/pseries code into patch #2
  + patch #3,#4: fix regression due to Power10 and Power11 having same PCR
  + patch #5: create pnv_chip_power11_dt_populate and split 
pnv_chip_power10_common_realize as per review
  + patch #6-#11: no change
  - remove commit to make Power11 as default

v2:
  + split powernv patch into homer,lpc,occ,psi,sbe
  + reduce code duplication by reusing power10 code
  + make power11 as default
  + rebase on qemu upstream/master
  + add more information in commit descriptions
  + update docs
  + update skiboot.lid


Aditya Gupta (4):
  target/ppc: Add Power11 DD2.0 processor
  ppc/pseries: Add Power11 cpu type
  target/ppc: Introduce 'PowerPCCPUClass::logical_pvr'
  target/ppc: Fix regression due to Power10 and Power11 having same PCR

Harsh Prateek Bora (1):
  target/ppc: reduce code duplication across Power9/10 init code

 docs/system/ppc/pseries.rst |  17 +++-
 hw/ppc/spapr_cpu_core.c |   1 +
 target/ppc/compat.c |  11 +++
 target/ppc/cpu-models.c |   3 +
 target/ppc/cpu-models.h |   3 +
 target/ppc/cpu.h|   1 +
 target/ppc/cpu_init.c   | 183 +++-
 target/ppc/cpu_init.h   |  78 +++
 8 files changed, 184 insertions(+), 113 deletions(-)
 create mode 100644 target/ppc/cpu_init.h

-- 
2.45.1




[PATCH v5 4/5] target/ppc: Introduce 'PowerPCCPUClass::logical_pvr'

2024-06-06 Thread Aditya Gupta
Introduce 'PnvChipClass::logical_pvr' to know corresponding logical PVR
of a PowerPC CPU.
This helps to have a one-to-one mapping between PVR and logical PVR for
a CPU, and used in a later commit to handle cases where PCR of two
generations of Power chip is same, which causes regressions with compat-mode.

Cc: Cédric Le Goater 
Cc: Daniel Henrique Barboza 
Cc: Harsh Prateek Bora 
Cc: Mahesh J Salgaonkar 
Cc: Madhavan Srinivasan 
Cc: Nicholas Piggin 
Signed-off-by: Aditya Gupta 
---
 target/ppc/cpu.h  | 1 +
 target/ppc/cpu_init.c | 5 +
 2 files changed, 6 insertions(+)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 2015e603d4e0..ff43e3645228 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1504,6 +1504,7 @@ struct PowerPCCPUClass {
 void (*parent_parse_features)(const char *type, char *str, Error **errp);
 
 uint32_t pvr;
+uint32_t logical_pvr;
 /*
  * If @best is false, match if pcc is in the family of pvr
  * Else match only if pcc is the best match for pvr in this family.
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 9aa098935d05..50f136cca7f0 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -6152,6 +6152,7 @@ POWERPC_FAMILY(POWER7)(ObjectClass *oc, void *data)
 
 dc->fw_name = "PowerPC,POWER7";
 dc->desc = "POWER7";
+pcc->logical_pvr = CPU_POWERPC_LOGICAL_2_06_PLUS;
 pcc->pvr_match = ppc_pvr_match_power7;
 pcc->pcr_mask = PCR_VEC_DIS | PCR_VSX_DIS | PCR_COMPAT_2_05;
 pcc->pcr_supported = PCR_COMPAT_2_06 | PCR_COMPAT_2_05;
@@ -6315,6 +6316,7 @@ POWERPC_FAMILY(POWER8)(ObjectClass *oc, void *data)
 
 dc->fw_name = "PowerPC,POWER8";
 dc->desc = "POWER8";
+pcc->logical_pvr = CPU_POWERPC_LOGICAL_2_07;
 pcc->pvr_match = ppc_pvr_match_power8;
 pcc->pcr_mask = PCR_TM_DIS | PCR_COMPAT_2_06 | PCR_COMPAT_2_05;
 pcc->pcr_supported = PCR_COMPAT_2_07 | PCR_COMPAT_2_06 | PCR_COMPAT_2_05;
@@ -6508,6 +6510,7 @@ POWERPC_FAMILY(POWER9)(ObjectClass *oc, void *data)
 
 dc->fw_name = "PowerPC,POWER9";
 dc->desc = "POWER9";
+pcc->logical_pvr = CPU_POWERPC_LOGICAL_3_00;
 pcc->pvr_match = ppc_pvr_match_power9;
 pcc->pcr_mask = POWERPC_POWER9_PCC_PCR_MASK;
 pcc->pcr_supported = POWERPC_POWER9_PCC_PCR_SUPPORTED;
@@ -6642,6 +6645,7 @@ POWERPC_FAMILY(POWER10)(ObjectClass *oc, void *data)
 
 dc->fw_name = "PowerPC,POWER10";
 dc->desc = "POWER10";
+pcc->logical_pvr = CPU_POWERPC_LOGICAL_3_10;
 pcc->pvr_match = ppc_pvr_match_power10;
 pcc->pcr_mask = POWERPC_POWER10_PCC_PCR_MASK;
 pcc->pcr_supported = POWERPC_POWER10_PCC_PCR_SUPPORTED;
@@ -6696,6 +6700,7 @@ POWERPC_FAMILY(POWER11)(ObjectClass *oc, void *data)
 
 dc->fw_name = "PowerPC,POWER11";
 dc->desc = "POWER11";
+pcc->logical_pvr = CPU_POWERPC_LOGICAL_3_10_PLUS;
 pcc->pvr_match = ppc_pvr_match_power11;
 pcc->pcr_mask = POWERPC_POWER10_PCC_PCR_MASK;
 pcc->pcr_supported = POWERPC_POWER10_PCC_PCR_SUPPORTED;
-- 
2.45.1




[PATCH v5 2/5] target/ppc: Add Power11 DD2.0 processor

2024-06-06 Thread Aditya Gupta
Add CPU target code to add support for new Power11 Processor.

Power11 core is same as Power10, hence reuse functions defined for
Power10.

Cc: Cédric Le Goater 
Cc: Daniel Henrique Barboza 
Cc: Frédéric Barrat 
Cc: Harsh Prateek Bora 
Cc: Mahesh J Salgaonkar 
Cc: Madhavan Srinivasan 
Cc: Nicholas Piggin 
Signed-off-by: Aditya Gupta 
---
 target/ppc/compat.c |  7 ++
 target/ppc/cpu-models.c |  3 +++
 target/ppc/cpu-models.h |  3 +++
 target/ppc/cpu_init.c   | 54 +
 4 files changed, 67 insertions(+)

diff --git a/target/ppc/compat.c b/target/ppc/compat.c
index ebef2cccecf3..12dd8ae290ca 100644
--- a/target/ppc/compat.c
+++ b/target/ppc/compat.c
@@ -100,6 +100,13 @@ static const CompatInfo compat_table[] = {
 .pcr_level = PCR_COMPAT_3_10,
 .max_vthreads = 8,
 },
+{ /* POWER11, ISA3.10 */
+.name = "power11",
+.pvr = CPU_POWERPC_LOGICAL_3_10_PLUS,
+.pcr = PCR_COMPAT_3_10,
+.pcr_level = PCR_COMPAT_3_10,
+.max_vthreads = 8,
+},
 };
 
 static const CompatInfo *compat_by_pvr(uint32_t pvr)
diff --git a/target/ppc/cpu-models.c b/target/ppc/cpu-models.c
index f2301b43f78b..ece348178188 100644
--- a/target/ppc/cpu-models.c
+++ b/target/ppc/cpu-models.c
@@ -734,6 +734,8 @@
 "POWER9 v2.2")
 POWERPC_DEF("power10_v2.0",  CPU_POWERPC_POWER10_DD20,   POWER10,
 "POWER10 v2.0")
+POWERPC_DEF("power11_v2.0",  CPU_POWERPC_POWER11_DD20,   POWER11,
+"POWER11_v2.0")
 #endif /* defined (TARGET_PPC64) */
 
 /***/
@@ -909,6 +911,7 @@ PowerPCCPUAlias ppc_cpu_aliases[] = {
 { "power8nvl", "power8nvl_v1.0" },
 { "power9", "power9_v2.2" },
 { "power10", "power10_v2.0" },
+{ "power11", "power11_v2.0" },
 #endif
 
 /* Generic PowerPCs */
diff --git a/target/ppc/cpu-models.h b/target/ppc/cpu-models.h
index 0229ef3a9a5c..ef74e387b047 100644
--- a/target/ppc/cpu-models.h
+++ b/target/ppc/cpu-models.h
@@ -354,6 +354,8 @@ enum {
 CPU_POWERPC_POWER10_BASE   = 0x0080,
 CPU_POWERPC_POWER10_DD1= 0x00801100,
 CPU_POWERPC_POWER10_DD20   = 0x00801200,
+CPU_POWERPC_POWER11_BASE   = 0x0082,
+CPU_POWERPC_POWER11_DD20   = 0x00821200,
 CPU_POWERPC_970_v22= 0x00390202,
 CPU_POWERPC_970FX_v10  = 0x00391100,
 CPU_POWERPC_970FX_v20  = 0x003C0200,
@@ -391,6 +393,7 @@ enum {
 CPU_POWERPC_LOGICAL_2_07   = 0x0F04,
 CPU_POWERPC_LOGICAL_3_00   = 0x0F05,
 CPU_POWERPC_LOGICAL_3_10   = 0x0F06,
+CPU_POWERPC_LOGICAL_3_10_PLUS  = 0x0F07,
 };
 
 /* System version register (used on MPC 8xxx)*/
diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 3d8a112935ae..9aa098935d05 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -6669,6 +6669,60 @@ POWERPC_FAMILY(POWER10)(ObjectClass *oc, void *data)
 pcc->l1_icache_size = 0x8000;
 }
 
+static bool ppc_pvr_match_power11(PowerPCCPUClass *pcc, uint32_t pvr, bool 
best)
+{
+uint32_t base = pvr & CPU_POWERPC_POWER_SERVER_MASK;
+uint32_t pcc_base = pcc->pvr & CPU_POWERPC_POWER_SERVER_MASK;
+
+if (!best && (base == CPU_POWERPC_POWER11_BASE)) {
+return true;
+}
+
+if (base != pcc_base) {
+return false;
+}
+
+if ((pvr & 0x0f00) == (pcc->pvr & 0x0f00)) {
+return true;
+}
+
+return false;
+}
+
+POWERPC_FAMILY(POWER11)(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
+
+dc->fw_name = "PowerPC,POWER11";
+dc->desc = "POWER11";
+pcc->pvr_match = ppc_pvr_match_power11;
+pcc->pcr_mask = POWERPC_POWER10_PCC_PCR_MASK;
+pcc->pcr_supported = POWERPC_POWER10_PCC_PCR_SUPPORTED;
+pcc->init_proc = init_proc_POWER10;
+pcc->check_pow = check_pow_nocheck;
+pcc->check_attn = check_attn_hid0_power9;
+pcc->insns_flags = POWERPC_FAMILY_POWER9_INSNS_FLAGS; /* same as P9 */
+pcc->insns_flags2 = POWERPC_FAMILY_POWER10_INSNS_FLAGS2;
+pcc->msr_mask = POWERPC_POWER10_PCC_MSR_MASK;
+pcc->lpcr_mask = POWERPC_POWER10_PCC_LPCR_MASK;
+
+pcc->lpcr_pm = LPCR_PDEE | LPCR_HDEE | LPCR_EEE | LPCR_DEE | LPCR_OEE;
+pcc->mmu_model = POWERPC_MMU_3_00;
+#if !defined(CONFIG_USER_ONLY)
+/* segment page size remain the same */
+pcc->hash64_opts = &ppc_hash64_opts_POWER7;
+pcc->radix_page_info = &POWER10_radix_page_info;
+pcc->lrg_decr_bits = 56;
+#endif
+pcc->excp_model = POWERPC_EXCP_POWER10;
+pcc->bus_model = PPC_FLAGS_INPUT_POWER9;
+pcc->bfd_mach = bfd_mach_ppc64;
+pcc->flags = POWERPC_POWER10_PCC_FLAGS;
+pcc->l1_dcache_size = 0x8000;
+pcc->l1_icache_size = 0x8000;
+}
+
 #if !defined(CONFIG_USER_ONLY)
 void cpu_ppc_set_vhyp(PowerPCCPU *cpu, PPCVirtualHypervisor *vhyp)
 {
-- 
2.45.1




Re: [PATCH v5 0/5] Power11 support for QEMU [PSeries]

2024-06-06 Thread Aditya Gupta

Hello Nick & Cedric,

Based on your comments on considering the pseries for 9.1, and having to 
wait for skiboot parts for powernv, I have split the patch series into 
pseries and powernv.


There might be little delay in posting the powernv part, where I am 
still looking into having power11's instance_init.


Also, I have applied Harsh's patch that should simplify the rest of the 
patches.



Thanks,

Aditya Gupta

On 06/06/24 17:46, Aditya Gupta wrote:

Overview


Split "Power11 support for QEMU" into 2 patch series: pseries & powernv.

This patch series is for pseries support for Power11.

As Power11 core is same as Power10, hence much of the code has been reused from
Power10.

Power11 was added in Linux in:
   commit c2ed087ed35c ("powerpc: Add Power11 architected and raw mode")

Git Tree for Testing


QEMU: https://github.com/adi-g15-ibm/qemu/tree/p11-v5-pseries

Has been tested with following cases:
* '-M pseries' / '-M pseries -cpu Power11'
* '-smp' option tested
* with compat mode: 'max-cpu-compat=power10' and 'max-cpu-compat=power9'
* with/without device 'virtio-scsi-pci'
* with/without -kernel and -drive with qcow_file

Linux with Power11 support: https://github.com/torvalds/linux, since v6.9-rc1

Changelog
=
v5:
   + split patch series into pseries+powernv
   + patch #1: apply harsh's patch to reduce duplication
   + patch #2: simplified, by removing duplication
   + patch #3: update docs, according to harsh's suggestion
   + patch #4: no functional change, #define used for P9 & P10 pcr_supported
   + patch #5: no change

v4:
   + patch #5: fix memory leak in pnv_chip_power10_quad_realize
   - no change in other patches

v3:
   + patch #1: version power11 as power11_v2.0
   + patch #2: split target hw/pseries code into patch #2
   + patch #3,#4: fix regression due to Power10 and Power11 having same PCR
   + patch #5: create pnv_chip_power11_dt_populate and split 
pnv_chip_power10_common_realize as per review
   + patch #6-#11: no change
   - remove commit to make Power11 as default

v2:
   + split powernv patch into homer,lpc,occ,psi,sbe
   + reduce code duplication by reusing power10 code
   + make power11 as default
   + rebase on qemu upstream/master
   + add more information in commit descriptions
   + update docs
   + update skiboot.lid


Aditya Gupta (4):
   target/ppc: Add Power11 DD2.0 processor
   ppc/pseries: Add Power11 cpu type
   target/ppc: Introduce 'PowerPCCPUClass::logical_pvr'
   target/ppc: Fix regression due to Power10 and Power11 having same PCR

Harsh Prateek Bora (1):
   target/ppc: reduce code duplication across Power9/10 init code

  docs/system/ppc/pseries.rst |  17 +++-
  hw/ppc/spapr_cpu_core.c |   1 +
  target/ppc/compat.c |  11 +++
  target/ppc/cpu-models.c |   3 +
  target/ppc/cpu-models.h |   3 +
  target/ppc/cpu.h|   1 +
  target/ppc/cpu_init.c   | 183 +++-
  target/ppc/cpu_init.h   |  78 +++
  8 files changed, 184 insertions(+), 113 deletions(-)
  create mode 100644 target/ppc/cpu_init.h





[PATCH v5 00/10] Support persistent reservation operations

2024-06-06 Thread Changqi Lu
Hi,

patchv5 has been modified. 

Sincerely hope that everyone can help review the
code and provide some suggestions.

v4->v5:
- Fixed a memory leak bug at hw/nvme/ctrl.c.

v3->v4:
- At the nvme layer, the two patches of enabling the ONCS
  function and enabling rescap are combined into one.
- At the nvme layer, add helper functions for pr capacity
  conversion between the block layer and the nvme layer.

v2->v3:
In v2 Persist Through Power Loss(PTPL) is enable default.
In v3 PTPL is supported, which is passed as a parameter.

v1->v2:
- Add sg_persist --report-capabilities for SCSI protocol and enable
  oncs and rescap for NVMe protocol.
- Add persistent reservation capabilities constants and helper functions for
  SCSI and NVMe protocol.
- Add comments for necessary APIs.

v1:
- Add seven APIs about persistent reservation command for block layer.
  These APIs including reading keys, reading reservations, registering,
  reserving, releasing, clearing and preempting.
- Add the necessary pr-related operation APIs for both the
  SCSI protocol and NVMe protocol at the device layer.
- Add scsi driver at the driver layer to verify the functions


Changqi Lu (10):
  block: add persistent reservation in/out api
  block/raw: add persistent reservation in/out driver
  scsi/constant: add persistent reservation in/out protocol constants
  scsi/util: add helper functions for persistent reservation types
conversion
  hw/scsi: add persistent reservation in/out api for scsi device
  block/nvme: add reservation command protocol constants
  hw/nvme: add helper functions for converting reservation types
  hw/nvme: enable ONCS and rescap function
  hw/nvme: add reservation protocal command
  block/iscsi: add persistent reservation in/out driver

 block/block-backend.c | 397 ++
 block/io.c| 163 +++
 block/iscsi.c | 443 ++
 block/raw-format.c|  56 
 hw/nvme/ctrl.c| 326 +-
 hw/nvme/ns.c  |   5 +
 hw/nvme/nvme.h|  84 ++
 hw/scsi/scsi-disk.c   | 352 
 include/block/block-common.h  |  40 +++
 include/block/block-io.h  |  20 ++
 include/block/block_int-common.h  |  84 ++
 include/block/nvme.h  |  98 +++
 include/scsi/constants.h  |  52 
 include/scsi/utils.h  |   8 +
 include/sysemu/block-backend-io.h |  24 ++
 scsi/utils.c  |  81 ++
 16 files changed, 2231 insertions(+), 2 deletions(-)

-- 
2.20.1




[PATCH v5 07/10] hw/nvme: add helper functions for converting reservation types

2024-06-06 Thread Changqi Lu
This commit introduces two helper functions
that facilitate the conversion between the
reservation types used in the NVME protocol
and those used in the block layer.

Reviewed-by: Stefan Hajnoczi 
Signed-off-by: Changqi Lu 
Signed-off-by: zhenwei pi 
---
 hw/nvme/nvme.h | 80 ++
 1 file changed, 80 insertions(+)

diff --git a/hw/nvme/nvme.h b/hw/nvme/nvme.h
index bed8191bd5..b1ad27c8f2 100644
--- a/hw/nvme/nvme.h
+++ b/hw/nvme/nvme.h
@@ -474,6 +474,86 @@ static inline const char *nvme_io_opc_str(uint8_t opc)
 }
 }
 
+static inline NvmeResvType block_pr_type_to_nvme(BlockPrType type)
+{
+switch (type) {
+case BLK_PR_WRITE_EXCLUSIVE:
+return NVME_RESV_WRITE_EXCLUSIVE;
+case BLK_PR_EXCLUSIVE_ACCESS:
+return NVME_RESV_EXCLUSIVE_ACCESS;
+case BLK_PR_WRITE_EXCLUSIVE_REGS_ONLY:
+return NVME_RESV_WRITE_EXCLUSIVE_REGS_ONLY;
+case BLK_PR_EXCLUSIVE_ACCESS_REGS_ONLY:
+return NVME_RESV_EXCLUSIVE_ACCESS_REGS_ONLY;
+case BLK_PR_WRITE_EXCLUSIVE_ALL_REGS:
+return NVME_RESV_WRITE_EXCLUSIVE_ALL_REGS;
+case BLK_PR_EXCLUSIVE_ACCESS_ALL_REGS:
+return NVME_RESV_EXCLUSIVE_ACCESS_ALL_REGS;
+}
+
+return 0;
+}
+
+static inline BlockPrType nvme_pr_type_to_block(NvmeResvType type)
+{
+switch (type) {
+case NVME_RESV_WRITE_EXCLUSIVE:
+return BLK_PR_WRITE_EXCLUSIVE;
+case NVME_RESV_EXCLUSIVE_ACCESS:
+return BLK_PR_EXCLUSIVE_ACCESS;
+case NVME_RESV_WRITE_EXCLUSIVE_REGS_ONLY:
+return BLK_PR_WRITE_EXCLUSIVE_REGS_ONLY;
+case NVME_RESV_EXCLUSIVE_ACCESS_REGS_ONLY:
+return BLK_PR_EXCLUSIVE_ACCESS_REGS_ONLY;
+case NVME_RESV_WRITE_EXCLUSIVE_ALL_REGS:
+return BLK_PR_WRITE_EXCLUSIVE_ALL_REGS;
+case NVME_RESV_EXCLUSIVE_ACCESS_ALL_REGS:
+return BLK_PR_EXCLUSIVE_ACCESS_ALL_REGS;
+}
+
+return 0;
+}
+
+static inline uint8_t nvme_pr_cap_to_block(uint16_t nvme_pr_cap)
+{
+uint8_t res = 0;
+
+res |= (nvme_pr_cap & NVME_PR_CAP_WR_EX) ?
+   BLK_PR_CAP_WR_EX : 0;
+res |= (nvme_pr_cap & NVME_PR_CAP_EX_AC) ?
+   BLK_PR_CAP_EX_AC : 0;
+res |= (nvme_pr_cap & NVME_PR_CAP_WR_EX_RO) ?
+   BLK_PR_CAP_WR_EX_RO : 0;
+res |= (nvme_pr_cap & NVME_PR_CAP_EX_AC_RO) ?
+   BLK_PR_CAP_EX_AC_RO : 0;
+res |= (nvme_pr_cap & NVME_PR_CAP_WR_EX_AR) ?
+   BLK_PR_CAP_WR_EX_AR : 0;
+res |= (nvme_pr_cap & NVME_PR_CAP_EX_AC_AR) ?
+   BLK_PR_CAP_EX_AC_AR : 0;
+
+return res;
+}
+
+static inline uint8_t block_pr_cap_to_nvme(uint8_t block_pr_cap)
+{
+uint16_t res = 0;
+
+res |= (block_pr_cap & BLK_PR_CAP_WR_EX) ?
+  NVME_PR_CAP_WR_EX : 0;
+res |= (block_pr_cap & BLK_PR_CAP_EX_AC) ?
+  NVME_PR_CAP_EX_AC : 0;
+res |= (block_pr_cap & BLK_PR_CAP_WR_EX_RO) ?
+  NVME_PR_CAP_WR_EX_RO : 0;
+res |= (block_pr_cap & BLK_PR_CAP_EX_AC_RO) ?
+  NVME_PR_CAP_EX_AC_RO : 0;
+res |= (block_pr_cap & BLK_PR_CAP_WR_EX_AR) ?
+  NVME_PR_CAP_WR_EX_AR : 0;
+res |= (block_pr_cap & BLK_PR_CAP_EX_AC_AR) ?
+  NVME_PR_CAP_EX_AC_AR : 0;
+
+return res;
+}
+
 typedef struct NvmeSQueue {
 struct NvmeCtrl *ctrl;
 uint16_tsqid;
-- 
2.20.1




[PATCH v5 03/10] scsi/constant: add persistent reservation in/out protocol constants

2024-06-06 Thread Changqi Lu
Add constants for the persistent reservation in/out protocol
in the scsi/constant module. The constants include the persistent
reservation command, type, and scope values defined in sections
6.13 and 6.14 of the SCSI Primary Commands-4 (SPC-4) specification.

Signed-off-by: Changqi Lu 
Signed-off-by: zhenwei pi 
---
 include/scsi/constants.h | 52 
 1 file changed, 52 insertions(+)

diff --git a/include/scsi/constants.h b/include/scsi/constants.h
index 9b98451912..922a314535 100644
--- a/include/scsi/constants.h
+++ b/include/scsi/constants.h
@@ -319,4 +319,56 @@
 #define IDENT_DESCR_TGT_DESCR_SIZE 32
 #define XCOPY_BLK2BLK_SEG_DESC_SIZE 28
 
+typedef enum {
+SCSI_PR_WRITE_EXCLUSIVE = 0x01,
+SCSI_PR_EXCLUSIVE_ACCESS= 0x03,
+SCSI_PR_WRITE_EXCLUSIVE_REGS_ONLY   = 0x05,
+SCSI_PR_EXCLUSIVE_ACCESS_REGS_ONLY  = 0x06,
+SCSI_PR_WRITE_EXCLUSIVE_ALL_REGS= 0x07,
+SCSI_PR_EXCLUSIVE_ACCESS_ALL_REGS   = 0x08,
+} SCSIPrType;
+
+typedef enum {
+SCSI_PR_LU_SCOPE  = 0x00,
+} SCSIPrScope;
+
+typedef enum {
+SCSI_PR_OUT_REGISTER = 0x0,
+SCSI_PR_OUT_RESERVE  = 0x1,
+SCSI_PR_OUT_RELEASE  = 0x2,
+SCSI_PR_OUT_CLEAR= 0x3,
+SCSI_PR_OUT_PREEMPT  = 0x4,
+SCSI_PR_OUT_PREEMPT_AND_ABORT= 0x5,
+SCSI_PR_OUT_REG_AND_IGNORE_KEY   = 0x6,
+SCSI_PR_OUT_REG_AND_MOVE = 0x7,
+} SCSIPrOutAction;
+
+typedef enum {
+SCSI_PR_IN_READ_KEYS = 0x0,
+SCSI_PR_IN_READ_RESERVATION  = 0x1,
+SCSI_PR_IN_REPORT_CAPABILITIES   = 0x2,
+} SCSIPrInAction;
+
+typedef enum {
+/* Exclusive Access All Registrants reservation type */
+SCSI_PR_CAP_EX_AC_AR = 1 << 0,
+/* Write Exclusive reservation type */
+SCSI_PR_CAP_WR_EX = 1 << 9,
+/* Exclusive Access reservation type */
+SCSI_PR_CAP_EX_AC = 1 << 11,
+/* Write Exclusive Registrants Only reservation type */
+SCSI_PR_CAP_WR_EX_RO = 1 << 13,
+/* Exclusive Access Registrants Only reservation type */
+SCSI_PR_CAP_EX_AC_RO = 1 << 14,
+/* Write Exclusive All Registrants reservation type */
+SCSI_PR_CAP_WR_EX_AR = 1 << 15,
+
+SCSI_PR_CAP_ALL = (SCSI_PR_CAP_EX_AC_AR |
+  SCSI_PR_CAP_WR_EX |
+  SCSI_PR_CAP_EX_AC |
+  SCSI_PR_CAP_WR_EX_RO |
+  SCSI_PR_CAP_EX_AC_RO |
+  SCSI_PR_CAP_WR_EX_AR),
+} SCSIPrCap;
+
 #endif
-- 
2.20.1




  1   2   3   >