Re: QTest framework does not capture toggled irq line

[Gustavo Romero]

On 11/10/23 3:16 AM, Thomas Huth wrote:

On 10/11/2023 04.40, Gustavo Romero wrote:

Hi folks,

I'm writing a test for a device that has one IRQ output line
that is toggled (raised then lowered) by the device to trigger
a CPU interrupt.

Afaics the QTest framework does not provide a way to capture
when an output line is raised because the API functions, e.g.
qtest_get_irq(), read the current state of the intercepted
IRQ lines, which is already low when the function is called,
since the line is toggled by the device.

I'd like to introduce a new API function to address this case,
called qtest_get_irq_trigger_counter():

...

This change addresses the current QTest limitation. Is it acceptable?


  Hi Gustavo,

that sounds reasonable to me.


Thanks, Thomas! I've posted the patch here:

https://lists.nongnu.org/archive/html/qemu-devel/2023-11/msg02867.html


Cheers,
Gustavo

[PATCH] test/qtest: Add an API function to capture IRQ toggling

[Gustavo Romero]

Currently the QTest API does not provide a function to allow capturing
when an IRQ line is toggled (raised then lowered). Functions like
qtest_get_irq() read the current state of the intercepted IRQ lines,
which is already low when the function is called, since the line is
toggled.

This commit introduces a new function, qtest_get_irq_trigger_counter(),
which returns the number of times a given intercepted IRQ line was
triggered (raised), hence allowing to capture when an IRQ line was
toggled.

Signed-off-by: Gustavo Romero 
---
 tests/qtest/libqtest.c | 12 
 tests/qtest/libqtest.h |  9 +
 2 files changed, 21 insertions(+)

diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index f33a210861..21891b52f1 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -82,6 +82,7 @@ struct QTestState
 int expected_status;
 bool big_endian;
 bool irq_level[MAX_IRQ];
+uint64_t irq_trigger_counter[MAX_IRQ];
 GString *rx;
 QTestTransportOps ops;
 GList *pending_events;
@@ -498,6 +499,7 @@ static QTestState *qtest_init_internal(const char *qemu_bin,
 s->rx = g_string_new("");
 for (i = 0; i < MAX_IRQ; i++) {
 s->irq_level[i] = false;
+s->irq_trigger_counter[i] = 0;
 }
 
 /*
@@ -690,6 +692,7 @@ redo:
 
 if (strcmp(words[1], "raise") == 0) {
 s->irq_level[irq] = true;
+s->irq_trigger_counter[irq]++;
 } else {
 s->irq_level[irq] = false;
 }
@@ -980,6 +983,14 @@ bool qtest_get_irq(QTestState *s, int num)
 return s->irq_level[num];
 }
 
+uint64_t qtest_get_irq_trigger_counter(QTestState *s, int irq_num)
+{
+/* dummy operation in order to make sure irq is up to date */
+qtest_inb(s, 0);
+
+return s->irq_trigger_counter[irq_num];
+}
+
 void qtest_module_load(QTestState *s, const char *prefix, const char *libname)
 {
 qtest_sendf(s, "module_load %s %s\n", prefix, libname);
@@ -1799,6 +1810,7 @@ QTestState *qtest_inproc_init(QTestState **s, bool log, 
const char* arch,
 qts->wstatus = 0;
 for (int i = 0; i < MAX_IRQ; i++) {
 qts->irq_level[i] = false;
+qts->irq_trigger_counter[i] = 0;
 }
 
 qtest_client_set_rx_handler(qts, qtest_client_inproc_recv_line);
diff --git a/tests/qtest/libqtest.h b/tests/qtest/libqtest.h
index 6e3d3525bf..d1c525aea0 100644
--- a/tests/qtest/libqtest.h
+++ b/tests/qtest/libqtest.h
@@ -364,6 +364,15 @@ void qtest_module_load(QTestState *s, const char *prefix, 
const char *libname);
  */
 bool qtest_get_irq(QTestState *s, int num);
 
+/**
+ * qtest_get_irq_counter:
+ * @s: #QTestState instance to operate on.
+ * @num: Interrupt to observe.
+ *
+ * Returns: The number of times IRQ @num got triggered (raised).
+ */
+uint64_t qtest_get_irq_trigger_counter(QTestState *s, int num);
+
 /**
  * qtest_irq_intercept_in:
  * @s: #QTestState instance to operate on.
-- 
2.34.1

Re: [PATCH] Fix Windows 2000 and XP HDAudio Support

[Christopher Lentocha]

So wait, you want me to add it as another device name? Because 
it is going to be the same exact way as the 1af4 device
just with a number change. Ok, work it is then ...
(Sorry about not getting back sooner also)

Christopher

On 11/8/23 6:12 AM, Gerd Hoffmann wrote:
> On Wed, Nov 08, 2023 at 11:02:06AM +0100, Philippe Mathieu-Daudé wrote:
>> Thanks Christopher for your patch,
>>
>> I'm Cc'ing Volker and Gerd who know better this hardware model.
>>
>> On 7/11/23 20:27, Christopher Lentocha wrote:
>>>
>>> Change the ID to be a Realtek ALC885 so that both
> 
> No.  Rewriting the existing codecs is clearly a non-starter.
> 
> You can add a 'hda-realtek-alc885' variant which tries to
> mimic the realtek coded close enough to make old guests
> without generic hda driver happy.
> 
>>> +#define QEMU_HDA_ID 0x10EC0885
> 
> Nope.  Somemething like 'REALTEK_ALC885_ID' please.
> 
> [ remaining bits of the patch snipped, needs major rework ]
> 
> take care,
>   Gerd
> 

Re: [PATCH v1 1/7] xen-block: Do not write frontend nodes

[David Woodhouse]

On 11 November 2023 16:51:22 GMT-05:00, Andrew Cooper 
 wrote:
>On 11/11/2023 8:18 pm, David Woodhouse wrote:
>> On 11 November 2023 08:43:40 GMT-05:00, Andrew Cooper 
>>  wrote:
>>> Furthermore, the control domain doesn't always have the domid of 0.
>>>
>>> If qemu wants/needs to make changes like this, the control domain has to
>>> arrange for qemu's domain to have appropriate permissions on the nodes.
>> Right. And that's simple enough: if you are running QEMU in a domain which 
>> doesn't have permission to create the backend directory and/or the frontend 
>> nodes, don't ask it to *create* devices. In that case it is only able to 
>> connect as the backend for devices which were created *for* it by the 
>> toolstack.
>>
>> The criterion used in this patch series should be "did QEMU create this 
>> device, or discover it".
>>
>
>Yeah, that sounds like the right approach.

I think we want to kill the xen_backend_set_device() function and instead set 
the backend as a property of the XenDevice *before* realizing it.

Re: [PATCH v1 1/7] xen-block: Do not write frontend nodes

[Andrew Cooper]

On 11/11/2023 8:18 pm, David Woodhouse wrote:
> On 11 November 2023 08:43:40 GMT-05:00, Andrew Cooper 
>  wrote:
>> Furthermore, the control domain doesn't always have the domid of 0.
>>
>> If qemu wants/needs to make changes like this, the control domain has to
>> arrange for qemu's domain to have appropriate permissions on the nodes.
> Right. And that's simple enough: if you are running QEMU in a domain which 
> doesn't have permission to create the backend directory and/or the frontend 
> nodes, don't ask it to *create* devices. In that case it is only able to 
> connect as the backend for devices which were created *for* it by the 
> toolstack.
>
> The criterion used in this patch series should be "did QEMU create this 
> device, or discover it".
>

Yeah, that sounds like the right approach.

~Andrew

Re: [PATCH v1 1/7] xen-block: Do not write frontend nodes

[David Woodhouse]

On 11 November 2023 08:43:40 GMT-05:00, Andrew Cooper 
 wrote:
>Furthermore, the control domain doesn't always have the domid of 0.
>
>If qemu wants/needs to make changes like this, the control domain has to
>arrange for qemu's domain to have appropriate permissions on the nodes.

Right. And that's simple enough: if you are running QEMU in a domain which 
doesn't have permission to create the backend directory and/or the frontend 
nodes, don't ask it to *create* devices. In that case it is only able to 
connect as the backend for devices which were created *for* it by the toolstack.

The criterion used in this patch series should be "did QEMU create this device, 
or discover it".

Re: disable-pie build

[Volker Rümelin]

Am 11.11.23 um 17:09 schrieb Paolo Bonzini:
> On Sat, Nov 11, 2023 at 3:40 AM Michael Tokarev  wrote:
>> Hi!
>>
>> It looks like --disable-pie configure, which uses -fno-pie -no-pie flags
>> for the compiler, is broken: it does not not tell the *linker* about the
>> option, so the link fails (at least on debian bookworm):
> Looks good, if you can send a patch perhaps Stefan can apply it (or
> someone else can handle it in my stead, because I'm away next week).
>
> Paolo

No, this doesn't look good. This patch again breaks the native Windows
build with MSYS2 and mingw64 cross compile probably too.

See

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

https://lore.kernel.org/qemu-devel/20230522080816.66320-1-pbonz...@redhat.com/
https://lore.kernel.org/qemu-devel/20230523073029.19549-1-pbonz...@redhat.com/

and the big comment above the changed lines in meson.build.

With best regards,
Volker

>> /usr/bin/ld: libcommon.fa.p/hw_core_cpu-common.c.o: relocation R_X86_64_32 
>> against `.rodata' can not be used when making a PIE object; recompile with
>> -fPIE
>> /usr/bin/ld: failed to set dynamic section sizes: bad value
>>
>> This is failing for *all* executables, including tests, qemu-img, etc.
>>
>> The following change fixes it:
>>
>> diff --git a/meson.build b/meson.build
>> index a9c4f28247..0b7ca45d48 100644
>> --- a/meson.build
>> +++ b/meson.build
>> @@ -278,7 +278,8 @@ endif
>>   # tries to build an executable instead of a shared library and fails.  So
>>   # don't add -no-pie anywhere and cross fingers. :(
>>   if not get_option('b_pie')
>> -  qemu_common_flags += cc.get_supported_arguments('-fno-pie', '-no-pie')
>> +  qemu_common_flags += cc.get_supported_arguments('-fno-pie')
>> +  qemu_ldflags += cc.get_supported_arguments('-no-pie')
>>   endif
>>
>>   if not get_option('stack_protector').disabled()

Re: [PATCH v5 03/20] vfio/iommufd: Implement the iommufd backend

[Nicolin Chen]

On Thu, Nov 09, 2023 at 07:45:12PM +0800, Zhenzhong Duan wrote:

> +static int iommufd_cdev_attach_ioas_hwpt(VFIODevice *vbasedev, bool is_ioas,
> + uint32_t id, Error **errp)
> +{
> +int ret, iommufd = vbasedev->iommufd->fd;
> +struct vfio_device_attach_iommufd_pt attach_data = {
> +.argsz = sizeof(attach_data),
> +.flags = 0,
> +.pt_id = id,
> +};
> +const char *str = is_ioas ? "ioas" : "hwpt";
> +
> +/* Attach device to an IOAS or hwpt within iommufd */
> +ret = ioctl(vbasedev->fd, VFIO_DEVICE_ATTACH_IOMMUFD_PT, _data);
> +if (ret) {
> +error_setg_errno(errp, errno,
> + "[iommufd=%d] error attach %s (%d) to %s_id=%d",
> + iommufd, vbasedev->name, vbasedev->fd, str, id);
> +} else {
> +trace_iommufd_cdev_attach_ioas_hwpt(iommufd, vbasedev->name,
> +vbasedev->fd, str, id);
> +}
> +return ret;
> +}
> +
> +static int iommufd_cdev_detach_ioas_hwpt(VFIODevice *vbasedev, bool is_ioas,
> + uint32_t id, Error **errp)
> +{
> +int ret, iommufd = vbasedev->iommufd->fd;
> +struct vfio_device_detach_iommufd_pt detach_data = {
> +.argsz = sizeof(detach_data),
> +.flags = 0,
> +};
> +const char *str = is_ioas ? "ioas" : "hwpt";
> +
> +ret = ioctl(vbasedev->fd, VFIO_DEVICE_DETACH_IOMMUFD_PT, _data);
> +if (ret) {
> +error_setg_errno(errp, errno, "detach %s from %s failed",
> + vbasedev->name, str);
> +} else {
> +trace_iommufd_cdev_detach_ioas_hwpt(iommufd, vbasedev->name, str, 
> id);
> +}
> +return ret;
> +}

Being a bit late to the game, I might have missed some review
history here, yet any reason why we changed the attach/detach
APIs to specify is_ioas? The attach kernel uAPI generically
handles this without requiring an is_ioas input, and it could
be interpreted to attaching both ioas and hwpt (auto). On the
hand, the detach uAPI doesn't even care about id. So, I don't
see a value of the is_ioas except the trace logs..

If we have such a hard requirement somewhere, shall we create
an IOMMUFDPtObject structure that holds the type (ioas/hwpt)?

Thanks
Nic

Re: [PATCH v8] target/ppc: Fix bugs in VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2 macros

[Cédric Le Goater]

Adding Richard,

Thanks,

C.


On 11/10/23 19:41, John Platts wrote:

The patch below fixes a bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2
macros in target/ppc/fpu_helper.c where a non-NaN floating point value from the
source vector is incorrectly converted to 0, 0x8000, or 0x8000
instead of the expected value if a preceding source floating point value from
the same source vector was a NaN.

The bug in the VSX_CVT_FP_TO_INT and VSX_CVT_FP_TO_INT2 macros in
target/ppc/fpu_helper.c was introduced with commit c3f24257e3c0.

This patch also adds a new vsx_f2i_nan test in tests/tcg/ppc64 that checks that
the VSX xvcvspsxws, xvcvspuxws, xvcvspsxds, xvcvspuxds, xvcvdpsxws, xvcvdpuxws,
xvcvdpsxds, and xvcvdpuxds instructions correctly convert non-NaN floating point
values to integer values if the source vector contains NaN floating point 
values.

Fixes: c3f24257e3c0 ("target/ppc: Clear fpstatus flags on helpers missing it")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1941
Signed-off-by: John Platts 
---
  target/ppc/fpu_helper.c |  12 +-
  tests/tcg/ppc64/Makefile.target |   5 +
  tests/tcg/ppc64/vsx_f2i_nan.c   | 300 
  3 files changed, 313 insertions(+), 4 deletions(-)
  create mode 100644 tests/tcg/ppc64/vsx_f2i_nan.c

diff --git a/target/ppc/fpu_helper.c b/target/ppc/fpu_helper.c
index 03150a0f10..4b3dcad5d1 100644
--- a/target/ppc/fpu_helper.c
+++ b/target/ppc/fpu_helper.c
@@ -2880,20 +2880,22 @@ uint64_t helper_XSCVSPDPN(uint64_t xb)
  #define VSX_CVT_FP_TO_INT(op, nels, stp, ttp, sfld, tfld, sfi, rnan) \
  void helper_##op(CPUPPCState *env, ppc_vsr_t *xt, ppc_vsr_t *xb) \
  {\
+int all_flags = 0;   \
  ppc_vsr_t t = { };   \
  int i, flags;\
   \
-helper_reset_fpstatus(env);  \
- \
  for (i = 0; i < nels; i++) { \
+helper_reset_fpstatus(env);  \
  t.tfld = stp##_to_##ttp##_round_to_zero(xb->sfld, >fp_status);  \
  flags = env->fp_status.float_exception_flags;\
+all_flags |= flags;  \
  if (unlikely(flags & float_flag_invalid)) {  \
  t.tfld = float_invalid_cvt(env, flags, t.tfld, rnan, 0, GETPC());\
  }\
  }\
   \
  *xt = t; \
+env->fp_status.float_exception_flags = all_flags;\
  do_float_check_status(env, sfi, GETPC());\
  }
  
@@ -2945,15 +2947,16 @@ VSX_CVT_FP_TO_INT128(XSCVQPSQZ, int128, 0x8000ULL);

  #define VSX_CVT_FP_TO_INT2(op, nels, stp, ttp, sfi, rnan)\
  void helper_##op(CPUPPCState *env, ppc_vsr_t *xt, ppc_vsr_t *xb) \
  {\
+int all_flags = 0;   \
  ppc_vsr_t t = { };   \
  int i, flags;\
   \
-helper_reset_fpstatus(env);  \
- \
  for (i = 0; i < nels; i++) { \
+helper_reset_fpstatus(env);  \
  t.VsrW(2 * i) = stp##_to_##ttp##_round_to_zero(xb->VsrD(i),  \
 >fp_status); \
  flags = env->fp_status.float_exception_flags;\
+all_flags |= flags;  \
  if (unlikely(flags & float_flag_invalid)) {  \
  t.VsrW(2 * i) = float_invalid_cvt(env, flags, t.VsrW(2 * i), \
rnan, 0, GETPC()); \
@@ -2962,6 +2965,7 @@ void helper_##op(CPUPPCState *env, ppc_vsr_t *xt, 
ppc_vsr_t *xb) \
  }  

Re: [RFC PATCH-for-8.2] .gitlab-ci.d/cirrus.yml: Promote NetBSD job as gating

[Reinoud Zandijk]

On Fri, Nov 10, 2023 at 10:12:38PM +0100, Reinoud Zandijk wrote:
> On Thu, Nov 09, 2023 at 06:15:51PM +0100, Thomas Huth wrote:
> > On 09/11/2023 17.58, Daniel P. Berrangé wrote:
> > > On Thu, Nov 09, 2023 at 04:35:56PM +0100, Philippe Mathieu-Daudé wrote:
...
> > You're right, Daniel. Seems like both, the Cirrus netbsd and the openbsd job
> > are currently broken and only output some help text instead of compiling
> > QEMU:
> > 
> >  https://gitlab.com/philmd/qemu/-/jobs/5497861511#L6834
> > 
> > ... that's why the finish so fast.
> > 
> > IIRC last time I've seen them "working", they were running into the 80
> > minute timeout again.
> > 
> > So the netbsd and openbsd job are indeed not very useful anymore. I think we
> > should rather remove them and add a proper job via our own custom
> > KVM-capable runners instead.
> 
> Even though I am a co-maintainer of the NetBSD support for Qemu I am not quite
> sure what testcase this is. Is this a regression test of installing NetBSD
> from an ISO? That somehow times out? Where can I find the resulting console
> output? Maybe the installer changed?

Re-reading the thread its about compiling Qemu on NetBSD. Doh. I am a novice
to the test kit you use so please forgive me if I don't make sense. Am I right
that it does install NetBSD OK, it then comes up and then tries to compile
Qemu on it but it fails due to some Python errors in the test script? Does it
use NetBSDs pkgsrc with its patches or has it its own method of dealing with
them?

With regards,
Reinoud

Re: [PATCH v4 3/3] hw/ppc: Nest1 chiplet wiring

[Cédric Le Goater]

On 11/7/23 08:41, Chalapathi V wrote:

From: Chalapathi V 

This part of the patchset connects the nest1 chiplet model to p10 chip.

Signed-off-by: Chalapathi V 
---
  hw/ppc/pnv.c  | 14 ++
  include/hw/ppc/pnv_chip.h |  2 ++
  2 files changed, 16 insertions(+)

diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index c0e34ff..2b93cdd 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -351,6 +351,8 @@ static void pnv_chip_power10_dt_populate(PnvChip *chip, 
void *fdt)
  static const char compat[] = "ibm,power10-xscom\0ibm,xscom";
  int i;
  
+Pnv10Chip *chip10 = PNV10_CHIP(chip);

+
  pnv_dt_xscom(chip, fdt, 0,
   cpu_to_be64(PNV10_XSCOM_BASE(chip)),
   cpu_to_be64(PNV10_XSCOM_SIZE),
@@ -366,6 +368,9 @@ static void pnv_chip_power10_dt_populate(PnvChip *chip, 
void *fdt)
  pnv_dt_memory(fdt, chip->chip_id, chip->ram_start, chip->ram_size);
  }
  
+/* Populate nest1_chiplet device tree */

+PNV_NEST1CHIPLET_GET_CLASS(>nest1_chiplet)->nest1_dt_populate(fdt);

you could call directly pnv_nest1_dt_populate() IMO.


Have you tried to start a 2 sockets machine ?

  -machine powernv10 -smp 16,sockets=2,cores=2,threads=4


Thanks,

C.




+
  pnv_dt_lpc(chip, fdt, 0, PNV10_LPCM_BASE(chip), PNV10_LPCM_SIZE);
  }
  
@@ -1649,6 +1654,8 @@ static void pnv_chip_power10_instance_init(Object *obj)

  object_initialize_child(obj, "occ",  >occ, TYPE_PNV10_OCC);
  object_initialize_child(obj, "sbe",  >sbe, TYPE_PNV10_SBE);
  object_initialize_child(obj, "homer", >homer, TYPE_PNV10_HOMER);
+object_initialize_child(obj, "nest1_chiplet", >nest1_chiplet,
+TYPE_PNV_NEST1_CHIPLET);
  
  chip->num_pecs = pcc->num_pecs;
  
@@ -1813,6 +1820,13 @@ static void pnv_chip_power10_realize(DeviceState *dev, Error **errp)

  memory_region_add_subregion(get_system_memory(), PNV10_HOMER_BASE(chip),
  >homer.regs);
  
+/* nest1 chiplet control regs */

+if (!qdev_realize(DEVICE(>nest1_chiplet), NULL, errp)) {
+return;
+}
+pnv_xscom_add_subregion(chip, PNV10_XSCOM_NEST1_CTRL_CHIPLET_BASE,
+   >nest1_chiplet.perv_chiplet.xscom_perv_ctrl_regs);
+
  /* PHBs */
  pnv_chip_power10_phb_realize(chip, _err);
  if (local_err) {
diff --git a/include/hw/ppc/pnv_chip.h b/include/hw/ppc/pnv_chip.h
index 53e1d92..4bcb925 100644
--- a/include/hw/ppc/pnv_chip.h
+++ b/include/hw/ppc/pnv_chip.h
@@ -4,6 +4,7 @@
  #include "hw/pci-host/pnv_phb4.h"
  #include "hw/ppc/pnv_core.h"
  #include "hw/ppc/pnv_homer.h"
+#include "hw/ppc/pnv_nest_chiplet.h"
  #include "hw/ppc/pnv_lpc.h"
  #include "hw/ppc/pnv_occ.h"
  #include "hw/ppc/pnv_psi.h"
@@ -109,6 +110,7 @@ struct Pnv10Chip {
  PnvOCC   occ;
  PnvSBE   sbe;
  PnvHomer homer;
+PnvNest1Chiplet nest1_chiplet;
  
  uint32_t nr_quads;

  PnvQuad  *quads;

Re: [PATCH v4 2/3] hw/ppc: Add nest1 chiplet model

[Cédric Le Goater]

On 11/7/23 08:41, Chalapathi V wrote:

From: Chalapathi V 

The nest1 chiplet handle the high speed i/o traffic over PCIe and others.
The nest1 chiplet consists of PowerBus Fabric controller,
nest Memory Management Unit, chiplet control unit and more.

This commit creates a nest1 chiplet model and initialize and realize the
pervasive chiplet model where chiplet control registers are implemented.

Signed-off-by: Chalapathi V 
---
  hw/ppc/meson.build|  1 +
  hw/ppc/pnv_nest1_chiplet.c| 94 +++
  include/hw/ppc/pnv_nest_chiplet.h | 41 +
  3 files changed, 136 insertions(+)
  create mode 100644 hw/ppc/pnv_nest1_chiplet.c
  create mode 100644 include/hw/ppc/pnv_nest_chiplet.h

diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
index c80d2f6..4e45e5c 100644
--- a/hw/ppc/meson.build
+++ b/hw/ppc/meson.build
@@ -51,6 +51,7 @@ ppc_ss.add(when: 'CONFIG_POWERNV', if_true: files(
'pnv_homer.c',
'pnv_pnor.c',
'pnv_pervasive.c',
+  'pnv_nest1_chiplet.c',
  ))
  # PowerPC 4xx boards
  ppc_ss.add(when: 'CONFIG_PPC405', if_true: files(
diff --git a/hw/ppc/pnv_nest1_chiplet.c b/hw/ppc/pnv_nest1_chiplet.c
new file mode 100644
index 000..e078076
--- /dev/null
+++ b/hw/ppc/pnv_nest1_chiplet.c
@@ -0,0 +1,94 @@
+/*
+ * QEMU PowerPC nest1 chiplet model
+ *
+ * Copyright (c) 2023, IBM Corporation.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * This code is licensed under the GPL version 2 or later. See the
+ * COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/qdev-properties.h"
+#include "hw/ppc/pnv.h"
+#include "hw/ppc/pnv_xscom.h"
+#include "hw/ppc/pnv_nest_chiplet.h"
+#include "hw/ppc/pnv_pervasive.h"
+#include "hw/ppc/fdt.h"
+#include 
+
+/*
+ * The nest1 chiplet contains chiplet control unit,
+ * PowerBus/RaceTrack/Bridge logic, nest Memory Management Unit(nMMU)
+ * and more.
+ */
+
+static void pnv_nest1_chiplet_realize(DeviceState *dev, Error **errp)
+{
+PnvNest1Chiplet *nest1_chiplet = PNV_NEST1CHIPLET(dev);
+
+object_initialize_child(OBJECT(nest1_chiplet), "perv_chiplet",
+_chiplet->perv_chiplet,
+TYPE_PNV_PERV_CHIPLET);
+
+if (!qdev_realize(DEVICE(_chiplet->perv_chiplet), NULL, errp)) {


I think we will save some bytes and ease reading by removing the '_chiplet'
suffix in the variable names and types. A QEMU model is generally an HW
logic unit or sub-unit. We don't need to add a Chip* suffix.

PnvChip is an exception to this comment, because it represent a socket or
processor, and is referred to as a chip in the POWER documentation AFAICR.

For instance, this routine would become :


  static void pnv_nest1_realize(DeviceState *dev, Error **errp)
  {
  PnvNest1 *nest1 = PNV_NEST1(dev);
  
  object_initialize_child(OBJECT(nest1), "perv", >perv,

  TYPE_PNV_PERV);
  
  if (!qdev_realize(DEVICE(>perv), NULL, errp)) {

  return;
  }
  }


which is clear enough for me. What do you think ? We can still use the
term chiplet in the documentation.



+return;
+}
+}
+
+static int pnv_nest1_chiplet_dt_xscom(PnvXScomInterface *dev, void *fdt,
+ int offset)
+{
+g_autofree char *name = NULL;
+int nest1_chiplet_offset;
+const char compat[] = "ibm,power10-nest1-chiplet";
+
+name = g_strdup_printf("nest1_chiplet@%x",
+   PNV10_XSCOM_NEST1_CTRL_CHIPLET_BASE);
+nest1_chiplet_offset = fdt_add_subnode(fdt, offset, name);
+_FDT(nest1_chiplet_offset);
+
+_FDT(fdt_setprop(fdt, nest1_chiplet_offset, "compatible",
+compat, sizeof(compat)));
+return 0;
+}
+
+static void pnv_nest1_dt_populate(void *fdt)
+{
+


Please remove white line.


+uint32_t nest1_base = cpu_to_be32(PNV10_XSCOM_NEST1_CTRL_CHIPLET_BASE);
+pnv_perv_dt(nest1_base, fdt, 0);
+}
+
+static void pnv_nest1_chiplet_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+PnvNest1Class *nest1_class = PNV_NEST1CHIPLET_CLASS(klass);
+PnvXScomInterfaceClass *xscomc = PNV_XSCOM_INTERFACE_CLASS(klass);
+
+xscomc->dt_xscom = pnv_nest1_chiplet_dt_xscom;
+
+dc->desc = "PowerNV nest1 chiplet";
+dc->realize = pnv_nest1_chiplet_realize;
+nest1_class->nest1_dt_populate = pnv_nest1_dt_populate;


Why do you need a class handler for the Nest1 unit ? Do you have plans
to have multiple implementations ?


+}
+
+static const TypeInfo pnv_nest1_chiplet_info = {
+.name  = TYPE_PNV_NEST1_CHIPLET,
+.parent= TYPE_DEVICE,
+.instance_size = sizeof(PnvNest1Chiplet),
+.class_init= pnv_nest1_chiplet_class_init,
+.interfaces= (InterfaceInfo[]) {
+{ TYPE_PNV_XSCOM_INTERFACE },
+{ }
+}
+};
+
+static void pnv_nest1_chiplet_register_types(void)
+{
+

Re: [PULL 0/8] Firmware/edk2 20230918 patches

[Akihiko Odaki]

On 2023/09/18 22:33, Gerd Hoffmann wrote:

The following changes since commit c5ea91da443b458352c1b629b490ee6631775cb4:

   Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into 
staging (2023-09-08 10:06:25 -0400)

are available in the Git repository at:

   https://gitlab.com/kraxel/qemu.git tags/firmware/edk2-20230918-pull-request

for you to fetch changes up to 0ec0767e59261b7a1f59e904020cf52b45380e54:

   tests/acpi: disallow virt/SSDT.memhp updates (2023-09-18 15:27:27 +0200)


edk2: update to edk2-stable202308

v2: include acpi test data updates



Gerd Hoffmann (8):
   tests/acpi: allow virt/SSDT.memhp updates
   edk2: update build script
   edk2: update build config
   edk2: workaround edk-stable202308 bug
   edk2: update submodule to edk2-stable202308
   edk2: update binaries to edk2-stable202308
   tests/acpi: update virt/SSDT.memhp
   tests/acpi: disallow virt/SSDT.memhp updates

  roms/edk2-build.py | 202 -
  pc-bios/edk2-aarch64-code.fd.bz2   | Bin 1508184 -> 1573561 bytes
  pc-bios/edk2-arm-code.fd.bz2   | Bin 1483149 -> 1560966 bytes
  pc-bios/edk2-i386-code.fd.bz2  | Bin 1695318 -> 1770410 bytes
  pc-bios/edk2-i386-secure-code.fd.bz2   | Bin 1922002 -> 2121818 bytes
  pc-bios/edk2-riscv-code.fd.bz2 | Bin 0 -> 1177402 bytes
  pc-bios/edk2-riscv-vars.fd.bz2 | Bin 0 -> 231 bytes
  pc-bios/edk2-riscv.fd.bz2  | Bin 1096418 -> 0 bytes
  pc-bios/edk2-x86_64-code.fd.bz2| Bin 1796544 -> 1887921 bytes
  pc-bios/edk2-x86_64-microvm.fd.bz2 | Bin 1697788 -> 1782629 bytes
  pc-bios/edk2-x86_64-secure-code.fd.bz2 | Bin 1999841 -> 2200701 bytes
  roms/edk2  |   2 +-
  roms/edk2-build.config |  12 +-
  tests/data/acpi/virt/SSDT.memhp| Bin 1817 -> 1817 bytes
  14 files changed, 139 insertions(+), 77 deletions(-)
  create mode 100644 pc-bios/edk2-riscv-code.fd.bz2
  create mode 100644 pc-bios/edk2-riscv-vars.fd.bz2
  delete mode 100644 pc-bios/edk2-riscv.fd.bz2



Hi,

This apparently broke EDK2 for AArch64. I tried the following command:
build/qemu-system-aarch64 -drive 
file=build/pc-bios/edk2-aarch64-code.fd,format=raw,if=pflash,readonly=on 
-M virt -cpu max -nographic -cdrom 
Fedora-Silverblue-ostree-aarch64-37-1.7.iso


Below is the output:
BdsDxe: loading Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0)
BdsDxe: starting Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x0)


Synchronous Exception at 0x43695920
PC 0x43695920
PC 0x43697EE4
PC 0x4369A514
PC 0x4369B030
PC 0x43C04288
PC 0x43C04338
PC 0x43C051B4
PC 0x43C02030
PC 0x47685788 (0x4767E000+0x7788) [ 1] DxeCore.dll
PC 0x4732AECC (0x47324000+0x6ECC) [ 2] BdsDxe.dll
PC 0x4732DFD4 (0x47324000+0x9FD4) [ 2] BdsDxe.dll
PC 0x4768900C (0x4767E000+0xB00C) [ 3] DxeCore.dll
[ 1] 
/home/kraxel/projects/qemu/roms/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
[ 2] 
/home/kraxel/projects/qemu/roms/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/BdsDxe.dll
[ 3] 
/home/kraxel/projects/qemu/roms/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll


  X0 0x43679960   X1 0x   X2 0x000D 
  X3 0x436A2F70
  X4 0x43679920   X5 0x4366B000   X6 0x43677000 
  X7 0x436A20D0
  X8 0x436A20C8   X9 0x436A20D0  X10 0x436A20E0 
 X11 0x436A20D0
 X12 0x43679FFF  X13 0x0008  X14 0x 
 X15 0x
 X16 0x473962BC  X17 0xE6D79577  X18 0x0011 
 X19 0x43C83000
 X20 0x  X21 0x46310C98  X22 0x43C972F0 
 X23 0x
 X24 0x43C97000  X25 0x43C973B8  X26 0x43C973C0 
 X27 0x43C973C8

 X28 0x43C973D0   FP 0x4767D6A0   LR 0x43697EE4

  V0 0xAFAFAFAFAFAFAFAF AFAFAFAFAFAFAFAF   V1 0x0004 

  V2 0x554E65213A544C55 41464544464F544E   V3 0x 
0010
  V4 0x4000    V5 0x4010040140100401 
4010040140100401
  V6 0x00401000 00401000   V7 0x 

  V8 0x    V9 0x 

 V10 0x   V11 0x 

 V12 0x   V13 0x 

 V14 0x   V15 0x 

 V16 0x   V17 0x 

 V18 

Re: [PATCH v4 1/3] hw/ppc: Add pnv pervasive common chiplet units

[Cédric Le Goater]

Hello Chalapathi,

Please add to your ~/.gitconfig :

  [diff]
  orderFile = /path/to/qemu/scripts/git.orderfile

It will order the header file first in the patch.

On 11/7/23 08:41, Chalapathi V wrote:

From: Chalapathi V 

This part of the patchset creates a common pervasive chiplet model where it
houses the common units of a chiplets.

The chiplet control unit is common across chiplets and this commit implements
the pervasive chiplet model with chiplet control registers.

Signed-off-by: Chalapathi V 
---
  hw/ppc/meson.build |   1 +
  hw/ppc/pnv_pervasive.c | 213 +
  include/hw/ppc/pnv_pervasive.h |  39 
  include/hw/ppc/pnv_xscom.h |   3 +
  4 files changed, 256 insertions(+)
  create mode 100644 hw/ppc/pnv_pervasive.c
  create mode 100644 include/hw/ppc/pnv_pervasive.h

diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
index 7c2c524..c80d2f6 100644
--- a/hw/ppc/meson.build
+++ b/hw/ppc/meson.build
@@ -50,6 +50,7 @@ ppc_ss.add(when: 'CONFIG_POWERNV', if_true: files(
'pnv_bmc.c',
'pnv_homer.c',
'pnv_pnor.c',
+  'pnv_pervasive.c',
  ))
  # PowerPC 4xx boards
  ppc_ss.add(when: 'CONFIG_PPC405', if_true: files(
diff --git a/hw/ppc/pnv_pervasive.c b/hw/ppc/pnv_pervasive.c
new file mode 100644
index 000..40f60b5
--- /dev/null
+++ b/hw/ppc/pnv_pervasive.c
@@ -0,0 +1,213 @@
+/*
+ * QEMU PowerPC pervasive common chiplet model
+ *
+ * Copyright (c) 2023, IBM Corporation.
+ *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
+ * This code is licensed under the GPL version 2 or later. See the
+ * COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "hw/qdev-properties.h"
+#include "hw/ppc/pnv.h"
+#include "hw/ppc/pnv_xscom.h"
+#include "hw/ppc/pnv_pervasive.h"
+#include "hw/ppc/fdt.h"
+#include 
+
+#define CPLT_CONF0   0x08
+#define CPLT_CONF0_OR0x18
+#define CPLT_CONF0_CLEAR 0x28
+#define CPLT_CONF1   0x09
+#define CPLT_CONF1_OR0x19
+#define CPLT_CONF1_CLEAR 0x29
+#define CPLT_STAT0   0x100
+#define CPLT_MASK0   0x101
+#define CPLT_PROTECT_MODE0x3FE
+#define CPLT_ATOMIC_CLOCK0x3FF
+
+static uint64_t pnv_chiplet_ctrl_read(void *opaque, hwaddr addr,
+ unsigned size)
+{
+PnvPervChiplet *perv_chiplet = PNV_PERVCHIPLET(opaque);
+int reg = addr >> 3;
+uint64_t val = ~0ull;


White line please


+/* CPLT_CTRL0 to CPLT_CTRL5 */
+for (int i = 0; i <= 5; i++) {


I would introduce a #define for this "5" value, and use it in ControlRegs also.


+if (reg == i) {
+val = perv_chiplet->control_regs.cplt_ctrl[i];
+return val;


or may be :

   return perv_chiplet->control_regs.cplt_ctrl[i];  ?
 


+} else if ((reg == (i + 0x10)) || (reg == (i + 0x20))) {
+qemu_log_mask(LOG_GUEST_ERROR, "%s: Write only register, ignoring "
+   "xscom read at 0x%" PRIx64 "\n",
+   __func__, (unsigned long)reg);
+return val;
+}
+}
+
+switch (reg) {
+case CPLT_CONF0:
+val = perv_chiplet->control_regs.cplt_cfg0;
+break;
+case CPLT_CONF0_OR:
+case CPLT_CONF0_CLEAR:
+qemu_log_mask(LOG_GUEST_ERROR, "%s: Write only register, ignoring "
+   "xscom read at 0x%" PRIx64 "\n",
+   __func__, (unsigned long)reg);
+break;
+case CPLT_CONF1:
+val = perv_chiplet->control_regs.cplt_cfg1;
+break;
+case CPLT_CONF1_OR:
+case CPLT_CONF1_CLEAR:
+qemu_log_mask(LOG_GUEST_ERROR, "%s: Write only register, ignoring "
+   "xscom read at 0x%" PRIx64 "\n",
+   __func__, (unsigned long)reg);
+break;
+case CPLT_STAT0:
+val = perv_chiplet->control_regs.cplt_stat0;
+break;
+case CPLT_MASK0:
+val = perv_chiplet->control_regs.cplt_mask0;
+break;
+case CPLT_PROTECT_MODE:
+val = perv_chiplet->control_regs.ctrl_protect_mode;
+break;
+case CPLT_ATOMIC_CLOCK:
+val = perv_chiplet->control_regs.ctrl_atomic_lock;
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "%s: Chiplet_control_regs: Invalid xscom "
+ "read at 0x%" PRIx64 "\n", __func__, (unsigned long)reg);
+}
+return val;
+}
+
+static void pnv_chiplet_ctrl_write(void *opaque, hwaddr addr,
+ uint64_t val, unsigned size)
+{
+PnvPervChiplet *perv_chiplet = PNV_PERVCHIPLET(opaque);
+int reg = addr >> 3;
+/* CPLT_CTRL0 to CPLT_CTRL5 */
+for (int i = 0; i <= 5; i++) {
+if (reg == i) {
+perv_chiplet->control_regs.cplt_ctrl[i] = val;
+return;
+} else if (reg == (i + 0x10)) 

Re: [PATCH v4 0/3] pnv nest1 chiplet model

[Cédric Le Goater]

Hello Chalapathi,

Please tune the "From: " email address of the series you send.
This one uses " Chalapathi V "
which is certainly from an internal IBM host. Unfortunately, we
can not reply to this user/sender.

On 11/7/23 08:41, Chalapathi V wrote:

From: Chalapathi V 

Hello,

For modularity reasons the P10 processor chip is split into multiple
chiplets individually controlled and managed by the pervasive logic.
The boundaries of these chiplets are defined based on physical design
parameters like clock grids, the nature of the functional units as well
as their pervasive requirements (e.g. clock domains). Examples of chiplet
in the P10 chip are processor cores and caches, memory controllers or IO
interfaces like PCIe. Partitioning the processor chip into these chiplets
allows the pervasive logic to test, initialize, control and manage these
chip partitions individually.

In this series, we create a nest1 chiplet model and implements the chiplet
control scom registers on nest1 chiplet. The chiplet control registers does
the initialization and configuration of a chiplet.

PATCH4: The review comments of PATCH3 has been addressed.


What do you mean by PATCH4 and PATCH3 ? Version 4 and 3 ?

Usually, people send a small changelog with the cover letter explaining
the differences between each respin. See the Zhenzhong's series "vfio:
Adopt iommufd" [1] for an example. Your series does not need that much
details, but "comments have been addressed" is not very useful.

Thanks,

C.




/nest1_chiplet (pnv-nest1-chiplet)
   /perv_chiplet (pnv-pervasive-chiplet)
 /xscom-chiplet-control-regs[0] (memory-region)

Chalapathi V (3):
   hw/ppc: Add pnv pervasive common chiplet units
   hw/ppc: Add nest1 chiplet model
   hw/ppc: Nest1 chiplet wiring

  hw/ppc/meson.build|   2 +
  hw/ppc/pnv.c  |  14 +++
  hw/ppc/pnv_nest1_chiplet.c|  94 +
  hw/ppc/pnv_pervasive.c| 213 ++
  include/hw/ppc/pnv_chip.h |   2 +
  include/hw/ppc/pnv_nest_chiplet.h |  41 
  include/hw/ppc/pnv_pervasive.h|  39 +++
  include/hw/ppc/pnv_xscom.h|   3 +
  8 files changed, 408 insertions(+)
  create mode 100644 hw/ppc/pnv_nest1_chiplet.c
  create mode 100644 hw/ppc/pnv_pervasive.c
  create mode 100644 include/hw/ppc/pnv_nest_chiplet.h
  create mode 100644 include/hw/ppc/pnv_pervasive.h

Re: disable-pie build

[Paolo Bonzini]

On Sat, Nov 11, 2023 at 3:40 AM Michael Tokarev  wrote:
>
> Hi!
>
> It looks like --disable-pie configure, which uses -fno-pie -no-pie flags
> for the compiler, is broken: it does not not tell the *linker* about the
> option, so the link fails (at least on debian bookworm):

Looks good, if you can send a patch perhaps Stefan can apply it (or
someone else can handle it in my stead, because I'm away next week).

Paolo

> /usr/bin/ld: libcommon.fa.p/hw_core_cpu-common.c.o: relocation R_X86_64_32 
> against `.rodata' can not be used when making a PIE object; recompile with
> -fPIE
> /usr/bin/ld: failed to set dynamic section sizes: bad value
>
> This is failing for *all* executables, including tests, qemu-img, etc.
>
> The following change fixes it:
>
> diff --git a/meson.build b/meson.build
> index a9c4f28247..0b7ca45d48 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -278,7 +278,8 @@ endif
>   # tries to build an executable instead of a shared library and fails.  So
>   # don't add -no-pie anywhere and cross fingers. :(
>   if not get_option('b_pie')
> -  qemu_common_flags += cc.get_supported_arguments('-fno-pie', '-no-pie')
> +  qemu_common_flags += cc.get_supported_arguments('-fno-pie')
> +  qemu_ldflags += cc.get_supported_arguments('-no-pie')
>   endif
>
>   if not get_option('stack_protector').disabled()
>
>C

[PULL 3/6] docs: document what configure does with virtual environments

[Paolo Bonzini]

Given the recent confusion around how QEMU detects the system
Meson installation, and/or decides to install its own, it is
time to fill in the "Python virtual environments and the QEMU
build system" section of the documentation.

As a curiosity, a first and partial draft of the text was generated
by an LLM[1].  It required quite a bit of editing and probably did not
save much time, but some expressions do remain in the finished text.

[1] https://chat.openai.com/share/42c1500d-71c1-480b-bab9-7ccc2c155365

Signed-off-by: Paolo Bonzini 
---
 docs/devel/build-system.rst | 88 +++--
 pythondeps.toml |  3 +-
 2 files changed, 87 insertions(+), 4 deletions(-)

diff --git a/docs/devel/build-system.rst b/docs/devel/build-system.rst
index 21f78da7d1d..43d6005881e 100644
--- a/docs/devel/build-system.rst
+++ b/docs/devel/build-system.rst
@@ -122,10 +122,78 @@ functioning.  These are performed using a few more helper 
functions:
indicated by $TMPC.
 
 
-Python virtual environments and the QEMU build system
--
+Python virtual environments and the build process
+-
+
+An important step in ``configure`` is to create a Python virtual
+environment (venv) during the configuration phase.  The Python interpreter
+comes from the ``--python`` command line option, the ``$PYTHON`` variable
+from the environment, or the system PATH, in this order.  The venv resides
+in the ``pyvenv`` directory in the build tree, and provides consistency
+in how the build process runs Python code.
+
+At this stage, ``configure`` also queries the chosen Python interpreter
+about QEMU's build dependencies.  Note that the build process does  *not*
+look for ``meson``, ``sphinx-build`` or ``avocado`` binaries in the PATH;
+likewise, there are no options such as ``--meson`` or ``--sphinx-build``.
+This avoids a potential mismatch, where Meson and Sphinx binaries on the
+PATH might operate in a different Python environment than the one chosen
+by the user during the build process.  On the other hand, it introduces
+a potential source of confusion where the user installs a dependency but
+``configure`` is not able to find it.  When this happens, the dependency
+was installed in the ``site-packages`` directory of another interpreter,
+or with the wrong ``pip`` program.
+
+If a package is available for the chosen interpreter, ``configure``
+prepares a small script that invokes it from the venv itself[#distlib]_.
+If not, ``configure`` can also optionally install dependencies in the
+virtual environment with ``pip``, either from wheels in ``python/wheels``
+or by downloading the package with PyPI.  Downloading can be disabled with
+``--disable-download``; and anyway, it only happens when a ``configure``
+option (currently, only ``--enable-docs``) is explicitly enabled but
+the dependencies are not present[#pip]_.
+
+.. [#distlib] The scripts are created based on the package's metadata,
+  specifically the ``console_script`` entry points.  This is the
+  same mechanism that ``pip`` uses when installing a package.
+  Currently, in all cases it would be possible to use ``python -m``
+  instead of an entry point script, which makes this approach a
+  bit overkill.  On the other hand, creating the scripts is
+  future proof and it makes the contents of the ``pyvenv/bin``
+  directory more informative.  Portability is also not an issue,
+  because the Python Packaging Authority provides a package
+  ``distlib.scripts`` to perform this task.
+
+.. [#pip] ``pip`` might also be used when running ``make check-avocado``
+   if downloading is enabled, to ensure that Avocado is
+   available.
+
+The required versions of the packages are stored in a configuration file
+``pythondeps.toml``.  The format is custom to QEMU, but it is documented
+at the top of the file itself and it should be easy to understand.  The
+requirements should make it possible to use the version that is packaged
+that is provided by supported distros.
+
+When dependencies are downloaded, instead, ``configure`` uses a "known
+good" version that is also listed in ``pythondeps.toml``.  In this
+scenario, ``pythondeps.toml`` behaves like the "lock file" used by
+``cargo``, ``poetry`` or other dependency management systems.
+
+
+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).
+
+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 

[PULL 5/6] .gitlab-ci.d/cirrus: Upgrade macOS to 13 (Ventura)

[Paolo Bonzini]

From: Philippe Mathieu-Daudé 

macOS 14 "Sonoma" was released on September 2023 [1].

According to QEMU's support policy, we stop supporting the
previous major release two years after the the new major
release has been published. Replace the macOS 12 (Monterey)
testing by macOS 13 (Ventura, released on October 2022, [2]).

Refresh the generated files by running:

  $ make lcitool-refresh

[1] https://www.apple.com/newsroom/2023/09/macos-sonoma-is-available-today/
[2] https://www.apple.com/newsroom/2022/10/macos-ventura-is-now-available/

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Daniel P. Berrangé 
Message-ID: <20231108162022.76189-1-phi...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 .gitlab-ci.d/cirrus.yml  | 6 +++---
 .gitlab-ci.d/cirrus/{macos-12.vars => macos-13.vars} | 2 +-
 tests/lcitool/refresh| 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)
 rename .gitlab-ci.d/cirrus/{macos-12.vars => macos-13.vars} (95%)

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index e7f1f83c2c4..07dc6edae1c 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -59,13 +59,13 @@ x64-freebsd-13-build:
 INSTALL_COMMAND: pkg install -y
 TEST_TARGETS: check
 
-aarch64-macos-12-base-build:
+aarch64-macos-13-base-build:
   extends: .cirrus_build_job
   variables:
-NAME: macos-12
+NAME: macos-13
 CIRRUS_VM_INSTANCE_TYPE: macos_instance
 CIRRUS_VM_IMAGE_SELECTOR: image
-CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-monterey-base:latest
+CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-ventura-base:latest
 CIRRUS_VM_CPUS: 12
 CIRRUS_VM_RAM: 24G
 UPDATE_COMMAND: brew update
diff --git a/.gitlab-ci.d/cirrus/macos-12.vars 
b/.gitlab-ci.d/cirrus/macos-13.vars
similarity index 95%
rename from .gitlab-ci.d/cirrus/macos-12.vars
rename to .gitlab-ci.d/cirrus/macos-13.vars
index 5f3fb346d1d..534f0299560 100644
--- a/.gitlab-ci.d/cirrus/macos-12.vars
+++ b/.gitlab-ci.d/cirrus/macos-13.vars
@@ -1,6 +1,6 @@
 # THIS FILE WAS AUTO-GENERATED
 #
-#  $ lcitool variables macos-12 qemu
+#  $ lcitool variables macos-13 qemu
 #
 # https://gitlab.com/libvirt/libvirt-ci
 
diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index 92e7d30982e..2259f131b48 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -196,7 +196,7 @@ try:
 # Cirrus packages lists for GitLab
 #
 generate_cirrus("freebsd-13")
-generate_cirrus("macos-12")
+generate_cirrus("macos-13")
 
 #
 # VM packages lists
-- 
2.41.0

[PULL 0/6] Biuld system and CI changes for 2023-11-10

[Paolo Bonzini]

The following changes since commit ad6ef0a42e314a8c6ac6c96d5f6e607a1e5644b5:

  Merge tag 'for-upstream' of https://repo.or.cz/qemu/kevin into staging 
(2023-11-09 08:26:01 +0800)

are available in the Git repository at:

  https://gitlab.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to 1d802d050caeff83add1054bee1fc9f98e59a3f2:

  .gitlab-ci.d/cirrus: Add manual testing of macOS 14 (Sonoma) (2023-11-10 
10:39:05 +0100)


* document what configure does with virtual environments
* Bump known good meson version to v1.2.3
* Upgrade macOS to 13 (Ventura) and Add manual testing of macOS 14 (Sonoma)
* use simple assertions instead of Coverity models


Paolo Bonzini (2):
  tests: respect --enable/--disable-download for Avocado
  docs: document what configure does with virtual environments

Philippe Mathieu-Daudé (3):
  buildsys: Bump known good meson version to v1.2.3
  .gitlab-ci.d/cirrus: Upgrade macOS to 13 (Ventura)
  .gitlab-ci.d/cirrus: Add manual testing of macOS 14 (Sonoma)

Vladimir Sementsov-Ogievskiy (1):
  coverity: physmem: use simple assertions instead of modelling

 .gitlab-ci.d/cirrus.yml|  22 +-
 .../cirrus/{macos-12.vars => macos-13.vars}|   2 +-
 .gitlab-ci.d/cirrus/macos-14.vars  |  16 
 configure  |   9 ++-
 docs/devel/build-system.rst|  88 -
 python/scripts/vendor.py   |   4 +-
 python/wheels/meson-0.63.3-py3-none-any.whl| Bin 926526 -> 0 bytes
 python/wheels/meson-1.2.3-py3-none-any.whl | Bin 0 -> 964928 bytes
 pythondeps.toml|   5 +-
 scripts/coverity-scan/model.c  |  88 -
 system/physmem.c   |  22 ++
 tests/Makefile.include |   2 +-
 tests/lcitool/libvirt-ci   |   2 +-
 tests/lcitool/refresh  |   3 +-
 14 files changed, 157 insertions(+), 106 deletions(-)
 rename .gitlab-ci.d/cirrus/{macos-12.vars => macos-13.vars} (95%)
 create mode 100644 .gitlab-ci.d/cirrus/macos-14.vars
 delete mode 100644 python/wheels/meson-0.63.3-py3-none-any.whl
 create mode 100644 python/wheels/meson-1.2.3-py3-none-any.whl
-- 
2.41.0

[PULL 2/6] tests: respect --enable/--disable-download for Avocado

[Paolo Bonzini]

Pass the content of $mkvenv_flags (which is either "--online"
or empty) down to tests/Makefile.include.

Signed-off-by: Paolo Bonzini 
---
 configure  | 9 +
 tests/Makefile.include | 2 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index abcb199aa87..2da3c278db6 100755
--- a/configure
+++ b/configure
@@ -968,14 +968,14 @@ meson="$(cd pyvenv/bin; pwd)/meson"
 
 # Conditionally ensure Sphinx is installed.
 
-mkvenv_flags=""
-if test "$download" = "enabled" -a "$docs" = "enabled" ; then
-mkvenv_flags="--online"
+mkvenv_online_flag=""
+if test "$download" = "enabled" ; then
+mkvenv_online_flag=" --online"
 fi
 
 if test "$docs" != "disabled" ; then
 if ! $mkvenv ensuregroup \
- $mkvenv_flags \
+ $(test "$docs" = "enabled" && echo "$mkvenv_online_flag") \
  ${source_path}/pythondeps.toml docs;
 then
 if test "$docs" = "enabled" ; then
@@ -1631,6 +1631,7 @@ if test "$container" != no; then
 fi
 echo "SUBDIRS=$subdirs" >> $config_host_mak
 echo "PYTHON=$python" >> $config_host_mak
+echo "MKVENV_ENSUREGROUP=$mkvenv ensuregroup $mkvenv_online_flag" >> 
$config_host_mak
 echo "GENISOIMAGE=$genisoimage" >> $config_host_mak
 echo "MESON=$meson" >> $config_host_mak
 echo "NINJA=$ninja" >> $config_host_mak
diff --git a/tests/Makefile.include b/tests/Makefile.include
index dab1989a071..c9d1674bd07 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -111,7 +111,7 @@ quiet-venv-pip = $(quiet-@)$(call quiet-command-run, \
 
 $(TESTS_VENV_TOKEN): $(SRC_PATH)/pythondeps.toml
$(call quiet-venv-pip,install -e "$(SRC_PATH)/python/")
-   $(PYTHON) python/scripts/mkvenv.py ensuregroup --online $< avocado
+   $(MKVENV_ENSUREGROUP) $< avocado
$(call quiet-command, touch $@)
 
 $(TESTS_RESULTS_DIR):
-- 
2.41.0

[PULL 1/6] coverity: physmem: use simple assertions instead of modelling

[Paolo Bonzini]

From: Vladimir Sementsov-Ogievskiy 

Unfortunately Coverity doesn't follow the logic aroung "len" and "l"
variables in stacks finishing with flatview_{read,write}_continue() and
generate a lot of OVERRUN false-positives. When small buffer (2 or 4
bytes) is passed to mem read/write path, Coverity assumes the worst
case of sz=8 in stn_he_p()/ldn_he_p() (defined in
include/qemu/bswap.h), and reports buffer overrun.

To silence these false-positives we have model functions, which hide
real logic from Coverity.

However, it turned out that these new two assertions are enough to
quiet Coverity.

Assertions are better than hiding the logic, so let's drop the
modelling and move to assertions for memory r/w call stacks.

After patch, the sequence

 cov-make-library --output-file /tmp/master.xmldb \
scripts/coverity-scan/model.c
 cov-build --dir ~/covtmp/master make -j9
 cov-analyze --user-model-file /tmp/master.xmldb \
--dir ~/covtmp/master --all --strip-path "$(pwd)
 cov-format-errors --dir ~/covtmp/master \
--html-output ~/covtmp/master_html_report

Generate for me the same big set of CIDs excepept for 6 disappeared (so
it becomes even better).

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Acked-by: David Hildenbrand 
Message-ID: <20231005140326.332830-1-vsement...@yandex-team.ru>
Signed-off-by: Paolo Bonzini 
---
 scripts/coverity-scan/model.c | 88 ---
 system/physmem.c  | 22 +
 2 files changed, 22 insertions(+), 88 deletions(-)

diff --git a/scripts/coverity-scan/model.c b/scripts/coverity-scan/model.c
index 686d1a30089..a064d840849 100644
--- a/scripts/coverity-scan/model.c
+++ b/scripts/coverity-scan/model.c
@@ -42,94 +42,6 @@ typedef _Bool bool;
 
 typedef struct va_list_str *va_list;
 
-/* exec.c */
-
-typedef struct AddressSpace AddressSpace;
-typedef struct MemoryRegionCache MemoryRegionCache;
-typedef uint64_t hwaddr;
-typedef uint32_t MemTxResult;
-typedef struct MemTxAttrs {} MemTxAttrs;
-
-static void __bufwrite(uint8_t *buf, ssize_t len)
-{
-int first, last;
-__coverity_negative_sink__(len);
-if (len == 0) return;
-buf[0] = first;
-buf[len-1] = last;
-__coverity_writeall__(buf);
-}
-
-static void __bufread(uint8_t *buf, ssize_t len)
-{
-__coverity_negative_sink__(len);
-if (len == 0) return;
-int first = buf[0];
-int last = buf[len-1];
-}
-
-MemTxResult address_space_read_cached(MemoryRegionCache *cache, hwaddr addr,
-  MemTxAttrs attrs,
-  void *buf, int len)
-{
-MemTxResult result;
-// TODO: investigate impact of treating reads as producing
-// tainted data, with __coverity_tainted_data_argument__(buf).
-__bufwrite(buf, len);
-return result;
-}
-
-MemTxResult address_space_write_cached(MemoryRegionCache *cache, hwaddr addr,
-MemTxAttrs attrs,
-const void *buf, int len)
-{
-MemTxResult result;
-__bufread(buf, len);
-return result;
-}
-
-MemTxResult address_space_rw_cached(MemoryRegionCache *cache, hwaddr addr,
-MemTxAttrs attrs,
-void *buf, int len, bool is_write)
-{
-if (is_write) {
-return address_space_write_cached(cache, addr, attrs, buf, len);
-} else {
-return address_space_read_cached(cache, addr, attrs, buf, len);
-}
-}
-
-MemTxResult address_space_read(AddressSpace *as, hwaddr addr,
-   MemTxAttrs attrs,
-   void *buf, int len)
-{
-MemTxResult result;
-// TODO: investigate impact of treating reads as producing
-// tainted data, with __coverity_tainted_data_argument__(buf).
-__bufwrite(buf, len);
-return result;
-}
-
-MemTxResult address_space_write(AddressSpace *as, hwaddr addr,
-MemTxAttrs attrs,
-const void *buf, int len)
-{
-MemTxResult result;
-__bufread(buf, len);
-return result;
-}
-
-MemTxResult address_space_rw(AddressSpace *as, hwaddr addr,
- MemTxAttrs attrs,
- void *buf, int len, bool is_write)
-{
-if (is_write) {
-return address_space_write(as, addr, attrs, buf, len);
-} else {
-return address_space_read(as, addr, attrs, buf, len);
-}
-}
-
 /* Tainting */
 
 typedef struct {} name2keysym_t;
diff --git a/system/physmem.c b/system/physmem.c
index fc2b0fee018..a63853a7bc9 100644
--- a/system/physmem.c
+++ b/system/physmem.c
@@ -2699,6 +2699,17 @@ static MemTxResult flatview_write_continue(FlatView *fv, 
hwaddr addr,
 l = memory_access_size(mr, l, addr1);
 /* XXX: could force current_cpu to NULL to avoid
potential bugs */
+
+/*
+ * Assure Coverity (and ourselves) that we are not going to OVERRUN
+ * the buffer 

[PULL 6/6] .gitlab-ci.d/cirrus: Add manual testing of macOS 14 (Sonoma)

[Paolo Bonzini]

From: Philippe Mathieu-Daudé 

Upgrade libvirt-ci so it covers macOS 14. Add a manual entry
(QEMU_JOB_OPTIONAL: 1) to test on Sonoma release. Refresh the
lci-tool generated files.

Signed-off-by: Philippe Mathieu-Daudé 
Message-ID: <20231109160504.93677-3-phi...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 .gitlab-ci.d/cirrus.yml   | 16 
 .gitlab-ci.d/cirrus/macos-14.vars | 16 
 tests/lcitool/libvirt-ci  |  2 +-
 tests/lcitool/refresh |  1 +
 4 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 .gitlab-ci.d/cirrus/macos-14.vars

diff --git a/.gitlab-ci.d/cirrus.yml b/.gitlab-ci.d/cirrus.yml
index 07dc6edae1c..64f2e25afab 100644
--- a/.gitlab-ci.d/cirrus.yml
+++ b/.gitlab-ci.d/cirrus.yml
@@ -74,6 +74,22 @@ aarch64-macos-13-base-build:
 PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
 TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
 
+aarch64-macos-14-base-build:
+  extends: .cirrus_build_job
+  variables:
+NAME: macos-14
+CIRRUS_VM_INSTANCE_TYPE: macos_instance
+CIRRUS_VM_IMAGE_SELECTOR: image
+CIRRUS_VM_IMAGE_NAME: ghcr.io/cirruslabs/macos-sonoma-base:latest
+CIRRUS_VM_CPUS: 12
+CIRRUS_VM_RAM: 24G
+UPDATE_COMMAND: brew update
+INSTALL_COMMAND: brew install
+PATH_EXTRA: /opt/homebrew/ccache/libexec:/opt/homebrew/gettext/bin
+PKG_CONFIG_PATH: 
/opt/homebrew/curl/lib/pkgconfig:/opt/homebrew/ncurses/lib/pkgconfig:/opt/homebrew/readline/lib/pkgconfig
+TEST_TARGETS: check-unit check-block check-qapi-schema check-softfloat 
check-qtest-x86_64
+QEMU_JOB_OPTIONAL: 1
+
 
 # The following jobs run VM-based tests via KVM on a Linux-based Cirrus-CI job
 .cirrus_kvm_job:
diff --git a/.gitlab-ci.d/cirrus/macos-14.vars 
b/.gitlab-ci.d/cirrus/macos-14.vars
new file mode 100644
index 000..43070f4a265
--- /dev/null
+++ b/.gitlab-ci.d/cirrus/macos-14.vars
@@ -0,0 +1,16 @@
+# THIS FILE WAS AUTO-GENERATED
+#
+#  $ lcitool variables macos-14 qemu
+#
+# https://gitlab.com/libvirt/libvirt-ci
+
+CCACHE='/opt/homebrew/bin/ccache'
+CPAN_PKGS=''
+CROSS_PKGS=''
+MAKE='/opt/homebrew/bin/gmake'
+NINJA='/opt/homebrew/bin/ninja'
+PACKAGING_COMMAND='brew'
+PIP3='/opt/homebrew/bin/pip3'
+PKGS='bash bc bison bzip2 capstone ccache cmocka ctags curl dbus diffutils dtc 
flex gcovr gettext git glib gnu-sed gnutls gtk+3 jemalloc jpeg-turbo json-c 
libepoxy libffi libgcrypt libiscsi libnfs libpng libslirp libssh libtasn1 
libusb llvm lzo make meson mtools ncurses nettle ninja pixman pkg-config 
python3 rpm2cpio sdl2 sdl2_image snappy socat sparse spice-protocol swtpm 
tesseract usbredir vde vte3 xorriso zlib zstd'
+PYPI_PKGS='PyYAML numpy pillow sphinx sphinx-rtd-theme tomli'
+PYTHON='/opt/homebrew/bin/python3'
diff --git a/tests/lcitool/libvirt-ci b/tests/lcitool/libvirt-ci
index 36bc517161c..77c800186f3 16
--- a/tests/lcitool/libvirt-ci
+++ b/tests/lcitool/libvirt-ci
@@ -1 +1 @@
-Subproject commit 36bc517161c45ead20224d47f2dc4fa428af6724
+Subproject commit 77c800186f34b21be7660750577cc5582a914deb
diff --git a/tests/lcitool/refresh b/tests/lcitool/refresh
index 2259f131b48..e11d0ba381f 100755
--- a/tests/lcitool/refresh
+++ b/tests/lcitool/refresh
@@ -197,6 +197,7 @@ try:
 #
 generate_cirrus("freebsd-13")
 generate_cirrus("macos-13")
+generate_cirrus("macos-14")
 
 #
 # VM packages lists
-- 
2.41.0

[PULL 4/6] buildsys: Bump known good meson version to v1.2.3

[Paolo Bonzini]

From: Philippe Mathieu-Daudé 

We need meson v1.2.3 to build QEMU on macOS Sonoma.  It
also builds fine all our CI jobs (as tested by also bumping
"accepted" in pythondeps.toml), so let's use it as our
"good enough" packaged wheel.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1939
Suggested-by: Paolo Bonzini 
Signed-off-by: Philippe Mathieu-Daudé 
Message-ID: <20231109160504.93677-2-phi...@linaro.org>
Signed-off-by: Paolo Bonzini 
---
 python/scripts/vendor.py|   4 ++--
 python/wheels/meson-0.63.3-py3-none-any.whl | Bin 926526 -> 0 bytes
 python/wheels/meson-1.2.3-py3-none-any.whl  | Bin 0 -> 964928 bytes
 pythondeps.toml |   2 +-
 4 files changed, 3 insertions(+), 3 deletions(-)
 delete mode 100644 python/wheels/meson-0.63.3-py3-none-any.whl
 create mode 100644 python/wheels/meson-1.2.3-py3-none-any.whl

diff --git a/python/scripts/vendor.py b/python/scripts/vendor.py
index 76274871170..1038b14ae0c 100755
--- a/python/scripts/vendor.py
+++ b/python/scripts/vendor.py
@@ -41,8 +41,8 @@ def main() -> int:
 parser.parse_args()
 
 packages = {
-"meson==0.63.3":
-"d677b809c4895dcbaac9bf6c43703fcb3609a4b24c6057c78f828590049cf43a",
+"meson==1.2.3":
+"4533a43c34548edd1f63a276a42690fce15bde9409bcf20c4b8fa3d7e4d7cac1",
 
 "tomli==2.0.1":
 "939de3e7a6161af0c887ef91b7d41a53e7c5a1ca976325f429cb46ea9bc30ecc",
diff --git a/python/wheels/meson-0.63.3-py3-none-any.whl 
b/python/wheels/meson-0.63.3-py3-none-any.whl
deleted file mode 100644
index 
8a191e3a200eba6783297676729ec85ceb96f89d..
Binary files a/python/wheels/meson-0.63.3-py3-none-any.whl and /dev/null differ
diff --git a/python/wheels/meson-1.2.3-py3-none-any.whl 
b/python/wheels/meson-1.2.3-py3-none-any.whl
new file mode 100644
index 
..a8b84e5f114ad3fbec8ae56008426a90bccfc168
GIT binary patch
Binary files /dev/null and b/python/wheels/meson-1.2.3-py3-none-any.whl differ
diff --git a/pythondeps.toml b/pythondeps.toml
index 4beadfd96f5..0e884159993 100644
--- a/pythondeps.toml
+++ b/pythondeps.toml
@@ -19,7 +19,7 @@
 
 [meson]
 # The install key should match the version in python/wheels/
-meson = { accepted = ">=0.63.0", installed = "0.63.3", canary = "meson" }
+meson = { accepted = ">=0.63.0", installed = "1.2.3", canary = "meson" }
 
 [docs]
 sphinx = { accepted = ">=1.6", installed = "5.3.0", canary = "sphinx-build" }
-- 
2.41.0

Re: [PATCH v6 11/21] virtio-net: Return an error when vhost cannot enable RSS

[Akihiko Odaki]

On 2023/11/03 22:14, Yuri Benditovich wrote:



On Fri, Nov 3, 2023 at 11:55 AM Akihiko Odaki > wrote:


On 2023/11/03 18:35, Yuri Benditovich wrote:
 >
 >
 > On Thu, Nov 2, 2023 at 4:56 PM Akihiko Odaki
mailto:akihiko.od...@daynix.com>
 > >> wrote:
 >
 >     On 2023/11/02 19:20, Yuri Benditovich wrote:
 >      >
 >      >
 >      > On Thu, Nov 2, 2023 at 11:33 AM Michael S. Tsirkin
 >     mailto:m...@redhat.com>
>
 >      > 
      >
 >      >     On Thu, Nov 02, 2023 at 11:09:27AM +0200, Yuri
Benditovich wrote:
 >      >      > Probably we mix two different patches in this
discussion.
 >      >      > Focusing on the patch in the e-mail header:
 >      >      >
 >      >      > IMO it is not acceptable to fail QEMU run for one
feature
 >     that we
 >      >     can't make
 >      >      > active when we silently drop all other features in
such a
 >     case.
 >      >
 >      >     If the feature is off by default then it seems more
reasonable
 >      >     and silent masking can be seen as a bug.
 >      >     Most virtio features are on by default this is why it's
 >      >     reasonable to mask them.
 >      >
 >      >
 >      > If we are talking about RSS: setting it initially off is the
 >     development
 >      > time decision.
 >      > When it will be completely stable there is no reason to
keep it
 >     off by
 >      > default, so this is more a question of time and of a
readiness of
 >     libvirt.
 >
 >     It is not ok to make "on" the default; that will enable RSS
even when
 >     eBPF steering support is not present and can result in
performance
 >     degradation.
 >
 >
 > Exactly as it is today - with vhost=on the host does not suggest RSS
 > without  eBPF.
 > I do not understand what you call "performance degradation", can you
 > describe the scenario?

I was not clear, but I was talking about the case of vhost=off or peers
other than tap (e.g., user). rss=on employs in-qemu RSS, which incurs
overheads for such configurations.


So, vhost=off OR peers other than tap:

In the case of peers other than tap (IMO) we're not talking about 
performance at all.
Backends like "user" (without vnet_hdr) do not support _many_ 
performance-oriented features.
If RSS is somehow "supported" for such backends this is rather a 
misunderstanding (IMO again).


We do not need to ensure good performance when RSS is enabled by the 
guest for backends without eBPF steering program as you say. In-QEMU RSS 
is only useful for testing and not meant to improve the performance.


However, if you set rss=on, QEMU will advertise the availability of RSS 
feature. The guest will have no mean to know if it's implemented in a 
way not performance-wise so it may decide to use the feature to improve 
the performance, which can result in performance degradation. Therefore, 
it's better not to set rss=on for such backends.

Re: [PATCH 1/1] ui/cocoa: add zoom-interpolation display option

[Akihiko Odaki]

On 2023/11/11 1:17, carwynel...@gmail.com wrote:

From: Carwyn Ellis 

Provides a new display option, zoom-interpolation, that enables
interpolation of the scaled display when zoom-to-fit is enabled.

Also provides a corresponding view menu item to allow this to be toggled
as required.

Signed-off-by: Carwyn Ellis 


Reviewed-by: Akihiko Odaki 

Re: [PATCH v6 06/21] net: Remove flag propagation

[Akihiko Odaki]

On 2023/11/10 16:35, Pavel Dovgalyuk wrote:
You need to bump REPLAY_VERSION in replay/replay.c, because your patch 
changes the replay log format.


Otherwise, for replay part:
Acked-by: Pavel Dovgalyuk 


I'll drop this change then. It's just a cleanup and does not bring an 
additional benefit worth breaking the log format.

Re: [PATCH] hw/audio/es1370: Clean up comment

[Volker Rümelin]

Am 10.11.23 um 17:43 schrieb Peter Maydell:
> Replace a sweary comment with one that's a bit more helpful to
> future readers of the code.
>
> Signed-off-by: Peter Maydell 

Reviewed-by: Volker Rümelin 

> ---
>  hw/audio/es1370.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/hw/audio/es1370.c b/hw/audio/es1370.c
> index 91c47330ad3..fad55412119 100644
> --- a/hw/audio/es1370.c
> +++ b/hw/audio/es1370.c
> @@ -670,8 +670,13 @@ static void es1370_transfer_audio (ES1370State *s, 
> struct chan *d, int loop_sel,
>  cnt += (transferred + d->leftover) >> 2;
>  
>  if (s->sctl & loop_sel) {
> -/* Bah, how stupid is that having a 0 represent true value?
> -   i just spent few hours on this shit */
> +/*
> + * loop_sel tells us which bit in the SCTL register to look at
> + * (either P1_LOOP_SEL, P2_LOOP_SEL or R1_LOOP_SEL). The sense
> + * of these bits is 0 for loop mode (set interrupt and keep recording
> + * when the sample count reaches zero) or 1 for stop mode (set
> + * interrupt and stop recording).
> + */
>  AUD_log ("es1370: warning", "non looping mode\n");
>  } else {
>  d->frame_cnt = size;

Re: [PATCH v1 1/7] xen-block: Do not write frontend nodes

[Andrew Cooper]

On 11/11/2023 10:55 am, David Woodhouse wrote:
> On Fri, 2023-11-10 at 20:42 +, Volodymyr Babchuk wrote:
>> From: Oleksandr Tyshchenko 
>>
>> The PV backend running in other than Dom0 domain (non toolstack domain)
>> is not allowed to write frontend nodes. The more, the backend does not
>> need to do that at all, this is purely toolstack/xl devd business.
>>
>> I do not know for what reason the backend does that here, this is not really
>> needed, probably it is just a leftover and all xen_device_frontend_printf()
>> instances should go away completely.
> No, this is what allows qemu to create PV devices, as opposed to just
> handle the ones which are created for it by the toolstack.
>
> Perhaps we should only create the frontend nodes (and likewise, only
> destroy those and the backend nodes on destruction) in the case where
> the device was instantiated directly by the QEMU command line, and
> refrain from doing so for the devices which were created by the
> toolstack and merely 'discovered' by xen_block_device_create()?
>
> (Note that we need to look at net and console devices too, now they've
> finally been converted to the 'new' XenBus framework in QEMU 8.2.)
>
>

Furthermore, the control domain doesn't always have the domid of 0.

If qemu wants/needs to make changes like this, the control domain has to
arrange for qemu's domain to have appropriate permissions on the nodes.

~Andrew

Re: [PATCH for 8.2] ui/gtk-egl: move function calls back to regular code path

[Volker Rümelin]

Cc: Antonio

> Commit 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing
> scanout") introduced a regression when QEMU is running with a
> virtio-gpu-gl-device on a host under X11. After the guest has
> initialized the virtio-gpu-gl-device, the guest screen only
> shows "Display output is not active.".
>
> Commit 6f189a08c1 moved all function calls in
> gd_egl_scanout_texture() to a code path which is only called
> once after gd_egl_init() succeeds in gd_egl_scanout_texture().
> Move all function calls in gd_egl_scanout_texture() back to
> the regular code path so they get always called if one of the
> gd_egl_init() calls was successful.
>
> Fixes: 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing scanout")
> Signed-off-by: Volker Rümelin 
> ---
>  ui/gtk-egl.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
> index cd2f176502..3af5ac5bcf 100644
> --- a/ui/gtk-egl.c
> +++ b/ui/gtk-egl.c
> @@ -249,14 +249,14 @@ void gd_egl_scanout_texture(DisplayChangeListener *dcl,
>  if (!vc->gfx.esurface) {
>  return;
>  }
> +}
>  
> -eglMakeCurrent(qemu_egl_display, vc->gfx.esurface,
> -   vc->gfx.esurface, vc->gfx.ectx);
> +eglMakeCurrent(qemu_egl_display, vc->gfx.esurface,
> +   vc->gfx.esurface, vc->gfx.ectx);
>  
> -gtk_egl_set_scanout_mode(vc, true);
> -egl_fb_setup_for_tex(>gfx.guest_fb, backing_width, 
> backing_height,
> - backing_id, false);
> -}
> +gtk_egl_set_scanout_mode(vc, true);
> +egl_fb_setup_for_tex(>gfx.guest_fb, backing_width, backing_height,
> + backing_id, false);
>  }
>  
>  void gd_egl_scanout_dmabuf(DisplayChangeListener *dcl,

Re: [PATCH v1 5/7] xen-bus: Set offline if backend's state is XenbusStateClosed

[David Woodhouse]

(When sending a series, if you Cc someone on one message please could you Cc 
them on the whole thread for context? Thanks.)

> Both state (XenbusStateClosed) and online (0) are expected by
> toolstack/xl devd to completely destroy the device. But "offline"
> is never being set by the backend resulting in timeout during
> domain destruction, garbage in Xestore and still running Qemu
> instance.

I would dearly love to see a clear state diagram showing all the possible state 
transitions during device creation, fe/be reconnecting, and hot plug/unplug. 
Does anything like that exist? Any test cases for the common and the less 
common transitions, and even the illegal ones which need to be handled 
gracefully?

Fantasy aside, can you please confirm that this patch series was tested with 
hotplug (device_add in the monitor) *and* unplug in QEMU, both under real Xen 
and ideally also emulated Xen in KVM? 

Thanks.

[PATCH] linux-user: xtensa: fix signal delivery in FDPIC

[Max Filippov]

In FDPIC signal handlers are passed around as FD pointers. Actual code
address and GOT pointer must be fetched from memory by the QEMU code
that implements kernel signal delivery functionality. This change is
equivalent to the following kernel change:
9c2cc74fb31e ("xtensa: fix signal delivery to FDPIC process")

Cc: qemu-sta...@nongnu.org
Fixes: d2796be69d7c ("linux-user: add support for xtensa FDPIC")
Signed-off-by: Max Filippov 
---
 linux-user/xtensa/signal.c | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/linux-user/xtensa/signal.c b/linux-user/xtensa/signal.c
index f5fb8b5cbebe..32dcfa522919 100644
--- a/linux-user/xtensa/signal.c
+++ b/linux-user/xtensa/signal.c
@@ -157,6 +157,9 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
 {
 abi_ulong frame_addr;
 struct target_rt_sigframe *frame;
+int is_fdpic = info_is_fdpic(((TaskState *)thread_cpu->opaque)->info);
+abi_ulong handler = 0;
+abi_ulong handler_fdpic_GOT = 0;
 uint32_t ra;
 bool abi_call0;
 unsigned base;
@@ -165,6 +168,17 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
 frame_addr = get_sigframe(ka, env, sizeof(*frame));
 trace_user_setup_rt_frame(env, frame_addr);
 
+if (is_fdpic) {
+abi_ulong funcdesc_ptr = ka->_sa_handler;
+
+if (get_user_ual(handler, funcdesc_ptr)
+|| get_user_ual(handler_fdpic_GOT, funcdesc_ptr + 4)) {
+goto give_sigsegv;
+}
+} else {
+handler = ka->_sa_handler;
+}
+
 if (!lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0)) {
 goto give_sigsegv;
 }
@@ -185,14 +199,21 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
 }
 
 if (ka->sa_flags & TARGET_SA_RESTORER) {
-ra = ka->sa_restorer;
+if (is_fdpic) {
+if (get_user_ual(ra, ka->sa_restorer)) {
+unlock_user_struct(frame, frame_addr, 0);
+goto give_sigsegv;
+}
+} else {
+ra = ka->sa_restorer;
+}
 } else {
 /* Not used, but retain for ABI compatibility. */
 install_sigtramp(frame->retcode);
 ra = default_rt_sigreturn;
 }
 memset(env->regs, 0, sizeof(env->regs));
-env->pc = ka->_sa_handler;
+env->pc = handler;
 env->regs[1] = frame_addr;
 env->sregs[WINDOW_BASE] = 0;
 env->sregs[WINDOW_START] = 1;
@@ -212,6 +233,9 @@ void setup_rt_frame(int sig, struct target_sigaction *ka,
 env->regs[base + 3] = frame_addr + offsetof(struct target_rt_sigframe,
 info);
 env->regs[base + 4] = frame_addr + offsetof(struct target_rt_sigframe, uc);
+if (is_fdpic) {
+env->regs[base + 11] = handler_fdpic_GOT;
+}
 unlock_user_struct(frame, frame_addr, 1);
 return;
 
-- 
2.39.2

Re: [PATCH v1 3/7] xen: xenstore: add possibility to preserve owner

[David Woodhouse]

On Fri, 2023-11-10 at 20:42 +, Volodymyr Babchuk wrote:
> Add option to preserve owner when creating an entry in Xen Store. This
> may be needed in cases when Qemu is working as device model in a
> domain that is Domain-0, e.g. in driver domain.
> 
> "owner" parameter for qemu_xen_xs_create() function can have special
> value XS_PRESERVE_OWNER, which will make specific implementation to
> get original owner of an entry and pass it back to
> set_permissions() call.
> 
> Signed-off-by: Volodymyr Babchuk 

I like this, although I'd like it more if XenStore itself offered this
facility rather than making QEMU do it. Can we make it abundantly clear
that XS_PRESERVE_OWNER is a QEMU internal thing?

>  hw/i386/kvm/xen_xenstore.c   | 18 ++
>  hw/xen/xen-operations.c  | 12 
>  include/hw/xen/xen_backend_ops.h |  2 ++
>  3 files changed, 32 insertions(+)
> 
> diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
> index 660d0b72f9..7b894a9884 100644
> --- a/hw/i386/kvm/xen_xenstore.c
> +++ b/hw/i386/kvm/xen_xenstore.c
> @@ -1572,6 +1572,24 @@ static bool xs_be_create(struct qemu_xs_handle *h, 
> xs_transaction_t t,
>  return false;
>  }
>  
> +    if (owner == XS_PRESERVE_OWNER) {
> +    GList *perms;
> +    char letter;
> +
> +    err = xs_impl_get_perms(h->impl, 0, t, path, );
> +    if (err) {
> +    errno = err;
> +    return false;
> +    }

I guess we get away without a race here because it's all internal and
we're holding the QEMU iothread mutex? Perhaps assert that?

> +    if (sscanf(perms->data, "%c%u", , ) != 2) {

I'd be slightly happier if you used parse_perm() from xenstore_impl.c,
but it's static so I suppose that's fair enough.

> +    errno = EFAULT;
> +    g_list_free_full(perms, g_free);
> +    return false;
> +    }
> +    g_list_free_full(perms, g_free);
> +    }
> +
>  perms_list = g_list_append(perms_list,
>     xs_perm_as_string(XS_PERM_NONE, owner));
>  perms_list = g_list_append(perms_list,
> diff --git a/hw/xen/xen-operations.c b/hw/xen/xen-operations.c
> index e00983ec44..1df59b3c08 100644
> --- a/hw/xen/xen-operations.c
> +++ b/hw/xen/xen-operations.c
> @@ -300,6 +300,18 @@ static bool libxenstore_create(struct qemu_xs_handle *h, 
> xs_transaction_t t,
>  return false;
>  }
>  
> +    if (owner == XS_PRESERVE_OWNER) {
> +    struct xs_permissions *tmp;
> +    unsigned int num;
> +
> +    tmp = xs_get_permissions(h->xsh, 0, path, );
> +    if (tmp == NULL) {
> +    return false;
> +    }
> +    perms_list[0].id = tmp[0].id;
> +    free(tmp);
> +    }
> +

Don't see what saves you from someone else changing it at this point on
true Xen though. Which is why I'd prefer XenStore to do it natively.

>  return xs_set_permissions(h->xsh, t, path, perms_list,
>    ARRAY_SIZE(perms_list));
>  }
> diff --git a/include/hw/xen/xen_backend_ops.h 
> b/include/hw/xen/xen_backend_ops.h
> index 90cca85f52..273e414559 100644
> --- a/include/hw/xen/xen_backend_ops.h
> +++ b/include/hw/xen/xen_backend_ops.h
> @@ -266,6 +266,8 @@ typedef uint32_t xs_transaction_t;
>  #define XS_PERM_READ  0x01
>  #define XS_PERM_WRITE 0x02
>  
> +#define XS_PRESERVE_OWNER    0xFFFE
> +
>  struct xenstore_backend_ops {
>  struct qemu_xs_handle *(*open)(void);
>  void (*close)(struct qemu_xs_handle *h);



smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v1 1/7] xen-block: Do not write frontend nodes

[David Woodhouse]

On Fri, 2023-11-10 at 20:42 +, Volodymyr Babchuk wrote:
> From: Oleksandr Tyshchenko 
> 
> The PV backend running in other than Dom0 domain (non toolstack domain)
> is not allowed to write frontend nodes. The more, the backend does not
> need to do that at all, this is purely toolstack/xl devd business.
> 
> I do not know for what reason the backend does that here, this is not really
> needed, probably it is just a leftover and all xen_device_frontend_printf()
> instances should go away completely.

No, this is what allows qemu to create PV devices, as opposed to just
handle the ones which are created for it by the toolstack.

Perhaps we should only create the frontend nodes (and likewise, only
destroy those and the backend nodes on destruction) in the case where
the device was instantiated directly by the QEMU command line, and
refrain from doing so for the devices which were created by the
toolstack and merely 'discovered' by xen_block_device_create()?

(Note that we need to look at net and console devices too, now they've
finally been converted to the 'new' XenBus framework in QEMU 8.2.)




smime.p7s
Description: S/MIME cryptographic signature

[PATCH for 8.2] ui/gtk-egl: move function calls back to regular code path

[Volker Rümelin]

Commit 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing
scanout") introduced a regression when QEMU is running with a
virtio-gpu-gl-device on a host under X11. After the guest has
initialized the virtio-gpu-gl-device, the guest screen only
shows "Display output is not active.".

Commit 6f189a08c1 moved all function calls in
gd_egl_scanout_texture() to a code path which is only called
once after gd_egl_init() succeeds in gd_egl_scanout_texture().
Move all function calls in gd_egl_scanout_texture() back to
the regular code path so they get always called if one of the
gd_egl_init() calls was successful.

Fixes: 6f189a08c1 ("ui/gtk-egl: Check EGLSurface before doing scanout")
Signed-off-by: Volker Rümelin 
---
 ui/gtk-egl.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/ui/gtk-egl.c b/ui/gtk-egl.c
index cd2f176502..3af5ac5bcf 100644
--- a/ui/gtk-egl.c
+++ b/ui/gtk-egl.c
@@ -249,14 +249,14 @@ void gd_egl_scanout_texture(DisplayChangeListener *dcl,
 if (!vc->gfx.esurface) {
 return;
 }
+}
 
-eglMakeCurrent(qemu_egl_display, vc->gfx.esurface,
-   vc->gfx.esurface, vc->gfx.ectx);
+eglMakeCurrent(qemu_egl_display, vc->gfx.esurface,
+   vc->gfx.esurface, vc->gfx.ectx);
 
-gtk_egl_set_scanout_mode(vc, true);
-egl_fb_setup_for_tex(>gfx.guest_fb, backing_width, backing_height,
- backing_id, false);
-}
+gtk_egl_set_scanout_mode(vc, true);
+egl_fb_setup_for_tex(>gfx.guest_fb, backing_width, backing_height,
+ backing_id, false);
 }
 
 void gd_egl_scanout_dmabuf(DisplayChangeListener *dcl,
-- 
2.35.3

Re: [PULL v2 00/11] qdev: Make array properties user accessible again

[Stefan Hajnoczi]

Applied, thanks.

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


signature.asc
Description: PGP signature

Re: [PATCH] linux-user/riscv: Add Zicboz block size to hwprobe

[Daniel Henrique Barboza]

On 11/10/23 14:37, Palmer Dabbelt wrote:

Support for probing the Zicboz block size landed in Linux 6.6, which was
released a few weeks ago.  This provides the user-configured block size
when Zicboz is enabled.

Signed-off-by: Palmer Dabbelt 
---


Reviewed-by: Daniel Henrique Barboza 



  linux-user/syscall.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 65ac3ac796..7caacf43d6 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -8808,6 +8808,8 @@ static int do_getdents64(abi_long dirfd, abi_long arg2, 
abi_long count)
  #define RISCV_HWPROBE_MISALIGNED_UNSUPPORTED (4 << 0)
  #define RISCV_HWPROBE_MISALIGNED_MASK(7 << 0)
  
+#define RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE 6

+
  struct riscv_hwprobe {
  abi_llong  key;
  abi_ullong value;
@@ -8860,6 +8862,10 @@ static void risc_hwprobe_fill_pairs(CPURISCVState *env,
  case RISCV_HWPROBE_KEY_CPUPERF_0:
  __put_user(RISCV_HWPROBE_MISALIGNED_FAST, >value);
  break;
+case RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE:
+value = cfg->ext_zicboz ? cfg->cboz_blocksize : 0;
+__put_user(value, >value);
+break;
  default:
  __put_user(-1, >key);
  break;