Re: [Bug 1907427] [NEW] Build on sparc64 fails with "undefined reference to `fdt_check_full'"

[Thomas Huth]

On 09/12/2020 10.13, John Paul Adrian Glaubitz wrote:
> Public bug reported:
> 
> Trying to build QEMU on sparc64 fails with:
[...]
> /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function 
> `h_update_dt':
> ./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to 
> `fdt_check_full'
> collect2: error: ld returned 1 exit status
> 
> Full build log available at:
> https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=sparc64&ver=1%3A5.2%2Bdfsg-1&stamp=1607502300&raw=0

Looking at the build log, it seems like your system libfdt is version 1.4.6.
However, that fdt_check_full function is only properly available with
version >= 1.5.1, if I get that right.

As a workaround, you could try to run the configure script with
--enable-fdt=git (or of course update your system version to 1.5.1 if
somehow possible).

But anyway, this also means that the check in the QEMU build system is
likely wrong. But it's weird, I can see that we explicitely test for
fdt_check_full() in the meson.build script, so no clue what's going wrong
here. David, do you have an idea?

 Thomas

Re: [PATCH v12 08/19] multi-process: define MPQemuMsg format and transmission functions

[Marc-André Lureau]

Hi

On Thu, Dec 10, 2020 at 5:42 AM Elena Ufimtseva 
wrote:

> On Mon, Dec 07, 2020 at 05:18:46PM +0400, Marc-André Lureau wrote:
> > Hi
> >
> > On Wed, Dec 2, 2020 at 12:25 AM Jagannathan Raman 
> > wrote:
> >
> > > From: Elena Ufimtseva 
> > >
> > > Defines MPQemuMsg, which is the message that is sent to the remote
> > > process. This message is sent over QIOChannel and is used to
> > > command the remote process to perform various tasks.
> > > Define transmission functions used by proxy and by remote.
> > > There are certain restrictions on where its safe to use these
> > > functions:
> > >   - From main loop in co-routine context. Will block the main loop if
> not
> > > in
> > > co-routine context;
> > >   - From vCPU thread with no co-routine context and if the channel is
> not
> > > part
> > > of the main loop handling;
> > >   - From IOThread within co-routine context, outside of co-routine
> context
> > > will
> > > block IOThread;
> > >
> > > Signed-off-by: Jagannathan Raman 
> > > Signed-off-by: John G Johnson 
> > > Signed-off-by: Elena Ufimtseva 
> > > ---
> > >  include/hw/remote/mpqemu-link.h |  60 ++
> > >  hw/remote/mpqemu-link.c | 242
> > > 
> > >  MAINTAINERS |   2 +
> > >  hw/remote/meson.build   |   1 +
> > >  4 files changed, 305 insertions(+)
> > >  create mode 100644 include/hw/remote/mpqemu-link.h
> > >  create mode 100644 hw/remote/mpqemu-link.c
> > >
> > > diff --git a/include/hw/remote/mpqemu-link.h
> > > b/include/hw/remote/mpqemu-link.h
> > > new file mode 100644
> > > index 000..2d79ff8
> > > --- /dev/null
> > > +++ b/include/hw/remote/mpqemu-link.h
> > > @@ -0,0 +1,60 @@
> > > +/*
> > > + * Communication channel between QEMU and remote device process
> > > + *
> > > + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL, version 2 or
> > > later.
> > > + * See the COPYING file in the top-level directory.
> > > + *
> > > + */
> > > +
> > > +#ifndef MPQEMU_LINK_H
> > > +#define MPQEMU_LINK_H
> > > +
> > > +#include "qom/object.h"
> > > +#include "qemu/thread.h"
> > > +#include "io/channel.h"
> > > +
> > > +#define REMOTE_MAX_FDS 8
> > > +
> > > +#define MPQEMU_MSG_HDR_SIZE offsetof(MPQemuMsg, data.u64)
> > > +
> > > +/**
> > > + * MPQemuCmd:
> > > + *
> > > + * MPQemuCmd enum type to specify the command to be executed on the
> remote
> > > + * device.
> > > + */
> > > +typedef enum {
> > > +MPQEMU_CMD_INIT,
> > > +MPQEMU_CMD_MAX,
> > > +} MPQemuCmd;
> > > +
> > > +/**
> > > + * MPQemuMsg:
> > > + * @cmd: The remote command
> > > + * @size: Size of the data to be shared
> > > + * @data: Structured data
> > > + * @fds: File descriptors to be shared with remote device
> > > + *
> > > + * MPQemuMsg Format of the message sent to the remote device from
> QEMU.
> > > + *
> > > + */
> > > +typedef struct {
> > > +int cmd;
> > > +size_t size;
> > > +
> > > +union {
> > > +uint64_t u64;
> > > +} data;
> > > +
> > > +int fds[REMOTE_MAX_FDS];
> > > +int num_fds;
> > > +} MPQemuMsg;
> > > +
> > > +void mpqemu_msg_send(MPQemuMsg *msg, QIOChannel *ioc, Error **errp);
> > > +void mpqemu_msg_recv(MPQemuMsg *msg, QIOChannel *ioc, Error **errp);
> > > +
> > > +bool mpqemu_msg_valid(MPQemuMsg *msg);
> > > +
> > > +#endif
> > > diff --git a/hw/remote/mpqemu-link.c b/hw/remote/mpqemu-link.c
> > > new file mode 100644
> > > index 000..e535ed2
> > > --- /dev/null
> > > +++ b/hw/remote/mpqemu-link.c
> > > @@ -0,0 +1,242 @@
> > > +/*
> > > + * Communication channel between QEMU and remote device process
> > > + *
> > > + * Copyright © 2018, 2020 Oracle and/or its affiliates.
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL, version 2 or
> > > later.
> > > + * See the COPYING file in the top-level directory.
> > > + *
> > > + */
> > > +
> > > +#include "qemu/osdep.h"
> > > +#include "qemu-common.h"
> > > +
> > > +#include "qemu/module.h"
> > > +#include "hw/remote/mpqemu-link.h"
> > > +#include "qapi/error.h"
> > > +#include "qemu/iov.h"
> > > +#include "qemu/error-report.h"
> > > +#include "qemu/main-loop.h"
> > > +
> > > +/*
> > > + * Send message over the ioc QIOChannel.
> > > + * This function is safe to call from:
> > > + * - From main loop in co-routine context. Will block the main loop if
> > > not in
> > > + *   co-routine context;
> > > + * - From vCPU thread with no co-routine context and if the channel is
> > > not part
> > > + *   of the main loop handling;
> > > + * - From IOThread within co-routine context, outside of co-routine
> > > context
> > > + *   will block IOThread;
> > >
> >
> > Can drop the extra "From" on each line.
> >
> > + */
> > > +void mpqemu_msg_send(MPQemuMsg *msg, QIOChannel *ioc, Error **errp)
> > > +{
> > > +bool iolock = qemu_mutex_iothread_locked();
> > > +bool iothread = qemu_get_current_aio_context() ==
> > > qemu_get_

Re: [PATCH 1/6] spapr: Add an "spapr" property to sPAPR CPU core

[Cédric Le Goater]

On 12/9/20 9:54 PM, Eduardo Habkost wrote:
> On Wed, Dec 09, 2020 at 09:24:36PM +0100, Greg Kurz wrote:
>> On Wed, 9 Dec 2020 13:26:17 -0500
>> Eduardo Habkost  wrote:
>>
>>> On Wed, Dec 09, 2020 at 07:11:40PM +0100, Philippe Mathieu-Daudé wrote:
>>> [...]
 @@ -200,7 +199,7 @@ static void spapr_cpu_core_reset(DeviceState *dev)
  int i;
  
  for (i = 0; i < cc->nr_threads; i++) {
 -spapr_reset_vcpu(sc->threads[i]);
 +spapr_reset_vcpu(sc->threads[i], sc->spapr);
>>>
>>> Why reset() needs access to the machine state, don't
>>> you have it in realize()?
>>>
>>
>> This is for the vCPU threads of the sPAPR CPU core. They don't have the
>> link to the machine state.
>
> They are created by spapr_create_vcpu() + spapr_realize_vcpu() in
> spapr_cpu_core_realize(), which has sc->spapr set... Am I missing
> something?

 Anyhow, from a QOM design point of view, resetfn() is not the correct
 place to set a property IMHO, so Cc'ing Eduardo.
>>>
>>> This patch is not setting the property on resetfn(), it is
>>> setting it on CPU core pre_plug().
>>>
>>> This is more complex than simply using qdev_get_machine() and I
>>> don't see why it would be better, but I don't think it's wrong.
>>>
>>
>> The reference to the machine state is basically needed to
>> setup/reset/teardown interrupt presenters in the IRQ chip
>> backend. It is a bit unfortunate to express this dependency
>> at realize(), reset() and unrealize(). Maybe having an
>> "irq_chip" property linked to the IRQ chip backend would
>> make more sense ?
>>
> 
> Considering that the spapr_irq_*() functions get a
> SpaprMachineState argument and deal with two interrupt
> controllers, maybe you won't be able to save what you need in a
> single irq_chip field?

The sPAPR machine needs to operate on all available interrupt 
controllers and the array is built under the spapr_irq* routines 
with : 

SpaprInterruptController *intcs[] = ALL_INTCS(spapr);

We could add the array under the machine and use a link to that
instead but we need to keep the existing interrupt controllers 
anyway because of migration compatibility.
 
> I don't have a strong opinion here.  It feels weird to me to save
> a reference to the global machine object that is always
> available, but I don't think that's a problem if you believe the
> resulting code looks better.

I think it's a good cleanup to remove globals. QEMU might emulate 
multiple "machines" in a single binary one day.

C.

Re: [PATCH v2 0/4] vhost-user: avoid g_return_val_if() in get/set_config()

[Marc-André Lureau]

Hi Michael,

On Thu, Dec 3, 2020 at 5:41 PM Stefano Garzarella 
wrote:

> On Wed, Dec 02, 2020 at 03:26:07PM +, Stefan Hajnoczi wrote:
> >v2:
> > * Print errors [Marc-André]
> >
> >Markus Armbruster pointed out that g_return_val_if() is meant for
> programming
> >errors. It must not be used for input validation since it can be compiled
> out.
> >Use explicit if statements instead.
> >
> >This patch series converts vhost-user device backends that use
> >g_return_val_if() in get/set_config().
> >
> >Stefan Hajnoczi (4):
> >  contrib/vhost-user-blk: avoid g_return_val_if() input validation
> >  contrib/vhost-user-gpu: avoid g_return_val_if() input validation
> >  contrib/vhost-user-input: avoid g_return_val_if() input validation
> >  block/export: avoid g_return_val_if() input validation
> >
> > block/export/vhost-user-blk-server.c| 6 +-
> > contrib/vhost-user-blk/vhost-user-blk.c | 6 +-
> > contrib/vhost-user-gpu/vhost-user-gpu.c | 6 +-
> > contrib/vhost-user-input/main.c | 6 +-
> > 4 files changed, 20 insertions(+), 4 deletions(-)
> >
> >--
> >2.28.0
> >
>
> Reviewed-by: Stefano Garzarella 
>
>
You didn't collect the v2 patch series, with the received reviewed-by. Not
a big deal here, but please be more careful.

thanks

-- 
Marc-André Lureau

[Bug 1907427] Re: Build on sparc64 fails with "undefined reference to `fdt_check_full'"

[Thomas Huth]

Looking at the build log, it seems like your system libfdt is version 1.4.6.
However, that fdt_check_full function is only properly available with
version >= 1.5.1, if I get that right.

As a workaround, you could try to run the configure script with
--enable-fdt=git (or of course update your system version to 1.5.1 if
somehow possible).

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1907427

Title:
  Build on sparc64 fails with "undefined reference to `fdt_check_full'"

Status in QEMU:
  New

Bug description:
  Trying to build QEMU on sparc64 fails with:

  [4648/8435] c++  -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o 
libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o 
libcommon.fa.p/hw_input_vhost-user-input.c.o 
libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o 
libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o 
libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o 
libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o 
libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o 
libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o 
libcommon.fa.p/hw_display_sm501.c.o 
libcommon.fa.p/hw_net_rocker_rocker_world.c.o 
libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o 
libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o 
libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o 
libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o 
libcommon.fa.p/migration_global_state.c.o 
libcommon.fa.p/backends_rng-random.c.o 
libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o 
libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o 
libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o 
libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o 
libcommon.fa.p/hw_core_qdev-properties-system.c.o 
libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o 
libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o 
libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o 
libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o 
libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o 
libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o 
libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o 
libcommon.fa.p/audio_audio_legacy.c.o
  (...)
  libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro 
-Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong 
libmigration.fa -Wl,--start-group libqemuutil.a 
contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa 
libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa 
@block.syms @qemu.syms 
/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so 
/usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm 
/usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so 
/usr/lib/sparc64-linux-gnu/libslirp.so 
/usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 
-lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so 
@block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so 
/usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug 
/usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil 
-lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm 
-Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle 
-lstdc++ -Wl,--end-group
  /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function 
`h_update_dt':
  ./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to 
`fdt_check_full'
  collect2: error: ld returned 1 exit status

  Full build log available at:
  
https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=sparc64&ver=1%3A5.2%2Bdfsg-1&stamp=1607502300&raw=0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1907427/+subscriptions

Re: [PATCH] smbios: entry-point-type option

[Laszlo Ersek]

On 12/09/20 19:16, Eduardo Habkost wrote:
> On Wed, Dec 09, 2020 at 09:42:25AM +, Daniel P. Berrangé wrote:
>> On Tue, Dec 08, 2020 at 04:20:23PM -0500, Eduardo Habkost wrote:
>>> Add command-line option that lets the SMBIOS entry point type to
>>> be configured.
>>>
>>> SMBIOS 3.0 support is necessary to allow us to support more
>>> than 720 VCPUs in x86_64, due to SMBIOS 2.1 table size limits.
>>>
>>> Note that it's still up to firmware to decide whether to generate
>>> SMBIOS 2.1 and/or 3.0 entry points for the guest, using the
>>> information contained in etc/smbios/smbios-anchor.  OVMF, for
>>> example, is able to generate both entry points, depending on the
>>> value of PcdSmbiosEntryPointProvideMethod.
>>>
>>> The SMBIOS 3.0 entry point won't be enabled by default because it
>>> is not supported yet by Seabios.  This may be changed once
>>> Seabios starts supporting SMBIOS 3.0 entry points.
>>>
>>> Signed-off-by: Eduardo Habkost 
>>> ---
>>> Laszlo, Philippe: do you know how exactly the value of
>>> PcdSmbiosEntryPointProvideMethod is chosen when running OVMF?
>>
>> Laszlo proides alot of detail in my original proposal for
>> selecting SMBIOS entry point here:
>>
>> https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg03347.html
> 
> Thanks!
> 
>>
> [...]
>>> diff --git a/qemu-options.hx b/qemu-options.hx
>>> index 104632ea34..d2a973f8a7 100644
>>> --- a/qemu-options.hx
>>> +++ b/qemu-options.hx
>>> @@ -2294,7 +2294,9 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
>>>  "specify SMBIOS type 11 fields\n"
>>>  "-smbios 
>>> type=17[,loc_pfx=str][,bank=str][,manufacturer=str][,serial=str]\n"
>>>  "   [,asset=str][,part=str][,speed=%d]\n"
>>> -"specify SMBIOS type 17 fields\n",
>>> +"specify SMBIOS type 17 fields\n"
>>> +"-smbios entry-point-type=2.1|3.0\n"
>>> +"specify SMBIOS entry point type\n",
>>
>> My previous patch:
>>
>>   https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg03027.html
>>
>> exposed the entry point version as a property on the PC machine
>> rather than the -smbios arg, principally because it is the machin
>> setup code that currently defines what version is used via the calls
>> to smbios_set_defaults().
>>
>> IIUC from Laszlo's reply,  SMBIOS 2.1 is not valid for AArch64
>> at all - they only support 3.0.  So there's a small benefit from
>> configuring this against the PC machine types, because it prevents
>> ability to select 2.1 for ARM SMBIOS which would be invalid.
> 
> Good point.  It would also make it easier to change the machine
> type default in the future.
> 
> I will submit something based on your patches, instead.
> 

Thank you, Daniel, for finding that write-up; I've got it completely
paged-out by now :) I don't have anything to add here, just confirming
that I've read this thread quickly. Eduardo, if you have questions wrt.
OVMF, please let me know; I'll try to find the time.

Thanks!
Laszlo

[Bug 1900155] Re: MIPS Malta fails booting due to IDE error

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1900155

Title:
  MIPS Malta fails booting due to IDE error

Status in QEMU:
  Fix Released

Bug description:
  As of commit 3e407488349:

  $ avocado --show=console run -t machine:malta 
tests/acceptance/boot_linux_console.py
  console: [0.00] Linux version 4.5.0-2-4kc-malta 
(debian-ker...@lists.debian.org) (gcc version 5.3.1 20160519 (Debian 5.3.1-20) 
) #1 Debian 4.5.5-1 (2016-05-29)
  console: [0.00] earlycon: Early serial console at I/O port 0x3f8 
(options '38400n8')
  console: [0.00] bootconsole [uart0] enabled
  console: [0.00] CPU0 revision is: 00019300 (MIPS 24Kc)
  console: [0.00] FPU revision is: 00739300
  console: [0.00] MIPS: machine is mti,malta
  [...]
  console: ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100
  console: ata2.00: Drive reports diagnostics failure. This may indicate a drive
  console: ata2.00: fault or invalid emulation. Contact drive vendor for 
information.
  console: ata2.00: configured for UDMA/33
  console: scsi 1:0:0:0: CD-ROMQEMU QEMU DVD-ROM 2.5+ PQ: 0 
ANSI: 5
  console: Freeing unused kernel memory: 412K (80979000 - 809e)
  console: do_page_fault(): sending SIGSEGV to mount for invalid write access 
to 0018a000
  console: epc = 775cca54 in libc-2.27.so[775b3000+177000]
  console: ra  = 77754618 in ld-2.27.so[77743000+24000]
  console: do_page_fault(): sending SIGSEGV to klogd for invalid write access 
to 0018a000
  console: epc = 770f0a54 in libc-2.27.so[770d7000+177000]
  console: ra  = 77278618 in ld-2.27.so[77267000+24000]
  console: do_page_fault(): sending SIGSEGV to S20urandom for invalid write 
access to 0018a000
  console: epc = 77d0ca54 in libc-2.27.so[77cf3000+177000]
  console: ra  = 77e94618 in ld-2.27.so[77e83000+24000]
  console: do_page_fault(): sending SIGSEGV to mkdir for invalid write access 
to 0018a000
  console: epc = 776b8a54 in libc-2.27.so[7769f000+177000]
  console: ra  = 77840618 in ld-2.27.so[7782f000+24000]
  console: do_page_fault(): sending SIGSEGV to sh for invalid write access to 
0018a000
  console: epc = 77364a54 in libc-2.27.so[7734b000+177000]
  console: ra  = 774ec618 in ld-2.27.so[774db000+24000]
  console: do_page_fault(): sending SIGSEGV to sh for invalid write access to 
0018a000
  console: epc = 77bd4a54 in libc-2.27.so[77bbb000+177000]
  console: ra  = 77d5c618 in ld-2.27.so[77d4b000+24000]
  console: do_page_fault(): sending SIGSEGV to awk for invalid write access to 
0018a000
  console: epc = 76f44a54 in libc-2.27.so[76f2b000+177000]
  console: ra  = 770cc618 in ld-2.27.so[770bb000+24000]
  console: do_page_fault(): sending SIGSEGV to cat for invalid write access to 
0018a000
  console: epc = 770cca54 in libc-2.27.so[770b3000+177000]
  console: ra  = 77254618 in ld-2.27.so[77243000+24000]
  $ echo $?
  8

  55adb3c45620c31f29978f209e2a44a08d34e2da is the first bad commit
  commit 55adb3c45620c31f29978f209e2a44a08d34e2da
  Author: John Snow 
  Date:   Fri Jul 24 01:23:00 2020 -0400

  ide: cancel pending callbacks on SRST

  The SRST implementation did not keep up with the rest of IDE; it is
  possible to perform a weak reset on an IDE device to remove the BSY/DRQ
  bits, and then issue writes to the control/device registers which can
  cause chaos with the state machine.

  Fix that by actually performing a real reset.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1900155/+subscriptions

[Bug 1881231] Re: colo: Can not recover colo after svm failover twice

[Thomas Huth]

QEMU v5.2 has been released now and should contain the fix

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1881231

Title:
  colo: Can not  recover colo after svm failover twice

Status in QEMU:
  Fix Released

Bug description:
  Hi Expert,
  x-blockdev-change met some error, during testing colo

  Host os:
  CentOS Linux release 7.6.1810 (Core)

  Reproduce steps:
  1. create colo vm following 
https://github.com/qemu/qemu/blob/master/docs/COLO-FT.txt
  2. kill secondary vm and remove the nbd child from the quorum to wait for 
recover
type those commands on primary vm console:
{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 
'child': 'children.1'}}
{ 'execute': 'human-monitor-command','arguments': {'command-line': 
'drive_del replication0'}}
{ 'execute': 'x-colo-lost-heartbeat'}
  3. recover colo
  4. kill secondary vm again after recover colo and type same commands as step 
2:
{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 
'child': 'children.1'}}
{ 'execute': 'human-monitor-command','arguments': {'command-line': 
'drive_del replication0'}}
{ 'execute': 'x-colo-lost-heartbeat'}
but the first command got error
{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'colo-disk0', 
'child': 'children.1'}}
  {"error": {"class": "GenericError", "desc": "Node 'colo-disk0' does not have 
child 'children.1'"}}

  according to https://www.qemu.org/docs/master/qemu-qmp-ref.html
  Command: x-blockdev-change
  Dynamically reconfigure the block driver state graph. It can be used to add, 
remove, insert or replace a graph node. Currently only the Quorum driver 
implements this feature to add or remove its child. This is useful to fix a 
broken quorum child.

  It seems x-blockdev-change not worked as expected.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1881231/+subscriptions

[Bug 1896263] Re: The bios-tables-test test causes QEMU to crash (Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed) on AMD processors

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1896263

Title:
  The bios-tables-test test causes QEMU to crash (Assertion `ret ==
  cpu->kvm_msr_buf->nmsrs' failed) on AMD processors

Status in QEMU:
  Fix Released

Bug description:
  QEMU release version: Any recent version (5.0.0, 5.1.0, git master)
  Host CPU: AMD Ryzen 3900X

  The following backtrace is from commit
  e883b492c221241d28aaa322c61536436090538a.

  QTEST_QEMU_BINARY=./build/qemu-system-x86_64 gdb 
./build/tests/qtest/bios-tables-test
  GNU gdb (GDB) 9.2
  Copyright (C) 2020 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later 
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-unknown-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  .
  Find the GDB manual and other documentation resources online at:
  .

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./build/tests/qtest/bios-tables-test...
  (gdb) run
  Starting program: 
/home/mcournoyer/src/qemu/build/tests/qtest/bios-tables-test 
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library 
"/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1".
  [New Thread 0x77af6700 (LWP 18955)]
  # random seed: R02S5106b7afa2fd84a0353605795c04ab7d
  1..19
  # Start of x86_64 tests
  # Start of acpi tests
  # starting QEMU: exec ./build/qemu-system-x86_64 -qtest 
unix:/tmp/qtest-18951.sock -qtest-log /dev/null -chardev 
socket,path=/tmp/qtest-18951.qmp,id=char0 -mon chardev=char0,mode=control 
-display none -machine pc,kernel-irqchip=off -accel kvm -accel tcg -net none 
-display none  -drive 
id=hd0,if=none,file=tests/acpi-test-disk-R3kbyc,format=raw -device 
ide-hd,drive=hd0  -accel qtest
  [Attaching after Thread 0x77af7900 (LWP 18951) fork to child process 
18956]
  [New inferior 2 (process 18956)]
  [Detaching after fork from parent process 18951]
  [Inferior 1 (process 18951) detached]
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library 
"/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1".
  [New Thread 0x77af6700 (LWP 18957)]
  [Thread 0x77af6700 (LWP 18957) exited]
  process 18956 is executing new program: 
/gnu/store/87kif0bpf0anwbsaw0jvg8fyciw4sz67-bash-5.0.16/bin/bash
  process 18956 is executing new program: 
/home/mcournoyer/src/qemu/build/qemu-system-x86_64
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library 
"/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libthread_db.so.1".
  [New Thread 0x748ed700 (LWP 18958)]
  [New Thread 0x7fffe700 (LWP 18960)]
  [New Thread 0x7fffef61c700 (LWP 18961)]
  [New Thread 0x7fffed5ff700 (LWP 18962)]
  qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0
  qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion 
`ret == cpu->kvm_msr_buf->nmsrs' failed.

  Thread 2.5 "qemu-system-x86" received signal SIGABRT, Aborted.
  [Switching to Thread 0x7fffef61c700 (LWP 18961)]
  0x765dbaba in raise () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
  (gdb) taas bt

  Thread 2.6 (Thread 0x7fffed5ff700 (LWP 18962)):
  #0  0x76770c4d in pthread_cond_timedwait@@GLIBC_2.3.2 () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0
  #1  0x55cc8a0e in qemu_sem_timedwait (sem=sem@entry=0x5662f758, 
ms=ms@entry=1) at ../util/qemu-thread-posix.c:282
  #2  0x55cd91b5 in worker_thread (opaque=opaque@entry=0x5662f6e0) 
at ../util/thread-pool.c:91
  #3  0x55cc7e86 in qemu_thread_start (args=) at 
../util/qemu-thread-posix.c:521
  #4  0x76769f64 in start_thread () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libpthread.so.0
  #5  0x7669b9af in clone () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6

  Thread 2.5 (Thread 0x7fffef61c700 (LWP 18961)):
  #0  0x765dbaba in raise () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
  #1  0x765dcbf5 in abort () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
  #2  0x765d470a in __assert_fail_base () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6
  #3  0x765d4782 in __assert_fail () from 
/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-

[Bug 1892540] Re: qemu can no longer boot NetBSD/sparc

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1892540

Title:
  qemu can no longer boot NetBSD/sparc

Status in QEMU:
  Fix Released

Bug description:
  Booting NetBSD/sparc in qemu no longer works.  It broke between qemu
  version 5.0.0 and 5.1.0, and a bisection identified the following as
  the offending commit:

[5d971f9e672507210e77d020d89e0e89165c8fc9] memory: Revert "memory:
  accept mismatching sizes in memory_region_access_valid"

  It's still broken as of 7fd51e68c34fcefdb4d6fd646ed3346f780f89f4.

  To reproduce, run

wget http://ftp.netbsd.org/pub/NetBSD/NetBSD-9.0/images/NetBSD-9.0-sparc.iso
qemu-system-sparc -nographic -cdrom NetBSD-9.0-sparc.iso -boot d

  The expected behavior is that the guest boots to the prompt

Installation medium to load the additional utilities from:

  The observed behavior is a panic:

[   1.050] system[0]: trap 0x29: pc=0xf0046b14 sfsr=0xb6 sfva=0x5400
[   1.050] cpu0: data fault: pc=0xf0046b14 addr=0x5400 
sfsr=0xb6
[   1.050] panic: kernel fault
[   1.050] halted

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1892540/+subscriptions

Re: [PATCH 1/1] net/socket.c: Fix memory leak

[Stefano Garzarella]

On Wed, Dec 09, 2020 at 08:00:13PM +0800, ruc_gongyuan...@163.com wrote:

From: yuanjungong 

close fd opened by monitor_fd_param() before returning.

Signed-off-by: yuanjungong 
---
net/socket.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/net/socket.c b/net/socket.c
index 15b410e..2f720a7 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -735,12 +735,15 @@ int net_init_socket(const Netdev *netdev, const char 
*name,
if (ret < 0) {
error_setg_errno(errp, -ret, "%s: Can't use file descriptor %d",
 name, fd);
+close(fd);
return -1;
}
if (!net_socket_fd_init(peer, "socket", name, fd, 1, sock->mcast,
errp)) {
+close(fd);


net_socket_fd_init() closes the fd in the error path, so this close 
should be avoided.



return -1;
}
+close(fd);


I don't know the code, but is it right to close the file descriptor in 
the success path?


Thanks,
Stefano


return 0;
}

--
2.17.1

Re: [PATCH 1/6] spapr: Add an "spapr" property to sPAPR CPU core

[Greg Kurz]

On Thu, 10 Dec 2020 14:53:02 +1100
David Gibson  wrote:

> On Wed, Dec 09, 2020 at 01:26:17PM -0500, Eduardo Habkost wrote:
> > On Wed, Dec 09, 2020 at 07:11:40PM +0100, Philippe Mathieu-Daudé wrote:
> > [...]
> > >  @@ -200,7 +199,7 @@ static void spapr_cpu_core_reset(DeviceState 
> > >  *dev)
> > >   int i;
> > >   
> > >   for (i = 0; i < cc->nr_threads; i++) {
> > >  -spapr_reset_vcpu(sc->threads[i]);
> > >  +spapr_reset_vcpu(sc->threads[i], sc->spapr);
> > > >>>
> > > >>> Why reset() needs access to the machine state, don't
> > > >>> you have it in realize()?
> > > >>>
> > > >>
> > > >> This is for the vCPU threads of the sPAPR CPU core. They don't have the
> > > >> link to the machine state.
> > > > 
> > > > They are created by spapr_create_vcpu() + spapr_realize_vcpu() in
> > > > spapr_cpu_core_realize(), which has sc->spapr set... Am I missing
> > > > something?
> > > 
> > > Anyhow, from a QOM design point of view, resetfn() is not the correct
> > > place to set a property IMHO, so Cc'ing Eduardo.
> > 
> > This patch is not setting the property on resetfn(), it is
> > setting it on CPU core pre_plug().
> 
> Well, also machine reset, but the point is it's not the resetfn() of
> the cpu.
> 
> Basically what this is doing is machine specific (rather than just cpu
> specific) initialization of the cpu state - we need that because the
> pseries machine is implementing an explicitly paravirtualized platform
> which starts things off in a state a bit different from the "raw" cpu
> behaviour.
> 
> So, although it's working on a CPU's state, this function actually
> belongs to the machine, rather than the cpu.
> 
> > This is more complex than simply using qdev_get_machine() and I
> > don't see why it would be better, but I don't think it's wrong.
> 
> But, yeah, this...
> 
> I've applied some of the later patches in this series, but I'm not
> convinced on this one or 2/6.  It seems like they're just replacing
> one ugly (access to qdev_machine_state() as a global) with a different
> ugly (duplicating something which has to equal the global machine
> pointer as properties in a bunch of other objects).
> 
> Both 1/6 and 2/6 are altering explicitly spapr specific devices, they
> have interactions with the overall platform model which mean they have
> to sit in that environment, so I think trying to add a property here
> implies an abstraction that can't actually be used in practice.
> 

Eduardo and you convinced me that 1/6 and 2/6 might not be an
improvement in the end, but rather making things more complex
than simply calling qdev_get_machine() when needed.


pgploFUnWnQly.pgp
Description: OpenPGP digital signature

Re: [PATCH] block/nfs: fix int overflow in nfs_client_open_qdict

[Stefano Garzarella]

On Wed, Dec 09, 2020 at 01:17:35PM +0100, Peter Lieven wrote:

nfs_client_open returns the file size in sectors. This effectively
makes it impossible to open files larger than 1TB.

Fixes: a1a42af422d46812f1f0cebe6b230c20409a3731
Cc: qemu-sta...@nongnu.org
Signed-off-by: Peter Lieven 
---
block/nfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


The issue seems to be pre-existing to the commit 
a1a42af422d46812f1f0cebe6b230c20409a3731, but of course that commit 
touched this code and this patch would not apply before, so it seems 
okay to me:


Reviewed-by: Stefano Garzarella 

Thanks,
Stefano



diff --git a/block/nfs.c b/block/nfs.c
index 77905f516d..8c1968bb41 100644
--- a/block/nfs.c
+++ b/block/nfs.c
@@ -592,7 +592,7 @@ static int64_t nfs_client_open_qdict(NFSClient *client, 
QDict *options,
 int flags, int open_flags, Error **errp)
{
BlockdevOptionsNfs *opts;
-int ret;
+int64_t ret;

opts = nfs_options_qdict_to_qapi(options, errp);
if (opts == NULL) {
--
2.17.1

[Bug 1893691] Re: Chardev logfile is not written (regression between 5.0 and 5.1)

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1893691

Title:
  Chardev logfile is not written (regression between 5.0 and 5.1)

Status in QEMU:
  Fix Released

Bug description:
  After update from version 5.0 to 5.1, logfile stopped being populated
  with console output. The file is being created, but remains empty.

  Relevant command line options:

  -mon chardev=char0
  -serial chardev:char0
  -chardev 
socket,host=127.0.0.10,port=2323,server,nowait,telnet,mux=on,id=char0,logfile=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/log

  
  Full command line:

  qemu-system-x86_64
  -nodefaults
  -no-user-config
  -snapshot
  -enable-kvm
  -cpu
  host
  -nographic
  -echr
  17
  -mon
  chardev=char0
  -serial
  chardev:char0
  -rtc
  clock=vm
  -object
  rng-random,filename=/dev/urandom,id=rng0
  -device
  virtio-rng-pci,rng=rng0,max-bytes=512,period=1000
  -name
  2020-08-31T21:46:55-0,debug-threads=on
  -smp
  sockets=1,cores=9,threads=2
  -m
  251G
  -overcommit
  cpu-pm=on
  -pidfile
  /home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/pid
  -net
  nic,model=virtio
  -net
  
user,hostfwd=tcp:127.0.0.10:-:22,hostfwd=tcp:127.0.0.10:8000-:8000,hostfwd=tcp:127.0.0.10:9000-:9000
  -fsdev
  
local,id=machiner_internal_dir,security_model=none,path=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal
  -device
  virtio-9p-pci,fsdev=machiner_internal_dir,mount_tag=machiner_internal_dir
  -fsdev
  local,id=machiner_lower_dir,security_model=none,readonly,path=.
  -device
  virtio-9p-pci,fsdev=machiner_lower_dir,mount_tag=machiner_lower_dir
  -fsdev
  
local,id=machiner_upper_dir,security_model=mapped-xattr,fmode=0777,dmode=0777,path=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0
  -device
  virtio-9p-pci,fsdev=machiner_upper_dir,mount_tag=machiner_upper_dir
  -device
  virtio-scsi
  -drive
  
if=none,file=/home/jurkiew/.machiner/images/famtar/image.qcow2,discard=on,id=famtar
  -device
  scsi-hd,drive=famtar
  -chardev
  
socket,host=127.0.0.10,port=2323,server,nowait,telnet,mux=on,id=char0,logfile=/home/jurkiew/.machiner/runs/2020-08-31T21:46:55-0/internal/log

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1893691/+subscriptions

[Bug 1907427] Re: Build on sparc64 fails with "undefined reference to `fdt_check_full'"

[John Paul Adrian Glaubitz]

Indeed, libfdt has been failing to build from source on sparc64 since
version 1.4.7 due to the testsuite crashing with unaligned access:

> https://buildd.debian.org/status/fetch.php?pkg=device-tree-
compiler&arch=sparc64&ver=1.6.0-1&stamp=1605385435&raw=0

libfdt-dev probably contains some fancy pointer arithmetic resulting in
unaligned access which is not allowed but not recognized by gcc.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1907427

Title:
  Build on sparc64 fails with "undefined reference to `fdt_check_full'"

Status in QEMU:
  New

Bug description:
  Trying to build QEMU on sparc64 fails with:

  [4648/8435] c++  -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o 
libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o 
libcommon.fa.p/hw_input_vhost-user-input.c.o 
libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o 
libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o 
libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o 
libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o 
libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o 
libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o 
libcommon.fa.p/hw_display_sm501.c.o 
libcommon.fa.p/hw_net_rocker_rocker_world.c.o 
libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o 
libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o 
libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o 
libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o 
libcommon.fa.p/migration_global_state.c.o 
libcommon.fa.p/backends_rng-random.c.o 
libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o 
libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o 
libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o 
libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o 
libcommon.fa.p/hw_core_qdev-properties-system.c.o 
libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o 
libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o 
libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o 
libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o 
libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o 
libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o 
libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o 
libcommon.fa.p/audio_audio_legacy.c.o
  (...)
  libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro 
-Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong 
libmigration.fa -Wl,--start-group libqemuutil.a 
contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa 
libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa 
@block.syms @qemu.syms 
/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so 
/usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm 
/usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so 
/usr/lib/sparc64-linux-gnu/libslirp.so 
/usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 
-lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so 
@block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so 
/usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug 
/usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil 
-lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm 
-Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle 
-lstdc++ -Wl,--end-group
  /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function 
`h_update_dt':
  ./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to 
`fdt_check_full'
  collect2: error: ld returned 1 exit status

  Full build log available at:
  
https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=sparc64&ver=1%3A5.2%2Bdfsg-1&stamp=1607502300&raw=0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1907427/+subscriptions

[Bug 1900779] Re: xp /16i on arm mixes DWords

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1900779

Title:
  xp /16i on arm mixes DWords

Status in QEMU:
  Fix Released

Bug description:
  I was working with qemuand wanted to understag ATAG structure.
  In Monitor mode I used xp /16i 0x100 and I got really confused.
  with xp /16i 0x100:
  At address 0x120 the DWords are 0x, 0x0004, 0x54410009, 0x74736574
  with xp /16x 0x100:
  At address 0x120 the DWords are 0x54410001, 0x0001, 0x0001, 0x

  from my Terminal:

  (qemu) xp /16x 0x100
  0100: 0x0005 0x54410001 0x0001 0x1000
  0110: 0x 0x0004 0x54410002 0x3c00
  0120: 0x 0x0004 0x54410009 0x74736574
  0130: 0x 0x 0x 0x
  (qemu) xp /16i 0x100
  0x0100:  0005  andeqr0, r0, r5
  0x0104:  54410001  strbpl   r0, [r1], #-1
  0x0108:  0001  andeqr0, r0, r1
  0x010c:  1000  andeqr1, r0, r0
  0x0110:    andeqr0, r0, r0
  0x0114:  0004  andeqr0, r0, r4
  0x0118:  54410002  strbpl   r0, [r1], #-2
  0x011c:  3c00  .byte0x00, 0x00, 0x00, 0x3c
  0x0120:  54410001  strbpl   r0, [r1], #-1
  0x0124:  0001  andeqr0, r0, r1
  0x0128:  1000  andeqr1, r0, r0
  0x012c:    andeqr0, r0, r0
  0x0130:  0004  andeqr0, r0, r4
  0x0134:  54410002  strbpl   r0, [r1], #-2
  0x0138:  3c00  .byte0x00, 0x00, 0x00, 0x3c
  0x013c:    andeqr0, r0, r0
  (increasing length only results in more   andeqr0, r0, r0 Lines)

  Version:
  4.2.1Debian 1:4.2-3ubuntu6.6
  Commandline:
  qemu-system-arm -machine raspi2 --nographic -S -s -kernel ./vmlinuz --append 
"test"
  ./vmlinuz is a x64 linux kernel. I didn't care about architecture because i 
just wanted to see ATAG structure.
  I also tried
  qemu-system-arm -machine raspi2 --nographic -S -s -kernel ./overview.pdf 
--append "test"
  same result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1900779/+subscriptions

[Bug 1872237] Re: SysTick reload behavior emulated incorrectly

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1872237

Title:
  SysTick reload behavior emulated incorrectly

Status in QEMU:
  Fix Released

Bug description:
  QEMU's emuation of SysTick on ARM is incorrect with respect to reload
  behavior.  This issue is described here, and also in a repository
  dedicated to the issue:

https://github.com/oxidecomputer/qemu-systick-bug

  
  (What follows is in Markdown, which I understand that Launchpad does
  not support; see the repository linked above for a rendering of it.)

  Take this Rust program:

  ```rust
  #![no_std]
  #![no_main]

  extern crate panic_semihosting;

  use cortex_m_rt::entry;
  use cortex_m_semihosting::hprintln;
  use cortex_m::peripheral::syst::SystClkSource;
  use cortex_m::peripheral::SYST;

  fn delay(syst: &mut cortex_m::peripheral::SYST, ms: u32)
  {
  /*
   * Configured for the LM3S6965, which has a default CPU clock of 12 Mhz
   */
  let reload = 12_000 * ms;

  syst.set_reload(reload);
  syst.clear_current();
  syst.enable_counter();

  hprintln!("waiting for {} ms (SYST_CVR={}) ...",
  ms, SYST::get_current()
  ).unwrap();

  while !syst.has_wrapped() {}

  hprintln!("  ... done (SYST_CVR={})\n",
  SYST::get_current()).unwrap();

  syst.disable_counter();
  }

  #[entry]
  fn main() -> ! {
  let p = cortex_m::Peripherals::take().unwrap();
  let mut syst = p.SYST;

  syst.set_clock_source(SystClkSource::Core);

  loop {
  delay(&mut syst, 1000);
  delay(&mut syst, 100);
  }
  }
  ```

  This program should oscillate between waiting for one second and waiting
  for 100 milliseconds.  Under hardware, this is more or less what it does
  (depending on core clock frequency); e.g., from an STM32F4107 (connected via
  OCD and with semi-hosting enabled):

  ```
  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=1102)

  waiting for 100 ms (SYST_CVR=1199949) ...
... done (SYST_CVR=1199897)

  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=11999885)

  waiting for 100 ms (SYST_CVR=1199949) ...
... done (SYST_CVR=1199897)

  waiting for 1000 ms (SYST_CVR=1149) ...
... done (SYST_CVR=11999885)

  ```

  Under QEMU, however, its behavior is quite different:

  ```
  $ cargo run
  Finished dev [unoptimized + debuginfo] target(s) in 0.03s
   Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic 
-semihosting-config enable=on,target=native -kernel 
target/thumbv7m-none-eabi/debug/qemu-systick-bug`
  waiting for 1000 ms (SYST_CVR=11999658) ...
... done (SYST_CVR=11986226)

  waiting for 100 ms (SYST_CVR=0) ...
... done (SYST_CVR=1186560)

  waiting for 1000 ms (SYST_CVR=1185996) ...
... done (SYST_CVR=11997350)

  waiting for 100 ms (SYST_CVR=0) ...
... done (SYST_CVR=1186581)
  ```

  In addition to the values being strangely wrong, the behavior is wrong:
  the first wait correctly waits for 1000 ms -- but the subsequent wait
  (which should be for 100 ms) is in fact 1000 ms, and the next wait (which
  should be for 1000 ms) is in fact 100 ms.  (That is, it appears as if
  the periods of the two delays have been switched.)

  The problems is that the QEMU ARM emulation code does not reload SYST_CVR from
  SYST_RVR if SYST_CSR.ENABLE is not set -- and moreover, that SYST_CVR is
  not reloaded from SYST_RVR even when SYST_CSR.ENABLE becomes set.  This is
  very explicit; from
  https://github.com/qemu/qemu/blob/8bac3ba57eecc466b7e73dabf7d19328a59f684e/hw/timer/armv7m_systick.c#L42-L60";>hw/timer/armv7m_systick.c:

  ```c
  static void systick_reload(SysTickState *s, int reset)
  {
  /* The Cortex-M3 Devices Generic User Guide says that "When the
   * ENABLE bit is set to 1, the counter loads the RELOAD value from the
   * SYST RVR register and then counts down". So, we need to check the
   * ENABLE bit before reloading the value.
   */
  trace_systick_reload();

  if ((s->control & SYSTICK_ENABLE) == 0) {
  return;
  }

  if (reset) {
  s->tick = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
  }
  s->tick += (s->reload + 1) * systick_scale(s);
  timer_mod(s->timer, s->tick);
  }
  ```

  The statement in the code is stronger than the statement in the
  https://static.docs.arm.com/ddi0403/eb/DDI0403E_B_armv7m_arm.pdf";>ARMv7-M 
Architecture Reference Manual (sec B3.3.1):

  > Writing to SYST_CVR clears both the register and the COUNTFLAG status
  > bit to zero. This causes the SysTick logic to reload SYST_CVR from SYST_RVR
  > on the next timer clock. A write to SYST_CVR does not trigger the
  > SysTick exception logic.

  Note that this does not mention the behavior on a write to SYST_CVR when
  SYST_CSR.ENABLE i

[Bug 1877384] Re: 9pfs file create with mapped-xattr can fail on overlayfs

[Thomas Huth]

Fixed in commit d76f4f97eb2772bf85fe286097183d0c7db19ae8

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1877384

Title:
  9pfs file create with mapped-xattr can fail on overlayfs

Status in QEMU:
  Fix Released

Bug description:
  QEMU Version: 3.1.0 as packaged in debian buster, but the code appears to do 
the same in master.
  qemu command-line: qemu-system-x86_64 -m 1G -nographic -nic 
"user,model=virtio-net-pci,tftp=$(pwd),net=10.0.2.0/24,host=10.0.2.2" -fsdev 
local,id=fs,path=$thisdir/..,security_model=mapped-xattr -device 
virtio-9p-pci,fsdev=fs,mount_tag=fs -drive 
"file=$rootdisk,if=virtio,format=raw" -kernel "$kernel" -initrd "$initrd" 
-append "$append"

  
  I'm using CI that runs in a Docker container and runs a qemu VM with code and 
results shared via virtio 9p.
  The 9p fsdev is configured with security_model=mapped-xattr
  When the test code attempts to create a log file in an existing directory, 
open with O_CREAT fails with -ENOENT.

  The relevant strace excerpt is:

  28791 openat(11, ".", O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 20
  28791 openat(20, "src", O_RDONLY|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW|O_DIRECTORY) 
= 21
  28791 fcntl(21, F_SETFL, O_RDONLY|O_DIRECTORY) = 0
  28791 close(20) = 0
  28791 openat(21, "client.log", 
O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_NOFOLLOW, 0600) = 20
  28791 fcntl(20, F_SETFL, O_WRONLY|O_CREAT|O_NONBLOCK|O_NOFOLLOW) = 0
  28791 lsetxattr("/proc/self/fd/21/client.log", "user.virtfs.uid", "\0\0\0", 
4, 0) = -1 ENOENT (No such file or directory)

  My hypothesis for what's going wrong is since the Docker container's
  overlayfs copies-up on writes, when it opens the file it's created a
  new version of the `src` directory containing a `client.log`, but this
  new src directory isn't accessible by file descriptor 20 and the
  lsetxattr call is instead attempting to set attributes on the path in
  the old `src` directory.

  Looking at the code, a fix would be to change `hw/9pfs/9p-local.c` and
  change `local_open2` to instead of calling `local_set_xattrat` to set
  the xattrs by directory file descriptor and file name, to have a
  version of local_set_xattrat` which uses `fsetxattr` to set the virtfs
  attributes instead of the `fsetxattrat_nofollow` helper.

  This reliably happened for me in CI, but I don't have access to the CI
  host or the time to strip the test down to make a minimal test case,
  and had difficulty reproducing the error on other machines.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1877384/+subscriptions

[Bug 1904486] Re: resource leak in /net/tap.c

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1904486

Title:
  resource leak in /net/tap.c

Status in QEMU:
  Fix Released

Bug description:
  Hi,there might be a resource leak in function net_init_tap in
  /net/tap.c. The version is 5.1.91.

  
   811 fd = monitor_fd_param(monitor_cur(), tap->fd, errp);
   812 if (fd == -1) {
   813 return -1;
   814 }
   815
   816 ret = qemu_try_set_nonblock(fd);
   817 if (ret < 0) {
   818 error_setg_errno(errp, -ret, "%s: Can't use file descriptor 
%d",
   819  name, fd);
   820 return -1;
   821 }
   822
   823 vnet_hdr = tap_probe_vnet_hdr(fd, errp);
   824 if (vnet_hdr < 0) {
   825 close(fd);
   826 return -1;
   827 }
   828
   829 net_init_tap_one(tap, peer, "tap", name, NULL,
   830  script, downscript,
   831  vhostfdname, vnet_hdr, fd, &err);
   832 if (err) {
   833 error_propagate(errp, err);
   834 return -1;
   835 }

  fd should be closed before return in line 820 and line 834, similar to
  the implementation in line 825.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1904486/+subscriptions

[Bug 1880326] Re: memory writes make artist_rop8() crash

[Thomas Huth]

Fixed in commits 84a7b7741a62ede8ff01ae151e59b2a16bda629b and
a501bfc91763d4642390090dd4e6039d67b63702

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880326

Title:
  memory writes make artist_rop8() crash

Status in QEMU:
  Fix Released

Bug description:
  As of commit d19f1ab0, LLVM libFuzzer found:

  =
  ==6814==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x7fd89f97bd5a at pc 0x55dc44594db5 bp 0x7ffd6f461b40 sp 0x7ffd6f461b38
  READ of size 1 at 0x7fd89f97bd5a thread T0
  #0 0x55dc44594db4 in artist_rop8
  #1 0x55dc44595fd9 in draw_line
  #2 0x55dc445937e4 in draw_line_size
  #3 0x55dc4458ee9d in artist_reg_write
  #4 0x55dc43f77ba7 in memory_region_write_accessor
  #5 0x55dc43f775b8 in access_with_adjusted_size
  #6 0x55dc43f762b3 in memory_region_dispatch_write
  #7 0x55dc43dbb322 in flatview_write_continue
  #8 0x55dc43dab2e2 in flatview_write
  #9 0x55dc43daae14 in address_space_write

  0x7fd89f97bd5a is located 1122 bytes to the right of 16777464-byte region 
[0x7fd89e97b800,0x7fd89f97b8f8)
  allocated by thread T0 here:
  #0 0x55dc43d87abf in operator new(unsigned long)
  #1 0x55dc43c4274d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned 
char const*, unsigned long))
  #2 0x55dc43c3a526 in main (qemu-fuzz-hppa+0x982526)
  #3 0x7fd8d05edf42 in __libc_start_main (/lib64/libc.so.6+0x23f42)

  SUMMARY: AddressSanitizer: heap-buffer-overflow (qemu-fuzz-hppa+0x12dcdb4) in 
artist_rop8
  Shadow bytes around the buggy address:
0x0ffb93f27750: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0ffb93f27760: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0ffb93f27770: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0ffb93f27780: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0ffb93f27790: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  =>0x0ffb93f277a0: fa fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa
0x0ffb93f277b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0ffb93f277c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0ffb93f277d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0ffb93f277e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0ffb93f277f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable:   00
Partially addressable: 01 02 03 04 05 06 07 
Heap left redzone:   fa
Freed heap region:   fd
Stack left redzone:  f1
Stack mid redzone:   f2
Stack right redzone: f3
Stack after return:  f5
Stack use after scope:   f8
Global redzone:  f9
Global init order:   f6
Poisoned by user:f7
Container overflow:  fc
Array cookie:ac
Intra object redzone:bb
ASan internal:   fe
Left alloca redzone: ca
Right alloca redzone:cb
Shadow gap:  cc
  ==6814==ABORTING

  How to reproduce:

  qemu-system-hppa -S -qtest stdio -accel qtest -display none < EOF
  writeb 0xf8100081 0x40
  writeb 0xf81000c5 0x40
  writeb 0xf8100e44 0x2b
  writeb 0xf8100e44 0x56
  writeb 0xf8100e44 0x10
  writeb 0xf8100600 0x0
  writeb 0xf8100821 0x21
  writeb 0xf8100b01 0x14
  writew 0xf8100044 0x1245
  writeb 0xf8100a0e 0x50
  writeb 0xf8100a02 0x49
  writeb 0xf8100821 0x0
  writew 0xf8100014 0x0
  writeb 0xf8100e46 0x46
  writeb 0xf8100052 0xe
  writeb 0xf8100621 0x14
  writeb 0xf8100b01 0x14
  writew 0xf8100044 0x1241
  writeb 0xf8100b02 0x25
  writeb 0xf8100b01 0x4
  writeb 0xf8100e46 0xb0
  writeb 0xf8100b02 0x0
  writel 0xf81000c4 0x49494949
  writeb 0xf8100b02 0x10
  writew 0xf8100010 0x11
  writew 0xf8100044 0x1212
  writew 0xf8100044 0x1245
  writew 0xf8100050 0xe2a
  writeb 0xf812 0x11
  writeb 0xf8100081 0xec
  writeb 0xf8100081 0xec
  writeb 0xf810030e 0xe
  writeb 0xf81e 0x44
  writeb 0xf810 0xe
  writeb 0xf8100044 0xe
  writeb 0xf810 0xe
  writeb 0xf810030e 0x13
  writeb 0xf8100b44 0x2a
  writeb 0xf8100bf8 0x4
  writeb 0xf817 0x45
  writeb 0xf81000ff 0xff
  writew 0xf8100044 0xf042
  writew 0xf810 0x45
  writew 0xf8100044 0xf042
  writeb 0xf810 0xc5
  writeb 0xf81000ff 0xff
  writel 0xf8100044 0x101364ff
  writel 0xf81000c4 0xfba0a0a0
  writeb 0xf810 0x2a
  writeb 0xf81000c5 0x40
  writeb 0xf81000ff 0xdf
  writew 0xf810 0x4144
  writeb 0xf81000df 0x0
  writew 0xf8100044 0x4400
  writel 0xf8100044 0x101364ff
  writel 0xf81000c4 0xfb490045
  writeb 0xf810 0x2a
  writeb 0xf81000c5 0x40
  writel 0xf8100044 0x101364ff
  writel 0xf8100bc4 0x49004545
  writeb 0xf810 0x2a
  writeb 0xf81000c5 0x40
  writeb 0xf81e 0x21
  writeb 0xf810 0x2a
  writeb 0xf81000c3 0x40
  writeb 0xf81000ff 0xdf
 

[Bug 1793608] Re: qemu doesn't seem to support lxvwsx for POWER9 target

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1793608

Title:
  qemu doesn't seem to support lxvwsx for POWER9 target

Status in QEMU:
  Fix Released

Bug description:
  When running a simple program built for POWER9 on QEMU 3.0.0 in linux-
  user mode, it crashes with a message: "illegal instruction". It turns
  out that lxvwsx instruction "Load Word and Splat Indexed" is not
  supported. If workaround is implemented by issuing two separate
  instructions (first load then splat) then all tests pass correctly.

  Operating system: Ubuntu Mate 16.04.2 64-bit (or Linux Mint 18 64-bit).
  Cross-compiler for gcc-powerpc64le-linux-gnu is installed (gcc-5 series).
  QEMU 3.0.0 is built from source and installed with: sudo make install

  The program in question: https://github.com/VectorChief/UniSIMD-assembler
  Turn off the workaround: RT_ELEM_COMPAT_PW9 should be set to 1 in the 
following file:
  
https://github.com/VectorChief/UniSIMD-assembler/blob/master/core/config/rtarch_p32_128x1v2.h

  Change to the "test" directory and type "make -f simd_make_p64.mk".
  powerpc64le-linux-gnu-objdump -d simd_test.p64_32Lp9 > simd_test_p64_32Lp9.txt
  Open newly created text file simd_test_p64_32Lp9.txt and search for lxvwsx 
(in s_test01, ...)
  The instruction shows up in objdump correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1793608/+subscriptions

[Bug 1890312] Re: Segfault in artist_vram_read

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890312

Title:
  Segfault in artist_vram_read

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Reproducer:

  cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \
  -qtest stdio -accel qtest
  writew 0xf8118001 0x105a
  readq 0xf900f8ff
  EOF

  =
  ==20118==ERROR: AddressSanitizer: SEGV on unknown address 0x7fc6fb847672 (pc 
0x55ec9c0f6828 bp 0x7ffd91000230 sp 0x7ffd90d0 T0)
  ==20118==The signal is caused by a READ memory access.
  #0 0x55ec9c0f6828 in artist_vram_read /hw/display/artist.c:1174:15
  #1 0x55ec9b84a582 in memory_region_read_accessor /softmmu/memory.c:434:11
  #2 0x55ec9b7d1adc in access_with_adjusted_size /softmmu/memory.c:539:18
  #3 0x55ec9b7cd769 in memory_region_dispatch_read1 
/softmmu/memory.c:1385:16
  #4 0x55ec9b7cc855 in memory_region_dispatch_read /softmmu/memory.c:1414:9
  #5 0x55ec9ae621de in flatview_read_continue /exec.c:3239:23
  #6 0x55ec9ae64fb1 in flatview_read /exec.c:3279:12
  #7 0x55ec9ae64af7 in address_space_read_full /exec.c:3292:18
  #8 0x55ec9b87c990 in address_space_read /include/exec/memory.h:2429:18
  #9 0x55ec9b87c990 in qtest_process_command /softmmu/qtest.c:485:13
  #10 0x55ec9b870c08 in qtest_process_inbuf /softmmu/qtest.c:710:9
  #11 0x55ec9b86f895 in qtest_read /softmmu/qtest.c:722:5
  #12 0x55ec9dd2b2f3 in qemu_chr_be_write_impl /chardev/char.c:188:9
  #13 0x55ec9dd2b477 in qemu_chr_be_write /chardev/char.c:200:9
  #14 0x55ec9dd3f763 in fd_chr_read /chardev/char-fd.c:68:9
  #15 0x55ec9de93b24 in qio_channel_fd_source_dispatch 
/io/channel-watch.c:84:12
  #16 0x7fc7261ad897 in g_main_context_dispatch ()
  #17 0x55ec9e28ba2b in glib_pollfds_poll /util/main-loop.c:217:9
  #18 0x55ec9e28915b in os_host_main_loop_wait /util/main-loop.c:240:5
  #19 0x55ec9e288af4 in main_loop_wait /util/main-loop.c:516:11
  #20 0x55ec9b891d00 in qemu_main_loop /softmmu/vl.c:1676:9
  #21 0x55ec9decb911 in main /softmmu/main.c:49:5

  The error occurs even with Message-Id:
  <20200804140056.7690-1-del...@gmx.de> applied (I collected the above
  trace with the patch-set applied)

  Thanks
  -Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890312/+subscriptions

[Bug 1453608] Re: explain what pcsys_monitor in manpage

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1453608

Title:
  explain what pcsys_monitor in manpage

Status in QEMU:
  Fix Released

Bug description:
  The specification of vnc passwords seems to have changed. `man qemu-
  system-x86_64` mentions `set_password` to be used in `pcsys_monitor`.
  Both are are not further mentioned in the man page and misteriously
  inexisting in both the web and the source root (as far as `grep -r -I
  'pcsys_monitor' .` is concerned). That's too vage to be usable.

  experienced with 2.3.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1453608/+subscriptions

[Bug 1852196] Re: update edk2 submodule & binaries to edk2-stable202008

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1852196

Title:
  update edk2 submodule & binaries to edk2-stable202008

Status in QEMU:
  Fix Released

Bug description:
  Consume the following upstream edk2 releases:

  https://github.com/tianocore/edk2/releases/tag/edk2-stable201908
  https://github.com/tianocore/edk2/releases/tag/edk2-stable201911
  https://github.com/tianocore/edk2/releases/tag/edk2-stable202002
  https://github.com/tianocore/edk2/releases/tag/edk2-stable202005
  https://github.com/tianocore/edk2/releases/tag/edk2-stable202008

  Worth mentioning (in random order):

  - various CVE fixes [*]
  - OpenSSL-1.1.1g
  - UEFI HTTPS Boot for ARM/AARCH64
  - TPM2 for ARM/AARCH64
  - VCPU hotplug with SMI
  - support for Linux v5.7+ initrd and mixed mode loading
  - Fusion-MPT SCSI driver in OVMF
  - VMware PVSCSI driver in OVMF
  - PXEv4 / PXEv6 boot possible to disable on the QEMU command line
  - SEV-ES support

  [*] the below list has been collected simply from the subject lines in
  commit range edk2-stable201905..edk2-stable202008:

CVE-2019-11098 CVE-2019-14553 CVE-2019-14558 CVE-2019-14559
CVE-2019-14562 CVE-2019-14563 CVE-2019-14575 CVE-2019-14586
CVE-2019-14587

  (Note that any given CVE from the above list may or may not affect the
  firmware binaries packaged with upstream QEMU; consult the upstream
  TianoCore bug tracker at  for details.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1852196/+subscriptions

[Bug 1838658] Re: qemu 4.0.0 broken by glib update

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1838658

Title:
  qemu 4.0.0 broken by glib update

Status in QEMU:
  Fix Released

Bug description:
  In brief, an install CD will successfully boot with qemu 4.0.0 built with 
glib 2.58.3, but freeze during boot with qemu 4.0.0 built with glib 2.60.0. I 
tracked it down to glib's GHashTable improvements. qemu is happy with a glib 
built from
  ```
   git checkout -f 2.60.4
   git revert --no-edit 86c6f7e2b..3bed8a13b
   git revert --no-edit 75f8ec1df9b48b0c3a13a9125f2c7d7c5adf5159
   git revert --no-edit 603fb5958..d3074a748
   git revert --no-edit 0b45ddc55..0600dd322
  ```
  When the GHashTable improvements were committed, there was already a 
preemptive note about any breakage being due to using private implementation 
details, hence mentioning it here rather than with glib.

  For the full saga, see: http://gnats.netbsd.org/54310

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1838658/+subscriptions

[Bug 1890311] Re: Segfault in cpu_physical_memory_set_dirty_range on hppa + artist

[Thomas Huth]

Fixed in commit a501bfc91763d4642390090dd4e6039d67b63702

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890311

Title:
  Segfault in cpu_physical_memory_set_dirty_range on hppa + artist

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Reproducer:

  cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \
  -qtest stdio -accel qtest
  writeq 0xf810049f 0x85
  writew 0xf8118001 0x14
  writeq 0xf81005fb 0x5c6418001832
  EOF

  AddressSanitizer:DEADLYSIGNAL
  =
  ==10793==ERROR: AddressSanitizer: SEGV on unknown address 0x7f93dbb4 (pc 
0x5577f5523078 bp 0x7ffd41ad6360 sp 0x7ffd41ad5fd0 T0)
  ==10793==The signal is caused by a READ memory access.

  #0 0x5577f5523078 in block_move /hw/display/artist.c:525:13
  #1 0x5577f5515fbc in artist_reg_write /hw/display/artist.c:964:9
  #2 0x5577f4c077a3 in memory_region_write_accessor /softmmu/memory.c:483:5
  #3 0x5577f4c06adc in access_with_adjusted_size /softmmu/memory.c:539:18
  #4 0x5577f4c04873 in memory_region_dispatch_write 
/softmmu/memory.c:1466:16
  #5 0x5577f42b2056 in flatview_write_continue /exec.c:3176:23
  #6 0x5577f429a866 in flatview_write /exec.c:3216:14
  #7 0x5577f429a387 in address_space_write /exec.c:3308:18
  #8 0x5577f4cae604 in qtest_process_command /softmmu/qtest.c:452:13
  #9 0x5577f4ca5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9
  #10 0x5577f4ca4895 in qtest_read /softmmu/qtest.c:722:5
  #11 0x5577f7160c43 in qemu_chr_be_write_impl /chardev/char.c:188:9
  #12 0x5577f7160dc7 in qemu_chr_be_write /chardev/char.c:200:9
  #13 0x5577f71750b3 in fd_chr_read /chardev/char-fd.c:68:9
  #14 0x5577f72c9474 in qio_channel_fd_source_dispatch 
/io/channel-watch.c:84:12
  #15 0x7f93ea531897 in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
  #16 0x5577f76c137b in glib_pollfds_poll /util/main-loop.c:217:9
  #17 0x5577f76beaab in os_host_main_loop_wait /util/main-loop.c:240:5
  #18 0x5577f76be444 in main_loop_wait /util/main-loop.c:516:11
  #19 0x5577f4cc6d00 in qemu_main_loop /softmmu/vl.c:1676:9
  #20 0x5577f7301261 in main /softmmu/main.c:49:5
  #21 0x7f93e90b7e0a in __libc_start_main 
/build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
  #22 0x5577f41a5729 in _start 
(/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729)

  AddressSanitizer can not provide additional info.
  SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move
  ==10793==ABORTING

  
  The error occurs even with Message-Id: <20200804140056.7690-1-del...@gmx.de> 
applied (I collected the above trace with the patch-set applied)

  Thanks
  -Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890311/+subscriptions

[Bug 1611394] Re: qemu-ppc: Scalar Single-Precision Floating-Point instructions should not test MSR[SPV]

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1611394

Title:
  qemu-ppc: Scalar Single-Precision Floating-Point instructions should
  not test  MSR[SPV]

Status in QEMU:
  Fix Released

Bug description:
  According to "Signal Processing Engine (SPE) Programming Environments Manual" 
at
  
http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf?fsrch=1&sr=1&pageNum=1

  c.f section 4.2.3  and also Figure 2-2.

  When MSR[SPV] is _NOT_ set, then the embedded scalar single-precision 
floating-point instructions
  should _NOT_ generate an Embedded Floating-Point Unavailable Interrupt.

  
  Hence, some tests for MSR[SPV] in file target-ppc/translate.c need to be 
removed.
  Namely, in the definitions of 
  1. GEN_SPEFPUOP_ARITH2_32_32
  2. gen_efsabs
  3. gen_efsnabs
  4. gen_efsneg
  5. GEN_SPEFPUOP_COMP_32

  Note, the macro GEN_SPEFPUOP_CONV_32_32 is already correct.

  One more thing, afaict the macro GEN_SPEFPUOP_CONV_32_64 is used by both
  efs- and efd- instructions, and will need to be split in two versions.
  The efs-use (i.e for efscfd) should be as it is today, but the use by 
efd-instructions 
  (e.g efdctui) will need to add a test for MSR[SPV].


  (I've looked at today's HEAD-revision of target-ppc/translate.c).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1611394/+subscriptions

[Bug 1336794] Re: 9pfs does not honor open file handles on unlinked files

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1336794

Title:
  9pfs does not honor open file handles on unlinked files

Status in QEMU:
  Fix Released
Status in Ubuntu:
  Confirmed

Bug description:
  This was originally filed over here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1114221

  The open-unlink-fstat idiom used in some places to create an anonymous
  private temporary file does not work in a QEMU guest over a virtio-9p
  filesystem.

  Version-Release number of selected component (if applicable):

  qemu-kvm-1.6.2-6.fc20.x86_64
  qemu-system-x86-1.6.2-6.fc20.x86_64
  (those are fedora RPMs)

  How reproducible:

  Always. See this example C program:

  https://bugzilla.redhat.com/attachment.cgi?id=913069

  Steps to Reproduce:
  1. Export a filesystem with virt-manager for the guest.
(type: mount, driver: default, mode: passthrough)
  2. Start guest and mount that filesystem
(mount -t 9p -o trans=virtio,version=9p2000.L  ...)
  3. Run a program that uses open-unlink-fstat
(in my case it was trying to compile Perl 5.20)

  Actual results:

  fstat fails:

  open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
  unlink("/home/tst/filename")= 0
  fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or 
directory)
  close(3)

  Expected results:

  open("/home/tst/filename", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
  unlink("/home/tst/filename")= 0
  fstat(3, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
  fcntl(3, F_SETFD, FD_CLOEXEC)   = 0
  close(3) 

  Additional info:

  There was a patch put into the kernel back in '07 to handle this very
  problem for other filesystems; maybe its helpful:

http://lwn.net/Articles/251228/

  There is also a thread on LKML from last December specifically about
  this very problem:

https://lkml.org/lkml/2013/12/31/163

  There was a discussion on the QEMU list back in '11 that doesn't seem
  to have come to a conclusion, but did provide the test program that
  i've attached to this report:

http://marc.info/?l=qemu-devel&m=130443605720648&w=2

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1336794/+subscriptions

[Bug 1890310] Re: Segfault in artist.c:block_move

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890310

Title:
  Segfault in artist.c:block_move

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Reproducer:

  cat << EOF | ./hppa-softmmu/qemu-system-hppa -m 64 -display none \
  -qtest stdio -accel qtest
  writeq 0xf8100802 0xff5c651b7c5c
  writeq 0xf8100afb 0x25e
  EOF

  AddressSanitizer:DEADLYSIGNAL
  =
  ==12686==ERROR: AddressSanitizer: SEGV on unknown address 0x7f001a54 (pc 
0x55af3a373078 bp 0x7ffc23001a00 sp 0x7ffc23001670 T0)
  ==12686==The signal is caused by a READ memory access.
  #0 0x55af3a373078 in block_move /hw/display/artist.c:525:13
  #1 0x55af3a365fbc in artist_reg_write /hw/display/artist.c:964:9
  #2 0x55af39a577a3 in memory_region_write_accessor /softmmu/memory.c:483:5
  #3 0x55af39a56adc in access_with_adjusted_size /softmmu/memory.c:539:18
  #4 0x55af39a54873 in memory_region_dispatch_write 
/softmmu/memory.c:1466:16
  #5 0x55af39102056 in flatview_write_continue /exec.c:3176:23
  #6 0x55af390ea866 in flatview_write /exec.c:3216:14
  #7 0x55af390ea387 in address_space_write /exec.c:3308:18
  #8 0x55af39afe604 in qtest_process_command /softmmu/qtest.c:452:13
  #9 0x55af39af5c08 in qtest_process_inbuf /softmmu/qtest.c:710:9
  #10 0x55af39af4895 in qtest_read /softmmu/qtest.c:722:5
  #11 0x55af3bfb0c43 in qemu_chr_be_write_impl /chardev/char.c:188:9
  #12 0x55af3bfb0dc7 in qemu_chr_be_write /chardev/char.c:200:9
  #13 0x55af3bfc50b3 in fd_chr_read /chardev/char-fd.c:68:9
  #14 0x55af3c119474 in qio_channel_fd_source_dispatch 
/io/channel-watch.c:84:12
  #15 0x7f0028f60897 in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897)
  #16 0x55af3c51137b in glib_pollfds_poll /util/main-loop.c:217:9
  #17 0x55af3c50eaab in os_host_main_loop_wait /util/main-loop.c:240:5
  #18 0x55af3c50e444 in main_loop_wait /util/main-loop.c:516:11
  #19 0x55af39b16d00 in qemu_main_loop /softmmu/vl.c:1676:9
  #20 0x55af3c151261 in main /softmmu/main.c:49:5
  #21 0x7f0027ae6e0a in __libc_start_main 
/build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
  #22 0x55af38ff5729 in _start 
(/home/alxndr/Development/qemu/general-fuzz/build/hppa-softmmu/qemu-system-hppa+0x22d4729)

  AddressSanitizer can not provide additional info.
  SUMMARY: AddressSanitizer: SEGV /hw/display/artist.c:525:13 in block_move
  ==12686==ABORTING

  The error occurs even with Message-Id:
  <20200804140056.7690-1-del...@gmx.de> applied (I collected the above
  trace with the patch-set applied)

  Thanks
  -Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890310/+subscriptions

[Bug 1894836] Re: kernel panic using hvf with CPU passthrough

[Thomas Huth]

Fixed in commit 65baabca22366e5246955474228908d6a8354881

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1894836

Title:
  kernel panic using hvf with CPU passthrough

Status in QEMU:
  Fix Released

Bug description:
  Host Details
  QEMU 5.1 (Homebrew)
  macOS 10.15.6 Catalina
  Late 2014 iMac
  i5-4690 @ 3.5 GHz
  8 GB RAM

  Guest Details
  Ubuntu Desktop 20.04.1 Installer ISO

  Problem
  Whenever I boot with "-accel hvf -cpu host", the Ubuntu desktop installer 
will immediately crash with a kernel panic after the initial splash screen.
  See the attached picture of the kernel panic for more details.

  Steps to recreate
  From 
https://www.jwillikers.com/posts/virtualize_ubuntu_desktop_on_macos_with_qemu/

  1. Install QEMU with Homebrew.
  $ brew install qemu

  2. Create a qcow2 disk image to which to install.
  $ qemu-img create -f qcow2 ubuntu2004.qcow2 60G

  3. Download the ISO.
  $ curl -L -o ubuntu-20.04.1-desktop-amd64.iso 
https://releases.ubuntu.com/20.04/ubuntu-20.04.1-desktop-amd64.iso

  4. Run the installer in QEMU.
  $ qemu-system-x86_64 \
    -accel hvf \
    -cpu host \
    -smp 2 \
    -m 4G \
    -usb \
    -device usb-tablet \
    -vga virtio \
    -display default,show-cursor=on \
    -device virtio-net,netdev=vmnic -netdev user,id=vmnic \
    -audiodev coreaudio,id=snd0 \
    -device ich9-intel-hda -device hda-output,audiodev=snd0 \
    -cdrom ubuntu-20.04.1-desktop-amd64.iso \
    -drive file=ubuntu2004.qcow2,if=virtio

  Workaround
  Emulating the CPU with "-cpu qemu64" does not result in a kernel panic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1894836/+subscriptions

[Bug 1895310] Re: Heap-overflow (read) in sd_erase

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1895310

Title:
  Heap-overflow (read) in sd_erase

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  One more bug in sd ...

  cat << EOF | ./qemu-system-i386 -nodefaults \
  -device sdhci-pci,sd-spec-version=3 \
  -device sd-card,drive=mydrive \
  -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \
  -nographic -qtest stdio -m 64m -trace 'sd*'
  outl 0xcf8 0x80001003
  outl 0xcfc 0xd735d735
  outl 0xcf8 0x80001011
  outl 0xcfc 0x3405064c
  write 0x5064c2c 0x1 0xd7
  write 0x5064c0f 0x1 0xf7
  write 0x5064c05 0x1 0xd7
  write 0x5064c0a 0x1 0x84
  write 0x5064c0b 0x1 0x4c
  write 0x5064c0c 0x1 0x11
  write 0x5064c0f 0x1 0xa9
  write 0x5064c0f 0x1 0x02
  write 0x5064c0f 0x1 0x03
  write 0x5064c0e 0x1 0x2c
  write 0x5064c0f 0x1 0x06
  write 0x5064c0f 0x1 0xe1
  write 0x5064c0f 0x1 0x60
  write 0x5064c0f 0x1 0x26
  EOF

  The crash:
  ==133840==ERROR: AddressSanitizer: heap-buffer-overflow on address 
0x60759e78 at pc 0x55abd1d761e6 bp 0x7ffc12800630 sp 0x7ffc12800628
  READ of size 8 at 0x60759e78 thread T0
  #0 0x55abd1d761e5 in test_bit 
/home/alxndr/Development/qemu/general-fuzz/include/qemu/bitops.h:135:19
  #1 0x55abd1d6cb1e in sd_erase 
/home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:771:13
  #2 0x55abd1d4c893 in sd_normal_command 
/home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:1412:13
  #3 0x55abd1d33c5d in sd_do_command 
/home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sd.c:1724:17
  #4 0x55abd20117a4 in sdbus_do_command 
/home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/core.c:99:16
  #5 0x55abd27ecc90 in sdhci_send_command 
/home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:326:12
  #6 0x55abd27e16ed in sdhci_write 
/home/alxndr/Development/qemu/general-fuzz/build/../hw/sd/sdhci.c:1136:9
  #7 0x55abd43aacc0 in memory_region_write_accessor 
/home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:483:5
  #8 0x55abd43aa19d in access_with_adjusted_size 
/home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:544:18
  #9 0x55abd43a7e50 in memory_region_dispatch_write 
/home/alxndr/Development/qemu/general-fuzz/build/../softmmu/memory.c:1466:16
  #10 0x55abd3de5dc6 in flatview_write_continue 
/home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3176:23
  #11 0x55abd3dced98 in flatview_write 
/home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3216:14
  #12 0x55abd3dce8c8 in address_space_write 
/home/alxndr/Development/qemu/general-fuzz/build/../exec.c:3308:18
  #13 0x55abd3ffabbc in qtest_process_command 
/home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:567:9
  #14 0x55abd3feb8be in qtest_process_inbuf 
/home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:710:9
  #15 0x55abd3fea663 in qtest_read 
/home/alxndr/Development/qemu/general-fuzz/build/../softmmu/qtest.c:722:5
  #16 0x55abd51cb9a2 in qemu_chr_be_write_impl 
/home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:188:9
  #17 0x55abd51cbaea in qemu_chr_be_write 
/home/alxndr/Development/qemu/general-fuzz/build/../chardev/char.c:200:9
  #18 0x55abd51e6264 in fd_chr_read 
/home/alxndr/Development/qemu/general-fuzz/build/../chardev/char-fd.c:68:9
  #19 0x55abd515bef6 in qio_channel_fd_source_dispatch 
/home/alxndr/Development/qemu/general-fuzz/build/../io/channel-watch.c:84:12
  #20 0x7fd5d58bd4cd in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x504cd)
  #21 0x55abd54db327 in glib_pollfds_poll 
/home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:217:9
  #22 0x55abd54d8c27 in os_host_main_loop_wait 
/home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:240:5
  #23 0x55abd54d8607 in main_loop_wait 
/home/alxndr/Development/qemu/general-fuzz/build/../util/main-loop.c:516:11
  #24 0x55abd3d55afd in qemu_main_loop 
/home/alxndr/Development/qemu/general-fuzz/build/../softmmu/vl.c:1676:9
  #25 0x55abd16df67c in main 
/home/alxndr/Development/qemu/general-fuzz/build/../softmmu/main.c:50:5
  #26 0x7fd5d4ec0cc9 in __libc_start_main csu/../csu/libc-start.c:308:16
  #27 0x55abd1634e59 in _start 
(/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2d3ee59)

  0x60759e78 is located 0 bytes to the right of 72-byte region 
[0x60759e30,0x60759e78)
  allocated by thread T0 here:
  #0 0x55abd16ad712 in calloc 
(/home/alxndr/Development/qemu/general-fuzz/build/qemu-system-i386+0x2db7712)
  #1 0x55abd1d75464 in bitmap_try_new 
/home/alxndr/Development/qemu/general-fuzz/include/qemu/bitmap.h:96:12
  #2 0x55abd1d74bd4 in bitmap_new 
/home/alxndr/Development/qemu

[Bug 1887309] Re: Floating-point exception in ide_set_sector

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1887309

Title:
  Floating-point exception in ide_set_sector

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Here is a reproducer:
  cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\
   -qtest null -nographic -vga qxl -qtest stdio -nodefaults\
   -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\
   -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\
   -device ide-cd,drive=drive0 -device ide-hd,drive=drive1
  outw 0x176 0x3538
  outl 0xcf8 0x8903
  outl 0xcfc 0x184275c
  outb 0x376 0x2f
  outb 0x376 0x0
  outw 0x176 0xa1a4
  outl 0xcf8 0x8920
  outb 0xcfc 0xff
  outb 0xf8 0x9
  EOF

  The stack-trace:
  ==16513==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 
0x556783603fdc (pc 0x556783603fdc bp 0x7fff82143b10 sp 0x7fff82143ab0 T16513)
  #0 0x556783603fdc in ide_set_sector 
/home/alxndr/Development/qemu/hw/ide/core.c:626:26
  #1 0x556783603fdc in ide_dma_cb 
/home/alxndr/Development/qemu/hw/ide/core.c:883:9
  #2 0x55678349d74d in dma_complete 
/home/alxndr/Development/qemu/dma-helpers.c:120:9
  #3 0x55678349d74d in dma_blk_cb 
/home/alxndr/Development/qemu/dma-helpers.c:138:9
  #4 0x556783962f25 in blk_aio_complete 
/home/alxndr/Development/qemu/block/block-backend.c:1402:9
  #5 0x556783962f25 in blk_aio_complete_bh 
/home/alxndr/Development/qemu/block/block-backend.c:1412:5
  #6 0x556783ac030f in aio_bh_call 
/home/alxndr/Development/qemu/util/async.c:136:5
  #7 0x556783ac030f in aio_bh_poll 
/home/alxndr/Development/qemu/util/async.c:164:13
  #8 0x556783a9a863 in aio_dispatch 
/home/alxndr/Development/qemu/util/aio-posix.c:380:5
  #9 0x556783ac1b4c in aio_ctx_dispatch 
/home/alxndr/Development/qemu/util/async.c:306:5
  #10 0x7f4f1c0fe9ed in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed)
  #11 0x556783acdccb in glib_pollfds_poll 
/home/alxndr/Development/qemu/util/main-loop.c:219:9
  #12 0x556783acdccb in os_host_main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:242:5
  #13 0x556783acdccb in main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:518:11
  #14 0x5567833613e5 in qemu_main_loop 
/home/alxndr/Development/qemu/softmmu/vl.c:1664:9
  #15 0x556783a07a4d in main 
/home/alxndr/Development/qemu/softmmu/main.c:49:5
  #16 0x7f4f1ac84e0a in __libc_start_main 
/build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
  #17 0x5567830a9089 in _start 
(/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x7d2089)

  With -trace ide*

  12163@1594585516.671265:ide_reset IDEstate 0x56162a269058
  [R +0.024963] outw 0x176 0x3538
  12163@1594585516.673676:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); 
val 0x38; bus 0x56162a268c00 IDEState 0x56162a268c88
  12163@1594585516.673683:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 
0x35; bus 0x56162a268c00 IDEState 0x56162a269058
  12163@1594585516.673686:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 
0x56162a269058; cmd 0x35
  OK
  [S +0.025002] OK
  [R +0.025012] outl 0xcf8 0x8903
  OK
  [S +0.025018] OK
  [R +0.025026] outl 0xcfc 0x184275c
  OK
  [S +0.025210] OK
  [R +0.025219] outb 0x376 0x2f
  12163@1594585516.673916:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); 
val 0x2f; bus 0x56162a268c00
  OK
  [S +0.025229] OK
  [R +0.025234] outb 0x376 0x0
  12163@1594585516.673928:ide_cmd_write IDE PIO wr @ 0x376 (Device Control); 
val 0x00; bus 0x56162a268c00
  OK
  [S +0.025240] OK
  [R +0.025246] outw 0x176 0xa1a4
  12163@1594585516.673940:ide_ioport_write IDE PIO wr @ 0x176 (Device/Head); 
val 0xa4; bus 0x56162a268c00 IDEState 0x56162a269058
  12163@1594585516.673943:ide_ioport_write IDE PIO wr @ 0x177 (Command); val 
0xa1; bus 0x56162a268c00 IDEState 0x56162a268c88
  12163@1594585516.673946:ide_exec_cmd IDE exec cmd: bus 0x56162a268c00; state 
0x56162a268c88; cmd 0xa1
  OK
  [S +0.025265] OK
  [R +0.025270] outl 0xcf8 0x8920
  OK
  [S +0.025274] OK
  [R +0.025279] outb 0xcfc 0xff
  OK
  [S +0.025443] OK
  [R +0.025451] outb 0xf8 0x9
  12163@1594585516.674221:ide_dma_cb IDEState 0x56162a268c88; sector_num=0 n=1 
cmd=DMA READ
  OK
  [S +0.025724] OK
  UndefinedBehaviorSanitizer:DEADLYSIGNAL
  ==12163==ERROR: UndefinedBehaviorSanitizer: FPE on unknown address 
0x5616279cffdc (pc 0x5616279cffdc bp 0x7ffcdaabae90 sp 0x7ffcdaabae30 T12163)

  -Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1887309/+subscriptions

[Bug 1891341] Re: Heap-use-after-free in usb_packet_copy through iov_to_buf

[Thomas Huth]

Fixed in commit 21bc31524e8ca487e976f713b878d7338ee00df2

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1891341

Title:
  Heap-use-after-free in usb_packet_copy through iov_to_buf

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Reproducer:

  cat << EOF | ./i386-softmmu/qemu-system-i386 -device nec-usb-xhci \
  -trace usb\* -device usb-audio -device usb-storage,drive=mydrive \
  -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \
  -nodefaults -nographic -qtest stdio
  outl 0xcf8 0x80001016
  outl 0xcfc 0x3c009f0d
  outl 0xcf8 0x80001004
  outl 0xcfc 0xc77695e
  writel 0x9f0d0040 0x3655
  writeq 0x9f0d2000 0xff2f9e00
  write 0x1d 0x1 0x27
  write 0x2d 0x1 0x2e
  write 0x17232 0x1 0x03
  write 0x17254 0x1 0x06
  write 0x17278 0x1 0x34
  write 0x3d 0x1 0x27
  write 0x40 0x1 0x2e
  write 0x41 0x1 0x72
  write 0x42 0x1 0x01
  write 0x4d 0x1 0x2e
  write 0x4f 0x1 0x01
  writeq 0x9f0d2000 0x5c051a01
  write 0x34001d 0x1 0x13
  write 0x340026 0x1 0x30
  write 0x340028 0x1 0x08
  write 0x34002c 0x1 0xfe
  write 0x34002d 0x1 0x08
  write 0x340037 0x1 0x5e
  write 0x34003a 0x1 0x05
  write 0x34003d 0x1 0x05
  write 0x34004d 0x1 0x13
  writeq 0x9f0d2000 0xff0001010049
  EOF

  
  Abridged trace:
  ...
  [R +0.032356] writel 0x9f0d0040 0x3655
  4760@1597243414.491762:usb_xhci_oper_write off 0x, val 0x3655
  4760@1597243414.491765:usb_xhci_run
  4760@1597243414.491769:usb_xhci_irq_intx level 0
  OK
  [S +0.032371] OK
  [R +0.032376] writeq 0x9f0d2000 0xff2f9e00
  4760@1597243414.491784:usb_xhci_doorbell_write off 0x, val 0x
  4760@1597243414.491793:usb_xhci_fetch_trb addr 0x, 
TRB_RESERVED, p 0x, s 0x, c 0x
  4760@1597243414.491798:usb_xhci_doorbell_write off 0x0004, val 0xff2f9e00
  OK
  [S +0.032400] OK
  ...

  [R +0.032495] writeq 0x9f0d2000 0x5c051a01
  4760@1597243414.491899:usb_xhci_doorbell_write off 0x, val 0x
  4760@1597243414.491902:usb_xhci_fetch_trb addr 0x0010, 
CR_ENABLE_SLOT, p 0x, s 0x, c 0x2700
  4760@1597243414.491906:usb_xhci_slot_enable slotid 1
  4760@1597243414.491909:usb_xhci_fetch_trb addr 0x0020, 
CR_ADDRESS_DEVICE, p 0x, s 0x, c 0x2e00
  4760@1597243414.491914:usb_xhci_fetch_trb addr 0x0030, 
CR_ENABLE_SLOT, p 0x, s 0x, c 0x2700
  4760@1597243414.491917:usb_xhci_slot_enable slotid 2
  4760@1597243414.491920:usb_xhci_fetch_trb addr 0x0040, 
CR_ADDRESS_DEVICE, p 0x0001722e, s 0x, c 0x01002e00
  4760@1597243414.491925:usb_xhci_slot_address slotid 1, port 2
  4760@1597243414.491931:usb_xhci_ep_enable slotid 1, epid 1
  4760@1597243414.491937:usb_xhci_fetch_trb addr 0x0050, 
TRB_RESERVED, p 0x, s 0x, c 0x
  4760@1597243414.491941:usb_xhci_doorbell_write off 0x0004, val 0x5c051a01
  4760@1597243414.491945:usb_xhci_ep_kick slotid 1, epid 1, streamid 23557
  4760@1597243414.491955:usb_xhci_fetch_trb addr 0x0034, 
TRB_RESERVED, p 0x, s 0x, c 0x
  OK
  [S +0.032563] OK
  ...

  OK
  [S +0.032643] OK
  [R +0.032648] writeq 0x9f0d2000 0xff0001010049
  4760@1597243414.492052:usb_xhci_doorbell_write off 0x, val 0x0049
  4760@1597243414.492055:usb_xhci_doorbell_write off 0x0004, val 0xff000101
  4760@1597243414.492058:usb_xhci_ep_kick slotid 1, epid 1, streamid 65280
  4760@1597243414.492063:usb_xhci_fetch_trb addr 0x00340010, TR_STATUS, 
p 0x, s 0x, c 0x1300
  4760@1597243414.492067:usb_xhci_xfer_start 0x61145140: slotid 1, epid 1, 
streamid 0
  4760@1597243414.492074:usb_xhci_fetch_trb addr 0x00340020, TR_SETUP, 
p 0x0030, s 0x0008, c 0x08fe
  4760@1597243414.492078:usb_xhci_fetch_trb addr 0x00340030, TR_NORMAL, 
p 0x5e00, s 0x0005, c 0x0500
  4760@1597243414.492081:usb_xhci_fetch_trb addr 0x00340040, TR_STATUS, 
p 0x, s 0x, c 0x1300
  4760@1597243414.492084:usb_xhci_xfer_start 0x61145280: slotid 1, epid 1, 
streamid 0
  4760@1597243414.492089:usb_packet_state_change bus 0, port 2, ep 0, packet 
0x61145288, state undef -> setup
  =
  ==4760==ERROR: AddressSanitizer: heap-use-after-free on address 
0x625000341000 at pc 0x562d20cd6847 bp 0x7ffccc326780 sp 0x7ffccc325f48
  READ of size 48 at 0x625000341000 thread T0
  #0 0x562d20cd6846 in __asan_memcpy 
(build/i386-softmmu/qemu-system-i386+0x250d846)
  #1 0x562d22a6b374 in iov_to_buf_full util/iov.c:52:13
  #2 0x562d21ee5139 in iov_to_buf inclu

[Bug 1888918] Re: qemu-system-ppc: Floating point instructions do not properly generate the SPE/Embedded Floating-Point Unavailable interrupt

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1888918

Title:
  qemu-system-ppc: Floating point instructions do not properly generate
  the SPE/Embedded Floating-Point Unavailable interrupt

Status in QEMU:
  Fix Released

Bug description:
  When emulating certain floating point instructions or vector
  instructions on PowerPC machines, QEMU does not properly generate the
  SPE/Embedded Floating-Point Unavailable interrupt.

  As described in the Signal Processing Engine (SPE) Programming
  Environments Manual, Rev. 0, available at https://www.nxp.com/docs/en
  /reference-manual/SPEPEM.pdf:

  > An SPE/embedded floating-point unavailable exception occurs on an attempt 
to execute any of the
  > following instructions and MSR[SPV] is not set:
  > * SPE instruction (except brinc)
  > * An embedded scalar double-precision instruction
  > * A vector single-precision floating-point instructions
  > It is not used by embedded scalar single-precision floating-point 
instructions

  This behavior was partially reported in Bug #1611394, however the
  issue is larger than what is described in that bug. As mentioned in
  that bug, some single-precision instructions generate the exception
  (while they should not), which is incorrect but does not typically
  produce an incorrect output. What is more of an issue is that several
  double-precision and vector instructions do not generate the exception
  (while they should), and this breaks support for lazy FPU/vector
  context switching in Linux (for example).

  The upper 32-bit of the double-precision/vector registers (which are
  in fact hidden in the general purpose registers) is not properly
  saved/restored, and this causes arithmetic errors. This was observed
  very frequently on a commercial project that does a lot of double-
  precision computations. The application works perfectly fine on an
  MPC8548 CPU, but fails often with QEMU.

  This is only an issue with full platform emulation - the SPE/Embedded
  Floating-Point Unavailable interrupt is not relevant for application
  emulation.

  The issue can be reproduced using the attached Linux program "spe-
  bug.c". This program properly prints the number 42 (as the result of
  some very simple double-precision computation) on real PowerPC
  hardware, but prints an incorrect result (typically 0) on QEMU.

  This issue was first discovered in an older version of QEMU, but is
  also reproduced in the latest:

  # git rev-parse HEAD
  7adfbea8fd1efce36019a0c2f198ca73be9d3f18
  # ppc-softmmu/qemu-system-ppc --version
  QEMU emulator version 5.0.91 (v5.1.0-rc1-28-g7adfbea8fd-dirty)
  Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers

  Upon further analysis a total of 39 instructions are misbehaving:

  efsabs: raised: 1, expected: 0
  efsnabs: raised: 1, expected: 0
  efsneg: raised: 1, expected: 0
  efdcfs: raised: 0, expected: 1
  efdcfsf: raised: 0, expected: 1
  efdcfsi: raised: 0, expected: 1
  efdcfuf: raised: 0, expected: 1
  efdcfui: raised: 0, expected: 1
  efdctsf: raised: 0, expected: 1
  efdctsi: raised: 0, expected: 1
  efdctsiz: raised: 0, expected: 1
  efdctuf: raised: 0, expected: 1
  efdctui: raised: 0, expected: 1
  efdctuiz: raised: 0, expected: 1
  efscfd: raised: 0, expected: 1
  evfscfsf: raised: 0, expected: 1
  evfscfsi: raised: 0, expected: 1
  evfscfuf: raised: 0, expected: 1
  evfscfui: raised: 0, expected: 1
  evfsctsf: raised: 0, expected: 1
  evfsctsi: raised: 0, expected: 1
  evfsctsiz: raised: 0, expected: 1
  evfsctuf: raised: 0, expected: 1
  evfsctui: raised: 0, expected: 1
  evfsctuiz: raised: 0, expected: 1
  brinc: raised: 0, expected: 1
  efsadd: raised: 1, expected: 0
  efsdiv: raised: 1, expected: 0
  efsmul: raised: 1, expected: 0
  efssub: raised: 1, expected: 0
  evsplatfi: raised: 0, expected: 1
  evsplati: raised: 0, expected: 1
  efscmpeq: raised: 1, expected: 0
  efscmpgt: raised: 1, expected: 0
  efscmplt: raised: 1, expected: 0
  efststeq: raised: 1, expected: 0
  efststgt: raised: 1, expected: 0
  efststlt: raised: 1, expected: 0
  evsel: raised: 0, expected: 1

  When "raised" is 0 and "expected" is 1, this means that the SPE/Embedded 
Floating-Point Unavailable interrupt was not generated while it should have.
  When "raised" is 1 and "expected" is 0, this means that the SPE/Embedded 
Floating-Point Unavailable interrupt was generated while it should not have 
(Bug #1611394).

  A comprehensive program testing all the instructions listed in the
  Signal Processing Engine (SPE) Programming Environments Manual, Rev. 0
  is posted in the comments of this ticket, and can be used to reproduce
  the issue, and validate the future fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1888918/+subscriptions

[Bug 1890290] Re: PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual, kernel-irqchip=on - `KVM is too old to support ic-mode=dual, kernel-irqchip=on`

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890290

Title:
  PowerPC L2(nested virt) kvm guest fails to boot with ic-mode=dual
  ,kernel-irqchip=on - `KVM is too old to support ic-mode=dual,kernel-
  irqchip=on`

Status in QEMU:
  Fix Released

Bug description:
  Env:
  HW: Power 9 DD2.3
  Host L0: 5.8.0-rc5-g8ba4ffcd8
  Qemu: 5.0.50 (v5.0.0-533-gdebe78ce14)
  Libvirt: 6.4.0
  L1: 5.8.0-rc5-ge9919e11e
  qemu_version': '5.0.50 (v5.1.0-rc2-dirty)
  libvirt_version': '6.4.0'
  L2: 5.8.0-rc7-g6ba1b005f

  
  1. boot a L2 KVM guest with `ic-mode=dual,kernel-irqchip=on`

  /usr/bin/virt-install --connect=qemu:///system --hvm --accelerate --name 
'vm1' --machine pseries --memory=8192 --vcpu=8,maxvcpus=8,sockets=1,cores=2,t
  hreads=4 --import --nographics --serial pty --memballoon model=virtio --disk 
path=/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2,bus=virtio,size=10,format=qcow2
 --network
  =bridge=virbr0,model=virtio,mac=52:54:00:e6:fe:f6 --mac=52:54:00:e6:fe:f6 
--boot 
emulator=/usr/share/avocado-plugins-vt/bin/qemu,kernel=/tmp/linux/vmlinux,kernel_args="root=/de
  v/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init initcall_debug 
selinux=0" --noautoconsole --qemu-commandline=" -M 
pseries,ic-mode=dual,kernel-irqchip=on"

  
  ERRORinternal error: process exited while connecting to monitor: 
2020-08-04T11:12:53.304482Z qemu: KVM is too old to support 
ic-mode=dual,kernel-irqchip=on


  
  Qemu Log:
  ```
  /usr/share/avocado-plugins-vt/bin/qemu \
  -name guest=vm1,debug-threads=on \
  -S \
  -object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-5-vm1/master-key.aes
 \
  -machine pseries-5.1,accel=kvm,usb=off,dump-guest-core=off \
  -cpu POWER9 \
  -m 8192 \
  -overcommit mem-lock=off \
  -smp 8,sockets=1,dies=1,cores=2,threads=4 \
  -uuid 20a3351b-2776-4e75-9059-c070fe3dd44b \
  -display none \
  -no-user-config \
  -nodefaults \
  -chardev socket,id=charmonitor,fd=34,server,nowait \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=utc \
  -no-shutdown \
  -boot strict=on \
  -kernel /tmp/linux/vmlinux \
  -append 'root=/dev/vda2 rw console=tty0 console=ttyS0,115200 init=/sbin/init 
initcall_debug selinux=0' \
  -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.0,addr=0x2 \
  -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 \
  -blockdev 
'{"driver":"file","filename":"/home/tests/data/avocado-vt/images/f31-ppc64le.qcow2","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}'
 \
  -blockdev 
'{"node-name":"libvirt-1-format","read-only":false,"driver":"qcow2","file":"libvirt-1-storage","backing":null}'
 \
  -device 
virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1
 \
  -netdev tap,fd=37,id=hostnet0,vhost=on,vhostfd=38 \
  -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:e6:fe:f6,bus=pci.0,addr=0x1 
\
  -chardev pty,id=charserial0 \
  -device spapr-vty,chardev=charserial0,id=serial0,reg=0x3000 \
  -chardev socket,id=charchannel0,fd=39,server,nowait \
  -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
 \
  -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 \
  -M pseries,ic-mode=dual,kernel-irqchip=on \
  -msg timestamp=on
  2020-08-04 11:12:53.169+: Domain id=5 is tainted: custom-argv
  2020-08-04 11:12:53.179+: 11120: info : libvirt version: 6.4.0, package: 
1.fc31 (Unknown, 2020-06-02-05:09:40, ltc-wspoon4.aus.stglabs.ibm.com)
  2020-08-04 11:12:53.179+: 11120: info : hostname: atest-guest
  2020-08-04 11:12:53.179+: 11120: info : virObjectUnref:347 : 
OBJECT_UNREF: obj=0x7fff0c117c40
  char device redirected to /dev/pts/0 (label charserial0)
  2020-08-04T11:12:53.304482Z qemu: KVM is too old to support 
ic-mode=dual,kernel-irqchip=on
  2020-08-04 11:12:53.694+: shutting down, reason=failed
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890290/+subscriptions

[Bug 1890360] Re: Assertion failure in address_space_unmap through virtio-blk

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890360

Title:
  Assertion failure in address_space_unmap through virtio-blk

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Reproducer:
  cat << EOF | ./i386-softmmu/qemu-system-i386 \
  -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \
  -device virtio-blk,drive=mydrive \
  -nodefaults -nographic -qtest stdio
  outl 0xcf8 0x80001010
  outl 0xcfc 0xc001
  outl 0xcf8 0x80001014
  outl 0xcf8 0x80001004
  outw 0xcfc 0x7
  outl 0xc006 0x3aff9090
  outl 0xcf8 0x8000100e
  outl 0xcfc 0x41005e1e
  write 0x3b2 0x1 0x5e
  write 0x3b4 0x1 0x5e
  write 0x3aff5e6 0x1 0x11
  write 0x3aff5eb 0x1 0xc6
  write 0x3aff5ec 0x1 0xc6
  write 0x7 0x1 0xff
  write 0x8 0x1 0xfb
  write 0xc 0x1 0x11
  write 0xe 0x1 0x5e
  write 0x5e8 0x1 0x11
  write 0x5ec 0x1 0xc6
  outl 0x410e 0x10e
  EOF

  
  qemu-fuzz-i386: /exec.c:3623: void address_space_unmap(AddressSpace *, void 
*, hwaddr, _Bool, hwaddr): Assertion `mr != NULL' failed.
  ==789== ERROR: libFuzzer: deadly signal
  #8  in __assert_fail /build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3
  #9  in address_space_unmap /exec.c:3623:9
  #10 in dma_memory_unmap /include/sysemu/dma.h:145:5
  #11 in virtqueue_unmap_sg /hw/virtio/virtio.c:690:9
  #12 in virtqueue_fill /hw/virtio/virtio.c:843:5
  #13 in virtqueue_push /hw/virtio/virtio.c:917:5
  #14 in virtio_blk_req_complete /hw/block/virtio-blk.c:83:5
  #15 in virtio_blk_handle_request /hw/block/virtio-blk.c:671:13
  #16 in virtio_blk_handle_vq /hw/block/virtio-blk.c:780:17
  #17 in virtio_queue_notify_aio_vq /hw/virtio/virtio.c:2324:15
  #18 in virtio_queue_host_notifier_aio_read /hw/virtio/virtio.c:3495:9
  #19 in aio_dispatch_handler /util/aio-posix.c:328:9
  #20 in aio_dispatch_handlers /util/aio-posix.c:371:20
  #21 in aio_dispatch /util/aio-posix.c:381:5
  #22 in aio_ctx_dispatch /util/async.c:306:5
  #23 in g_main_context_dispatch

  
  With -trace virtio\*

  ...
  [S +0.099667] OK
  [R +0.099681] write 0x5ec 0x1 0xc6
  OK
  [S +0.099690] OK
  [R +0.099700] outl 0x410e 0x10e
  29575@1596590112.074339:virtio_queue_notify vdev 0x62d30590 n 0 vq 
0x7f9b93fc9800
  29575@1596590112.074423:virtio_blk_data_plane_start dataplane 0x6060f260
  OK
  [S +0.099833] OK
  29575@1596590112.076459:virtio_queue_notify vdev 0x62d30590 n 0 vq 
0x7f9b93fc9800
  29575@1596590112.076642:virtio_blk_handle_read vdev 0x62d30590 req 
0x61143e80 sector 0 nsectors 0
  29575@1596590112.076651:virtio_blk_req_complete vdev 0x62d30590 req 
0x61143e80 status 1
  qemu-system-i386: /home/alxndr/Development/qemu/general-fuzz/exec.c:3623: 
void address_space_unmap(AddressSpace *, void *, hwaddr, _Bool, hwaddr): 
Assertion `mr != NULL' failed.

  
  -Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890360/+subscriptions

[Bug 1880189] Re: I/O writes make cirrus_invalidate_region() crash

[Thomas Huth]

Fixed in commit 5fcf787582dd911df3a971718010bfca5a20e61d

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880189

Title:
  I/O writes make cirrus_invalidate_region() crash

Status in QEMU:
  Fix Released

Bug description:
  As of commit d19f1ab0, LLVM libFuzzer found:

  qemu-fuzz-i386: hw/display/cirrus_vga.c:646: void 
cirrus_invalidate_region(CirrusVGAState *, int, int, int, int): Assertion 
`off_cur_end >= off_cur' failed.
  ==1336555== ERROR: libFuzzer: deadly signal
  #0 0xaf943ce4 in __sanitizer_print_stack_trace
  #1 0xaf899474 in fuzzer::PrintStackTrace()
  #2 0xaf884c80 in fuzzer::Fuzzer::CrashCallback()
  #3 0x9b4e8568  (linux-vdso.so.1+0x568)
  #4 0x99ac406c in __libc_signal_restore_set 
/build/glibc-w4ZToO/glibc-2.31/signal/../sysdeps/unix/sysv/linux/internal-signals.h:86:3
  #5 0x99ac406c in raise 
/build/glibc-w4ZToO/glibc-2.31/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
  #6 0x99ab0d64 in abort 
/build/glibc-w4ZToO/glibc-2.31/stdlib/abort.c:79:7
  #7 0x99abd5d8 in __assert_fail_base 
/build/glibc-w4ZToO/glibc-2.31/assert/assert.c:92:3
  #8 0x99abd640 in __assert_fail 
/build/glibc-w4ZToO/glibc-2.31/assert/assert.c:101:3
  #9 0xb040768c in cirrus_invalidate_region
  #10 0xb0405404 in cirrus_bitblt_solidfill
  #11 0xb0402a88 in cirrus_bitblt_start
  #12 0xb04046a8 in cirrus_write_bitblt
  #13 0xb0400db4 in cirrus_vga_write_gr
  #14 0xb03fd33c in cirrus_vga_ioport_write
  #15 0xafb41674 in memory_region_write_accessor
  #16 0xafb411ec in access_with_adjusted_size
  #17 0xafb40180 in memory_region_dispatch_write
  #18 0xaf995dfc in flatview_write_continue
  #19 0xaf985bd8 in flatview_write
  #20 0xaf98574c in address_space_write
  #21 0xb110510c in ioport_fuzz_qtest
  #22 0xb1103a48 in i440fx_fuzz_qtest
  #23 0xb11010d8 in LLVMFuzzerTestOneInput

  Reproducer:

  qemu-system-i386 -M isapc,accel=qtest -vga cirrus -qtest stdio << 'EOF'
  outl 0x03b1 0x2fdc1001
  outb 0x03cc 0xe
  outb 0x03cc 0xe
  outb 0x03cc 0x2f
  outb 0x03cc 0xe
  outb 0x03cc 0x2f
  outb 0x03cc 0xe
  outl 0x03cc 0xedc100e
  outb 0x03cc 0x2f
  outl 0x03cc 0xe24f40e
  outl 0x03cc 0x2f23dc12
  outl 0x03cc 0xe23f40e
  outl 0x03cc 0xe31dc12
  outb 0x03cc 0x2f
  outl 0x03cc 0xe2af40e
  outl 0x03cc 0x2f235612
  outl 0x03cc 0xe23f40e
  outl 0x03cc 0xe31dc12
  outb 0x03cc 0x2f
  outl 0x03cc 0x2fdcf40e
  outb 0x03cc 0xe
  outl 0x03cc 0xedc100e
  outb 0x03cc 0x2f
  outl 0x03cc 0xe24f40e
  outl 0x03cc 0xe23dc12
  outb 0x03cc 0x2f
  outl 0x03cc 0xedc100e
  outl 0x03cc 0x2fdc400e
  outb 0x03cc 0xe
  outl 0x03cc 0xe130100e
  outb 0x03cc 0x2f
  outl 0x03cc 0xe23f40e
  outl 0x03cc 0xe31dc12
  outb 0x03cc 0x2f
  outl 0x03cc 0xe33f40e
  outl 0x03cc 0xdc235612
  outb 0x03cc 0xe
  outl 0x03cc 0x2fdc400e
  outb 0x03cc 0xe
  outl 0x03cc 0xfb24100e
  outb 0x03cc 0x2f
  outl 0x03cc 0xdc10dc0e
  outl 0x03cc 0x2f31dc12
  outl 0x03cc 0xe23f40e
  outl 0x03cc 0xe31dc12
  outb 0x03cc 0x2f
  outl 0x03cc 0xe23f40e
  outl 0x03cc 0xe31dc12
  outb 0x03cc 0x2f
  outl 0x03cc 0x1021f40e
  EOF
  qemu-system-i386: hw/display/cirrus_vga.c:645: cirrus_invalidate_region: 
Assertion `off_cur_end >= off_cur' failed.
  Aborted (core dumped)

  (gdb) bt
  #0  0x7f1d019fee35 in raise () at /lib64/libc.so.6
  #1  0x7f1d019e9895 in abort () at /lib64/libc.so.6
  #2  0x7f1d019e9769 in _nl_load_domain.cold () at /lib64/libc.so.6
  #3  0x7f1d019f7566 in annobin_assert.c_end () at /lib64/libc.so.6
  #4  0x5645cb447a37 in cirrus_invalidate_region (s=0x5645cd237540, 
off_begin=2097204, off_pitch=251, bytesperline=1, lines=7169) at 
hw/display/cirrus_vga.c:645
  #5  0x5645cb447cc8 in cirrus_bitblt_solidfill (s=0x5645cd237540, 
blt_rop=0) at hw/display/cirrus_vga.c:704
  #6  0x5645cb448886 in cirrus_bitblt_start (s=0x5645cd237540) at 
hw/display/cirrus_vga.c:1005
  #7  0x5645cb448dd1 in cirrus_write_bitblt (s=0x5645cd237540, 
reg_value=47) at hw/display/cirrus_vga.c:1090
  #8  0x5645cb449b02 in cirrus_vga_write_gr (s=0x5645cd237540, 
reg_index=49, reg_value=47) at hw/display/cirrus_vga.c:1593
  #9  0x5645cb44bb2f in cirrus_vga_ioport_write (opaque=0x5645cd237540, 
addr=975, val=47, size=1) at hw/display/cirrus_vga.c:2686
  #10 0x5645cb1e0d6e in memory_region_write_accessor (mr=0x5645cd247f10, 
addr=31, value=0x7fff178d6c18, size=1, shift=24, mask=255, attrs=...) at 
memory.c:483
  #11 0x5645cb1e0f7f in access_with_adjusted_size (addr=28, 
value=0x7fff178d6c18, size=4, access_size_min=1, access_size_max=1, access_fn=
  0x5645cb1e0c8b , mr=0x5645cd247f10, 
attrs=...) at memory.c:544
  #12 0x5645cb1e3e9d in memory_region_dispatch_write (mr=0x5645cd247f10, 
addr=28, data=791796754, op=MO_32, 

[Bug 1878263] Re: Assertion-failure in scsi_dma_complete, with megasas

[Thomas Huth]

Fixed in commit 4773a5f35b0d83674f92816a226a594b03bbcf60

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1878263

Title:
  Assertion-failure in scsi_dma_complete, with megasas

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  While fuzzing, I found an input that triggers an assertion-failure in 
scsi_dma_complete, with megasas:

  qemu-system-i386: /home/alxndr/Development/qemu/hw/scsi/scsi-
  disk.c:292: void scsi_dma_complete(void *, int): Assertion
  `r->req.aiocb != NULL' failed.

  #3  0x76866092 in __GI___assert_fail (assertion=0x56efa460  
"r->req.aiocb != NULL", file=0x56ef9b20  
"/home/alxndr/Development/qemu/hw/scsi/scsi-disk.c", line=0x124, 
function=0x56efa560 <__PRETTY_FUNCTION__.scsi_dma_complete> "void 
scsi_dma_complete(void *, int)") at assert.c:101
  #4  0x5669d473 in scsi_dma_complete (opaque=0x61640280, 
ret=) at /home/alxndr/Development/qemu/hw/scsi/scsi-disk.c:292
  #5  0x5639c89b in dma_complete (dbs=, ret=) at /home/alxndr/Development/qemu/dma-helpers.c:118
  #6  0x5639c89b in dma_blk_cb (opaque=, ret=) at /home/alxndr/Development/qemu/dma-helpers.c:136
  #7  0x5639bd58 in dma_blk_io (ctx=, sg=, offset=, align=, io_func=, io_func_opaque=, cb=, opaque=, dir=) at /home/alxndr/Development/qemu/dma-helpers.c:232
  #8  0x5669baa5 in scsi_write_data (req=0x61640280) at 
/home/alxndr/Development/qemu/hw/scsi/scsi-disk.c:583
  #9  0x566b5d93 in scsi_req_continue (req=0x61640280) at 
/home/alxndr/Development/qemu/hw/scsi/scsi-bus.c:1337
  #10 0x566f52e3 in megasas_enqueue_req (cmd=, 
is_write=) at 
/home/alxndr/Development/qemu/hw/scsi/megasas.c:1651
  #11 0x566e276f in megasas_handle_io (s=, 
cmd=, frame_cmd=) at 
/home/alxndr/Development/qemu/hw/scsi/megasas.c:1790
  #12 0x566e276f in megasas_handle_frame (s=, 
frame_addr=, frame_count=) at 
/home/alxndr/Development/qemu/hw/scsi/megasas.c:1969
  #13 0x566e276f in megasas_mmio_write (opaque=, 
addr=, val=, size=) at 
/home/alxndr/Development/qemu/hw/scsi/megasas.c:2122
  #14 0x560028d7 in memory_region_write_accessor (mr=, 
addr=, value=, size=, 
shift=, mask=, attrs=...) at 
/home/alxndr/Development/qemu/memory.c:483
  #15 0x56002280 in access_with_adjusted_size (addr=, 
value=, size=, access_size_min=, 
access_size_max=, access_fn=, mr=0x7fffeeb301e0, 
attrs=...) at /home/alxndr/Development/qemu/memory.c:544
  #16 0x56002280 in memory_region_dispatch_write (mr=, 
addr=, data=0x17, op=, attrs=...) at 
/home/alxndr/Development/qemu/memory.c:1476
  #17 0x55f171d4 in flatview_write_continue (fv=, 
addr=0xc1c0, attrs=..., ptr=, len=0x1, addr1=0x7fffae00, 
l=, mr=0x7fffeeb301e0) at 
/home/alxndr/Development/qemu/exec.c:3137
  #18 0x55f0fb98 in flatview_write (fv=0x60638180, addr=, attrs=..., buf=, len=) at 
/home/alxndr/Development/qemu/exec.c:3177

  I can reproduce it in qemu 5.0 using:

  cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -qtest 
stdio -nographic -monitor none -serial none -M q35 -device megasas -device 
scsi-cd,drive=null0 -blockdev driver=null-co,read-zeroes=on,node-name=null0
  outl 0xcf8 0x80001818
  outl 0xcfc 0xc101
  outl 0xcf8 0x8000181c
  outl 0xcf8 0x80001804
  outw 0xcfc 0x7
  outl 0xcf8 0x8000186a
  write 0x14 0x1 0xfe
  write 0x0 0x1 0x02
  outb 0xc1c0 0x17
  EOF

  I also attached the commands to this launchpad report, in case the
  formatting is broken:

  qemu-system-i386 -qtest stdio -nographic -monitor none -serial none -M
  q35 -device megasas -device scsi-cd,drive=null0 -blockdev driver=null-
  co,read-zeroes=on,node-name=null0 < attachment

  Please let me know if I can provide any further info.
  -Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1878263/+subscriptions

[Bug 1892960] Re: Heap-overflow in flatview_read through sdhci_data_transfer

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1892960

Title:
  Heap-overflow in flatview_read through sdhci_data_transfer

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Reproducer:
  cat << EOF | ./qemu-system-i386 -nodefaults \
  -device sdhci-pci,sd-spec-version=3 \
  -device sd-card,drive=mydrive \
  -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \
  -nographic -qtest stdio -accel qtest 
  outl 0xcf8 0x80001010
  outl 0xcfc 0xd7055dba
  outl 0xcf8 0x80001003
  outl 0xcfc 0x86b1d733
  writeq 0xd7055d2b 0x84126e0ed7d7355e
  writeq 0xd7055d23 0x13bd7d7346e0129
  writeq 0xd7055d05 0x615bfb845e05c42c
  write 0x0 0x1 0x39
  write 0x5 0x1 0x06
  write 0x6 0x1 0x35
  write 0x7 0x1 0x01
  write 0x1350600 0x1 0x39
  writew 0xd7055d0e 0x846e
  write 0x1350600 0x1 0x29
  write 0x1350602 0x1 0x1a
  write 0x1350608 0x1 0x39
  clock_step
  writeq 0xd7055d03 0x6d002600
  clock_step
  EOF

  The trace:

  [R +0.077745] outl 0xcf8 0x80001010
  OK
  [S +0.03] OK
  [R +0.077792] outl 0xcfc 0xd7055dba
  OK
  [S +0.077813] OK
  [R +0.077826] outl 0xcf8 0x80001003
  OK
  [S +0.077835] OK
  [R +0.077846] outl 0xcfc 0x86b1d733
  OK
  [S +0.080186] OK
  [R +0.080204] writeq 0xd7055d2b 0x84126e0ed7d7355e
  752161@1598405049.572123:sdhci_access wr8: addr[0x002b] <- 0x005e (94)
  752161@1598405049.572133:sdhci_access wr32: addr[0x002c] <- 0x0ed7d735 
(249026357)
  752161@1598405049.572142:sdhci_access wr16: addr[0x0030] <- 0x126e (4718)
  752161@1598405049.572150:sdhci_access wr8: addr[0x0032] <- 0x0084 (132)
  OK
  [S +0.080255] OK
  [R +0.080267] writeq 0xd7055d23 0x13bd7d7346e0129
  752161@1598405049.572176:sdhci_error Non-sequential access to Buffer Data 
Port registeris prohibited

  752161@1598405049.572181:sdhci_access wr8: addr[0x0023] <- 0x0029 (41)
  752161@1598405049.572187:sdhci_access wr32: addr[0x0024] <- 0xd7346e01 
(3610537473)
  752161@1598405049.572193:sdhci_access wr16: addr[0x0028] <- 0x3bd7 (15319)
  752161@1598405049.572200:sdhci_access wr8: addr[0x002a] <- 0x0001 (1)
  OK
  [S +0.080303] OK
  [R +0.080316] writeq 0xd7055d05 0x615bfb845e05c42c
  752161@1598405049.572226:sdhci_access wr8: addr[0x0005] <- 0x002c (44)
  752161@1598405049.572233:sdhci_access wr16: addr[0x0006] <- 0x05c4 (1476)
  752161@1598405049.572240:sdhci_access wr32: addr[0x0008] <- 0x5bfb845e 
(1543210078)
  752161@1598405049.572247:sdhci_access wr8: addr[0x000c] <- 0x0061 (97)
  OK
  [S +0.080350] OK
  [R +0.080362] write 0x0 0x1 0x39
  OK
  [S +0.080606] OK
  [R +0.080617] write 0x5 0x1 0x06
  OK
  [S +0.080629] OK
  [R +0.080639] write 0x6 0x1 0x35
  OK
  [S +0.080648] OK
  [R +0.080657] write 0x7 0x1 0x01
  OK
  [S +0.080665] OK
  [R +0.080675] write 0x1350600 0x1 0x39
  OK
  [S +0.080863] OK
  [R +0.080875] writew 0xd7055d0e 0x846e
  752161@1598405049.572786:sdhci_send_command CMD132 ARG[0x5bfb845e]
  752161@1598405049.572810:sdhci_error timeout waiting for command response
  752161@1598405049.572822:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39
  752161@1598405049.572827:sdhci_adma link: admasysaddr=0x1350600
  752161@1598405049.572833:sdhci_adma_loop addr=0x, len=0, attr=0x39
  752161@1598405049.572837:sdhci_adma link: admasysaddr=0x0
  752161@1598405049.572842:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39
  752161@1598405049.572845:sdhci_adma link: admasysaddr=0x1350600
  752161@1598405049.572851:sdhci_adma_loop addr=0x, len=0, attr=0x39
  752161@1598405049.572854:sdhci_adma link: admasysaddr=0x0
  752161@1598405049.572859:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39
  752161@1598405049.572862:sdhci_adma link: admasysaddr=0x1350600
  752161@1598405049.572875:sdhci_access wr16: addr[0x000e] <- 0x846e (33902)
  OK
  [S +0.080979] OK
  [R +0.080991] write 0x1350600 0x1 0x29
  OK
  [S +0.081001] OK
  [R +0.081011] write 0x1350602 0x1 0x1a
  OK
  [S +0.081019] OK
  [R +0.081029] write 0x1350608 0x1 0x39
  OK
  [S +0.081037] OK
  [R +0.081045] clock_step
  752161@1598405049.572962:sdhci_adma_loop addr=0x, len=26, attr=0x29
  752161@1598405049.572972:sdhci_adma_loop addr=0x, len=0, attr=0x39
  752161@1598405049.572977:sdhci_adma link: admasysaddr=0x0
  752161@1598405049.572981:sdhci_adma_loop addr=0x01350600, len=0, attr=0x39
  752161@1598405049.572985:sdhci_adma link: admasysaddr=0x1350600
  752161@1598405049.572989:sdhci_adma_loop addr=0x, len=26, attr=0x29
  752161@1598405049.572997:sdhci_adma_loop addr=0x, len=0, attr=0x39
  752161@1598405049.573001:sdhci_adma link: admasysaddr=0x0
  OK 100
  [S +0.081112] OK 100
  [R +0.081126] writeq 0xd7055d03 0x6d002600
  752161@1598405049.573038:sdhci_access wr8: addr[0x0003] <- 0x (0)
  752161@1598405049.573045:sdhci_access wr32: addr[0x0004] <- 0x0026

[Bug 1878642] Re: Assertion failure in pci_bus_get_irq_level

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1878642

Title:
  Assertion failure in pci_bus_get_irq_level

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  I found an input which triggers an assertion failure in pci_bus_get_irq_level:

  qemu-system-i386: /home/alxndr/Development/qemu/hw/pci/pci.c:268: int 
pci_bus_get_irq_level(PCIBus *, int): Assertion `irq_num < bus->nirq' failed.
  Aborted
  #0  0x7686d761 in __GI_raise (sig=sig@entry=0x6) at 
../sysdeps/unix/sysv/linux/raise.c:50
  #1  0x7685755b in __GI_abort () at abort.c:79
  #2  0x7685742f in __assert_fail_base (fmt=0x769bdb48 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x57f9bca0  "irq_num < 
bus->nirq", file=0x57f9bbe0  
"/home/alxndr/Development/qemu/hw/pci/pci.c", line=0x10c, function=) at assert.c:92
  #3  0x76866092 in __GI___assert_fail (assertion=0x57f9bca0  
"irq_num < bus->nirq", file=0x57f9bbe0  
"/home/alxndr/Development/qemu/hw/pci/pci.c", line=0x10c, 
function=0x57f9bc40 <__PRETTY_FUNCTION__.pci_bus_get_irq_level> "int 
pci_bus_get_irq_level(PCIBus *, int)") at assert.c:101
  #4  0x57060c34 in pci_bus_get_irq_level (bus=0x61d96080, 
irq_num=0xef) at /home/alxndr/Development/qemu/hw/pci/pci.c:268
  #5  0x56657391 in ich9_lpc_update_apic (lpc=0x62a06200, gsi=0xff) 
at /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:249
  #6  0x56658ea7 in ich9_set_sci (opaque=0x62a06200, irq_num=0x0, 
level=0x1) at /home/alxndr/Development/qemu/hw/isa/lpc_ich9.c:354
  #7  0x56ccefc6 in qemu_set_irq (irq=0x6062af80, level=0x1) at 
/home/alxndr/Development/qemu/hw/core/irq.c:44
  #8  0x56bc06fd in acpi_update_sci (regs=0x62a06c80, 
irq=0x6062af80) at /home/alxndr/Development/qemu/hw/acpi/core.c:723
  #9  0x56bccb08 in ich9_pm_update_sci_fn (regs=0x62a06c80) at 
/home/alxndr/Development/qemu/hw/acpi/ich9.c:56
  #10 0x56bc10ee in acpi_pm_evt_write (opaque=0x62a06c80, addr=0x2, 
val=0x2049, width=0x2) at /home/alxndr/Development/qemu/hw/acpi/core.c:456
  #11 0x564938b5 in memory_region_write_accessor (mr=0x62a06db0, 
addr=0x2, value=0x7fff9c70, size=0x2, shift=0x0, mask=0x, attrs=...) at 
/home/alxndr/Development/qemu/memory.c:483
  #12 0x5649328a in access_with_adjusted_size (addr=0x2, 
value=0x7fff9c70, size=0x2, access_size_min=0x1, access_size_max=0x4, 
access_fn=0x56493360 , mr=0x62a06db0, 
attrs=...) at /home/alxndr/Development/qemu/memory.c:544
  #13 0x56491df6 in memory_region_dispatch_write (mr=0x62a06db0, 
addr=0x2, data=0x2049, op=MO_16, attrs=...) at 
/home/alxndr/Development/qemu/memory.c:1476
  #14 0x562cbbf4 in flatview_write_continue (fv=0x60633fe0, 
addr=0x5d02, attrs=..., ptr=0x7fffa4e0, len=0x4, addr1=0x2, l=0x2, 
mr=0x62a06db0) at /home/alxndr/Development/qemu/exec.c:3137
  #15 0x562bbad9 in flatview_write (fv=0x60633fe0, addr=0x5d02, 
attrs=..., buf=0x7fffa4e0, len=0x4) at 
/home/alxndr/Development/qemu/exec.c:3177
  #16 0x562bb609 in address_space_write (as=0x5968f940 
, addr=0x5d02, attrs=..., buf=0x7fffa4e0, len=0x4) at 
/home/alxndr/Development/qemu/exec.c:3268
  #17 0x56478c0a in cpu_outl (addr=0x5d02, val=0xedf82049) at 
/home/alxndr/Development/qemu/ioport.c:80
  #18 0x5648166f in qtest_process_command (chr=0x59691d00 
, words=0x6039ef20) at /home/alxndr/Development/qemu/qtest.c:396
  #19 0x5647f187 in qtest_process_inbuf (chr=0x59691d00 
, inbuf=0x6190f680) at /home/alxndr/Development/qemu/qtest.c:710
  #20 0x5647e8b4 in qtest_read (opaque=0x59691d00 , 
buf=0x7fffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 
0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device 
hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device 
hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", size=0xe9) at 
/home/alxndr/Development/qemu/qtest.c:722
  #21 0x579c260c in qemu_chr_be_write_impl (s=0x60f01f30, 
buf=0x7fffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 
0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device 
hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device 
hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", len=0xe9) at 
/home/alxndr/Development/qemu/chardev/char.c:183
  #22 0x579c275b in qemu_chr_be_write (s=0x60f01f30, 
buf=0x7fffca40 "outl 0xcf8 0x8400f841\noutl 0xcfc 0xebed205d\noutl 0x5d02 
0xedf82049\n-M pc-q35-5.0 -device intel-hda,id=hda0 -device 
hda-output,bus=hda0.0 -device hda-micro,bus=hda0.0 -device 
hda-duplex,bus=hda0.0 -display none -nodefaults -nographic\n", len=0xe9) at 
/home/alxndr/Development/qemu/char

[Bug 1884693] Re: Assertion failure in address_space_unmap through ahci_map_clb_address

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1884693

Title:
  Assertion failure in address_space_unmap through ahci_map_clb_address

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Reproducer:
  cat << EOF | ./i386-softmmu/qemu-system-i386 -qtest stdio -monitor none 
-serial none -M pc-q35-5.0 -nographic
  outl 0xcf8 0x8000fa24
  outl 0xcfc 0xe1068000
  outl 0xcf8 0x8000fa04
  outw 0xcfc 0x7
  outl 0xcf8 0x8000fb20
  write 0xe1068304 0x1 0x21
  write 0xe1068318 0x1 0x21
  write 0xe1068384 0x1 0x21
  write 0xe1068398 0x2 0x21
  EOF

  Stack trace:
  #0 0x55bfabfe9ea0 in __libc_start_main 
/build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
  #1 0x55bfabfc8ef9 in __sanitizer_print_stack_trace 
(build/i386-softmmu/qemu-fuzz-i386+0x7b7ef9)
  #2 0x55bfabfaf933 in fuzzer::PrintStackTrace() FuzzerUtil.cpp:210:5
  #3 0x7f88df76110f  (/lib/x86_64-linux-gnu/libpthread.so.0+0x1410f)
  #4 0x7f88df5a4760 in __libc_signal_restore_set 
/build/glibc-GwnBeO/glibc-2.30/signal/../sysdeps/unix/sysv/linux/internal-signals.h:84:10
  #5 0x7f88df5a4760 in raise 
/build/glibc-GwnBeO/glibc-2.30/signal/../sysdeps/unix/sysv/linux/raise.c:48:3
  #6 0x7f88df58e55a in abort /build/glibc-GwnBeO/glibc-2.30/stdlib/abort.c:79:7
  #7 0x7f88df58e42e in __assert_fail_base 
/build/glibc-GwnBeO/glibc-2.30/assert/assert.c:92:3
  #8 0x7f88df59d091 in __assert_fail 
/build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3
  #9 0x55bfabff7182 in address_space_unmap exec.c:3602:9
  #10 0x55bfac4a452f in dma_memory_unmap include/sysemu/dma.h:148:5
  #11 0x55bfac4a452f in map_page hw/ide/ahci.c:254:9
  #12 0x55bfac4a1f98 in ahci_map_clb_address hw/ide/ahci.c:748:5
  #13 0x55bfac4a1f98 in ahci_cond_start_engines hw/ide/ahci.c:276:14
  #14 0x55bfac4a074e in ahci_port_write hw/ide/ahci.c:339:9
  #15 0x55bfac4a074e in ahci_mem_write hw/ide/ahci.c:513:9
  #16 0x55bfac0e0dc2 in memory_region_write_accessor memory.c:483:5
  #17 0x55bfac0e0bde in access_with_adjusted_size memory.c:544:18
  #18 0x55bfac0e0917 in memory_region_dispatch_write memory.c
  #19 0x55bfabffa4fd in flatview_write_continue exec.c:3146:23
  #20 0x55bfabff569b in flatview_write exec.c:3186:14
  #21 0x55bfabff569b in address_space_write exec.c:3280:18
  #22 0x55bfac8982a9 in op_write_pattern tests/qtest/fuzz/general_fuzz.c:407:5
  #23 0x55bfac897749 in general_fuzz tests/qtest/fuzz/general_fuzz.c:481:17
  #24 0x55bfac8930a2 in LLVMFuzzerTestOneInput tests/qtest/fuzz/fuzz.c:136:5
  #25 0x55bfabfb0e68 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned long) FuzzerLoop.cpp:558:15
  #26 0x55bfabfb0485 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned 
long, bool, fuzzer::InputInfo*, bool*) FuzzerLoop.cpp:470:3
  #27 0x55bfabfb18a1 in fuzzer::Fuzzer::MutateAndTestOne() FuzzerLoop.cpp:701:19
  #28 0x55bfabfb2305 in fuzzer::Fuzzer::Loop(std::vector >&) FuzzerLoop.cpp:837:5
  #29 0x55bfabfa2018 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned 
char const*, unsigned long)) FuzzerDriver.cpp:846:6
  #30 0x55bfabfb8722 in main FuzzerMain.cpp:19:10
  #31 0x7f88df58fe0a in __libc_start_main 
/build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
  #32 0x55bfabf97869 in _start (build/i386-softmmu/qemu-fuzz-i386+0x786869)

  The same error can be triggered through  ahci_map_fis_address @ 
hw/ide/ahci.c:721:5
  Found with generic device fuzzer: 
https://patchew.org/QEMU/20200611055651.13784-1-alx...@bu.edu/

  Please let me know if I can provide any further info.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1884693/+subscriptions

[Bug 1900241] Re: [regression][powerpc] some vcpus are found offline inside guest with different vsmt setting from qemu-cmdline and breaks subsequent vcpu hotplug operation (xive)

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1900241

Title:
  [regression][powerpc] some vcpus are found offline inside guest with
  different vsmt setting from qemu-cmdline and breaks subsequent vcpu
  hotplug operation (xive)

Status in QEMU:
  Fix Released

Bug description:
  Env:
  Host: Power9 HW ppc64le

  # lscpu
  Architecture:ppc64le
  Byte Order:  Little Endian
  CPU(s):  128
  On-line CPU(s) list: 24-31,40-159
  Thread(s) per core:  4
  Core(s) per socket:  16
  Socket(s):   2
  NUMA node(s):2
  Model:   2.3 (pvr 004e 1203)
  Model name:  POWER9, altivec supported
  Frequency boost: enabled
  CPU max MHz: 3800.
  CPU min MHz: 2300.
  L1d cache:   1 MiB
  L1i cache:   1 MiB
  L2 cache:8 MiB
  L3 cache:160 MiB
  NUMA node0 CPU(s):   24-31,40-79
  NUMA node8 CPU(s):   80-159
  Vulnerability Itlb multihit: Not affected
  Vulnerability L1tf:  Mitigation; RFI Flush, L1D private per thread
  Vulnerability Mds:   Not affected
  Vulnerability Meltdown:  Mitigation; RFI Flush, L1D private per thread
  Vulnerability Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio)
  Vulnerability Spectre v1:Mitigation; __user pointer sanitization, 
ori31 speculation barrier enabled
  Vulnerability Spectre v2:Mitigation; Software count cache flush 
(hardware accelerated), Software link stack flush
  Vulnerability Srbds: Not affected
  Vulnerability Tsx async abort:   Not affected


  Host Kernel: 5.9.0-0.rc8.28.fc34.ppc64le (Fedora rawhide)
  Guest Kernel: Fedora33(5.8.6-301.fc33.ppc64le)

  Qemu: e12ce85b2c79d83a340953291912875c30b3af06 (qemu/master)

  
  Steps to reproduce:

  Boot below kvm guest: (-M pseries,vsmt=2 -smp 8,cores=8,threads=1)

   /home/sath/qemu/build/qemu-system-ppc64 -name vm1 -M pseries,vsmt=2
  -accel kvm -m 4096  -smp 8,cores=8,threads=1 -nographic -nodefaults
  -serial mon:stdio -vga none -nographic -device virtio-scsi-pci -drive
  file=/home/sath/tests/data/avocado-vt/images/fdevel-
  ppc64le.qcow2,if=none,id=hd0,format=qcow2,cache=none -device scsi-
  hd,drive=hd0

  
  lscpu inside guest:
  Actual:
  [root@atest-guest ~]# lscpu
  Architecture:ppc64le
  Byte Order:  Little Endian
  CPU(s):  8
  On-line CPU(s) list: 0,2,4,6
  Off-line CPU(s) list:1,3,5,7 --NOK
  Thread(s) per core:  1
  Core(s) per socket:  4
  Socket(s):   1
  NUMA node(s):1
  Model:   2.3 (pvr 004e 1203)
  Model name:  POWER9 (architected), altivec supported
  Hypervisor vendor:   KVM
  Virtualization type: para
  L1d cache:   128 KiB
  L1i cache:   128 KiB
  NUMA node0 CPU(s):   0,2,4,6
  Vulnerability Itlb multihit: Not affected
  Vulnerability L1tf:  Mitigation; RFI Flush, L1D private per thread
  Vulnerability Mds:   Not affected
  Vulnerability Meltdown:  Mitigation; RFI Flush, L1D private per thread
  Vulnerability Spec store bypass: Mitigation; Kernel entry/exit barrier (eieio)
  Vulnerability Spectre v1:Mitigation; __user pointer sanitization, 
ori31 
   speculation barrier enabled
  Vulnerability Spectre v2:Mitigation; Software count cache flush 
(hardwar
   e accelerated), Software link stack flush
  Vulnerability Srbds: Not affected
  Vulnerability Tsx async abort:   Not affected

  
  Expected:

  [root@atest-guest ~]# lscpu
  Architecture:ppc64le
  Byte Order:  Little Endian
  CPU(s):  8
  On-line CPU(s) list: 0-7
  Thread(s) per core:  1
  Core(s) per socket:  8
  Socket(s):   1
  NUMA node(s):1
  Model:   2.3 (pvr 004e 1203)
  Model name:  POWER9 (architected), altivec supported
  Hypervisor vendor:   KVM
  Virtualization type: para
  L1d cache:   256 KiB
  L1i cache:   256 KiB
  NUMA node0 CPU(s):   0-7
  Vulnerability Itlb multihit: Not affected
  Vulnerability L1tf:  Mitigation; RFI Flush, L1D private p

[Bug 1890333] Re: [OSS-Fuzz] Issue 26797: qemu:qemu-fuzz-i386-target-generic-fuzz-virtio-blk: ASSERT: addr < cache->len && 2 <= cache->len - addr

[Thomas Huth]

Fix in commit 2d69eba5fe52045b2c8b0d04fd3806414352afc1

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1890333

Title:
  [OSS-Fuzz]  Issue 26797: qemu:qemu-fuzz-i386-target-generic-fuzz-
  virtio-blk: ASSERT: addr < cache->len && 2 <= cache->len - addr

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Reproducer:
  cat << EOF | ./i386-softmmu/qemu-system-i386 \
  -drive id=mydrive,file=null-co://,size=2M,format=raw,if=none \
  -device virtio-blk,drive=mydrive \
  -nodefaults -qtest stdio -nographic
  outl 0xcf8 0x80001001
  outl 0xcfc 0x6574c1ff
  outl 0xcf8 0x8000100e
  outl 0xcfc 0xefe5e1e
  outl 0xe86 0x3aff9090
  outl 0xe84 0x3aff9090
  outl 0xe8e 0xe
  EOF

  qemu-system-i386: 
/home/alxndr/Development/qemu/general-fuzz/include/exec/memory_ldst_cached.inc.h:88:
 void address_space_stw_le_cached(MemoryRegionCache *, hwaddr, uint32_t, 
MemTxAttrs, MemTxResult *): Assertion `addr < cache->len && 2 <= cache->len - 
addr' failed.
  Aborted

  I can trigger similar assertions with other VIRTIO devices, as-well.
  I reported this at some point in Message-ID: 
<20200511033001.dzvtbdhl3oz5p...@mozz.bu.edu> but never created a Launchpad 
issue...
  -Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1890333/+subscriptions

[Bug 1887303] Re: Assertion failure in *bmdma_active_if `bmdma->bus->retry_unit != (uint8_t)-1' failed.

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1887303

Title:
  Assertion failure in *bmdma_active_if `bmdma->bus->retry_unit !=
  (uint8_t)-1' failed.

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  Here is a QTest Reproducer:

  cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\
   -qtest null -nographic -vga qxl -qtest stdio -nodefaults\
   -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\
   -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\
   -device ide-cd,drive=drive0 -device ide-hd,drive=drive1
  outw 0x176 0x3538
  outw 0x376 0x6007
  outw 0x376 0x6b6b
  outw 0x176 0x985c
  outl 0xcf8 0x8903
  outl 0xcfc 0x2f2931
  outl 0xcf8 0x8920
  outb 0xcfc 0x6b
  outb 0x68 0x7
  outw 0x176 0x2530
  EOF

  Here is the call-stack:

  #8 0x7f00e0443091 in __assert_fail 
/build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3
  #9 0x55e163f5a1af in bmdma_active_if 
/home/alxndr/Development/qemu/include/hw/ide/pci.h:59:5
  #10 0x55e163f5a1af in bmdma_prepare_buf 
/home/alxndr/Development/qemu/hw/ide/pci.c:132:19
  #11 0x55e163f4f00d in ide_dma_cb 
/home/alxndr/Development/qemu/hw/ide/core.c:898:17
  #12 0x55e163de86ad in dma_complete 
/home/alxndr/Development/qemu/dma-helpers.c:120:9
  #13 0x55e163de86ad in dma_blk_cb 
/home/alxndr/Development/qemu/dma-helpers.c:138:9
  #14 0x55e1642ade85 in blk_aio_complete 
/home/alxndr/Development/qemu/block/block-backend.c:1402:9
  #15 0x55e1642ade85 in blk_aio_complete_bh 
/home/alxndr/Development/qemu/block/block-backend.c:1412:5
  #16 0x55e16443556f in aio_bh_call 
/home/alxndr/Development/qemu/util/async.c:136:5
  #17 0x55e16443556f in aio_bh_poll 
/home/alxndr/Development/qemu/util/async.c:164:13
  #18 0x55e16440fac3 in aio_dispatch 
/home/alxndr/Development/qemu/util/aio-posix.c:380:5
  #19 0x55e164436dac in aio_ctx_dispatch 
/home/alxndr/Development/qemu/util/async.c:306:5
  #20 0x7f00e16e29ed in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed)
  #21 0x55e164442f2b in glib_pollfds_poll 
/home/alxndr/Development/qemu/util/main-loop.c:219:9
  #22 0x55e164442f2b in os_host_main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:242:5
  #23 0x55e164442f2b in main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:518:11
  #24 0x55e164376953 in flush_events 
/home/alxndr/Development/qemu/tests/qtest/fuzz/fuzz.c:47:9
  #25 0x55e16437b8fa in general_fuzz 
/home/alxndr/Development/qemu/tests/qtest/fuzz/general_fuzz.c:544:17

  =

  Here is the same assertion failure but triggered through a different
  call-stack:

  cat << EOF | ./i386-softmmu/qemu-system-i386 -M pc,accel=qtest\
   -qtest null -nographic -vga qxl -qtest stdio -nodefaults\
   -drive if=none,id=drive0,file=null-co://,file.read-zeroes=on,format=raw\
   -drive if=none,id=drive1,file=null-co://,file.read-zeroes=on,format=raw\
   -device ide-cd,drive=drive0 -device ide-hd,drive=drive1
  outw 0x171 0x2fe9
  outb 0x177 0xa0
  outl 0x170 0x928
  outl 0x170 0x2b923b31
  outl 0x170 0x800a24d7
  outl 0xcf8 0x8903
  outl 0xcfc 0x842700
  outl 0xcf8 0x8920
  outb 0xcfc 0x5e
  outb 0x58 0x7
  outb 0x376 0x5
  outw 0x376 0x11
  outw 0x176 0x3538
  EOF

  Call-stack:
  #8 0x7f00e0443091 in __assert_fail 
/build/glibc-GwnBeO/glibc-2.30/assert/assert.c:101:3
  #9 0x55e163f5a622 in bmdma_active_if 
/home/alxndr/Development/qemu/include/hw/ide/pci.h:59:5
  #10 0x55e163f5a622 in bmdma_rw_buf 
/home/alxndr/Development/qemu/hw/ide/pci.c:187:19
  #11 0x55e163f57577 in ide_atapi_cmd_read_dma_cb 
/home/alxndr/Development/qemu/hw/ide/atapi.c:375:13
  #12 0x55e163f44c55 in ide_buffered_readv_cb 
/home/alxndr/Development/qemu/hw/ide/core.c:650:9
  #13 0x55e1642ade85 in blk_aio_complete 
/home/alxndr/Development/qemu/block/block-backend.c:1402:9
  #14 0x55e1642ade85 in blk_aio_complete_bh 
/home/alxndr/Development/qemu/block/block-backend.c:1412:5
  #15 0x55e16443556f in aio_bh_call 
/home/alxndr/Development/qemu/util/async.c:136:5
  #16 0x55e16443556f in aio_bh_poll 
/home/alxndr/Development/qemu/util/async.c:164:13
  #17 0x55e16440fac3 in aio_dispatch 
/home/alxndr/Development/qemu/util/aio-posix.c:380:5
  #18 0x55e164436dac in aio_ctx_dispatch 
/home/alxndr/Development/qemu/util/async.c:306:5
  #19 0x7f00e16e29ed in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed)
  #20 0x55e164442f2b in glib_pollfds_poll 
/home/alxndr/Development/qemu/util/main-loop.c:219:9
  #21 0x55e164442f2b in os_host_main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:242:5
  #22 0x55e164442f2b in main_loop_wait 
/home/alxndr/Development/qemu/util/mai

[Bug 1878253] Re: null-ptr dereference in address_space_to_flatview through ide

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1878253

Title:
  null-ptr dereference in address_space_to_flatview through ide

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  While fuzzing, I found an input that triggers a null-ptr dereference in
  address_space_to_flatview through ide:

  ==31699==ERROR: AddressSanitizer: SEGV on unknown address 0x0020 (pc 
0x55e0f562bafd bp 0x7ffee92355b0 sp 0x7ffee92354e0 T0)
  ==31699==The signal is caused by a READ memory access.
  ==31699==Hint: address points to the zero page.
  #0 0x55e0f562bafd in address_space_to_flatview 
/home/alxndr/Development/qemu/include/exec/memory.h:693:12
  #1 0x55e0f562bafd in address_space_write 
/home/alxndr/Development/qemu/exec.c:3267:14
  #2 0x55e0f562dd9c in address_space_unmap 
/home/alxndr/Development/qemu/exec.c:3592:9
  #3 0x55e0f5ab8277 in dma_memory_unmap 
/home/alxndr/Development/qemu/include/sysemu/dma.h:145:5
  #4 0x55e0f5ab8277 in dma_blk_unmap 
/home/alxndr/Development/qemu/dma-helpers.c:104:9
  #5 0x55e0f5ab8277 in dma_blk_cb 
/home/alxndr/Development/qemu/dma-helpers.c:139:5
  #6 0x55e0f617a6b8 in blk_aio_complete 
/home/alxndr/Development/qemu/block/block-backend.c:1398:9
  #7 0x55e0f617a6b8 in blk_aio_complete_bh 
/home/alxndr/Development/qemu/block/block-backend.c:1408:5
  #8 0x55e0f6355efb in aio_bh_call 
/home/alxndr/Development/qemu/util/async.c:136:5
  #9 0x55e0f6355efb in aio_bh_poll 
/home/alxndr/Development/qemu/util/async.c:164:13
  #10 0x55e0f63608ce in aio_dispatch 
/home/alxndr/Development/qemu/util/aio-posix.c:380:5
  #11 0x55e0f635799a in aio_ctx_dispatch 
/home/alxndr/Development/qemu/util/async.c:306:5
  #12 0x7f16e85d69ed in g_main_context_dispatch 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e9ed)
  #13 0x55e0f635e384 in glib_pollfds_poll 
/home/alxndr/Development/qemu/util/main-loop.c:219:9
  #14 0x55e0f635e384 in os_host_main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:242:5
  #15 0x55e0f635e384 in main_loop_wait 
/home/alxndr/Development/qemu/util/main-loop.c:518:11
  #16 0x55e0f593d676 in qemu_main_loop 
/home/alxndr/Development/qemu/softmmu/vl.c:1664:9
  #17 0x55e0f6267c6a in main 
/home/alxndr/Development/qemu/softmmu/main.c:49:5
  #18 0x7f16e7186e0a in __libc_start_main 
/build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16
  #19 0x55e0f55727b9 in _start 
(/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x9027b9)

  AddressSanitizer can not provide additional info.
  SUMMARY: AddressSanitizer: SEGV 
/home/alxndr/Development/qemu/include/exec/memory.h:693:12 in 
address_space_to_flatview

  I can reproduce it in qemu 5.0 using:

  cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M pc 
-nographic -drive file=null-co://,if=ide,cache=writeback,format=raw -nodefaults 
-display none -nographic -qtest stdio -monitor none -serial none
  outl 0xcf8 0x8920
  outl 0xcfc 0xc001
  outl 0xcf8 0x8924
  outl 0xcf8 0x8904
  outw 0xcfc 0x7
  outb 0x1f7 0xc8
  outw 0x3f6 0xe784
  outw 0x3f6 0xeb01
  outb 0xc005 0x21
  write 0x2103 0x1 0x4e
  outb 0xc000 0x1b
  outw 0x1f7 0xff35
  EOF

  I also attached the traces to this launchpad report, in case the
  formatting is broken:

  qemu-system-i386 -M pc -nographic -drive file=null-
  co://,if=ide,cache=writeback,format=raw -nodefaults -display none
  -nographic -qtest stdio -monitor none -serial none < attachment

  Please let me know if I can provide any further info.
  -Alex

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1878253/+subscriptions

[Bug 1598029] Re: failed to boot a customized kernel if emulating Broadwell/Skylake

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has be

** Changed in: qemu
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1598029

Title:
  failed to boot a customized kernel if emulating Broadwell/Skylake

Status in QEMU:
  Incomplete

Bug description:
  Hardware: X86-64, Intel(R) Core(TM) i7-6500U( Skylake)
  OS: Linux Mint 18
  Host Kernel: 4.5.7 + PaX/Grsecurity
  Qemu: QEMU emulator version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.2)

  [Reproduction Steps]
  1, Install a Debian 8 in the guest
  2, Install a customized kernel( using same config to Debian 8)
  3, Reboot:
  qemu-system-x86_64 -hda debian8-test.img -boot d  -m 2048 -enable-kvm -usb 
-usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu Broadwell -smp 2

  or

  qemu-system-x86_64 -hda debian8-test.img -boot d  -m 2048 -enable-kvm
  -usb -usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu
  host -smp 2

  [Actual Result]  
  kernel panic or can't login in the system

  [Workaround]
  qemu-system-x86_64 -hda debian8-test.img -boot d  -m 2048 -enable-kvm -usb 
-usbdevice tablet -net nic -net tap,ifname=tap0,script=no -cpu Haswell -smp 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1598029/+subscriptions

Re: [RFC PATCH 00/27] vDPA software assisted live migration

[Jason Wang]

On 2020/12/9 下午11:57, Stefan Hajnoczi wrote:

On Wed, Dec 09, 2020 at 04:26:50AM -0500, Jason Wang wrote:

- Original Message -

On Fri, Nov 20, 2020 at 07:50:38PM +0100, Eugenio Pérez wrote:

This series enable vDPA software assisted live migration for vhost-net
devices. This is a new method of vhost devices migration: Instead of
relay on vDPA device's dirty logging capability, SW assisted LM
intercepts dataplane, forwarding the descriptors between VM and device.

Pros:
+ vhost/vDPA devices don't need to implement dirty memory logging
+ Obsoletes ioctl(VHOST_SET_LOG_BASE) and friends

Cons:
- Not generic, relies on vhost-net-specific ioctls
- Doesn't support VIRTIO Shared Memory Regions
   https://github.com/oasis-tcs/virtio-spec/blob/master/shared-mem.tex

I may miss something but my understanding is that it's the
responsiblity of device to migrate this part?

Good point. You're right.


- Performance (see below)

I think performance will be significantly lower when the shadow vq is
enabled. Imagine a vDPA device with hardware vq doorbell registers
mapped into the guest so the guest driver can directly kick the device.
When the shadow vq is enabled a vmexit is needed to write to the shadow
vq ioeventfd, then the host kernel scheduler switches to a QEMU thread
to read the ioeventfd, the descriptors are translated, QEMU writes to
the vhost hdev kick fd, the host kernel scheduler switches to the vhost
worker thread, vhost/vDPA notifies the virtqueue, and finally the
vDPA driver writes to the hardware vq doorbell register. That is a lot
of overhead compared to writing to an exitless MMIO register!

I think it's a balance. E.g we can poll the virtqueue to have an
exitless doorbell.


If the shadow vq was implemented in drivers/vhost/ and QEMU used the
existing ioctl(VHOST_SET_LOG_BASE) approach, then the overhead would be
reduced to just one set of ioeventfd/irqfd. In other words, the QEMU
dirty memory logging happens asynchronously and isn't in the dataplane.

In addition, hardware that supports dirty memory logging as well as
software vDPA devices could completely eliminate the shadow vq for even
better performance.

Yes. That's our plan. But the interface might require more thought.

E.g is the bitmap a good approach? To me reporting dirty pages via
virqueue is better since it get less footprint and is self throttled.

And we need an address space other than the one used by guest for
either bitmap for virtqueue.


But performance is a question of "is it good enough?". Maybe this
approach is okay and users don't expect good performance while dirty
memory logging is enabled.

Yes, and actually such slow down may help for the converge of the
migration.

Note that the whole idea is try to have a generic solution for all
types of devices. It's good to consider the performance but for the
first stage, it should be sufficient to make it work and consider to
optimize on top.

Moving the shadow vq to the kernel later would be quite a big change
requiring rewriting much of the code. That's why I mentioned this now
before a lot of effort is invested in a QEMU implementation.



Right.





I just wanted to share the idea of moving the
shadow vq into the kernel in case you like that approach better.

My understanding is to keep kernel as simple as possible and leave the
polices to userspace as much as possible. E.g it requires us to
disable doorbell mapping and irq offloading, all of which were under
the control of userspace.

If the performance is acceptable with the QEMU approach then I think
that's the best place to implement it. It looks high-overhead though so
maybe one of the first things to do is to run benchmarks to collect data
on how it performs?



Yes, I agree.

Thanks




Stefan

[Bug 1901981] Re: assert issue locates in hw/usb/dev-storage.c:248: usb_msd_send_status

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1901981

Title:
  assert issue locates in hw/usb/dev-storage.c:248: usb_msd_send_status

Status in QEMU:
  Fix Released

Bug description:
  Hello,

  I found an assertion failure through hw/usb/dev-storage.c.

  This was found in latest version 5.1.0.

  

  qemu-system-x86_64: hw/usb/dev-storage.c:248: usb_msd_send_status: Assertion 
`s->csw.sig == cpu_to_le32(0x53425355)' failed.
  [1]29544 abort  sudo  -enable-kvm -boot c -m 2G -drive 
format=qcow2,file=./ubuntu.img -nic

  To reproduce the assertion failure, please run the QEMU with following
  command line.

  
  $ qemu-system-x86_64 -enable-kvm -boot c -m 2G -drive 
format=qcow2,file=./ubuntu.img -nic 
user,model=rtl8139,hostfwd=tcp:0.0.0.0:-:22 -device piix4-usb-uhci,id=uhci 
-device usb-storage,drive=mydrive -drive 
id=mydrive,file=null-co://,size=2M,format=raw,if=none

  The poc is attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1901981/+subscriptions

[Bug 1895703] Re: performance degradation in tcg since Meson switch

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1895703

Title:
  performance degradation in tcg since Meson switch

Status in QEMU:
  Fix Released

Bug description:
  The buildsys conversion to Meson (1d806cef0e3..7fd51e68c34)
  introduced a degradation in performance in some TCG targets:

  
  Test Program: matmult_double
  
  Target  Instructions PreviousLatest
   1d806cef   7fd51e68
  --    --  --
  alpha  3 233 957 639   - +7.472%
  m68k   3 919 110 506   -+18.433%
  

  Original report from Ahmed Karaman with further testing done
  by Aleksandar Markovic:
  https://www.mail-archive.com/qemu-devel@nongnu.org/msg740279.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1895703/+subscriptions

[Bug 1902112] Re: [OSS-Fuzz] Issue 26693: qemu:qemu-fuzz-i386-target-generic-fuzz-xhci: Index-out-of-bounds in xhci_runtime_write

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1902112

Title:
  [OSS-Fuzz] Issue 26693: qemu:qemu-fuzz-i386-target-generic-fuzz-xhci:
  Index-out-of-bounds in xhci_runtime_write

Status in QEMU:
  Fix Released

Bug description:
  OSS-Fuzz Report: https://bugs.chromium.org/p/oss-
  fuzz/issues/detail?id=26693

  === Reproducer (build with --enable-sanitizers) ===
  export UBSAN_OPTIONS="print_stacktrace=1:silence_unsigned_overflow=1"
  cat << EOF | ./qemu-system-i386 -display none -machine\
   accel=qtest, -m 512M -machine q35 -nodefaults -drive\
   file=null-co://,if=none,format=raw,id=disk0 -device\
   qemu-xhci,id=xhci -device usb-tablet,bus=xhci.0\
   -device usb-bot -device usb-storage,drive=disk0\
   -chardev null,id=cd0 -chardev null,id=cd1 -device\
   usb-braille,chardev=cd0 -device usb-ccid -device\
   usb-ccid -device usb-kbd -device usb-mouse -device\
   usb-serial,chardev=cd1 -device usb-tablet -device\
   usb-wacom-tablet -device usb-audio -qtest stdio
  outl 0xcf8 0x8803
  outl 0xcfc 0x18ca
  outl 0xcf8 0x8810
  outl 0xcfc 0x555a2e46
  write 0x555a1004 0x4 0xe7b9aa7a
  EOF

  === Stack Trace ===

  SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
../hw/usb/hcd-xhci.c:3012:30 in
  ../hw/usb/hcd-xhci.c:3012:30: runtime error: index -1 out of bounds for type 
'XHCIInterrupter [16]'
  #0 0x55bd2e97c8b0 in xhci_runtime_write /src/qemu/hw/usb/hcd-xhci.c:3012:30
  #1 0x55bd2edfdd13 in memory_region_write_accessor 
/src/qemu/softmmu/memory.c:484:5
  #2 0x55bd2edfdb14 in access_with_adjusted_size 
/src/qemu/softmmu/memory.c:545:18
  #3 0x55bd2edfd54b in memory_region_dispatch_write 
/src/qemu/softmmu/memory.c:0:13
  #4 0x55bd2ed7fa46 in flatview_write_continue 
/src/qemu/softmmu/physmem.c:2767:23
  #5 0x55bd2ed7cac0 in flatview_write /src/qemu/softmmu/physmem.c:2807:14
  #6 0x55bd2ed7c9f8 in address_space_write /src/qemu/softmmu/physmem.c:2899:18
  #7 0x55bd2e85cf9b in __wrap_qtest_writeq 
/src/qemu/tests/qtest/fuzz/qtest_wrappers.c:187:9
  #8 0x55bd2e85b7b1 in op_write /src/qemu/tests/qtest/fuzz/generic_fuzz.c:476:13
  #9 0x55bd2e85a84c in generic_fuzz 
/src/qemu/tests/qtest/fuzz/generic_fuzz.c:678:17
  #10 0x55bd2e85dd6f in LLVMFuzzerTestOneInput 
/src/qemu/tests/qtest/fuzz/fuzz.c:150:5
  #11 0x55bd2e7e9661 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:595:15
  #12 0x55bd2e7d4732 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, 
unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:323:6
  #13 0x55bd2e7da7ee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned 
char const*, unsigned long)) 
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:852:9
  #14 0x55bd2e8027d2 in main 
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
  #15 0x7f3d153b783f in __libc_start_main

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1902112/+subscriptions

[Bug 1826200] Re: RFE: populate "OEM Strings" (type 11) SMBIOS table strings from regular files

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1826200

Title:
  RFE: populate "OEM Strings" (type 11) SMBIOS table strings from
  regular files

Status in QEMU:
  Fix Released

Bug description:
  The feature added in

  
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd

  and exposed by libvirt as

https://libvirt.org/formatdomain.html#elementsSysinfo

  allows the user to specify up to 255 strings in the unofmatted area of
  the Type 11 SMBIOS table, where each string may be of arbitrary
  length. This feature is useful for exposing arbitrary text to
  arbitrary guest components (in particular when strings are prefixed
  with "application identifiers").

  Right now, strings can only be specified on the QEMU command line,
  which limits the amount of data that can be passed. Please enable
  users to pass data from regular files too.

  For example:

$QEMU -smbios
  type=11,value=Hello,txtfile=file1.txt,txtfile=file2.txt

  where "file1.txt" and "file2.txt" could be text files containing ASCII
  application prefixes, followed by base64-encoded binary data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1826200/+subscriptions

[Bug 1598612] Re: Windows for Workgroups 3.11 installer crashes with a general protection fault

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has be

** Changed in: qemu
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1598612

Title:
  Windows for Workgroups 3.11 installer crashes with a general
  protection fault

Status in QEMU:
  Incomplete

Bug description:
  I used only disk images from here:
  
http://ia801606.us.archive.org/zipview.php?zip=/22/items/IBM_PC_Compatibles_TOSEC_2012_04_23/IBM_PC_Compatibles_TOSEC_2012_04_23.zip

  When I try to install Windows for Workgroups 3.11 on either PC DOS
  2000 or MS-DOS 6.22, the installer crashes after entering the
  graphical part with two dialogs containing:

  Application Error
  WINSETUP caused a General Protection Fault in module 
0EDF:7011WINSETUP will close.

  Application Error
  WINSETUP caused a General Protection Fault in module USER.EXE at 0001:40B6.

  And then:
  Standard Mode: Bad Fault in MS-DOS Extender.
  Fault: 000D Stack Dump:   0070
  Raw fault frame: EC= IP=5EF7 CS=037F FL=3087 SP=FFEE SS=02DF

  This happens both with and without KVM. I tested with QEMU from Ubuntu
  14.04 and 16.04 and recent GIT
  (ef8757f1fe8095a256ee617e4dbac69d3b33ae94).

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1598612/+subscriptions

[Bug 1897783] Re: avocado tests not running on aarch64 host

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1897783

Title:
  avocado tests not running on aarch64 host

Status in QEMU:
  Fix Released

Bug description:
  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 20.04.1 LTS
  Release:20.04
  Codename:   focal

  $ make check-venv
VENV/home/phil/qemu/build/tests/venv
PIP /home/phil/qemu/tests/requirements.txt
ERROR: Command errored out with exit status 1:
 command: /home/phil/qemu/build/tests/venv/bin/python -u -c 'import sys, 
setuptools, tokenize; sys.argv[0] = 
'"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"'; 
__file__='"'"'/tmp/pip-install-w1h2bh4a/pycdlib/setup.py'"'"';f=getattr(tokenize,
 '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', 
'"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' 
bdist_wheel -d /tmp/pip-wheel-ic25ctcg
 cwd: /tmp/pip-install-w1h2bh4a/pycdlib/
Complete output (6 lines):
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'bdist_wheel'

ERROR: Failed building wheel for pycdlib
  $

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1897783/+subscriptions

[Bug 1891748] Re: qemu-arm-static 5.1 can't run gcc

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1891748

Title:
  qemu-arm-static 5.1 can't run gcc

Status in QEMU:
  Fix Released
Status in Juju Charms Collection:
  New

Bug description:
  Issue discovered while trying to build pikvm (1)

  Long story short: when using qemu-arm-static 5.1, gcc exits whith
  message:

  Allocating guest commpage: Operation not permitted

  
  when using qemu-arm-static v5.0, gcc "works"

  Steps to reproduce will follow

  (1)  https://github.com/pikvm/pikvm/blob/master/pages/building_os.md

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1891748/+subscriptions

[Bug 1597138] Re: Deadlock on Windows 10 pop-up

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has be

** Changed in: qemu
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1597138

Title:
  Deadlock on Windows 10 pop-up

Status in QEMU:
  Incomplete

Bug description:
  I was able to install and can log in but whenever a pop-up is attempted the 
VM appears to deadlock.
  I can still kill -9 the process and recover but the VM and the QEmu console 
both hang with no error output.

  At first I thought it was UAC but renaming a file causes a pop-up and that 
also deadlocks.
  I rebuilt QEmu 2.6.0 with debug info and did a thread back-trace once the 
deadlock occurs.
  See the attachment for the trace.

  I am attempting to setup GPU pass-thru with a GTX 970 but this
  deadlock occurs with -vga std (and no GPU pass-thru) as well.

  (I cannot install or start Windows 7 but I am told this is a known
  bug.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1597138/+subscriptions

[Bug 1779017] Re: qemu-system-arm: crashes raspian kernels with divide-by-zero

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1779017

Title:
  qemu-system-arm: crashes raspian kernels with divide-by-zero

Status in QEMU:
  Fix Released

Bug description:
  While trying to boot a arm kernel for a raspi2 machine 
(kernel7-4.9.41-stretch.img in my case, but applies to other versions, too) the 
kernel crash with a division by zero. The output on the sreial console is:
  [   10.022377] [<8011d344>] (__warn) from [<8011d42c>] 
(warn_slowpath_null+0x30/0x38)
  [   10.024726] [<8011d42c>] (warn_slowpath_null) from [<804da378>] 
(uart_get_baud_rate+0xf8/0x160)

  ...

  [   10.094933] Hardware name: BCM2835
  [   10.101507] [<8010fb3c>] (unwind_backtrace) from [<8010c058>] 
(show_stack+0x20/0x24)
  [   10.105413] [<8010c058>] (show_stack) from [<80455f84>] 
(dump_stack+0xd4/0x118)
  [   10.140268] [<80455f84>] (dump_stack) from [<8010bed4>] (__div0+0x24/0x28)
  [   10.143065] [<8010bed4>] (__div0) from [<8045498c>] (Ldiv0+0x8/0x14)
  [   10.145553] [<8045498c>] (Ldiv0) from [<804e5538>] 
(pl011_set_termios+0x9c/0x37c)
  [   10.148017] [<804e5538>] (pl011_set_termios) from [<804da954>] 
(uart_change_speed+0x40/0xfc)
  [   10.185887] [<804da954>] (uart_change_speed) from [<804ddedc>] 
(uart_startup.part.3+0xa4/0x13c)
  [   10.222187] [<804ddedc>] (uart_startup.part.3) from [<804ddfcc>] 
(uart_port_activate+0x58/0x64)
  [   10.226014] [<804ddfcc>] (uart_port_activate) from [<804c93b8>] 
(tty_port_open+0xa0/0xe0)
  [   10.228398] [<804c93b8>] (tty_port_open) from [<804dce64>] 
(uart_open+0x40/0x48)
  [   10.264254] [<804dce64>] (uart_open) from [<804c1d70>] 
(tty_open+0xc0/0x678)
  [   10.266697] [<804c1d70>] (tty_open) from [<802753f0>] 
(chrdev_open+0xe0/0x1a0)
  [   10.269049] [<802753f0>] (chrdev_open) from [<8026d964>] 
(do_dentry_open+0x1f4/0x314)
  [   10.271620] [<8026d964>] (do_dentry_open) from [<8026ec00>] 
(vfs_open+0x60/0x8c)
  [   10.275245] [<8026ec00>] (vfs_open) from [<8027f39c>] 
(path_openat+0x2bc/0x1040)
  [   10.312827] [<8027f39c>] (path_openat) from [<80281040>] 
(do_filp_open+0x70/0xd4)
  [   10.317860] [<80281040>] (do_filp_open) from [<8026efd8>] 
(do_sys_open+0x120/0x1d0)
  [   10.320370] [<8026efd8>] (do_sys_open) from [<8026f0b4>] 
(SyS_open+0x2c/0x30)
  [   10.357033] [<8026f0b4>] (SyS_open) from [<801080c0>] 
(ret_fast_syscall+0x0/0x1c)

  Tracking that down in the linux kernel source, it looks like somehow
  uart_get_baud_rate() returns 0.

  The same kernel could be booted without problem with qemu version 2.11.
  Trying to bisecting the issue revealed commit 
@d9f8bbd8eb4e95db97cf02bd03af86a3d606f4f1 as the culprit.

  Commandline to run was:
  qemu-system-arm -M raspi2 \
-kernel "$KERNEL" \
-m 1024 \
-d guest_errors,unimp \
-dtb bcm2709-rpi-2-b.dtb \
-drive file="$IMG,if=sd,format=raw"

  Distribution is SuSE tumbleweed (x86_64, kernel 4.17.2), but same
  problem also happens with a freshly compiled qemu from git repository.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1779017/+subscriptions

[Bug 1894361] Re: linux-user: syscall.c lacks pselect6_time64

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1894361

Title:
  linux-user: syscall.c lacks pselect6_time64

Status in QEMU:
  Fix Released

Bug description:
  in commit 50efc69586388a975c1ebd90cb8cc8e4a7328bc4 ("linux-user/riscv:
  Update the syscall_nr's to the 5.5 kernel") legacy pselect6 definition
  for riscv32 was removed in favour of pselect6_time64, but
  pselect6_time64 is not available in syscall.c, thus leaving riscv32
  without pselect syscall.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1894361/+subscriptions

[Bug 1580586] Re: Qemu WinXP SP3 second loadvm freezes Guest OS

[Thomas Huth]

The QEMU project is currently considering to move its bug tracking to another 
system. For this we need to know which bugs are still valid and which could be 
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state 
back to "New" within the next 60 days, otherwise this report will be marked as 
"Expired". Or mark it as "Fix Released" if the problem has be

** Changed in: qemu
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1580586

Title:
  Qemu WinXP SP3 second loadvm freezes Guest OS

Status in QEMU:
  Incomplete

Bug description:
  Using Qemu-system-i386 to run WinXP SP3 with the following command
  line:

  qemu-system-i386 -hda qcow2/windowsxp_32bits_dd.qcow2 -m 1024  -net
  user,smb=/shared -vga std -net nic,model=rtl8139 -rtc
  base=localtime,clock=vm -s -snapshot

  savevm works fine, and the first loadvm to the snapshot works
  properly, but the next ones will all freeze the guest OS.

  First I thought it was due to the clock but adding the rtc options did
  not fix it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1580586/+subscriptions

Re: [PATCH v2] gitlab-ci.yml: Add openSUSE Leap 15.2 for gitlab CI/CD

[AL Yu-Chen Cho via]

Hi Thomas,

I try to reproduce this failed in my repo, but it seems works fine.
Would you please give it a try again? I think you maybe just hit a bad
point in time...

Cheers,
  AL

On Tue, 2020-12-08 at 07:55 +0100, Thomas Huth wrote:
> On 24/11/2020 10.45, Cho, Yu-Chen wrote:
> > v2:
> > Drop some package from dockerfile to make docker image more light.
> > 
> > v1:
> > Add build-system-opensuse jobs and opensuse-leap.docker dockerfile.
> > Use openSUSE Leap 15.2 container image in the gitlab-CI.
> > 
> > Signed-off-by: Cho, Yu-Chen 
> > ---
> >  .gitlab-ci.d/containers.yml   |  5 ++
> >  .gitlab-ci.yml    | 30 +++
> >  tests/docker/dockerfiles/opensuse-leap.docker | 54
> > +++
> >  3 files changed, 89 insertions(+)
> >  create mode 100644 tests/docker/dockerfiles/opensuse-leap.docker
> 
>  Hi!
> 
> While trying to pick up your patch, I noticed that it is failing now
> in the
> gitlab-CI:
> 
>  https://gitlab.com/huth/qemu/-/jobs/896384459
> 
> Could you please have a look and send a fixed v3?
> 
>  Thanks,
>   Thomas
> 

[Bug 1878043] Re: memcpy param-overlap in Slirp ip_stripoptions through e1000e

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1878043

Title:
  memcpy param-overlap in Slirp ip_stripoptions through e1000e

Status in QEMU:
  Fix Released

Bug description:
  Hello,
  While fuzzing, I found an input that triggers an overlapping memcpy (caught 
by AddressSanitizer).
  Overlapping memcpys are undefined behavior according to the POSIX and C 
standards, and can lead to bugs.

  ==1==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges 
[0x625000264940,0x62500026699a) and [0x625000264948, 0x6250002669a2) overlap
  #0 0x5622d7b6a3d4 in __asan_memcpy 
(/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96c3d4)
  #1 0x5622d896a2d2 in ip_stripoptions 
/home/alxndr/Development/qemu/slirp/src/ip_input.c:457:5
  #2 0x5622d8963378 in udp_input 
/home/alxndr/Development/qemu/slirp/src/udp.c:86:9
  #3 0x5622d89351ea in slirp_input 
/home/alxndr/Development/qemu/slirp/src/slirp.c:840:13
  #4 0x5622d852e162 in net_slirp_receive 
/home/alxndr/Development/qemu/net/slirp.c:126:5
  #5 0x5622d8515851 in nc_sendv_compat 
/home/alxndr/Development/qemu/net/net.c:700:15
  #6 0x5622d8515851 in qemu_deliver_packet_iov 
/home/alxndr/Development/qemu/net/net.c:728:15
  #7 0x5622d851786d in qemu_net_queue_deliver_iov 
/home/alxndr/Development/qemu/net/queue.c:179:11
  #8 0x5622d851786d in qemu_net_queue_send_iov 
/home/alxndr/Development/qemu/net/queue.c:224:11
  #9 0x5622d851b1c1 in net_hub_receive_iov 
/home/alxndr/Development/qemu/net/hub.c:74:9
  #10 0x5622d851b1c1 in net_hub_port_receive_iov 
/home/alxndr/Development/qemu/net/hub.c:125:12
  #11 0x5622d851572b in qemu_deliver_packet_iov 
/home/alxndr/Development/qemu/net/net.c:726:15
  #12 0x5622d851786d in qemu_net_queue_deliver_iov 
/home/alxndr/Development/qemu/net/queue.c:179:11
  #13 0x5622d851786d in qemu_net_queue_send_iov 
/home/alxndr/Development/qemu/net/queue.c:224:11
  #14 0x5622d828bf87 in net_tx_pkt_sendv 
/home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:546:9
  #15 0x5622d828bf87 in net_tx_pkt_send 
/home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:620:9
  #16 0x5622d82b5f22 in e1000e_tx_pkt_send 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:666:16
  #17 0x5622d82b5f22 in e1000e_process_tx_desc 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:743:17
  #18 0x5622d82b5f22 in e1000e_start_xmit 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9
  #19 0x5622d82b2be0 in e1000e_set_tdt 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9
  #20 0x5622d82a30fc in e1000e_core_write 
/home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9
  #21 0x5622d7c9e336 in memory_region_write_accessor 
/home/alxndr/Development/qemu/memory.c:483:5
  #22 0x5622d7c9dcdf in access_with_adjusted_size 
/home/alxndr/Development/qemu/memory.c:544:18
  #23 0x5622d7c9dcdf in memory_region_dispatch_write 
/home/alxndr/Development/qemu/memory.c:1476:16
  #24 0x5622d7bb31d3 in flatview_write_continue 
/home/alxndr/Development/qemu/exec.c:3137:23
  #25 0x5622d7babb97 in flatview_write 
/home/alxndr/Development/qemu/exec.c:3177:14
  #26 0x5622d7babb97 in address_space_write 
/home/alxndr/Development/qemu/exec.c:3268:18

  0x625000264940 is located 64 bytes inside of 8354-byte region 
[0x625000264900,0x6250002669a2)
  allocated by thread T0 here:
  #0 0x5622d7b6b06d in malloc 
(/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96d06d)
  #1 0x7f724b932500 in g_malloc 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500)

  0x625000264948 is located 72 bytes inside of 8354-byte region 
[0x625000264900,0x6250002669a2)
  allocated by thread T0 here:
  #0 0x5622d7b6b06d in malloc 
(/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0x96d06d)
  #1 0x7f724b932500 in g_malloc 
(/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x54500)

  I can reproduce it in qemu 5.0 built with --enable-sanitizers using:
  cat << EOF | ~/Development/qemu/build/i386-softmmu/qemu-system-i386 -M 
pc-q35-5.0 -accel qtest -qtest stdio -nographic -monitor none -serial none
  outl 0xcf8 0x80001010
  outl 0xcfc 0xe102
  outl 0xcf8 0x80001014
  outl 0xcf8 0x80001004
  outw 0xcfc 0x7
  outl 0xcf8 0x800010a2
  outl 0xcf8 0x8000fa24
  outl 0xcfc 0xe1069000
  outl 0xcf8 0x8000fa04
  outw 0xcfc 0x7
  outl 0xcf8 0x8000fb20
  write 0xe1069100 0xe 0xff818420f9e10019
  write 0x820b 0xc 0x080047bb0c02e1004011
  write 0xe1020403 0x36 
0xb7e1000f009006e1625c5eb7e1000f009006e1625c5eb7e1000f009006e1
  EOF

  I also attached the trace to this launchpad report, in case the
  formatting is broken:

  qemu-system-i386 -M pc-q35-5.0 -accel qtest -qtest stdio -nographic
  -monitor n

[Bug 1893667] Re: Btrfs commands don't work when using user-space emulation of other architectures

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1893667

Title:
  Btrfs commands don't work when using user-space emulation of other
  architectures

Status in QEMU:
  Fix Released
Status in qemu package in Fedora:
  Unknown

Bug description:
  Description of problem:
  When doing cross-arch builds with mock, it uses qemu-user-static under the 
hood, and qemu-user-static lacks support for Btrfs ioctls to emulate so that 
btrfs(8) commands work correctly.

  This is especially important for being able to do cross-arch image
  builds.

  How reproducible:
  Always (on Fedora 33 with qemu-5.1.0-2.fc33)

  Steps to Reproduce:

  $ sudo dnf install mock qemu-user-static wget
  $ sudo usermod -a -G mock $USER
  $ newgrp mock
  $ mock --root fedora-rawhide-armhfp --install btrfs-progs util-linux
  $ mock --root fedora-rawhide-armhfp --chroot 'rm -f foo.img && dd 
if=/dev/zero of=foo.img bs=1G count=1 && losetup /dev/loop9 foo.img &&  
mkfs.btrfs /dev/loop9 && mkdir /foo && mount /dev/loop9 /foo && btrfs subvol 
create /foo/subvol && umount /foo && losetup -d /dev/loop9'

  
  Actual results:
  Fails with errors like "ERROR: cannot create subvolume: Function not 
implemented"

  Expected results:
  Succeeds and creates subvolumes properly.

  Additional info:
  There is a patch series from a few days ago to add support for many btrfs 
ioctls which could fix this...

  https://lists.gnu.org/archive/html/qemu-devel/2020-08/msg05594.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1893667/+subscriptions

[Bug 1762179] Re: Record and replay replay fails with: "ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed"

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1762179

Title:
  Record and replay replay fails with: "ERROR:replay/replay-
  time.c:49:replay_read_clock: assertion failed"

Status in QEMU:
  Fix Released

Bug description:
  QEMU master at 915d34c5f99b0ab91517c69f54272bfdb6ca2b32 Ubuntu 17.10
  host.

  QEMU commands:

  ```
  #!/usr/bin/env bash
  cmd="\
  time \
  ./x86_64-softmmu/qemu-system-x86_64 \
  -append 'root=/dev/sda console=ttyS0 nokaslr printk.time=y - 
lkmc_eval=\"/rand_check.out;/sbin/ifup -a;wget -S google.com;/poweroff.out;\"' \
  -kernel 'out/x86_64/buildroot/images/bzImage' \
  -nographic \
  \
  -drive 
file=out/x86_64/buildroot/images/rootfs.ext2.qcow2,if=none,id=img-direct,format=qcow2
 \
  -drive driver=blkreplay,if=none,image=img-direct,id=img-blkreplay \
  -device ide-hd,drive=img-blkreplay \
  \
  -netdev user,id=net1 \
  -device rtl8139,netdev=net1 \
  -object filter-replay,id=replay,netdev=net1 \
  "
  echo "$cmd"
  eval "$cmd -icount 'shift=7,rr=record,rrfile=replay.bin'"
  eval "$cmd -icount 'shift=7,rr=replay,rrfile=replay.bin'"
  ```

  This tries to stay as close as possible to the documented commands:
  
https://github.com/qemu/qemu/blob/08e173f29461396575c85510eb41474b993cb1fb/docs/replay.txt#L28

  Images uploaded to: https://github.com/cirosantilli/linux-kernel-
  module-cheat/releases/download/test-replay-arm/images4.zip

  Images generated with: https://github.com/cirosantilli/linux-kernel-
  module-cheat/tree/9513c162ef57e6cb70006dfe870856f94ee9a133

  The replay failed straight out with:

  ```
  ERROR:replay/replay-time.c:49:replay_read_clock: assertion failed: 
(replay_file && replay_mutex_locked())
  ```

  QEMU configure:

  ```
  ./configure --enable-debug --enable-trace-backends=simple 
--target-list=x86_64-softmmu
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1762179/+subscriptions

[Bug 1895080] Re: pgb_reserved_va: Assertion `addr == test' failed

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1895080

Title:
  pgb_reserved_va: Assertion `addr == test' failed

Status in QEMU:
  Fix Released

Bug description:
  This problem occurs on CentOS-7.5 (64-bit) with qemu-5.1.0, qemu head
  (commit 9435a8b3dd35f1f926f1b9127e8a906217a5518a) for riscv32-linux-
  user.

  Firstly, compile fails:
  Compiling C object libqemu-riscv32-linux-user.fa.p/linux-user_strace.c.o
  ../qemu.git/linux-user/strace.c:1210:18: error: ‘FALLOC_FL_KEEP_SIZE’ 
undeclared here (not in a function)
   FLAG_GENERIC(FALLOC_FL_KEEP_SIZE),

  I have to add below include to linux-user/strace.c
  diff --git a/linux-user/strace.c b/linux-user/strace.c
  index 11fea14fba..22e51d4a8a 100644
  --- a/linux-user/strace.c
  +++ b/linux-user/strace.c
  @@ -7,6 +7,7 @@
   #include 
   #include 
   #include 
  +#include 
   #include 
   #include 
   #include 

  Then trying qemu-riscv32 with a simple ELF, I get:
  linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == test' failed.

  strace shows that:
  mmap(0x1000, 4294963200, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, 
-1, 0) = 0x1
  write(2, "qemu-riscv32: ../qemu.git/linux-"..., 103qemu-riscv32: 
../qemu.git/linux-user/elfload.c:2341: pgb_reserved_va: Assertion `addr == 
test' failed.
  ) = 103

  The source code is in the function pgb_reserved_va (linux-
  user/elfload.c). I think mmap cannot guarantee that the returned
  pointer (test) equals to the parameter of addr. So is this a bug to
  assert (addr == test)?

  Attached configure script and test ELF file.

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1895080/+subscriptions

[Bug 1680991] Re: raspi2: system timer device not implemented

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991

Title:
  raspi2: system timer device not implemented

Status in QEMU:
  Fix Released

Bug description:
  In a small hobby kernel for Raspberry Pi 2B, I am using the system
  timer to control wait durations.  This timer is located at 0x3f003000
  and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008
  (CHI).  Reading these memory locations returns 0 for both.

  The basic code for this function is:
  
@
  @@ uint64_t ReadSysTimerCount() -- read the system time running count
  
@
  ReadSysTimerCount:
ldr r0,=ST_CLO  @ load the base address of the 
system timer
ldrdr0,r1,[r0]  @ Get the 64-bit timer "count" into 
r1:r0
mov pc,lr   @ return

  Tracing back the definition of ST_CLO in my code:
  #define ST_CLO  (ST_BASE+4) // Counter Lower 32 
bits
  #define ST_BASE (HW_BASE+0x3000)// System Timer base 
address
  #define HW_BASE (0x3f00)// this is the base 
address for all hardware I/O addresses

  I have tested a similar program that I know to work on real hardware
  with qemu-system-arm reading the same mmio register and have the same
  issue, so I'm pretty sure the issue is not with my code.

  My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
  [adam@os-dev ~]$ uname -a
  Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

  I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
  (git).

  adam@os-dev ~]$ qemu-system-arm --version
  QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 
Fabrice Bellard and the QEMU Project developers

  [adam@os-dev ~]$ 
./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
  QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  A remote debugger for my kernel shows the following:
  (gdb) info reg
  r0 0x00
  r1 0x00
  r2 0x96   150
  r3 0x00
  r4 0xa000 40960
  r5 0x00
  r6 0x00
  r7 0x00
  r8 0x00
  r9 0xa000 40960
  r100x00
  r110x7fdc 32732
  r120x00
  sp 0x7fc8 0x7fc8
  lr 0x8194 33172
  pc 0x80a4 0x80a4
  cpsr   0x81d3 -2147483181
  (gdb) stepi
  0x80a8 in ?? ()
  (gdb) info reg
  r0 0x3f003004 1056976900
  r1 0x00
  r2 0x96   150
  r3 0x00
  r4 0xa000 40960
  r5 0x00
  r6 0x00
  r7 0x00
  r8 0x00
  r9 0xa000 40960
  r100x00
  r110x7fdc 32732
  r120x00
  sp 0x7fc8 0x7fc8
  lr 0x8194 33172
  pc 0x80a8 0x80a8
  cpsr   0x81d3 -2147483181
  (gdb) stepi
  0x80ac in ?? ()
  (gdb) info reg
  r0 0x00
  r1 0x00
  r2 0x96   150
  r3 0x00
  r4 0xa000 40960
  r5 0x00
  r6 0x00
  r7 0x00
  r8 0x00
  r9 0xa000 40960
  r100x00
  r110x7fdc 32732
  r120x00
  sp 0x7fc8 0x7fc8
  lr 0x8194 33172
  pc 0x80ac 0x80ac
  cpsr   0x81d3 -2147483181

  Notice r0 is loaded with the address for CLO and then cleared with 0
  when read.

  I am writing my code against the documented specifications in "BCM2835
  ARM Peripherals" (attached for convenience), section "12 System
  Timer".

  
  Please let me know if you need anything else from me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1680991/+subscriptions

Re: [PATCH 6/6] target/ppc: Add mce_req_event() handler to PPCVirtualHypervisorClass

[Greg Kurz]

On Thu, 10 Dec 2020 14:54:08 +1100
David Gibson  wrote:

> On Wed, Dec 09, 2020 at 06:00:52PM +0100, Greg Kurz wrote:
> > kvm_handle_nmi() directly calls spapr_mce_req_event() which is machine
> > level code. Apart from being ugly, this forces spapr_mce_req_event()
> > to rely on qdev_get_machine() to get a pointer to the machine state.
> > This is a bit unfortunate since POWER CPUs have a backlink to the
> > virtual hypervisor, which happens to be the machine itself with
> > sPAPR.
> > 
> > Turn spapr_mce_req_event() into a PPC virtual hypervisor operation,
> > and adapt kvm_handle_nmi() to call it as such.
> > 
> > Signed-off-by: Greg Kurz 
> 
> I have somewhat mixed thoughts on this.  Putting it in vhyp makes a
> certain sense.  But on the other hand, the MCE event from KVM is an
> explicitly PAPR specific interface, so it can't really go to any other
> implementation.
> 

True. Same thing goest for the hypercalls actually. So I guess it's
better to keep this dependency explicit, as long as we don't have
to support non-PAPR KVM guests. Please ignore this patch.


pgprjr3CxfFn2.pgp
Description: OpenPGP digital signature

[Bug 1797262] Re: qemu arm no longer able to boot RPI Kernels

[Thomas Huth]

Released with QEMU v5.2.0.

** Changed in: qemu
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1797262

Title:
  qemu arm no longer able to boot RPI Kernels

Status in QEMU:
  Fix Released

Bug description:
  Since RPi Kernel 1.20170427, qemu is no longer able to emulate the
  Rasberry Pi, as the linux kernel is complaining about timing issues.

  Old kernel output - https://pastebin.com/wvkneNNF
  New kernel output - https://pastebin.com/QTwgCkV2

  Note that the actual error is caused by the kernel being unable to get
  the timing source for the mmc (Line 160), which causes an unable-to-
  mount-root panic.  There are other issues with the serial port
  returning an invalid speed, which displays a divide-by-zero error,
  which is PROBABLY a symptom of the same root cause.

  This is simple to replicate - The last working kernel is available
  here:

  https://github.com/raspberrypi/firmware/tree/1.20170405/boot

  Download kernel7 and the dtb, and try to boot with (for example)

  qemu-system-aarch64 -M raspi2 -kernel kernel7.img -dtb
  bcm2709-rpi-2-b.dtb -serial stdio -sd noobs.img -append
  "root=/dev/mmcblk0p2 init=/bin/bash"

  This works, and boots successfully.

  However, if you replace the kernel7.img and dtb with ones taken from
  https://github.com/raspberrypi/firmware/tree/1.20170427/boot it will
  NOT boot because of various clock timing issues (as in the second
  paste)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1797262/+subscriptions

Re: [External] Re: [PATCH v4 1/2] hw/misc: add an EMC141{3, 4} device model

[Cédric Le Goater]

On 12/10/20 10:40 AM, John Wang wrote:
> ping :)
> 
> I'm sorry I had a break(v3 -> v4)  for a while to do something else

I will send a small PR with this patch. We have time before 6.0.

C.

> 
> On Mon, Nov 23, 2020 at 8:21 PM Cédric Le Goater  wrote:
>>
>> On 11/22/20 11:51 AM, John Wang wrote:
>>> Largely inspired by the TMP421 temperature sensor, here is a model for
>>> the EMC1413/EMC1414 temperature sensors.
>>>
>>> Specs can be found here :
>>>   http://ww1.microchip.com/downloads/en/DeviceDoc/20005274A.pdf
>>>
>>> Signed-off-by: John Wang 
>>
>> Reviewed-by: Cédric Le Goater 
>>
>> Thanks,
>>
>> C.
>>
>>> ---
>>> v4:
>>>   -Fix QOM style name
>>>   -Add unittest
>>> v3:
>>>   - update the link to the spec
>>>   - Rename emc1413.c to emc141x.c
>>>   - Add sensors_count in EMC141XClass
>>>   - Make emc1413_read/write easier to review :)
>>> v2:
>>>   - Remove DeviceInfo
>>>   - commit message: TMP423 -> TMP421
>>> ---
>>>  hw/arm/Kconfig |   1 +
>>>  hw/misc/Kconfig|   4 +
>>>  hw/misc/emc141x.c  | 326 +
>>>  hw/misc/meson.build|   1 +
>>>  include/hw/misc/emc141x_regs.h |  37 
>>>  tests/qtest/emc141x-test.c |  81 
>>>  tests/qtest/meson.build|   1 +
>>>  7 files changed, 451 insertions(+)
>>>  create mode 100644 hw/misc/emc141x.c
>>>  create mode 100644 include/hw/misc/emc141x_regs.h
>>>  create mode 100644 tests/qtest/emc141x-test.c
>>>
>>> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
>>> index e69a9009cf..eb8a8844cf 100644
>>> --- a/hw/arm/Kconfig
>>> +++ b/hw/arm/Kconfig
>>> @@ -407,6 +407,7 @@ config ASPEED_SOC
>>>  select SSI_M25P80
>>>  select TMP105
>>>  select TMP421
>>> +select EMC141X
>>>  select UNIMP
>>>  select LED
>>>
>>> diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
>>> index dc44dc14f6..cf18ac08e6 100644
>>> --- a/hw/misc/Kconfig
>>> +++ b/hw/misc/Kconfig
>>> @@ -13,6 +13,10 @@ config TMP421
>>>  bool
>>>  depends on I2C
>>>
>>> +config EMC141X
>>> +bool
>>> +depends on I2C
>>> +
>>>  config ISA_DEBUG
>>>  bool
>>>  depends on ISA_BUS
>>> diff --git a/hw/misc/emc141x.c b/hw/misc/emc141x.c
>>> new file mode 100644
>>> index 00..f7c53d48a4
>>> --- /dev/null
>>> +++ b/hw/misc/emc141x.c
>>> @@ -0,0 +1,326 @@
>>> +/*
>>> + * SMSC EMC141X temperature sensor.
>>> + *
>>> + * Copyright (c) 2020 Bytedance Corporation
>>> + * Written by John Wang 
>>> + *
>>> + * 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 or
>>> + * (at your option) version 3 of the License.
>>> + *
>>> + * 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 .
>>> + */
>>> +
>>> +#include "qemu/osdep.h"
>>> +#include "hw/i2c/i2c.h"
>>> +#include "migration/vmstate.h"
>>> +#include "qapi/error.h"
>>> +#include "qapi/visitor.h"
>>> +#include "qemu/module.h"
>>> +#include "qom/object.h"
>>> +#include "hw/misc/emc141x_regs.h"
>>> +
>>> +#define SENSORS_COUNT_MAX4
>>> +
>>> +struct EMC141XState {
>>> +I2CSlave parent_obj;
>>> +struct {
>>> +uint8_t raw_temp_min;
>>> +uint8_t raw_temp_current;
>>> +uint8_t raw_temp_max;
>>> +} sensor[SENSORS_COUNT_MAX];
>>> +uint8_t len;
>>> +uint8_t data;
>>> +uint8_t pointer;
>>> +};
>>> +
>>> +struct EMC141XClass {
>>> +I2CSlaveClass parent_class;
>>> +uint8_t model;
>>> +unsigned sensors_count;
>>> +};
>>> +
>>> +#define TYPE_EMC141X "emc141x"
>>> +OBJECT_DECLARE_TYPE(EMC141XState, EMC141XClass, EMC141X)
>>> +
>>> +static void emc141x_get_temperature(Object *obj, Visitor *v, const char 
>>> *name,
>>> +void *opaque, Error **errp)
>>> +{
>>> +EMC141XState *s = EMC141X(obj);
>>> +EMC141XClass *sc = EMC141X_GET_CLASS(s);
>>> +int64_t value;
>>> +unsigned tempid;
>>> +
>>> +if (sscanf(name, "temperature%u", &tempid) != 1) {
>>> +error_setg(errp, "error reading %s: %s", name, g_strerror(errno));
>>> +return;
>>> +}
>>> +
>>> +if (tempid >= sc->sensors_count) {
>>> +error_setg(errp, "error reading %s", name);
>>> +return;
>>> +}
>>> +
>>> +value = s->sensor[tempid].raw_temp_current * 1000;
>>> +
>>> +visit_type_int(v, name, &value, errp);
>>> +}
>>> +
>>> +static void emc141x_set_temperature(Object *obj, Visitor *v, const char 
>>> *name,
>>> +void *opaque, Error **errp)
>>> +{
>>> +EMC141XState *s = EMC141X(obj);

[Bug 1907427] Re: Build on sparc64 fails with "undefined reference to `fdt_check_full'"

[John Paul Adrian Glaubitz]

The issue has been fixed in the device-tree-compiler package here:

>
https://git.kernel.org/pub/scm/utils/dtc/dtc.git/commit/?id=b28464a550c536296439b5785ed8852d1e15b35b

I have filed a Debian bug report asking to backport the patch:

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977031

Nevertheless, qemu should check for the presence of libfdt >= 1.5.1, so
this is still a valid bug report.

** Bug watch added: Debian Bug tracker #977031
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977031

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1907427

Title:
  Build on sparc64 fails with "undefined reference to `fdt_check_full'"

Status in QEMU:
  New

Bug description:
  Trying to build QEMU on sparc64 fails with:

  [4648/8435] c++  -o qemu-system-ppc64 qemu-system-ppc64.p/softmmu_main.c.o 
libcommon.fa.p/ui_vnc-auth-sasl.c.o libcommon.fa.p/migration_colo-failover.c.o 
libcommon.fa.p/hw_input_vhost-user-input.c.o 
libcommon.fa.p/replay_replay-random.c.o libcommon.fa.p/hw_9pfs_codir.c.o 
libcommon.fa.p/hw_display_edid-region.c.o libcommon.fa.p/hw_net_vhost_net.c.o 
libcommon.fa.p/hw_isa_i82378.c.o libcommon.fa.p/backends_rng-egd.c.o 
libcommon.fa.p/hw_usb_core.c.o libcommon.fa.p/hw_pci-bridge_i82801b11.c.o 
libcommon.fa.p/net_tap.c.o libcommon.fa.p/hw_ipack_ipack.c.o 
libcommon.fa.p/hw_scsi_mptconfig.c.o libcommon.fa.p/hw_usb_libhw.c.o 
libcommon.fa.p/hw_display_sm501.c.o 
libcommon.fa.p/hw_net_rocker_rocker_world.c.o 
libcommon.fa.p/fsdev_qemu-fsdev.c.o libcommon.fa.p/backends_tpm_tpm_util.c.o 
libcommon.fa.p/net_tap-linux.c.o libcommon.fa.p/hw_net_rocker_rocker_fp.c.o 
libcommon.fa.p/hw_usb_dev-uas.c.o libcommon.fa.p/hw_net_fsl_etsec_miim.c.o 
libcommon.fa.p/net_queue.c.o libcommon.fa.p/hw_isa_isa-superio.c.o 
libcommon.fa.p/migration_global_state.c.o 
libcommon.fa.p/backends_rng-random.c.o 
libcommon.fa.p/hw_ipmi_ipmi_bmc_extern.c.o 
libcommon.fa.p/migration_postcopy-ram.c.o libcommon.fa.p/hw_scsi_megasas.c.o 
libcommon.fa.p/hw_acpi_acpi-stub.c.o libcommon.fa.p/hw_nvram_mac_nvram.c.o 
libcommon.fa.p/hw_net_pcnet-pci.c.o libcommon.fa.p/cpus-common.c.o 
libcommon.fa.p/hw_core_qdev-properties-system.c.o 
libcommon.fa.p/migration_colo.c.o libcommon.fa.p/ui_spice-module.c.o 
libcommon.fa.p/hw_usb_hcd-ehci-pci.c.o libcommon.fa.p/migration_exec.c.o 
libcommon.fa.p/hw_input_adb-kbd.c.o libcommon.fa.p/hw_timer_xilinx_timer.c.o 
libcommon.fa.p/hw_cpu_core.c.o libcommon.fa.p/chardev_msmouse.c.o 
libcommon.fa.p/migration_socket.c.o libcommon.fa.p/hw_9pfs_9p-synth.c.o 
libcommon.fa.p/backends_dbus-vmstate.c.o libcommon.fa.p/net_colo-compare.c.o 
libcommon.fa.p/hw_misc_macio_cuda.c.o libcommon.fa.p/hw_audio_intel-hda.c.o 
libcommon.fa.p/audio_audio_legacy.c.o
  (...)
  libio.fa libchardev.fa -Wl,--no-whole-archive -Wl,--warn-common -Wl,-z,relro 
-Wl,-z,now -m64 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--as-needed -fstack-protector-strong 
libmigration.fa -Wl,--start-group libqemuutil.a 
contrib/libvhost-user/libvhost-user.a libqmp.fa libhwcore.fa libblockdev.fa 
libblock.fa libcrypto.fa libauthz.fa libqom.fa libio.fa libchardev.fa 
@block.syms @qemu.syms 
/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libfdt.so 
/usr/lib/sparc64-linux-gnu/libcapstone.so -lepoxy -lgbm 
/usr/lib/sparc64-linux-gnu/libpixman-1.so /usr/lib/sparc64-linux-gnu/libz.so 
/usr/lib/sparc64-linux-gnu/libslirp.so 
/usr/lib/sparc64-linux-gnu/libglib-2.0.so -lrdmacm -libverbs -libumad -lgio-2.0 
-lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 
/usr/lib/gcc/sparc64-linux-gnu/10/../../../sparc64-linux-gnu/libsasl2.so 
@block.syms -lusb-1.0 /lib/sparc64-linux-gnu/libudev.so 
/usr/lib/sparc64-linux-gnu/libpng16.so -lvdeplug 
/usr/lib/sparc64-linux-gnu/libjpeg.so -pthread -luring -lgnutls -lutil 
-lgio-2.0 -lgobject-2.0 -lglib-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lm 
-Wl,--export-dynamic -lgmodule-2.0 -lglib-2.0 -laio -luring -lgnutls -lnettle 
-lstdc++ -Wl,--end-group
  /usr/bin/ld: libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_hcall.c.o: in function 
`h_update_dt':
  ./b/qemu/../../hw/ppc/spapr_hcall.c:1966: undefined reference to 
`fdt_check_full'
  collect2: error: ld returned 1 exit status

  Full build log available at:
  
https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=sparc64&ver=1%3A5.2%2Bdfsg-1&stamp=1607502300&raw=0

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1907427/+subscriptions

Re: [PATCH v2 0/5] SCSI: fix transfer limits for SCSI passthrough

[Maxim Levitsky]

On Thu, 2020-12-10 at 01:09 +0100, Paolo Bonzini wrote:
> On 09/12/20 15:03, no-re...@patchew.org wrote:
> > Patchew URL: 
> > https://patchew.org/QEMU/20201209135355.561745-1-mlevi...@redhat.com/
> > 
> > 
> > 
> > Hi,
> > 
> > This series seems to have some coding style problems. See output below for
> > more information:
> > 
> > Type: series
> > Message-id: 20201209135355.561745-1-mlevi...@redhat.com
> > Subject: [PATCH v2 0/5] SCSI: fix transfer limits for SCSI passthrough
> > 
> > === TEST SCRIPT BEGIN ===
> > #!/bin/bash
> > git rev-parse base > /dev/null || exit 0
> > git config --local diff.renamelimit 0
> > git config --local diff.renames True
> > git config --local diff.algorithm histogram
> > ./scripts/checkpatch.pl --mailback base..
> > === TEST SCRIPT END ===
> > 
> > Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> >  From https://github.com/patchew-project/qemu
> >   * [new tag] patchew/20201209135355.561745-1-mlevi...@redhat.com 
> > -> patchew/20201209135355.561745-1-mlevi...@redhat.com
> > Switched to a new branch 'test'
> > 77c9000 block/scsi: correctly emulate the VPD block limits page
> > 61f49e1 block: use blk_get_max_ioctl_transfer for SCSI passthrough
> > 35c66d6 block: add max_ioctl_transfer to BlockLimits
> > 08ba263 file-posix: add sg_get_max_segments that actually works with sg
> > e9fd749 file-posix: split hdev_refresh_limits from raw_refresh_limits
> > 
> > === OUTPUT BEGIN ===
> > 1/5 Checking commit e9fd7498060c (file-posix: split hdev_refresh_limits 
> > from raw_refresh_limits)
> > 2/5 Checking commit 08ba263f565d (file-posix: add sg_get_max_segments that 
> > actually works with sg)
> > 3/5 Checking commit 35c66d636d83 (block: add max_ioctl_transfer to 
> > BlockLimits)
> > 4/5 Checking commit 61f49e1c953b (block: use blk_get_max_ioctl_transfer for 
> > SCSI passthrough)
> > 5/5 Checking commit 77c9000b7c30 (block/scsi: correctly emulate the VPD 
> > block limits page)
> > ERROR: braces {} are necessary for all arms of this statement
> > #39: FILE: hw/scsi/scsi-generic.c:204:
> > +if (len < r->buflen)
> > [...]
> > 
> > total: 1 errors, 0 warnings, 28 lines checked
> > 
> > Patch 5/5 has style problems, please review.  If any of these errors
> > are false positives report them to the maintainer, see
> > CHECKPATCH in MAINTAINERS.
> > 
> > === OUTPUT END ===
> > 
> > Test command exited with code: 1
> > 
> > 
> > The full log is available at
> > http://patchew.org/logs/20201209135355.561745-1-mlevi...@redhat.com/testing.checkpatch/?type=message.
> > ---
> > Email generated automatically by Patchew [https://patchew.org/].
> > Please send your feedback to patchew-de...@redhat.com
> > 
> 
> Time for v3?

I am waiting a bit to see if anything else pops up,
to avoid doing too much noise.


Best regards,
Maxim Levitsky
> 
> Paolo
> 

Re: [External] Re: [PATCH v4 1/2] hw/misc: add an EMC141{3, 4} device model

[John Wang]

ping :)

I'm sorry I had a break(v3 -> v4)  for a while to do something else

On Mon, Nov 23, 2020 at 8:21 PM Cédric Le Goater  wrote:
>
> On 11/22/20 11:51 AM, John Wang wrote:
> > Largely inspired by the TMP421 temperature sensor, here is a model for
> > the EMC1413/EMC1414 temperature sensors.
> >
> > Specs can be found here :
> >   http://ww1.microchip.com/downloads/en/DeviceDoc/20005274A.pdf
> >
> > Signed-off-by: John Wang 
>
> Reviewed-by: Cédric Le Goater 
>
> Thanks,
>
> C.
>
> > ---
> > v4:
> >   -Fix QOM style name
> >   -Add unittest
> > v3:
> >   - update the link to the spec
> >   - Rename emc1413.c to emc141x.c
> >   - Add sensors_count in EMC141XClass
> >   - Make emc1413_read/write easier to review :)
> > v2:
> >   - Remove DeviceInfo
> >   - commit message: TMP423 -> TMP421
> > ---
> >  hw/arm/Kconfig |   1 +
> >  hw/misc/Kconfig|   4 +
> >  hw/misc/emc141x.c  | 326 +
> >  hw/misc/meson.build|   1 +
> >  include/hw/misc/emc141x_regs.h |  37 
> >  tests/qtest/emc141x-test.c |  81 
> >  tests/qtest/meson.build|   1 +
> >  7 files changed, 451 insertions(+)
> >  create mode 100644 hw/misc/emc141x.c
> >  create mode 100644 include/hw/misc/emc141x_regs.h
> >  create mode 100644 tests/qtest/emc141x-test.c
> >
> > diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> > index e69a9009cf..eb8a8844cf 100644
> > --- a/hw/arm/Kconfig
> > +++ b/hw/arm/Kconfig
> > @@ -407,6 +407,7 @@ config ASPEED_SOC
> >  select SSI_M25P80
> >  select TMP105
> >  select TMP421
> > +select EMC141X
> >  select UNIMP
> >  select LED
> >
> > diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
> > index dc44dc14f6..cf18ac08e6 100644
> > --- a/hw/misc/Kconfig
> > +++ b/hw/misc/Kconfig
> > @@ -13,6 +13,10 @@ config TMP421
> >  bool
> >  depends on I2C
> >
> > +config EMC141X
> > +bool
> > +depends on I2C
> > +
> >  config ISA_DEBUG
> >  bool
> >  depends on ISA_BUS
> > diff --git a/hw/misc/emc141x.c b/hw/misc/emc141x.c
> > new file mode 100644
> > index 00..f7c53d48a4
> > --- /dev/null
> > +++ b/hw/misc/emc141x.c
> > @@ -0,0 +1,326 @@
> > +/*
> > + * SMSC EMC141X temperature sensor.
> > + *
> > + * Copyright (c) 2020 Bytedance Corporation
> > + * Written by John Wang 
> > + *
> > + * 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 or
> > + * (at your option) version 3 of the License.
> > + *
> > + * 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 .
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "hw/i2c/i2c.h"
> > +#include "migration/vmstate.h"
> > +#include "qapi/error.h"
> > +#include "qapi/visitor.h"
> > +#include "qemu/module.h"
> > +#include "qom/object.h"
> > +#include "hw/misc/emc141x_regs.h"
> > +
> > +#define SENSORS_COUNT_MAX4
> > +
> > +struct EMC141XState {
> > +I2CSlave parent_obj;
> > +struct {
> > +uint8_t raw_temp_min;
> > +uint8_t raw_temp_current;
> > +uint8_t raw_temp_max;
> > +} sensor[SENSORS_COUNT_MAX];
> > +uint8_t len;
> > +uint8_t data;
> > +uint8_t pointer;
> > +};
> > +
> > +struct EMC141XClass {
> > +I2CSlaveClass parent_class;
> > +uint8_t model;
> > +unsigned sensors_count;
> > +};
> > +
> > +#define TYPE_EMC141X "emc141x"
> > +OBJECT_DECLARE_TYPE(EMC141XState, EMC141XClass, EMC141X)
> > +
> > +static void emc141x_get_temperature(Object *obj, Visitor *v, const char 
> > *name,
> > +void *opaque, Error **errp)
> > +{
> > +EMC141XState *s = EMC141X(obj);
> > +EMC141XClass *sc = EMC141X_GET_CLASS(s);
> > +int64_t value;
> > +unsigned tempid;
> > +
> > +if (sscanf(name, "temperature%u", &tempid) != 1) {
> > +error_setg(errp, "error reading %s: %s", name, g_strerror(errno));
> > +return;
> > +}
> > +
> > +if (tempid >= sc->sensors_count) {
> > +error_setg(errp, "error reading %s", name);
> > +return;
> > +}
> > +
> > +value = s->sensor[tempid].raw_temp_current * 1000;
> > +
> > +visit_type_int(v, name, &value, errp);
> > +}
> > +
> > +static void emc141x_set_temperature(Object *obj, Visitor *v, const char 
> > *name,
> > +void *opaque, Error **errp)
> > +{
> > +EMC141XState *s = EMC141X(obj);
> > +EMC141XClass *sc = EMC141X_GET_CLASS(s);
> > +int64_t temp;
> > +unsigned tempid;
> > +
> > +if (!visit_typ

Re: [PATCH for-6.0] spapr: Allow memory unplug to always succeed

[Greg Kurz]

On Thu, 10 Dec 2020 14:38:44 +1100
David Gibson  wrote:

> On Tue, Dec 08, 2020 at 10:06:09AM +0100, Greg Kurz wrote:
> > On Tue, 8 Dec 2020 15:30:04 +1100
> > David Gibson  wrote:
> > 
> > > On Mon, Dec 07, 2020 at 02:37:04PM +0100, Greg Kurz wrote:
> > > > It is currently impossible to hot-unplug a memory device between
> > > > machine reset and CAS.
> > > > 
> > > > (qemu) device_del dimm1
> > > > Error: Memory hot unplug not supported for this guest
> > > > 
> > > > This limitation was introduced in order to provide an explicit
> > > > error path for older guests that didn't support hot-plug event
> > > > sources (and thus memory hot-unplug).
> > > > 
> > > > The linux kernel has been supporting these since 4.11. All recent
> > > > enough guests are thus capable of handling the removal of a memory
> > > > device at all time, including during early boot.
> > > > 
> > > > Lift the limitation for the latest machine type. This means that
> > > > trying to unplug memory from a guest that doesn't support it will
> > > > likely just do nothing and the memory will only get removed at
> > > > next reboot. Such older guests can still get the existing behavior
> > > > by using an older machine type.
> > > > 
> > > > Signed-off-by: Greg Kurz 
> > > 
> > > Looks like this conflicts with something I've added to for-6.0
> > > recently.  Can you rebase and resend, please.
> > > 
> > 
> > I'm not quite sure what for-6.0 you're talking about. Despite
> > you're recent announcement about moving to gitlab, it seems
> > that the branch at github is the most up to date.
> > 
> > gitlab:
> > - HEAD is "xive: Add trace events"
> > - Date: 26 Nov, 2020
> > 
> > github:
> > - HEAD is "MAINTAINERS: Add Greg Kurz as co-maintainer for ppc"
> > - Date: Dec 4, 2020
> > 
> > I've thus based this patch on github. Also, this is based on Connie's
> > "hw: add compat machines for 6.0" patch...
> > 
> > > > ---
> > > > Based-on: 20201109173928.1001764-1-coh...@redhat.com
> > 
> > ... maybe I should have made it more clear than just
> > mentioning the message id ?
> > 
> > I think I'll just wait for Connie's patch to get merged and I'll repost 
> > after
> > you've rebased ppc-for-6.0.
> 
> Sorry, I think I forgot to push the latest to either gitlab *or*
> github.  I've pushed some new stuff now.
> 

Np. I see you now have the 6.0 compat machine types in your tree on gitlab.
This patch should apply flawlessly.


pgpNvTi8tD_YV.pgp
Description: OpenPGP digital signature

Re: [RFC 2/8] s390x/pci: MSI-X isn't strictly required for passthrough

[Cornelia Huck]

On Wed,  9 Dec 2020 15:34:20 -0500
Matthew Rosato  wrote:

> s390 PCI currently disallows PCI devices without the MSI-X capability.
> However, this fence doesn't make sense for passthrough devices.  Move
> the check to only fence emulated devices (e.g., virtio).
> 
> Signed-off-by: Matthew Rosato 
> Reviewed-by: Pierre Morel 
> ---
>  hw/s390x/s390-pci-bus.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> index 05f7460..afad048 100644
> --- a/hw/s390x/s390-pci-bus.c
> +++ b/hw/s390x/s390-pci-bus.c
> @@ -1028,12 +1028,12 @@ static void s390_pcihost_plug(HotplugHandler 
> *hotplug_dev, DeviceState *dev,
>  s390_pci_get_clp_info(pbdev);
>  } else {
>  pbdev->fh |= FH_SHM_EMUL;
> -}
>  
> -if (s390_pci_msix_init(pbdev)) {
> -error_setg(errp, "MSI-X support is mandatory "
> -   "in the S390 architecture");
> -return;
> +if (s390_pci_msix_init(pbdev)) {
> +error_setg(errp, "MSI-X support is mandatory "
> +   "in the S390 architecture");
> +return;
> +}
>  }
>  
>  if (dev->hotplugged) {
> @@ -1073,7 +1073,9 @@ static void s390_pcihost_unplug(HotplugHandler 
> *hotplug_dev, DeviceState *dev,
>  devfn = pci_dev->devfn;
>  qdev_unrealize(dev);
>  
> -s390_pci_msix_free(pbdev);
> +if (pbdev->fh & FH_SHM_EMUL) {
> +s390_pci_msix_free(pbdev);
> +}
>  s390_pci_iommu_free(s, bus, devfn);
>  pbdev->pdev = NULL;
>  pbdev->state = ZPCI_FS_RESERVED;

Remind me: Wasn't it only msi that was strictly required (i.e., not msi-x?)

Can we generally relax this requirement, possibly with some changes in
the adapter interrupt mapping? I might misremember, though.

Re: [RFC 3/8] s390x/pci: fix pcistb length

[Cornelia Huck]

On Wed,  9 Dec 2020 15:34:21 -0500
Matthew Rosato  wrote:

> In pcistb_service_call, we are grabbing 8 bits from a guest register to
> indicate the length of the store operation -- but per the architecture
> the length is actually defined by 13 bits of the guest register.
> 
> Signed-off-by: Matthew Rosato 
> Reviewed-by: Pierre Morel 
> ---
>  hw/s390x/s390-pci-inst.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c
> index 70bfd91..db86f12 100644
> --- a/hw/s390x/s390-pci-inst.c
> +++ b/hw/s390x/s390-pci-inst.c
> @@ -750,7 +750,7 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
> r3, uint64_t gaddr,
>  int i;
>  uint32_t fh;
>  uint8_t pcias;
> -uint8_t len;
> +uint16_t len;
>  uint8_t buffer[128];
>  
>  if (env->psw.mask & PSW_MASK_PSTATE) {
> @@ -760,7 +760,7 @@ int pcistb_service_call(S390CPU *cpu, uint8_t r1, uint8_t 
> r3, uint64_t gaddr,
>  
>  fh = env->regs[r1] >> 32;
>  pcias = (env->regs[r1] >> 16) & 0xf;
> -len = env->regs[r1] & 0xff;
> +len = env->regs[r1] & 0x1fff;
>  offset = env->regs[r3];
>  
>  if (!(fh & FH_MASK_ENABLE)) {

Is that a general problem that we just did not notice before?

If yes, this probably deserves a Fixes: tag and can be queued
independently of the rest of the series.

Re: [PATCH v5 1/4] crypto: luks: Fix tiny memory leak

[Vladimir Sementsov-Ogievskiy]

09.12.2020 23:33, Maxim Levitsky wrote:

When the underlying block device doesn't support the
bdrv_co_delete_file interface, an 'Error' object was leaked.

Signed-off-by: Maxim Levitsky 
Reviewed-by: Alberto Garcia 


Reviewed-by: Vladimir Sementsov-Ogievskiy 


---
  block/crypto.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/block/crypto.c b/block/crypto.c
index aef5a5721a..b3a5275132 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -735,6 +735,8 @@ fail:
   */
  if ((r_del < 0) && (r_del != -ENOTSUP)) {
  error_report_err(local_delete_err);
+} else {
+error_free(local_delete_err);
  }
  }
  




--
Best regards,
Vladimir

Re: [PATCH v2 1/5] file-posix: split hdev_refresh_limits from raw_refresh_limits

[Tom Yan]

On Wed, 9 Dec 2020 at 21:54, Maxim Levitsky  wrote:
>
> From: Tom Yan 
>
> We can and should get max transfer length and max segments for all host
> devices / cdroms (on Linux).
>
> Also use MIN_NON_ZERO instead when we clamp max transfer length against
> max segments.
>
> Signed-off-by: Tom Yan 
> Signed-off-by: Maxim Levitsky 
> ---
>  block/file-posix.c | 59 +-
>  1 file changed, 43 insertions(+), 16 deletions(-)
>
> diff --git a/block/file-posix.c b/block/file-posix.c
> index d5fd1dbcd2..226ddbbdad 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -1162,6 +1162,12 @@ static void raw_reopen_abort(BDRVReopenState *state)
>
>  static int sg_get_max_transfer_length(int fd)
>  {
> +/*
> + * BLKSECTGET for /dev/sg* character devices incorrectly returns
> + * the max transfer size in bytes (rather than in blocks).
> + * Also note that /dev/sg* doesn't support BLKSSZGET ioctl.
> + */
The second statement should be removed. Also maybe it's better to have
the first one right above the line `return max_bytes;`.
> +
>  #ifdef BLKSECTGET
>  int max_bytes = 0;
>
> @@ -1175,7 +1181,22 @@ static int sg_get_max_transfer_length(int fd)
>  #endif
>  }
>
> -static int sg_get_max_segments(int fd)
> +static int get_max_transfer_length(int fd)
> +{
> +#if defined(BLKSECTGET)
> +int sect = 0;
> +
> +if (ioctl(fd, BLKSECTGET, §) == 0) {
> +return sect << 9;
> +} else {
> +return -errno;
> +}
> +#else
> +return -ENOSYS;
> +#endif
> +}
> +
> +static int get_max_segments(int fd)
>  {
>  #ifdef CONFIG_LINUX
>  char buf[32];
> @@ -1230,23 +1251,29 @@ static void raw_refresh_limits(BlockDriverState *bs, 
> Error **errp)
>  {
>  BDRVRawState *s = bs->opaque;
>
> -if (bs->sg) {
> -int ret = sg_get_max_transfer_length(s->fd);
> +raw_probe_alignment(bs, s->fd, errp);
> +bs->bl.min_mem_alignment = s->buf_align;
> +bs->bl.opt_mem_alignment = MAX(s->buf_align, qemu_real_host_page_size);
> +}
>
> -if (ret > 0 && ret <= BDRV_REQUEST_MAX_BYTES) {
> -bs->bl.max_transfer = pow2floor(ret);
> -}
> +static void hdev_refresh_limits(BlockDriverState *bs, Error **errp)
> +{
> +BDRVRawState *s = bs->opaque;
>
> -ret = sg_get_max_segments(s->fd);
> -if (ret > 0) {
> -bs->bl.max_transfer = MIN(bs->bl.max_transfer,
> -  ret * qemu_real_host_page_size);
> -}
> +int ret = bs->sg ? sg_get_max_transfer_length(s->fd) :
> +   get_max_transfer_length(s->fd);
> +
> +if (ret > 0 && ret <= BDRV_REQUEST_MAX_BYTES) {
> +bs->bl.max_transfer = pow2floor(ret);
>  }
>
> -raw_probe_alignment(bs, s->fd, errp);
> -bs->bl.min_mem_alignment = s->buf_align;
> -bs->bl.opt_mem_alignment = MAX(s->buf_align, qemu_real_host_page_size);
> +ret = get_max_segments(s->fd);
> +if (ret > 0) {
> +bs->bl.max_transfer = MIN_NON_ZERO(bs->bl.max_transfer,
> +   ret * qemu_real_host_page_size);
> +}
> +
> +raw_refresh_limits(bs, errp);
>  }
>
>  static int check_for_dasd(int fd)
> @@ -3601,7 +3628,7 @@ static BlockDriver bdrv_host_device = {
>  .bdrv_co_pdiscard   = hdev_co_pdiscard,
>  .bdrv_co_copy_range_from = raw_co_copy_range_from,
>  .bdrv_co_copy_range_to  = raw_co_copy_range_to,
> -.bdrv_refresh_limits = raw_refresh_limits,
> +.bdrv_refresh_limits = hdev_refresh_limits,
>  .bdrv_io_plug = raw_aio_plug,
>  .bdrv_io_unplug = raw_aio_unplug,
>  .bdrv_attach_aio_context = raw_aio_attach_aio_context,
> @@ -3725,7 +3752,7 @@ static BlockDriver bdrv_host_cdrom = {
>  .bdrv_co_preadv = raw_co_preadv,
>  .bdrv_co_pwritev= raw_co_pwritev,
>  .bdrv_co_flush_to_disk  = raw_co_flush_to_disk,
> -.bdrv_refresh_limits = raw_refresh_limits,
> +.bdrv_refresh_limits = hdev_refresh_limits,
>  .bdrv_io_plug = raw_aio_plug,
>  .bdrv_io_unplug = raw_aio_unplug,
>  .bdrv_attach_aio_context = raw_aio_attach_aio_context,
> --
> 2.26.2
>

[PATCH aspeed-5.2] aspeed: g220a-bmc: Add an FRU

[John Wang]

Add an eeprom device and fill it with fru
information

$ ipmitool fru print 0
Product Manufacturer  : Bytedance
Product Name  : G220A

Signed-off-by: John Wang 
---
 hw/arm/aspeed.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 04c8ad2bcd..fc80d45513 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -595,6 +595,18 @@ static void g220a_bmc_i2c_init(AspeedMachineState *bmc)
 object_property_set_int(OBJECT(dev), "temperature0", 31000, &error_abort);
 object_property_set_int(OBJECT(dev), "temperature1", 28000, &error_abort);
 object_property_set_int(OBJECT(dev), "temperature2", 2, &error_abort);
+
+static uint8_t eeprom_buf[2 * 1024] = {
+0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0xfe,
+0x01, 0x06, 0x00, 0xc9, 0x42, 0x79, 0x74, 0x65,
+0x64, 0x61, 0x6e, 0x63, 0x65, 0xc5, 0x47, 0x32,
+0x32, 0x30, 0x41, 0xc4, 0x41, 0x41, 0x42, 0x42,
+0xc4, 0x43, 0x43, 0x44, 0x44, 0xc4, 0x45, 0x45,
+0x46, 0x46, 0xc4, 0x48, 0x48, 0x47, 0x47, 0xc1,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xa7,
+};
+smbus_eeprom_init_one(aspeed_i2c_get_bus(&soc->i2c, 4), 0x57,
+  eeprom_buf);
 }
 
 static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
-- 
2.25.1

Re: [PATCH aspeed-5.2] aspeed: g220a-bmc: Add an FRU

[Cédric Le Goater]

On 12/10/20 11:36 AM, John Wang wrote:
> Add an eeprom device and fill it with fru
> information
> 
> $ ipmitool fru print 0
> Product Manufacturer  : Bytedance
> Product Name  : G220A
> 
> Signed-off-by: John Wang 


Reviewed-by: Cédric Le Goater 

Thanks,

C. 

> ---
>  hw/arm/aspeed.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 04c8ad2bcd..fc80d45513 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -595,6 +595,18 @@ static void g220a_bmc_i2c_init(AspeedMachineState *bmc)
>  object_property_set_int(OBJECT(dev), "temperature0", 31000, 
> &error_abort);
>  object_property_set_int(OBJECT(dev), "temperature1", 28000, 
> &error_abort);
>  object_property_set_int(OBJECT(dev), "temperature2", 2, 
> &error_abort);
> +
> +static uint8_t eeprom_buf[2 * 1024] = {
> +0x01, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0xfe,
> +0x01, 0x06, 0x00, 0xc9, 0x42, 0x79, 0x74, 0x65,
> +0x64, 0x61, 0x6e, 0x63, 0x65, 0xc5, 0x47, 0x32,
> +0x32, 0x30, 0x41, 0xc4, 0x41, 0x41, 0x42, 0x42,
> +0xc4, 0x43, 0x43, 0x44, 0x44, 0xc4, 0x45, 0x45,
> +0x46, 0x46, 0xc4, 0x48, 0x48, 0x47, 0x47, 0xc1,
> +0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xa7,
> +};
> +smbus_eeprom_init_one(aspeed_i2c_get_bus(&soc->i2c, 4), 0x57,
> +  eeprom_buf);
>  }
>  
>  static bool aspeed_get_mmio_exec(Object *obj, Error **errp)
> 

Re: [PATCH v5 2/4] block: add bdrv_co_delete_file_noerr

[Vladimir Sementsov-Ogievskiy]

09.12.2020 23:33, Maxim Levitsky wrote:

This function wraps bdrv_co_delete_file for the common case of removing a file,
which was just created by format driver, on an error condition.

It hides the -ENOTSUPP error, and reports all other errors otherwise.


I've looked at original commit added this logic, and didn't find exactly, why 
should we hide it..



Signed-off-by: Maxim Levitsky 
Reviewed-by: Alberto Garcia 
---
  block.c   | 24 
  include/block/block.h |  1 +
  2 files changed, 25 insertions(+)

diff --git a/block.c b/block.c
index f1cedac362..5d35ba2fb8 100644
--- a/block.c
+++ b/block.c
@@ -704,6 +704,30 @@ int coroutine_fn bdrv_co_delete_file(BlockDriverState *bs, 
Error **errp)
  return ret;
  }
  
+void coroutine_fn bdrv_co_delete_file_noerr(BlockDriverState *bs)

+{
+Error *local_err = NULL;
+int ret;
+
+if (!bs) {
+return;
+}
+
+ret = bdrv_co_delete_file(bs, &local_err);
+/*
+ * ENOTSUP will happen if the block driver doesn't support
+ * the 'bdrv_co_delete_file' interface. This is a predictable
+ * scenario and shouldn't be reported back to the user.
+ */


It's not predictable for user: user doesn't know internal processes and 
interfaces.

The problem: we've left extra file on failure scenario and can't remove it. We 
want to warn the user that there is a wrong file left. Why not to warn, when 
the removement is unsupported internally by the driver?

I think, it's better to report it in any case.

Another reason: less code and logic on failure case. Optimizing failure 
scenarios in different manner is seldom a good thing to do.

And finally: why to report the error at all? If we have errp parameter, it's better to 
add the info to it using error_append.. something like error_append(errp, " (also 
failed to remove unfinished file %s: %s)", file_name, error_get_pretty(local_err))


Probably I'm making mountains out of molehills. It should work, so take my r-b 
anyway:

Reviewed-by: Vladimir Sementsov-Ogievskiy 


Side note: I'd not split patches 02 and 03: this way it would be simpler to see 
the code movement.


+if (ret == -ENOTSUP) {
+error_free(local_err);
+} else if (ret < 0) {
+error_report_err(local_err);
+}
+}
+
+
+


three empty lines..


  /**
   * Try to get @bs's logical and physical block size.
   * On success, store them in @bsz struct and return 0.
diff --git a/include/block/block.h b/include/block/block.h
index c9d7c58765..af03022723 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -428,6 +428,7 @@ int bdrv_freeze_backing_chain(BlockDriverState *bs, 
BlockDriverState *base,
Error **errp);
  void bdrv_unfreeze_backing_chain(BlockDriverState *bs, BlockDriverState 
*base);
  int coroutine_fn bdrv_co_delete_file(BlockDriverState *bs, Error **errp);
+void coroutine_fn bdrv_co_delete_file_noerr(BlockDriverState *bs);
  
  
  typedef struct BdrvCheckResult {





--
Best regards,
Vladimir

Re: [PATCH v5 3/4] crypto: luks: use bdrv_co_delete_file_noerr

[Vladimir Sementsov-Ogievskiy]

09.12.2020 23:33, Maxim Levitsky wrote:

This refactoring is now possible thanks to this function.

Signed-off-by: Maxim Levitsky
Reviewed-by: Alberto Garcia


Reviewed-by: Vladimir Sementsov-Ogievskiy 

--
Best regards,
Vladimir

Re: [PATCH V2] virtiofsd: Use --thread-pool-size=0 to mean no thread pool

[Dr. David Alan Gilbert]

* Vivek Goyal (vgo...@redhat.com) wrote:
> Right now we create a thread pool and main thread hands over the request
> to thread in thread pool to process. Number of threads in thread pool
> can be managed by option --thread-pool-size.
> 
> In tests we have noted that many of the workloads are getting better
> performance if we don't use a thread pool at all and process all
> the requests in the context of a thread receiving the request.
> 
> Hence give user an option to be able to run virtiofsd without using
> a thread pool.
> 
> To implement this, I have used existing option --thread-pool-size. This
> option defines how many maximum threads can be in the thread pool.
> Thread pool size zero freezes thead pool. I can't see why will one
> start virtiofsd with a frozen thread pool (hence frozen file system).
> So I am redefining --thread-pool-size=0 to mean, don't use a thread pool.
> Instead process the request in the context of thread receiving request
> from the queue.
> 
> Signed-off-by: Vivek Goyal 

Queued.

> ---
>  tools/virtiofsd/fuse_virtio.c | 36 ++-
>  1 file changed, 27 insertions(+), 9 deletions(-)
> 
> diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
> index 83ba07c6cd..944b9a577c 100644
> --- a/tools/virtiofsd/fuse_virtio.c
> +++ b/tools/virtiofsd/fuse_virtio.c
> @@ -588,13 +588,18 @@ static void *fv_queue_thread(void *opaque)
>  struct VuDev *dev = &qi->virtio_dev->dev;
>  struct VuVirtq *q = vu_get_queue(dev, qi->qidx);
>  struct fuse_session *se = qi->virtio_dev->se;
> -GThreadPool *pool;
> -
> -pool = g_thread_pool_new(fv_queue_worker, qi, se->thread_pool_size, 
> FALSE,
> - NULL);
> -if (!pool) {
> -fuse_log(FUSE_LOG_ERR, "%s: g_thread_pool_new failed\n", __func__);
> -return NULL;
> +GThreadPool *pool = NULL;
> +GList *req_list = NULL;
> +
> +if (se->thread_pool_size) {
> +fuse_log(FUSE_LOG_DEBUG, "%s: Creating thread pool for Queue %d\n",
> + __func__, qi->qidx);
> +pool = g_thread_pool_new(fv_queue_worker, qi, se->thread_pool_size,
> + FALSE, NULL);
> +if (!pool) {
> +fuse_log(FUSE_LOG_ERR, "%s: g_thread_pool_new failed\n", 
> __func__);
> +return NULL;
> +}
>  }
>  
>  fuse_log(FUSE_LOG_INFO, "%s: Start for queue %d kick_fd %d\n", __func__,
> @@ -669,14 +674,27 @@ static void *fv_queue_thread(void *opaque)
>  
>  req->reply_sent = false;
>  
> -g_thread_pool_push(pool, req, NULL);
> +if (!se->thread_pool_size) {
> +req_list = g_list_prepend(req_list, req);
> +} else {
> +g_thread_pool_push(pool, req, NULL);
> +}
>  }
>  
>  pthread_mutex_unlock(&qi->vq_lock);
>  pthread_rwlock_unlock(&qi->virtio_dev->vu_dispatch_rwlock);
> +
> +/* Process all the requests. */
> +if (!se->thread_pool_size && req_list != NULL) {
> +g_list_foreach(req_list, fv_queue_worker, qi);
> +g_list_free(req_list);
> +req_list = NULL;
> +}
>  }
>  
> -g_thread_pool_free(pool, FALSE, TRUE);
> +if (pool) {
> +g_thread_pool_free(pool, FALSE, TRUE);
> +}
>  
>  return NULL;
>  }
> -- 
> 2.25.4
> 
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH v5 4/4] block: qcow2: remove the created file on initialization error

[Vladimir Sementsov-Ogievskiy]

09.12.2020 23:33, Maxim Levitsky wrote:

If the qcow initialization fails, we should remove the file if it was
already created, to avoid leaving stale files around.

We already do this for luks raw images.

Signed-off-by: Maxim Levitsky 
Reviewed-by: Alberto Garcia 
---
  block/qcow2.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index 3a90ef2786..68c9182f92 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -3847,12 +3847,14 @@ static int coroutine_fn 
qcow2_co_create_opts(BlockDriver *drv,
  
  /* Create the qcow2 image (format layer) */

  ret = qcow2_co_create(create_options, errp);
+finish:
  if (ret < 0) {
-goto finish;
+bdrv_co_delete_file_noerr(bs);
+bdrv_co_delete_file_noerr(data_bs);
  }
  
  ret = 0;


Ooops :) After this patch the function always returns zero :)


-finish:
+
  qobject_unref(qdict);
  bdrv_unref(bs);
  bdrv_unref(data_bs);




--
Best regards,
Vladimir

Re: [PATCH v5 4/4] block: qcow2: remove the created file on initialization error

[Maxim Levitsky]

On Thu, 2020-12-10 at 14:00 +0300, Vladimir Sementsov-Ogievskiy wrote:
> 09.12.2020 23:33, Maxim Levitsky wrote:
> > If the qcow initialization fails, we should remove the file if it was
> > already created, to avoid leaving stale files around.
> > 
> > We already do this for luks raw images.
> > 
> > Signed-off-by: Maxim Levitsky 
> > Reviewed-by: Alberto Garcia 
> > ---
> >   block/qcow2.c | 6 --
> >   1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index 3a90ef2786..68c9182f92 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -3847,12 +3847,14 @@ static int coroutine_fn 
> > qcow2_co_create_opts(BlockDriver *drv,
> >   
> >   /* Create the qcow2 image (format layer) */
> >   ret = qcow2_co_create(create_options, errp);
> > +finish:
> >   if (ret < 0) {
> > -goto finish;
> > +bdrv_co_delete_file_noerr(bs);
> > +bdrv_co_delete_file_noerr(data_bs);
> >   }
> >   
> >   ret = 0;
> 
> Ooops :) After this patch the function always returns zero :)

Indeed :-(

These small changes done in the last minute are the most dangerous.

Best regards,
Maxim Levitsky
> 
> > -finish:
> > +
> >   qobject_unref(qdict);
> >   bdrv_unref(bs);
> >   bdrv_unref(data_bs);
> > 
> 
> 

Re: [PATCH v12 00/19] Initial support for multi-process Qemu

[Stefan Hajnoczi]

On Thu, Dec 03, 2020 at 08:40:11PM +, Peter Maydell wrote:
> On Thu, 3 Dec 2020 at 09:51, Stefan Hajnoczi  wrote:
> >
> > On Tue, Dec 01, 2020 at 03:22:35PM -0500, Jagannathan Raman wrote:
> > > This is the v12 of the patchset. Thank you very much for the
> > > review of the v11 of the series.
> >
> > I'm in favor of merging this for QEMU 6.0. The command-line interface
> > has the x- prefix so QEMU is not committing to a stable interface.
> > Changes needed to support additional device types or to switch to the
> > vfio-user protocol can be made later.
> >
> > Jag, Elena, JJ: I suggest getting your GPG key to Peter Maydell so you
> > can send multi-process QEMU pull requests.
> 
> I would prefer to see this going through the tree of an
> established QEMU developer who's already sending pullrequests,
> at least initially.

Once the discussion has completed I can send the patches in a pull
request.

I don't want to be the bottleneck for all multi-process QEMU patches in
the future though. That's why I think the authors should be able to send
pull requests on their own after the initial code is merged. Much of
this work is isolated an only affects multi-process QEMU and the feature
is marked experimental. There is little risk of introducing instability
for non-multi-process QEMU users/developers. Hence why this is a new
subsystem and has MAINTAINERS files entries.

Does that sound good?

Stefan


signature.asc
Description: PGP signature

Re: [PATCH 1/1] trace: Send "-d trace:help" output to stdout

[Stefan Hajnoczi]

On Wed, Nov 25, 2020 at 01:52:45PM -0800, Doug Evans wrote:
> ... for consistency with "-d help".
> 
> Signed-off-by: Doug Evans 
> ---
>  trace/control.c | 12 ++--
>  trace/control.h |  3 ++-
>  2 files changed, 8 insertions(+), 7 deletions(-)

Thanks, applied to my tracing tree:
https://gitlab.com/stefanha/qemu/commits/tracing

Stefan


signature.asc
Description: PGP signature

Re: [PATCH v12 00/19] Initial support for multi-process Qemu

[Peter Maydell]

On Thu, 10 Dec 2020 at 11:14, Stefan Hajnoczi  wrote:
> On Thu, Dec 03, 2020 at 08:40:11PM +, Peter Maydell wrote:
> > I would prefer to see this going through the tree of an
> > established QEMU developer who's already sending pullrequests,
> > at least initially.
>
> Once the discussion has completed I can send the patches in a pull
> request.
>
> I don't want to be the bottleneck for all multi-process QEMU patches in
> the future though. That's why I think the authors should be able to send
> pull requests on their own after the initial code is merged. Much of
> this work is isolated an only affects multi-process QEMU and the feature
> is marked experimental. There is little risk of introducing instability
> for non-multi-process QEMU users/developers. Hence why this is a new
> subsystem and has MAINTAINERS files entries.

My reasoning is basically that new pull-request senders are more
work for me, because I have to make sure they have a GPG key set
up, and then examine pull requests pretty carefully to check they're
well-formed, all the sign-offs are correct, the changes aren't
touching areas of the codebase that they shouldn't, and so on.
That's particularly painful if the first pull request that comes
through is a massive one rather than "here's a small number of
patches with some bug fixes".

thanks
-- PMM

Re: [PATCH 1/1] trace: Send "-d trace:help" output to stdout

[Philippe Mathieu-Daudé]

Hi Stefan,

On 12/10/20 12:25 PM, Stefan Hajnoczi wrote:
> On Wed, Nov 25, 2020 at 01:52:45PM -0800, Doug Evans wrote:
>> ... for consistency with "-d help".

Do you mind replacing the '...' by the subject:
'Send "-d trace:help" output to stdout', so the
commit description makes more sense?

Thanks,

Phil.

>>
>> Signed-off-by: Doug Evans 
>> ---
>>  trace/control.c | 12 ++--
>>  trace/control.h |  3 ++-
>>  2 files changed, 8 insertions(+), 7 deletions(-)
> 
> Thanks, applied to my tracing tree:
> https://gitlab.com/stefanha/qemu/commits/tracing
> 
> Stefan
> 

Re: [RFC PATCH 05/27] vhost: Add hdev->dev.sw_lm_vq_handler

[Stefan Hajnoczi]

On Wed, Dec 09, 2020 at 04:02:56PM +0100, Eugenio Perez Martin wrote:
> On Mon, Dec 7, 2020 at 5:52 PM Stefan Hajnoczi  wrote:
> > On Fri, Nov 20, 2020 at 07:50:43PM +0100, Eugenio Pérez wrote:
> > > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > > index 9179013ac4..9a69ae3598 100644
> > > --- a/hw/net/virtio-net.c
> > > +++ b/hw/net/virtio-net.c
> > > @@ -2628,24 +2628,32 @@ static void virtio_net_tx_bh(void *opaque)
> > >  }
> > >  }
> > >
> > > -static void virtio_net_add_queue(VirtIONet *n, int index)
> > > +static void virtio_net_add_queue(VirtIONet *n, int index,
> > > + VirtIOHandleOutput custom_handler)
> > >  {
> >
> > We talked about the possibility of moving this into the generic vhost
> > code so that devices don't need to be modified. It would be nice to hide
> > this feature inside vhost.
> 
> I'm thinking of tying it to VirtQueue, allowing the caller to override
> the handler knowing it is not going to be called (I mean, not offering
> race conditions protection, like before of starting processing
> notifications in qemu calling vhost_dev_disable_notifiers).

Yes, I can see how at least part of this belongs to VirtQueue.

Stefan


signature.asc
Description: PGP signature

Re: [PATCH] fuzz: map all BARs and enable PCI devices

[Darren Kenny]

Hi Alex,

On Wednesday, 2020-12-09 at 15:10:54 -05, Alexander Bulekov wrote:
> Prior to this patch, the fuzzer found inputs to map PCI device BARs and
> enable the device. While it is nice that the fuzzer can do this, it
> added significant overhead, since the fuzzer needs to map all the
> BARs (regenerating the memory topology), at the start of each input.
> With this patch, we do this once, before fuzzing, mitigating some of
> this overhead.
>
> Signed-off-by: Alexander Bulekov 

In general this looks good, I've a small comment/nit below, but nothing
serious, so:

Reviewed-by: Darren Kenny 

> ---
>  tests/qtest/fuzz/generic_fuzz.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/tests/qtest/fuzz/generic_fuzz.c b/tests/qtest/fuzz/generic_fuzz.c
> index 07ad690683..d95093ee53 100644
> --- a/tests/qtest/fuzz/generic_fuzz.c
> +++ b/tests/qtest/fuzz/generic_fuzz.c
> @@ -16,6 +16,7 @@
>  
>  #include "hw/core/cpu.h"
>  #include "tests/qtest/libqos/libqtest.h"
> +#include "tests/qtest/libqos/pci-pc.h"
>  #include "fuzz.h"
>  #include "fork_fuzz.h"
>  #include "exec/address-spaces.h"
> @@ -762,6 +763,22 @@ static int locate_fuzz_objects(Object *child, void 
> *opaque)
>  return 0;
>  }
>  
> +
> +static void pci_enum(gpointer pcidev, gpointer bus)
> +{
> +PCIDevice *dev = pcidev;
> +QPCIDevice *qdev;
> +
> +qdev = qpci_device_find(bus, dev->devfn);
> +g_assert(qdev != NULL);
> +for (int i = 0; i < 6; i++) {
> +if (dev->io_regions[i].size) {
> +qpci_iomap(qdev, i, NULL);
> +}
> +}
> +qpci_device_enable(qdev);
> +}
> +
>  static void generic_pre_fuzz(QTestState *s)
>  {
>  GHashTableIter iter;
> @@ -810,6 +827,12 @@ static void generic_pre_fuzz(QTestState *s)
>  exit(1);
>  }
>  
> +QPCIBus *pcibus;

NIT: I'm not a huge fan of defining variables in the middle of code,
 call me old-fashioned if you will, but I tend to prefer them at the
 top of the function, or block ;)

 It does look good in the diff, but would seem odd in the overall
 code.

Thanks,

Darren.

Re: [PATCH v5 2/4] block: add bdrv_co_delete_file_noerr

[Maxim Levitsky]

On Thu, 2020-12-10 at 13:54 +0300, Vladimir Sementsov-Ogievskiy wrote:
> 09.12.2020 23:33, Maxim Levitsky wrote:
> > This function wraps bdrv_co_delete_file for the common case of removing a 
> > file,
> > which was just created by format driver, on an error condition.
> > 
> > It hides the -ENOTSUPP error, and reports all other errors otherwise.
> 
> I've looked at original commit added this logic, and didn't find exactly, why 
> should we hide it..
> 
> > Signed-off-by: Maxim Levitsky 
> > Reviewed-by: Alberto Garcia 
> > ---
> >   block.c   | 24 
> >   include/block/block.h |  1 +
> >   2 files changed, 25 insertions(+)
> > 
> > diff --git a/block.c b/block.c
> > index f1cedac362..5d35ba2fb8 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -704,6 +704,30 @@ int coroutine_fn bdrv_co_delete_file(BlockDriverState 
> > *bs, Error **errp)
> >   return ret;
> >   }
> >   
> > +void coroutine_fn bdrv_co_delete_file_noerr(BlockDriverState *bs)
> > +{
> > +Error *local_err = NULL;
> > +int ret;
> > +
> > +if (!bs) {
> > +return;
> > +}
> > +
> > +ret = bdrv_co_delete_file(bs, &local_err);
> > +/*
> > + * ENOTSUP will happen if the block driver doesn't support
> > + * the 'bdrv_co_delete_file' interface. This is a predictable
> > + * scenario and shouldn't be reported back to the user.
> > + */
> 
> It's not predictable for user: user doesn't know internal processes and 
> interfaces.
> 
> The problem: we've left extra file on failure scenario and can't remove it. 
> We want to warn the user that there is a wrong file left. Why not to warn, 
> when the removement is unsupported internally by the driver?
> 
> I think, it's better to report it in any case.

This is a good point, but it is not something I changed.
I prefer this to be changed in a separate patch.


> 
> Another reason: less code and logic on failure case. Optimizing failure 
> scenarios in different manner is seldom a good thing to do.
> 
> And finally: why to report the error at all? If we have errp parameter, it's 
> better to add the info to it using error_append.. something like 
> error_append(errp, " (also failed to remove unfinished file %s: %s)", 
> file_name, error_get_pretty(local_err))

The idea behind this was to reduce code duplication in the callers of this 
function,
and this is why this function doesn't even have the 'errp' parameter.
I'll think about it.

> 
> 
> Probably I'm making mountains out of molehills. It should work, so take my 
> r-b anyway:
> 
> Reviewed-by: Vladimir Sementsov-Ogievskiy 
> 
> 
> Side note: I'd not split patches 02 and 03: this way it would be simpler to 
> see the code movement.
> 
> > +if (ret == -ENOTSUP) {
> > +error_free(local_err);
> > +} else if (ret < 0) {
> > +error_report_err(local_err);
> > +}
> > +}
> > +
> > +
> > +
> 
> three empty lines..

Will fix.
> 
> >   /**
> >* Try to get @bs's logical and physical block size.
> >* On success, store them in @bsz struct and return 0.
> > diff --git a/include/block/block.h b/include/block/block.h
> > index c9d7c58765..af03022723 100644
> > --- a/include/block/block.h
> > +++ b/include/block/block.h
> > @@ -428,6 +428,7 @@ int bdrv_freeze_backing_chain(BlockDriverState *bs, 
> > BlockDriverState *base,
> > Error **errp);
> >   void bdrv_unfreeze_backing_chain(BlockDriverState *bs, BlockDriverState 
> > *base);
> >   int coroutine_fn bdrv_co_delete_file(BlockDriverState *bs, Error **errp);
> > +void coroutine_fn bdrv_co_delete_file_noerr(BlockDriverState *bs);
> >   
> >   
> >   typedef struct BdrvCheckResult {
> > 

Thanks a lot for the review!

Best regards,
Maxim Levitsky

> 
> 

[PULL 10/36] i.MX6: Fix bad printf format specifiers

[Peter Maydell]

From: Alex Chen 

We should use printf format specifier "%u" instead of "%d" for
argument of type "unsigned int".

Reported-by: Euler Robot 
Signed-off-by: Alex Chen 
Message-id: 2020112609.112238-4-alex.c...@huawei.com
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 hw/misc/imx6_ccm.c | 20 ++--
 hw/misc/imx6_src.c |  2 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/hw/misc/imx6_ccm.c b/hw/misc/imx6_ccm.c
index 7fec8f0a476..cb740427eca 100644
--- a/hw/misc/imx6_ccm.c
+++ b/hw/misc/imx6_ccm.c
@@ -96,7 +96,7 @@ static const char *imx6_ccm_reg_name(uint32_t reg)
 case CCM_CMEOR:
 return "CMEOR";
 default:
-sprintf(unknown, "%d ?", reg);
+sprintf(unknown, "%u ?", reg);
 return unknown;
 }
 }
@@ -235,7 +235,7 @@ static const char *imx6_analog_reg_name(uint32_t reg)
 case USB_ANALOG_DIGPROG:
 return "USB_ANALOG_DIGPROG";
 default:
-sprintf(unknown, "%d ?", reg);
+sprintf(unknown, "%u ?", reg);
 return unknown;
 }
 }
@@ -263,7 +263,7 @@ static uint64_t imx6_analog_get_pll2_clk(IMX6CCMState *dev)
 freq *= 20;
 }
 
-DPRINTF("freq = %d\n", (uint32_t)freq);
+DPRINTF("freq = %u\n", (uint32_t)freq);
 
 return freq;
 }
@@ -275,7 +275,7 @@ static uint64_t imx6_analog_get_pll2_pfd0_clk(IMX6CCMState 
*dev)
 freq = imx6_analog_get_pll2_clk(dev) * 18
/ EXTRACT(dev->analog[CCM_ANALOG_PFD_528], PFD0_FRAC);
 
-DPRINTF("freq = %d\n", (uint32_t)freq);
+DPRINTF("freq = %u\n", (uint32_t)freq);
 
 return freq;
 }
@@ -287,7 +287,7 @@ static uint64_t imx6_analog_get_pll2_pfd2_clk(IMX6CCMState 
*dev)
 freq = imx6_analog_get_pll2_clk(dev) * 18
/ EXTRACT(dev->analog[CCM_ANALOG_PFD_528], PFD2_FRAC);
 
-DPRINTF("freq = %d\n", (uint32_t)freq);
+DPRINTF("freq = %u\n", (uint32_t)freq);
 
 return freq;
 }
@@ -315,7 +315,7 @@ static uint64_t imx6_analog_get_periph_clk(IMX6CCMState 
*dev)
 break;
 }
 
-DPRINTF("freq = %d\n", (uint32_t)freq);
+DPRINTF("freq = %u\n", (uint32_t)freq);
 
 return freq;
 }
@@ -327,7 +327,7 @@ static uint64_t imx6_ccm_get_ahb_clk(IMX6CCMState *dev)
 freq = imx6_analog_get_periph_clk(dev)
/ (1 + EXTRACT(dev->ccm[CCM_CBCDR], AHB_PODF));
 
-DPRINTF("freq = %d\n", (uint32_t)freq);
+DPRINTF("freq = %u\n", (uint32_t)freq);
 
 return freq;
 }
@@ -339,7 +339,7 @@ static uint64_t imx6_ccm_get_ipg_clk(IMX6CCMState *dev)
 freq = imx6_ccm_get_ahb_clk(dev)
/ (1 + EXTRACT(dev->ccm[CCM_CBCDR], IPG_PODF));
 
-DPRINTF("freq = %d\n", (uint32_t)freq);
+DPRINTF("freq = %u\n", (uint32_t)freq);
 
 return freq;
 }
@@ -351,7 +351,7 @@ static uint64_t imx6_ccm_get_per_clk(IMX6CCMState *dev)
 freq = imx6_ccm_get_ipg_clk(dev)
/ (1 + EXTRACT(dev->ccm[CCM_CSCMR1], PERCLK_PODF));
 
-DPRINTF("freq = %d\n", (uint32_t)freq);
+DPRINTF("freq = %u\n", (uint32_t)freq);
 
 return freq;
 }
@@ -385,7 +385,7 @@ static uint32_t imx6_ccm_get_clock_frequency(IMXCCMState 
*dev, IMXClk clock)
 break;
 }
 
-DPRINTF("Clock = %d) = %d\n", clock, freq);
+DPRINTF("Clock = %d) = %u\n", clock, freq);
 
 return freq;
 }
diff --git a/hw/misc/imx6_src.c b/hw/misc/imx6_src.c
index dd99cc7acf0..79f43759113 100644
--- a/hw/misc/imx6_src.c
+++ b/hw/misc/imx6_src.c
@@ -68,7 +68,7 @@ static const char *imx6_src_reg_name(uint32_t reg)
 case SRC_GPR10:
 return "SRC_GPR10";
 default:
-sprintf(unknown, "%d ?", reg);
+sprintf(unknown, "%u ?", reg);
 return unknown;
 }
 }
-- 
2.20.1

[PULL 03/36] xlnx-zynqmp: Connect Xilinx ZynqMP CAN controllers

[Peter Maydell]

From: Vikram Garhwal 

Connect CAN0 and CAN1 on the ZynqMP.

Reviewed-by: Francisco Iglesias 
Reviewed-by: Edgar E. Iglesias 
Signed-off-by: Vikram Garhwal 
Message-id: 1605728926-352690-3-git-send-email-fnu.vik...@xilinx.com
Signed-off-by: Peter Maydell 
---
 include/hw/arm/xlnx-zynqmp.h |  8 
 hw/arm/xlnx-zcu102.c | 20 
 hw/arm/xlnx-zynqmp.c | 34 ++
 3 files changed, 62 insertions(+)

diff --git a/include/hw/arm/xlnx-zynqmp.h b/include/hw/arm/xlnx-zynqmp.h
index 567d0dba09b..6f45387a173 100644
--- a/include/hw/arm/xlnx-zynqmp.h
+++ b/include/hw/arm/xlnx-zynqmp.h
@@ -22,6 +22,7 @@
 #include "hw/intc/arm_gic.h"
 #include "hw/net/cadence_gem.h"
 #include "hw/char/cadence_uart.h"
+#include "hw/net/xlnx-zynqmp-can.h"
 #include "hw/ide/ahci.h"
 #include "hw/sd/sdhci.h"
 #include "hw/ssi/xilinx_spips.h"
@@ -33,6 +34,7 @@
 #include "hw/cpu/cluster.h"
 #include "target/arm/cpu.h"
 #include "qom/object.h"
+#include "net/can_emu.h"
 
 #define TYPE_XLNX_ZYNQMP "xlnx,zynqmp"
 OBJECT_DECLARE_SIMPLE_TYPE(XlnxZynqMPState, XLNX_ZYNQMP)
@@ -41,6 +43,8 @@ OBJECT_DECLARE_SIMPLE_TYPE(XlnxZynqMPState, XLNX_ZYNQMP)
 #define XLNX_ZYNQMP_NUM_RPU_CPUS 2
 #define XLNX_ZYNQMP_NUM_GEMS 4
 #define XLNX_ZYNQMP_NUM_UARTS 2
+#define XLNX_ZYNQMP_NUM_CAN 2
+#define XLNX_ZYNQMP_CAN_REF_CLK (24 * 1000 * 1000)
 #define XLNX_ZYNQMP_NUM_SDHCI 2
 #define XLNX_ZYNQMP_NUM_SPIS 2
 #define XLNX_ZYNQMP_NUM_GDMA_CH 8
@@ -92,6 +96,7 @@ struct XlnxZynqMPState {
 
 CadenceGEMState gem[XLNX_ZYNQMP_NUM_GEMS];
 CadenceUARTState uart[XLNX_ZYNQMP_NUM_UARTS];
+XlnxZynqMPCANState can[XLNX_ZYNQMP_NUM_CAN];
 SysbusAHCIState sata;
 SDHCIState sdhci[XLNX_ZYNQMP_NUM_SDHCI];
 XilinxSPIPS spi[XLNX_ZYNQMP_NUM_SPIS];
@@ -112,6 +117,9 @@ struct XlnxZynqMPState {
 bool virt;
 /* Has the RPU subsystem?  */
 bool has_rpu;
+
+/* CAN bus. */
+CanBusState *canbus[XLNX_ZYNQMP_NUM_CAN];
 };
 
 #endif
diff --git a/hw/arm/xlnx-zcu102.c b/hw/arm/xlnx-zcu102.c
index ad7fff9697b..4ef0c516bfd 100644
--- a/hw/arm/xlnx-zcu102.c
+++ b/hw/arm/xlnx-zcu102.c
@@ -25,6 +25,7 @@
 #include "sysemu/qtest.h"
 #include "sysemu/device_tree.h"
 #include "qom/object.h"
+#include "net/can_emu.h"
 
 struct XlnxZCU102 {
 MachineState parent_obj;
@@ -34,6 +35,8 @@ struct XlnxZCU102 {
 bool secure;
 bool virt;
 
+CanBusState *canbus[XLNX_ZYNQMP_NUM_CAN];
+
 struct arm_boot_info binfo;
 };
 
@@ -125,6 +128,14 @@ static void xlnx_zcu102_init(MachineState *machine)
 object_property_set_bool(OBJECT(&s->soc), "virtualization", s->virt,
  &error_fatal);
 
+for (i = 0; i < XLNX_ZYNQMP_NUM_CAN; i++) {
+gchar *bus_name = g_strdup_printf("canbus%d", i);
+
+object_property_set_link(OBJECT(&s->soc), bus_name,
+ OBJECT(s->canbus[i]), &error_fatal);
+g_free(bus_name);
+}
+
 qdev_realize(DEVICE(&s->soc), NULL, &error_fatal);
 
 /* Create and plug in the SD cards */
@@ -208,6 +219,15 @@ static void xlnx_zcu102_machine_instance_init(Object *obj)
 s->secure = false;
 /* Default to virt (EL2) being disabled */
 s->virt = false;
+object_property_add_link(obj, "xlnx-zcu102.canbus0", TYPE_CAN_BUS,
+ (Object **)&s->canbus[0],
+ object_property_allow_set_link,
+ 0);
+
+object_property_add_link(obj, "xlnx-zcu102.canbus1", TYPE_CAN_BUS,
+ (Object **)&s->canbus[1],
+ object_property_allow_set_link,
+ 0);
 }
 
 static void xlnx_zcu102_machine_class_init(ObjectClass *oc, void *data)
diff --git a/hw/arm/xlnx-zynqmp.c b/hw/arm/xlnx-zynqmp.c
index 7885bb17745..881847255b4 100644
--- a/hw/arm/xlnx-zynqmp.c
+++ b/hw/arm/xlnx-zynqmp.c
@@ -81,6 +81,14 @@ static const int uart_intr[XLNX_ZYNQMP_NUM_UARTS] = {
 21, 22,
 };
 
+static const uint64_t can_addr[XLNX_ZYNQMP_NUM_CAN] = {
+0xFF06, 0xFF07,
+};
+
+static const int can_intr[XLNX_ZYNQMP_NUM_CAN] = {
+23, 24,
+};
+
 static const uint64_t sdhci_addr[XLNX_ZYNQMP_NUM_SDHCI] = {
 0xFF16, 0xFF17,
 };
@@ -243,6 +251,11 @@ static void xlnx_zynqmp_init(Object *obj)
 TYPE_CADENCE_UART);
 }
 
+for (i = 0; i < XLNX_ZYNQMP_NUM_CAN; i++) {
+object_initialize_child(obj, "can[*]", &s->can[i],
+TYPE_XLNX_ZYNQMP_CAN);
+}
+
 object_initialize_child(obj, "sata", &s->sata, TYPE_SYSBUS_AHCI);
 
 for (i = 0; i < XLNX_ZYNQMP_NUM_SDHCI; i++) {
@@ -482,6 +495,23 @@ static void xlnx_zynqmp_realize(DeviceState *dev, Error 
**errp)
gic_spi[uart_intr[i]]);
 }
 
+for (i = 0; i < XLNX_ZYNQMP_NUM_CAN; i++) {
+object_property_set_int(OBJECT(&s->can[i]), "ext_clk_freq",
+XLNX_ZYNQMP_CAN_REF_CLK, &error

[PULL 00/36] target-arm queue

[Peter Maydell]

First pullreq for 6.0: mostly my v8.1M work, plus some other
bits and pieces. (I still have a lot of stuff in my to-review
folder, which I may or may not get to before the Christmas break...)

thanks
-- PMM

The following changes since commit 5e7b204dbfae9a562fc73684986f936b97f63877:

  Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 
(2020-12-09 20:08:54 +)

are available in the Git repository at:

  https://git.linaro.org/people/pmaydell/qemu-arm.git 
tags/pull-target-arm-20201210

for you to fetch changes up to 71f916be1c7e9ede0e37d9cabc781b5a9e8638ff:

  hw/arm/armv7m: Correct typo in QOM object name (2020-12-10 11:44:56 +)


target-arm queue:
 * hw/arm/smmuv3: Fix up L1STD_SPAN decoding
 * xlnx-zynqmp: Support Xilinx ZynqMP CAN controllers
 * sbsa-ref: allow to use Cortex-A53/57/72 cpus
 * Various minor code cleanups
 * hw/intc/armv7m_nvic: Make all of system PPB range be RAZWI/BusFault
 * Implement more pieces of ARMv8.1M support


Alex Chen (4):
  i.MX25: Fix bad printf format specifiers
  i.MX31: Fix bad printf format specifiers
  i.MX6: Fix bad printf format specifiers
  i.MX6ul: Fix bad printf format specifiers

Havard Skinnemoen (1):
  tests/qtest/npcm7xx_rng-test: dump random data on failure

Kunkun Jiang (1):
  hw/arm/smmuv3: Fix up L1STD_SPAN decoding

Marcin Juszkiewicz (1):
  sbsa-ref: allow to use Cortex-A53/57/72 cpus

Peter Maydell (25):
  hw/intc/armv7m_nvic: Make all of system PPB range be RAZWI/BusFault
  target/arm: Implement v8.1M PXN extension
  target/arm: Don't clobber ID_PFR1.Security on M-profile cores
  target/arm: Implement VSCCLRM insn
  target/arm: Implement CLRM instruction
  target/arm: Enforce M-profile VMRS/VMSR register restrictions
  target/arm: Refactor M-profile VMSR/VMRS handling
  target/arm: Move general-use constant expanders up in translate.c
  target/arm: Implement VLDR/VSTR system register
  target/arm: Implement M-profile FPSCR_nzcvqc
  target/arm: Use new FPCR_NZCV_MASK constant
  target/arm: Factor out preserve-fp-state from full_vfp_access_check()
  target/arm: Implement FPCXT_S fp system register
  hw/intc/armv7m_nvic: Update FPDSCR masking for v8.1M
  target/arm: For v8.1M, always clear R0-R3, R12, APSR, EPSR on exception 
entry
  target/arm: In v8.1M, don't set HFSR.FORCED on vector table fetch failures
  target/arm: Implement v8.1M REVIDR register
  target/arm: Implement new v8.1M NOCP check for exception return
  target/arm: Implement new v8.1M VLLDM and VLSTM encodings
  hw/intc/armv7m_nvic: Support v8.1M CCR.TRD bit
  target/arm: Implement CCR_S.TRD behaviour for SG insns
  hw/intc/armv7m_nvic: Fix "return from inactive handler" check
  target/arm: Implement M-profile "minimal RAS implementation"
  hw/intc/armv7m_nvic: Implement read/write for RAS register block
  hw/arm/armv7m: Correct typo in QOM object name

Vikram Garhwal (4):
  hw/net/can: Introduce Xilinx ZynqMP CAN controller
  xlnx-zynqmp: Connect Xilinx ZynqMP CAN controllers
  tests/qtest: Introduce tests for Xilinx ZynqMP CAN controller
  MAINTAINERS: Add maintainer entry for Xilinx ZynqMP CAN controller

 meson.build  |1 +
 hw/arm/smmuv3-internal.h |2 +-
 hw/net/can/trace.h   |1 +
 include/hw/arm/xlnx-zynqmp.h |8 +
 include/hw/intc/armv7m_nvic.h|2 +
 include/hw/net/xlnx-zynqmp-can.h |   78 +++
 target/arm/cpu.h |   46 ++
 target/arm/m-nocp.decode |   10 +-
 target/arm/t32.decode|   10 +-
 target/arm/vfp.decode|   14 +
 hw/arm/armv7m.c  |4 +-
 hw/arm/sbsa-ref.c|   23 +-
 hw/arm/xlnx-zcu102.c |   20 +
 hw/arm/xlnx-zynqmp.c |   34 ++
 hw/intc/armv7m_nvic.c|  246 ++--
 hw/misc/imx25_ccm.c  |   12 +-
 hw/misc/imx31_ccm.c  |   14 +-
 hw/misc/imx6_ccm.c   |   20 +-
 hw/misc/imx6_src.c   |2 +-
 hw/misc/imx6ul_ccm.c |4 +-
 hw/misc/imx_ccm.c|4 +-
 hw/net/can/xlnx-zynqmp-can.c | 1161 ++
 target/arm/cpu.c |5 +-
 target/arm/helper.c  |7 +-
 target/arm/m_helper.c|  130 -
 target/arm/translate.c   |  105 +++-
 tests/qtest/npcm7xx_rng-test.c   |   12 +
 tests/qtest/xlnx-can-test.c  |  360 
 MAINTAINERS  |8 +
 hw/Kconfig   |1 +
 hw/net/can/meson.build   |1 +
 hw/net/can/trace-events  |9 +
 target/arm/translate-vfp.c.inc   |  511 -
 tests/qtest/meson.build  |1 +
 34 files ch

[PULL 05/36] MAINTAINERS: Add maintainer entry for Xilinx ZynqMP CAN controller

[Peter Maydell]

From: Vikram Garhwal 

Reviewed-by: Francisco Iglesias 
Reviewed-by: Edgar E. Iglesias 
Signed-off-by: Vikram Garhwal 
Message-id: 1605728926-352690-5-git-send-email-fnu.vik...@xilinx.com
Signed-off-by: Peter Maydell 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 68bc160f41b..a83416d54c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1563,6 +1563,14 @@ F: hw/net/opencores_eth.c
 
 Devices
 ---
+Xilinx CAN
+M: Vikram Garhwal 
+M: Francisco Iglesias 
+S: Maintained
+F: hw/net/can/xlnx-*
+F: include/hw/net/xlnx-*
+F: tests/qtest/xlnx-can-test*
+
 EDU
 M: Jiri Slaby 
 S: Maintained
-- 
2.20.1

[PULL 13/36] target/arm: Implement v8.1M PXN extension

[Peter Maydell]

In v8.1M the PXN architecture extension adds a new PXN bit to the
MPU_RLAR registers, which forbids execution of code in the region
from a privileged mode.

This is another feature which is just in the generic "in v8.1M" set
and has no ID register field indicating its presence.

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Message-id: 20201119215617.29887-3-peter.mayd...@linaro.org
---
 target/arm/helper.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 38cd35c0492..7b8bcd69030 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -11754,6 +11754,11 @@ bool pmsav8_mpu_lookup(CPUARMState *env, uint32_t 
address,
 } else {
 uint32_t ap = extract32(env->pmsav8.rbar[secure][matchregion], 1, 2);
 uint32_t xn = extract32(env->pmsav8.rbar[secure][matchregion], 0, 1);
+bool pxn = false;
+
+if (arm_feature(env, ARM_FEATURE_V8_1M)) {
+pxn = extract32(env->pmsav8.rlar[secure][matchregion], 4, 1);
+}
 
 if (m_is_system_region(env, address)) {
 /* System space is always execute never */
@@ -11761,7 +11766,7 @@ bool pmsav8_mpu_lookup(CPUARMState *env, uint32_t 
address,
 }
 
 *prot = simple_ap_to_rw_prot(env, mmu_idx, ap);
-if (*prot && !xn) {
+if (*prot && !xn && !(pxn && !is_user)) {
 *prot |= PAGE_EXEC;
 }
 /* We don't need to look the attribute up in the MAIR0/MAIR1
-- 
2.20.1

[PULL 02/36] hw/net/can: Introduce Xilinx ZynqMP CAN controller

[Peter Maydell]

From: Vikram Garhwal 

The Xilinx ZynqMP CAN controller is developed based on SocketCAN, QEMU CAN bus
implementation. Bus connection and socketCAN connection for each CAN module
can be set through command lines.

Example for using single CAN:
-object can-bus,id=canbus0 \
-machine xlnx-zcu102.canbus0=canbus0 \
-object can-host-socketcan,id=socketcan0,if=vcan0,canbus=canbus0

Example for connecting both CAN to same virtual CAN on host machine:
-object can-bus,id=canbus0 -object can-bus,id=canbus1 \
-machine xlnx-zcu102.canbus0=canbus0 \
-machine xlnx-zcu102.canbus1=canbus1 \
-object can-host-socketcan,id=socketcan0,if=vcan0,canbus=canbus0 \
-object can-host-socketcan,id=socketcan1,if=vcan0,canbus=canbus1

To create virtual CAN on the host machine, please check the QEMU CAN docs:
https://github.com/qemu/qemu/blob/master/docs/can.txt

Signed-off-by: Vikram Garhwal 
Message-id: 1605728926-352690-2-git-send-email-fnu.vik...@xilinx.com
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 meson.build  |1 +
 hw/net/can/trace.h   |1 +
 include/hw/net/xlnx-zynqmp-can.h |   78 ++
 hw/net/can/xlnx-zynqmp-can.c | 1161 ++
 hw/Kconfig   |1 +
 hw/net/can/meson.build   |1 +
 hw/net/can/trace-events  |9 +
 7 files changed, 1252 insertions(+)
 create mode 100644 hw/net/can/trace.h
 create mode 100644 include/hw/net/xlnx-zynqmp-can.h
 create mode 100644 hw/net/can/xlnx-zynqmp-can.c
 create mode 100644 hw/net/can/trace-events

diff --git a/meson.build b/meson.build
index 732b29a1f37..9ea05ab49fa 100644
--- a/meson.build
+++ b/meson.build
@@ -1433,6 +1433,7 @@ if have_system
 'hw/misc',
 'hw/misc/macio',
 'hw/net',
+'hw/net/can',
 'hw/nvram',
 'hw/pci',
 'hw/pci-host',
diff --git a/hw/net/can/trace.h b/hw/net/can/trace.h
new file mode 100644
index 000..d391c649012
--- /dev/null
+++ b/hw/net/can/trace.h
@@ -0,0 +1 @@
+#include "trace/trace-hw_net_can.h"
diff --git a/include/hw/net/xlnx-zynqmp-can.h b/include/hw/net/xlnx-zynqmp-can.h
new file mode 100644
index 000..eb1558708bb
--- /dev/null
+++ b/include/hw/net/xlnx-zynqmp-can.h
@@ -0,0 +1,78 @@
+/*
+ * QEMU model of the Xilinx ZynqMP CAN controller.
+ *
+ * Copyright (c) 2020 Xilinx Inc.
+ *
+ * Written-by: Vikram Garhwal
+ *
+ * Based on QEMU CAN Device emulation implemented by Jin Yang, Deniz Eren and
+ * Pavel Pisa.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#ifndef XLNX_ZYNQMP_CAN_H
+#define XLNX_ZYNQMP_CAN_H
+
+#include "hw/register.h"
+#include "net/can_emu.h"
+#include "net/can_host.h"
+#include "qemu/fifo32.h"
+#include "hw/ptimer.h"
+#include "hw/qdev-clock.h"
+
+#define TYPE_XLNX_ZYNQMP_CAN "xlnx.zynqmp-can"
+
+#define XLNX_ZYNQMP_CAN(obj) \
+ OBJECT_CHECK(XlnxZynqMPCANState, (obj), TYPE_XLNX_ZYNQMP_CAN)
+
+#define MAX_CAN_CTRLS  2
+#define XLNX_ZYNQMP_CAN_R_MAX (0x84 / 4)
+#define MAILBOX_CAPACITY   64
+#define CAN_TIMER_MAX  0XUL
+#define CAN_DEFAULT_CLOCK (24 * 1000 * 1000)
+
+/* Each CAN_FRAME will have 4 * 32bit size. */
+#define CAN_FRAME_SIZE 4
+#define RXFIFO_SIZE(MAILBOX_CAPACITY * CAN_FRAME_SIZE)
+
+typedef struct XlnxZynqMPCANState {
+SysBusDeviceparent_obj;
+MemoryRegioniomem;
+
+qemu_irqirq;
+
+CanBusClientState   bus_client;
+CanBusState *canbus;
+
+struct {
+uint32_text_clk_freq;
+} cfg;
+
+RegisterInforeg_info[XLNX_ZYNQMP_CAN_R_MAX];
+uint32_tregs[XLNX_ZYNQMP_CAN_R_MAX];
+
+Fifo32  rx_fifo;
+Fifo32  tx_fifo;
+Fifo32  txhpb_fifo;
+
+ptimer_state*can_timer;
+} XlnxZynqMPCANState;
+
+#endif
diff --git a/hw/net/can/xlnx-zynqmp-can.c b/hw/net/can/xlnx-zynqmp-can.c
new file mode 100644
index 000..affa21a5ed3
--- /dev/n

[PULL 04/36] tests/qtest: Introduce tests for Xilinx ZynqMP CAN controller

[Peter Maydell]

From: Vikram Garhwal 

The QTests perform five tests on the Xilinx ZynqMP CAN controller:
Tests the CAN controller in loopback, sleep and snoop mode.
Tests filtering of incoming CAN messages.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Francisco Iglesias 
Signed-off-by: Vikram Garhwal 
Message-id: 1605728926-352690-4-git-send-email-fnu.vik...@xilinx.com
Signed-off-by: Peter Maydell 
---
 tests/qtest/xlnx-can-test.c | 360 
 tests/qtest/meson.build |   1 +
 2 files changed, 361 insertions(+)
 create mode 100644 tests/qtest/xlnx-can-test.c

diff --git a/tests/qtest/xlnx-can-test.c b/tests/qtest/xlnx-can-test.c
new file mode 100644
index 000..3d1120005b6
--- /dev/null
+++ b/tests/qtest/xlnx-can-test.c
@@ -0,0 +1,360 @@
+/*
+ * QTests for the Xilinx ZynqMP CAN controller.
+ *
+ * Copyright (c) 2020 Xilinx Inc.
+ *
+ * Written-by: Vikram Garhwal
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "libqos/libqtest.h"
+
+/* Base address. */
+#define CAN0_BASE_ADDR  0xFF06
+#define CAN1_BASE_ADDR  0xFF07
+
+/* Register addresses. */
+#define R_SRR_OFFSET0x00
+#define R_MSR_OFFSET0x04
+#define R_SR_OFFSET 0x18
+#define R_ISR_OFFSET0x1C
+#define R_ICR_OFFSET0x24
+#define R_TXID_OFFSET   0x30
+#define R_TXDLC_OFFSET  0x34
+#define R_TXDATA1_OFFSET0x38
+#define R_TXDATA2_OFFSET0x3C
+#define R_RXID_OFFSET   0x50
+#define R_RXDLC_OFFSET  0x54
+#define R_RXDATA1_OFFSET0x58
+#define R_RXDATA2_OFFSET0x5C
+#define R_AFR   0x60
+#define R_AFMR1 0x64
+#define R_AFIR1 0x68
+#define R_AFMR2 0x6C
+#define R_AFIR2 0x70
+#define R_AFMR3 0x74
+#define R_AFIR3 0x78
+#define R_AFMR4 0x7C
+#define R_AFIR4 0x80
+
+/* CAN modes. */
+#define CONFIG_MODE 0x00
+#define NORMAL_MODE 0x00
+#define LOOPBACK_MODE   0x02
+#define SNOOP_MODE  0x04
+#define SLEEP_MODE  0x01
+#define ENABLE_CAN  (1 << 1)
+#define STATUS_NORMAL_MODE  (1 << 3)
+#define STATUS_LOOPBACK_MODE(1 << 1)
+#define STATUS_SNOOP_MODE   (1 << 12)
+#define STATUS_SLEEP_MODE   (1 << 2)
+#define ISR_TXOK(1 << 1)
+#define ISR_RXOK(1 << 4)
+
+static void match_rx_tx_data(const uint32_t *buf_tx, const uint32_t *buf_rx,
+ uint8_t can_timestamp)
+{
+uint16_t size = 0;
+uint8_t len = 4;
+
+while (size < len) {
+if (R_RXID_OFFSET + 4 * size == R_RXDLC_OFFSET)  {
+g_assert_cmpint(buf_rx[size], ==, buf_tx[size] + can_timestamp);
+} else {
+g_assert_cmpint(buf_rx[size], ==, buf_tx[size]);
+}
+
+size++;
+}
+}
+
+static void read_data(QTestState *qts, uint64_t can_base_addr, uint32_t 
*buf_rx)
+{
+uint32_t int_status;
+
+/* Read the interrupt on CAN rx. */
+int_status = qtest_readl(qts, can_base_addr + R_ISR_OFFSET) & ISR_RXOK;
+
+g_assert_cmpint(int_status, ==, ISR_RXOK);
+
+/* Read the RX register data for CAN. */
+buf_rx[0] = qtest_readl(qts, can_base_addr + R_RXID_OFFSET);
+buf_rx[1] = qtest_readl(qts, can_base_addr + R_RXDLC_OFFSET);
+buf_rx[2] = qtest_readl(qts, can_base_addr + R_RXDATA1_OFFSET);
+buf_rx[3] = qtest_readl(qts, can_base_addr + R_RXDATA2_OFFSET);
+
+/* Clear the RX interrupt. */
+qtest_writel(qts, CAN1_BASE_ADDR + R_ICR_OFFSET, ISR_RXOK);
+}
+
+static void send_data(QTestState *qts, uint64_t can_base_addr,
+  const uint32_t *buf_tx)
+{
+uint32_t int_status;
+
+/* Write the TX register data for CAN. */
+qtest_writel(qts, can_base_addr + R_TXID_OFFSET, buf_tx[0]);
+qtest_wr

[PULL 06/36] sbsa-ref: allow to use Cortex-A53/57/72 cpus

[Peter Maydell]

From: Marcin Juszkiewicz 

Trusted Firmware now supports A72 on sbsa-ref by default [1] so enable
it for QEMU as well. A53 was already enabled there.

1. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/7117

Signed-off-by: Marcin Juszkiewicz 
Reviewed-by: Richard Henderson 
Message-id: 20201120141705.246690-1-marcin.juszkiew...@linaro.org
Reviewed-by: Peter Maydell 
Signed-off-by: Peter Maydell 
---
 hw/arm/sbsa-ref.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index 7d9e180c0db..4a5ea42938a 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -143,6 +143,24 @@ static const int sbsa_ref_irqmap[] = {
 [SBSA_GWDT] = 16,
 };
 
+static const char * const valid_cpus[] = {
+ARM_CPU_TYPE_NAME("cortex-a53"),
+ARM_CPU_TYPE_NAME("cortex-a57"),
+ARM_CPU_TYPE_NAME("cortex-a72"),
+};
+
+static bool cpu_type_valid(const char *cpu)
+{
+int i;
+
+for (i = 0; i < ARRAY_SIZE(valid_cpus); i++) {
+if (strcmp(cpu, valid_cpus[i]) == 0) {
+return true;
+}
+}
+return false;
+}
+
 static uint64_t sbsa_ref_cpu_mp_affinity(SBSAMachineState *sms, int idx)
 {
 uint8_t clustersz = ARM_DEFAULT_CPUS_PER_CLUSTER;
@@ -649,9 +667,8 @@ static void sbsa_ref_init(MachineState *machine)
 const CPUArchIdList *possible_cpus;
 int n, sbsa_max_cpus;
 
-if (strcmp(machine->cpu_type, ARM_CPU_TYPE_NAME("cortex-a57"))) {
-error_report("sbsa-ref: CPU type other than the built-in "
- "cortex-a57 not supported");
+if (!cpu_type_valid(machine->cpu_type)) {
+error_report("mach-virt: CPU type %s not supported", 
machine->cpu_type);
 exit(1);
 }
 
-- 
2.20.1

[PULL 17/36] target/arm: Enforce M-profile VMRS/VMSR register restrictions

[Peter Maydell]

For M-profile before v8.1M, the only valid register for VMSR/VMRS is
the FPSCR.  We have a comment that states this, but the actual logic
to forbid accesses for any other register value is missing, so we
would end up with A-profile style behaviour.  Add the missing check.

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Message-id: 20201119215617.29887-7-peter.mayd...@linaro.org
---
 target/arm/translate-vfp.c.inc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/target/arm/translate-vfp.c.inc b/target/arm/translate-vfp.c.inc
index 2a67ed0f6e2..e100182a32c 100644
--- a/target/arm/translate-vfp.c.inc
+++ b/target/arm/translate-vfp.c.inc
@@ -622,7 +622,10 @@ static bool trans_VMSR_VMRS(DisasContext *s, arg_VMSR_VMRS 
*a)
  * Accesses to R15 are UNPREDICTABLE; we choose to undef.
  * (FPSCR -> r15 is a special case which writes to the PSR flags.)
  */
-if (a->rt == 15 && (!a->l || a->reg != ARM_VFP_FPSCR)) {
+if (a->reg != ARM_VFP_FPSCR) {
+return false;
+}
+if (a->rt == 15 && !a->l) {
 return false;
 }
 }
-- 
2.20.1

[PULL 01/36] hw/arm/smmuv3: Fix up L1STD_SPAN decoding

[Peter Maydell]

From: Kunkun Jiang 

Accroding to the SMMUv3 spec, the SPAN field of Level1 Stream Table
Descriptor is 5 bits([4:0]).

Fixes: 9bde7f0674f(hw/arm/smmuv3: Implement translate callback)
Signed-off-by: Kunkun Jiang 
Message-id: 20201124023711.1184-1-jiangkun...@huawei.com
Reviewed-by: Peter Maydell 
Acked-by: Eric Auger 
Signed-off-by: Peter Maydell 
---
 hw/arm/smmuv3-internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
index fa3c088972e..b6f7e53b7c7 100644
--- a/hw/arm/smmuv3-internal.h
+++ b/hw/arm/smmuv3-internal.h
@@ -633,6 +633,6 @@ static inline uint64_t l1std_l2ptr(STEDesc *desc)
 return hi << 32 | lo;
 }
 
-#define L1STD_SPAN(stm) (extract32((stm)->word[0], 0, 4))
+#define L1STD_SPAN(stm) (extract32((stm)->word[0], 0, 5))
 
 #endif
-- 
2.20.1

[PULL 16/36] target/arm: Implement CLRM instruction

[Peter Maydell]

In v8.1M the new CLRM instruction allows zeroing an arbitrary set of
the general-purpose registers and APSR.  Implement this.

The encoding is a subset of the LDMIA T2 encoding, using what would
be Rn=0b (which UNDEFs for LDMIA).

Signed-off-by: Peter Maydell 
Reviewed-by: Richard Henderson 
Message-id: 20201119215617.29887-6-peter.mayd...@linaro.org
---
 target/arm/t32.decode  |  6 +-
 target/arm/translate.c | 38 ++
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/target/arm/t32.decode b/target/arm/t32.decode
index cfcc71bfb0a..f045eb62c84 100644
--- a/target/arm/t32.decode
+++ b/target/arm/t32.decode
@@ -609,7 +609,11 @@ UXTAB 1010 0101    10..    
   @rrr_rot
 
 STM_t32  1110 1000 10.0   @ldstm i=1 b=0
 STM_t32  1110 1001 00.0   @ldstm i=0 b=1
-LDM_t32  1110 1000 10.1   @ldstm i=1 b=0
+{
+  # Rn=15 UNDEFs for LDM; M-profile CLRM uses that encoding
+  CLRM   1110 1000 1001  list:16
+  LDM_t321110 1000 10.1   @ldstm i=1 b=0
+}
 LDM_t32  1110 1001 00.1   @ldstm i=0 b=1
 
 &rfe !extern rn w pu
diff --git a/target/arm/translate.c b/target/arm/translate.c
index 9f2b6018a21..47a1a5739c8 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -7968,6 +7968,44 @@ static bool trans_LDM_t16(DisasContext *s, 
arg_ldst_block *a)
 return do_ldm(s, a, 1);
 }
 
+static bool trans_CLRM(DisasContext *s, arg_CLRM *a)
+{
+int i;
+TCGv_i32 zero;
+
+if (!dc_isar_feature(aa32_m_sec_state, s)) {
+return false;
+}
+
+if (extract32(a->list, 13, 1)) {
+return false;
+}
+
+if (!a->list) {
+/* UNPREDICTABLE; we choose to UNDEF */
+return false;
+}
+
+zero = tcg_const_i32(0);
+for (i = 0; i < 15; i++) {
+if (extract32(a->list, i, 1)) {
+/* Clear R[i] */
+tcg_gen_mov_i32(cpu_R[i], zero);
+}
+}
+if (extract32(a->list, 15, 1)) {
+/*
+ * Clear APSR (by calling the MSR helper with the same argument
+ * as for "MSR APSR_nzcvqg, Rn": mask = 0b1100, SYSM=0)
+ */
+TCGv_i32 maskreg = tcg_const_i32(0xc << 8);
+gen_helper_v7m_msr(cpu_env, maskreg, zero);
+tcg_temp_free_i32(maskreg);
+}
+tcg_temp_free_i32(zero);
+return true;
+}
+
 /*
  * Branch, branch with link
  */
-- 
2.20.1