Re: [PULL 12/12] accel: abort if we fail to load the accelerator plugin

[Claudio Fontana]

Hi all,

and thanks Paolo for taking care of this series, I think I noticed something 
that seems off:

On 11/6/22 09:51, Paolo Bonzini wrote:
> From: Claudio Fontana 
> 
> if QEMU is configured with modules enabled, it is possible that the
> load of an accelerator module will fail.
> Exit in this case, relying on module_object_class_by_name to report
> the specific load error if any.
> 
> Signed-off-by: Claudio Fontana 
> Reviewed-by: Richard Henderson 
> 
> [claudio: changed abort() to exit(1)]
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Markus Armbruster 
> Message-Id: <20220929093035.4231-6-cfont...@suse.de>
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  accel/accel-softmmu.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/accel/accel-softmmu.c b/accel/accel-softmmu.c
> index 67276e4f5222..f9cdafb148ac 100644
> --- a/accel/accel-softmmu.c
> +++ b/accel/accel-softmmu.c
> @@ -66,6 +66,7 @@ void accel_init_ops_interfaces(AccelClass *ac)
>  {
>  const char *ac_name;
>  char *ops_name;
> +ObjectClass *oc;
>  AccelOpsClass *ops;
>  
>  ac_name = object_class_get_name(OBJECT_CLASS(ac));
> @@ -73,8 +74,13 @@ void accel_init_ops_interfaces(AccelClass *ac)
>  
>  ops_name = g_strdup_printf("%s" ACCEL_OPS_SUFFIX, ac_name);
>  ops = ACCEL_OPS_CLASS(module_object_class_by_name(ops_name));

I think this last line should be removed. I somehow left it there by mistake.
Not sure if it hurts, but we assign to "ops" here,

only to reassign to the same variable...

I 

> +oc = module_object_class_by_name(ops_name);
> +if (!oc) {
> +error_report("fatal: could not load module for type '%s'", ops_name);
> +exit(1);
> +}
>  g_free(ops_name);
> -
> +ops = ACCEL_OPS_CLASS(oc);

here. Do I see it right?

>  /*
>   * all accelerators need to define ops, providing at least a mandatory
>   * non-NULL create_vcpu_thread operation.

So I suggest:

- ops = ACCEL_OPS_CLASS(module_object_class_by_name(ops_name)); 
 

Thanks and sorry for the oversight,

Claudio

Re: [PULL v3 50/81] tests: acpi: whitelist DSDT before generating PCI-ISA bridge AML automatically

[Ani Sinha]

On Mon, Nov 7, 2022 at 3:18 AM Bernhard Beschow  wrote:
>
>
>
> On Sat, Nov 5, 2022 at 6:27 PM Michael S. Tsirkin  wrote:
>>
>> From: Igor Mammedov 
>>
>> Signed-off-by: Igor Mammedov 
>> Message-Id: <20221017102146.2254096-3-imamm...@redhat.com>
>> Reviewed-by: Michael S. Tsirkin 
>> Signed-off-by: Michael S. Tsirkin 
>> ---
>>  tests/qtest/bios-tables-test-allowed-diff.h | 34 +
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
>> b/tests/qtest/bios-tables-test-allowed-diff.h
>> index dfb8523c8b..570b17478e 100644
>> --- a/tests/qtest/bios-tables-test-allowed-diff.h
>> +++ b/tests/qtest/bios-tables-test-allowed-diff.h
>> @@ -1 +1,35 @@
>>  /* List of comma-separated changed AML files to ignore */
>> +"tests/data/acpi/pc/DSDT",
>> +"tests/data/acpi/pc/DSDT.acpierst",
>> +"tests/data/acpi/pc/DSDT.acpihmat",
>> +"tests/data/acpi/pc/DSDT.bridge",
>> +"tests/data/acpi/pc/DSDT.cphp",
>> +"tests/data/acpi/pc/DSDT.dimmpxm",
>> +"tests/data/acpi/pc/DSDT.hpbridge",
>> +"tests/data/acpi/pc/DSDT.hpbrroot",
>> +"tests/data/acpi/pc/DSDT.ipmikcs",
>> +"tests/data/acpi/pc/DSDT.memhp",
>> +"tests/data/acpi/pc/DSDT.nohpet",
>> +"tests/data/acpi/pc/DSDT.numamem",
>> +"tests/data/acpi/pc/DSDT.roothp",
>> +"tests/data/acpi/q35/DSDT",
>> +"tests/data/acpi/q35/DSDT.acpierst",
>> +"tests/data/acpi/q35/DSDT.acpihmat",
>> +"tests/data/acpi/q35/DSDT.applesmc",
>> +"tests/data/acpi/q35/DSDT.bridge",
>
>
> +"tests/data/acpi/q35/DSDT.core-count2"
>
> ... and probably in more patches down the road.

Yes I am seeing this failure too:

68/600 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test
   ERROR  39.95s   killed by signal 6 SIGABRT
>>> QTEST_QEMU_IMG=./qemu-img 
>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon 
>>> MALLOC_PERTURB_=138 
>>> G_TEST_DBUS_DAEMON=/home/anisinha/workspace/qemu-ani/tests/dbus-vmstate-daemon.sh
>>>  QTEST_QEMU_BINARY=./qemu-system-x86_64 
>>> /home/anisinha/workspace/qemu-ani/build/tests/qtest/bios-tables-test --tap 
>>> -k

✀  
―
stderr:
acpi-test: Warning! DSDT binary file mismatch. Actual
[aml:/tmp/aml-ARFCV1], Expected
[aml:tests/data/acpi/q35/DSDT.core-count2].
See source file tests/qtest/bios-tables-test.c for instructions on how
to update expected files.
acpi-test: Warning! DSDT mismatch. Actual [asl:/tmp/asl-NTFCV1.dsl,
aml:/tmp/aml-ARFCV1], Expected [asl:/tmp/asl-15QEV1.dsl,
aml:tests/data/acpi/q35/DSDT.core-count2].
**
ERROR:../tests/qtest/bios-tables-test.c:533:test_acpi_asl: assertion
failed: (all_tables_match)



>
> Best regards,
> Bernhard
>
>> +"tests/data/acpi/q35/DSDT.cphp",
>> +"tests/data/acpi/q35/DSDT.cxl",
>> +"tests/data/acpi/q35/DSDT.dimmpxm",
>> +"tests/data/acpi/q35/DSDT.ipmibt",
>> +"tests/data/acpi/q35/DSDT.ipmismbus",
>> +"tests/data/acpi/q35/DSDT.ivrs",
>> +"tests/data/acpi/q35/DSDT.memhp",
>> +"tests/data/acpi/q35/DSDT.mmio64",
>> +"tests/data/acpi/q35/DSDT.multi-bridge",
>> +"tests/data/acpi/q35/DSDT.nohpet",
>> +"tests/data/acpi/q35/DSDT.numamem",
>> +"tests/data/acpi/q35/DSDT.pvpanic-isa",
>> +"tests/data/acpi/q35/DSDT.tis.tpm12",
>> +"tests/data/acpi/q35/DSDT.tis.tpm2",
>> +"tests/data/acpi/q35/DSDT.viot",
>> +"tests/data/acpi/q35/DSDT.xapic",
>> --
>> MST
>>
>>

Re: [PATCH] hw/riscv: virt: Remove size restriction for pflash

[Andrew Jones]

On Mon, Nov 07, 2022 at 11:16:00AM +0530, Sunil V L wrote:
> On Sun, Nov 06, 2022 at 10:20:57PM +0300, Mike Maslenkin wrote:
> > Hello Sunil!
> > 
> > What about virt_machine_done() function?
> > kernel_entry variable still points to the second flash started from
> > virt_memmap[VIRT_FLASH].size / 2.
> > 
> 
> The base address of the flash has not changed to keep things flexible. So, I
> didn't change this portion of the code to keep the changes minimal.

I think we should change virt_machine_done() to be consistent with
create_fdt_flash() and also add a comment in virt_flash_map() explaining
the base addresses are statically determined from virt_memmap[VIRT_FLASH],
but the sizes are variable and determined in virt_flash_map1().

Thanks,
drew

Re: [PATCH] hw/riscv: virt: Remove size restriction for pflash

[Sunil V L]

On Mon, Nov 07, 2022 at 09:48:03AM +0100, Andrew Jones wrote:
> On Mon, Nov 07, 2022 at 11:16:00AM +0530, Sunil V L wrote:
> > On Sun, Nov 06, 2022 at 10:20:57PM +0300, Mike Maslenkin wrote:
> > > Hello Sunil!
> > > 
> > > What about virt_machine_done() function?
> > > kernel_entry variable still points to the second flash started from
> > > virt_memmap[VIRT_FLASH].size / 2.
> > > 
> > 
> > The base address of the flash has not changed to keep things flexible. So, I
> > didn't change this portion of the code to keep the changes minimal.
> 
> I think we should change virt_machine_done() to be consistent with
> create_fdt_flash() and also add a comment in virt_flash_map() explaining
> the base addresses are statically determined from virt_memmap[VIRT_FLASH],
> but the sizes are variable and determined in virt_flash_map1().
> 

Sure Drew. Let me update and send V2.

Thanks
Sunil
> Thanks,
> drew

Re: [PULL 07/55] hw/virtio: move vm_running check to virtio_device_started

[Alex Bennée]

"Michael S. Tsirkin"  writes:

> On Mon, Oct 10, 2022 at 01:29:10PM -0400, Michael S. Tsirkin wrote:
>> From: Alex Bennée 
>> 
>> All the boilerplate virtio code does the same thing (or should at
>> least) of checking to see if the VM is running before attempting to
>> start VirtIO. Push the logic up to the common function to avoid
>> getting a copy and paste wrong.
>> 
>> Signed-off-by: Alex Bennée 
>> Message-Id: <20220802095010.3330793-11-alex.ben...@linaro.org>
>> Reviewed-by: Michael S. Tsirkin 
>> Signed-off-by: Michael S. Tsirkin 
>
> So, looking at the resulting code, I missed the fact that this function
> is also used in virtio core.  So this patch does not do what it's saying
> it does (just refactor code).
> Instead it completely changes the meaning for virtio core.
> I thunk we should revert upstream, however, gpio has grown a
> dependency on this since then.
> Alex, could you take a look please?

So I guess we have three choices:

  new function for use by backends
  new function for use by core
  parameterise virtio_device_started to ignore vm state

I'll add some usage doc comments whichever way.

Do you have a preference?

>
>> ---
>>  include/hw/virtio/virtio.h   | 5 +
>>  hw/virtio/vhost-user-fs.c| 6 +-
>>  hw/virtio/vhost-user-i2c.c   | 6 +-
>>  hw/virtio/vhost-user-rng.c   | 6 +-
>>  hw/virtio/vhost-user-vsock.c | 6 +-
>>  hw/virtio/vhost-vsock.c  | 6 +-
>>  6 files changed, 10 insertions(+), 25 deletions(-)
>> 
>> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
>> index 9bb2485415..74e7ad5a92 100644
>> --- a/include/hw/virtio/virtio.h
>> +++ b/include/hw/virtio/virtio.h
>> @@ -100,6 +100,7 @@ struct VirtIODevice
>>  VirtQueue *vq;
>>  MemoryListener listener;
>>  uint16_t device_id;
>> +/* @vm_running: current VM running state via virtio_vmstate_change() */
>>  bool vm_running;
>>  bool broken; /* device in invalid state, needs reset */
>>  bool use_disabled_flag; /* allow use of 'disable' flag when needed */
>> @@ -376,6 +377,10 @@ static inline bool virtio_device_started(VirtIODevice 
>> *vdev, uint8_t status)
>>  return vdev->started;
>>  }
>>  
>> +if (!vdev->vm_running) {
>> +return false;
>> +}
>> +
>>  return status & VIRTIO_CONFIG_S_DRIVER_OK;
>>  }
>>  
>> diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
>> index e513e4fdda..d2bebba785 100644
>> --- a/hw/virtio/vhost-user-fs.c
>> +++ b/hw/virtio/vhost-user-fs.c
>> @@ -122,11 +122,7 @@ static void vuf_stop(VirtIODevice *vdev)
>>  static void vuf_set_status(VirtIODevice *vdev, uint8_t status)
>>  {
>>  VHostUserFS *fs = VHOST_USER_FS(vdev);
>> -bool should_start = status & VIRTIO_CONFIG_S_DRIVER_OK;
>> -
>> -if (!vdev->vm_running) {
>> -should_start = false;
>> -}
>> +bool should_start = virtio_device_started(vdev, status);
>>  
>>  if (fs->vhost_dev.started == should_start) {
>>  return;
>> diff --git a/hw/virtio/vhost-user-i2c.c b/hw/virtio/vhost-user-i2c.c
>> index 6020eee093..b930cf6d5e 100644
>> --- a/hw/virtio/vhost-user-i2c.c
>> +++ b/hw/virtio/vhost-user-i2c.c
>> @@ -93,11 +93,7 @@ static void vu_i2c_stop(VirtIODevice *vdev)
>>  static void vu_i2c_set_status(VirtIODevice *vdev, uint8_t status)
>>  {
>>  VHostUserI2C *i2c = VHOST_USER_I2C(vdev);
>> -bool should_start = status & VIRTIO_CONFIG_S_DRIVER_OK;
>> -
>> -if (!vdev->vm_running) {
>> -should_start = false;
>> -}
>> +bool should_start = virtio_device_started(vdev, status);
>>  
>>  if (i2c->vhost_dev.started == should_start) {
>>  return;
>> diff --git a/hw/virtio/vhost-user-rng.c b/hw/virtio/vhost-user-rng.c
>> index 3a7bf8e32d..a9c1c4bc79 100644
>> --- a/hw/virtio/vhost-user-rng.c
>> +++ b/hw/virtio/vhost-user-rng.c
>> @@ -90,11 +90,7 @@ static void vu_rng_stop(VirtIODevice *vdev)
>>  static void vu_rng_set_status(VirtIODevice *vdev, uint8_t status)
>>  {
>>  VHostUserRNG *rng = VHOST_USER_RNG(vdev);
>> -bool should_start = status & VIRTIO_CONFIG_S_DRIVER_OK;
>> -
>> -if (!vdev->vm_running) {
>> -should_start = false;
>> -}
>> +bool should_start = virtio_device_started(vdev, status);
>>  
>>  if (rng->vhost_dev.started == should_start) {
>>  return;
>> diff --git a/hw/virtio/vhost-user-vsock.c b/hw/virtio/vhost-user-vsock.c
>> index 0f8ff99f85..22c1616ebd 100644
>> --- a/hw/virtio/vhost-user-vsock.c
>> +++ b/hw/virtio/vhost-user-vsock.c
>> @@ -55,11 +55,7 @@ const VhostDevConfigOps vsock_ops = {
>>  static void vuv_set_status(VirtIODevice *vdev, uint8_t status)
>>  {
>>  VHostVSockCommon *vvc = VHOST_VSOCK_COMMON(vdev);
>> -bool should_start = status & VIRTIO_CONFIG_S_DRIVER_OK;
>> -
>> -if (!vdev->vm_running) {
>> -should_start = false;
>> -}
>> +bool should_start = virtio_device_started(vdev, status);
>>  
>>  if (vvc->vhost_dev.started == should_start) {
>>  return;
>> diff

Re: [PATCH 3/3] vdpa: Expose VIRTIO_NET_F_STATUS unconditionally

[Eugenio Perez Martin]

On Mon, Nov 7, 2022 at 8:51 AM Jason Wang  wrote:
>
> On Thu, Nov 3, 2022 at 4:12 PM Eugenio Perez Martin  
> wrote:
> >
> > On Thu, Nov 3, 2022 at 4:21 AM Jason Wang  wrote:
> > >
> > > On Wed, Nov 2, 2022 at 7:19 PM Eugenio Perez Martin  
> > > wrote:
> > > >
> > > > On Tue, Nov 1, 2022 at 9:10 AM Jason Wang  wrote:
> > > > >
> > > > > On Fri, Oct 28, 2022 at 5:30 PM Eugenio Perez Martin
> > > > >  wrote:
> > > > > >
> > > > > > On Fri, Oct 28, 2022 at 3:59 AM Jason Wang  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Oct 27, 2022 at 6:18 PM Eugenio Perez Martin
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Thu, Oct 27, 2022 at 8:54 AM Jason Wang 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Oct 27, 2022 at 2:47 PM Eugenio Perez Martin
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Oct 27, 2022 at 6:32 AM Jason Wang 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 在 2022/10/26 17:53, Eugenio Pérez 写道:
> > > > > > > > > > > > Now that qemu can handle and emulate it if the vdpa 
> > > > > > > > > > > > backend does not
> > > > > > > > > > > > support it we can offer it always.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Eugenio Pérez 
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I may miss something but isn't more easier to simply 
> > > > > > > > > > > remove the
> > > > > > > > > > > _F_STATUS from vdpa_feature_bits[]?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > How is that? if we remove it, the guest cannot ack it so it 
> > > > > > > > > > cannot
> > > > > > > > > > access the net status, isn't it?
> > > > > > > > >
> > > > > > > > > My understanding is that the bits stored in the 
> > > > > > > > > vdpa_feature_bits[]
> > > > > > > > > are the features that must be explicitly supported by the 
> > > > > > > > > vhost
> > > > > > > > > device.
> > > > > > > >
> > > > > > > > (Non English native here, so maybe I don't get what you mean :) 
> > > > > > > > ) The
> > > > > > > > device may not support them. net simulator lacks some of them
> > > > > > > > actually, and it works.
> > > > > > >
> > > > > > > Speaking too fast, I think I meant that, if the bit doesn't 
> > > > > > > belong to
> > > > > > > vdpa_feature_bits[], it is assumed to be supported by the Qemu 
> > > > > > > without
> > > > > > > the support of the vhost. So Qemu won't even try to validate if 
> > > > > > > vhost
> > > > > > > has this support. E.g for vhost-net, we only have:
> > > > > > >
> > > > > > > static const int kernel_feature_bits[] = {
> > > > > > > VIRTIO_F_NOTIFY_ON_EMPTY,
> > > > > > > VIRTIO_RING_F_INDIRECT_DESC,
> > > > > > > VIRTIO_RING_F_EVENT_IDX,
> > > > > > > VIRTIO_NET_F_MRG_RXBUF,
> > > > > > > VIRTIO_F_VERSION_1,
> > > > > > > VIRTIO_NET_F_MTU,
> > > > > > > VIRTIO_F_IOMMU_PLATFORM,
> > > > > > > VIRTIO_F_RING_PACKED,
> > > > > > > VIRTIO_NET_F_HASH_REPORT,
> > > > > > > VHOST_INVALID_FEATURE_BIT
> > > > > > > };
> > > > > > >
> > > > > > > You can see there's no STATUS bit there since it is emulated by 
> > > > > > > Qemu.
> > > > > > >
> > > > > >
> > > > > > Ok now I get what you mean, and yes we may modify the patches in 
> > > > > > that direction.
> > > > > >
> > > > > > But if we go then we need to modify how qemu ack the features, 
> > > > > > because
> > > > > > the features that are not in vdpa_feature_bits are not acked to the
> > > > > > device. More on this later.
> > > > > >
> > > > > > > >
> > > > > > > > From what I see these are the only features that will be 
> > > > > > > > forwarded to
> > > > > > > > the guest as device_features. If it is not in the list, the 
> > > > > > > > feature
> > > > > > > > will be masked out,
> > > > > > >
> > > > > > > Only when there's no support for this feature from the vhost.
> > > > > > >
> > > > > > > > as if the device does not support it.
> > > > > > > >
> > > > > > > > So now _F_STATUS it was forwarded only if the device supports 
> > > > > > > > it. If
> > > > > > > > we remove it from bit_mask, it will never be offered to the 
> > > > > > > > guest. But
> > > > > > > > we want to offer it always, since we will need it for
> > > > > > > > _F_GUEST_ANNOUNCE.
> > > > > > > >
> > > > > > > > Things get more complex because we actually need to ack it back 
> > > > > > > > if the
> > > > > > > > device offers it, so the vdpa device can report link_down. We 
> > > > > > > > will
> > > > > > > > only emulate LINK_UP always in the case the device does not 
> > > > > > > > support
> > > > > > > > _F_STATUS.
> > > > > > > >
> > > > > > > > > So if we remove _F_STATUS, Qemu vhost code won't validate if
> > > > > > > > > vhost-vdpa device has this support:
> > > > > > > > >
> > > > > > > > > uint64_t vhost_get_features(struct vhost_dev *hdev, const int 
> > > > > > > > > *feature_bits,
> > > > > > > > > uint64_t features)
> > 

Re: [PATCH v8 8/8] s390x/s390-virtio-ccw: add zpcii-disable machine property

[Cédric Le Goater]

Hello,

On 9/2/22 19:27, Matthew Rosato wrote:

The zpcii-disable machine property can be used to force-disable the use
of zPCI interpretation facilities for a VM.  By default, this setting
will be off for machine 7.2 and newer.


KVM will tell if the zPCI interpretation feature is available for
the VM depending on the host capabilities and activation can be
handled with the "interpret" property at the device level.

For migration compatibility, zPCI interpretation can be globally
deactivated with a compat property. So, I don't understand how the
"zpcii-disable" machine option is useful.

The patch could possibly be reverted for 7.2 and replaced with :

  @@ -921,9 +921,13 @@ static void ccw_machine_7_1_instance_opt
   static void ccw_machine_7_1_class_options(MachineClass *mc)
   {
   S390CcwMachineClass *s390mc = S390_CCW_MACHINE_CLASS(mc);
  +static GlobalProperty compat[] = {
  +{ TYPE_S390_PCI_DEVICE, "interpret", "off", },
  +};
   
   ccw_machine_7_2_class_options(mc);

   compat_props_add(mc->compat_props, hw_compat_7_1, hw_compat_7_1_len);
  +compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
   s390mc->max_threads = S390_MAX_CPUS;
   s390mc->topology_capable = false;

   }

Thanks,

C.



Signed-off-by: Matthew Rosato 
---
  hw/s390x/s390-pci-kvm.c|  4 +++-
  hw/s390x/s390-virtio-ccw.c | 25 +
  include/hw/s390x/s390-virtio-ccw.h |  1 +
  qemu-options.hx|  8 +++-
  util/qemu-config.c |  4 
  5 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/hw/s390x/s390-pci-kvm.c b/hw/s390x/s390-pci-kvm.c
index 9134fe185f..5eb7fd12e2 100644
--- a/hw/s390x/s390-pci-kvm.c
+++ b/hw/s390x/s390-pci-kvm.c
@@ -22,7 +22,9 @@
  
  bool s390_pci_kvm_interp_allowed(void)

  {
-return kvm_s390_get_zpci_op() && !s390_is_pv();
+return (kvm_s390_get_zpci_op() && !s390_is_pv() &&
+!object_property_get_bool(OBJECT(qdev_get_machine()),
+  "zpcii-disable", NULL));
  }
  
  int s390_pci_kvm_aif_enable(S390PCIBusDevice *pbdev, ZpciFib *fib, bool assist)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 9a2467c889..f8ecb6172c 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -645,6 +645,21 @@ static inline void machine_set_dea_key_wrap(Object *obj, 
bool value,
  ms->dea_key_wrap = value;
  }
  
+static inline bool machine_get_zpcii_disable(Object *obj, Error **errp)

+{
+S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
+
+return ms->zpcii_disable;
+}
+
+static inline void machine_set_zpcii_disable(Object *obj, bool value,
+ Error **errp)
+{
+S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
+
+ms->zpcii_disable = value;
+}
+
  static S390CcwMachineClass *current_mc;
  
  /*

@@ -740,6 +755,13 @@ static inline void s390_machine_initfn(Object *obj)
  "Up to 8 chars in set of [A-Za-z0-9. ] (lower case chars 
converted"
  " to upper case) to pass to machine loader, boot manager,"
  " and guest kernel");
+
+object_property_add_bool(obj, "zpcii-disable",
+ machine_get_zpcii_disable,
+ machine_set_zpcii_disable);
+object_property_set_description(obj, "zpcii-disable",
+"disable zPCI interpretation facilties");
+object_property_set_bool(obj, "zpcii-disable", false, NULL);
  }
  
  static const TypeInfo ccw_machine_info = {

@@ -803,8 +825,11 @@ DEFINE_CCW_MACHINE(7_2, "7.2", true);
  
  static void ccw_machine_7_1_instance_options(MachineState *machine)

  {
+S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
+
  ccw_machine_7_2_instance_options(machine);
  s390_cpudef_featoff_greater(16, 1, S390_FEAT_PAIE);
+ms->zpcii_disable = true;
  }
  
  static void ccw_machine_7_1_class_options(MachineClass *mc)

diff --git a/include/hw/s390x/s390-virtio-ccw.h 
b/include/hw/s390x/s390-virtio-ccw.h
index 3331990e02..8a0090a071 100644
--- a/include/hw/s390x/s390-virtio-ccw.h
+++ b/include/hw/s390x/s390-virtio-ccw.h
@@ -27,6 +27,7 @@ struct S390CcwMachineState {
  bool aes_key_wrap;
  bool dea_key_wrap;
  bool pv;
+bool zpcii_disable;
  uint8_t loadparm[8];
  };
  
diff --git a/qemu-options.hx b/qemu-options.hx

index 31c04f7eea..7427dd1ed5 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -37,7 +37,8 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
  "memory-encryption=@var{} memory encryption object to use 
(default=none)\n"
  "hmat=on|off controls ACPI HMAT support (default=off)\n"
  "memory-backend='backend-id' specifies explicitly provided 
backend for main RAM (default=none)\n"
-"
cxl-fmw.0.targets.0=firsttarget,cxl-fmw.0.targets.1=secondtarget,cxl-fmw.0.size=size[,cxl-fmw.0.interleave-granul

Re: [PATCH v11 01/11] s390x: Register TYPE_S390_CCW_MACHINE properties as class properties

[Pierre Morel]

On 11/6/22 12:37, Thomas Huth wrote:

On 04/11/2022 15.57, Pierre Morel wrote:



On 11/4/22 15:29, Thomas Huth wrote:

On 04/11/2022 11.53, Cédric Le Goater wrote:

On 11/4/22 11:16, Pierre Morel wrote:



On 11/4/22 07:32, Thomas Huth wrote:

On 03/11/2022 18.01, Pierre Morel wrote:

Signed-off-by: Pierre Morel 
---
  hw/s390x/s390-virtio-ccw.c | 127 
+

  1 file changed, 72 insertions(+), 55 deletions(-)


-EMISSINGPATCHDESCRIPTION

... please add some words *why* this is a good idea / necessary.


I saw that the i386 patch had no description for the same patch so...

To be honest I do not know why it is necessary.
The only reason I see is to be in sync with the PC implementation.

So what about:
"
Register TYPE_S390_CCW_MACHINE properties as class properties
to be conform with the X architectures
"
?

@Cédric , any official recommendation for doing that?


There was a bunch of commits related to QOM in this series :

   91def7b83 arm/virt: Register most properties as class properties
   f5730c69f0 i386: Register feature bit properties as class properties

which moved property definitions at the class level.

Then,

   commit d8fb7d0969 ("vl: switch -M parsing to keyval")

changed machine_help_func() to use a machine class and not machine
instance anymore.

I would use the same kind of commit log and add a Fixes tag to get it
merged in 7.2


Ah, so this fixes the problem that running QEMU with " -M 
s390-ccw-virtio,help" does not show the s390x-specific properties 
anymore? ... that's certainly somethings that should be mentioned in 
the commit message! What about something like this:


"Currently, when running 'qemu-system-s390x -M -M 
s390-ccw-virtio,help' the s390x-specific properties are not listed 
anymore. This happens because since commit d8fb7d0969 ("vl: switch -M 
parsing to keyval") the properties have to be defined at the class 
level and not at the instance level anymore. Fix it on s390x now, 
too, by moving the registration of the properties to the class level"


Fixes: d8fb7d0969 ("vl: switch -M parsing to keyval")

?

  Thomas



That seems really good :)


All right, I've queued this patch (with the updated commit description) 
and the next one on my s390x-branch for QEMU 7.2:


  https://gitlab.com/thuth/qemu/-/commits/s390x-next/

  Thomas




Thank you!

Regards,
Pierre


--
Pierre Morel
IBM Lab Boeblingen

Re: [PATCH] hw/riscv: virt: Remove size restriction for pflash

[maobibo]

在 2022/11/6 22:39, Sunil V L 写道:
> The pflash implementation currently assumes fixed size of the
> backend storage. Due to this, the backend storage file needs to be
> exactly of size 32M. Otherwise, there will be an error like below.
> 
> "device requires 33554432 bytes, block backend provides 3145728 bytes"
> 
> Fix this issue by using the actual size of the backing store.
> 
> Signed-off-by: Sunil V L 
> ---
>  hw/riscv/virt.c | 33 +
>  1 file changed, 25 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> index a5bc7353b4..aad175fa31 100644
> --- a/hw/riscv/virt.c
> +++ b/hw/riscv/virt.c
> @@ -49,6 +49,7 @@
>  #include "hw/pci/pci.h"
>  #include "hw/pci-host/gpex.h"
>  #include "hw/display/ramfb.h"
> +#include "sysemu/block-backend.h"
>  
>  /*
>   * The virt machine physical address space used by some of the devices
> @@ -144,10 +145,17 @@ static void virt_flash_map1(PFlashCFI01 *flash,
>  MemoryRegion *sysmem)
>  {
>  DeviceState *dev = DEVICE(flash);
> +BlockBackend *blk;
> +hwaddr real_size;
>  
> -assert(QEMU_IS_ALIGNED(size, VIRT_FLASH_SECTOR_SIZE));
> -assert(size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
> -qdev_prop_set_uint32(dev, "num-blocks", size / VIRT_FLASH_SECTOR_SIZE);
> +blk = pflash_cfi01_get_blk(flash);
> +
> +real_size = blk ? blk_getlength(blk): size;
> +
> +assert(real_size);
> +assert(QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE));
> +assert(real_size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
How about add one sentence?
   assert(real_size <= size);   

As defined VIRT_FLASH memory space, the total memory space size 64M,
Pflash0/Pflash1 cannot be more than 32M. Supposing real size of pflash0
is 33M, there will be conflict with address space of pflash1.

regards
bibo, mao

> +qdev_prop_set_uint32(dev, "num-blocks", real_size / 
> VIRT_FLASH_SECTOR_SIZE);
>  sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
>  
>  memory_region_add_subregion(sysmem, base,
> @@ -971,15 +979,24 @@ static void create_fdt_flash(RISCVVirtState *s, const 
> MemMapEntry *memmap)
>  {
>  char *name;
>  MachineState *mc = MACHINE(s);
> -hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
> -hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
> +MemoryRegion *flash_mem;
> +hwaddr flashsize[2];
> +hwaddr flashbase[2];
> +
> +flash_mem = pflash_cfi01_get_memory(s->flash[0]);
> +flashbase[0] = flash_mem->addr;
> +flashsize[0] = flash_mem->size;
> +
> +flash_mem = pflash_cfi01_get_memory(s->flash[1]);
> +flashbase[1] = flash_mem->addr;
> +flashsize[1] = flash_mem->size;
>  
> -name = g_strdup_printf("/flash@%" PRIx64, flashbase);
> +name = g_strdup_printf("/flash@%" PRIx64, flashbase[0]);
>  qemu_fdt_add_subnode(mc->fdt, name);
>  qemu_fdt_setprop_string(mc->fdt, name, "compatible", "cfi-flash");
>  qemu_fdt_setprop_sized_cells(mc->fdt, name, "reg",
> - 2, flashbase, 2, flashsize,
> - 2, flashbase + flashsize, 2, flashsize);
> + 2, flashbase[0], 2, flashsize[0],
> + 2, flashbase[1], 2, flashsize[1]);
>  qemu_fdt_setprop_cell(mc->fdt, name, "bank-width", 4);
>  g_free(name);
>  }

Re: [PATCH 1/3] qemu-img: Add checksum command

[Hanna Reitz]

On 30.10.22 18:37, Nir Soffer wrote:

On Wed, Oct 26, 2022 at 4:00 PM Hanna Reitz  wrote:

On 01.09.22 16:32, Nir Soffer wrote:
> The checksum command compute a checksum for disk image content
using the
> blkhash library[1]. The blkhash library is not packaged yet, but
it is
> available via copr[2].
>
> Example run:
>
>      $ ./qemu-img checksum -p fedora-35.qcow2
> 6e5c00c995056319d52395f8d91c7f84725ae3da69ffcba4de4c7d22cff713a5
fedora-35.qcow2
>
> The block checksum is constructed by splitting the image to
fixed sized
> blocks and computing a digest of every block. The image checksum
is the
> digest of the all block digests.
>
> The checksum uses internally the "sha256" algorithm but it cannot be
> compared with checksums created by other tools such as `sha256sum`.
>
> The blkhash library supports sparse images, zero detection, and
> optimizes zero block hashing (they are practically free). The
library
> uses multiple threads to speed up the computation.
>
> Comparing to `sha256sum`, `qemu-img checksum` is 3.5-4800[3] times
> faster, depending on the amount of data in the image:
>
>      $ ./qemu-img info /scratch/50p.raw
>      file format: raw
>      virtual size: 6 GiB (6442450944 bytes)
>      disk size: 2.91 GiB
>
>      $ hyperfine -w2 -r5 -p "sleep 1" "./qemu-img checksum
/scratch/50p.raw" \
>                                       "sha256sum /scratch/50p.raw"
>      Benchmark 1: ./qemu-img checksum /scratch/50p.raw
>        Time (mean ± σ):      1.849 s ±  0.037 s [User: 7.764 s,
System: 0.962 s]
>        Range (min … max):    1.813 s …  1.908 s    5 runs
>
>      Benchmark 2: sha256sum /scratch/50p.raw
>        Time (mean ± σ):     14.585 s ±  0.072 s [User: 13.537 s,
System: 1.003 s]
>        Range (min … max):   14.501 s … 14.697 s    5 runs
>
>      Summary
>        './qemu-img checksum /scratch/50p.raw' ran
>          7.89 ± 0.16 times faster than 'sha256sum /scratch/50p.raw'
>
> The new command is available only when `blkhash` is available during
> build. To test the new command please install the `blkhash-devel`
> package:
>
>      $ dnf copr enable nsoffer/blkhash
>      $ sudo dnf install blkhash-devel
>
> [1] https://gitlab.com/nirs/blkhash
> [2] https://copr.fedorainfracloud.org/coprs/nsoffer/blkhash/
> [3] Computing checksum for 8T empty image: qemu-img checksum: 3.7s,
>      sha256sum (estimate): 17,749s
>
> Signed-off-by: Nir Soffer 
> ---
>   docs/tools/qemu-img.rst |  22 +
>   meson.build             |  10 ++-
>   meson_options.txt       |   2 +
>   qemu-img-cmds.hx        |   8 ++
>   qemu-img.c              | 191

>   5 files changed, 232 insertions(+), 1 deletion(-)
>
> diff --git a/docs/tools/qemu-img.rst b/docs/tools/qemu-img.rst
> index 85a6e05b35..8be9c45cbf 100644
> --- a/docs/tools/qemu-img.rst
> +++ b/docs/tools/qemu-img.rst
> @@ -347,20 +347,42 @@ Command description:
>       Check completed, image is corrupted
>     3
>       Check completed, image has leaked clusters, but is not
corrupted
>     63
>       Checks are not supported by the image format
>
>     If ``-r`` is specified, exit codes representing the image
state refer to the
>     state after (the attempt at) repairing it. That is, a
successful ``-r all``
>     will yield the exit code 0, independently of the image state
before.
>
> +.. option:: checksum [--object OBJECTDEF] [--image-opts] [-f
FMT] [-T SRC_CACHE] [-p] FILENAME
> +
> +  Print a checksum for image *FILENAME* guest visible content.

Why not say which kind of checksum it is?


Do you mean the algorithm used? This may be confusing, for example we 
write


   Print a sha256 checksum ...

User will expect to get the same result from "sha256sum disk.img". How 
about


   Print a blkhash checksum ...

And add a link to the blkhash project?


I did mean sha256, but if it isn’t pure sha256, then a link to any 
description how it is computed would be good, I think.




>           Images with
> +  different format or settings wil have the same checksum.

s/wil/will/


Fixing


> +
> +  The format is probed unless you specify it by ``-f``.
> +
> +  The checksum is computed for guest visible content. Allocated
areas full of
> +  zeroes, zero clusters, and unallocated areas are read as
zeros so they will
> +  have the same checksum. Images with single or multiple files
or backing files
> +  will have the same checksums if the guest will see the same
content when
> +  reading the image.
> +
> +  Image metadata that is not visible to the guest such as dirty
bit

Re: [PATCH v8 8/8] s390x/s390-virtio-ccw: add zpcii-disable machine property

[Thomas Huth]

On 07/11/2022 10.53, Cédric Le Goater wrote:

Hello,

On 9/2/22 19:27, Matthew Rosato wrote:

The zpcii-disable machine property can be used to force-disable the use
of zPCI interpretation facilities for a VM.  By default, this setting
will be off for machine 7.2 and newer.


KVM will tell if the zPCI interpretation feature is available for
the VM depending on the host capabilities and activation can be
handled with the "interpret" property at the device level.

For migration compatibility, zPCI interpretation can be globally
deactivated with a compat property. So, I don't understand how the
"zpcii-disable" machine option is useful.

The patch could possibly be reverted for 7.2 and replaced with :

   @@ -921,9 +921,13 @@ static void ccw_machine_7_1_instance_opt
    static void ccw_machine_7_1_class_options(MachineClass *mc)
    {
    S390CcwMachineClass *s390mc = S390_CCW_MACHINE_CLASS(mc);
   +    static GlobalProperty compat[] = {
   +    { TYPE_S390_PCI_DEVICE, "interpret", "off", },
   +    };
    ccw_machine_7_2_class_options(mc);
    compat_props_add(mc->compat_props, hw_compat_7_1, hw_compat_7_1_len);
   +    compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
    s390mc->max_threads = S390_MAX_CPUS;
    s390mc->topology_capable = false;

    }


Thinking about this twice, I'm not sure whether we would need it at all 
since zpci cannot be migrated at all (see the "unmigratable = 1" in 
hw/s390x/s390-pci-bus.c) ... OTOH, doing it via the compat_props also does 
not really hurt.


Anyway, the zpcii-disable switch really does not seem to be necessary... 
Matthew, do you think it's ok if we revert "zpcii-disable" patch?


 Thomas

Re: [PATCH v2 0/6] Two -Wclobbered fixes, plus other cleanup

[Philippe Mathieu-Daudé]

On 6/11/22 22:28, Richard Henderson wrote:

Stefan reported for accel/tcg, and I reproduced on Ubuntu 22.04.

Changes for v2:
   * Incorporate suggested changes to nanomips.c (phil, balaton).


Thanks for v2, it was an optional review change request from my
side, but I appreciate the change, the result is cleaner.


Richard Henderson (6):
   disas/nanomips: Move setjmp into nanomips_dis
   disas/nanomips: Merge insn{1,2,3} into words[3]
   disas/nanomips: Split out read_u16
   disas/nanomips: Tidy read for 48-bit opcodes


I'm queuing the nanomips patches via mips-fixes.

Regards,

Phil.

[PATCH] hw/sd/sdhci: reset data count in sdhci_buff_access_is_sequential()

[Mauro Matteo Cascella]

Make sure to reset data_count if it's equal to (or exceeds) block_size.
This prevents an off-by-one read / write when accessing s->fifo_buffer
in sdhci_read_dataport / sdhci_write_dataport, both called right after
sdhci_buff_access_is_sequential.

Fixes: CVE-2022-3872
Reported-by: RivenDell 
Reported-by: Siqi Chen 
Reported-by: ningqiang 
Signed-off-by: Mauro Matteo Cascella 
---
 hw/sd/sdhci.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 306070c872..aa2fd79df2 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -978,6 +978,10 @@ static bool sdhci_can_issue_command(SDHCIState *s)
 static inline bool
 sdhci_buff_access_is_sequential(SDHCIState *s, unsigned byte_num)
 {
+if (s->data_count >= (s->blksize & BLOCK_SIZE_MASK)) {
+s->data_count = 0;
+}
+
 if ((s->data_count & 0x3) != byte_num) {
 trace_sdhci_error("Non-sequential access to Buffer Data Port register"
   "is prohibited\n");
-- 
2.38.1

Re: [PATCH 3/3] qemu-img: Speed up checksum

[Hanna Reitz]

On 30.10.22 18:38, Nir Soffer wrote:

On Wed, Oct 26, 2022 at 4:54 PM Hanna Reitz  wrote:

On 01.09.22 16:32, Nir Soffer wrote:
> Add coroutine based loop inspired by `qemu-img convert` design.
>
> Changes compared to `qemu-img convert`:
>
> - State for the entire image is kept in ImgChecksumState
>
> - State for single worker coroutine is kept in ImgChecksumworker.
>
> - "Writes" are always in-order, ensured using a queue.
>
> - Calling block status once per image extent, when the current
extent is
>    consumed by the workers.
>
> - Using 1m buffer size - testings shows that this gives best read
>    performance both with buffered and direct I/O.

Why does patch 1 then choose to use 2 MB?


The first patch uses sync I/O, and in this case 2 MB is a little faster.


Interesting.


> - Number of coroutines is not configurable. Testing does not show
>    improvement when using more than 8 coroutines.
>
> - Progress include entire image, not only the allocated state.
>
> Comparing to the simple read loop shows that this version is up
to 4.67
> times faster when computing a checksum for an image full of
zeroes. For
> real images it is 1.59 times faster with direct I/O, and with
buffered
> I/O there is no difference.
>
> Test results on Dell PowerEdge R640 in a CentOS Stream 9 container:
>
> | image    | size | i/o       | before         | after         |
change |
>
|--|--|---||||
> | zero [1] |   6g | buffered  | 1.600s ±0.014s | 0.342s ±0.016s
|  x4.67 |
> | zero     |   6g | direct    | 4.684s ±0.093s | 2.211s ±0.009s
|  x2.12 |
> | real [2] |   6g | buffered  | 1.841s ±0.075s | 1.806s ±0.036s
|  x1.02 |
> | real     |   6g | direct    | 3.094s ±0.079s | 1.947s ±0.017s
|  x1.59 |
> | nbd  [3] |   6g | buffered  | 2.455s ±0.183s | 1.808s ±0.016s
|  x1.36 |
> | nbd      |   6g | direct    | 3.540s ±0.020s | 1.749s ±0.018s
|  x2.02 |
>
> [1] raw image full of zeroes
> [2] raw fedora 35 image with additional random data, 50% full
> [3] image [2] exported by qemu-nbd via unix socket
>
> Signed-off-by: Nir Soffer 
> ---
>   qemu-img.c | 343
+
>   1 file changed, 270 insertions(+), 73 deletions(-)

Looks good!

Just a couple of style comments below.

> diff --git a/qemu-img.c b/qemu-img.c
> index 7edcfe4bc8..bfa8e2862f 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -1613,48 +1613,288 @@ out:
>       qemu_vfree(buf2);
>       blk_unref(blk2);
>   out2:
>       blk_unref(blk1);
>   out3:
>       qemu_progress_end();
>       return ret;
>   }
>
>   #ifdef CONFIG_BLKHASH
> +
> +#define CHECKSUM_COROUTINES 8
> +#define CHECKSUM_BUF_SIZE (1 * MiB)
> +#define CHECKSUM_ZERO_SIZE MIN(16 * GiB, SIZE_MAX)
> +
> +typedef struct ImgChecksumState ImgChecksumState;
> +
> +typedef struct ImgChecksumWorker {
> +    QTAILQ_ENTRY(ImgChecksumWorker) entry;
> +    ImgChecksumState *state;
> +    Coroutine *co;
> +    uint8_t *buf;
> +
> +    /* The current chunk. */
> +    int64_t offset;
> +    int64_t length;
> +    bool zero;
> +
> +    /* Always true for zero extent, false for data extent. Set
to true
> +     * when reading the chunk completes. */

Qemu codestyle requires /* and */ to be on separate lines for
multi-line
comments (see checkpatch.pl ).


I'll change that. Do we have a good way to run checkpatch.pl 
 when using

git-publish?

Maybe a way to run checkpatch.pl  on all patches 
generated by git publish

automatically?


I don’t know myself, I don’t use git-publish.  Stefan should know. ;)



> +    bool ready;
> +} ImgChecksumWorker;
> +
> +struct ImgChecksumState {
> +    const char *filename;
> +    BlockBackend *blk;
> +    BlockDriverState *bs;
> +    int64_t total_size;
> +
> +    /* Current extent, modified in checksum_co_next. */
> +    int64_t offset;
> +    int64_t length;
> +    bool zero;
> +
> +    int running_coroutines;
> +    CoMutex lock;
> +    ImgChecksumWorker workers[CHECKSUM_COROUTINES];
> +
> +    /* Ensure in-order updates. Update are scheduled at the
tail of the
> +     * queue and processed from the head of the queue when a
worker is
> +     * ready. */

Qemu codestyle requires /* and */ to be on separate lines for
multi-line
comments.

> +    QTAILQ_HEAD(, ImgChecksumWorker) update_queue;
> +
> +    struct blkhash *hash;
> +    int ret;
> +};

[...]

> +static coroutine_fn bool checksum_co_next

Re: [PULL v3 00/81] pci,pc,virtio: features, tests, fixes, cleanups

[Stefan Hajnoczi]

Hi Michael and Igor,
Looks like the ACPI commits broken the virtio-vga module:

>>> QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=60 
>>> G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh 
>>> QTEST_QEMU_BINARY=./qemu-system-or1k 
>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon 
>>> /builds/qemu-project/qemu/build/tests/qtest/device-introspect-test --tap -k
― ✀ ―
stderr:
failed to open module:
/builds/qemu-project/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
undefined symbol: aml_return
qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
NULL' failed.
Broken pipe
../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
signal 6 (Aborted) (core dumped)
TAP parsing error: Too few tests run (expected 6, got 0)
(test program exited with status code -6)
――
154/274 qemu:qtest+qtest-or1k / qtest-or1k/machine-none-test OK 0.05s
1 subtests passed
155/274 qemu:qtest+qtest-or1k / qtest-or1k/qmp-test OK 0.19s 4 subtests passed
156/274 qemu:qtest+qtest-or1k / qtest-or1k/qmp-cmd-test ERROR 1.72s
killed by signal 6 SIGABRT
>>> QTEST_QEMU_IMG=./qemu-img 
>>> G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh 
>>> QTEST_QEMU_BINARY=./qemu-system-or1k 
>>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon 
>>> MALLOC_PERTURB_=53 /builds/qemu-project/qemu/build/tests/qtest/qmp-cmd-test 
>>> --tap -k
― ✀ ―
stderr:
failed to open module:
/builds/qemu-project/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
undefined symbol: aml_return
qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
NULL' failed.
Broken pipe
../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
signal 6 (Aborted) (core dumped)
TAP parsing error: Too few tests run (expected 62, got 31)
(test program exited with status code -6)
――

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

Stefan

Re: [PATCH] hw/sd/sdhci: reset data count in sdhci_buff_access_is_sequential()

[Mauro Matteo Cascella]

On Mon, Nov 7, 2022 at 11:35 AM Mauro Matteo Cascella
 wrote:
>
> Make sure to reset data_count if it's equal to (or exceeds) block_size.
> This prevents an off-by-one read / write when accessing s->fifo_buffer
> in sdhci_read_dataport / sdhci_write_dataport, both called right after
> sdhci_buff_access_is_sequential.
>
> Fixes: CVE-2022-3872
> Reported-by: RivenDell 
> Reported-by: Siqi Chen 
> Reported-by: ningqiang 
> Signed-off-by: Mauro Matteo Cascella 
> ---
>  hw/sd/sdhci.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index 306070c872..aa2fd79df2 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -978,6 +978,10 @@ static bool sdhci_can_issue_command(SDHCIState *s)
>  static inline bool
>  sdhci_buff_access_is_sequential(SDHCIState *s, unsigned byte_num)
>  {
> +if (s->data_count >= (s->blksize & BLOCK_SIZE_MASK)) {
> +s->data_count = 0;
> +}
> +
>  if ((s->data_count & 0x3) != byte_num) {
>  trace_sdhci_error("Non-sequential access to Buffer Data Port 
> register"
>"is prohibited\n");
> --
> 2.38.1
>

Reproducer:

cat << EOF | ./qemu-system-x86_64 -machine accel=qtest \
-nodefaults -drive if=none,index=0,file=null-co://,format=raw,id=mydrive \
-device sdhci-pci -device sd-card,drive=mydrive -nographic -qtest stdio
outl 0xcf8 0x80001004
outl 0xcfc 0x107
outl 0xcf8 0x80001010
outl 0xcfc 0xfebf1000
writel 0xfebf102c 0x7
writel 0xfebf1004 0x10200
writel 0xfebf100c 0x20
writel 0xfebf1028 0x1
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf1020 0xdeadbeef
writel 0xfebf10

Re: [PATCH] hw/riscv: virt: Remove size restriction for pflash

[Sunil V L]

On Mon, Nov 07, 2022 at 05:57:45PM +0800, maobibo wrote:
> 
> 
> 在 2022/11/6 22:39, Sunil V L 写道:
> > The pflash implementation currently assumes fixed size of the
> > backend storage. Due to this, the backend storage file needs to be
> > exactly of size 32M. Otherwise, there will be an error like below.
> > 
> > "device requires 33554432 bytes, block backend provides 3145728 bytes"
> > 
> > Fix this issue by using the actual size of the backing store.
> > 
> > Signed-off-by: Sunil V L 
> > ---
> >  hw/riscv/virt.c | 33 +
> >  1 file changed, 25 insertions(+), 8 deletions(-)
> > 
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
> > index a5bc7353b4..aad175fa31 100644
> > --- a/hw/riscv/virt.c
> > +++ b/hw/riscv/virt.c
> > @@ -49,6 +49,7 @@
> >  #include "hw/pci/pci.h"
> >  #include "hw/pci-host/gpex.h"
> >  #include "hw/display/ramfb.h"
> > +#include "sysemu/block-backend.h"
> >  
> >  /*
> >   * The virt machine physical address space used by some of the devices
> > @@ -144,10 +145,17 @@ static void virt_flash_map1(PFlashCFI01 *flash,
> >  MemoryRegion *sysmem)
> >  {
> >  DeviceState *dev = DEVICE(flash);
> > +BlockBackend *blk;
> > +hwaddr real_size;
> >  
> > -assert(QEMU_IS_ALIGNED(size, VIRT_FLASH_SECTOR_SIZE));
> > -assert(size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
> > -qdev_prop_set_uint32(dev, "num-blocks", size / VIRT_FLASH_SECTOR_SIZE);
> > +blk = pflash_cfi01_get_blk(flash);
> > +
> > +real_size = blk ? blk_getlength(blk): size;
> > +
> > +assert(real_size);
> > +assert(QEMU_IS_ALIGNED(real_size, VIRT_FLASH_SECTOR_SIZE));
> > +assert(real_size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
> How about add one sentence?
>assert(real_size <= size);   
> 
> As defined VIRT_FLASH memory space, the total memory space size 64M,
> Pflash0/Pflash1 cannot be more than 32M. Supposing real size of pflash0
> is 33M, there will be conflict with address space of pflash1.
> 
> regards
> bibo, mao
> 

Good catch!. Thank you. Will add it in V2.

Thanks
Sunil

Re: [PATCH 1/1] tcg: add perfmap and jitdump

[Alex Bennée]

Ilya Leoshkevich  writes:

> Add ability to dump /tmp/perf-.map and jit-.dump.
> The first one allows the perf tool to map samples to each individual
> translation block. The second one adds the ability to resolve symbol
> names, line numbers and inspect JITed code.
>
> Example of use:
>
> perf record qemu-x86_64 -perfmap ./a.out
> perf report
>
> or
>
> perf record -k 1 qemu-x86_64 -jitdump ./a.out
> perf inject -j -i perf.data -o perf.data.jitted
> perf report -i perf.data.jitted
>
> Co-developed-by: Vanderson M. do Rosario 
> Co-developed-by: Alex Bennée 
> Signed-off-by: Ilya Leoshkevich 
> ---
>  accel/tcg/debuginfo.c | 108 +
>  accel/tcg/debuginfo.h |  54 +++
>  accel/tcg/meson.build |   2 +
>  accel/tcg/perf.c  | 333 ++
>  accel/tcg/perf.h  |  28 
>  accel/tcg/translate-all.c |   3 +
>  docs/devel/tcg.rst|  20 +++
>  linux-user/elfload.c  |   3 +
>  linux-user/exit.c |   2 +
>  linux-user/main.c |  15 ++
>  linux-user/meson.build|   1 +
>  meson.build   |   8 +
>  qemu-options.hx   |  20 +++
>  softmmu/vl.c  |  11 ++
>  tcg/tcg.c |   2 +
>  15 files changed, 610 insertions(+)
>  create mode 100644 accel/tcg/debuginfo.c
>  create mode 100644 accel/tcg/debuginfo.h
>  create mode 100644 accel/tcg/perf.c
>  create mode 100644 accel/tcg/perf.h
>
> diff --git a/accel/tcg/debuginfo.c b/accel/tcg/debuginfo.c
> new file mode 100644
> index 00..904eb23103
> --- /dev/null
> +++ b/accel/tcg/debuginfo.c
> @@ -0,0 +1,108 @@
> +/*
> + * Debug information support.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include "qemu/osdep.h"
> +
> +#include 
> +
> +#include "debuginfo.h"
> +
> +static QemuMutex lock;
> +static Dwfl *dwfl;
> +static const Dwfl_Callbacks dwfl_callbacks = {
> +.find_elf = NULL,
> +.find_debuginfo = dwfl_standard_find_debuginfo,
> +.section_address = NULL,
> +.debuginfo_path = NULL,
> +};
> +
> +__attribute__((constructor))
> +static void debuginfo_init(void)
> +{
> +qemu_mutex_init(&lock);
> +}
> +
> +bool debuginfo_report_elf(const char *image_name, int image_fd,
> +  target_ulong load_bias)
> +{
> +qemu_mutex_lock(&lock);

You can wrap this up with a QEMU_LOCK_GUARD(&lock) { and avoid having to
catch all your exit cases.

> +
> +if (dwfl == NULL) {
> +dwfl = dwfl_begin(&dwfl_callbacks);
> +} else {
> +dwfl_report_begin_add(dwfl);
> +}
> +
> +if (dwfl == NULL) {
> +qemu_mutex_unlock(&lock);
> +return false;
> +}
> +
> +dwfl_report_elf(dwfl, image_name, image_name, image_fd, load_bias, true);
> +dwfl_report_end(dwfl, NULL, NULL);
> +qemu_mutex_unlock(&lock);
> +return true;
> +}
> +
> +bool debuginfo_get_symbol(target_ulong address,
> +  const char **symbol, target_ulong *offset)
> +{
> +Dwfl_Module *dwfl_module;
> +GElf_Off dwfl_offset;
> +GElf_Sym dwfl_sym;
> +
> +qemu_mutex_lock(&lock);
> +
> +if (dwfl == NULL) {
> +qemu_mutex_unlock(&lock);
> +return false;
> +}
> +
> +dwfl_module = dwfl_addrmodule(dwfl, address);
> +if (dwfl_module == NULL) {
> +qemu_mutex_unlock(&lock);
> +return false;
> +}
> +
> +*symbol = dwfl_module_addrinfo(dwfl_module, address, &dwfl_offset,
> +   &dwfl_sym, NULL, NULL, NULL);
> +if (*symbol == NULL) {
> +qemu_mutex_unlock(&lock);
> +return false;
> +}
> +*offset = dwfl_offset;
> +qemu_mutex_unlock(&lock);
> +return true;
> +}
> +
> +bool debuginfo_get_line(target_ulong address,
> +const char **file, int *line)
> +{
> +Dwfl_Module *dwfl_module;
> +Dwfl_Line *dwfl_line;
> +
> +qemu_mutex_lock(&lock);

ditto.

> +
> +if (dwfl == NULL) {
> +qemu_mutex_unlock(&lock);
> +return false;
> +}
> +
> +dwfl_module = dwfl_addrmodule(dwfl, address);
> +if (dwfl_module == NULL) {
> +qemu_mutex_unlock(&lock);
> +return false;
> +}
> +
> +dwfl_line = dwfl_module_getsrc(dwfl_module, address);
> +if (dwfl_line == NULL) {
> +qemu_mutex_unlock(&lock);
> +return false;
> +}
> +*file = dwfl_lineinfo(dwfl_line, NULL, line, 0, NULL, NULL);
> +qemu_mutex_unlock(&lock);
> +return true;
> +}
> diff --git a/accel/tcg/debuginfo.h b/accel/tcg/debuginfo.h
> new file mode 100644
> index 00..f4f22aa786
> --- /dev/null
> +++ b/accel/tcg/debuginfo.h
> @@ -0,0 +1,54 @@
> +/*
> + * Debug information support.
> + *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef ACCEL_TCG_DEBUGINFO_H
> +#define ACCEL_TCG_DEBUGINFO_H
> +
> +#include "exec/cpu-defs.h"
> +
> +#ifdef CONFIG_LIBDW
> +/*
> + * Load debuginfo for the specified guest ELF image.
> + * Return true on suc

Re: [PATCH 2/3] iotests: Test qemu-img checksum

[Hanna Reitz]

On 30.10.22 18:38, Nir Soffer wrote:

On Wed, Oct 26, 2022 at 4:31 PM Hanna Reitz  wrote:

On 01.09.22 16:32, Nir Soffer wrote:
> Add simple tests creating an image with all kinds of extents,
different
> formats, different backing chain, different protocol, and different
> image options. Since all images have the same guest visible
content they
> must have the same checksum.
>
> To help debugging in case of failures, the output includes a
json map of
> every test image.
>
> Signed-off-by: Nir Soffer 
> ---
>   tests/qemu-iotests/tests/qemu-img-checksum    | 149
++
>   .../qemu-iotests/tests/qemu-img-checksum.out  |  74 +
>   2 files changed, 223 insertions(+)
>   create mode 100755 tests/qemu-iotests/tests/qemu-img-checksum
>   create mode 100644 tests/qemu-iotests/tests/qemu-img-checksum.out
>
> diff --git a/tests/qemu-iotests/tests/qemu-img-checksum
b/tests/qemu-iotests/tests/qemu-img-checksum
> new file mode 100755
> index 00..3a85ba33f2
> --- /dev/null
> +++ b/tests/qemu-iotests/tests/qemu-img-checksum
> @@ -0,0 +1,149 @@
> +#!/usr/bin/env python3
> +# group: rw auto quick
> +#
> +# Test cases for qemu-img checksum.
> +#
> +# Copyright (C) 2022 Red Hat, Inc.
> +#
> +# This program is free software; you can redistribute it and/or
modify
> +# it under the terms of the GNU General Public License as
published by
> +# the Free Software Foundation; either version 2 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see
.
> +
> +import re
> +
> +import iotests
> +
> +from iotests import (
> +    filter_testfiles,
> +    qemu_img,
> +    qemu_img_log,
> +    qemu_io,
> +    qemu_nbd_popen,
> +)
> +
> +
> +def checksum_available():
> +    out = qemu_img("--help").stdout
> +    return re.search(r"\bchecksum .+ filename\b", out) is not None
> +
> +
> +if not checksum_available():
> +    iotests.notrun("checksum command not available")
> +
> +iotests.script_initialize(
> +    supported_fmts=["raw", "qcow2"],
> +    supported_cache_modes=["none", "writeback"],

It doesn’t work with writeback, though, because it uses -T none below.


Good point


Which by the way is a heavy cost, because I usually run tests in
tmpfs,
where this won’t work.  Is there any way of not doing the -T none
below?


Testing using tempfs is problematic since you cannot test -T none.In 
oVirt
we alway use /var/tmp which usually uses something that supports 
direct I/O.


Do we have a way to specify cache mode in the tests, so we can use -T none
only when the option is set?


`./check` has a `-c` option (e.g. `./check -c none`), which lands in 
`iotests.cachemode`.  That isn’t automatically passed to qemu-img calls, 
but you can do it manually (i.e. `qemu_img_log("checksum", "-T", 
iotests.cachemode, disk_top)` instead of `"-T", "none"`).




> +    supported_protocols=["file", "nbd"],
> +    required_fmts=["raw", "qcow2"],
> +)
> +
> +print()
> +print("=== Test images ===")
> +print()
> +
> +disk_raw = iotests.file_path('raw')
> +qemu_img("create", "-f", "raw", disk_raw, "10m")
> +qemu_io("-f", "raw",
> +        "-c", "write -P 0x1 0 2m",      # data
> +        "-c", "write -P 0x0 2m 2m",     # data with zeroes
> +        "-c", "write -z 4m 2m",         # zero allocated
> +        "-c", "write -z -u 6m 2m",      # zero hole
> +                                        # unallocated
> +        disk_raw)
> +print(filter_testfiles(disk_raw))
> +qemu_img_log("map", "--output", "json", disk_raw)
> +
> +disk_qcow2 = iotests.file_path('qcow2')
> +qemu_img("create", "-f", "qcow2", disk_qcow2, "10m")
> +qemu_io("-f", "qcow2",
> +        "-c", "write -P 0x1 0 2m",      # data
> +        "-c", "write -P 0x0 2m 2m",     # data with zeroes
> +        "-c", "write -z 4m 2m",         # zero allocated
> +        "-c", "write -z -u 6m 2m",      # zero hole
> +                                        # unallocated
> +        disk_qcow2)
> +print(filter_testfiles(disk_qcow2))
> +qemu_img_log("map", "--output", "json", disk_qcow2)

This isn’t how iotests work, generally.  When run with -qcow2
-file, it
should only test qcow2 on file, not raw on file, not raw on nbd.
Perhaps
   

Re: [PATCH 1/3] net: Move the code to collect available NIC models to a separate function

[Claudio Fontana]

On 11/4/22 13:57, Thomas Huth wrote:
> The code that collects the available NIC models is not really specific
> to PCI anymore and will be required in the next patch, too, so let's
> move this into a new separate function in net.c instead.
> 
> Signed-off-by: Thomas Huth 
> ---
>  include/net/net.h |  1 +
>  hw/pci/pci.c  | 29 +
>  net/net.c | 36 
>  3 files changed, 38 insertions(+), 28 deletions(-)
> 
> diff --git a/include/net/net.h b/include/net/net.h
> index 3db75ff841..c96cefb89a 100644
> --- a/include/net/net.h
> +++ b/include/net/net.h
> @@ -189,6 +189,7 @@ void qemu_set_vnet_hdr_len(NetClientState *nc, int len);
>  int qemu_set_vnet_le(NetClientState *nc, bool is_le);
>  int qemu_set_vnet_be(NetClientState *nc, bool is_be);
>  void qemu_macaddr_default_if_unset(MACAddr *macaddr);
> +GPtrArray *qemu_get_nic_models(const char *device_type);

I know there is no precedent in this file, but it would be useful to document 
this function,
what it does exactly and what it returns, the return value, allocation 
assumptions etc.

>  int qemu_show_nic_models(const char *arg, const char *const *models);
>  void qemu_check_nic_model(NICInfo *nd, const char *model);
>  int qemu_find_nic_model(NICInfo *nd, const char * const *models,
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 2f450f6a72..2b7b343e82 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1964,7 +1964,6 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
> *rootbus,
> const char *default_devaddr)
>  {
>  const char *devaddr = nd->devaddr ? nd->devaddr : default_devaddr;
> -GSList *list;
>  GPtrArray *pci_nic_models;
>  PCIBus *bus;
>  PCIDevice *pci_dev;
> @@ -1979,33 +1978,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
> *rootbus,
>  nd->model = g_strdup("virtio-net-pci");
>  }
>  
> -list = object_class_get_list_sorted(TYPE_PCI_DEVICE, false);
> -pci_nic_models = g_ptr_array_new();
> -while (list) {
> -DeviceClass *dc = OBJECT_CLASS_CHECK(DeviceClass, list->data,
> - TYPE_DEVICE);
> -GSList *next;
> -if (test_bit(DEVICE_CATEGORY_NETWORK, dc->categories) &&
> -dc->user_creatable) {
> -const char *name = object_class_get_name(list->data);
> -/*
> - * A network device might also be something else than a NIC, see
> - * e.g. the "rocker" device. Thus we have to look for the 
> "netdev"
> - * property, too. Unfortunately, some devices like virtio-net 
> only
> - * create this property during instance_init, so we have to 
> create
> - * a temporary instance here to be able to check it.
> - */
> -Object *obj = object_new_with_class(OBJECT_CLASS(dc));
> -if (object_property_find(obj, "netdev")) {
> -g_ptr_array_add(pci_nic_models, (gpointer)name);
> -}
> -object_unref(obj);
> -}
> -next = list->next;
> -g_slist_free_1(list);
> -list = next;
> -}
> -g_ptr_array_add(pci_nic_models, NULL);
> +pci_nic_models = qemu_get_nic_models(TYPE_PCI_DEVICE);
>  
>  if (qemu_show_nic_models(nd->model, (const char 
> **)pci_nic_models->pdata)) {
>  exit(0);
> diff --git a/net/net.c b/net/net.c
> index 840ad9dca5..c0516a8067 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -899,6 +899,42 @@ static int nic_get_free_idx(void)
>  return -1;
>  }
>  
> +GPtrArray *qemu_get_nic_models(const char *device_type)
> +{
> +GPtrArray *nic_models;
> +GSList *list;
> +
> +list = object_class_get_list_sorted(device_type, false);
> +nic_models = g_ptr_array_new();
> +while (list) {
> +DeviceClass *dc = OBJECT_CLASS_CHECK(DeviceClass, list->data,
> + TYPE_DEVICE);
> +GSList *next;
> +if (test_bit(DEVICE_CATEGORY_NETWORK, dc->categories) &&
> +dc->user_creatable) {
> +const char *name = object_class_get_name(list->data);
> +/*
> + * A network device might also be something else than a NIC, see
> + * e.g. the "rocker" device. Thus we have to look for the 
> "netdev"
> + * property, too. Unfortunately, some devices like virtio-net 
> only
> + * create this property during instance_init, so we have to 
> create
> + * a temporary instance here to be able to check it.
> + */
> +Object *obj = object_new_with_class(OBJECT_CLASS(dc));
> +if (object_property_find(obj, "netdev")) {
> +g_ptr_array_add(nic_models, (gpointer)name);
> +}
> +object_unref(obj);
> +}
> +next = list->next;
> +g_slist_free_1(list);
> +list = next;
> +}
> +g_ptr_array_a

[RFC PATCH] hw/virtio: introduce virtio_device_should_start

[Alex Bennée]

The previous fix to virtio_device_started revealed a problem in its
use by both the core and the device code. The core code should be able
to handle the device "starting" while the VM isn't running to handle
the restoration of migration state. To solve this duel use introduce a
new helper for use by the vhost-user backends who all use it to feed a
should_start variable.

We can also pick up a change vhost_user_blk_set_status while we are at
it which follows the same pattern.

Fixes: 9f6bcfd99f (hw/virtio: move vm_running check to virtio_device_started)
Signed-off-by: Alex Bennée 
Cc: "Michael S. Tsirkin" 
---
 include/hw/virtio/virtio.h   | 18 ++
 hw/block/vhost-user-blk.c|  6 +-
 hw/virtio/vhost-user-fs.c|  2 +-
 hw/virtio/vhost-user-gpio.c  |  2 +-
 hw/virtio/vhost-user-i2c.c   |  2 +-
 hw/virtio/vhost-user-rng.c   |  2 +-
 hw/virtio/vhost-user-vsock.c |  2 +-
 hw/virtio/vhost-vsock.c  |  2 +-
 8 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index f41b4a7e64..3191c618f3 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -389,6 +389,24 @@ static inline bool virtio_device_started(VirtIODevice 
*vdev, uint8_t status)
 return vdev->started;
 }
 
+return status & VIRTIO_CONFIG_S_DRIVER_OK;
+}
+
+/**
+ * virtio_device_should_start() - check if device startable
+ * @vdev - the VirtIO device
+ * @status - the devices status bits
+ *
+ * This is similar to virtio_device_started() but also encapsulates a
+ * check on the VM status which would prevent a device starting
+ * anyway.
+ */
+static inline bool virtio_device_should_start(VirtIODevice *vdev, uint8_t 
status)
+{
+if (vdev->use_started) {
+return vdev->started;
+}
+
 if (!vdev->vm_running) {
 return false;
 }
diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
index 13bf5cc47a..8feaf12e4e 100644
--- a/hw/block/vhost-user-blk.c
+++ b/hw/block/vhost-user-blk.c
@@ -222,14 +222,10 @@ static void vhost_user_blk_stop(VirtIODevice *vdev)
 static void vhost_user_blk_set_status(VirtIODevice *vdev, uint8_t status)
 {
 VHostUserBlk *s = VHOST_USER_BLK(vdev);
-bool should_start = virtio_device_started(vdev, status);
+bool should_start = virtio_device_should_start(vdev, status);
 Error *local_err = NULL;
 int ret;
 
-if (!vdev->vm_running) {
-should_start = false;
-}
-
 if (!s->connected) {
 return;
 }
diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
index ad0f91c607..1c40f42045 100644
--- a/hw/virtio/vhost-user-fs.c
+++ b/hw/virtio/vhost-user-fs.c
@@ -123,7 +123,7 @@ static void vuf_stop(VirtIODevice *vdev)
 static void vuf_set_status(VirtIODevice *vdev, uint8_t status)
 {
 VHostUserFS *fs = VHOST_USER_FS(vdev);
-bool should_start = virtio_device_started(vdev, status);
+bool should_start = virtio_device_should_start(vdev, status);
 
 if (vhost_dev_is_started(&fs->vhost_dev) == should_start) {
 return;
diff --git a/hw/virtio/vhost-user-gpio.c b/hw/virtio/vhost-user-gpio.c
index 8b40fe450c..677d1c7730 100644
--- a/hw/virtio/vhost-user-gpio.c
+++ b/hw/virtio/vhost-user-gpio.c
@@ -152,7 +152,7 @@ static void vu_gpio_stop(VirtIODevice *vdev)
 static void vu_gpio_set_status(VirtIODevice *vdev, uint8_t status)
 {
 VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev);
-bool should_start = virtio_device_started(vdev, status);
+bool should_start = virtio_device_should_start(vdev, status);
 
 trace_virtio_gpio_set_status(status);
 
diff --git a/hw/virtio/vhost-user-i2c.c b/hw/virtio/vhost-user-i2c.c
index bc58b6c0d1..864eba695e 100644
--- a/hw/virtio/vhost-user-i2c.c
+++ b/hw/virtio/vhost-user-i2c.c
@@ -93,7 +93,7 @@ static void vu_i2c_stop(VirtIODevice *vdev)
 static void vu_i2c_set_status(VirtIODevice *vdev, uint8_t status)
 {
 VHostUserI2C *i2c = VHOST_USER_I2C(vdev);
-bool should_start = virtio_device_started(vdev, status);
+bool should_start = virtio_device_should_start(vdev, status);
 
 if (vhost_dev_is_started(&i2c->vhost_dev) == should_start) {
 return;
diff --git a/hw/virtio/vhost-user-rng.c b/hw/virtio/vhost-user-rng.c
index bc1f36c5ac..8b47287875 100644
--- a/hw/virtio/vhost-user-rng.c
+++ b/hw/virtio/vhost-user-rng.c
@@ -90,7 +90,7 @@ static void vu_rng_stop(VirtIODevice *vdev)
 static void vu_rng_set_status(VirtIODevice *vdev, uint8_t status)
 {
 VHostUserRNG *rng = VHOST_USER_RNG(vdev);
-bool should_start = virtio_device_started(vdev, status);
+bool should_start = virtio_device_should_start(vdev, status);
 
 if (vhost_dev_is_started(&rng->vhost_dev) == should_start) {
 return;
diff --git a/hw/virtio/vhost-user-vsock.c b/hw/virtio/vhost-user-vsock.c
index 7b67e29d83..9431b9792c 100644
--- a/hw/virtio/vhost-user-vsock.c
+++ b/hw/virtio/vhost-user-vsock.c
@@ -55,7 +55,7 @@ const VhostDevConfigOps vsock_ops = {
 static void vuv_set_st

Re: [RFC PATCH] hw/virtio: introduce virtio_device_should_start

[Michael S. Tsirkin]

On Mon, Nov 07, 2022 at 12:14:07PM +, Alex Bennée wrote:
> The previous fix to virtio_device_started revealed a problem in its
> use by both the core and the device code. The core code should be able
> to handle the device "starting" while the VM isn't running to handle
> the restoration of migration state. To solve this duel use introduce a
> new helper for use by the vhost-user backends who all use it to feed a
> should_start variable.
> 
> We can also pick up a change vhost_user_blk_set_status while we are at
> it which follows the same pattern.
> 
> Fixes: 9f6bcfd99f (hw/virtio: move vm_running check to virtio_device_started)
> Signed-off-by: Alex Bennée 
> Cc: "Michael S. Tsirkin" 

Hi Alex, did you actually check this under gitlab CI?


> ---
>  include/hw/virtio/virtio.h   | 18 ++
>  hw/block/vhost-user-blk.c|  6 +-
>  hw/virtio/vhost-user-fs.c|  2 +-
>  hw/virtio/vhost-user-gpio.c  |  2 +-
>  hw/virtio/vhost-user-i2c.c   |  2 +-
>  hw/virtio/vhost-user-rng.c   |  2 +-
>  hw/virtio/vhost-user-vsock.c |  2 +-
>  hw/virtio/vhost-vsock.c  |  2 +-
>  8 files changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index f41b4a7e64..3191c618f3 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -389,6 +389,24 @@ static inline bool virtio_device_started(VirtIODevice 
> *vdev, uint8_t status)
>  return vdev->started;
>  }
>  
> +return status & VIRTIO_CONFIG_S_DRIVER_OK;
> +}
> +
> +/**
> + * virtio_device_should_start() - check if device startable
> + * @vdev - the VirtIO device
> + * @status - the devices status bits
> + *
> + * This is similar to virtio_device_started() but also encapsulates a
> + * check on the VM status which would prevent a device starting
> + * anyway.
> + */
> +static inline bool virtio_device_should_start(VirtIODevice *vdev, uint8_t 
> status)
> +{
> +if (vdev->use_started) {
> +return vdev->started;
> +}
> +
>  if (!vdev->vm_running) {
>  return false;
>  }
> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> index 13bf5cc47a..8feaf12e4e 100644
> --- a/hw/block/vhost-user-blk.c
> +++ b/hw/block/vhost-user-blk.c
> @@ -222,14 +222,10 @@ static void vhost_user_blk_stop(VirtIODevice *vdev)
>  static void vhost_user_blk_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserBlk *s = VHOST_USER_BLK(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_should_start(vdev, status);
>  Error *local_err = NULL;
>  int ret;
>  
> -if (!vdev->vm_running) {
> -should_start = false;
> -}
> -
>  if (!s->connected) {
>  return;
>  }
> diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
> index ad0f91c607..1c40f42045 100644
> --- a/hw/virtio/vhost-user-fs.c
> +++ b/hw/virtio/vhost-user-fs.c
> @@ -123,7 +123,7 @@ static void vuf_stop(VirtIODevice *vdev)
>  static void vuf_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserFS *fs = VHOST_USER_FS(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_should_start(vdev, status);
>  
>  if (vhost_dev_is_started(&fs->vhost_dev) == should_start) {
>  return;
> diff --git a/hw/virtio/vhost-user-gpio.c b/hw/virtio/vhost-user-gpio.c
> index 8b40fe450c..677d1c7730 100644
> --- a/hw/virtio/vhost-user-gpio.c
> +++ b/hw/virtio/vhost-user-gpio.c
> @@ -152,7 +152,7 @@ static void vu_gpio_stop(VirtIODevice *vdev)
>  static void vu_gpio_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_should_start(vdev, status);
>  
>  trace_virtio_gpio_set_status(status);
>  
> diff --git a/hw/virtio/vhost-user-i2c.c b/hw/virtio/vhost-user-i2c.c
> index bc58b6c0d1..864eba695e 100644
> --- a/hw/virtio/vhost-user-i2c.c
> +++ b/hw/virtio/vhost-user-i2c.c
> @@ -93,7 +93,7 @@ static void vu_i2c_stop(VirtIODevice *vdev)
>  static void vu_i2c_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserI2C *i2c = VHOST_USER_I2C(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_should_start(vdev, status);
>  
>  if (vhost_dev_is_started(&i2c->vhost_dev) == should_start) {
>  return;
> diff --git a/hw/virtio/vhost-user-rng.c b/hw/virtio/vhost-user-rng.c
> index bc1f36c5ac..8b47287875 100644
> --- a/hw/virtio/vhost-user-rng.c
> +++ b/hw/virtio/vhost-user-rng.c
> @@ -90,7 +90,7 @@ static void vu_rng_stop(VirtIODevice *vdev)
>  static void vu_rng_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserRNG *rng = VHOST_USER_RNG(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_shoul

Re: [PATCH 2/3] net: Restore printing of the help text with "-nic help"

[Claudio Fontana]

should -net and -netdev be adapted too?

For audio, we now have support for help options in both -audiodev and -audio..

Thanks,

Claudio

On 11/4/22 13:57, Thomas Huth wrote:
> Running QEMU with "-nic help" used to work in QEMU 5.2 and earlier versions
> (it showed the available netdev backends), but this feature got broken during
> some refactoring in version 6.0. Let's restore the old behavior, and while
> we're at it, let's also print the available NIC models here now since this
> option can be used to configure both, netdev backend and model in one go.
> 
> Fixes: ad6f932fe8 ("net: do not exit on "netdev_add help" monitor command")
> Signed-off-by: Thomas Huth 
> ---
>  net/net.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/net/net.c b/net/net.c
> index c0516a8067..b4b8f2a9cc 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -1571,8 +1571,18 @@ static int net_param_nic(void *dummy, QemuOpts *opts, 
> Error **errp)
>  const char *type;
>  
>  type = qemu_opt_get(opts, "type");
> -if (type && g_str_equal(type, "none")) {
> -return 0;/* Nothing to do, default_net is cleared in vl.c */
> +if (type) {
> +if (g_str_equal(type, "none")) {
> +return 0;/* Nothing to do, default_net is cleared in vl.c */
> +}
> +if (is_help_option(type)) {
> +GPtrArray *nic_models = qemu_get_nic_models(TYPE_DEVICE);
> +show_netdevs();
> +printf("\n");
> +qemu_show_nic_models(type, (const char **)nic_models->pdata);
> +g_ptr_array_free(nic_models, true);
> +exit(0);
> +}
>  }
>  
>  idx = nic_get_free_idx();

Re: [PATCH 3/3] net: Replace "Supported NIC models" with "Available NIC models"

[Claudio Fontana]

On 11/4/22 13:57, Thomas Huth wrote:
> Just because a NIC model is compiled into the QEMU binary does not
> necessary mean that it can be used with each and every machine.
> So let's rather talk about "available" models instead of "supported"
> models, just to avoid confusion.
> 
> Signed-off-by: Thomas Huth 
> ---
>  net/net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/net.c b/net/net.c
> index b4b8f2a9cc..173195dbf9 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -943,7 +943,7 @@ int qemu_show_nic_models(const char *arg, const char 
> *const *models)
>  return 0;
>  }
>  
> -printf("Supported NIC models:\n");
> +printf("Available NIC models:\n");
>  for (i = 0 ; models[i]; i++) {
>  printf("%s\n", models[i]);
>  }

Reviewed-by: Claudio Fontana 

Re: [PULL v3 00/81] pci,pc,virtio: features, tests, fixes, cleanups

[Michael S. Tsirkin]

On Mon, Nov 07, 2022 at 05:43:44AM -0500, Stefan Hajnoczi wrote:
> Hi Michael and Igor,
> Looks like the ACPI commits broken the virtio-vga module:
> 
> >>> QTEST_QEMU_IMG=./qemu-img MALLOC_PERTURB_=60 
> >>> G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh 
> >>> QTEST_QEMU_BINARY=./qemu-system-or1k 
> >>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon 
> >>> /builds/qemu-project/qemu/build/tests/qtest/device-introspect-test --tap 
> >>> -k
> ― ✀ ―
> stderr:
> failed to open module:
> /builds/qemu-project/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
> undefined symbol: aml_return
> qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
> NULL' failed.
> Broken pipe
> ../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
> signal 6 (Aborted) (core dumped)
> TAP parsing error: Too few tests run (expected 6, got 0)
> (test program exited with status code -6)
> ――
> 154/274 qemu:qtest+qtest-or1k / qtest-or1k/machine-none-test OK 0.05s
> 1 subtests passed
> 155/274 qemu:qtest+qtest-or1k / qtest-or1k/qmp-test OK 0.19s 4 subtests passed
> 156/274 qemu:qtest+qtest-or1k / qtest-or1k/qmp-cmd-test ERROR 1.72s
> killed by signal 6 SIGABRT
> >>> QTEST_QEMU_IMG=./qemu-img 
> >>> G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh 
> >>> QTEST_QEMU_BINARY=./qemu-system-or1k 
> >>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon 
> >>> MALLOC_PERTURB_=53 
> >>> /builds/qemu-project/qemu/build/tests/qtest/qmp-cmd-test --tap -k
> ― ✀ ―
> stderr:
> failed to open module:
> /builds/qemu-project/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
> undefined symbol: aml_return
> qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
> NULL' failed.
> Broken pipe
> ../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
> signal 6 (Aborted) (core dumped)
> TAP parsing error: Too few tests run (expected 62, got 31)
> (test program exited with status code -6)
> ――
> 
> https://gitlab.com/qemu-project/qemu/-/jobs/3281425457
> 
> Stefan


Hmm it passed for me:

https://gitlab.com/mstredhat/qemu/-/jobs/3279401710

Igor you did make a change around VGA:

commit 03d525c27ab0b268cf375d8823f05e91509222b8
Author: Igor Mammedov 
Date:   Mon Oct 17 12:21:36 2022 +0200

acpi: pc: vga: use AcpiDevAmlIf interface to build VGA device descriptors

Signed-off-by: Igor Mammedov 
Message-Id: <20221017102146.2254096-2-imamm...@redhat.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
NB: we do not expect any functional change in
any ACPI tables with this change. It's only a refactoring.

Reviewed-by: Ani Sinha 


can you take a look pls?
How bad is it if I drop that patch?


-- 
MST
How is ths different

Re: [PULL v3 49/81] acpi: pc: vga: use AcpiDevAmlIf interface to build VGA device descriptors

[Michael S. Tsirkin]

On Sun, Nov 06, 2022 at 10:16:41PM +0100, Bernhard Beschow wrote:
> 
> 
> On Sat, Nov 5, 2022 at 6:45 PM Michael S. Tsirkin  wrote:
> 
> From: Igor Mammedov 
> 
> Signed-off-by: Igor Mammedov 
> Message-Id: <20221017102146.2254096-2-imamm...@redhat.com>
> Reviewed-by: Michael S. Tsirkin 
> Signed-off-by: Michael S. Tsirkin 
> NB: we do not expect any functional change in
> any ACPI tables with this change. It's only a refactoring.
> 
> Reviewed-by: Ani Sinha 
> ---
>  hw/display/vga_int.h       |  2 ++
>  hw/display/acpi-vga-stub.c |  7 +++
>  hw/display/acpi-vga.c      | 26 ++
>  hw/display/vga-pci.c       |  4 
>  hw/i386/acpi-build.c       | 26 +-
>  hw/display/meson.build     | 17 +
>  6 files changed, 57 insertions(+), 25 deletions(-)
>  create mode 100644 hw/display/acpi-vga-stub.c
>  create mode 100644 hw/display/acpi-vga.c
> 
> 
> With this "qemu:qtest+qtest-hppa / qtest-hppa/display-vga-test" fails due to
> the symbol "aml_return" being undefined:
> 
> # starting QEMU: exec ./qemu-system-hppa -qtest unix:/tmp/qtest-515650.sock
> -qtest-log /dev/null -chardev socket,path=/tmp/qtest-515650.qmp,id=char0 -mon
> chardev=char0,mode=control -display none -vga none -device virtio-vga -accel
> qtest
> --- stderr ---
> Failed to open module: qemu/build/qemu-bundle/usr/lib/qemu/
> hw-display-virtio-vga.so: undefined symbol: aml_return
> qemu-system-hppa: -device virtio-vga: 'virtio-vga' is not a valid device model
> name
> Broken pipe
> ../src/tests/qtest/libqtest.c:179: kill_qemu() tried to terminate QEMU process
> but encountered exit status 1 (expected 0)
> 
> (test program exited with status code -6)
> 
> Best regards,
> Bernhard

It's unfortunate that it doesn't reproduce for me :(
what's the system config look like?

-- 
MST

Re: [PATCH 0/2] util/log: Make the per-thread flag immutable

[Greg Kurz]

On Sat, 5 Nov 2022 09:37:26 +1100
Richard Henderson  wrote:

> On 11/4/22 23:00, Greg Kurz wrote:
> > While working on the "util/log: Always send errors to logfile when 
> > daemonized"
> > series [1], I've encountered some issues with the per-thread flag. They stem
> > from the code not being designed to allow the per-thread flag to be enabled
> > or disabled more than once, but nothing is done to prevent that from
> > happening. This results in unexpected results like the creation of a log
> > file with a `%d` in its name or confusing errors when using the `log`
> > command in the monitor.
> > 
> > I'm posting fixes separately now in case it makes sense to merge them during
> > soft freeze. If so, I'll open an issue as explained in this recent mail [2].
> > 
> > [1] https://patchew.org/QEMU/20221019151651.334334-1-gr...@kaod.org/
> > [2] https://lists.nongnu.org/archive/html/qemu-devel/2022-11/msg00137.html
> > 
> > Date: Wed, 19 Oct 2022 17:16:49 +0200
> > Message-ID: <20221019151651.334334-1-gr...@kaod.org>
> > 
> > Greg Kurz (2):
> >util/log: Make the per-thread flag immutable
> >util/log: Ignore per-thread flag if global file already there
> > 
> >   util/log.c | 9 +
> >   1 file changed, 9 insertions(+)
> > 
> 
> Series:
> Reviewed-by: Richard Henderson 
> 

Thanks for the quick review Richard !

I've created https://gitlab.com/qemu-project/qemu/-/issues/1302 with
a 7.2 milestone.

Paolo,

Can you queue this ?

Cheers,

--
Greg

> 
> r~

Re: [PATCH 2/3] hvf: implement guest debugging on Apple Silicon hosts

[Mads Ynddal]

> On 4 Nov 2022, at 19.41, francesco.cag...@gmail.com wrote:
> 
> From: Francesco Cagnin 
> 
> Support is added for single-stepping, software breakpoints, hardware
> breakpoints and watchpoints. The code has been structured like the KVM
> counterpart (and many parts are basically identical).
> 
> Guests can be debugged through the gdbstub.
> 
> Signed-off-by: Francesco Cagnin 
> ---
> accel/hvf/hvf-accel-ops.c | 124 
> accel/hvf/hvf-all.c   |  24 +
> cpu.c |   3 +
> include/sysemu/hvf.h  |  29 ++
> include/sysemu/hvf_int.h  |   1 +
> target/arm/hvf/hvf.c  | 194 +-
> 6 files changed, 374 insertions(+), 1 deletion(-)


I've been working on the exact same features just last week, and had it working 
just hours before you posted, but you beat me to it. I can see we have solved it
almost exactly the same way, so I won't post my patchset.

I can see you are missing support for SSTEP_NOIRQ. I've handled it like this:

diff --git a/accel/hvf/hvf-accel-ops.c b/accel/hvf/hvf-accel-ops.c
index 5ff5778d55..8b96d2f320 100644
--- a/accel/hvf/hvf-accel-ops.c
+++ b/accel/hvf/hvf-accel-ops.c
@@ -343,7 +343,7 @@ static int hvf_accel_init(MachineState *ms)

 static int hvf_gdbstub_sstep_flags(void)
 {
-return SSTEP_ENABLE;
+return SSTEP_ENABLE | SSTEP_NOIRQ;
 }

 static void hvf_accel_class_init(ObjectClass *oc, void *data)
diff --git a/target/arm/hvf/hvf.c b/target/arm/hvf/hvf.c
index dbc3605f6d..964a4ecf8a 100644
--- a/target/arm/hvf/hvf.c
+++ b/target/arm/hvf/hvf.c
@@ -1331,7 +1331,7 @@ int hvf_vcpu_exec(CPUState *cpu)
 hv_return_t r;
 bool advance_pc = false;

-if (hvf_inject_interrupts(cpu)) {
+if (!(cpu->singlestep_enabled & SSTEP_NOIRQ) && 
hvf_inject_interrupts(cpu)) {
 return EXCP_INTERRUPT;
 }

You'll have to suppress the interrupts while you're single-stepping the code. 
Otherwise, you'll only be stepping a few times, and suddenly get taken to the
interrupt-handler.

What issues do you have with multi-core systems?

Re: [PULL v3 49/81] acpi: pc: vga: use AcpiDevAmlIf interface to build VGA device descriptors

[Ani Sinha]

On Mon, Nov 7, 2022 at 6:03 PM Michael S. Tsirkin  wrote:
>
> On Sun, Nov 06, 2022 at 10:16:41PM +0100, Bernhard Beschow wrote:
> >
> >
> > On Sat, Nov 5, 2022 at 6:45 PM Michael S. Tsirkin  wrote:
> >
> > From: Igor Mammedov 
> >
> > Signed-off-by: Igor Mammedov 
> > Message-Id: <20221017102146.2254096-2-imamm...@redhat.com>
> > Reviewed-by: Michael S. Tsirkin 
> > Signed-off-by: Michael S. Tsirkin 
> > NB: we do not expect any functional change in
> > any ACPI tables with this change. It's only a refactoring.
> >
> > Reviewed-by: Ani Sinha 
> > ---
> >  hw/display/vga_int.h   |  2 ++
> >  hw/display/acpi-vga-stub.c |  7 +++
> >  hw/display/acpi-vga.c  | 26 ++
> >  hw/display/vga-pci.c   |  4 
> >  hw/i386/acpi-build.c   | 26 +-
> >  hw/display/meson.build | 17 +
> >  6 files changed, 57 insertions(+), 25 deletions(-)
> >  create mode 100644 hw/display/acpi-vga-stub.c
> >  create mode 100644 hw/display/acpi-vga.c
> >
> >
> > With this "qemu:qtest+qtest-hppa / qtest-hppa/display-vga-test" fails due to
> > the symbol "aml_return" being undefined:
> >
> > # starting QEMU: exec ./qemu-system-hppa -qtest unix:/tmp/qtest-515650.sock
> > -qtest-log /dev/null -chardev socket,path=/tmp/qtest-515650.qmp,id=char0 
> > -mon
> > chardev=char0,mode=control -display none -vga none -device virtio-vga -accel
> > qtest
> > --- stderr 
> > ---
> > Failed to open module: qemu/build/qemu-bundle/usr/lib/qemu/
> > hw-display-virtio-vga.so: undefined symbol: aml_return
> > qemu-system-hppa: -device virtio-vga: 'virtio-vga' is not a valid device 
> > model
> > name
> > Broken pipe
> > ../src/tests/qtest/libqtest.c:179: kill_qemu() tried to terminate QEMU 
> > process
> > but encountered exit status 1 (expected 0)
> >
> > (test program exited with status code -6)
> >
> > Best regards,
> > Bernhard
>
> It's unfortunate that it doesn't reproduce for me :(

To reproduce:

- docker pull registry.gitlab.com/qemu-project/qemu/qemu/centos8:latest
- configure line:

../configure --enable-werror --disable-docs --disable-nettle
--enable-gcrypt --enable-fdt=system --enable-modules
--enable-trace-backends=dtrace --enable-docs --enable-vfio-user-server
--target-list="ppc64-softmmu or1k-softmmu s390x-softmmu x86_64-softmmu
rx-softmmu sh4-softmmu nios2-softmmu"

- # make
- # QTEST_QEMU_BINARY=./qemu-system-or1k  ./tests/qtest/qos-test
failed to open module:
/build/qemu/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
undefined symbol: aml_return
qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
NULL' failed.
Broken pipe
../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
signal 6 (Aborted) (core dumped)
Aborted (core dumped)

Re: [PULL v3 50/81] tests: acpi: whitelist DSDT before generating PCI-ISA bridge AML automatically

[Michael S. Tsirkin]

On Mon, Nov 07, 2022 at 02:06:23PM +0530, Ani Sinha wrote:
> On Mon, Nov 7, 2022 at 3:18 AM Bernhard Beschow  wrote:
> >
> >
> >
> > On Sat, Nov 5, 2022 at 6:27 PM Michael S. Tsirkin  wrote:
> >>
> >> From: Igor Mammedov 
> >>
> >> Signed-off-by: Igor Mammedov 
> >> Message-Id: <20221017102146.2254096-3-imamm...@redhat.com>
> >> Reviewed-by: Michael S. Tsirkin 
> >> Signed-off-by: Michael S. Tsirkin 
> >> ---
> >>  tests/qtest/bios-tables-test-allowed-diff.h | 34 +
> >>  1 file changed, 34 insertions(+)
> >>
> >> diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
> >> b/tests/qtest/bios-tables-test-allowed-diff.h
> >> index dfb8523c8b..570b17478e 100644
> >> --- a/tests/qtest/bios-tables-test-allowed-diff.h
> >> +++ b/tests/qtest/bios-tables-test-allowed-diff.h
> >> @@ -1 +1,35 @@
> >>  /* List of comma-separated changed AML files to ignore */
> >> +"tests/data/acpi/pc/DSDT",
> >> +"tests/data/acpi/pc/DSDT.acpierst",
> >> +"tests/data/acpi/pc/DSDT.acpihmat",
> >> +"tests/data/acpi/pc/DSDT.bridge",
> >> +"tests/data/acpi/pc/DSDT.cphp",
> >> +"tests/data/acpi/pc/DSDT.dimmpxm",
> >> +"tests/data/acpi/pc/DSDT.hpbridge",
> >> +"tests/data/acpi/pc/DSDT.hpbrroot",
> >> +"tests/data/acpi/pc/DSDT.ipmikcs",
> >> +"tests/data/acpi/pc/DSDT.memhp",
> >> +"tests/data/acpi/pc/DSDT.nohpet",
> >> +"tests/data/acpi/pc/DSDT.numamem",
> >> +"tests/data/acpi/pc/DSDT.roothp",
> >> +"tests/data/acpi/q35/DSDT",
> >> +"tests/data/acpi/q35/DSDT.acpierst",
> >> +"tests/data/acpi/q35/DSDT.acpihmat",
> >> +"tests/data/acpi/q35/DSDT.applesmc",
> >> +"tests/data/acpi/q35/DSDT.bridge",
> >
> >
> > +"tests/data/acpi/q35/DSDT.core-count2"
> >
> > ... and probably in more patches down the road.
> 
> Yes I am seeing this failure too:
> 
> 68/600 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test
>ERROR  39.95s   killed by signal 6 SIGABRT
> >>> QTEST_QEMU_IMG=./qemu-img 
> >>> QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon 
> >>> MALLOC_PERTURB_=138 
> >>> G_TEST_DBUS_DAEMON=/home/anisinha/workspace/qemu-ani/tests/dbus-vmstate-daemon.sh
> >>>  QTEST_QEMU_BINARY=./qemu-system-x86_64 
> >>> /home/anisinha/workspace/qemu-ani/build/tests/qtest/bios-tables-test 
> >>> --tap -k
> 
> ✀  
> ―
> stderr:
> acpi-test: Warning! DSDT binary file mismatch. Actual
> [aml:/tmp/aml-ARFCV1], Expected
> [aml:tests/data/acpi/q35/DSDT.core-count2].
> See source file tests/qtest/bios-tables-test.c for instructions on how
> to update expected files.
> acpi-test: Warning! DSDT mismatch. Actual [asl:/tmp/asl-NTFCV1.dsl,
> aml:/tmp/aml-ARFCV1], Expected [asl:/tmp/asl-15QEV1.dsl,
> aml:tests/data/acpi/q35/DSDT.core-count2].
> **
> ERROR:../tests/qtest/bios-tables-test.c:533:test_acpi_asl: assertion
> failed: (all_tables_match)



My bad. BTW we should probably teach checkpatch that if
an expected file is modified then it has to be dropped
from allowed diff list in the same patch.


> 
> 
> >
> > Best regards,
> > Bernhard
> >
> >> +"tests/data/acpi/q35/DSDT.cphp",
> >> +"tests/data/acpi/q35/DSDT.cxl",
> >> +"tests/data/acpi/q35/DSDT.dimmpxm",
> >> +"tests/data/acpi/q35/DSDT.ipmibt",
> >> +"tests/data/acpi/q35/DSDT.ipmismbus",
> >> +"tests/data/acpi/q35/DSDT.ivrs",
> >> +"tests/data/acpi/q35/DSDT.memhp",
> >> +"tests/data/acpi/q35/DSDT.mmio64",
> >> +"tests/data/acpi/q35/DSDT.multi-bridge",
> >> +"tests/data/acpi/q35/DSDT.nohpet",
> >> +"tests/data/acpi/q35/DSDT.numamem",
> >> +"tests/data/acpi/q35/DSDT.pvpanic-isa",
> >> +"tests/data/acpi/q35/DSDT.tis.tpm12",
> >> +"tests/data/acpi/q35/DSDT.tis.tpm2",
> >> +"tests/data/acpi/q35/DSDT.viot",
> >> +"tests/data/acpi/q35/DSDT.xapic",
> >> --
> >> MST
> >>
> >>

Re: [PATCH 1/3] arm: move KVM breakpoints helpers

[Mads Ynddal]

> On 4 Nov 2022, at 19.40, francesco.cag...@gmail.com wrote:
> 
> From: Francesco Cagnin 
> 
> These helpers will be also used for HVF. Aside from reformatting a
> couple of comments for 'checkpatch.pl', this is just code motion.
> 
> Signed-off-by: Francesco Cagnin 
> ---
> target/arm/debug_helper.c | 241 +
> target/arm/internals.h|  50 +++
> target/arm/kvm64.c| 276 --
> 3 files changed, 291 insertions(+), 276 deletions(-)

Looks good. I was going to do the exact same in my patchset.

Reviewed-by: Mads Ynddal 

Re: [PULL v3 49/81] acpi: pc: vga: use AcpiDevAmlIf interface to build VGA device descriptors

[Michael S. Tsirkin]

On Mon, Nov 07, 2022 at 06:16:25PM +0530, Ani Sinha wrote:
> On Mon, Nov 7, 2022 at 6:03 PM Michael S. Tsirkin  wrote:
> >
> > On Sun, Nov 06, 2022 at 10:16:41PM +0100, Bernhard Beschow wrote:
> > >
> > >
> > > On Sat, Nov 5, 2022 at 6:45 PM Michael S. Tsirkin  wrote:
> > >
> > > From: Igor Mammedov 
> > >
> > > Signed-off-by: Igor Mammedov 
> > > Message-Id: <20221017102146.2254096-2-imamm...@redhat.com>
> > > Reviewed-by: Michael S. Tsirkin 
> > > Signed-off-by: Michael S. Tsirkin 
> > > NB: we do not expect any functional change in
> > > any ACPI tables with this change. It's only a refactoring.
> > >
> > > Reviewed-by: Ani Sinha 
> > > ---
> > >  hw/display/vga_int.h   |  2 ++
> > >  hw/display/acpi-vga-stub.c |  7 +++
> > >  hw/display/acpi-vga.c  | 26 ++
> > >  hw/display/vga-pci.c   |  4 
> > >  hw/i386/acpi-build.c   | 26 +-
> > >  hw/display/meson.build | 17 +
> > >  6 files changed, 57 insertions(+), 25 deletions(-)
> > >  create mode 100644 hw/display/acpi-vga-stub.c
> > >  create mode 100644 hw/display/acpi-vga.c
> > >
> > >
> > > With this "qemu:qtest+qtest-hppa / qtest-hppa/display-vga-test" fails due 
> > > to
> > > the symbol "aml_return" being undefined:
> > >
> > > # starting QEMU: exec ./qemu-system-hppa -qtest 
> > > unix:/tmp/qtest-515650.sock
> > > -qtest-log /dev/null -chardev socket,path=/tmp/qtest-515650.qmp,id=char0 
> > > -mon
> > > chardev=char0,mode=control -display none -vga none -device virtio-vga 
> > > -accel
> > > qtest
> > > --- stderr 
> > > ---
> > > Failed to open module: qemu/build/qemu-bundle/usr/lib/qemu/
> > > hw-display-virtio-vga.so: undefined symbol: aml_return
> > > qemu-system-hppa: -device virtio-vga: 'virtio-vga' is not a valid device 
> > > model
> > > name
> > > Broken pipe
> > > ../src/tests/qtest/libqtest.c:179: kill_qemu() tried to terminate QEMU 
> > > process
> > > but encountered exit status 1 (expected 0)
> > >
> > > (test program exited with status code -6)
> > >
> > > Best regards,
> > > Bernhard
> >
> > It's unfortunate that it doesn't reproduce for me :(
> 
> To reproduce:
> 
> - docker pull registry.gitlab.com/qemu-project/qemu/qemu/centos8:latest
> - configure line:
> 
> ../configure --enable-werror --disable-docs --disable-nettle
> --enable-gcrypt --enable-fdt=system --enable-modules
> --enable-trace-backends=dtrace --enable-docs --enable-vfio-user-server
> --target-list="ppc64-softmmu or1k-softmmu s390x-softmmu x86_64-softmmu
> rx-softmmu sh4-softmmu nios2-softmmu"


I suspect --enable-modules is the difference.

> - # make
> - # QTEST_QEMU_BINARY=./qemu-system-or1k  ./tests/qtest/qos-test
> failed to open module:
> /build/qemu/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
> undefined symbol: aml_return
> qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
> NULL' failed.
> Broken pipe
> ../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
> signal 6 (Aborted) (core dumped)
> Aborted (core dumped)

[PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Sunil V L]

The pflash implementation currently assumes fixed size of the
backend storage. Due to this, the backend storage file needs to be
exactly of size 32M. Otherwise, there will be an error like below.

"device requires 33554432 bytes, block backend provides 4194304 bytes"

Fix this issue by using the actual size of the backing store.

Signed-off-by: Sunil V L 
---

Changes since V1:
1) Handle the case when blk_getlength() returns failure.
2) Added assertion to check actual size doesn't exceed the limit
3) Updated virt_machine_done() to find the flash base dynamically
4) Added code comments as suggested by Drew

 hw/riscv/virt.c | 59 -
 1 file changed, 48 insertions(+), 11 deletions(-)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index a5bc7353b4..b8ab1fd358 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -49,6 +49,7 @@
 #include "hw/pci/pci.h"
 #include "hw/pci-host/gpex.h"
 #include "hw/display/ramfb.h"
+#include "sysemu/block-backend.h"
 
 /*
  * The virt machine physical address space used by some of the devices
@@ -140,14 +141,32 @@ static void virt_flash_create(RISCVVirtState *s)
 }
 
 static void virt_flash_map1(PFlashCFI01 *flash,
-hwaddr base, hwaddr size,
+hwaddr base, hwaddr max_size,
 MemoryRegion *sysmem)
 {
 DeviceState *dev = DEVICE(flash);
+BlockBackend *blk;
+int64_t flash_size;
 
-assert(QEMU_IS_ALIGNED(size, VIRT_FLASH_SECTOR_SIZE));
-assert(size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
-qdev_prop_set_uint32(dev, "num-blocks", size / VIRT_FLASH_SECTOR_SIZE);
+blk = pflash_cfi01_get_blk(flash);
+
+if (blk) {
+flash_size = blk_getlength(blk);
+if (flash_size < 0) {
+error_report("can't get size of block device %s: %s",
+ blk_name(blk), strerror(-flash_size));
+exit(1);
+}
+} else {
+flash_size = max_size;
+}
+
+assert(flash_size > 0);
+assert(flash_size <= max_size);
+assert(QEMU_IS_ALIGNED(flash_size, VIRT_FLASH_SECTOR_SIZE));
+assert(flash_size / VIRT_FLASH_SECTOR_SIZE <= UINT32_MAX);
+qdev_prop_set_uint32(dev, "num-blocks",
+ flash_size / VIRT_FLASH_SECTOR_SIZE);
 sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), &error_fatal);
 
 memory_region_add_subregion(sysmem, base,
@@ -161,6 +180,14 @@ static void virt_flash_map(RISCVVirtState *s,
 hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
 hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
 
+/*
+ * The flash devices are created at fixed base addresses passed
+ * to virt_flash_map1().
+ * However, the flashsize passed here to virt_flash_map1()
+ * is the maximum size of the flash possible. The actual size
+ * is determined inside virt_flash_map1() and can be smaller
+ * than this maximum size based on the backend file size.
+ */
 virt_flash_map1(s->flash[0], flashbase, flashsize,
 sysmem);
 virt_flash_map1(s->flash[1], flashbase + flashsize, flashsize,
@@ -971,15 +998,24 @@ static void create_fdt_flash(RISCVVirtState *s, const 
MemMapEntry *memmap)
 {
 char *name;
 MachineState *mc = MACHINE(s);
-hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
-hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
+MemoryRegion *flash_mem;
+hwaddr flashsize[2];
+hwaddr flashbase[2];
+
+flash_mem = pflash_cfi01_get_memory(s->flash[0]);
+flashbase[0] = flash_mem->addr;
+flashsize[0] = flash_mem->size;
+
+flash_mem = pflash_cfi01_get_memory(s->flash[1]);
+flashbase[1] = flash_mem->addr;
+flashsize[1] = flash_mem->size;
 
-name = g_strdup_printf("/flash@%" PRIx64, flashbase);
+name = g_strdup_printf("/flash@%" PRIx64, flashbase[0]);
 qemu_fdt_add_subnode(mc->fdt, name);
 qemu_fdt_setprop_string(mc->fdt, name, "compatible", "cfi-flash");
 qemu_fdt_setprop_sized_cells(mc->fdt, name, "reg",
- 2, flashbase, 2, flashsize,
- 2, flashbase + flashsize, 2, flashsize);
+ 2, flashbase[0], 2, flashsize[0],
+ 2, flashbase[1], 2, flashsize[1]);
 qemu_fdt_setprop_cell(mc->fdt, name, "bank-width", 4);
 g_free(name);
 }
@@ -1242,6 +1278,7 @@ static void virt_machine_done(Notifier *notifier, void 
*data)
 target_ulong firmware_end_addr, kernel_start_addr;
 uint32_t fdt_load_addr;
 uint64_t kernel_entry;
+MemoryRegion *flash_mem;
 
 /*
  * Only direct boot kernel is currently supported for KVM VM,
@@ -1288,8 +1325,8 @@ static void virt_machine_done(Notifier *notifier, void 
*data)
  * In either case, the next_addr for opensbi will be the flash address.
  */
 riscv_setup_firmware_boot(machine);
-kernel_entry = virt_memmap[

Re: [PATCH 3/3] hvf: handle writes of MDSCR_EL1 and DBG*_EL1

[Mads Ynddal]

> On 4 Nov 2022, at 19.41, francesco.cag...@gmail.com wrote:
> 
> From: Francesco Cagnin 
> 
> This proved to be required when debugging the Linux kernel's initial
> code, as the Hypervisor framework was triggering 'EC_SYSTEMREGISTERTRAP'
> VM exits after enabling trap exceptions with
> 'hv_vcpu_set_trap_debug_exceptions()'.
> 
> Signed-off-by: Francesco Cagnin 
> ---
> target/arm/hvf/hvf.c | 140 +++
> 1 file changed, 140 insertions(+)

Reviewed-by: Mads Ynddal 

Re: [PATCH v2] vl: defuse PID file path resolve error

[Hanna Reitz]

On 31.10.22 10:47, Fiona Ebner wrote:

Commit 85c4bf8aa6 ("vl: Unlink absolute PID file path") introduced a
critical error when the PID file path cannot be resolved. Before this
commit, it was possible to invoke QEMU when the PID file was a file
created with mkstemp that was already unlinked at the time of the
invocation. There might be other similar scenarios.

It should not be a critical error when the PID file unlink notifier
can't be registered, because the path can't be resolved. If the file
is already gone from QEMU's perspective, silently ignore the error.
Otherwise, only print a warning.

Fixes: 85c4bf8aa6 ("vl: Unlink absolute PID file path")
Reported-by: Dominik Csapak 
Suggested-by: Thomas Lamprecht 
Signed-off-by: Fiona Ebner 
---

v1 -> v2:
 * Ignore error if errno == ENOENT.

  softmmu/vl.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)


Reviewed-by: Hanna Reitz 

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Peter Maydell]

On Mon, 7 Nov 2022 at 13:03, Sunil V L  wrote:
>
> The pflash implementation currently assumes fixed size of the
> backend storage. Due to this, the backend storage file needs to be
> exactly of size 32M. Otherwise, there will be an error like below.
>
> "device requires 33554432 bytes, block backend provides 4194304 bytes"
>
> Fix this issue by using the actual size of the backing store.
>
> Signed-off-by: Sunil V L 
> ---

Do you really want the flash device size presented to the guest
to be variable depending on what the user passed as a block backend?
I don't think this is how we handle flash devices on other boards...

thanks
-- PMM

Re: [PATCH v10 2/9] s390x/cpu topology: reporting the CPU topology to the guest

[Janis Schoetterl-Glausch]

On Fri, 2022-10-28 at 12:00 +0200, Pierre Morel wrote:
> 
> On 10/27/22 22:42, Janis Schoetterl-Glausch wrote:
> > On Wed, 2022-10-12 at 18:21 +0200, Pierre Morel wrote:
> > > The guest can use the STSI instruction to get a buffer filled
> > > with the CPU topology description.
> > > 
> > > Let us implement the STSI instruction for the basis CPU topology
> > > level, level 2.
> > > 
> > > Signed-off-by: Pierre Morel 
> > > ---
> > >   include/hw/s390x/cpu-topology.h |   3 +
> > >   target/s390x/cpu.h  |  48 ++
> > >   hw/s390x/cpu-topology.c |   8 ++-
> > >   target/s390x/cpu_topology.c | 109 
> > >   target/s390x/kvm/kvm.c  |   6 +-
> > >   target/s390x/meson.build|   1 +
> > >   6 files changed, 172 insertions(+), 3 deletions(-)
> > >   create mode 100644 target/s390x/cpu_topology.c
> > > 
> > > diff --git a/include/hw/s390x/cpu-topology.h 
> > > b/include/hw/s390x/cpu-topology.h
> > > index 66c171d0bc..61c11db017 100644
> > > --- a/include/hw/s390x/cpu-topology.h
> > > +++ b/include/hw/s390x/cpu-topology.h
> > > @@ -13,6 +13,8 @@
> > >   #include "hw/qdev-core.h"
> > >   #include "qom/object.h"
> > >   
> > > +#define S390_TOPOLOGY_POLARITY_H  0x00
> > > +
> > >   typedef struct S390TopoContainer {
> > >   int active_count;
> > >   } S390TopoContainer;
> > > @@ -29,6 +31,7 @@ struct S390Topology {
> > >   S390TopoContainer *socket;
> > >   S390TopoTLE *tle;
> > >   MachineState *ms;
> > > +QemuMutex topo_mutex;
> > >   };
> > >   
> > >   #define TYPE_S390_CPU_TOPOLOGY "s390-topology"
> > > diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
> > > index 7d6d01325b..d604aa9c78 100644
> > > --- a/target/s390x/cpu.h
> > > +++ b/target/s390x/cpu.h
> > > 
> > [...]
> > > +
> > > +/* Maxi size of a SYSIB structure is when all CPU are alone in a 
> > > container */
> > 
> > Max or Maximum.
> > 
> > > +#define S390_TOPOLOGY_SYSIB_SIZE (sizeof(SysIB_151x) +   
> > >   \
> > > +  S390_MAX_CPUS * 
> > > (sizeof(SysIBTl_container) + \
> > > +   sizeof(SysIBTl_cpu)))
> > 
> > Currently this is 16+248*3*8 == 5968 and will grow with books, drawer 
> > support to
> > 16+248*5*8 == 9936 ...
> > 
> > [...]
> > > 
> > > +
> > > +void insert_stsi_15_1_x(S390CPU *cpu, int sel2, __u64 addr, uint8_t ar)
> > > +{
> > > +uint64_t page[S390_TOPOLOGY_SYSIB_SIZE / sizeof(uint64_t)] = {};
> > 
> > ... so calling this page is a bit misleading. Also why not make it a char[]?
> > And maybe use a union for type punning.
> 
> OK, what about:
> 
>  union {
>  char place_holder[S390_TOPOLOGY_SYSIB_SIZE];
>  SysIB_151x sysib;
>  } buffer QEMU_ALIGNED(8);
> 
I don't think you need the QEMU_ALIGNED since SysIB_151x already has it. Not 
that it hurts to be
explicit. If you declared the tle member as uint64_t[], you should get the 
correct alignment
automatically and can then drop the explicit one.
Btw, [] seems to be preferred over [0], at least there is a commit doing a 
conversion:
f7795e4096 ("misc: Replace zero-length arrays with flexible array member 
(automatic)")
> 
> > 
> > > +SysIB_151x *sysib = (SysIB_151x *) page;
> > > +int len;
> > > +
> > > +if (s390_is_pv() || !s390_has_topology() ||
> > > +sel2 < 2 || sel2 > S390_TOPOLOGY_MAX_MNEST) {
> > > +setcc(cpu, 3);
> > > +return;
> > > +}
> > > +
> > > +len = setup_stsi(sysib, sel2);
> > 
> > This should now be memory safe, but might be larger than 4k,
> > the maximum size of the SYSIB. I guess you want to set cc code 3
> > in this case and return.
> 
> I do not find why the SYSIB can not be larger than 4k.
> Can you point me to this restriction?

Says so at the top of the description of STSI:

The SYSIB is 4K bytes and must begin at a 4 K-byte
boundary; otherwise, a specification exception may
be recognized.

Also the graphics show that it is 1024 words long.
> 
> 
> Regards,
> Pierre
> 

Re: [PATCH 2/3] hvf: implement guest debugging on Apple Silicon hosts

[Mads Ynddal]

> On 4 Nov 2022, at 19.41, francesco.cag...@gmail.com wrote:
> 
> From: Francesco Cagnin 
> 
> Support is added for single-stepping, software breakpoints, hardware
> breakpoints and watchpoints. The code has been structured like the KVM
> counterpart (and many parts are basically identical).
> 
> Guests can be debugged through the gdbstub.
> 
> Signed-off-by: Francesco Cagnin 
> ---
> accel/hvf/hvf-accel-ops.c | 124 
> accel/hvf/hvf-all.c   |  24 +
> cpu.c |   3 +
> include/sysemu/hvf.h  |  29 ++
> include/sysemu/hvf_int.h  |   1 +
> target/arm/hvf/hvf.c  | 194 +-
> 6 files changed, 374 insertions(+), 1 deletion(-)
> 
> diff --git a/include/sysemu/hvf.h b/include/sysemu/hvf.h
> index bb70082e45..3e99c80416 100644
> --- a/include/sysemu/hvf.h
> +++ b/include/sysemu/hvf.h
> @@ -1180,6 +1201,9 @@ int hvf_vcpu_exec(CPUState *cpu)
> 
> flush_cpu_state(cpu);
> 
> +r = hv_vcpu_set_trap_debug_exceptions(cpu->hvf->fd, 
> trap_debug_exceptions);
> +assert_hvf_ok(r);
> +
> qemu_mutex_unlock_iothread();
> assert_hvf_ok(hv_vcpu_run(cpu->hvf->fd));

We don't need to set this at every call to `hvf_vcpu_exec`. Would it make sense
to move it to `hvf_arch_update_guest_debug` or even `hvf_arch_init_vcpu`?

(CC'ed Alex Bennée as we discussed the GDB stub in HVF at KVM Forum 2022)

Re: [PULL v2 31/82] vhost: Change the sequence of device start

[Michael S. Tsirkin]

On Sun, Nov 06, 2022 at 07:00:33PM +0100, Christian A. Ehrhardt wrote:
> 
> Hi,
> 
> On Sat, Nov 05, 2022 at 12:43:05PM -0400, Michael S. Tsirkin wrote:
> > On Sat, Nov 05, 2022 at 05:35:57PM +0100, Bernhard Beschow wrote:
> > > 
> > > 
> > > On Wed, Nov 2, 2022 at 5:24 PM Michael S. Tsirkin  wrote:
> > > 
> > > From: Yajun Wu 
> > > 
> > > This patch is part of adding vhost-user vhost_dev_start support. The
> > > motivation is to improve backend configuration speed and reduce live
> > > migration VM downtime.
> > > 
> > > Moving the device start routines after finishing all the necessary 
> > > device
> > > and VQ configuration, further aligning to the virtio specification for
> > > "device initialization sequence".
> > > 
> > > Following patch will add vhost-user vhost_dev_start support.
> > > 
> > > Signed-off-by: Yajun Wu 
> > > Acked-by: Parav Pandit 
> > > 
> > > Message-Id: <20221017064452.1226514-2-yaj...@nvidia.com>
> > > Reviewed-by: Michael S. Tsirkin 
> > > Signed-off-by: Michael S. Tsirkin 
> > > ---
> > >  hw/block/vhost-user-blk.c | 18 +++---
> > >  hw/net/vhost_net.c        | 12 ++--
> > >  2 files changed, 17 insertions(+), 13 deletions(-)
> > > 
> > > 
> > > A git bisect tells me that this is the first bad commit for failing 
> > > qos-tests
> > > which only fail when parallel jobs are enabled, e.g. `make check-qtest 
> > > -j8`:
> 
> Parallel test run is not required provided that the test machine is
> sufficiently busy (load > number of CPU threads). In this case a single
> invocation of the qos test will fail reliably with this change.
> 
> However, the change is not really the root cause of the failures.
> 
> > > Summary of Failures:
> > > 
> > >  76/541 qemu:qtest+qtest-aarch64 / qtest-aarch64/qos-test                 
> > >      
> > >   ERROR          18.68s   killed by signal 6 SIGABRT
> > >  77/541 qemu:qtest+qtest-arm / qtest-arm/qos-test                         
> > >      
> > >   ERROR          17.60s   killed by signal 6 SIGABRT
> > >  93/541 qemu:qtest+qtest-i386 / qtest-i386/qos-test                       
> > >      
> > >   ERROR          18.98s   killed by signal 6 SIGABRT
> > > 108/541 qemu:qtest+qtest-ppc64 / qtest-ppc64/qos-test                     
> > >      
> > >   ERROR          16.40s   killed by signal 6 SIGABRT
> > > 112/541 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test               
> > >      
> > >   ERROR          145.94s   killed by signal 6 SIGABRT
> > > 130/541 qemu:qtest+qtest-x86_64 / qtest-x86_64/qos-test                   
> > >      
> > >   ERROR          17.32s   killed by signal 6 SIGABRT
> > > 243/541 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test           
> > >      
> > >   ERROR          127.70s   killed by signal 6 SIGABRT
> > > 
> > > Ok:                 500
> > > Expected Fail:      0  
> > > Fail:               7  
> > > Unexpected Pass:    0  
> > > Skipped:            34  
> > > Timeout:            0  
> > > 
> > > Can anyone else reproduce this?
> > 
> > Could you pls try latest for_upstream in my tree?
> > That should have this fixed.
> 
> Your new pull request simply drops this change and this does fix
> make check-qtest. However, this looks accidental to me and the real
> bug is there in plain origin/master, too.
> 
> What happens is this backtrace a recursive call to vu_gpio_stop
> via the backtrace below. It is caused by a delayed of the TCP
> connection (the delayed part only triggers with heavy load on the
> machine).
> 
> You can get the failure back (probably in upstream) if the test is
> forced to us "use-started=off" which can be set on the command line.
> E.g. like this:
> 
> diff --git a/tests/qtest/libqos/virtio-gpio.c 
> b/tests/qtest/libqos/virtio-gpio.c
> index 762aa6695b..17c6b71e8b 100644
> --- a/tests/qtest/libqos/virtio-gpio.c
> +++ b/tests/qtest/libqos/virtio-gpio.c
> @@ -154,14 +154,14 @@ static void virtio_gpio_register_nodes(void)
>  QOSGraphEdgeOptions edge_opts = { };
> 
>  /* vhost-user-gpio-device */
> -edge_opts.extra_device_opts = "id=gpio0,chardev=chr-vhost-user-test";
> +edge_opts.extra_device_opts = 
> "id=gpio0,chardev=chr-vhost-user-test,use-started=off";
>  qos_node_create_driver("vhost-user-gpio-device",
>  virtio_gpio_device_create);
>  qos_node_consumes("vhost-user-gpio-device", "virtio-bus", &edge_opts);
>  qos_node_produces("vhost-user-gpio-device", "vhost-user-gpio");
> 
>  /* virtio-gpio-pci */
> -edge_opts.extra_device_opts = 
> "id=gpio0,addr=04.0,chardev=chr-vhost-user-test";
> +edge_opts.extra_device_opts = 
> "id=gpio0,addr=04.0,chardev=chr-vhost-user-test,use-started=on";
>  add_qpci_address(&edge_opts, &addr);
>  qos_node_create_driver("vhost-user-gpio-pci", virtio_gpio_pci_create);
>  qos_node_consumes("vhost-user-gpio-pci", "pci-bus", &edge_opts);
> 
> 
> I haven't verified this but from looking at 

intermittent failures in iotest 108

[Claudio Fontana]

Hello Kevin and all,

I seem to be getting intermittent failures with mainline iotest 108. Is this 
already known?

../configure --enable-tcg --enable-kvm --enable-modules --enable-debug
make -j
make -j check


▶ 614/634 qcow2 108 
   FAIL  
614/634 qemu:block / qemu-iotests qcow2 
   ERROR  155.16s   exit status 1
>>> MALLOC_PERTURB_=33 PYTHON=/usr/bin/python3 /usr/bin/sh 
>>> /home/claudio/git/qemu/build-all/../tests/qemu-iotests/../check-block.sh 
>>> qcow2
――― ✀  
―――
stderr:
--- /home/claudio/git/qemu/tests/qemu-iotests/108.out
+++ /home/claudio/git/qemu/build-all/tests/qemu-iotests/scratch/108.out.bad
@@ -152,40 +152,4 @@

 --- Rebuilding refcount structures on block devices ---

-{ "execute": "qmp_capabilities" }
-{"return": {}}
-{ "execute": "blockdev-create",
-   "arguments": {
-   "job-id": "create",
-   "options": {
-   "driver": "IMGFMT",
-   "file": "file",
-   "size": 67108864,
-   "cluster-size": 512
-   } } }
-{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "created", "id": "create"}}
-{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "running", "id": "create"}}
-{"return": {}}
-{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "waiting", "id": "create"}}
-{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "pending", "id": "create"}}
-{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "concluded", "id": "create"}}
-{ "execute": "job-dismiss", "arguments": { "id": "create" } }
-{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "null", "id": "create"}}
-{"return": {}}
-{ "execute": "quit" }
-{"return": {}}
-{"timestamp": {"seconds":  TIMESTAMP, "microseconds":  TIMESTAMP}, "event": 
"SHUTDOWN", "data": {"guest": false, "reason": "host-qmp-quit"}}
-
-wrote 65536/65536 bytes at offset 0
-64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
-
-ERROR cluster 0 refcount=0 reference=1
-Rebuilding refcount structure
-The following inconsistencies were found and repaired:
-
-0 leaked clusters
-1 corruptions
-
-Double checking the fixed image now...
-No errors were found on the image.
-*** done
+Timeout waiting for capabilities on handle 0

(test program exited with status code 1)
――

615/634 qemu:softfloat+softfloat-conv / fp-test-float-to-float  
   OK  0.18s
616/634 qemu:softfloat+softfloat-conv / fp-test-int-to-float
   OK  0.18s
617/634 qemu:softfloat+softfloat-conv / fp-test-uint-to-float   
   OK  0.17s
618/634 qemu:softfloat+softfloat-conv / fp-test-float-to-int
   OK  0.17s
619/634 qemu:softfloat+softfloat-conv / fp-test-float-to-uint   
   OK  0.16s
620/634 qemu:softfloat+softfloat-conv / fp-test-round-to-integer
   OK  0.15s
621/634 qemu:softfloat+softfloat-compare / fp-test-lt_quiet 
   OK  0.18s
622/634 qemu:softfloat+softfloat-compare / fp-test-le_quiet 
   OK  0.19s
623/634 qemu:softfloat+softfloat-compare / fp-test-eq_signaling 
   OK  0.24s
624/634 qemu:softfloat+softfloat-compare / fp-test-le   
   OK  0.24s
625/634 qemu:qapi-schema+qapi-doc / QAPI rST doc
   OK  0.02s
626/634 qemu:softfloat+softfloat-ops / fp-test-sqrt 
   OK  0.15s
627/634 qemu:softfloat+softfloat-ops / fp-test-log2 
   OK  0.28s
628/634 qemu:qapi-schema+qapi-frontend / QAPI schema regression tests   
   OK  0.33s
629/634 qemu:softfloat+softfloat-ops / fp-test-sub  
   OK  1.90s
630/634 qemu:softfloat+softfloat-ops / fp-test-add  
   OK  2.05s
631/634 qemu:decodetree / decodetree
   OK  2.57s
632/634 qemu:softfloat+softfloat-ops / fp-test-re

[PATCH] hw/acpi: fix breakage due to missing aml stub definitions when acpi is off

[Ani Sinha]

Some HW architectures do not support acpi and CONFIG_ACPI is off for them. For
those architectures, dummy stub function definitions help to resolve symbols.
This change adds couple of dummy stub definitions so that symbols for those can
be resolved and failures such as the following can be fixed for or1k targets.

Configuration:
qemu/build $ ../configure --enable-werror --disable-docs --disable-nettle
 --enable-gcrypt --enable-fdt=system --enable-modules
 --enable-trace-backends=dtrace --enable-docs
 --enable-vfio-user-server
 --target-list="ppc64-softmmu or1k-softmmu s390x-softmmu
   x86_64-softmmu rx-softmmu sh4-softmmu nios2-softmmu"

actual failure:

qemu/build $ QTEST_QEMU_BINARY=./qemu-system-or1k  ./tests/qtest/qos-test
failed to open module:
/build/qemu/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
undefined symbol: aml_return
qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
NULL' failed.
Broken pipe
../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
signal 6 (Aborted) (core dumped)
Aborted (core dumped)

Signed-off-by: Ani Sinha 
---
 hw/acpi/aml-build-stub.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/hw/acpi/aml-build-stub.c b/hw/acpi/aml-build-stub.c
index 8d8ad1a314..89a8fec4af 100644
--- a/hw/acpi/aml-build-stub.c
+++ b/hw/acpi/aml-build-stub.c
@@ -26,6 +26,16 @@ void aml_append(Aml *parent_ctx, Aml *child)
 {
 }
 
+Aml *aml_return(Aml *val)
+{
+return NULL;
+}
+
+Aml *aml_method(const char *name, int arg_count, AmlSerializeFlag sflag)
+{
+return NULL;
+}
+
 Aml *aml_resource_template(void)
 {
 return NULL;
-- 
2.34.1

Re: [PATCH v10 2/9] s390x/cpu topology: reporting the CPU topology to the guest

[Pierre Morel]

On 11/7/22 14:20, Janis Schoetterl-Glausch wrote:

On Fri, 2022-10-28 at 12:00 +0200, Pierre Morel wrote:


On 10/27/22 22:42, Janis Schoetterl-Glausch wrote:

On Wed, 2022-10-12 at 18:21 +0200, Pierre Morel wrote:

The guest can use the STSI instruction to get a buffer filled
with the CPU topology description.

Let us implement the STSI instruction for the basis CPU topology
level, level 2.

Signed-off-by: Pierre Morel 
---
   include/hw/s390x/cpu-topology.h |   3 +
   target/s390x/cpu.h  |  48 ++
   hw/s390x/cpu-topology.c |   8 ++-
   target/s390x/cpu_topology.c | 109 
   target/s390x/kvm/kvm.c  |   6 +-
   target/s390x/meson.build|   1 +
   6 files changed, 172 insertions(+), 3 deletions(-)
   create mode 100644 target/s390x/cpu_topology.c

diff --git a/include/hw/s390x/cpu-topology.h b/include/hw/s390x/cpu-topology.h
index 66c171d0bc..61c11db017 100644
--- a/include/hw/s390x/cpu-topology.h
+++ b/include/hw/s390x/cpu-topology.h
@@ -13,6 +13,8 @@
   #include "hw/qdev-core.h"
   #include "qom/object.h"
   
+#define S390_TOPOLOGY_POLARITY_H  0x00

+
   typedef struct S390TopoContainer {
   int active_count;
   } S390TopoContainer;
@@ -29,6 +31,7 @@ struct S390Topology {
   S390TopoContainer *socket;
   S390TopoTLE *tle;
   MachineState *ms;
+QemuMutex topo_mutex;
   };
   
   #define TYPE_S390_CPU_TOPOLOGY "s390-topology"

diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 7d6d01325b..d604aa9c78 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h


[...]

+
+/* Maxi size of a SYSIB structure is when all CPU are alone in a container */


Max or Maximum.


+#define S390_TOPOLOGY_SYSIB_SIZE (sizeof(SysIB_151x) + 
\
+  S390_MAX_CPUS * (sizeof(SysIBTl_container) + 
\
+   sizeof(SysIBTl_cpu)))


Currently this is 16+248*3*8 == 5968 and will grow with books, drawer support to
16+248*5*8 == 9936 ...

[...]


+
+void insert_stsi_15_1_x(S390CPU *cpu, int sel2, __u64 addr, uint8_t ar)
+{
+uint64_t page[S390_TOPOLOGY_SYSIB_SIZE / sizeof(uint64_t)] = {};


... so calling this page is a bit misleading. Also why not make it a char[]?
And maybe use a union for type punning.


OK, what about:

  union {
  char place_holder[S390_TOPOLOGY_SYSIB_SIZE];
  SysIB_151x sysib;
  } buffer QEMU_ALIGNED(8);


I don't think you need the QEMU_ALIGNED since SysIB_151x already has it. Not 
that it hurts to be
explicit. If you declared the tle member as uint64_t[], you should get the 
correct alignment
automatically and can then drop the explicit one.


I find the explicit statement better. Why make it non explicit?


Btw, [] seems to be preferred over [0], at least there is a commit doing a 
conversion:
f7795e4096 ("misc: Replace zero-length arrays with flexible array member 
(automatic)")


OK






+SysIB_151x *sysib = (SysIB_151x *) page;
+int len;
+
+if (s390_is_pv() || !s390_has_topology() ||
+sel2 < 2 || sel2 > S390_TOPOLOGY_MAX_MNEST) {
+setcc(cpu, 3);
+return;
+}
+
+len = setup_stsi(sysib, sel2);


This should now be memory safe, but might be larger than 4k,
the maximum size of the SYSIB. I guess you want to set cc code 3
in this case and return.


I do not find why the SYSIB can not be larger than 4k.
Can you point me to this restriction?


Says so at the top of the description of STSI:

The SYSIB is 4K bytes and must begin at a 4 K-byte
boundary; otherwise, a specification exception may
be recognized.


Right, I guess I can not read.

So I will return CC=3 in case the length is greater than 4K


thanks,
Regards,

Pierre


--
Pierre Morel
IBM Lab Boeblingen

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Philippe Mathieu-Daudé]

On 7/11/22 14:06, Peter Maydell wrote:

On Mon, 7 Nov 2022 at 13:03, Sunil V L  wrote:


The pflash implementation currently assumes fixed size of the
backend storage. Due to this, the backend storage file needs to be
exactly of size 32M. Otherwise, there will be an error like below.

"device requires 33554432 bytes, block backend provides 4194304 bytes"

Fix this issue by using the actual size of the backing store.

Signed-off-by: Sunil V L 
---


Do you really want the flash device size presented to the guest
to be variable depending on what the user passed as a block backend?
I don't think this is how we handle flash devices on other boards...


Ideally handling smaller/bigger backend size should be transparent for
machine frontend, but we never agreed on what are user expectations and
how to deal with such cases.

Long term I'd go for:

- if flash is read-only

  a/ bigger backend: display a warning and ignore extra backend data.

  b/ smaller backend: assume flash block is in erased state and fill
 missing gap with -1 (the default erase value), displaying a warning
 on startup.

- if flash is read-write

  a/ bigger backend: display a warning and ignore extra backend data.

  b/ smaller backend: add a property to pflash device to handle missing
 gap as erased data. If this flag is not set, display a hint and
 exit with an error.

In Sunil particular case, I suppose the issue comes from commit
334c388f25 ("hw/block/pflash_cfi0{1, 2}: Error out if device length
isn't a power of two") which I'm going to revert because the code
base is not ready for such check:

https://lore.kernel.org/qemu-devel/78b914c5-ce7e-1d4a-0a67-450f286eb...@linaro.org/

Regards,

Phil.

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Sunil V L]

On Mon, Nov 07, 2022 at 01:06:38PM +, Peter Maydell wrote:
> On Mon, 7 Nov 2022 at 13:03, Sunil V L  wrote:
> >
> > The pflash implementation currently assumes fixed size of the
> > backend storage. Due to this, the backend storage file needs to be
> > exactly of size 32M. Otherwise, there will be an error like below.
> >
> > "device requires 33554432 bytes, block backend provides 4194304 bytes"
> >
> > Fix this issue by using the actual size of the backing store.
> >
> > Signed-off-by: Sunil V L 
> > ---
> 
> Do you really want the flash device size presented to the guest
> to be variable depending on what the user passed as a block backend?
> I don't think this is how we handle flash devices on other boards...
> 

Hi Peter,

x86 appears to support variable flash but arm doesn't. What is
the reason for not supporting variable size flash in arm?

Thanks
Sunil

Re: [PULL v2 0/9] loongarch-to-apply queue

[Stefan Hajnoczi]

Applied, thanks.

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


signature.asc
Description: PGP signature

Re: [PULL 0/7] target-arm queue

[Stefan Hajnoczi]

Applied, thanks.

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


signature.asc
Description: PGP signature

Re: [PULL 0/1] VFIO fix for v7.2-rc0

[Stefan Hajnoczi]

Applied, thanks.

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


signature.asc
Description: PGP signature

Re: [PATCH 1/3] arm: move KVM breakpoints helpers

[Alex Bennée]

francesco.cag...@gmail.com writes:

> From: Francesco Cagnin 
>
> These helpers will be also used for HVF. Aside from reformatting a
> couple of comments for 'checkpatch.pl', this is just code motion.
>
> Signed-off-by: Francesco Cagnin 
> ---
>  target/arm/debug_helper.c | 241 +
>  target/arm/internals.h|  50 +++

Moving out of kvm64.c seems fine to me but I wonder if debug_helper.c is
the best location. debug_helpers is currently very focused on just
handling the TCG emulation case where as we are doing this tracking just
for the VMM cases or KVM and now HVF.

We are (slowly) trying to clean up the code in target/arm so we can
support builds like --disable-tcg and to do that we want to avoid too
much ifdef hackery in the individual compilation units.

Peter, what do you think?


>  target/arm/kvm64.c| 276 --
>  3 files changed, 291 insertions(+), 276 deletions(-)


-- 
Alex Bennée

Re: [RFC PATCH] hw/virtio: introduce virtio_device_should_start

[Michael S. Tsirkin]

On Mon, Nov 07, 2022 at 12:14:07PM +, Alex Bennée wrote:
> The previous fix to virtio_device_started revealed a problem in its
> use by both the core and the device code. The core code should be able
> to handle the device "starting" while the VM isn't running to handle
> the restoration of migration state. To solve this duel use introduce a

dual use ;)

> new helper for use by the vhost-user backends who all use it to feed a
> should_start variable.
> 
> We can also pick up a change vhost_user_blk_set_status while we are at
> it which follows the same pattern.
> 
> Fixes: 9f6bcfd99f (hw/virtio: move vm_running check to virtio_device_started)
> Signed-off-by: Alex Bennée 
> Cc: "Michael S. Tsirkin" 

Thanks, gitlab ci seems to have passed this.

I think I'll add 27ba7b027f0f06479091bcfbcd308a6b272563a4 to the Fixes
tag too.

> ---
>  include/hw/virtio/virtio.h   | 18 ++
>  hw/block/vhost-user-blk.c|  6 +-
>  hw/virtio/vhost-user-fs.c|  2 +-
>  hw/virtio/vhost-user-gpio.c  |  2 +-
>  hw/virtio/vhost-user-i2c.c   |  2 +-
>  hw/virtio/vhost-user-rng.c   |  2 +-
>  hw/virtio/vhost-user-vsock.c |  2 +-
>  hw/virtio/vhost-vsock.c  |  2 +-
>  8 files changed, 25 insertions(+), 11 deletions(-)
> 
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index f41b4a7e64..3191c618f3 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -389,6 +389,24 @@ static inline bool virtio_device_started(VirtIODevice 
> *vdev, uint8_t status)
>  return vdev->started;
>  }
>  
> +return status & VIRTIO_CONFIG_S_DRIVER_OK;
> +}
> +
> +/**
> + * virtio_device_should_start() - check if device startable
> + * @vdev - the VirtIO device
> + * @status - the devices status bits
> + *
> + * This is similar to virtio_device_started() but also encapsulates a
> + * check on the VM status which would prevent a device starting
> + * anyway.
> + */
> +static inline bool virtio_device_should_start(VirtIODevice *vdev, uint8_t 
> status)
> +{
> +if (vdev->use_started) {
> +return vdev->started;
> +}
> +
>  if (!vdev->vm_running) {
>  return false;
>  }
> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> index 13bf5cc47a..8feaf12e4e 100644
> --- a/hw/block/vhost-user-blk.c
> +++ b/hw/block/vhost-user-blk.c
> @@ -222,14 +222,10 @@ static void vhost_user_blk_stop(VirtIODevice *vdev)
>  static void vhost_user_blk_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserBlk *s = VHOST_USER_BLK(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_should_start(vdev, status);
>  Error *local_err = NULL;
>  int ret;
>  
> -if (!vdev->vm_running) {
> -should_start = false;
> -}
> -
>  if (!s->connected) {
>  return;
>  }
> diff --git a/hw/virtio/vhost-user-fs.c b/hw/virtio/vhost-user-fs.c
> index ad0f91c607..1c40f42045 100644
> --- a/hw/virtio/vhost-user-fs.c
> +++ b/hw/virtio/vhost-user-fs.c
> @@ -123,7 +123,7 @@ static void vuf_stop(VirtIODevice *vdev)
>  static void vuf_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserFS *fs = VHOST_USER_FS(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_should_start(vdev, status);
>  
>  if (vhost_dev_is_started(&fs->vhost_dev) == should_start) {
>  return;
> diff --git a/hw/virtio/vhost-user-gpio.c b/hw/virtio/vhost-user-gpio.c
> index 8b40fe450c..677d1c7730 100644
> --- a/hw/virtio/vhost-user-gpio.c
> +++ b/hw/virtio/vhost-user-gpio.c
> @@ -152,7 +152,7 @@ static void vu_gpio_stop(VirtIODevice *vdev)
>  static void vu_gpio_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserGPIO *gpio = VHOST_USER_GPIO(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_should_start(vdev, status);
>  
>  trace_virtio_gpio_set_status(status);
>  
> diff --git a/hw/virtio/vhost-user-i2c.c b/hw/virtio/vhost-user-i2c.c
> index bc58b6c0d1..864eba695e 100644
> --- a/hw/virtio/vhost-user-i2c.c
> +++ b/hw/virtio/vhost-user-i2c.c
> @@ -93,7 +93,7 @@ static void vu_i2c_stop(VirtIODevice *vdev)
>  static void vu_i2c_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserI2C *i2c = VHOST_USER_I2C(vdev);
> -bool should_start = virtio_device_started(vdev, status);
> +bool should_start = virtio_device_should_start(vdev, status);
>  
>  if (vhost_dev_is_started(&i2c->vhost_dev) == should_start) {
>  return;
> diff --git a/hw/virtio/vhost-user-rng.c b/hw/virtio/vhost-user-rng.c
> index bc1f36c5ac..8b47287875 100644
> --- a/hw/virtio/vhost-user-rng.c
> +++ b/hw/virtio/vhost-user-rng.c
> @@ -90,7 +90,7 @@ static void vu_rng_stop(VirtIODevice *vdev)
>  static void vu_rng_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserRNG *rng = VHOST_USER_RNG(vdev);
> -bool should_start 

Re: [PATCH 1/3] arm: move KVM breakpoints helpers

[Philippe Mathieu-Daudé]

On 7/11/22 15:15, Alex Bennée wrote:


francesco.cag...@gmail.com writes:


From: Francesco Cagnin 

These helpers will be also used for HVF. Aside from reformatting a
couple of comments for 'checkpatch.pl', this is just code motion.

Signed-off-by: Francesco Cagnin 
---
  target/arm/debug_helper.c | 241 +
  target/arm/internals.h|  50 +++


Moving out of kvm64.c seems fine to me but I wonder if debug_helper.c is
the best location. debug_helpers is currently very focused on just
handling the TCG emulation case where as we are doing this tracking just
for the VMM cases or KVM and now HVF.

We are (slowly) trying to clean up the code in target/arm so we can
support builds like --disable-tcg and to do that we want to avoid too
much ifdef hackery in the individual compilation units.



I was planning to move hypervisor-specific code to 
target/arm/$hypervisor/, but here Francesco wants to re-use the same code

between 2 hypervisors... Maybe move it to target/arm/hyp_gdbstub.c
and let meson add it conditionally?


  target/arm/kvm64.c| 276 --
  3 files changed, 291 insertions(+), 276 deletions(-)

[PATCH] tcg/loongarch64: Optimize immediate loading

[Rui Wang]

diff:
  Imm Before  After
  addi.w  rd, zero, 0 ori rd, zero, 0
  lu52i.d rd, zero, 0
  f800lu12i.w rd, -1  addi.w  rd, zero, -2048
  ori rd, rd, 2048lu32i.d rd, 0
  lu32i.d rd, 0
  ...

Signed-off-by: Rui Wang 
---
 tcg/loongarch64/tcg-target.c.inc | 35 +++-
 1 file changed, 12 insertions(+), 23 deletions(-)

diff --git a/tcg/loongarch64/tcg-target.c.inc b/tcg/loongarch64/tcg-target.c.inc
index d326e28740..7755c4ffd0 100644
--- a/tcg/loongarch64/tcg-target.c.inc
+++ b/tcg/loongarch64/tcg-target.c.inc
@@ -274,16 +274,6 @@ static bool tcg_out_mov(TCGContext *s, TCGType type, 
TCGReg ret, TCGReg arg)
 return true;
 }
 
-static bool imm_part_needs_loading(bool high_bits_are_ones,
-   tcg_target_long part)
-{
-if (high_bits_are_ones) {
-return part != -1;
-} else {
-return part != 0;
-}
-}
-
 /* Loads a 32-bit immediate into rd, sign-extended.  */
 static void tcg_out_movi_i32(TCGContext *s, TCGReg rd, int32_t val)
 {
@@ -291,16 +281,16 @@ static void tcg_out_movi_i32(TCGContext *s, TCGReg rd, 
int32_t val)
 tcg_target_long hi12 = sextreg(val, 12, 20);
 
 /* Single-instruction cases.  */
-if (lo == val) {
-/* val fits in simm12: addi.w rd, zero, val */
-tcg_out_opc_addi_w(s, rd, TCG_REG_ZERO, val);
-return;
-}
-if (0x800 <= val && val <= 0xfff) {
+if (hi12 == 0) {
 /* val fits in uimm12: ori rd, zero, val */
 tcg_out_opc_ori(s, rd, TCG_REG_ZERO, val);
 return;
 }
+if (hi12 == sextreg(lo, 12, 20)) {
+/* val fits in simm12: addi.w rd, zero, val */
+tcg_out_opc_addi_w(s, rd, TCG_REG_ZERO, val);
+return;
+}
 
 /* High bits must be set; load with lu12i.w + optional ori.  */
 tcg_out_opc_lu12i_w(s, rd, hi12);
@@ -334,8 +324,7 @@ static void tcg_out_movi(TCGContext *s, TCGType type, 
TCGReg rd,
 
 intptr_t pc_offset;
 tcg_target_long val_lo, val_hi, pc_hi, offset_hi;
-tcg_target_long hi32, hi52;
-bool rd_high_bits_are_ones;
+tcg_target_long hi12, hi32, hi52;
 
 /* Value fits in signed i32.  */
 if (type == TCG_TYPE_I32 || val == (int32_t)val) {
@@ -366,25 +355,25 @@ static void tcg_out_movi(TCGContext *s, TCGType type, 
TCGReg rd,
 return;
 }
 
+hi12 = sextreg(val, 12, 20);
 hi32 = sextreg(val, 32, 20);
 hi52 = sextreg(val, 52, 12);
 
 /* Single cu52i.d case.  */
-if (ctz64(val) >= 52) {
+if ((hi52 != 0) && (ctz64(val) >= 52)) {
 tcg_out_opc_cu52i_d(s, rd, TCG_REG_ZERO, hi52);
 return;
 }
 
 /* Slow path.  Initialize the low 32 bits, then concat high bits.  */
 tcg_out_movi_i32(s, rd, val);
-rd_high_bits_are_ones = (int32_t)val < 0;
 
-if (imm_part_needs_loading(rd_high_bits_are_ones, hi32)) {
+/* Load hi32 and hi52 explicitly when they are unexpected values. */
+if (hi32 != sextreg(hi12, 20, 20)) {
 tcg_out_opc_cu32i_d(s, rd, hi32);
-rd_high_bits_are_ones = hi32 < 0;
 }
 
-if (imm_part_needs_loading(rd_high_bits_are_ones, hi52)) {
+if (hi52 != sextreg(hi32, 20, 12)) {
 tcg_out_opc_cu52i_d(s, rd, rd, hi52);
 }
 }
-- 
2.38.1

[RFC PATCH] tests/docker: allow user to override check target

[Alex Bennée]

This is useful when trying to bisect a particular failing test behind
a docker run. For example:

  make docker-test-clang@fedora \
TARGET_LIST=arm-softmmu \
CHECK_TARGET="meson test qtest-arm/qos-test" \
J=9 V=1

Signed-off-by: Alex Bennée 
---
 tests/docker/Makefile.include | 2 ++
 tests/docker/common.rc| 6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index c87f14477a..ece0aa77df 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -184,6 +184,7 @@ docker:
@echo 'TARGET_LIST=a,b,cOverride target list in builds.'
@echo 'EXTRA_CONFIGURE_OPTS="..."'
@echo ' Extra configure options.'
+   @echo 'CHECK_TARGET="..."   Override the default `make check` 
target '
@echo 'IMAGES="a b c ..":   Restrict available images to subset.'
@echo 'TESTS="x y z .." Restrict available tests to subset.'
@echo 'J=[0..9]*Overrides the -jN parameter for make 
commands'
@@ -230,6 +231,7 @@ docker-run: docker-qemu-src
$(if $(NETWORK),$(if $(subst 
$(NETWORK),,1),--net=$(NETWORK)),--net=none) \
-e TARGET_LIST=$(subst 
$(SPACE),$(COMMA),$(TARGET_LIST))\
-e EXTRA_CONFIGURE_OPTS="$(EXTRA_CONFIGURE_OPTS)" \
+   -e CHECK_TARGET="$(CHECK_TARGET)"   \
-e V=$V -e J=$J -e DEBUG=$(DEBUG)   \
-e SHOW_ENV=$(SHOW_ENV) \
$(if $(NOUSER),,\
diff --git a/tests/docker/common.rc b/tests/docker/common.rc
index e6f8cee0d6..f2769c1ff6 100755
--- a/tests/docker/common.rc
+++ b/tests/docker/common.rc
@@ -63,12 +63,12 @@ check_qemu()
 {
 # default to make check unless the caller specifies
 if [ $# = 0 ]; then
-INVOCATION="check"
+INVOCATION="${CHECK_TARGET:-make $MAKEFLAGS check}"
 else
-INVOCATION="$@"
+INVOCATION="make $MAKEFLAGS $@"
 fi
 
-make $MAKEFLAGS $INVOCATION
+$INVOCATION
 }
 
 test_fail()
-- 
2.34.1

Re: [RFC PATCH] hw/virtio: introduce virtio_device_should_start

[Alex Bennée]

"Michael S. Tsirkin"  writes:

> On Mon, Nov 07, 2022 at 12:14:07PM +, Alex Bennée wrote:
>> The previous fix to virtio_device_started revealed a problem in its
>> use by both the core and the device code. The core code should be able
>> to handle the device "starting" while the VM isn't running to handle
>> the restoration of migration state. To solve this duel use introduce a
>> new helper for use by the vhost-user backends who all use it to feed a
>> should_start variable.
>> 
>> We can also pick up a change vhost_user_blk_set_status while we are at
>> it which follows the same pattern.
>> 
>> Fixes: 9f6bcfd99f (hw/virtio: move vm_running check to virtio_device_started)
>> Signed-off-by: Alex Bennée 
>> Cc: "Michael S. Tsirkin" 
>
> Hi Alex, did you actually check this under gitlab CI?

It's had a clean pass as part of my for-7.2/misc-fixes branch but I've
been unable to replicate the crash it was meant to fix locally as of
yet.

  https://gitlab.com/stsquad/qemu/-/pipelines/687366712

-- 
Alex Bennée

[PATCH] checkpatch: better pattern for inline comments

[Michael S. Tsirkin]

checkpatch is unhappy about this line:

WARNING: Block comments use a leading /* on a separate line
#50: FILE: hw/acpi/nvdimm.c:1074:
+   aml_equal(aml_sizeof(pckg), aml_int(1)) /* 1 element? 
*/));

but there's nothing wrong with it - the check is just too simplistic. It
will also miss lines which mix inline and block comments.

Instead, let's strip all inline comments from a line and then check for block
comments.

Signed-off-by: Michael S. Tsirkin 
---
 scripts/checkpatch.pl | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3e3b43076..be37c9e0bf 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1681,10 +1681,15 @@ sub process {
 # Block comment styles
 
# Block comments use /* on a line of its own
-   if ($rawline !~ m@^\+.*/\*.*\*/[ \t)}]*$@ &&#inline /*...*/
-   $rawline =~ m@^\+.*/\*\*?+[ \t]*[^ \t]@) { # /* or /** 
non-blank
-   WARN("Block comments use a leading /* on a separate 
line\n" . $herecurr);
-   }
+   {
+# remove inline #inline /*...*/
+my $commentline = $rawline;
+while ($commentline =~ s@^(\+.*)/\*.*\*/@$1@o) {
+}
+if ($commentline =~ m@^\+.*/\*\*?+[ \t]*[^ \t]@) { # /* or 
/** non-blank
+WARN("Block comments use a leading /* on a 
separate line\n" . $herecurr);
+}
+}
 
 # Block comments use * on subsequent lines
if ($prevline =~ /$;[ \t]*$/ && #ends in comment
-- 
MST

[PATCH v2 1/3] block: Make bdrv_child_get_parent_aio_context I/O

[Hanna Reitz]

We want to use bdrv_child_get_parent_aio_context() from
bdrv_parent_drained_{begin,end}_single(), both of which are "I/O or GS"
functions.

Prior to 3ed4f708fe1, all the implementations were I/O code anyway.
3ed4f708fe1 has put block jobs' AioContext field under the job mutex, so
to make child_job_get_parent_aio_context() work in an I/O context, we
need to take that lock there.

Furthermore, blk_root_get_parent_aio_context() is not marked as
anything, but is safe to run in an I/O context, so mark it that way now.
(blk_get_aio_context() is an I/O code function.)

With that done, all implementations explicitly are I/O code, so we can
mark bdrv_child_get_parent_aio_context() as I/O code, too, so callers
know it is safe to run from both GS and I/O contexts.

Signed-off-by: Hanna Reitz 
---
 include/block/block-global-state.h | 1 -
 include/block/block-io.h   | 2 ++
 include/block/block_int-common.h   | 4 ++--
 block.c| 2 +-
 block/block-backend.c  | 1 +
 blockjob.c | 3 ++-
 6 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/block/block-global-state.h 
b/include/block/block-global-state.h
index bb42ed9559..c7bd4a2088 100644
--- a/include/block/block-global-state.h
+++ b/include/block/block-global-state.h
@@ -220,7 +220,6 @@ void coroutine_fn bdrv_co_lock(BlockDriverState *bs);
  */
 void coroutine_fn bdrv_co_unlock(BlockDriverState *bs);
 
-AioContext *bdrv_child_get_parent_aio_context(BdrvChild *c);
 bool bdrv_child_change_aio_context(BdrvChild *c, AioContext *ctx,
GHashTable *visited, Transaction *tran,
Error **errp);
diff --git a/include/block/block-io.h b/include/block/block-io.h
index 770ddeb7c8..b099d7db45 100644
--- a/include/block/block-io.h
+++ b/include/block/block-io.h
@@ -171,6 +171,8 @@ void bdrv_debug_event(BlockDriverState *bs, BlkdebugEvent 
event);
  */
 AioContext *bdrv_get_aio_context(BlockDriverState *bs);
 
+AioContext *bdrv_child_get_parent_aio_context(BdrvChild *c);
+
 /**
  * Move the current coroutine to the AioContext of @bs and return the old
  * AioContext of the coroutine. Increase bs->in_flight so that draining @bs
diff --git a/include/block/block_int-common.h b/include/block/block_int-common.h
index 5a2cc077a0..31ae91e56e 100644
--- a/include/block/block_int-common.h
+++ b/include/block/block_int-common.h
@@ -911,8 +911,6 @@ struct BdrvChildClass {
GHashTable *visited, Transaction *tran,
Error **errp);
 
-AioContext *(*get_parent_aio_context)(BdrvChild *child);
-
 /*
  * I/O API functions. These functions are thread-safe.
  *
@@ -929,6 +927,8 @@ struct BdrvChildClass {
  */
 const char *(*get_name)(BdrvChild *child);
 
+AioContext *(*get_parent_aio_context)(BdrvChild *child);
+
 /*
  * If this pair of functions is implemented, the parent doesn't issue new
  * requests after returning from .drained_begin() until .drained_end() is
diff --git a/block.c b/block.c
index 3bd594eb2a..2d6128d80a 100644
--- a/block.c
+++ b/block.c
@@ -1533,7 +1533,7 @@ const BdrvChildClass child_of_bds = {
 
 AioContext *bdrv_child_get_parent_aio_context(BdrvChild *c)
 {
-GLOBAL_STATE_CODE();
+IO_CODE();
 return c->klass->get_parent_aio_context(c);
 }
 
diff --git a/block/block-backend.c b/block/block-backend.c
index c0c7d56c8d..ed2f4b67a2 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -311,6 +311,7 @@ static void blk_root_detach(BdrvChild *child)
 static AioContext *blk_root_get_parent_aio_context(BdrvChild *c)
 {
 BlockBackend *blk = c->opaque;
+IO_CODE();
 
 return blk_get_aio_context(blk);
 }
diff --git a/blockjob.c b/blockjob.c
index 2d86014fa5..f51d4e18f3 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -173,7 +173,8 @@ static bool child_job_change_aio_ctx(BdrvChild *c, 
AioContext *ctx,
 static AioContext *child_job_get_parent_aio_context(BdrvChild *c)
 {
 BlockJob *job = c->opaque;
-GLOBAL_STATE_CODE();
+IO_CODE();
+JOB_LOCK_GUARD();
 
 return job->job.aio_context;
 }
-- 
2.36.1

[PATCH v2 2/3] block-backend: Update ctx immediately after root

[Hanna Reitz]

blk_get_aio_context() asserts that blk->ctx is always equal to the root
BDS's context (if there is a root BDS).  Therefore,
blk_do_set_aio_context() must update blk->ctx immediately after the root
BDS's context has changed.

Without this patch, the next patch would break iotest 238, because
bdrv_drained_begin() (called by blk_do_set_aio_context()) may then
invoke bdrv_child_get_parent_aio_context() on the root child, i.e.
blk_get_aio_context().  However, by this point, blk->ctx would not have
been updated and thus differ from the root node's context.  This patch
fixes that.

Reviewed-by: Kevin Wolf 
Signed-off-by: Hanna Reitz 
---
 block/block-backend.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/block/block-backend.c b/block/block-backend.c
index ed2f4b67a2..b48c91f4e1 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -2158,6 +2158,11 @@ static int blk_do_set_aio_context(BlockBackend *blk, 
AioContext *new_context,
 return ret;
 }
 }
+/*
+ * Make blk->ctx consistent with the root node before we invoke any
+ * other operations like drain that might inquire blk->ctx
+ */
+blk->ctx = new_context;
 if (tgm->throttle_state) {
 bdrv_drained_begin(bs);
 throttle_group_detach_aio_context(tgm);
@@ -2166,9 +2171,10 @@ static int blk_do_set_aio_context(BlockBackend *blk, 
AioContext *new_context,
 }
 
 bdrv_unref(bs);
+} else {
+blk->ctx = new_context;
 }
 
-blk->ctx = new_context;
 return 0;
 }
 
-- 
2.36.1

[PATCH v2 0/3] block: Start/end drain on correct AioContext

[Hanna Reitz]

Hi,

v1 cover letter:
https://lists.nongnu.org/archive/html/qemu-block/2022-09/msg00389.html

bdrv_replace_child_noperm() drains the child via
bdrv_parent_drained_{begin,end}_single().  When it removes a child, the
bdrv_parent_drained_end_single() at its end will be called on an empty
child, making the BDRV_POLL_WHILE() in it poll the main AioContext
(because c->bs is NULL).

That’s wrong, though, because it’s supposed to operate on the parent.
bdrv_parent_drained_end_single_no_poll() will have scheduled any BHs in
the parents’ AioContext, which may be anything, not necessarily the main
context.  Therefore, we must poll the parent’s context.

Patch 3 does this for both bdrv_parent_drained_{begin,end}_single().
Patch 1 ensures that we can legally call
bdrv_child_get_parent_aio_context() from those I/O context functions,
and patch 2 fixes blk_do_set_aio_context() to not cause an assertion
failure if it beginning a drain can end up in blk_get_aio_context()
before blk->ctx has been updated.


v2:
- Patch 1:
  - Move bdrv_child_get_parent_aio_context() from block-global-state.h
to block-io.h
  - Move BdrvChildClass.get_parent_aio_context into the I/O code section
  - Mark blk_root_get_parent_aio_context() as I/O code
  - Mark child_job_get_parent_aio_context(), and lock the job mutex,
which we now need to do (as of 3ed4f708fe1)
- Patch 2:
  - Added comment similar to Kevin’s suggestion
(Still decided to take Kevin’s R-b, even though I didn’t use the
literal suggestion, but made it a bit more verbose)


Hanna Reitz (3):
  block: Make bdrv_child_get_parent_aio_context I/O
  block-backend: Update ctx immediately after root
  block: Start/end drain on correct AioContext

 include/block/block-global-state.h | 1 -
 include/block/block-io.h   | 2 ++
 include/block/block_int-common.h   | 4 ++--
 block.c| 2 +-
 block/block-backend.c  | 9 -
 block/io.c | 6 --
 blockjob.c | 3 ++-
 7 files changed, 19 insertions(+), 8 deletions(-)

-- 
2.36.1

[PATCH v2 3/3] block: Start/end drain on correct AioContext

[Hanna Reitz]

bdrv_parent_drained_{begin,end}_single() are supposed to operate on the
parent, not on the child, so they should not attempt to get the context
to poll from the child but the parent instead.  BDRV_POLL_WHILE(c->bs)
does get the context from the child, so we should replace it with
AIO_WAIT_WHILE() on the parent's context instead.

This problem becomes apparent when bdrv_replace_child_noperm() invokes
bdrv_parent_drained_end_single() after removing a child from a subgraph
that is in an I/O thread.  By the time bdrv_parent_drained_end_single()
is called, child->bs is NULL, and so BDRV_POLL_WHILE(c->bs, ...) will
poll the main loop instead of the I/O thread; but anything that
bdrv_parent_drained_end_single_no_poll() may have scheduled is going to
want to run in the I/O thread, but because we poll the main loop, the
I/O thread is never unpaused, and nothing is run, resulting in a
deadlock.

Closes: https://gitlab.com/qemu-project/qemu/-/issues/1215
Reviewed-by: Kevin Wolf 
Signed-off-by: Hanna Reitz 
---
 block/io.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/block/io.c b/block/io.c
index 34b30e304e..b9424024f9 100644
--- a/block/io.c
+++ b/block/io.c
@@ -71,9 +71,10 @@ static void bdrv_parent_drained_end_single_no_poll(BdrvChild 
*c,
 void bdrv_parent_drained_end_single(BdrvChild *c)
 {
 int drained_end_counter = 0;
+AioContext *ctx = bdrv_child_get_parent_aio_context(c);
 IO_OR_GS_CODE();
 bdrv_parent_drained_end_single_no_poll(c, &drained_end_counter);
-BDRV_POLL_WHILE(c->bs, qatomic_read(&drained_end_counter) > 0);
+AIO_WAIT_WHILE(ctx, qatomic_read(&drained_end_counter) > 0);
 }
 
 static void bdrv_parent_drained_end(BlockDriverState *bs, BdrvChild *ignore,
@@ -116,13 +117,14 @@ static bool bdrv_parent_drained_poll(BlockDriverState 
*bs, BdrvChild *ignore,
 
 void bdrv_parent_drained_begin_single(BdrvChild *c, bool poll)
 {
+AioContext *ctx = bdrv_child_get_parent_aio_context(c);
 IO_OR_GS_CODE();
 c->parent_quiesce_counter++;
 if (c->klass->drained_begin) {
 c->klass->drained_begin(c);
 }
 if (poll) {
-BDRV_POLL_WHILE(c->bs, bdrv_parent_drained_poll_single(c));
+AIO_WAIT_WHILE(ctx, bdrv_parent_drained_poll_single(c));
 }
 }
 
-- 
2.36.1

[PATCH v2] hw/acpi: fix breakage due to missing aml stub definitions when acpi is off

[Ani Sinha]

Some HW architectures do not support acpi and CONFIG_ACPI is off for them. For
those architectures, dummy stub function definitions help to resolve symbols.
This change adds couple of dummy stub definitions so that symbols for those can
be resolved and failures such as the following can be fixed for or1k targets.

Configuration:
qemu/build $ ../configure --enable-werror --disable-docs --disable-nettle \
 --enable-gcrypt --enable-fdt=system --enable-modules \
 --enable-trace-backends=dtrace --enable-docs \
 --enable-vfio-user-server \
 --target-list="ppc64-softmmu or1k-softmmu s390x-softmmu 
x86_64-softmmu
 rx-softmmu sh4-softmmu nios2-softmmu"

actual failure:

qemu/build $ QTEST_QEMU_BINARY=./qemu-system-or1k  ./tests/qtest/qos-test

failed to open module:
/build/qemu/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
undefined symbol: aml_return
qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
NULL' failed.
Broken pipe
../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
signal 6 (Aborted) (core dumped)
Aborted (core dumped)

CC: Bernhard Beschow 
Signed-off-by: Ani Sinha 
---
 hw/acpi/aml-build-stub.c | 10 ++
 1 file changed, 10 insertions(+)

changelog:
v2: cosmetic commit description format update.

diff --git a/hw/acpi/aml-build-stub.c b/hw/acpi/aml-build-stub.c
index 8d8ad1a314..89a8fec4af 100644
--- a/hw/acpi/aml-build-stub.c
+++ b/hw/acpi/aml-build-stub.c
@@ -26,6 +26,16 @@ void aml_append(Aml *parent_ctx, Aml *child)
 {
 }
 
+Aml *aml_return(Aml *val)
+{
+return NULL;
+}
+
+Aml *aml_method(const char *name, int arg_count, AmlSerializeFlag sflag)
+{
+return NULL;
+}
+
 Aml *aml_resource_template(void)
 {
 return NULL;
-- 
2.34.1

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Alex Bennée]

Sunil V L  writes:

> On Mon, Nov 07, 2022 at 01:06:38PM +, Peter Maydell wrote:
>> On Mon, 7 Nov 2022 at 13:03, Sunil V L  wrote:
>> >
>> > The pflash implementation currently assumes fixed size of the
>> > backend storage. Due to this, the backend storage file needs to be
>> > exactly of size 32M. Otherwise, there will be an error like below.
>> >
>> > "device requires 33554432 bytes, block backend provides 4194304 bytes"
>> >
>> > Fix this issue by using the actual size of the backing store.
>> >
>> > Signed-off-by: Sunil V L 
>> > ---
>> 
>> Do you really want the flash device size presented to the guest
>> to be variable depending on what the user passed as a block backend?
>> I don't think this is how we handle flash devices on other boards...
>> 
>
> Hi Peter,
>
> x86 appears to support variable flash but arm doesn't. What is
> the reason for not supporting variable size flash in arm?

If I recall from the last time we went around this is was the question
of what you should pad it with.

  
https://patchew.org/QEMU/20190307093723.655-1-arm...@redhat.com/20190307093723.655-3-arm...@redhat.com/

>
> Thanks
> Sunil


-- 
Alex Bennée

Re: [PATCH v1 1/4] target/riscv: Add itrigger support when icount is not enabled

[Alex Bennée]

LIU Zhiwei  writes:

> On 2022/11/7 9:37, Alistair Francis wrote:
>> On Thu, Oct 13, 2022 at 4:32 PM LIU Zhiwei  
>> wrote:
>>> When icount is not enabled, there is no API in QEMU that can get the
>>> guest instruction number.
>>>
>>> Translate the guest code in a way that each TB only has one instruction.
>> I don't think this is a great idea.
>>
>> Why can't we just require icount be enabled if a user wants this? Or 
>> singlestep?
>
> This feature will only be used by users who want to  run the native
> gdb on Linux. If we run QEMU as a service,  after booting the kernel,
> we can't predicate whether the users will use native gdb.
>
> Besides, icount can't be enabled on MTTCG currently (I am working on
> this problem)

I'm curious as to what your approach is going to be to solve this one?

-- 
Alex Bennée

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Markus Armbruster]

Philippe Mathieu-Daudé  writes:

> On 7/11/22 14:06, Peter Maydell wrote:
>> On Mon, 7 Nov 2022 at 13:03, Sunil V L  wrote:
>>>
>>> The pflash implementation currently assumes fixed size of the
>>> backend storage.

Intentional.

commit 06f1521795207359a395996c253c306f4ab7586e
Author: Markus Armbruster 
Date:   Tue Mar 19 17:35:50 2019 +0100

pflash: Require backend size to match device, improve errors

We reject undersized backends with a rather enigmatic "failed to read
the initial flash content" error.  For instance:

$ qemu-system-ppc64 -S -display none -M sam460ex -drive 
if=pflash,format=raw,file=eins.img
qemu-system-ppc64: Initialization of device cfi.pflash02 failed: failed 
to read the initial flash content

We happily accept oversized images, ignoring their tail.  Throwing
away parts of firmware that way is pretty much certain to end in an
even more enigmatic failure to boot.

Require the backend's size to match the device's size exactly.  Report
mismatch like this:

qemu-system-ppc64: Initialization of device cfi.pflash01 failed: device 
requires 1048576 bytes, block backend provides 512 bytes

Improve the error for actual read failures to "can't read block
backend".

To avoid duplicating even more code between the two pflash device
models, do all that in new helper blk_check_size_and_read_all().

The error reporting can still be confusing.  For instance:

qemu-system-ppc64 -S -display none -M taihu -drive 
if=pflash,format=raw,file=eins.img  -drive 
if=pflash,unit=1,format=raw,file=zwei.img
qemu-system-ppc64: Initialization of device cfi.pflash02 failed: device 
requires 2097152 bytes, block backend provides 512 bytes

Leaves the user guessing which of the two -drive is wrong.  Mention
the issue in a TODO comment.

Suggested-by: Alex Bennée 
Signed-off-by: Markus Armbruster 
Message-Id: <20190319163551.32499-2-arm...@redhat.com>
Reviewed-by: Laszlo Ersek 
Reviewed-by: Alex Bennée 
Reviewed-by: Philippe Mathieu-Daudé 

>>>  Due to this, the backend storage file needs to be
>>> exactly of size 32M. Otherwise, there will be an error like below.
>>>
>>> "device requires 33554432 bytes, block backend provides 4194304 bytes"

Why is that a problem?  Genuine question!

>>> Fix this issue by using the actual size of the backing store.
>>>
>>> Signed-off-by: Sunil V L 
>>> ---
>> Do you really want the flash device size presented to the guest
>> to be variable depending on what the user passed as a block backend?
>> I don't think this is how we handle flash devices on other boards...

Flash device is generally a property of the machine type.  Similar to
physical machines.  Not an accident.

> Ideally handling smaller/bigger backend size should be transparent for
> machine frontend, but we never agreed on what are user expectations and
> how to deal with such cases.
>
> Long term I'd go for:
>
> - if flash is read-only
>
>   a/ bigger backend: display a warning and ignore extra backend data.

Truncating images seems unlikely to be useful.

>   b/ smaller backend: assume flash block is in erased state and fill
>  missing gap with -1 (the default erase value), displaying a warning
>  on startup.

Padding has a better chance to work.  But is it worth the trouble?

>
> - if flash is read-write
>
>   a/ bigger backend: display a warning and ignore extra backend data.
>
>   b/ smaller backend: add a property to pflash device to handle missing
>  gap as erased data. If this flag is not set, display a hint and
>  exit with an error.

What happens when the guest writes to the part that isn't backed by the
backend?

Is this worth the trouble?

> In Sunil particular case, I suppose the issue comes from commit
> 334c388f25 ("hw/block/pflash_cfi0{1, 2}: Error out if device length
> isn't a power of two") which I'm going to revert because the code
> base is not ready for such check:
>
> https://lore.kernel.org/qemu-devel/78b914c5-ce7e-1d4a-0a67-450f286eb...@linaro.org/
>
> Regards,
>
> Phil.

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Peter Maydell]

On Mon, 7 Nov 2022 at 14:08, Sunil V L  wrote:
>
> On Mon, Nov 07, 2022 at 01:06:38PM +, Peter Maydell wrote:
> > On Mon, 7 Nov 2022 at 13:03, Sunil V L  wrote:
> > >
> > > The pflash implementation currently assumes fixed size of the
> > > backend storage. Due to this, the backend storage file needs to be
> > > exactly of size 32M. Otherwise, there will be an error like below.
> > >
> > > "device requires 33554432 bytes, block backend provides 4194304 bytes"
> > >
> > > Fix this issue by using the actual size of the backing store.
> > >
> > > Signed-off-by: Sunil V L 
> > > ---
> >
> > Do you really want the flash device size presented to the guest
> > to be variable depending on what the user passed as a block backend?
> > I don't think this is how we handle flash devices on other boards...
> >

> x86 appears to support variable flash but arm doesn't. What is
> the reason for not supporting variable size flash in arm?

Mostly, that that's the straightforward thing to code.
Partly, that it avoids weird cases (eg you can have a backing
file that's an odd number of bytes but you can't have a
flash that size).

If x86 has a standard way of handling this then I'm all
in favour of being consistent across platforms. What's
the x86 board doing there?

thanks
-- PMM

[PATCH for 7.2 0/2] s390x/s390-virtio-ccw:

[Cédric Le Goater]

From: Cédric Le Goater 

Hello,

This series removes the redundant "zpcii-disable" machine property and
and introduces a GlobalProperty compat array to maintain the same
behaviour on older machines.

Thanks,

C.

Cédric Le Goater (2):
  Revert "s390x/s390-virtio-ccw: add zpcii-disable machine property"
  s390x/s390-virtio-ccw: Switch off zPCI enhancements on older machines

 include/hw/s390x/s390-virtio-ccw.h |  1 -
 hw/s390x/s390-pci-kvm.c|  4 +---
 hw/s390x/s390-virtio-ccw.c | 29 +
 util/qemu-config.c |  4 
 qemu-options.hx|  8 +---
 5 files changed, 7 insertions(+), 39 deletions(-)

-- 
2.38.1

[PATCH for 7.2 2/2] s390x/s390-virtio-ccw: Switch off zPCI enhancements on older machines

[Cédric Le Goater]

From: Cédric Le Goater 

zPCI enhancement features (interpretation and forward assist) were
recently introduced to improve performance on PCI passthrough devices.
To maintain the same behaviour on older Z machines, deactivate the
features with the associated properties.

Signed-off-by: Cédric Le Goater 
---
 hw/s390x/s390-virtio-ccw.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index bb98d40792..7d80bc1837 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -844,9 +844,14 @@ static void ccw_machine_7_1_instance_options(MachineState 
*machine)
 static void ccw_machine_7_1_class_options(MachineClass *mc)
 {
 S390CcwMachineClass *s390mc = S390_CCW_MACHINE_CLASS(mc);
+static GlobalProperty compat[] = {
+{ TYPE_S390_PCI_DEVICE, "interpret", "off", },
+{ TYPE_S390_PCI_DEVICE, "forwarding-assist", "off", },
+};
 
 ccw_machine_7_2_class_options(mc);
 compat_props_add(mc->compat_props, hw_compat_7_1, hw_compat_7_1_len);
+compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
 s390mc->max_threads = S390_MAX_CPUS;
 }
 DEFINE_CCW_MACHINE(7_1, "7.1", false);
-- 
2.38.1

[PATCH for 7.2 1/2] Revert "s390x/s390-virtio-ccw: add zpcii-disable machine property"

[Cédric Le Goater]

From: Cédric Le Goater 

This reverts commit 59d1ce44396e3ad2330dc3261ff3da7ad3a16184.

The "zpcii-disable" machine property is redundant with the "interpret"
zPCI device property. Remove it for clarification.

Signed-off-by: Cédric Le Goater 
---
 include/hw/s390x/s390-virtio-ccw.h |  1 -
 hw/s390x/s390-pci-kvm.c|  4 +---
 hw/s390x/s390-virtio-ccw.c | 24 
 util/qemu-config.c |  4 
 qemu-options.hx|  8 +---
 5 files changed, 2 insertions(+), 39 deletions(-)

diff --git a/include/hw/s390x/s390-virtio-ccw.h 
b/include/hw/s390x/s390-virtio-ccw.h
index 4f8a39abda..9bba21a916 100644
--- a/include/hw/s390x/s390-virtio-ccw.h
+++ b/include/hw/s390x/s390-virtio-ccw.h
@@ -27,7 +27,6 @@ struct S390CcwMachineState {
 bool aes_key_wrap;
 bool dea_key_wrap;
 bool pv;
-bool zpcii_disable;
 uint8_t loadparm[8];
 };
 
diff --git a/hw/s390x/s390-pci-kvm.c b/hw/s390x/s390-pci-kvm.c
index 5eb7fd12e2..9134fe185f 100644
--- a/hw/s390x/s390-pci-kvm.c
+++ b/hw/s390x/s390-pci-kvm.c
@@ -22,9 +22,7 @@
 
 bool s390_pci_kvm_interp_allowed(void)
 {
-return (kvm_s390_get_zpci_op() && !s390_is_pv() &&
-!object_property_get_bool(OBJECT(qdev_get_machine()),
-  "zpcii-disable", NULL));
+return kvm_s390_get_zpci_op() && !s390_is_pv();
 }
 
 int s390_pci_kvm_aif_enable(S390PCIBusDevice *pbdev, ZpciFib *fib, bool assist)
diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 560ddbb6fb..bb98d40792 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -627,21 +627,6 @@ static inline void machine_set_dea_key_wrap(Object *obj, 
bool value,
 ms->dea_key_wrap = value;
 }
 
-static inline bool machine_get_zpcii_disable(Object *obj, Error **errp)
-{
-S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
-
-return ms->zpcii_disable;
-}
-
-static inline void machine_set_zpcii_disable(Object *obj, bool value,
- Error **errp)
-{
-S390CcwMachineState *ms = S390_CCW_MACHINE(obj);
-
-ms->zpcii_disable = value;
-}
-
 static S390CcwMachineClass *current_mc;
 
 /*
@@ -778,12 +763,6 @@ static void ccw_machine_class_init(ObjectClass *oc, void 
*data)
 "Up to 8 chars in set of [A-Za-z0-9. ] (lower case chars converted"
 " to upper case) to pass to machine loader, boot manager,"
 " and guest kernel");
-
-object_class_property_add_bool(oc, "zpcii-disable",
-   machine_get_zpcii_disable,
-   machine_set_zpcii_disable);
-object_class_property_set_description(oc, "zpcii-disable",
-"disable zPCI interpretation facilties");
 }
 
 static inline void s390_machine_initfn(Object *obj)
@@ -792,7 +771,6 @@ static inline void s390_machine_initfn(Object *obj)
 
 ms->aes_key_wrap = true;
 ms->dea_key_wrap = true;
-ms->zpcii_disable = false;
 }
 
 static const TypeInfo ccw_machine_info = {
@@ -857,12 +835,10 @@ DEFINE_CCW_MACHINE(7_2, "7.2", true);
 static void ccw_machine_7_1_instance_options(MachineState *machine)
 {
 static const S390FeatInit qemu_cpu_feat = { S390_FEAT_LIST_QEMU_V7_1 };
-S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
 
 ccw_machine_7_2_instance_options(machine);
 s390_cpudef_featoff_greater(16, 1, S390_FEAT_PAIE);
 s390_set_qemu_cpu_model(0x8561, 15, 1, qemu_cpu_feat);
-ms->zpcii_disable = true;
 }
 
 static void ccw_machine_7_1_class_options(MachineClass *mc)
diff --git a/util/qemu-config.c b/util/qemu-config.c
index 5325f6bf80..433488aa56 100644
--- a/util/qemu-config.c
+++ b/util/qemu-config.c
@@ -236,10 +236,6 @@ static QemuOptsList machine_opts = {
 .help = "Up to 8 chars in set of [A-Za-z0-9. ](lower case chars"
 " converted to upper case) to pass to machine"
 " loader, boot manager, and guest kernel",
-},{
-.name = "zpcii-disable",
-.type = QEMU_OPT_BOOL,
-.help = "disable zPCI interpretation facilities",
 },
 { /* End of list */ }
 }
diff --git a/qemu-options.hx b/qemu-options.hx
index 911d82afa5..1e140e99e1 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -37,8 +37,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
 "memory-encryption=@var{} memory encryption object to use 
(default=none)\n"
 "hmat=on|off controls ACPI HMAT support (default=off)\n"
 "memory-backend='backend-id' specifies explicitly provided 
backend for main RAM (default=none)\n"
-"
cxl-fmw.0.targets.0=firsttarget,cxl-fmw.0.targets.1=secondtarget,cxl-fmw.0.size=size[,cxl-fmw.0.interleave-granularity=granularity]\n"
-"zpcii-disable=on|off disables zPCI interpretation 
facilities (default=off)\n",
+"
cxl-fmw.0.targets.0=firsttarg

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Daniel P . Berrangé]

On Mon, Nov 07, 2022 at 03:50:44PM +, Alex Bennée wrote:
> 
> Sunil V L  writes:
> 
> > On Mon, Nov 07, 2022 at 01:06:38PM +, Peter Maydell wrote:
> >> On Mon, 7 Nov 2022 at 13:03, Sunil V L  wrote:
> >> >
> >> > The pflash implementation currently assumes fixed size of the
> >> > backend storage. Due to this, the backend storage file needs to be
> >> > exactly of size 32M. Otherwise, there will be an error like below.
> >> >
> >> > "device requires 33554432 bytes, block backend provides 4194304 bytes"
> >> >
> >> > Fix this issue by using the actual size of the backing store.
> >> >
> >> > Signed-off-by: Sunil V L 
> >> > ---
> >> 
> >> Do you really want the flash device size presented to the guest
> >> to be variable depending on what the user passed as a block backend?
> >> I don't think this is how we handle flash devices on other boards...
> >> 
> >
> > Hi Peter,
> >
> > x86 appears to support variable flash but arm doesn't. What is
> > the reason for not supporting variable size flash in arm?
> 
> If I recall from the last time we went around this is was the question
> of what you should pad it with.

Padding is a very good thing from the POV of upgrades. Firmware has shown
a tendancy to change (grow) over time, and the size has an impact of the
guest ABI/live migration state.

To be able to live migrate, or save/restore to/from files, then the machine
firmware size needs to be sufficient to cope with future size changes of
the firmware. The best way to deal with this is to not use the firmware
binaries' minimum compiled size, but instead to pad it upto a higher
boundary.

Enforcing such padding is a decent way to prevent users from inadvertantly
painting themselves into a corner with a very specific firmware binary
size at initial boot.

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 v8 1/4] block: drop bdrv_detach_child()

[Vladimir Sementsov-Ogievskiy]

From: Vladimir Sementsov-Ogievskiy 

The only caller is bdrv_root_unref_child(), let's just do the logic
directly in it. It simplifies further convertion of
bdrv_root_unref_child() to transaction action.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
---
 block.c | 46 +++---
 1 file changed, 19 insertions(+), 27 deletions(-)

diff --git a/block.c b/block.c
index 3bd594eb2a..65f5bb96ed 100644
--- a/block.c
+++ b/block.c
@@ -3060,30 +3060,6 @@ static BdrvChild 
*bdrv_attach_child_noperm(BlockDriverState *parent_bs,
 tran, errp);
 }
 
-static void bdrv_detach_child(BdrvChild *child)
-{
-BlockDriverState *old_bs = child->bs;
-
-GLOBAL_STATE_CODE();
-bdrv_replace_child_noperm(child, NULL);
-bdrv_child_free(child);
-
-if (old_bs) {
-/*
- * Update permissions for old node. We're just taking a parent away, so
- * we're loosening restrictions. Errors of permission update are not
- * fatal in this case, ignore them.
- */
-bdrv_refresh_perms(old_bs, NULL);
-
-/*
- * When the parent requiring a non-default AioContext is removed, the
- * node moves back to the main AioContext
- */
-bdrv_try_change_aio_context(old_bs, qemu_get_aio_context(), NULL, 
NULL);
-}
-}
-
 /*
  * This function steals the reference to child_bs from the caller.
  * That reference is later dropped by bdrv_root_unref_child().
@@ -3172,12 +3148,28 @@ out:
 /* Callers must ensure that child->frozen is false. */
 void bdrv_root_unref_child(BdrvChild *child)
 {
-BlockDriverState *child_bs;
+BlockDriverState *child_bs = child->bs;
 
 GLOBAL_STATE_CODE();
+bdrv_replace_child_noperm(child, NULL);
+bdrv_child_free(child);
+
+if (child_bs) {
+/*
+ * Update permissions for old node. We're just taking a parent away, so
+ * we're loosening restrictions. Errors of permission update are not
+ * fatal in this case, ignore them.
+ */
+bdrv_refresh_perms(child_bs, NULL);
+
+/*
+ * When the parent requiring a non-default AioContext is removed, the
+ * node moves back to the main AioContext
+ */
+bdrv_try_change_aio_context(child_bs, qemu_get_aio_context(), NULL,
+NULL);
+}
 
-child_bs = child->bs;
-bdrv_detach_child(child);
 bdrv_unref(child_bs);
 }
 
-- 
2.34.1

[PATCH v8 4/4] block: refactor bdrv_list_refresh_perms to allow any list of nodes

[Vladimir Sementsov-Ogievskiy]

From: Vladimir Sementsov-Ogievskiy 

We are going to increase usage of collecting nodes in a list to then
update, and calling bdrv_topological_dfs() each time is not convenient,
and not correct as we are going to interleave graph modifying with
filling the node list.

So, let's switch to a function that takes any list of nodes, adds all
their subtrees and do topological sort. And finally, refresh
permissions.

While being here, make the function public, as we'll want to use it
from blockdev.c in near future.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
---
 block.c | 51 ---
 1 file changed, 32 insertions(+), 19 deletions(-)

diff --git a/block.c b/block.c
index eed54f968d..4e039ee220 100644
--- a/block.c
+++ b/block.c
@@ -2511,8 +2511,12 @@ static int bdrv_node_refresh_perm(BlockDriverState *bs, 
BlockReopenQueue *q,
 return 0;
 }
 
-static int bdrv_list_refresh_perms(GSList *list, BlockReopenQueue *q,
-   Transaction *tran, Error **errp)
+/*
+ * @list is a product of bdrv_topological_dfs() (may be called several times) -
+ * a topologically sorted subgraph.
+ */
+static int bdrv_do_refresh_perms(GSList *list, BlockReopenQueue *q,
+ Transaction *tran, Error **errp)
 {
 int ret;
 BlockDriverState *bs;
@@ -2534,6 +2538,24 @@ static int bdrv_list_refresh_perms(GSList *list, 
BlockReopenQueue *q,
 return 0;
 }
 
+/*
+ * @list is any list of nodes. List is completed by all subtrees and
+ * topologically sorted. It's not a problem if some node occurs in the @list
+ * several times.
+ */
+static int bdrv_list_refresh_perms(GSList *list, BlockReopenQueue *q,
+   Transaction *tran, Error **errp)
+{
+g_autoptr(GHashTable) found = g_hash_table_new(NULL, NULL);
+g_autoptr(GSList) refresh_list = NULL;
+
+for ( ; list; list = list->next) {
+refresh_list = bdrv_topological_dfs(refresh_list, found, list->data);
+}
+
+return bdrv_do_refresh_perms(refresh_list, q, tran, errp);
+}
+
 void bdrv_get_cumulative_perm(BlockDriverState *bs, uint64_t *perm,
   uint64_t *shared_perm)
 {
@@ -2594,7 +2616,7 @@ static int bdrv_refresh_perms(BlockDriverState *bs, 
Transaction *tran,
 tran = local_tran = tran_new();
 }
 
-ret = bdrv_list_refresh_perms(list, NULL, tran, errp);
+ret = bdrv_do_refresh_perms(list, NULL, tran, errp);
 
 if (local_tran) {
 tran_finalize(local_tran, ret);
@@ -4350,7 +4372,6 @@ int bdrv_reopen_multiple(BlockReopenQueue *bs_queue, 
Error **errp)
 BlockReopenQueueEntry *bs_entry, *next;
 AioContext *ctx;
 Transaction *tran = tran_new();
-g_autoptr(GHashTable) found = NULL;
 g_autoptr(GSList) refresh_list = NULL;
 
 assert(qemu_get_current_aio_context() == qemu_get_aio_context());
@@ -4380,18 +4401,15 @@ int bdrv_reopen_multiple(BlockReopenQueue *bs_queue, 
Error **errp)
 bs_entry->prepared = true;
 }
 
-found = g_hash_table_new(NULL, NULL);
 QTAILQ_FOREACH(bs_entry, bs_queue, entry) {
 BDRVReopenState *state = &bs_entry->state;
 
-refresh_list = bdrv_topological_dfs(refresh_list, found, state->bs);
+refresh_list = g_slist_prepend(refresh_list, state->bs);
 if (state->old_backing_bs) {
-refresh_list = bdrv_topological_dfs(refresh_list, found,
-state->old_backing_bs);
+refresh_list = g_slist_prepend(refresh_list, 
state->old_backing_bs);
 }
 if (state->old_file_bs) {
-refresh_list = bdrv_topological_dfs(refresh_list, found,
-state->old_file_bs);
+refresh_list = g_slist_prepend(refresh_list, state->old_file_bs);
 }
 }
 
@@ -5108,7 +5126,6 @@ static int bdrv_replace_node_common(BlockDriverState 
*from,
 Error **errp)
 {
 Transaction *tran = tran_new();
-g_autoptr(GHashTable) found = NULL;
 g_autoptr(GSList) refresh_list = NULL;
 BlockDriverState *to_cow_parent = NULL;
 int ret;
@@ -5149,10 +5166,8 @@ static int bdrv_replace_node_common(BlockDriverState 
*from,
 bdrv_remove_child(bdrv_filter_or_cow_child(to_cow_parent), tran);
 }
 
-found = g_hash_table_new(NULL, NULL);
-
-refresh_list = bdrv_topological_dfs(refresh_list, found, to);
-refresh_list = bdrv_topological_dfs(refresh_list, found, from);
+refresh_list = g_slist_prepend(refresh_list, to);
+refresh_list = g_slist_prepend(refresh_list, from);
 
 ret = bdrv_list_refresh_perms(refresh_list, NULL, tran, errp);
 if (ret < 0) {
@@ -5237,7 +5252,6 @@ int bdrv_replace_child_bs(BdrvChild *child, 
BlockDriverState *new_bs,
 {
 int ret;
 Transaction *tran = tran_new();
-g_autoptr(GHashTable) found = NULL;
 g_autoptr(GSList) refresh_list = NULL;

[PATCH v8 2/4] block: drop bdrv_remove_filter_or_cow_child

[Vladimir Sementsov-Ogievskiy]

From: Vladimir Sementsov-Ogievskiy 

Drop this simple wrapper used only in one place. We have too many graph
modifying functions even without it.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
---
 block.c | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/block.c b/block.c
index 65f5bb96ed..8acff7983d 100644
--- a/block.c
+++ b/block.c
@@ -93,8 +93,6 @@ static bool bdrv_recurse_has_child(BlockDriverState *bs,
 static void bdrv_replace_child_noperm(BdrvChild *child,
   BlockDriverState *new_bs);
 static void bdrv_remove_child(BdrvChild *child, Transaction *tran);
-static void bdrv_remove_filter_or_cow_child(BlockDriverState *bs,
-Transaction *tran);
 
 static int bdrv_reopen_prepare(BDRVReopenState *reopen_state,
BlockReopenQueue *queue,
@@ -5055,17 +5053,6 @@ static void bdrv_remove_child(BdrvChild *child, 
Transaction *tran)
 tran_add(tran, &bdrv_remove_child_drv, child);
 }
 
-/*
- * A function to remove backing-chain child of @bs if exists: cow child for
- * format nodes (always .backing) and filter child for filters (may be .file or
- * .backing)
- */
-static void bdrv_remove_filter_or_cow_child(BlockDriverState *bs,
-Transaction *tran)
-{
-bdrv_remove_child(bdrv_filter_or_cow_child(bs), tran);
-}
-
 static int bdrv_replace_node_noperm(BlockDriverState *from,
 BlockDriverState *to,
 bool auto_skip, Transaction *tran,
@@ -5150,7 +5137,7 @@ static int bdrv_replace_node_common(BlockDriverState 
*from,
 }
 
 if (detach_subchain) {
-bdrv_remove_filter_or_cow_child(to_cow_parent, tran);
+bdrv_remove_child(bdrv_filter_or_cow_child(to_cow_parent), tran);
 }
 
 found = g_hash_table_new(NULL, NULL);
-- 
2.34.1

[PATCH v8 3/4] block: bdrv_refresh_perms(): allow external tran

[Vladimir Sementsov-Ogievskiy]

From: Vladimir Sementsov-Ogievskiy 

Allow passing external Transaction pointer, stop creating extra
Transaction objects.

Signed-off-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Hanna Reitz 
---
 block.c | 31 ---
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/block.c b/block.c
index 8acff7983d..eed54f968d 100644
--- a/block.c
+++ b/block.c
@@ -2581,15 +2581,24 @@ char *bdrv_perm_names(uint64_t perm)
 }
 
 
-static int bdrv_refresh_perms(BlockDriverState *bs, Error **errp)
+/* @tran is allowed to be NULL. In this case no rollback is possible */
+static int bdrv_refresh_perms(BlockDriverState *bs, Transaction *tran,
+  Error **errp)
 {
 int ret;
-Transaction *tran = tran_new();
+Transaction *local_tran = NULL;
 g_autoptr(GSList) list = bdrv_topological_dfs(NULL, NULL, bs);
 GLOBAL_STATE_CODE();
 
+if (!tran) {
+tran = local_tran = tran_new();
+}
+
 ret = bdrv_list_refresh_perms(list, NULL, tran, errp);
-tran_finalize(tran, ret);
+
+if (local_tran) {
+tran_finalize(local_tran, ret);
+}
 
 return ret;
 }
@@ -2605,7 +2614,7 @@ int bdrv_child_try_set_perm(BdrvChild *c, uint64_t perm, 
uint64_t shared,
 
 bdrv_child_set_perm(c, perm, shared, tran);
 
-ret = bdrv_refresh_perms(c->bs, &local_err);
+ret = bdrv_refresh_perms(c->bs, tran, &local_err);
 
 tran_finalize(tran, ret);
 
@@ -3089,7 +3098,7 @@ BdrvChild *bdrv_root_attach_child(BlockDriverState 
*child_bs,
 goto out;
 }
 
-ret = bdrv_refresh_perms(child_bs, errp);
+ret = bdrv_refresh_perms(child_bs, tran, errp);
 
 out:
 tran_finalize(tran, ret);
@@ -3130,7 +3139,7 @@ BdrvChild *bdrv_attach_child(BlockDriverState *parent_bs,
 goto out;
 }
 
-ret = bdrv_refresh_perms(parent_bs, errp);
+ret = bdrv_refresh_perms(parent_bs, tran, errp);
 if (ret < 0) {
 goto out;
 }
@@ -3158,7 +3167,7 @@ void bdrv_root_unref_child(BdrvChild *child)
  * we're loosening restrictions. Errors of permission update are not
  * fatal in this case, ignore them.
  */
-bdrv_refresh_perms(child_bs, NULL);
+bdrv_refresh_perms(child_bs, NULL, NULL);
 
 /*
  * When the parent requiring a non-default AioContext is removed, the
@@ -3400,7 +3409,7 @@ int bdrv_set_backing_hd(BlockDriverState *bs, 
BlockDriverState *backing_hd,
 goto out;
 }
 
-ret = bdrv_refresh_perms(bs, errp);
+ret = bdrv_refresh_perms(bs, tran, errp);
 out:
 tran_finalize(tran, ret);
 
@@ -5213,7 +5222,7 @@ int bdrv_append(BlockDriverState *bs_new, 
BlockDriverState *bs_top,
 goto out;
 }
 
-ret = bdrv_refresh_perms(bs_new, errp);
+ret = bdrv_refresh_perms(bs_new, tran, errp);
 out:
 tran_finalize(tran, ret);
 
@@ -6513,7 +6522,7 @@ int bdrv_activate(BlockDriverState *bs, Error **errp)
  */
 if (bs->open_flags & BDRV_O_INACTIVE) {
 bs->open_flags &= ~BDRV_O_INACTIVE;
-ret = bdrv_refresh_perms(bs, errp);
+ret = bdrv_refresh_perms(bs, NULL, errp);
 if (ret < 0) {
 bs->open_flags |= BDRV_O_INACTIVE;
 return ret;
@@ -6658,7 +6667,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs)
  * We only tried to loosen restrictions, so errors are not fatal, ignore
  * them.
  */
-bdrv_refresh_perms(bs, NULL);
+bdrv_refresh_perms(bs, NULL, NULL);
 
 /* Recursively inactivate children */
 QLIST_FOREACH(child, &bs->children, next) {
-- 
2.34.1

[PATCH v8 0/4] block: small refactorings

[Vladimir Sementsov-Ogievskiy]

Hi all!

Here is 4-more simple already reviewed patches from
 "[PATCH v5 00/45] Transactional block-graph modifying API" [1]

Called v8 because first part of [1] was recently merged as
 "[PATCH v7 for-7.2 00/15] block: cleanup backing and file handling"

Vladimir Sementsov-Ogievskiy (4):
  block: drop bdrv_detach_child()
  block: drop bdrv_remove_filter_or_cow_child
  block: bdrv_refresh_perms(): allow external tran
  block: refactor bdrv_list_refresh_perms to allow any list of nodes

 block.c | 141 
 1 file changed, 71 insertions(+), 70 deletions(-)

-- 
2.34.1

[PATCH qemu.git v2 1/9] hw/timer/imx_epit: improve comments

[~axelheider]

From: Axel Heider 

Fix typos, add background information

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index ec0fa440d7..4af730593f 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -100,9 +100,7 @@ static void imx_epit_reset(DeviceState *dev)
 {
 IMXEPITState *s = IMX_EPIT(dev);
 
-/*
- * Soft reset doesn't touch some bits; hard reset clears them
- */
+/* Soft reset doesn't touch some bits; hard reset clears them */
 s->cr &= (CR_EN|CR_ENMOD|CR_STOPEN|CR_DOZEN|CR_WAITEN|CR_DBGEN);
 s->sr = 0;
 s->lr = EPIT_TIMER_MAX;
@@ -214,6 +212,7 @@ static void imx_epit_write(void *opaque, hwaddr offset, 
uint64_t value,
 ptimer_transaction_begin(s->timer_cmp);
 ptimer_transaction_begin(s->timer_reload);
 
+/* Update the frequency. Has been done already in case of a reset. */
 if (!(s->cr & CR_SWR)) {
 imx_epit_set_freq(s);
 }
@@ -254,7 +253,7 @@ static void imx_epit_write(void *opaque, hwaddr offset, 
uint64_t value,
 break;
 
 case 1: /* SR - ACK*/
-/* writing 1 to OCIF clear the OCIF bit */
+/* writing 1 to OCIF clears the OCIF bit */
 if (value & 0x01) {
 s->sr = 0;
 imx_epit_update_int(s);
@@ -352,8 +351,18 @@ static void imx_epit_realize(DeviceState *dev, Error 
**errp)
   0x1000);
 sysbus_init_mmio(sbd, &s->iomem);
 
+/*
+ * The reload timer keeps running when the peripheral is enabled. It is a
+ * kind of wall clock that does not generate any interrupts. The callback
+ * needs to be provided, but it does nothing as the ptimer already supports
+ * all necessary reloading functionality.
+ */
 s->timer_reload = ptimer_init(imx_epit_reload, s, PTIMER_POLICY_LEGACY);
 
+/*
+ * The compare timer is running only when the peripheral configuration is
+ * in a state that will generate compare interrupts.
+ */
 s->timer_cmp = ptimer_init(imx_epit_cmp, s, PTIMER_POLICY_LEGACY);
 }
 
-- 
2.34.5

[PATCH qemu.git v2 3/9] hw/timer/imx_epit: simplify interrupt logic

[~axelheider]

From: Axel Heider 

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 27 +++
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index 8ec770f674..2e9dae0bc8 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -61,18 +61,6 @@ static const IMXClk imx_epit_clocks[] =  {
 CLK_32k,   /* 11 ipg_clk_32k -- ~32kHz */
 };
 
-/*
- * Update interrupt status
- */
-static void imx_epit_update_int(IMXEPITState *s)
-{
-if (s->sr && (s->cr & CR_OCIEN) && (s->cr & CR_EN)) {
-qemu_irq_raise(s->irq);
-} else {
-qemu_irq_lower(s->irq);
-}
-}
-
 /*
  * Must be called from within a ptimer_transaction_begin/commit block
  * for both s->timer_cmp and s->timer_reload.
@@ -253,10 +241,10 @@ static void imx_epit_write(void *opaque, hwaddr offset, 
uint64_t value,
 break;
 
 case 1: /* SR - ACK*/
-/* writing 1 to OCIF clears the OCIF bit */
+/* writing 1 to OCIF clears the OCIF bit and the interrupt */
 if (value & 0x01) {
 s->sr = 0;
-imx_epit_update_int(s);
+qemu_irq_lower(s->irq);
 }
 break;
 
@@ -305,10 +293,17 @@ static void imx_epit_cmp(void *opaque)
 {
 IMXEPITState *s = IMX_EPIT(opaque);
 
+/* Set the interrupt status flag to signaled. */
 DPRINTF("sr was %d\n", s->sr);
-
 s->sr = 1;
-imx_epit_update_int(s);
+
+/*
+ * An actual interrupt is generated only if the peripheral is enabled
+ * and the interrupt generation is enabled.
+ */
+if ((s->cr & (CR_EN | CR_OCIEN)) == (CR_EN | CR_OCIEN)) {
+qemu_irq_raise(s->irq);
+}
 }
 
 static void imx_epit_reload(void *opaque)
-- 
2.34.5

[PATCH qemu.git v2 0/9] hw/timer/imx_epit: imprive and fix compare timer handling

[~axelheider]

This patch set improves the i.MX EPIT emulation:
- fix #1263 for writes to CR also
- do not persist CR.SWR bit
- remove explicit fields cnt and freq
- software reset clears the interrupt
- general code and documentation improvements

Axel Heider (9):
  hw/timer/imx_epit: improve comments
  hw/timer/imx_epit: cleanup CR defines
  hw/timer/imx_epit: simplify interrupt logic
  hw/timer/imx_epit: software reset clears the interrupt
  hw/timer/imx_epit: do not persist CR.SWR bit
  hw/timer/imx_epit: remove explicit fields cnt and freq
  hw/timer/imx_epit: factor out register write handlers
  hw/timer/imx_epit: change reset handling
  hw/timer/imx_epit: fix compare timer handling

 hw/timer/imx_epit.c | 408 
 include/hw/timer/imx_epit.h |   6 +-
 2 files changed, 231 insertions(+), 183 deletions(-)

-- 
2.34.5

[PATCH qemu.git v2 6/9] hw/timer/imx_epit: remove explicit fields cnt and freq

[~axelheider]

From: Axel Heider 

The CNT register is a read-only register. There is no need to
store it's value, it can be calculated on demand.
The calculated frequency is needed temporarily only.

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 76 +++--
 include/hw/timer/imx_epit.h |  2 -
 2 files changed, 30 insertions(+), 48 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index 6af460946f..b0ef727efb 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -61,27 +61,16 @@ static const IMXClk imx_epit_clocks[] =  {
 CLK_32k,   /* 11 ipg_clk_32k -- ~32kHz */
 };
 
-/*
- * Must be called from within a ptimer_transaction_begin/commit block
- * for both s->timer_cmp and s->timer_reload.
- */
-static void imx_epit_set_freq(IMXEPITState *s)
+static uint32_t imx_epit_get_freq(IMXEPITState *s)
 {
-uint32_t clksrc;
-uint32_t prescaler;
-
-clksrc = extract32(s->cr, CR_CLKSRC_SHIFT, CR_CLKSRC_BITS);
-prescaler = 1 + extract32(s->cr, CR_PRESCALE_SHIFT, CR_PRESCALE_BITS);
-
-s->freq = imx_ccm_get_clock_frequency(s->ccm,
-imx_epit_clocks[clksrc]) / prescaler;
-
-DPRINTF("Setting ptimer frequency to %u\n", s->freq);
-
-if (s->freq) {
-ptimer_set_freq(s->timer_reload, s->freq);
-ptimer_set_freq(s->timer_cmp, s->freq);
-}
+uint32_t clksrc = extract32(s->cr, CR_CLKSRC_SHIFT, CR_CLKSRC_BITS);
+uint32_t prescaler = 1 + extract32(s->cr, CR_PRESCALE_SHIFT,
+   CR_PRESCALE_BITS);
+uint32_t f_in = imx_ccm_get_clock_frequency(s->ccm,
+imx_epit_clocks[clksrc]);
+uint32_t freq = f_in / prescaler;
+DPRINTF("ptimer frequency is %u\n", freq);
+return freq;
 }
 
 static void imx_epit_reset(DeviceState *dev)
@@ -93,36 +82,26 @@ static void imx_epit_reset(DeviceState *dev)
 s->sr = 0;
 s->lr = EPIT_TIMER_MAX;
 s->cmp = 0;
-s->cnt = 0;
-
 /* clear the interrupt */
 qemu_irq_lower(s->irq);
 
 ptimer_transaction_begin(s->timer_cmp);
 ptimer_transaction_begin(s->timer_reload);
-/* stop both timers */
+
+/*
+ * The reset switches off the input clock, so even if the CR.EN is still
+ * set, the timers are no longer running.
+ */
+assert(0 == imx_epit_get_freq(s));
 ptimer_stop(s->timer_cmp);
 ptimer_stop(s->timer_reload);
-/* compute new frequency */
-imx_epit_set_freq(s);
 /* init both timers to EPIT_TIMER_MAX */
 ptimer_set_limit(s->timer_cmp, EPIT_TIMER_MAX, 1);
 ptimer_set_limit(s->timer_reload, EPIT_TIMER_MAX, 1);
-if (s->freq && (s->cr & CR_EN)) {
-/* if the timer is still enabled, restart it */
-ptimer_run(s->timer_reload, 0);
-}
 ptimer_transaction_commit(s->timer_cmp);
 ptimer_transaction_commit(s->timer_reload);
 }
 
-static uint32_t imx_epit_update_count(IMXEPITState *s)
-{
-s->cnt = ptimer_get_count(s->timer_reload);
-
-return s->cnt;
-}
-
 static uint64_t imx_epit_read(void *opaque, hwaddr offset, unsigned size)
 {
 IMXEPITState *s = IMX_EPIT(opaque);
@@ -146,8 +125,7 @@ static uint64_t imx_epit_read(void *opaque, hwaddr offset, 
unsigned size)
 break;
 
 case 4: /* CNT */
-imx_epit_update_count(s);
-reg_value = s->cnt;
+reg_value = ptimer_get_count(s->timer_reload);
 break;
 
 default:
@@ -166,7 +144,7 @@ static void imx_epit_reload_compare_timer(IMXEPITState *s)
 {
 if ((s->cr & (CR_EN | CR_OCIEN)) == (CR_EN | CR_OCIEN))  {
 /* if the compare feature is on and timers are running */
-uint32_t tmp = imx_epit_update_count(s);
+uint32_t tmp = ptimer_get_count(s->timer_reload);
 uint64_t next;
 if (tmp > s->cmp) {
 /* It'll fire in this round of the timer */
@@ -182,6 +160,7 @@ static void imx_epit_write(void *opaque, hwaddr offset, 
uint64_t value,
unsigned size)
 {
 IMXEPITState *s = IMX_EPIT(opaque);
+uint64_t freq = 0;
 uint64_t oldcr;
 
 DPRINTF("(%s, value = 0x%08x)\n", imx_epit_reg_name(offset >> 2),
@@ -205,12 +184,19 @@ static void imx_epit_write(void *opaque, hwaddr offset, 
uint64_t value,
 ptimer_transaction_begin(s->timer_cmp);
 ptimer_transaction_begin(s->timer_reload);
 
-/* Update the frequency. Has been done already in case of a reset. */
+/*
+ * Update the frequency. In case of a reset the input clock was
+ * switched off, so this can be skipped.
+ */
 if (!(value & CR_SWR)) {
-imx_epit_set_freq(s);
+freq = imx_epit_get_freq(s);
+if (freq) {
+ptimer_set_freq(s->timer_reload, freq);
+ptimer_set_freq(s->timer_cmp, freq);
+}
 }
 
-if (s->freq && (s->cr & CR_EN) && !(oldcr & CR_EN)) {
+if (freq && (s->cr & CR_EN) && !(oldcr & CR_EN

[PATCH qemu.git v2 9/9] hw/timer/imx_epit: fix compare timer handling

[~axelheider]

From: Axel Heider 

- fix #1263
- rework compare time handling
  - The compare timer has to run even if CR.OCIEN is not set,
as SR.OCIF must be updated.
  - The compare timer fires exactly once when the
compare value is less than the current value, but the
reload values is less than the compare value.
  - The compare timer will never fire if the reload value is
less than the compare value. Disable it in this case.

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 188 +---
 1 file changed, 123 insertions(+), 65 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index 77bd2b0a2b..cb2880cabc 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -6,6 +6,7 @@
  * Originally written by Hans Jiang
  * Updated by Peter Chubb
  * Updated by Jean-Christophe Dubois 
+ * Updated by Axel Heider
  *
  * This code is licensed under GPL version 2 or later.  See
  * the COPYING file in the top-level directory.
@@ -110,33 +111,84 @@ static uint64_t imx_epit_read(void *opaque, hwaddr 
offset, unsigned size)
 return reg_value;
 }
 
-/* Must be called from ptimer_transaction_begin/commit block for s->timer_cmp 
*/
-static void imx_epit_reload_compare_timer(IMXEPITState *s)
+/*
+ * Must be called from a ptimer_transaction_begin/commit block for
+ * s->timer_cmp, but outside of a transaction block of s->timer_reload,
+ * so the proper counter value is read.
+ */
+static void imx_epit_update_compare_timer(IMXEPITState *s)
 {
-if ((s->cr & (CR_EN | CR_OCIEN)) == (CR_EN | CR_OCIEN))  {
-/* if the compare feature is on and timers are running */
-uint32_t tmp = ptimer_get_count(s->timer_reload);
-uint64_t next;
-if (tmp > s->cmp) {
-/* It'll fire in this round of the timer */
-next = tmp - s->cmp;
-} else { /* catch it next time around */
-next = tmp - s->cmp + ((s->cr & CR_RLD) ? EPIT_TIMER_MAX : s->lr);
+uint64_t counter = 0;
+bool is_oneshot = false;
+/* The compare timer only has to run if the timer peripheral is active
+ * and there is an input clock, Otherwise it can be switched off.
+ */
+bool is_active = (s->cr & CR_EN) && imx_epit_get_freq(s);
+if (is_active)
+{
+/*
+ * Calculate next timeout for compare timer. Reading the reload
+ * counter returns proper results only if pending transactions
+ * on it are committed here. Otherwise stale values are be read.
+ */
+counter = ptimer_get_count(s->timer_reload);
+uint64_t limit = ptimer_get_limit(s->timer_cmp);
+/* The compare timer is a periodic timer if the limit is at least
+ * the compare value. Otherwise it may fire at most once in the
+ * current round.
+ */
+bool is_oneshot = (limit >= s->cmp);
+if (counter >= s->cmp) {
+/* The compare timer fires in the current round. */
+counter -= s->cmp;
+} else if (!is_oneshot) {
+/*
+ * The compare timer fires after a reload, as it below the
+ * compare value already in this round. Note that the counter
+ * value calculated below can be above the 32-bit limit, which
+ * is legal here because the compare timer is an internal
+ * helper ptimer only.
+ */
+counter += limit - s->cmp;
+} else {
+/*
+ * The compare timer wont fire in this round, and the limit is
+ * set to a value below the compare value. This practically means
+ * it will never fire, so it can be switched off.
+ */
+is_active = false;
 }
-ptimer_set_count(s->timer_cmp, next);
 }
+
+/*
+ * Set the compare timer and let it run, or stop it. This is agnostic
+ * of CR.OCIEN bit, as this only matters for interrupt generation. The
+ * compare timer needs to run in any case, as the SR.OCIF bit must be
+ * updated even if no interrupt in generated.
+ * Note that the timer might already be stopped or be running with
+ * counter values. However, finding out when an update is needed and
+ * when not is not trivial. It's much easier applying the setting again,
+ * as this does not harm either and the overhead is negligible.
+ */
+if (is_active) {
+ptimer_set_count(s->timer_cmp, counter);
+ptimer_run(s->timer_cmp, is_oneshot ? 1 : 0);
+} else {
+ptimer_stop(s->timer_cmp);
+}
+
 }
 
 static void imx_epit_write_cr(IMXEPITState *s, uint32_t value)
 {
 uint32_t freq = 0;
-uint32_t oldcr = s->cr;
+bool set_limit = false;
+bool set_counter = false;
 
 /* SWR bit is never persisted, it clears itself once reset is done */
+uint32_t old_cr = s->cr;
 s->cr = (value & ~CR_SWR) & 0x03ff;
-
-ptimer_transaction_begin(s->timer_cmp);
-ptimer_transaction_begin(s

[PATCH qemu.git v2 4/9] hw/timer/imx_epit: software reset clears the interrupt

[~axelheider]

From: Axel Heider 

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index 2e9dae0bc8..5315d9633e 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -94,6 +94,10 @@ static void imx_epit_reset(DeviceState *dev)
 s->lr = EPIT_TIMER_MAX;
 s->cmp = 0;
 s->cnt = 0;
+
+/* clear the interrupt */
+qemu_irq_lower(s->irq);
+
 ptimer_transaction_begin(s->timer_cmp);
 ptimer_transaction_begin(s->timer_reload);
 /* stop both timers */
-- 
2.34.5

[PATCH qemu.git v2 2/9] hw/timer/imx_epit: cleanup CR defines

[~axelheider]

From: Axel Heider 

remove unused defines, add needed defines

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 4 ++--
 include/hw/timer/imx_epit.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index 4af730593f..8ec770f674 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -82,8 +82,8 @@ static void imx_epit_set_freq(IMXEPITState *s)
 uint32_t clksrc;
 uint32_t prescaler;
 
-clksrc = extract32(s->cr, CR_CLKSRC_SHIFT, 2);
-prescaler = 1 + extract32(s->cr, CR_PRESCALE_SHIFT, 12);
+clksrc = extract32(s->cr, CR_CLKSRC_SHIFT, CR_CLKSRC_BITS);
+prescaler = 1 + extract32(s->cr, CR_PRESCALE_SHIFT, CR_PRESCALE_BITS);
 
 s->freq = imx_ccm_get_clock_frequency(s->ccm,
 imx_epit_clocks[clksrc]) / prescaler;
diff --git a/include/hw/timer/imx_epit.h b/include/hw/timer/imx_epit.h
index 2acc41e982..e2cb96229b 100644
--- a/include/hw/timer/imx_epit.h
+++ b/include/hw/timer/imx_epit.h
@@ -43,7 +43,7 @@
 #define CR_OCIEN(1 << 2)
 #define CR_RLD  (1 << 3)
 #define CR_PRESCALE_SHIFT (4)
-#define CR_PRESCALE_MASK  (0xfff)
+#define CR_PRESCALE_BITS  (12)
 #define CR_SWR  (1 << 16)
 #define CR_IOVW (1 << 17)
 #define CR_DBGEN(1 << 18)
@@ -51,7 +51,7 @@
 #define CR_DOZEN(1 << 20)
 #define CR_STOPEN   (1 << 21)
 #define CR_CLKSRC_SHIFT (24)
-#define CR_CLKSRC_MASK  (0x3 << CR_CLKSRC_SHIFT)
+#define CR_CLKSRC_BITS  (2)
 
 #define EPIT_TIMER_MAX  0XUL
 
-- 
2.34.5

[PATCH qemu.git v2 7/9] hw/timer/imx_epit: factor out register write handlers

[~axelheider]

From: Axel Heider 

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 211 
 1 file changed, 115 insertions(+), 96 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index b0ef727efb..30280a9ac1 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -156,130 +156,149 @@ static void imx_epit_reload_compare_timer(IMXEPITState 
*s)
 }
 }
 
-static void imx_epit_write(void *opaque, hwaddr offset, uint64_t value,
-   unsigned size)
+static void imx_epit_write_cr(IMXEPITState *s, uint32_t value)
 {
-IMXEPITState *s = IMX_EPIT(opaque);
-uint64_t freq = 0;
-uint64_t oldcr;
-
-DPRINTF("(%s, value = 0x%08x)\n", imx_epit_reg_name(offset >> 2),
-(uint32_t)value);
+uint32_t freq = 0;
+uint32_t oldcr = s->cr;
 
-switch (offset >> 2) {
-case 0: /* CR */
-
-oldcr = s->cr;
-/* SWR bit is never persisted, it clears itself once reset is done */
-s->cr = (value & ~CR_SWR) & 0x03ff;
-if (value & CR_SWR) {
-/* handle the reset */
-imx_epit_reset(DEVICE(s));
-/*
- * TODO: could we 'break' here? following operations appear
- * to duplicate the work imx_epit_reset() already did.
- */
-}
-
-ptimer_transaction_begin(s->timer_cmp);
-ptimer_transaction_begin(s->timer_reload);
+/* SWR bit is never persisted, it clears itself once reset is done */
+s->cr = (value & ~CR_SWR) & 0x03ff;
 
+if (value & CR_SWR) {
+/* handle the reset */
+imx_epit_reset(DEVICE(s));
 /*
- * Update the frequency. In case of a reset the input clock was
- * switched off, so this can be skipped.
+ * TODO: could we 'break' here? following operations appear
+ * to duplicate the work imx_epit_reset() already did.
  */
-if (!(value & CR_SWR)) {
-freq = imx_epit_get_freq(s);
-if (freq) {
-ptimer_set_freq(s->timer_reload, freq);
-ptimer_set_freq(s->timer_cmp, freq);
-}
-}
+}
 
-if (freq && (s->cr & CR_EN) && !(oldcr & CR_EN)) {
-if (s->cr & CR_ENMOD) {
-if (s->cr & CR_RLD) {
-ptimer_set_limit(s->timer_reload, s->lr, 1);
-ptimer_set_limit(s->timer_cmp, s->lr, 1);
-} else {
-ptimer_set_limit(s->timer_reload, EPIT_TIMER_MAX, 1);
-ptimer_set_limit(s->timer_cmp, EPIT_TIMER_MAX, 1);
-}
-}
+ptimer_transaction_begin(s->timer_cmp);
+ptimer_transaction_begin(s->timer_reload);
 
-imx_epit_reload_compare_timer(s);
-ptimer_run(s->timer_reload, 0);
-if (s->cr & CR_OCIEN) {
-ptimer_run(s->timer_cmp, 0);
+/*
+ * Update the frequency. In case of a reset the input clock was
+ * switched off, so this can be skipped.
+ */
+if (!(value & CR_SWR)) {
+freq = imx_epit_get_freq(s);
+if (freq) {
+ptimer_set_freq(s->timer_reload, freq);
+ptimer_set_freq(s->timer_cmp, freq);
+}
+}
+
+if (freq && (s->cr & CR_EN) && !(oldcr & CR_EN)) {
+if (s->cr & CR_ENMOD) {
+if (s->cr & CR_RLD) {
+ptimer_set_limit(s->timer_reload, s->lr, 1);
+ptimer_set_limit(s->timer_cmp, s->lr, 1);
 } else {
-ptimer_stop(s->timer_cmp);
-}
-} else if (!(s->cr & CR_EN)) {
-/* stop both timers */
-ptimer_stop(s->timer_reload);
-ptimer_stop(s->timer_cmp);
-} else  if (s->cr & CR_OCIEN) {
-if (!(oldcr & CR_OCIEN)) {
-imx_epit_reload_compare_timer(s);
-ptimer_run(s->timer_cmp, 0);
+ptimer_set_limit(s->timer_reload, EPIT_TIMER_MAX, 1);
+ptimer_set_limit(s->timer_cmp, EPIT_TIMER_MAX, 1);
 }
+}
+
+imx_epit_reload_compare_timer(s);
+ptimer_run(s->timer_reload, 0);
+if (s->cr & CR_OCIEN) {
+ptimer_run(s->timer_cmp, 0);
 } else {
 ptimer_stop(s->timer_cmp);
 }
+} else if (!(s->cr & CR_EN)) {
+/* stop both timers */
+ptimer_stop(s->timer_reload);
+ptimer_stop(s->timer_cmp);
+} else  if (s->cr & CR_OCIEN) {
+if (!(oldcr & CR_OCIEN)) {
+imx_epit_reload_compare_timer(s);
+ptimer_run(s->timer_cmp, 0);
+}
+} else {
+ptimer_stop(s->timer_cmp);
+}
+
+ptimer_transaction_commit(s->timer_cmp);
+ptimer_transaction_commit(s->timer_reload);
+}
+
+static void imx_epit_write_sr(IMXEPITState *s, uint32_t value)
+{
+/* writing 1 to OCIF clears the OCIF bit and the interrupt */
+if (value & 0x01) {
+s->sr = 0;
+qemu

[PATCH qemu.git v2 8/9] hw/timer/imx_epit: change reset handling

[~axelheider]

From: Axel Heider 

- inline software reset
- make hardware reset invoke software reset
- simplify code flow

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 66 -
 1 file changed, 23 insertions(+), 43 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index 30280a9ac1..77bd2b0a2b 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -73,35 +73,6 @@ static uint32_t imx_epit_get_freq(IMXEPITState *s)
 return freq;
 }
 
-static void imx_epit_reset(DeviceState *dev)
-{
-IMXEPITState *s = IMX_EPIT(dev);
-
-/* Soft reset doesn't touch some bits; hard reset clears them */
-s->cr &= (CR_EN|CR_ENMOD|CR_STOPEN|CR_DOZEN|CR_WAITEN|CR_DBGEN);
-s->sr = 0;
-s->lr = EPIT_TIMER_MAX;
-s->cmp = 0;
-/* clear the interrupt */
-qemu_irq_lower(s->irq);
-
-ptimer_transaction_begin(s->timer_cmp);
-ptimer_transaction_begin(s->timer_reload);
-
-/*
- * The reset switches off the input clock, so even if the CR.EN is still
- * set, the timers are no longer running.
- */
-assert(0 == imx_epit_get_freq(s));
-ptimer_stop(s->timer_cmp);
-ptimer_stop(s->timer_reload);
-/* init both timers to EPIT_TIMER_MAX */
-ptimer_set_limit(s->timer_cmp, EPIT_TIMER_MAX, 1);
-ptimer_set_limit(s->timer_reload, EPIT_TIMER_MAX, 1);
-ptimer_transaction_commit(s->timer_cmp);
-ptimer_transaction_commit(s->timer_reload);
-}
-
 static uint64_t imx_epit_read(void *opaque, hwaddr offset, unsigned size)
 {
 IMXEPITState *s = IMX_EPIT(opaque);
@@ -164,23 +135,23 @@ static void imx_epit_write_cr(IMXEPITState *s, uint32_t 
value)
 /* SWR bit is never persisted, it clears itself once reset is done */
 s->cr = (value & ~CR_SWR) & 0x03ff;
 
-if (value & CR_SWR) {
-/* handle the reset */
-imx_epit_reset(DEVICE(s));
-/*
- * TODO: could we 'break' here? following operations appear
- * to duplicate the work imx_epit_reset() already did.
- */
-}
-
 ptimer_transaction_begin(s->timer_cmp);
 ptimer_transaction_begin(s->timer_reload);
 
-/*
- * Update the frequency. In case of a reset the input clock was
- * switched off, so this can be skipped.
- */
-if (!(value & CR_SWR)) {
+if (value & CR_SWR) {
+/* Soft reset doesn't touch some bits; only a hard reset clears them */
+s->cr &= (CR_EN|CR_ENMOD|CR_STOPEN|CR_DOZEN|CR_WAITEN|CR_DBGEN);
+s->sr = 0;
+s->lr = EPIT_TIMER_MAX;
+s->cmp = 0;
+/* reset is supposed to disable the input clock */
+assert(0 == imx_epit_get_freq(s));
+/* turn interrupt off since SR and the OCIEN bit got cleared */
+qemu_irq_lower(s->irq);
+/* reset timer limits, set timer values to these limits */
+ptimer_set_limit(s->timer_cmp, EPIT_TIMER_MAX, 1);
+ptimer_set_limit(s->timer_reload, EPIT_TIMER_MAX, 1);
+} else {
 freq = imx_epit_get_freq(s);
 if (freq) {
 ptimer_set_freq(s->timer_reload, freq);
@@ -369,6 +340,15 @@ static void imx_epit_realize(DeviceState *dev, Error 
**errp)
 s->timer_cmp = ptimer_init(imx_epit_cmp, s, PTIMER_POLICY_LEGACY);
 }
 
+static void imx_epit_reset(DeviceState *dev)
+{
+IMXEPITState *s = IMX_EPIT(dev);
+
+/* initialize CR and perform a software reset */
+s->cr = 0;
+imx_epit_write_cr(s, CR_SWR);
+}
+
 static void imx_epit_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc  = DEVICE_CLASS(klass);
-- 
2.34.5

[PATCH qemu.git v2 5/9] hw/timer/imx_epit: do not persist CR.SWR bit

[~axelheider]

From: Axel Heider 

Signed-off-by: Axel Heider 
---
 hw/timer/imx_epit.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/timer/imx_epit.c b/hw/timer/imx_epit.c
index 5315d9633e..6af460946f 100644
--- a/hw/timer/imx_epit.c
+++ b/hw/timer/imx_epit.c
@@ -191,8 +191,9 @@ static void imx_epit_write(void *opaque, hwaddr offset, 
uint64_t value,
 case 0: /* CR */
 
 oldcr = s->cr;
-s->cr = value & 0x03ff;
-if (s->cr & CR_SWR) {
+/* SWR bit is never persisted, it clears itself once reset is done */
+s->cr = (value & ~CR_SWR) & 0x03ff;
+if (value & CR_SWR) {
 /* handle the reset */
 imx_epit_reset(DEVICE(s));
 /*
@@ -205,7 +206,7 @@ static void imx_epit_write(void *opaque, hwaddr offset, 
uint64_t value,
 ptimer_transaction_begin(s->timer_reload);
 
 /* Update the frequency. Has been done already in case of a reset. */
-if (!(s->cr & CR_SWR)) {
+if (!(value & CR_SWR)) {
 imx_epit_set_freq(s);
 }
 
-- 
2.34.5

Re: [PATCH for 7.2 0/2] s390x/s390-virtio-ccw:

[Matthew Rosato]

On 11/7/22 11:13 AM, Cédric Le Goater wrote:
> From: Cédric Le Goater 
> 
> Hello,
> 
> This series removes the redundant "zpcii-disable" machine property and
> and introduces a GlobalProperty compat array to maintain the same
> behaviour on older machines.
> 
> Thanks,
> 
> C.

Thanks Cedric.

For the series:
Reviewed-by: Matthew Rosato 

Also did a quick test on top of
https://gitlab.com/thuth/qemu.git tags/pull-request-2022-11-06

to verify that zPCI interpretation/forwarding is available as expected with 
machine 7.2 and off by default in 7.1 and older.

> 
> Cédric Le Goater (2):
>   Revert "s390x/s390-virtio-ccw: add zpcii-disable machine property"
>   s390x/s390-virtio-ccw: Switch off zPCI enhancements on older machines
> 
>  include/hw/s390x/s390-virtio-ccw.h |  1 -
>  hw/s390x/s390-pci-kvm.c|  4 +---
>  hw/s390x/s390-virtio-ccw.c | 29 +
>  util/qemu-config.c |  4 
>  qemu-options.hx|  8 +---
>  5 files changed, 7 insertions(+), 39 deletions(-)
> 

[PATCH v2] migration: check magic value for deciding the mapping of channels

[manish.mishra]

Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connection established on the source side it can be in the pending state on
the destination side and a newer connection can be established first.
Basically causing out of order mapping of channels on the destination side.
Currently, all channels except post-copy preempt send a magic number, this
patch uses that magic number to decide the type of channel. This logic is
applicable only for precopy(multifd) live migration, as mentioned, the
post-copy preempt channel does not send any magic number. Also, tls live
migrations already does tls handshake before creating other channels, so
this issue is not possible with tls, hence this logic is avoided for tls
live migrations. This patch uses MSG_PEEK to check the magic number of
channels so that current data/control stream management remains
un-effected.

Suggested-by: Daniel P. Berrangé 
Signed-off-by: manish.mishra 

v2:
  TLS does not support MSG_PEEK, so V1 was broken for tls live
  migrations. For tls live migration, while initializing main channel
  tls handshake is done before we can create other channels, so this
  issue is not possible for tls live migrations. In V2 added a check
  to avoid checking magic number for tls live migration and fallback
  to older method to decide mapping of channels on destination side.
---
 include/io/channel.h | 25 +++
 io/channel-socket.c  | 27 
 io/channel.c | 39 +++
 migration/migration.c| 44 +---
 migration/multifd.c  | 12 ---
 migration/multifd.h  |  2 +-
 migration/postcopy-ram.c |  5 +
 migration/postcopy-ram.h |  2 +-
 8 files changed, 130 insertions(+), 26 deletions(-)

diff --git a/include/io/channel.h b/include/io/channel.h
index c680ee7480..74177aeeea 100644
--- a/include/io/channel.h
+++ b/include/io/channel.h
@@ -115,6 +115,10 @@ struct QIOChannelClass {
 int **fds,
 size_t *nfds,
 Error **errp);
+ssize_t (*io_read_peek)(QIOChannel *ioc,
+void *buf,
+size_t nbytes,
+Error **errp);
 int (*io_close)(QIOChannel *ioc,
 Error **errp);
 GSource * (*io_create_watch)(QIOChannel *ioc,
@@ -475,6 +479,27 @@ int qio_channel_write_all(QIOChannel *ioc,
   size_t buflen,
   Error **errp);
 
+/**
+ * qio_channel_read_peek_all:
+ * @ioc: the channel object
+ * @buf: the memory region to read in data
+ * @nbytes: the number of bytes to read
+ * @errp: pointer to a NULL-initialized error object
+ *
+ * Read given @nbytes data from peek of channel into
+ * memory region @buf.
+ *
+ * The function will be blocked until read size is
+ * equal to requested size.
+ *
+ * Returns: 1 if all bytes were read, 0 if end-of-file
+ *  occurs without data, or -1 on error
+ */
+int qio_channel_read_peek_all(QIOChannel *ioc,
+  void* buf,
+  size_t nbytes,
+  Error **errp);
+
 /**
  * qio_channel_set_blocking:
  * @ioc: the channel object
diff --git a/io/channel-socket.c b/io/channel-socket.c
index b76dca9cc1..b99f5dfda6 100644
--- a/io/channel-socket.c
+++ b/io/channel-socket.c
@@ -705,6 +705,32 @@ static ssize_t qio_channel_socket_writev(QIOChannel *ioc,
 }
 #endif /* WIN32 */
 
+static ssize_t qio_channel_socket_read_peek(QIOChannel *ioc,
+void *buf,
+size_t nbytes,
+Error **errp)
+{
+QIOChannelSocket *sioc = QIO_CHANNEL_SOCKET(ioc);
+ssize_t bytes = 0;
+
+retry:
+bytes = recv(sioc->fd, buf, nbytes, MSG_PEEK);
+
+if (bytes < 0) {
+if (errno == EINTR) {
+goto retry;
+}
+if (errno == EAGAIN) {
+return QIO_CHANNEL_ERR_BLOCK;
+}
+
+error_setg_errno(errp, errno,
+ "Unable to read from peek of socket");
+return -1;
+}
+
+return bytes;
+}
 
 #ifdef QEMU_MSG_ZEROCOPY
 static int qio_channel_socket_flush(QIOChannel *ioc,
@@ -902,6 +928,7 @@ static void qio_channel_socket_class_init(ObjectClass 
*klass,
 
 ioc_klass->io_writev = qio_channel_socket_writev;
 ioc_klass->io_readv = qio_channel_socket_readv;
+ioc_klass->io_read_peek = qio_channel_socket_read_peek;
 ioc_klass->io_set_blocking = qio_channel_socket_set_blocking;
 ioc_klass->io_close = qio_channel_socket_close;
 ioc_klass->io_shutdown = qio_channel_socket_shutdown

Re: [RFC PATCH] tests/docker: allow user to override check target

[Philippe Mathieu-Daudé]

On 7/11/22 15:52, Alex Bennée wrote:

This is useful when trying to bisect a particular failing test behind
a docker run. For example:

   make docker-test-clang@fedora \
 TARGET_LIST=arm-softmmu \
 CHECK_TARGET="meson test qtest-arm/qos-test" \
 J=9 V=1

Signed-off-by: Alex Bennée 
---
  tests/docker/Makefile.include | 2 ++
  tests/docker/common.rc| 6 +++---
  2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index c87f14477a..ece0aa77df 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -184,6 +184,7 @@ docker:
@echo 'TARGET_LIST=a,b,cOverride target list in builds.'
@echo 'EXTRA_CONFIGURE_OPTS="..."'
@echo ' Extra configure options.'
+   @echo 'CHECK_TARGET="..."   Override the default `make check` 
target '


s/target /target./


@echo 'IMAGES="a b c ..":   Restrict available images to subset.'
@echo 'TESTS="x y z .." Restrict available tests to subset.'
@echo 'J=[0..9]*Overrides the -jN parameter for make 
commands'
@@ -230,6 +231,7 @@ docker-run: docker-qemu-src
$(if $(NETWORK),$(if $(subst 
$(NETWORK),,1),--net=$(NETWORK)),--net=none) \
-e TARGET_LIST=$(subst 
$(SPACE),$(COMMA),$(TARGET_LIST))\
-e EXTRA_CONFIGURE_OPTS="$(EXTRA_CONFIGURE_OPTS)" \
+   -e CHECK_TARGET="$(CHECK_TARGET)" \
-e V=$V -e J=$J -e DEBUG=$(DEBUG)   \
-e SHOW_ENV=$(SHOW_ENV) \
$(if $(NOUSER),,\
diff --git a/tests/docker/common.rc b/tests/docker/common.rc
index e6f8cee0d6..f2769c1ff6 100755
--- a/tests/docker/common.rc
+++ b/tests/docker/common.rc
@@ -63,12 +63,12 @@ check_qemu()
  {
  # default to make check unless the caller specifies
  if [ $# = 0 ]; then
-INVOCATION="check"
+INVOCATION="${CHECK_TARGET:-make $MAKEFLAGS check}"


Why pass MAKEFLAGS here?


  else
-INVOCATION="$@"
+INVOCATION="make $MAKEFLAGS $@"
  fi
  
-make $MAKEFLAGS $INVOCATION

+$INVOCATION
  }
  
  test_fail()

Re: [PATCH v2] hw/acpi: fix breakage due to missing aml stub definitions when acpi is off

[Philippe Mathieu-Daudé]

On 7/11/22 16:27, Ani Sinha wrote:

Some HW architectures do not support acpi and CONFIG_ACPI is off for them. For
those architectures, dummy stub function definitions help to resolve symbols.
This change adds couple of dummy stub definitions so that symbols for those can
be resolved and failures such as the following can be fixed for or1k targets.

Configuration:
qemu/build $ ../configure --enable-werror --disable-docs --disable-nettle \
  --enable-gcrypt --enable-fdt=system --enable-modules \
  --enable-trace-backends=dtrace --enable-docs \
 --enable-vfio-user-server \
  --target-list="ppc64-softmmu or1k-softmmu s390x-softmmu 
x86_64-softmmu
  rx-softmmu sh4-softmmu nios2-softmmu"

actual failure:

qemu/build $ QTEST_QEMU_BINARY=./qemu-system-or1k  ./tests/qtest/qos-test

failed to open module:
/build/qemu/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
undefined symbol: aml_return
qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
NULL' failed.
Broken pipe
../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
signal 6 (Aborted) (core dumped)
Aborted (core dumped)

CC: Bernhard Beschow 
Signed-off-by: Ani Sinha 
---
  hw/acpi/aml-build-stub.c | 10 ++
  1 file changed, 10 insertions(+)

changelog:
v2: cosmetic commit description format update.

diff --git a/hw/acpi/aml-build-stub.c b/hw/acpi/aml-build-stub.c
index 8d8ad1a314..89a8fec4af 100644
--- a/hw/acpi/aml-build-stub.c
+++ b/hw/acpi/aml-build-stub.c
@@ -26,6 +26,16 @@ void aml_append(Aml *parent_ctx, Aml *child)
  {
  }
  
+Aml *aml_return(Aml *val)

+{
+return NULL;


Can't return NULL, otherwise aml_append() will crash.

We just want the symbol to be defined, so instead:

  g_assert_not_reached();


+}

Re: [PATCH v3 0/7] memory: prevent dma-reentracy issues

[Alexander Bulekov]

On 221028 1516, Alexander Bulekov wrote:
> These patches aim to solve two types of DMA-reentrancy issues:
> 
> 1.) mmio -> dma -> mmio case
> To solve this, we track whether the device is engaged in io by
> checking/setting a flag within APIs used for MMIO access.
> 
> 2.) bh -> dma write -> mmio case
> This case is trickier, since we dont have a generic way to associate a
> bh with the underlying Device/DeviceState. Thus, this version introduces
> a change to QEMU's DMA APIs to associate each request with the
> origiantor DeviceState. In total, the affected APIs are used in
> approximately 250 locations:
> 
> dma_memory_valid (1 usage)
> dma_memory_rw (~5 uses)
> dma_memory_read (~92 uses)
> dma_memory_write (~71 uses)
> dma_memory_set (~4 uses)
> dma_memory_map (~18 uses)
> dma_memory_unmap (~21 uses)
> {ld,st}_{le,be}_{uw,l,q}_dma (~10 uses)
> ldub_dma (does not appear to be used anywhere)
> stb_dma (1 usage)
> dma_buf_read (~18 uses)
> dma_buf_write (~7 uses)
> 
> It is not trivial to mechanically replace all of the invocations:
> For many cases, this will be as simple as adding DEVICE(s) to the
> arguments, but there are locations where the code will need to be
> slightly changed. As such, for now I added "_guarded" versions of most
> of the APIs which can be used until all of the invocations are fixed.
> 
> The end goal is to go through all of hw/ and make the required changes
> (I will need help with this). Once that is done, the "_guarded" APIs can
> take the place of the standard DMA APIs and we can mecahnically remove
> the "_guarded" suffix from all invocations.
> 
> These changes do not address devices that bypass DMA apis and directly
> call into address_space.. APIs. This occurs somewhat commonly, and
> prevents me from fixing issues in Virtio devices, such as:
> https://gitlab.com/qemu-project/qemu/-/issues/827
> I'm not sure what approach we should take for these cases - maybe they
> should be switched to DMA APIs (or the DMA API expanded).
> 
> v2 -> v3: Bite the bullet and modify the DMA APIs, rather than
> attempting to guess DeviceStates in BHs.
> 
> Alexander Bulekov (7):
>   memory: associate DMA accesses with the initiator Device
>   dma-helpers: switch to guarded DMA accesses
>   ahci: switch to guarded DMA acccesses
>   sdhci: switch to guarded DMA accesses
>   ehci: switch to guarded DMA accesses
>   xhci: switch to guarded DMA accesses
>   usb/libhw: switch to guarded DMA accesses
> 
>  hw/ide/ahci.c  | 16 +---
>  hw/sd/sdhci.c  | 43 ++
>  hw/usb/hcd-ehci.c  |  8 
>  hw/usb/hcd-xhci.c  | 24 +++
>  hw/usb/libhw.c |  4 ++--
>  include/hw/qdev-core.h |  2 ++
>  include/sysemu/dma.h   | 41 
>  softmmu/dma-helpers.c  | 15 ---
>  softmmu/memory.c   | 15 +++
>  softmmu/trace-events   |  1 +
>  10 files changed, 117 insertions(+), 52 deletions(-)
> 
> -- 
> 2.27.0
>

ping

Re: [PATCH v2] hw/acpi: fix breakage due to missing aml stub definitions when acpi is off

[Michael S. Tsirkin]

On Mon, Nov 07, 2022 at 06:08:49PM +0100, Philippe Mathieu-Daudé wrote:
> On 7/11/22 16:27, Ani Sinha wrote:
> > Some HW architectures do not support acpi and CONFIG_ACPI is off for them. 
> > For
> > those architectures, dummy stub function definitions help to resolve 
> > symbols.
> > This change adds couple of dummy stub definitions so that symbols for those 
> > can
> > be resolved and failures such as the following can be fixed for or1k 
> > targets.
> > 
> > Configuration:
> > qemu/build $ ../configure --enable-werror --disable-docs --disable-nettle \
> >   --enable-gcrypt --enable-fdt=system --enable-modules \
> >   --enable-trace-backends=dtrace --enable-docs \
> >  --enable-vfio-user-server \
> >   --target-list="ppc64-softmmu or1k-softmmu s390x-softmmu 
> > x86_64-softmmu
> >   rx-softmmu sh4-softmmu nios2-softmmu"
> > 
> > actual failure:
> > 
> > qemu/build $ QTEST_QEMU_BINARY=./qemu-system-or1k  ./tests/qtest/qos-test
> > 
> > failed to open module:
> > /build/qemu/qemu/build/qemu-bundle/usr/local/lib64/qemu/hw-display-virtio-vga.so:
> > undefined symbol: aml_return
> > qemu-system-or1k: ../util/error.c:59: error_setv: Assertion `*errp ==
> > NULL' failed.
> > Broken pipe
> > ../tests/qtest/libqtest.c:188: kill_qemu() detected QEMU death from
> > signal 6 (Aborted) (core dumped)
> > Aborted (core dumped)
> > 
> > CC: Bernhard Beschow 
> > Signed-off-by: Ani Sinha 
> > ---
> >   hw/acpi/aml-build-stub.c | 10 ++
> >   1 file changed, 10 insertions(+)
> > 
> > changelog:
> > v2: cosmetic commit description format update.
> > 
> > diff --git a/hw/acpi/aml-build-stub.c b/hw/acpi/aml-build-stub.c
> > index 8d8ad1a314..89a8fec4af 100644
> > --- a/hw/acpi/aml-build-stub.c
> > +++ b/hw/acpi/aml-build-stub.c
> > @@ -26,6 +26,16 @@ void aml_append(Aml *parent_ctx, Aml *child)
> >   {
> >   }
> > +Aml *aml_return(Aml *val)
> > +{
> > +return NULL;
> 
> Can't return NULL, otherwise aml_append() will crash.

This is what rest of functions do.

> We just want the symbol to be defined, so instead:
> 
>   g_assert_not_reached();
> 
> > +}

NULL derefs are actually somewhat easier to debug than asserts.

-- 
MST

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Andrew Jones]

On Mon, Nov 07, 2022 at 04:19:10PM +, Daniel P. Berrangé wrote:
> On Mon, Nov 07, 2022 at 03:50:44PM +, Alex Bennée wrote:
> > 
> > Sunil V L  writes:
> > 
> > > On Mon, Nov 07, 2022 at 01:06:38PM +, Peter Maydell wrote:
> > >> On Mon, 7 Nov 2022 at 13:03, Sunil V L  wrote:
> > >> >
> > >> > The pflash implementation currently assumes fixed size of the
> > >> > backend storage. Due to this, the backend storage file needs to be
> > >> > exactly of size 32M. Otherwise, there will be an error like below.
> > >> >
> > >> > "device requires 33554432 bytes, block backend provides 4194304 bytes"
> > >> >
> > >> > Fix this issue by using the actual size of the backing store.
> > >> >
> > >> > Signed-off-by: Sunil V L 
> > >> > ---
> > >> 
> > >> Do you really want the flash device size presented to the guest
> > >> to be variable depending on what the user passed as a block backend?
> > >> I don't think this is how we handle flash devices on other boards...
> > >> 
> > >
> > > Hi Peter,
> > >
> > > x86 appears to support variable flash but arm doesn't. What is
> > > the reason for not supporting variable size flash in arm?
> > 
> > If I recall from the last time we went around this is was the question
> > of what you should pad it with.
> 
> Padding is a very good thing from the POV of upgrades. Firmware has shown
> a tendancy to change (grow) over time, and the size has an impact of the
> guest ABI/live migration state.
> 
> To be able to live migrate, or save/restore to/from files, then the machine
> firmware size needs to be sufficient to cope with future size changes of
> the firmware. The best way to deal with this is to not use the firmware
> binaries' minimum compiled size, but instead to pad it upto a higher
> boundary.
> 
> Enforcing such padding is a decent way to prevent users from inadvertantly
> painting themselves into a corner with a very specific firmware binary
> size at initial boot.

Padding is a good idea, but too much causes other problems. When building
lightweight VMs which may pull the firmware image from a network,
AArch64 VMs require 64MB of mostly zeros to be transferred first, which
can become a substantial amount of the overall boot time[*]. Being able to
create images smaller than the total flash device size, but still add some
pad for later growth, seems like the happy-medium to shoot for.

[*] My web searching skills are failing me at the moment, but I recall
seeing a BZ or gitlab/github issue specifically pointing out the AArch64
64MB firmware size as a pain point.

Thanks,
drew

Re: [PULL v2 31/82] vhost: Change the sequence of device start

[Christian A. Ehrhardt]

On Mon, Nov 07, 2022 at 08:30:32AM -0500, Michael S. Tsirkin wrote:
> On Sun, Nov 06, 2022 at 07:00:33PM +0100, Christian A. Ehrhardt wrote:
> > 
> > Hi,
> > 
> > On Sat, Nov 05, 2022 at 12:43:05PM -0400, Michael S. Tsirkin wrote:
> > > On Sat, Nov 05, 2022 at 05:35:57PM +0100, Bernhard Beschow wrote:
> > > > 
> > > > 
> > > > On Wed, Nov 2, 2022 at 5:24 PM Michael S. Tsirkin  
> > > > wrote:
> > > > 
> > > > From: Yajun Wu 
> > > > 
> > > > This patch is part of adding vhost-user vhost_dev_start support. The
> > > > motivation is to improve backend configuration speed and reduce live
> > > > migration VM downtime.
> > > > 
> > > > Moving the device start routines after finishing all the necessary 
> > > > device
> > > > and VQ configuration, further aligning to the virtio specification 
> > > > for
> > > > "device initialization sequence".
> > > > 
> > > > Following patch will add vhost-user vhost_dev_start support.
> > > > 
> > > > Signed-off-by: Yajun Wu 
> > > > Acked-by: Parav Pandit 
> > > > 
> > > > Message-Id: <20221017064452.1226514-2-yaj...@nvidia.com>
> > > > Reviewed-by: Michael S. Tsirkin 
> > > > Signed-off-by: Michael S. Tsirkin 
> > > > ---
> > > >  hw/block/vhost-user-blk.c | 18 +++---
> > > >  hw/net/vhost_net.c        | 12 ++--
> > > >  2 files changed, 17 insertions(+), 13 deletions(-)
> > > > 
> > > > 
> > > > A git bisect tells me that this is the first bad commit for failing 
> > > > qos-tests
> > > > which only fail when parallel jobs are enabled, e.g. `make check-qtest 
> > > > -j8`:
> > 
> > Parallel test run is not required provided that the test machine is
> > sufficiently busy (load > number of CPU threads). In this case a single
> > invocation of the qos test will fail reliably with this change.
> > 
> > However, the change is not really the root cause of the failures.
> > 
> > > > Summary of Failures:
> > > > 
> > > >  76/541 qemu:qtest+qtest-aarch64 / qtest-aarch64/qos-test               
> > > >        
> > > >   ERROR          18.68s   killed by signal 6 SIGABRT
> > > >  77/541 qemu:qtest+qtest-arm / qtest-arm/qos-test                       
> > > >        
> > > >   ERROR          17.60s   killed by signal 6 SIGABRT
> > > >  93/541 qemu:qtest+qtest-i386 / qtest-i386/qos-test                     
> > > >        
> > > >   ERROR          18.98s   killed by signal 6 SIGABRT
> > > > 108/541 qemu:qtest+qtest-ppc64 / qtest-ppc64/qos-test                   
> > > >        
> > > >   ERROR          16.40s   killed by signal 6 SIGABRT
> > > > 112/541 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test             
> > > >        
> > > >   ERROR          145.94s   killed by signal 6 SIGABRT
> > > > 130/541 qemu:qtest+qtest-x86_64 / qtest-x86_64/qos-test                 
> > > >        
> > > >   ERROR          17.32s   killed by signal 6 SIGABRT
> > > > 243/541 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test         
> > > >        
> > > >   ERROR          127.70s   killed by signal 6 SIGABRT
> > > > 
> > > > Ok:                 500
> > > > Expected Fail:      0  
> > > > Fail:               7  
> > > > Unexpected Pass:    0  
> > > > Skipped:            34  
> > > > Timeout:            0  
> > > > 
> > > > Can anyone else reproduce this?
> > > 
> > > Could you pls try latest for_upstream in my tree?
> > > That should have this fixed.
> > 
> > Your new pull request simply drops this change and this does fix
> > make check-qtest. However, this looks accidental to me and the real
> > bug is there in plain origin/master, too.
> > 
> > What happens is this backtrace a recursive call to vu_gpio_stop
> > via the backtrace below. It is caused by a delayed of the TCP
> > connection (the delayed part only triggers with heavy load on the
> > machine).
> > 
> > You can get the failure back (probably in upstream) if the test is
> > forced to us "use-started=off" which can be set on the command line.
> > E.g. like this:
> > 
> > diff --git a/tests/qtest/libqos/virtio-gpio.c 
> > b/tests/qtest/libqos/virtio-gpio.c
> > index 762aa6695b..17c6b71e8b 100644
> > --- a/tests/qtest/libqos/virtio-gpio.c
> > +++ b/tests/qtest/libqos/virtio-gpio.c
> > @@ -154,14 +154,14 @@ static void virtio_gpio_register_nodes(void)
> >  QOSGraphEdgeOptions edge_opts = { };
> > 
> >  /* vhost-user-gpio-device */
> > -edge_opts.extra_device_opts = "id=gpio0,chardev=chr-vhost-user-test";
> > +edge_opts.extra_device_opts = 
> > "id=gpio0,chardev=chr-vhost-user-test,use-started=off";
> >  qos_node_create_driver("vhost-user-gpio-device",
> >  virtio_gpio_device_create);
> >  qos_node_consumes("vhost-user-gpio-device", "virtio-bus", &edge_opts);
> >  qos_node_produces("vhost-user-gpio-device", "vhost-user-gpio");
> > 
> >  /* virtio-gpio-pci */
> > -edge_opts.extra_device_opts = 
> > "id=gpio0,addr=04.0,chardev=chr-vhost-user-test";
> > +edge_opts.extra_device_opt

Re: [PATCH V2] hw/riscv: virt: Remove size restriction for pflash

[Daniel P . Berrangé]

On Mon, Nov 07, 2022 at 06:32:01PM +0100, Andrew Jones wrote:
> On Mon, Nov 07, 2022 at 04:19:10PM +, Daniel P. Berrangé wrote:
> > On Mon, Nov 07, 2022 at 03:50:44PM +, Alex Bennée wrote:
> > > 
> > > Sunil V L  writes:
> > > 
> > > > On Mon, Nov 07, 2022 at 01:06:38PM +, Peter Maydell wrote:
> > > >> On Mon, 7 Nov 2022 at 13:03, Sunil V L  
> > > >> wrote:
> > > >> >
> > > >> > The pflash implementation currently assumes fixed size of the
> > > >> > backend storage. Due to this, the backend storage file needs to be
> > > >> > exactly of size 32M. Otherwise, there will be an error like below.
> > > >> >
> > > >> > "device requires 33554432 bytes, block backend provides 4194304 
> > > >> > bytes"
> > > >> >
> > > >> > Fix this issue by using the actual size of the backing store.
> > > >> >
> > > >> > Signed-off-by: Sunil V L 
> > > >> > ---
> > > >> 
> > > >> Do you really want the flash device size presented to the guest
> > > >> to be variable depending on what the user passed as a block backend?
> > > >> I don't think this is how we handle flash devices on other boards...
> > > >> 
> > > >
> > > > Hi Peter,
> > > >
> > > > x86 appears to support variable flash but arm doesn't. What is
> > > > the reason for not supporting variable size flash in arm?
> > > 
> > > If I recall from the last time we went around this is was the question
> > > of what you should pad it with.
> > 
> > Padding is a very good thing from the POV of upgrades. Firmware has shown
> > a tendancy to change (grow) over time, and the size has an impact of the
> > guest ABI/live migration state.
> > 
> > To be able to live migrate, or save/restore to/from files, then the machine
> > firmware size needs to be sufficient to cope with future size changes of
> > the firmware. The best way to deal with this is to not use the firmware
> > binaries' minimum compiled size, but instead to pad it upto a higher
> > boundary.
> > 
> > Enforcing such padding is a decent way to prevent users from inadvertantly
> > painting themselves into a corner with a very specific firmware binary
> > size at initial boot.
> 
> Padding is a good idea, but too much causes other problems. When building
> lightweight VMs which may pull the firmware image from a network,
> AArch64 VMs require 64MB of mostly zeros to be transferred first, which
> can become a substantial amount of the overall boot time[*]. Being able to
> create images smaller than the total flash device size, but still add some
> pad for later growth, seems like the happy-medium to shoot for.

QEMU configures the firmware using -blockdev, so can use any file
format that QEMU supports at the block layer.  IOW, you can store
the firmware in a qcow2 file and thus you will never fetch any
of the padding zeros to be transferred.  That said I'm not sure
that libvirt supports anything other than a raw file today. 

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/3] net: Move the code to collect available NIC models to a separate function

[Alex Bennée]

Thomas Huth  writes:

> The code that collects the available NIC models is not really specific
> to PCI anymore and will be required in the next patch, too, so let's
> move this into a new separate function in net.c instead.
>
> Signed-off-by: Thomas Huth 
> ---
>  include/net/net.h |  1 +
>  hw/pci/pci.c  | 29 +
>  net/net.c | 36 
>  3 files changed, 38 insertions(+), 28 deletions(-)
>
> diff --git a/include/net/net.h b/include/net/net.h
> index 3db75ff841..c96cefb89a 100644
> --- a/include/net/net.h
> +++ b/include/net/net.h
> @@ -189,6 +189,7 @@ void qemu_set_vnet_hdr_len(NetClientState *nc, int len);
>  int qemu_set_vnet_le(NetClientState *nc, bool is_le);
>  int qemu_set_vnet_be(NetClientState *nc, bool is_be);
>  void qemu_macaddr_default_if_unset(MACAddr *macaddr);
> +GPtrArray *qemu_get_nic_models(const char *device_type);
>  int qemu_show_nic_models(const char *arg, const char *const *models);
>  void qemu_check_nic_model(NICInfo *nd, const char *model);
>  int qemu_find_nic_model(NICInfo *nd, const char * const *models,
> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
> index 2f450f6a72..2b7b343e82 100644
> --- a/hw/pci/pci.c
> +++ b/hw/pci/pci.c
> @@ -1964,7 +1964,6 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
> *rootbus,
> const char *default_devaddr)
>  {
>  const char *devaddr = nd->devaddr ? nd->devaddr : default_devaddr;
> -GSList *list;
>  GPtrArray *pci_nic_models;
>  PCIBus *bus;
>  PCIDevice *pci_dev;
> @@ -1979,33 +1978,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
> *rootbus,
>  nd->model = g_strdup("virtio-net-pci");
>  }
>  
> -list = object_class_get_list_sorted(TYPE_PCI_DEVICE, false);
> -pci_nic_models = g_ptr_array_new();
> -while (list) {
> -DeviceClass *dc = OBJECT_CLASS_CHECK(DeviceClass, list->data,
> - TYPE_DEVICE);
> -GSList *next;
> -if (test_bit(DEVICE_CATEGORY_NETWORK, dc->categories) &&
> -dc->user_creatable) {
> -const char *name = object_class_get_name(list->data);
> -/*
> - * A network device might also be something else than a NIC, see
> - * e.g. the "rocker" device. Thus we have to look for the 
> "netdev"
> - * property, too. Unfortunately, some devices like virtio-net 
> only
> - * create this property during instance_init, so we have to 
> create
> - * a temporary instance here to be able to check it.
> - */
> -Object *obj = object_new_with_class(OBJECT_CLASS(dc));
> -if (object_property_find(obj, "netdev")) {
> -g_ptr_array_add(pci_nic_models, (gpointer)name);
> -}
> -object_unref(obj);
> -}
> -next = list->next;
> -g_slist_free_1(list);
> -list = next;
> -}
> -g_ptr_array_add(pci_nic_models, NULL);
> +pci_nic_models = qemu_get_nic_models(TYPE_PCI_DEVICE);
>  
>  if (qemu_show_nic_models(nd->model, (const char 
> **)pci_nic_models->pdata)) {
>  exit(0);
> diff --git a/net/net.c b/net/net.c
> index 840ad9dca5..c0516a8067 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -899,6 +899,42 @@ static int nic_get_free_idx(void)
>  return -1;
>  }
>  
> +GPtrArray *qemu_get_nic_models(const char *device_type)
> +{
> +GPtrArray *nic_models;
> +GSList *list;
> +
> +list = object_class_get_list_sorted(device_type, false);
> +nic_models = g_ptr_array_new();
> +while (list) {
> +DeviceClass *dc = OBJECT_CLASS_CHECK(DeviceClass, list->data,
> + TYPE_DEVICE);
> +GSList *next;
> +if (test_bit(DEVICE_CATEGORY_NETWORK, dc->categories) &&
> +dc->user_creatable) {
> +const char *name = object_class_get_name(list->data);
> +/*
> + * A network device might also be something else than a NIC, see
> + * e.g. the "rocker" device. Thus we have to look for the 
> "netdev"
> + * property, too. Unfortunately, some devices like virtio-net 
> only
> + * create this property during instance_init, so we have to 
> create
> + * a temporary instance here to be able to check it.
> + */
> +Object *obj = object_new_with_class(OBJECT_CLASS(dc));
> +if (object_property_find(obj, "netdev")) {
> +g_ptr_array_add(nic_models, (gpointer)name);
> +}
> +object_unref(obj);
> +}
> +next = list->next;
> +g_slist_free_1(list);
> +list = next;
> +}
> +g_ptr_array_add(nic_models, NULL);
> +
> +return nic_models;
> +}

Is it worth freeing as you go and playing the next/list dance when you
could just:

  GPtrArray *qemu_get_nic_models(const char *device_type)

Re: [RFC PATCH] tests/docker: allow user to override check target

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> On 7/11/22 15:52, Alex Bennée wrote:
>> This is useful when trying to bisect a particular failing test behind
>> a docker run. For example:
>>make docker-test-clang@fedora \
>>  TARGET_LIST=arm-softmmu \
>>  CHECK_TARGET="meson test qtest-arm/qos-test" \
>>  J=9 V=1
>> Signed-off-by: Alex Bennée 
>> ---
>>   tests/docker/Makefile.include | 2 ++
>>   tests/docker/common.rc| 6 +++---
>>   2 files changed, 5 insertions(+), 3 deletions(-)
>> diff --git a/tests/docker/Makefile.include
>> b/tests/docker/Makefile.include
>> index c87f14477a..ece0aa77df 100644
>> --- a/tests/docker/Makefile.include
>> +++ b/tests/docker/Makefile.include
>> @@ -184,6 +184,7 @@ docker:
>>  @echo 'TARGET_LIST=a,b,cOverride target list in builds.'
>>  @echo 'EXTRA_CONFIGURE_OPTS="..."'
>>  @echo ' Extra configure options.'
>> +@echo 'CHECK_TARGET="..."   Override the default `make check` 
>> target '
>
> s/target /target./
>
>>  @echo 'IMAGES="a b c ..":   Restrict available images to subset.'
>>  @echo 'TESTS="x y z .." Restrict available tests to subset.'
>>  @echo 'J=[0..9]*Overrides the -jN parameter for make 
>> commands'
>> @@ -230,6 +231,7 @@ docker-run: docker-qemu-src
>>  $(if $(NETWORK),$(if $(subst 
>> $(NETWORK),,1),--net=$(NETWORK)),--net=none) \
>>  -e TARGET_LIST=$(subst 
>> $(SPACE),$(COMMA),$(TARGET_LIST))\
>>  -e EXTRA_CONFIGURE_OPTS="$(EXTRA_CONFIGURE_OPTS)" \
>> +-e CHECK_TARGET="$(CHECK_TARGET)"   \
>>  -e V=$V -e J=$J -e DEBUG=$(DEBUG)   \
>>  -e SHOW_ENV=$(SHOW_ENV) \
>>  $(if $(NOUSER),,\
>> diff --git a/tests/docker/common.rc b/tests/docker/common.rc
>> index e6f8cee0d6..f2769c1ff6 100755
>> --- a/tests/docker/common.rc
>> +++ b/tests/docker/common.rc
>> @@ -63,12 +63,12 @@ check_qemu()
>>   {
>>   # default to make check unless the caller specifies
>>   if [ $# = 0 ]; then
>> -INVOCATION="check"
>> +INVOCATION="${CHECK_TARGET:-make $MAKEFLAGS check}"
>
> Why pass MAKEFLAGS here?

That was just preserving previous behaviour. That said I think MAKEFLAGS
only ever has J in it and perhaps for check_qemu we never want to parallise?

>
>>   else
>> -INVOCATION="$@"
>> +INVOCATION="make $MAKEFLAGS $@"
>>   fi
>>   -make $MAKEFLAGS $INVOCATION
>> +$INVOCATION
>>   }
>> test_fail()


-- 
Alex Bennée

Re: [PULL v2 31/82] vhost: Change the sequence of device start

[Michael S. Tsirkin]

On Mon, Nov 07, 2022 at 06:31:00PM +0100, Christian A. Ehrhardt wrote:
> On Mon, Nov 07, 2022 at 08:30:32AM -0500, Michael S. Tsirkin wrote:
> > On Sun, Nov 06, 2022 at 07:00:33PM +0100, Christian A. Ehrhardt wrote:
> > > 
> > > Hi,
> > > 
> > > On Sat, Nov 05, 2022 at 12:43:05PM -0400, Michael S. Tsirkin wrote:
> > > > On Sat, Nov 05, 2022 at 05:35:57PM +0100, Bernhard Beschow wrote:
> > > > > 
> > > > > 
> > > > > On Wed, Nov 2, 2022 at 5:24 PM Michael S. Tsirkin  
> > > > > wrote:
> > > > > 
> > > > > From: Yajun Wu 
> > > > > 
> > > > > This patch is part of adding vhost-user vhost_dev_start support. 
> > > > > The
> > > > > motivation is to improve backend configuration speed and reduce 
> > > > > live
> > > > > migration VM downtime.
> > > > > 
> > > > > Moving the device start routines after finishing all the 
> > > > > necessary device
> > > > > and VQ configuration, further aligning to the virtio 
> > > > > specification for
> > > > > "device initialization sequence".
> > > > > 
> > > > > Following patch will add vhost-user vhost_dev_start support.
> > > > > 
> > > > > Signed-off-by: Yajun Wu 
> > > > > Acked-by: Parav Pandit 
> > > > > 
> > > > > Message-Id: <20221017064452.1226514-2-yaj...@nvidia.com>
> > > > > Reviewed-by: Michael S. Tsirkin 
> > > > > Signed-off-by: Michael S. Tsirkin 
> > > > > ---
> > > > >  hw/block/vhost-user-blk.c | 18 +++---
> > > > >  hw/net/vhost_net.c        | 12 ++--
> > > > >  2 files changed, 17 insertions(+), 13 deletions(-)
> > > > > 
> > > > > 
> > > > > A git bisect tells me that this is the first bad commit for failing 
> > > > > qos-tests
> > > > > which only fail when parallel jobs are enabled, e.g. `make 
> > > > > check-qtest -j8`:
> > > 
> > > Parallel test run is not required provided that the test machine is
> > > sufficiently busy (load > number of CPU threads). In this case a single
> > > invocation of the qos test will fail reliably with this change.
> > > 
> > > However, the change is not really the root cause of the failures.
> > > 
> > > > > Summary of Failures:
> > > > > 
> > > > >  76/541 qemu:qtest+qtest-aarch64 / qtest-aarch64/qos-test             
> > > > >          
> > > > >   ERROR          18.68s   killed by signal 6 SIGABRT
> > > > >  77/541 qemu:qtest+qtest-arm / qtest-arm/qos-test                     
> > > > >          
> > > > >   ERROR          17.60s   killed by signal 6 SIGABRT
> > > > >  93/541 qemu:qtest+qtest-i386 / qtest-i386/qos-test                   
> > > > >          
> > > > >   ERROR          18.98s   killed by signal 6 SIGABRT
> > > > > 108/541 qemu:qtest+qtest-ppc64 / qtest-ppc64/qos-test                 
> > > > >          
> > > > >   ERROR          16.40s   killed by signal 6 SIGABRT
> > > > > 112/541 qemu:qtest+qtest-i386 / qtest-i386/bios-tables-test           
> > > > >          
> > > > >   ERROR          145.94s   killed by signal 6 SIGABRT
> > > > > 130/541 qemu:qtest+qtest-x86_64 / qtest-x86_64/qos-test               
> > > > >          
> > > > >   ERROR          17.32s   killed by signal 6 SIGABRT
> > > > > 243/541 qemu:qtest+qtest-x86_64 / qtest-x86_64/bios-tables-test       
> > > > >          
> > > > >   ERROR          127.70s   killed by signal 6 SIGABRT
> > > > > 
> > > > > Ok:                 500
> > > > > Expected Fail:      0  
> > > > > Fail:               7  
> > > > > Unexpected Pass:    0  
> > > > > Skipped:            34  
> > > > > Timeout:            0  
> > > > > 
> > > > > Can anyone else reproduce this?
> > > > 
> > > > Could you pls try latest for_upstream in my tree?
> > > > That should have this fixed.
> > > 
> > > Your new pull request simply drops this change and this does fix
> > > make check-qtest. However, this looks accidental to me and the real
> > > bug is there in plain origin/master, too.
> > > 
> > > What happens is this backtrace a recursive call to vu_gpio_stop
> > > via the backtrace below. It is caused by a delayed of the TCP
> > > connection (the delayed part only triggers with heavy load on the
> > > machine).
> > > 
> > > You can get the failure back (probably in upstream) if the test is
> > > forced to us "use-started=off" which can be set on the command line.
> > > E.g. like this:
> > > 
> > > diff --git a/tests/qtest/libqos/virtio-gpio.c 
> > > b/tests/qtest/libqos/virtio-gpio.c
> > > index 762aa6695b..17c6b71e8b 100644
> > > --- a/tests/qtest/libqos/virtio-gpio.c
> > > +++ b/tests/qtest/libqos/virtio-gpio.c
> > > @@ -154,14 +154,14 @@ static void virtio_gpio_register_nodes(void)
> > >  QOSGraphEdgeOptions edge_opts = { };
> > > 
> > >  /* vhost-user-gpio-device */
> > > -edge_opts.extra_device_opts = "id=gpio0,chardev=chr-vhost-user-test";
> > > +edge_opts.extra_device_opts = 
> > > "id=gpio0,chardev=chr-vhost-user-test,use-started=off";
> > >  qos_node_create_driver("vhost-user-gpio-device",
> > >  virtio_gpio_device_create);
>

Re: [PATCH v10 1/9] s390x/cpu topology: core_id sets s390x CPU topology

[Janis Schoetterl-Glausch]

On Fri, 2022-10-28 at 11:30 +0200, Pierre Morel wrote:
> 
> On 10/27/22 22:20, Janis Schoetterl-Glausch wrote:
> > On Wed, 2022-10-26 at 10:34 +0200, Pierre Morel wrote:
> > > 
> > > On 10/25/22 21:58, Janis Schoetterl-Glausch wrote:
> > > > On Wed, 2022-10-12 at 18:20 +0200, Pierre Morel wrote:
> > > > > In the S390x CPU topology the core_id specifies the CPU address
> > > > > and the position of the core withing the topology.
> > > > > 
> > > > > Let's build the topology based on the core_id.
> > > > > s390x/cpu topology: core_id sets s390x CPU topology
> > > > > 
> > > > > In the S390x CPU topology the core_id specifies the CPU address
> > > > > and the position of the cpu withing the topology.
> > > > > 
> > > > > Let's build the topology based on the core_id.
> > > > > 
> > > > > Signed-off-by: Pierre Morel 
> > > > > ---
> > > > >include/hw/s390x/cpu-topology.h |  45 +++
> > > > >hw/s390x/cpu-topology.c | 132 
> > > > > 
> > > > >hw/s390x/s390-virtio-ccw.c  |  21 +
> > > > >hw/s390x/meson.build|   1 +
> > > > >4 files changed, 199 insertions(+)
> > > > >create mode 100644 include/hw/s390x/cpu-topology.h
> > > > >create mode 100644 hw/s390x/cpu-topology.c
> > > > > 
> > > > [...]
> > > > 
> > > > > +/**
> > > > > + * s390_topology_realize:
> > > > > + * @dev: the device state
> > > > > + * @errp: the error pointer (not used)
> > > > > + *
> > > > > + * During realize the machine CPU topology is initialized with the
> > > > > + * QEMU -smp parameters.
> > > > > + * The maximum count of CPU TLE in the all Topology can not be 
> > > > > greater
> > > > > + * than the maximum CPUs.
> > > > > + */
> > > > > +static void s390_topology_realize(DeviceState *dev, Error **errp)
> > > > > +{
> > > > > +MachineState *ms = MACHINE(qdev_get_machine());
> > > > > +S390Topology *topo = S390_CPU_TOPOLOGY(dev);
> > > > > +
> > > > > +topo->cpus = ms->smp.cores * ms->smp.threads;
> > > > 
> > > > Currently threads are not supported, effectively increasing the number 
> > > > of cpus,
> > > > so this is currently correct. Once the machine version limits the 
> > > > threads to 1,
> > > > it is also correct. However, once we support multiple threads, this 
> > > > becomes incorrect.
> > > > I wonder if it's ok from a backward compatibility point of view to 
> > > > modify the smp values
> > > > by doing cores *= threads, threads = 1 for old machines.
> > > 
> > > Right, this will become incorrect with thread support.
> > > What about having a dedicated function:
> > > 
> > >   topo->cpus = s390_get_cpus(ms);
> > > 
> > > This function will use the S390CcwMachineClass->max_thread introduced
> > > later to report the correct number of CPUs.
> > 
> > I don't think max_threads is exactly what matters here, it's if
> > threads are supported or not or, if max_threads == 1 it doesn't matter.
> > The question is how best to do the check. You could check the machine 
> > version.
> > I wonder if you could add a feature bit for the multithreading facility 
> > that is
> > always false and use that.
> > 
> > I don't know if using a function makes a difference, that is if it is 
> > obvious on
> > introduction of multithreading support that the function needs to be 
> > updated.
> > (If it is implemented in a way that requires updating, if you check the 
> > machine
> > version it doesn't)
> > In any case, the name you suggested isn't very descriptive.
> 
> I think we care about this machine and olders.
> Olders do not support topology so this, Multithreading (MT) does not mater.
> This machine support topology, if I follow Cedric advise, the 
> "max_thread" will/may be introduce before the topology.
> 
> This in fact is not an implementation for MT or does not allow the 
> implementation of MT it is only a way to get rid of the false 
> information given to the user that we accept MT.
> 
> So I think that when we introduce MT we will take care of making things 
> right at this place as in other places of the code.
> 
> What about we keep the original:
> 
>  topo->cpus = ms->smp.cores * ms->smp.threads;

If topology is only supported for new machines and not the old machines
for which you set max_threads to a compatibility value (max cpus), then
you should just ignore the threads, cpus == cores.
(There might not be any point in keeping a topo->cpus member in this case, I 
haven't checked)
> 
> Which does not do any arm to machines without MT ?
> 
> Regards,
> Pierre
> 

[PATCH] docs/cxl: Fix some typos

[Davidlohr Bueso]

Found while reading the doc.

Signed-off-by: Davidlohr Bueso 
---
 docs/system/devices/cxl.rst | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/system/devices/cxl.rst b/docs/system/devices/cxl.rst
index abf7c1f24305..891bbd65d9d8 100644
--- a/docs/system/devices/cxl.rst
+++ b/docs/system/devices/cxl.rst
@@ -83,7 +83,7 @@ CXL Fixed Memory Windows (CFMW)
 A CFMW consists of a particular range of Host Physical Address space
 which is routed to particular CXL Host Bridges.  At time of generic
 software initialization it will have a particularly interleaving
-configuration and associated Quality of Serice Throtling Group (QTG).
+configuration and associated Quality of Service Throttling Group (QTG).
 This information is available to system software, when making
 decisions about how to configure interleave across available CXL
 memory devices.  It is provide as CFMW Structures (CFMWS) in
@@ -98,7 +98,7 @@ specification defined register interface called CXL Host 
Bridge
 Component Registers (CHBCR). The location of this CHBCR MMIO
 space is described to system software via a CXL Host Bridge
 Structure (CHBS) in the CEDT ACPI table.  The actual interfaces
-are identical to those used for other parts of the CXL heirarchy
+are identical to those used for other parts of the CXL hierarchy
 as CXL Component Registers in PCI BARs.
 
 Interfaces provided include:
@@ -111,7 +111,7 @@ Interfaces provided include:
 
 CXL Root Ports (CXL RP)
 ~~~
-A CXL Root Port servers te same purpose as a PCIe Root Port.
+A CXL Root Port servers the same purpose as a PCIe Root Port.
 There are a number of CXL specific Designated Vendor Specific
 Extended Capabilities (DVSEC) in PCIe Configuration Space
 and associated component register access via PCI bars.
@@ -143,7 +143,7 @@ CXL Memory Devices - Type 3
 ~~~
 CXL type 3 devices use a PCI class code and are intended to be supported
 by a generic operating system driver. They have HDM decoders
-though in these EP devices, the decoder is reponsible not for
+though in these EP devices, the decoder is responsible not for
 routing but for translation of the incoming host physical address (HPA)
 into a Device Physical Address (DPA).
 
@@ -209,7 +209,7 @@ Notes:
 ranges of the system physical address map.  Each CFMW has
 particular interleave setup across the CXL Host Bridges (HB)
 CFMW0 provides uninterleaved access to HB0, CFW2 provides
-uninterleaved acess to HB1. CFW1 provides interleaved memory access
+uninterleaved access to HB1. CFW1 provides interleaved memory access
 across HB0 and HB1.
 
 (2) **Two CXL Host Bridges**. Each of these has 2 CXL Root Ports and
@@ -282,7 +282,7 @@ Example topology involving a switch::
 ---
|Switch 0  USP as PCI 0d:00.0   |
|USP has HDM decoder which direct traffic to|
-   |appropiate downstream port |
+   |appropriate downstream port|
|Switch BUS appears as 0e   |
|x__|
 |  |   |  |
-- 
2.38.0

Re: [PATCH] hw/sd/sdhci: reset data count in sdhci_buff_access_is_sequential()

[Philippe Mathieu-Daudé]

On 7/11/22 11:35, Mauro Matteo Cascella wrote:

Make sure to reset data_count if it's equal to (or exceeds) block_size.
This prevents an off-by-one read / write when accessing s->fifo_buffer
in sdhci_read_dataport / sdhci_write_dataport, both called right after
sdhci_buff_access_is_sequential.

Fixes: CVE-2022-3872
Reported-by: RivenDell 
Reported-by: Siqi Chen 
Reported-by: ningqiang 
Signed-off-by: Mauro Matteo Cascella 
---
  hw/sd/sdhci.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 306070c872..aa2fd79df2 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -978,6 +978,10 @@ static bool sdhci_can_issue_command(SDHCIState *s)
  static inline bool
  sdhci_buff_access_is_sequential(SDHCIState *s, unsigned byte_num)
  {
+if (s->data_count >= (s->blksize & BLOCK_SIZE_MASK)) {
+s->data_count = 0;
+}


You avoid an off-by-one but now the model doesn't work per the spec.
Not really what the best fix IMHO.


  if ((s->data_count & 0x3) != byte_num) {
  trace_sdhci_error("Non-sequential access to Buffer Data Port register"
"is prohibited\n");


I wonder why sdhci_data_transfer() indiscriminately sets
SDHC_SPACE_AVAILABLE in the write path (at least without
clearing the FIFO first).

The fix could be:

-- >8 --
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
@@ -955,5 +955,5 @@ static void sdhci_data_transfer(void *opaque)
 } else {
 s->prnsts |= SDHC_DOING_WRITE | SDHC_DAT_LINE_ACTIVE |
-SDHC_SPACE_AVAILABLE | SDHC_DATA_INHIBIT;
+   SDHC_DATA_INHIBIT;
 sdhci_write_block_to_card(s);
 }
---

Bin, what do you think?

Regards,

Phil.

[PATCH v2] checkpatch: better pattern for inline comments

[Michael S. Tsirkin]

checkpatch is unhappy about this line:

WARNING: Block comments use a leading /* on a separate line
#50: FILE: hw/acpi/nvdimm.c:1074:
+   aml_equal(aml_sizeof(pckg), aml_int(1)) /* 1 element? 
*/));

but there's nothing wrong with it - the check is just too simplistic. It
will also miss lines which mix inline and block comments.

Instead, let's strip all inline comments from a line and then check for block
comments.

Signed-off-by: Michael S. Tsirkin 
---

changes from v1:
indendation fixes (in script itself)

 scripts/checkpatch.pl | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e3e3b43076..bc7d4780ec 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1681,8 +1681,10 @@ sub process {
 # Block comment styles
 
# Block comments use /* on a line of its own
-   if ($rawline !~ m@^\+.*/\*.*\*/[ \t)}]*$@ &&#inline /*...*/
-   $rawline =~ m@^\+.*/\*\*?+[ \t]*[^ \t]@) { # /* or /** 
non-blank
+   my $commentline = $rawline;
+   while ($commentline =~ s@^(\+.*)/\*.*\*/@$1@o) { # remove 
inline #inline /*...*/
+   }
+   if ($commentline =~ m@^\+.*/\*\*?+[ \t]*[^ \t]@) { # /* or /** 
non-blank
WARN("Block comments use a leading /* on a separate 
line\n" . $herecurr);
}
 
-- 
MST

Re: [PULL 00/12] Misc bugfix patches (+ improved module errors) for QEMU 7.2

[Stefan Hajnoczi]

Applied, thanks.

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


signature.asc
Description: PGP signature

Re: [PULL 0/7] Trivial branch for 7.2 patches

[Stefan Hajnoczi]

Applied, thanks.

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


signature.asc
Description: PGP signature