Re: Let's remove some deprecated stuff
Philippe Mathieu-Daudé writes: > On 4/29/21 3:46 PM, Gerd Hoffmann wrote: > >> Hmm. Not so easy I suspect. While most sound cards map to a single >> device there are exceptions. pcspk is build-in and hda is two devices. > > What do you mean by "pcspk is build-in"? > > Do you mean "the 'pcspk' audiodev is build in the 8254 PIT device"? > (see pcspk_audio_init). I think so. The 8254 is an onboard device, i.e. it's always there. In real PC hardware, one of its timers is wired to a speaker. In our virtual hardware, we have separate "isa-pit" (or "kvm-pit) and "isa-pcspk" devices, where the latter connects to the former via link property "pit", and may be connected to an audio backend, but isn't by default. To connect to one, use -machine pcspk-audiodev=... > FWIW I'm using this device as example to work on the PWM API, > and I see the AUD API as a generic DSP processing one. > And in my TODO I have "split pcspk audiodev backend from 8254". Not sure I understand your TODO, but then I don't have to :)
Re: Let's remove some deprecated stuff
On Thu, Apr 29, 2021 at 05:05:35PM +0200, Philippe Mathieu-Daudé wrote: > On 4/29/21 3:46 PM, Gerd Hoffmann wrote: > > > Hmm. Not so easy I suspect. While most sound cards map to a single > > device there are exceptions. pcspk is build-in and hda is two devices. > > What do you mean by "pcspk is build-in"? > > Do you mean "the 'pcspk' audiodev is build in the 8254 PIT device"? > (see pcspk_audio_init). built-in == "the device is there, no matter what". Being part of 8254 PIT is the underlying technical reason for that. The only thing you can do when configuring qemu is assigning an audio backend to it (or not). take care, Gerd
Re: [RFC PATCH v2 2/4] hw/arm/virt: Parse -smp cluster parameter in virt_smp_parse
On Fri, Apr 30, 2021 at 08:41:25AM +0200, Andrew Jones wrote: > On Fri, Apr 30, 2021 at 01:09:00PM +0800, wangyanan (Y) wrote: > > But I think the requirement for ARM "if even one parameter other than cpus > > or maxcpus > > is provided then all parameters must be provided" will be better. This can > > ensure the > > whole accurate users-specified topology. As you mentioned, if anybody who > > bothers > > to specify one, why not also specify the others. > > > > I can add the requirement for ARM in the documentation, and also check the > > parameters > > in virt_smp_parse. Will this be fine? > > We sort of have to support command lines that are missing 'maxcpus' and > 'clusters', unless we work together with libvirt to make the change. > Currently libvirt will generate '-smp 16,sockets=16,cores=1,threads=1' > from '16'. That's sufficient for our > stricter, but not completely strict requirements. And, I still think > 'threads' could be optional, because there's a good chance the user > doesn't want to describe them, so a default of 1 is good enough. Also, > given maxcpus, but not cpus, it's pretty obvious that cpus should equal > maxcpus. > We also still need just 'cpus' or just 'maxcpus' to work, since that already works now. So, at least these should work -smp N -smp maxcpus=N -smp N,maxcpus=M -smp N,sockets=N,cores=1,threads=1 -smp N,maxcpus=M,sockets=M,cores=1,threads=1 since they work today, even though no topology is described. If we want to describe a topology for the first three, then we'll have to pick one, which brings us back to the sockets over cores stuff. Or, we could choose to just not generate topology descriptions when none is provided. Thanks, drew
RE: [PATCH v2 07/12] virtio-gpu: Add virtio_gpu_resource_create_blob
Hi Gerd,
> > res->remapsz = QEMU_ALIGN_UP(res->remapsz,
> > qemu_real_host_page_size);
> >
> > res->remapped = mmap(NULL, res->remapsz, PROT_READ, @@ -152,7
> > +155,9 @@ void virtio_gpu_init_udmabuf(struct virtio_gpu_simple_resource
> > *res)
> > pdata = res->remapped;
> > }
> >
> > -(void) pdata;
> > +if (pdata) {
> > +res->blob = pdata;
> > +}
> > }
>
> That is confusing. Patch #2 introduces code which is removed here (probably
> leftovers
> from udmabuf prototype which didn't use blob resources). I think it would be
> useful to
> merge patch #2 with this one.
[Kasireddy, Vivek] Ok, will do.
>
> Also we might cleanup things a bit. Do we need separate remapsz + blob_size
> fields in the
> first place? Probably not ...
[Kasireddy, Vivek] Right, we don't. I was also going to slightly change the
names of some
of the new functions in v3 to keep them consistent with the rest of the code.
Do you have
any additional feedback for the other patches that I can include in v3?
>
> take care,
> Gerd
>
> PS: Can you explicitly cc me on the next version of the patch series?
> Some patches (this one for example) are on the list only and not in
> my inbox. Thanks.
[Kasireddy, Vivek] Sure. I was hoping that including the Based-on-patch-by
tag would do just that but looks like it doesn't.
Thanks,
Vivek
Re: [PATCH v3 3/3] hw/core/loader: clear uninitialized ROM space
On Thu, Apr 29, 2021 at 04:13:26PM +0200, Laurent Vivier wrote: As for "hw/elf_ops: clear uninitialized segment space" we need to clear the uninitialized space when the ELF is set in ROM. Signed-off-by: Laurent Vivier Reviewed-by: Stefano Garzarella
[PATCH] docs/system: riscv: Include shakti_c machine documentation
shakti_c machine documentation was missed in the riscv target doc. Signed-off-by: Bin Meng --- docs/system/target-riscv.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/system/target-riscv.rst b/docs/system/target-riscv.rst index 8d5946fbbb..4b3c78382c 100644 --- a/docs/system/target-riscv.rst +++ b/docs/system/target-riscv.rst @@ -67,6 +67,7 @@ undocumented; you can get a complete list by running :maxdepth: 1 riscv/microchip-icicle-kit + riscv/shakti-c riscv/sifive_u RISC-V CPU features -- 2.25.1
[PATCH v2 2/8] hw/riscv: virt: Switch to use qemu_fdt_setprop_string_array() helper
From: Bin Meng
Since commit 78da6a1bca22 ("device_tree: add qemu_fdt_setprop_string_array
helper"),
we can use the new helper to set the compatible strings for the
SiFive test device node.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v2:
- use "static const char * const" for compat
hw/riscv/virt.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index c0dc69ff33..992f1c58a9 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -395,8 +395,11 @@ static void create_fdt(RISCVVirtState *s, const
MemMapEntry *memmap,
(long)memmap[VIRT_TEST].base);
qemu_fdt_add_subnode(fdt, name);
{
-const char compat[] = "sifive,test1\0sifive,test0\0syscon";
-qemu_fdt_setprop(fdt, name, "compatible", compat, sizeof(compat));
+static const char * const compat[3] = {
+"sifive,test1", "sifive,test0", "syscon"
+};
+qemu_fdt_setprop_string_array(fdt, name, "compatible", (char
**)&compat,
+ ARRAY_SIZE(compat));
}
qemu_fdt_setprop_cells(fdt, name, "reg",
0x0, memmap[VIRT_TEST].base,
--
2.25.1
[PATCH v2 1/8] hw/riscv: sifive_u: Switch to use qemu_fdt_setprop_string_array() helper
From: Bin Meng
Since commit 78da6a1bca22 ("device_tree: add qemu_fdt_setprop_string_array
helper"),
we can use the new helper to set the clock name for the ethernet
controller node.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v2:
- use "static const char * const" for ethclk_names
hw/riscv/sifive_u.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 7b59942369..1b8af0c07a 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -96,9 +96,9 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry
*memmap,
int cpu;
uint32_t *cells;
char *nodename;
-char ethclk_names[] = "pclk\0hclk";
uint32_t plic_phandle, prci_phandle, gpio_phandle, phandle = 1;
uint32_t hfclk_phandle, rtcclk_phandle, phy_phandle;
+static const char * const ethclk_names[2] = { "pclk", "hclk" };
if (ms->dtb) {
fdt = s->fdt = load_device_tree(ms->dtb, &s->fdt_size);
@@ -413,8 +413,8 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry
*memmap,
qemu_fdt_setprop_cell(fdt, nodename, "interrupts", SIFIVE_U_GEM_IRQ);
qemu_fdt_setprop_cells(fdt, nodename, "clocks",
prci_phandle, PRCI_CLK_GEMGXLPLL, prci_phandle, PRCI_CLK_GEMGXLPLL);
-qemu_fdt_setprop(fdt, nodename, "clock-names", ethclk_names,
-sizeof(ethclk_names));
+qemu_fdt_setprop_string_array(fdt, nodename, "clock-names",
+(char **)ðclk_names, ARRAY_SIZE(ethclk_names));
qemu_fdt_setprop(fdt, nodename, "local-mac-address",
s->soc.gem.conf.macaddr.a, ETH_ALEN);
qemu_fdt_setprop_cell(fdt, nodename, "#address-cells", 1);
--
2.25.1
[PATCH v2 6/8] docs/system/riscv: sifive_u: Document '-dtb' usage
From: Bin Meng
Update the 'sifive_u' machine documentation to mention the '-dtb'
option that can be used to pass a custom DTB to QEMU.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
(no changes since v1)
docs/system/riscv/sifive_u.rst | 47 +-
1 file changed, 41 insertions(+), 6 deletions(-)
diff --git a/docs/system/riscv/sifive_u.rst b/docs/system/riscv/sifive_u.rst
index dcdfbda931..32d0a1b85d 100644
--- a/docs/system/riscv/sifive_u.rst
+++ b/docs/system/riscv/sifive_u.rst
@@ -36,12 +36,21 @@ Hardware configuration information
--
The ``sifive_u`` machine automatically generates a device tree blob ("dtb")
-which it passes to the guest. This provides information about the addresses,
-interrupt lines and other configuration of the various devices in the system.
-Guest software should discover the devices that are present in the generated
-DTB instead of using a DTB for the real hardware, as some of the devices are
-not modeled by QEMU and trying to access these devices may cause unexpected
-behavior.
+which it passes to the guest, if there is no ``-dtb`` option. This provides
+information about the addresses, interrupt lines and other configuration of
+the various devices in the system. Guest software should discover the devices
+that are present in the generated DTB instead of using a DTB for the real
+hardware, as some of the devices are not modeled by QEMU and trying to access
+these devices may cause unexpected behavior.
+
+If users want to provide their own DTB, they can use the ``-dtb`` option.
+These DTBs should have the following requirements:
+
+* The /cpus node should contain at least one subnode for E51 and the number
+ of subnodes should match QEMU's ``-smp`` option
+* The /memory reg size should match QEMU’s selected ram_size via ``-m``
+* Should contain a node for the CLINT device with a compatible string
+ "riscv,clint0" if using with OpenSBI BIOS images
Boot options
@@ -122,6 +131,32 @@ To boot the newly built Linux kernel in QEMU with the
``sifive_u`` machine:
-initrd /path/to/rootfs.ext4 \
-append "root=/dev/ram"
+Alternatively, we can use a custom DTB to boot the machine by inserting a CLINT
+node in fu540-c000.dtsi in the Linux kernel,
+
+.. code-block:: none
+
+clint: clint@200 {
+compatible = "riscv,clint0";
+interrupts-extended = <&cpu0_intc 3 &cpu0_intc 7
+ &cpu1_intc 3 &cpu1_intc 7
+ &cpu2_intc 3 &cpu2_intc 7
+ &cpu3_intc 3 &cpu3_intc 7
+ &cpu4_intc 3 &cpu4_intc 7>;
+reg = <0x00 0x200 0x00 0x1>;
+};
+
+with the following command line options:
+
+.. code-block:: bash
+
+ $ qemu-system-riscv64 -M sifive_u -smp 5 -m 8G \
+ -display none -serial stdio \
+ -kernel arch/riscv/boot/Image \
+ -dtb arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dtb \
+ -initrd /path/to/rootfs.ext4 \
+ -append "root=/dev/ram"
+
To build a Linux mainline kernel that can be booted by the ``sifive_u`` machine
in 32-bit mode, use the rv32_defconfig configuration. A patch is required to
fix the 32-bit boot issue for Linux kernel v5.10.
--
2.25.1
[PATCH v2 7/8] hw/riscv: Use macros for BIOS image names
From: Bin Meng
The OpenSBI BIOS image names are used by many RISC-V machines.
Let's define macros for them.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
(no changes since v1)
include/hw/riscv/boot.h | 5 +
hw/riscv/sifive_u.c | 6 ++
hw/riscv/spike.c| 6 ++
hw/riscv/virt.c | 6 ++
4 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/include/hw/riscv/boot.h b/include/hw/riscv/boot.h
index 11a21dd584..0e89400b09 100644
--- a/include/hw/riscv/boot.h
+++ b/include/hw/riscv/boot.h
@@ -24,6 +24,11 @@
#include "hw/loader.h"
#include "hw/riscv/riscv_hart.h"
+#define RISCV32_BIOS_BIN"opensbi-riscv32-generic-fw_dynamic.bin"
+#define RISCV32_BIOS_ELF"opensbi-riscv32-generic-fw_dynamic.elf"
+#define RISCV64_BIOS_BIN"opensbi-riscv64-generic-fw_dynamic.bin"
+#define RISCV64_BIOS_ELF"opensbi-riscv64-generic-fw_dynamic.elf"
+
bool riscv_is_32bit(RISCVHartArrayState *harts);
target_ulong riscv_calc_kernel_start_addr(RISCVHartArrayState *harts,
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index b55e56890c..f30cc8004b 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -561,12 +561,10 @@ static void sifive_u_machine_init(MachineState *machine)
if (riscv_is_32bit(&s->soc.u_cpus)) {
firmware_end_addr = riscv_find_and_load_firmware(machine,
-"opensbi-riscv32-generic-fw_dynamic.bin",
-start_addr, NULL);
+RISCV32_BIOS_BIN, start_addr, NULL);
} else {
firmware_end_addr = riscv_find_and_load_firmware(machine,
-"opensbi-riscv64-generic-fw_dynamic.bin",
-start_addr, NULL);
+RISCV64_BIOS_BIN, start_addr, NULL);
}
if (machine->kernel_filename) {
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index f094bb2158..98932fba62 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -259,13 +259,11 @@ static void spike_board_init(MachineState *machine)
*/
if (riscv_is_32bit(&s->soc[0])) {
firmware_end_addr = riscv_find_and_load_firmware(machine,
-"opensbi-riscv32-generic-fw_dynamic.elf",
-memmap[SPIKE_DRAM].base,
+RISCV32_BIOS_ELF, memmap[SPIKE_DRAM].base,
htif_symbol_callback);
} else {
firmware_end_addr = riscv_find_and_load_firmware(machine,
-"opensbi-riscv64-generic-fw_dynamic.elf",
-memmap[SPIKE_DRAM].base,
+RISCV64_BIOS_ELF, memmap[SPIKE_DRAM].base,
htif_symbol_callback);
}
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 8a8ff04dab..b03c5f8b5b 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -682,12 +682,10 @@ static void virt_machine_init(MachineState *machine)
if (riscv_is_32bit(&s->soc[0])) {
firmware_end_addr = riscv_find_and_load_firmware(machine,
-"opensbi-riscv32-generic-fw_dynamic.bin",
-start_addr, NULL);
+RISCV32_BIOS_BIN, start_addr, NULL);
} else {
firmware_end_addr = riscv_find_and_load_firmware(machine,
-"opensbi-riscv64-generic-fw_dynamic.bin",
-start_addr, NULL);
+RISCV64_BIOS_BIN, start_addr, NULL);
}
if (machine->kernel_filename) {
--
2.25.1
[PATCH v2 3/8] hw/riscv: Support the official CLINT DT bindings
From: Bin Meng
Linux kernel commit a2770b57d083 ("dt-bindings: timer: Add CLINT bindings")
adds the official DT bindings for CLINT, which uses "sifive,clint0"
as the compatible string. "riscv,clint0" is now legacy and has to
be kept for backward compatibility of legacy systems.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v2:
- use "static const char * const" for clint_compat
hw/riscv/sifive_u.c | 6 +-
hw/riscv/spike.c| 6 +-
hw/riscv/virt.c | 6 +-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index 1b8af0c07a..fd5cf7513b 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -99,6 +99,9 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry
*memmap,
uint32_t plic_phandle, prci_phandle, gpio_phandle, phandle = 1;
uint32_t hfclk_phandle, rtcclk_phandle, phy_phandle;
static const char * const ethclk_names[2] = { "pclk", "hclk" };
+static const char * const clint_compat[2] = {
+"sifive,clint0", "riscv,clint0"
+};
if (ms->dtb) {
fdt = s->fdt = load_device_tree(ms->dtb, &s->fdt_size);
@@ -210,7 +213,8 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry
*memmap,
nodename = g_strdup_printf("/soc/clint@%lx",
(long)memmap[SIFIVE_U_DEV_CLINT].base);
qemu_fdt_add_subnode(fdt, nodename);
-qemu_fdt_setprop_string(fdt, nodename, "compatible", "riscv,clint0");
+qemu_fdt_setprop_string_array(fdt, nodename, "compatible",
+(char **)&clint_compat, ARRAY_SIZE(clint_compat));
qemu_fdt_setprop_cells(fdt, nodename, "reg",
0x0, memmap[SIFIVE_U_DEV_CLINT].base,
0x0, memmap[SIFIVE_U_DEV_CLINT].size);
diff --git a/hw/riscv/spike.c b/hw/riscv/spike.c
index ec7cb2f707..f094bb2158 100644
--- a/hw/riscv/spike.c
+++ b/hw/riscv/spike.c
@@ -60,6 +60,9 @@ static void create_fdt(SpikeState *s, const MemMapEntry
*memmap,
uint32_t cpu_phandle, intc_phandle, phandle = 1;
char *name, *mem_name, *clint_name, *clust_name;
char *core_name, *cpu_name, *intc_name;
+static const char * const clint_compat[2] = {
+"sifive,clint0", "riscv,clint0"
+};
fdt = s->fdt = create_device_tree(&s->fdt_size);
if (!fdt) {
@@ -153,7 +156,8 @@ static void create_fdt(SpikeState *s, const MemMapEntry
*memmap,
(memmap[SPIKE_CLINT].size * socket);
clint_name = g_strdup_printf("/soc/clint@%lx", clint_addr);
qemu_fdt_add_subnode(fdt, clint_name);
-qemu_fdt_setprop_string(fdt, clint_name, "compatible", "riscv,clint0");
+qemu_fdt_setprop_string_array(fdt, clint_name, "compatible",
+(char **)&clint_compat, ARRAY_SIZE(clint_compat));
qemu_fdt_setprop_cells(fdt, clint_name, "reg",
0x0, clint_addr, 0x0, memmap[SPIKE_CLINT].size);
qemu_fdt_setprop(fdt, clint_name, "interrupts-extended",
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 992f1c58a9..4b32dc734f 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -195,6 +195,9 @@ static void create_fdt(RISCVVirtState *s, const MemMapEntry
*memmap,
char *name, *clint_name, *plic_name, *clust_name;
hwaddr flashsize = virt_memmap[VIRT_FLASH].size / 2;
hwaddr flashbase = virt_memmap[VIRT_FLASH].base;
+static const char * const clint_compat[2] = {
+"sifive,clint0", "riscv,clint0"
+};
if (mc->dtb) {
fdt = mc->fdt = load_device_tree(mc->dtb, &s->fdt_size);
@@ -300,7 +303,8 @@ static void create_fdt(RISCVVirtState *s, const MemMapEntry
*memmap,
(memmap[VIRT_CLINT].size * socket);
clint_name = g_strdup_printf("/soc/clint@%lx", clint_addr);
qemu_fdt_add_subnode(fdt, clint_name);
-qemu_fdt_setprop_string(fdt, clint_name, "compatible", "riscv,clint0");
+qemu_fdt_setprop_string_array(fdt, clint_name, "compatible",
+(char **)&clint_compat, ARRAY_SIZE(clint_compat));
qemu_fdt_setprop_cells(fdt, clint_name, "reg",
0x0, clint_addr, 0x0, memmap[VIRT_CLINT].size);
qemu_fdt_setprop(fdt, clint_name, "interrupts-extended",
--
2.25.1
[PATCH v2 4/8] hw/riscv: Support the official PLIC DT bindings
From: Bin Meng
The official DT bindings of PLIC uses "sifive,plic-1.0.0" as the
compatible string in the upstream Linux kernel. "riscv,plic0" is
now legacy and has to be kept for backward compatibility of legacy
systems.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
Changes in v2:
- use "static const char * const" for plic_compat
hw/riscv/sifive_u.c | 6 +-
hw/riscv/virt.c | 6 +-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/hw/riscv/sifive_u.c b/hw/riscv/sifive_u.c
index fd5cf7513b..b55e56890c 100644
--- a/hw/riscv/sifive_u.c
+++ b/hw/riscv/sifive_u.c
@@ -102,6 +102,9 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry
*memmap,
static const char * const clint_compat[2] = {
"sifive,clint0", "riscv,clint0"
};
+static const char * const plic_compat[2] = {
+"sifive,plic-1.0.0", "riscv,plic0"
+};
if (ms->dtb) {
fdt = s->fdt = load_device_tree(ms->dtb, &s->fdt_size);
@@ -271,7 +274,8 @@ static void create_fdt(SiFiveUState *s, const MemMapEntry
*memmap,
(long)memmap[SIFIVE_U_DEV_PLIC].base);
qemu_fdt_add_subnode(fdt, nodename);
qemu_fdt_setprop_cell(fdt, nodename, "#interrupt-cells", 1);
-qemu_fdt_setprop_string(fdt, nodename, "compatible", "riscv,plic0");
+qemu_fdt_setprop_string_array(fdt, nodename, "compatible",
+(char **)&plic_compat, ARRAY_SIZE(plic_compat));
qemu_fdt_setprop(fdt, nodename, "interrupt-controller", NULL, 0);
qemu_fdt_setprop(fdt, nodename, "interrupts-extended",
cells, (ms->smp.cpus * 4 - 2) * sizeof(uint32_t));
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 4b32dc734f..8a8ff04dab 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -198,6 +198,9 @@ static void create_fdt(RISCVVirtState *s, const MemMapEntry
*memmap,
static const char * const clint_compat[2] = {
"sifive,clint0", "riscv,clint0"
};
+static const char * const plic_compat[2] = {
+"sifive,plic-1.0.0", "riscv,plic0"
+};
if (mc->dtb) {
fdt = mc->fdt = load_device_tree(mc->dtb, &s->fdt_size);
@@ -320,7 +323,8 @@ static void create_fdt(RISCVVirtState *s, const MemMapEntry
*memmap,
"#address-cells", FDT_PLIC_ADDR_CELLS);
qemu_fdt_setprop_cell(fdt, plic_name,
"#interrupt-cells", FDT_PLIC_INT_CELLS);
-qemu_fdt_setprop_string(fdt, plic_name, "compatible", "riscv,plic0");
+qemu_fdt_setprop_string_array(fdt, plic_name, "compatible",
+(char **)&plic_compat, ARRAY_SIZE(plic_compat));
qemu_fdt_setprop(fdt, plic_name, "interrupt-controller", NULL, 0);
qemu_fdt_setprop(fdt, plic_name, "interrupts-extended",
plic_cells, s->soc[socket].num_harts * sizeof(uint32_t) * 4);
--
2.25.1
[PATCH v2 8/8] hw/riscv: microchip_pfsoc: Support direct kernel boot
From: Bin Meng
At present the Microchip Icicle Kit machine only supports using
'-bios' to load the HSS, and does not support '-kernel' for direct
kernel booting just like other RISC-V machines do. One has to use
U-Boot which is chain-loaded by HSS, to load a kernel for testing.
This is not so convenient.
Adding '-kernel' support together with the existing '-bios', we
follow the following table to select which payload we execute:
-bios |-kernel | payload
--++
N | N | HSS
Y | don't care | HSS
N | Y | kernel
This ensures backwards compatibility with how we used to expose
'-bios' to users. When '-kernel' is used for direct boot, '-dtb'
must be present to provide a valid device tree for the board,
as we don't generate device tree.
When direct kernel boot is used, the OpenSBI fw_dynamic BIOS image
is used to boot a payload like U-Boot or OS kernel directly.
Documentation is updated to describe the direct kernel boot. Note
as of today there is still no PolarFire SoC support in the upstream
Linux kernel hence the document does not include instructions for
that. It will be updated in the future.
Signed-off-by: Bin Meng
Reviewed-by: Alistair Francis
---
(no changes since v1)
docs/system/riscv/microchip-icicle-kit.rst | 30 ++--
hw/riscv/microchip_pfsoc.c | 81 +-
2 files changed, 103 insertions(+), 8 deletions(-)
diff --git a/docs/system/riscv/microchip-icicle-kit.rst
b/docs/system/riscv/microchip-icicle-kit.rst
index e803131763..54ced661e3 100644
--- a/docs/system/riscv/microchip-icicle-kit.rst
+++ b/docs/system/riscv/microchip-icicle-kit.rst
@@ -31,17 +31,37 @@ Boot options
The ``microchip-icicle-kit`` machine can start using the standard -bios
functionality for loading its BIOS image, aka Hart Software Services (HSS_).
-HSS loads the second stage bootloader U-Boot from an SD card. It does not
-support direct kernel loading via the -kernel option. One has to load kernel
-from U-Boot.
+HSS loads the second stage bootloader U-Boot from an SD card. Then a kernel
+can be loaded from U-Boot. It also supports direct kernel booting via the
+-kernel option along with the device tree blob via -dtb. When direct kernel
+boot is used, the OpenSBI fw_dynamic BIOS image is used to boot a payload
+like U-Boot or OS kernel directly.
+
+The user provided DTB should have the following requirements:
+
+* The /cpus node should contain at least one subnode for E51 and the number
+ of subnodes should match QEMU's ``-smp`` option
+* The /memory reg size should match QEMU’s selected ram_size via ``-m``
+* Should contain a node for the CLINT device with a compatible string
+ "riscv,clint0"
+
+QEMU follows below truth table to select which payload to execute:
+
+= == ===
+-bios -kernel payload
+= == ===
+N N HSS
+Y don't care HSS
+N Y kernel
+= == ===
The memory is set to 1537 MiB by default which is the minimum required high
memory size by HSS. A sanity check on ram size is performed in the machine
init routine to prompt user to increase the RAM size to > 1537 MiB when less
than 1537 MiB ram is detected.
-Boot the machine
-
+Running HSS
+---
HSS 2020.12 release is tested at the time of writing. To build an HSS image
that can be booted by the ``microchip-icicle-kit`` machine, type the following
diff --git a/hw/riscv/microchip_pfsoc.c b/hw/riscv/microchip_pfsoc.c
index c4146b7a6b..1919c09f2f 100644
--- a/hw/riscv/microchip_pfsoc.c
+++ b/hw/riscv/microchip_pfsoc.c
@@ -53,6 +53,7 @@
#include "hw/riscv/microchip_pfsoc.h"
#include "hw/intc/sifive_clint.h"
#include "hw/intc/sifive_plic.h"
+#include "sysemu/device_tree.h"
#include "sysemu/sysemu.h"
/*
@@ -462,6 +463,12 @@ static void microchip_icicle_kit_machine_init(MachineState
*machine)
MemoryRegion *mem_high = g_new(MemoryRegion, 1);
MemoryRegion *mem_high_alias = g_new(MemoryRegion, 1);
uint64_t mem_high_size;
+hwaddr firmware_load_addr;
+const char *firmware_name;
+bool kernel_as_payload = false;
+target_ulong firmware_end_addr, kernel_start_addr;
+uint64_t kernel_entry;
+uint32_t fdt_load_addr;
DriveInfo *dinfo = drive_get_next(IF_SD);
/* Sanity check on RAM size */
@@ -506,9 +513,6 @@ static void microchip_icicle_kit_machine_init(MachineState
*machine)
memmap[MICROCHIP_PFSOC_DRAM_HI_ALIAS].base,
mem_high_alias);
-/* Load the firmware */
-riscv_find_and_load_firmware(machine, BIOS_FILENAME, RESET_VECTOR, NULL);
-
/* Attach an SD card */
if (dinfo) {
CadenceSDHCIState *sdhci = &(s->soc.sdhci);
@@ -518,6 +522,77 @@ static void microchip_icicle_kit_machine_init(MachineState
*machine)
&error_fatal);
qdev_realize_and_unref(card, sdhci->bus, &e
[PATCH v2 5/8] docs/system/riscv: Correct the indentation level of supported devices
From: Bin Meng The supported device bullet list has an additional space before each entry, which makes a wrong indentation level. Correct it. Signed-off-by: Bin Meng --- (no changes since v1) docs/system/riscv/microchip-icicle-kit.rst | 20 +++ docs/system/riscv/sifive_u.rst | 30 +++--- 2 files changed, 25 insertions(+), 25 deletions(-) diff --git a/docs/system/riscv/microchip-icicle-kit.rst b/docs/system/riscv/microchip-icicle-kit.rst index 4fe97bce3f..e803131763 100644 --- a/docs/system/riscv/microchip-icicle-kit.rst +++ b/docs/system/riscv/microchip-icicle-kit.rst @@ -15,16 +15,16 @@ Supported devices The ``microchip-icicle-kit`` machine supports the following devices: - * 1 E51 core - * 4 U54 cores - * Core Level Interruptor (CLINT) - * Platform-Level Interrupt Controller (PLIC) - * L2 Loosely Integrated Memory (L2-LIM) - * DDR memory controller - * 5 MMUARTs - * 1 DMA controller - * 2 GEM Ethernet controllers - * 1 SDHC storage controller +* 1 E51 core +* 4 U54 cores +* Core Level Interruptor (CLINT) +* Platform-Level Interrupt Controller (PLIC) +* L2 Loosely Integrated Memory (L2-LIM) +* DDR memory controller +* 5 MMUARTs +* 1 DMA controller +* 2 GEM Ethernet controllers +* 1 SDHC storage controller Boot options diff --git a/docs/system/riscv/sifive_u.rst b/docs/system/riscv/sifive_u.rst index 98e7562848..dcdfbda931 100644 --- a/docs/system/riscv/sifive_u.rst +++ b/docs/system/riscv/sifive_u.rst @@ -9,21 +9,21 @@ Supported devices The ``sifive_u`` machine supports the following devices: - * 1 E51 / E31 core - * Up to 4 U54 / U34 cores - * Core Level Interruptor (CLINT) - * Platform-Level Interrupt Controller (PLIC) - * Power, Reset, Clock, Interrupt (PRCI) - * L2 Loosely Integrated Memory (L2-LIM) - * DDR memory controller - * 2 UARTs - * 1 GEM Ethernet controller - * 1 GPIO controller - * 1 One-Time Programmable (OTP) memory with stored serial number - * 1 DMA controller - * 2 QSPI controllers - * 1 ISSI 25WP256 flash - * 1 SD card in SPI mode +* 1 E51 / E31 core +* Up to 4 U54 / U34 cores +* Core Level Interruptor (CLINT) +* Platform-Level Interrupt Controller (PLIC) +* Power, Reset, Clock, Interrupt (PRCI) +* L2 Loosely Integrated Memory (L2-LIM) +* DDR memory controller +* 2 UARTs +* 1 GEM Ethernet controller +* 1 GPIO controller +* 1 One-Time Programmable (OTP) memory with stored serial number +* 1 DMA controller +* 2 QSPI controllers +* 1 ISSI 25WP256 flash +* 1 SD card in SPI mode Please note the real world HiFive Unleashed board has a fixed configuration of 1 E51 core and 4 U54 core combination and the RISC-V core boots in 64-bit mode. -- 2.25.1
Re: [PATCH 1/2] ui/cocoa: capture all keys and combos when mouse is grabbed
gust...@noronha.eti.br writes:
> From: Gustavo Noronha Silva
>
> Applications such as Gnome may use Alt-Tab and Super-Tab for different
> purposes, some use Ctrl-arrows so we want to allow qemu to handle
> everything when it captures the mouse/keyboard.
>
> However, Mac OS handles some combos like Command-Tab and Ctrl-arrows
> at an earlier part of the event handling chain, not letting qemu see it.
>
> We add a global Event Tap that allows qemu to see all events when the
> mouse is grabbed. Note that this requires additional permissions.
>
> See:
>
> https://developer.apple.com/documentation/coregraphics/1454426-cgeventtapcreate?language=objc#discussion
> https://support.apple.com/en-in/guide/mac-help/mh32356/mac
>
> Signed-off-by: Gustavo Noronha Silva
> ---
> qapi/ui.json| 15 ++
> qemu-options.hx | 3 ++
> ui/cocoa.m | 73 +++--
> 3 files changed, 89 insertions(+), 2 deletions(-)
>
> diff --git a/qapi/ui.json b/qapi/ui.json
> index 1052ca9c38..77bc00fd0d 100644
> --- a/qapi/ui.json
> +++ b/qapi/ui.json
> @@ -1088,6 +1088,20 @@
> { 'struct' : 'DisplayCurses',
>'data': { '*charset' : 'str' } }
>
> +##
> +# @DisplayCocoa:
> +#
> +# Cocoa display options.
> +#
> +# @full-grab: Capture all key presses, including system combos. This
> +# requires accessibility permissions, since it performs
> +# a global grab on key events. (default: off)
> +# See
> https://support.apple.com/en-in/guide/mac-help/mh32356/mac
Please indent like this
# @full-grab: Capture all key presses, including system combos. This
# requires accessibility permissions, since it performs
# a global grab on key events. (default: off)
# See https://support.apple.com/en-in/guide/mac-help/mh32356/mac
I hope the link is permanent.
> +#
> +##
> +{ 'struct' : 'DisplayCocoa',
> + 'data': { '*full-grab' : 'bool' } }
> +
> ##
> # @DisplayType:
> #
> @@ -1153,6 +1167,7 @@
> '*gl': 'DisplayGLMode' },
>'discriminator' : 'type',
>'data': { 'gtk': 'DisplayGTK',
> +'cocoa' : 'DisplayCocoa',
> 'curses' : 'DisplayCurses',
> 'egl-headless' : 'DisplayEGLHeadless'} }
>
With indentation tidied up, QAPI schema
Acked-by: Markus Armbruster
[Bug 1813201] Re: QEMU TCG i386 / x86_64 system emulation crash when executing int instruction
** 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/1813201
Title:
QEMU TCG i386 / x86_64 system emulation crash when executing int
instruction
Status in QEMU:
Fix Released
Bug description:
QEMU version:
-
qemu from git, master branch commit
d058a37a6e8daa8d71a6f2b613eb415b69363755
Release versions are also affected.
Summary:
QEMU i386 and x86_64 system emulation crash when executing the
following "int" instruction:
cd08 int 8
This generates a kernel NULL pointer dereference error in Linux, and a
BSOD error in Windows.
No special permissions are required to execute the instruction, any
unprivileged user can execute it.
This issue has been reproduced in QEMU running in TCG mode. KVM is not
affected.
Kernel panic log:
[ 111.091138] BUG: unable to handle kernel NULL pointer dereference at
0014
[ 111.092145] IP: [] doublefault_fn+0xd/0x130
[ 111.092145] *pdpt = *pde = f000ff53f000ff53 [
111.092145]
[ 111.092145] Oops: [#1] SMP
[ 111.092145] Modules linked in: kvm_amd bochs_drm ppdev ttm drm_kms_helper
drm kvm irqbypass evdev pcspkr serio_raw sg parport_pc parport button ip_tables
x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb xts lrw gf128mul
ablk_helper cryptd aes_i586 mbcache sr_mod sd_mod cdrom ata_generic ata_piix
libata psmouse e1000 scsi_mod i2c_piix4 floppy
[ 111.092145] CPU: 0 PID: 409 Comm: int8.elf Not tainted 4.9.0-8-686-pae #1
Debian 4.9.130-2
[ 111.092145] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
[ 111.092145] task: f6c88a80 task.stack: f6e52000
[ 111.092145] EIP: 0060:[] EFLAGS: 4086 CPU: 0
[ 111.092145] EIP is at doublefault_fn+0xd/0x130
[ 111.092145] EAX: EBX: ECX: EDX:
[ 111.092145] ESI: EDI: EBP: ce8f13fc ESP: ce8f13d4
[ 111.092145] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 111.092145] CR0: 8005003b CR2: 0014 CR3: 0e8e1000 CR4: 06f0
[ 111.092145] Stack:
[ 111.092145]
[ 111.092145]
[ 111.092145] fed0 ce474ad0
00017d78
[ 111.092145] Call Trace:
[ 111.092145] Code: 86 fd ff eb a3 89 f6 8d bc 27 00 00 00 00 55 89 e5 3e 8d
74 26 00 5d e9 e2 79 fd ff 66 90 55 89 e5 56 53 83 ec 20 3e 8d 74 26 00 <65> a1
14 00 00 00 89 45 f4 31 c0 31 c0 c7 45 f0 00 00 00 00 66
[ 111.092145] EIP: [] [ 111.092145] doublefault_fn+0xd/0x130
[ 111.092145] SS:ESP 0068:ce8f13d4
[ 111.092145] CR2: 0014
[ 111.092145] ---[ end trace 8afa7884b76cafc1 ]---
Testcase:
-
void main() {
asm("int $0x8");
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1813201/+subscriptions
Re: [PATCH 2/2] ui/cocoa: add option to swap Option and Command, enable by default
gust...@noronha.eti.br writes:
> From: Gustavo Noronha Silva
>
> On Mac OS X the Option key maps to Alt and Command to Super/Meta. This change
> swaps them around so that Alt is the key closer to the space bar and
> Meta/Super
> is between Control and Alt, like on non-Mac keyboards.
>
> It is a cocoa display option, enabled by default.
>
> Signed-off-by: Gustavo Noronha Silva
> ---
> qapi/ui.json| 7 +-
> qemu-options.hx | 1 +
> ui/cocoa.m | 66 +
> 3 files changed, 63 insertions(+), 11 deletions(-)
>
> diff --git a/qapi/ui.json b/qapi/ui.json
> index 77bc00fd0d..02db684251 100644
> --- a/qapi/ui.json
> +++ b/qapi/ui.json
> @@ -1098,9 +1098,14 @@
##
# @DisplayCocoa:
#
# Cocoa display options.
#
# @full-grab: Capture all key presses, including system combos. This
# requires accessibility permissions, since it performs
> # a global grab on key events. (default: off)
> # See
> https://support.apple.com/en-in/guide/mac-help/mh32356/mac
> #
> +# @swap-option-command: Swaps the Option and Command keys so that their key
> codes
Please use imperative mood consistently: "Swap", like "Capture" above.
> +# match their position on non-Mac keyboards and you
> can use
> +# Meta/Super and Alt where you expect them. (default:
> on)
> +#
Drop the blank comment line, and break your lines a bit earlier.
> ##
Like this:
##
# @DisplayCocoa:
#
# Cocoa display options.
#
# @full-grab: Capture all key presses, including system combos. This
# requires accessibility permissions, since it performs
# a global grab on key events. (default: off)
# See
https://support.apple.com/en-in/guide/mac-help/mh32356/mac
#
# @swap-option-command: Swap the Option and Command keys so that their key
# codes match their position on non-Mac keyboards and
# you can use Meta/Super and Alt where you expect
# them. (default: on)
##
> { 'struct' : 'DisplayCocoa',
> - 'data': { '*full-grab' : 'bool' } }
> + 'data': { '*full-grab' : 'bool',
> +'*swap-option-command' : 'bool' } }
>
> ##
> # @DisplayType:
With the doc comment tidied up, QAPI schema
Acked-by: Markus Armbruster
[Bug 1904954] Re: lan9118 bug peeked received message size not equal to actual received message size
** 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/1904954 Title: lan9118 bug peeked received message size not equal to actual received message size Status in QEMU: Fix Released Bug description: peeked message size is not equal to read message size Bug in the code at line: https://github.com/qemu/qemu/blob/master/hw/net/lan9118.c#L1209 s->tx_status_fifo_head should be s->rx_status_fifo_head Could also be a security bug, as the user could allocate a buffer of size peeked data smaller than the actual packet received, which could cause a buffer overflow. Thanks, Alfred To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1904954/+subscriptions
Re: [PATCH v4 0/3] nvdimm: Enable sync-dax property for nvdimm
On Thu, Apr 29, 2021 at 10:02:23PM +0530, Aneesh Kumar K.V wrote: > On 4/29/21 9:25 PM, Stefan Hajnoczi wrote: > > On Wed, Apr 28, 2021 at 11:48:21PM -0400, Shivaprasad G Bhat wrote: > > > The nvdimm devices are expected to ensure write persistence during power > > > failure kind of scenarios. > > > > > > The libpmem has architecture specific instructions like dcbf on POWER > > > to flush the cache data to backend nvdimm device during normal writes > > > followed by explicit flushes if the backend devices are not synchronous > > > DAX capable. > > > > > > Qemu - virtual nvdimm devices are memory mapped. The dcbf in the guest > > > and the subsequent flush doesn't traslate to actual flush to the backend > > > file on the host in case of file backed v-nvdimms. This is addressed by > > > virtio-pmem in case of x86_64 by making explicit flushes translating to > > > fsync at qemu. > > > > > > On SPAPR, the issue is addressed by adding a new hcall to > > > request for an explicit flush from the guest ndctl driver when the backend > > > nvdimm cannot ensure write persistence with dcbf alone. So, the approach > > > here is to convey when the hcall flush is required in a device tree > > > property. The guest makes the hcall when the property is found, instead > > > of relying on dcbf. > > > > Sorry, I'm not very familiar with SPAPR. Why add a hypercall when the > > virtio-nvdimm device already exists? > > > > On virtualized ppc64 platforms, guests use papr_scm.ko kernel drive for > persistent memory support. This was done such that we can use one kernel > driver to support persistent memory with multiple hypervisors. To avoid > supporting multiple drivers in the guest, -device nvdimm Qemu command-line > results in Qemu using PAPR SCM backend. What this patch series does is to > make sure we expose the correct synchronous fault support, when we back such > nvdimm device with a file. > > The existing PAPR SCM backend enables persistent memory support with the > help of multiple hypercall. > > #define H_SCM_READ_METADATA 0x3E4 > #define H_SCM_WRITE_METADATA0x3E8 > #define H_SCM_BIND_MEM 0x3EC > #define H_SCM_UNBIND_MEM0x3F0 > #define H_SCM_UNBIND_ALL0x3FC > > Most of them are already implemented in Qemu. This patch series implements > H_SCM_FLUSH hypercall. The overall point here is that we didn't define the hypercall. It was defined in order to support NVDIMM/pmem devices under PowerVM. For uniformity between PowerVM and KVM guests, we want to support the same hypercall interface on KVM/qemu as well. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH v2 1/7] target/ppc: move opcode table logic to translate.c
On Thu, Apr 29, 2021 at 01:21:24PM -0300, Bruno Larsen (billionai) wrote:
65;6203;1c> code motion to remove opcode callback table from
> translate_init.c.inc to translate.c in preparation to remove
> the #include from translate.c. Also created
> destroy_ppc_opcodes and removed that logic from ppc_cpu_unrealize
>
> Signed-off-by: Bruno Larsen (billionai)
>
Applied to ppc-for-6.1, thanks.
> ---
> target/ppc/internal.h | 8 +
> target/ppc/translate.c | 394
> target/ppc/translate_init.c.inc | 391 +--
> 3 files changed, 403 insertions(+), 390 deletions(-)
>
> diff --git a/target/ppc/internal.h b/target/ppc/internal.h
> index c401658e8d..184ba6d6b3 100644
> --- a/target/ppc/internal.h
> +++ b/target/ppc/internal.h
> @@ -216,6 +216,14 @@ void ppc_cpu_do_unaligned_access(CPUState *cs, vaddr
> addr,
> MMUAccessType access_type,
> int mmu_idx, uintptr_t retaddr);
>
> +/* translate.c */
> +
> +/* #define PPC_DUMP_CPU */
> +
> +int ppc_fixup_cpu(PowerPCCPU *cpu);
> +void create_ppc_opcodes(PowerPCCPU *cpu, Error **errp);
> +void destroy_ppc_opcodes(PowerPCCPU *cpu);
> +
> /* gdbstub.c */
> void ppc_gdb_init(CPUState *cs, PowerPCCPUClass *ppc);
> gchar *ppc_gdb_arch_name(CPUState *cs);
> diff --git a/target/ppc/translate.c b/target/ppc/translate.c
> index 0984ce637b..b319d409c6 100644
> --- a/target/ppc/translate.c
> +++ b/target/ppc/translate.c
> @@ -7825,6 +7825,400 @@ void ppc_cpu_dump_state(CPUState *cs, FILE *f, int
> flags)
> #undef RFPL
> }
>
> +/*/
> +/* Opcode types */
> +enum {
> +PPC_DIRECT = 0, /* Opcode routine*/
> +PPC_INDIRECT = 1, /* Indirect opcode table */
> +};
> +
> +#define PPC_OPCODE_MASK 0x3
> +
> +static inline int is_indirect_opcode(void *handler)
> +{
> +return ((uintptr_t)handler & PPC_OPCODE_MASK) == PPC_INDIRECT;
> +}
> +
> +static inline opc_handler_t **ind_table(void *handler)
> +{
> +return (opc_handler_t **)((uintptr_t)handler & ~PPC_OPCODE_MASK);
> +}
> +
> +/* Instruction table creation */
> +/* Opcodes tables creation */
> +static void fill_new_table(opc_handler_t **table, int len)
> +{
> +int i;
> +
> +for (i = 0; i < len; i++) {
> +table[i] = &invalid_handler;
> +}
> +}
> +
> +static int create_new_table(opc_handler_t **table, unsigned char idx)
> +{
> +opc_handler_t **tmp;
> +
> +tmp = g_new(opc_handler_t *, PPC_CPU_INDIRECT_OPCODES_LEN);
> +fill_new_table(tmp, PPC_CPU_INDIRECT_OPCODES_LEN);
> +table[idx] = (opc_handler_t *)((uintptr_t)tmp | PPC_INDIRECT);
> +
> +return 0;
> +}
> +
> +static int insert_in_table(opc_handler_t **table, unsigned char idx,
> +opc_handler_t *handler)
> +{
> +if (table[idx] != &invalid_handler) {
> +return -1;
> +}
> +table[idx] = handler;
> +
> +return 0;
> +}
> +
> +static int register_direct_insn(opc_handler_t **ppc_opcodes,
> +unsigned char idx, opc_handler_t *handler)
> +{
> +if (insert_in_table(ppc_opcodes, idx, handler) < 0) {
> +printf("*** ERROR: opcode %02x already assigned in main "
> + "opcode table\n", idx);
> +#if defined(DO_PPC_STATISTICS) || defined(PPC_DUMP_CPU)
> +printf(" Registered handler '%s' - new handler '%s'\n",
> + ppc_opcodes[idx]->oname, handler->oname);
> +#endif
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +static int register_ind_in_table(opc_handler_t **table,
> + unsigned char idx1, unsigned char idx2,
> + opc_handler_t *handler)
> +{
> +if (table[idx1] == &invalid_handler) {
> +if (create_new_table(table, idx1) < 0) {
> +printf("*** ERROR: unable to create indirect table "
> + "idx=%02x\n", idx1);
> +return -1;
> +}
> +} else {
> +if (!is_indirect_opcode(table[idx1])) {
> +printf("*** ERROR: idx %02x already assigned to a direct "
> + "opcode\n", idx1);
> +#if defined(DO_PPC_STATISTICS) || defined(PPC_DUMP_CPU)
> +printf(" Registered handler '%s' - new handler '%s'\n",
> + ind_table(table[idx1])[idx2]->oname, handler->oname);
> +#endif
> +return -1;
> +}
> +}
> +if (handler != NULL &&
> +insert_in_table(ind_table(table[idx1]), idx2, handler) < 0) {
> +printf("*** ERROR: opcode %02x already assigned in "
> + "opcode table %02x\n", idx2, idx1);
> +#if defined(DO_PPC_STATISTICS) || defined(PPC_DUMP_CPU)
> +printf(" Registered handler '%s' - new handler '%s'\n",
> + ind_table(table[idx1])[idx2]->oname, handler->oname);
> +#endif
> +return -1;
> +}
> +
> +
Re: [PATCH v2 3/7] target/ppc: Isolated SPR read/write callbacks
On Thu, Apr 29, 2021 at 01:21:26PM -0300, Bruno Larsen (billionai) wrote:
> Moved all SPR read/write callback, and some related functions, to a
> new file specific for it. These callbacks are TCG only, so separating
> them is required to support the flag disable-tcg.
>
> Making the spr_noaccess function not static, and moving the define to
> internal.h is required, as spr_tcg.c.inc has to be included after
> SPR_NOACCESS has been used.
>
> Signed-off-by: Bruno Larsen (billionai)
> ---
> target/ppc/internal.h |3 +
> target/ppc/spr_tcg.c.inc| 1033 +++
> target/ppc/translate.c | 49 +-
> target/ppc/translate_init.c.inc | 981 -
> 4 files changed, 1039 insertions(+), 1027 deletions(-)
> create mode 100644 target/ppc/spr_tcg.c.inc
>
> diff --git a/target/ppc/internal.h b/target/ppc/internal.h
> index 184ba6d6b3..1de15acfbd 100644
> --- a/target/ppc/internal.h
> +++ b/target/ppc/internal.h
> @@ -228,4 +228,7 @@ void destroy_ppc_opcodes(PowerPCCPU *cpu);
> void ppc_gdb_init(CPUState *cs, PowerPCCPUClass *ppc);
> gchar *ppc_gdb_arch_name(CPUState *cs);
>
> +void spr_noaccess(DisasContext *ctx, int gprn, int sprn);
> +#define SPR_NOACCESS (&spr_noaccess)
> +
> #endif /* PPC_INTERNAL_H */
> diff --git a/target/ppc/spr_tcg.c.inc b/target/ppc/spr_tcg.c.inc
> new file mode 100644
> index 00..48274dd52b
> --- /dev/null
> +++ b/target/ppc/spr_tcg.c.inc
I'm confused. You create the new file as a .inc.c, but I don't see
anything #including the new file.
> @@ -0,0 +1,1033 @@
> +#include "exec/translator.h"
> +
> +/*/
> +/* Reader and writer functions for SPRs */
> +
> +/* I really see no reason to keep these gen_*_xer */
> +/* instead of just leaving the code in the spr_*_xer */
> +static void gen_read_xer(DisasContext *ctx, TCGv dst)
> +{
> +TCGv t0 = tcg_temp_new();
> +TCGv t1 = tcg_temp_new();
> +TCGv t2 = tcg_temp_new();
> +tcg_gen_mov_tl(dst, cpu_xer);
> +tcg_gen_shli_tl(t0, cpu_so, XER_SO);
> +tcg_gen_shli_tl(t1, cpu_ov, XER_OV);
> +tcg_gen_shli_tl(t2, cpu_ca, XER_CA);
> +tcg_gen_or_tl(t0, t0, t1);
> +tcg_gen_or_tl(dst, dst, t2);
> +tcg_gen_or_tl(dst, dst, t0);
> +if (is_isa300(ctx)) {
> +tcg_gen_shli_tl(t0, cpu_ov32, XER_OV32);
> +tcg_gen_or_tl(dst, dst, t0);
> +tcg_gen_shli_tl(t0, cpu_ca32, XER_CA32);
> +tcg_gen_or_tl(dst, dst, t0);
> +}
> +tcg_temp_free(t0);
> +tcg_temp_free(t1);
> +tcg_temp_free(t2);
> +}
> +
> +static void gen_write_xer(TCGv src)
> +{
> +/* Write all flags, while reading back check for isa300 */
> +tcg_gen_andi_tl(cpu_xer, src,
> +~((1u << XER_SO) |
> + (1u << XER_OV) | (1u << XER_OV32) |
> + (1u << XER_CA) | (1u << XER_CA32)));
> +tcg_gen_extract_tl(cpu_ov32, src, XER_OV32, 1);
> +tcg_gen_extract_tl(cpu_ca32, src, XER_CA32, 1);
> +tcg_gen_extract_tl(cpu_so, src, XER_SO, 1);
> +tcg_gen_extract_tl(cpu_ov, src, XER_OV, 1);
> +tcg_gen_extract_tl(cpu_ca, src, XER_CA, 1);
> +}
> +
> +void spr_noaccess(DisasContext *ctx, int gprn, int sprn)
> +{
> +#if 0
> +sprn = ((sprn >> 5) & 0x1F) | ((sprn & 0x1F) << 5);
> +printf("ERROR: try to access SPR %d !\n", sprn);
> +#endif
> +}
> +
> +/* #define PPC_DUMP_SPR_ACCESSES */
> +
> +/*
> + * Generic callbacks:
> + * do nothing but store/retrieve spr value
> + */
> +static void spr_load_dump_spr(int sprn)
> +{
> +#ifdef PPC_DUMP_SPR_ACCESSES
> +TCGv_i32 t0 = tcg_const_i32(sprn);
> +gen_helper_load_dump_spr(cpu_env, t0);
> +tcg_temp_free_i32(t0);
> +#endif
> +}
> +
> +static void spr_read_generic(DisasContext *ctx, int gprn, int sprn)
> +{
> +gen_load_spr(cpu_gpr[gprn], sprn);
> +spr_load_dump_spr(sprn);
> +}
> +
> +static void spr_store_dump_spr(int sprn)
> +{
> +#ifdef PPC_DUMP_SPR_ACCESSES
> +TCGv_i32 t0 = tcg_const_i32(sprn);
> +gen_helper_store_dump_spr(cpu_env, t0);
> +tcg_temp_free_i32(t0);
> +#endif
> +}
> +
> +static void spr_write_generic(DisasContext *ctx, int sprn, int gprn)
> +{
> +gen_store_spr(sprn, cpu_gpr[gprn]);
> +spr_store_dump_spr(sprn);
> +}
> +
> +#if !defined(CONFIG_USER_ONLY)
> +static void spr_write_generic32(DisasContext *ctx, int sprn, int gprn)
> +{
> +#ifdef TARGET_PPC64
> +TCGv t0 = tcg_temp_new();
> +tcg_gen_ext32u_tl(t0, cpu_gpr[gprn]);
> +gen_store_spr(sprn, t0);
> +tcg_temp_free(t0);
> +spr_store_dump_spr(sprn);
> +#else
> +spr_write_generic(ctx, sprn, gprn);
> +#endif
> +}
> +
> +static void spr_write_clear(DisasContext *ctx, int sprn, int gprn)
> +{
> +TCGv t0 = tcg_temp_new();
> +TCGv t1 = tcg_temp_new();
> +gen_load_spr(t0, sprn);
> +tcg_gen_neg_tl(t1, cpu_gpr[gprn]);
> +tcg_gen_and_tl(t0, t0, t1);
> +gen_store_spr(sprn, t0);
> +tcg_temp_free(t0);
> +tcg_temp
[Bug 1758819] Re: HVF Illegal instruction: 4, High Sierra, v2.12-rc0
Looks like this should have been fixed here: https://gitlab.com/qemu-project/qemu/-/commit/118f2aadbc66aaae4e8d52 ** 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/1758819 Title: HVF Illegal instruction: 4, High Sierra, v2.12-rc0 Status in QEMU: Fix Released Bug description: I've built v2.12.0-rc0 on MacOS using homebrew. I'm running 10.13.3 on a 5,1 Mac Pro with a X5690 processor. When I run 'qemu-system-x86_64 -M accel=hvf', I get a crash "Illegal instruction: 4". To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1758819/+subscriptions
[Bug 1922611] Re: Acceptance Tests: migration fails on sparc target
** 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/1922611
Title:
Acceptance Tests: migration fails on sparc target
Status in QEMU:
Fix Released
Bug description:
QEMU fails migration when using a sparc target.
This cab be verified/reproduced with the
`tests/acceptance/migration.py` test. Running it with:
$ make check-venv
$ ./tests/venv/bin/avocado --show=test run -p qemu_bin=./qemu-system-sparc
tests/acceptance/migration.py:Migration.test_migration_with_tcp_localhost
Right after a QMP `query-migrate` is executed, communication with the
monitor is lost:
>>> {'execute': 'query-migrate'}
<<< {'timestamp': {'seconds': 1617667984, 'microseconds': 330282}, 'event':
'STOP'}
<<< {'return': {'blocked': False, 'status': 'completed', 'setup-time': 0,
'downtime': 1, 'total-time': 15, 'ram': {'total': 135274496,
'postcopy-requests': 0, 'dirty-sync-count': 2, 'multifd-bytes': 0,
'pages-per-second': 0, 'page-size': 4096, 'remaining': 0, 'mbps':
301.22347, 'transferred': 528703, 'duplicate': 33202,
'dirty-pages-rate': 0, 'skipped': 0, 'normal-bytes': 229376, 'normal': 56}}}
>>> {'execute': 'query-migrate'}
Reproduced traceback from:
/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.7/site-packages/avocado/core/test.py:756
Traceback (most recent call last):
File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line
80, in test_migration_with_tcp_localhost
self.do_migrate(dest_uri)
File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line
69, in do_migrate
self.assert_migration(source_vm, dest_vm)
File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line
41, in assert_migration
args=(dst_vm,))
File
"/var/lib/users/cleber/build/qemu/tests/venv/lib64/python3.7/site-packages/avocado/utils/wait.py",
line 34, in wait_for
output = func(*args, **kwargs)
File "/var/lib/users/cleber/build/qemu/tests/acceptance/migration.py", line
31, in migration_finished
return vm.command('query-migrate')['status'] in ('completed', 'failed')
File "/home/cleber/src/qemu/python/qemu/machine.py", line 572, in command
return self._qmp.command(cmd, **qmp_args)
File "/home/cleber/src/qemu/python/qemu/qmp.py", line 284, in command
ret = self.cmd(cmd, kwds)
File "/home/cleber/src/qemu/python/qemu/qmp.py", line 278, in cmd
return self.cmd_obj(qmp_cmd)
File "/home/cleber/src/qemu/python/qemu/qmp.py", line 256, in cmd_obj
self.__sock.sendall(json.dumps(qmp_cmd).encode('utf-8'))
BrokenPipeError: [Errno 32] Broken pipe
The qemu-system-sparc binary outputs:
qemu-system-sparc: warning: nic lance.0 has no peer
qemu-system-sparc: Missing section footer for sysbusespscsi
qemu-system-sparc: load of migration failed: Invalid argument
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1922611/+subscriptions
[Bug 1880518] Re: issue while installing docker inside s390x container
** Changed in: qemu
Status: New => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1880518
Title:
issue while installing docker inside s390x container
Status in QEMU:
Invalid
Bug description:
This is in reference to
https://github.com/multiarch/qemu-user-static/issues/108.
I am facing issue while installing docker inside s390x container under qemu
on Ubuntu 18.04 host running on amd64.
Following are the contents of /proc/sys/fs/binfmt_misc/qemu-s390x on Intel
host after running
docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
enabled
interpreter /usr/bin/qemu-s390x-static
flags: F
offset 0
magic 7f454c46020201020016
mask ff00fffe
I could get docker service up with the following trick.
printf '{"iptables": false,"ip-masq": false,"bridge": "none" }' >
/etc/docker/daemon.json
But even though docker service comes up, images are not getting pulled,
docker pull fails with the following error.
failed to register layer: Error processing tar file(exit status 1):
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1880518/+subscriptions
[Bug 1909418] Re: QEMU: Heap Overflow vulnerability in SDHCI Component
Fixed here: https://gitlab.com/qemu-project/qemu/-/commit/cffb446e8fd19a14e1634c ** 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/1909418 Title: QEMU: Heap Overflow vulnerability in SDHCI Component Status in QEMU: Fix Released Bug description: Hello, i want to report qemu vulnerability in SDHCI component, this is integer overflow bug leads to oob read/write in the heap, that can happens in sdhci_do_adma or sdhci_sdma_transfer_multi_blocks. This is caused when in the middle of unfinished transfer, blksize can change, but the data_count still have the last offset of fifo_buffer from the last transfer. We change blksize to zero, then in the next transfer dma_memory_read/dma_memory_write in the first loop calculate length as blksize-data_count, this leads to integer overflow, because blksize is zero, and data_count can be more than zero. This bug is recorded in CVE-2020-25085, but the fix is not complete and not fix the root cause of the bug. Reproducer: outl 0xcf8 0x80001010 outl 0xcfc 0xd7055dba outl 0xcf8 0x80001003 outl 0xcfc 0x86b1d733 write 0x00 0x1 0x29 write 0x02 0x1 0x10 write 0x08 0x1 0x39 writeb 0xd7055d2b 0x5e writel 0xd7055d2c 0xed7d735 writew 0xd7055d30 0x126e writeb 0xd7055d32 0x84 writel 0xd7055d24 0xd7346e01 writew 0xd7055d28 0x3bd7 writeb 0xd7055d2a 0x1 writeb 0xd7055d05 0x2c writew 0xd7055d06 0x5c4 writeb 0xd7055d0c 0x21 writew 0xd7055d0e 0x846e writel 0xd7055d04 0x26 writew 0xd7055d08 0x0 writeb 0xd7055d0a 0x6d writeb 0xd7055d0c 0x31 clock_step EOF ➜ x86_64-softmmu git:(master) ✗ ./qemu-system-x86_64 -m 4G -nodefaults -trace 'sdhci*' -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 ==410717==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! [I 1609122395.789698] OPENED qemu-system-x86_64: -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive: warning: bogus if=sd is deprecated, use if=none [R +0.037381] outl 0xcf8 0x80001010 [S +0.037436] OK OK [R +0.037470] outl 0xcfc 0xd7055dba [S +0.037510] OK OK [R +0.037531] outl 0xcf8 0x80001003 [S +0.037549] OK OK [R +0.037571] outl 0xcfc 0x86b1d733 [S +0.039830] OK OK [R +0.039882] write 0x00 0x1 0x29 [S +0.040364] OK OK [R +0.040401] write 0x02 0x1 0x10 [S +0.040428] OK OK [R +0.040449] write 0x08 0x1 0x39 [S +0.040472] OK OK [R +0.040491] writeb 0xd7055d2b 0x5e [S +0.040530] OK OK [R +0.040550] writel 0xd7055d2c 0xed7d735 [S +0.040575] OK OK [R +0.040594] writew 0xd7055d30 0x126e [S +0.040620] OK OK [R +0.040638] writeb 0xd7055d32 0x84 [S +0.040658] OK OK [R +0.040676] writel 0xd7055d24 0xd7346e01 [S +0.040697] OK OK [R +0.040715] writew 0xd7055d28 0x3bd7 [S +0.040738] OK OK [R +0.040756] writeb 0xd7055d2a 0x1 [S +0.040779] OK OK [R +0.040797] writeb 0xd7055d05 0x2c [S +0.040819] OK OK [R +0.040840] writew 0xd7055d06 0x5c4 [S +0.040862] OK OK [R +0.040882] writeb 0xd7055d0c 0x21 [S +0.040907] OK OK [R +0.040927] writew 0xd7055d0e 0x846e [S +0.041026] OK OK [R +0.041054] writel 0xd7055d04 0x26 [S +0.041115] OK OK [R +0.041139] writew 0xd7055d08 0x0 = ==410717==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61524180 at pc 0x7fe40cb7457d bp 0x7fffa1a7b800 sp 0x7fffa1a7afa8 WRITE of size 786432 at 0x61524180 thread T0 #0 0x7fe40cb7457c (/lib/x86_64-linux-gnu/libasan.so.5+0x9b57c) #1 0x55f804942120 in flatview_read_continue ../../softmmu/physmem.c:2829 #2 0x55f8049423dd in flatview_read ../../softmmu/physmem.c:2862 #3 0x55f804942581 in address_space_read_full ../../softmmu/physmem.c:2875 #4 0x55f804942800 in address_space_rw ../../softmmu/physmem.c:2903 #5 0x55f8038d6a92 in dma_memory_rw_relaxed /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:88 #6 0x55f8038d6adf in dma_memory_rw /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:127 #7 0x55f8038d6b17 in dma_memory_read /home/n0p/belajar/qemu/source/qemu/include/sysemu/dma.h:145 #8 0x55f8038e47d9 in sdhci_do_adma ../../hw/sd/sdhci.c:807 #9 0x55f8038e6081 in sdhci_data_transfer ../../hw/sd/sdhci.c:905 #10 0x55f8038e694c in sdhci_resume_pending_transfer ../../hw/sd/sdhci.c:962 #11 0x55f8038e9227 in sdhci_write ../../hw/sd/sdhci.c:1118 #12 0x55f804856869 in memory_region_write_accessor ../../softmmu/memory.c:491 #13 0x55f804856cf4 in access_with_adjusted_size ../../softmmu/memory.c:552 #14 0x55f804863f28 in memory_region_dispatch_write ../../softmmu/memory.c:
[Bug 1917085] Re: [OSS-Fuzz] Issue 30588 pcnet: Loopback-related stack-overflow
https://gitlab.com/qemu-project/qemu/-/commit/99ccfaa1edafd79f7a3a0ff7 ** 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/1917085 Title: [OSS-Fuzz] Issue 30588 pcnet: Loopback-related stack-overflow Status in QEMU: Fix Released Bug description: === Reproducer === cat << EOF | ./qemu-system-i386 -display none -machine accel=qtest, -m \ 512M -machine q35 -nodefaults -device pcnet,netdev=net0 -netdev \ user,id=net0 -qtest /dev/null -qtest stdio outl 0xcf8 0x8810 outl 0xcfc 0xc001 outl 0xcf8 0x8804 outw 0xcfc 0x7 outl 0xc011 0xff14ff outl 0xcf8 0x8815 outl 0xcfc 0x outl 0xc015 0x35a inl 0xc012 outw 0xc010 0x6165 outw 0xc010 0x1127 write 0x0 0x1 0x56 write 0x2 0x1 0xff write 0x15 0x1 0xff write 0x16 0x1 0xff write 0x17 0x1 0xff write 0x18 0x1 0xfd write 0x19 0x1 0x59 write 0x1a 0x1 0xfe write 0x1b 0x1 0xff outw 0xc010 0x1db EOF === Stack-trace === ==312573==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd5bb4cec8 (pc 0x55a8f1c9cf36 bp 0x7ffd5bb4d710 sp 0x7ffd5bb4ced0 T0) #0 0x55a8f1c9cf36 in __asan_memcpy (/home/alxndr/Development/qemu/build/qemu-system-i386+0x2baff36) #1 0x55a8f2f54ddf in flatview_do_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:518:12 #2 0x55a8f2f6ec8e in flatview_translate /home/alxndr/Development/qemu/build/../softmmu/physmem.c:568:15 #3 0x55a8f2f6ec8e in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2878:10 #4 0x55a8f2f6ec8e in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18 #5 0x55a8f273036e in pcnet_rmd_load /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:381:9 #6 0x55a8f272e386 in pcnet_rdte_poll /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:896:9 #7 0x55a8f27299d0 in pcnet_receive /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1016:9 #8 0x55a8f27406be in pcnet_transmit /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1253:13 #9 0x55a8f2735b4c in pcnet_poll_timer /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1322:9 #10 0x55a8f273c353 in pcnet_ioport_readl /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1660:5 #11 0x55a8f2727361 in pcnet_ioport_read /home/alxndr/Development/qemu/build/../hw/net/pcnet-pci.c:107:20 #12 0x55a8f309e9f6 in memory_region_read_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:442:11 #13 0x55a8f3070d63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 #14 0x55a8f306f222 in memory_region_dispatch_read1 /home/alxndr/Development/qemu/build/../softmmu/memory.c #15 0x55a8f306f222 in memory_region_dispatch_read /home/alxndr/Development/qemu/build/../softmmu/memory.c:1449:9 #16 0x55a8f2f6d88f in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2839:23 #17 0x55a8f2f6ed1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12 #18 0x55a8f2f6ed1b in address_space_read_full /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2892:18 #19 0x55a8f273036e in pcnet_rmd_load /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:381:9 #20 0x55a8f2729d97 in pcnet_receive /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1028:17 #21 0x55a8f27406be in pcnet_transmit /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1253:13 #22 0x55a8f2735b4c in pcnet_poll_timer /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1322:9 #23 0x55a8f273c353 in pcnet_ioport_readl /home/alxndr/Development/qemu/build/../hw/net/pcnet.c:1660:5 #24 0x55a8f2727361 in pcnet_ioport_read /home/alxndr/Development/qemu/build/../hw/net/pcnet-pci.c:107:20 #25 0x55a8f309e9f6 in memory_region_read_accessor /home/alxndr/Development/qemu/build/../softmmu/memory.c:442:11 #26 0x55a8f3070d63 in access_with_adjusted_size /home/alxndr/Development/qemu/build/../softmmu/memory.c:552:18 #27 0x55a8f306f222 in memory_region_dispatch_read1 /home/alxndr/Development/qemu/build/../softmmu/memory.c #28 0x55a8f306f222 in memory_region_dispatch_read /home/alxndr/Development/qemu/build/../softmmu/memory.c:1449:9 #29 0x55a8f2f6d88f in flatview_read_continue /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2839:23 #30 0x55a8f2f6ed1b in flatview_read /home/alxndr/Development/qemu/build/../softmmu/physmem.c:2879:12 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1917085/+subscriptions
[Bug 1921138] Re: tcg.c:3329: tcg fatal error
https://gitlab.com/qemu-project/qemu/-/commit/10b8eb94c0902b58 ** 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/1921138 Title: tcg.c:3329: tcg fatal error Status in QEMU: Fix Released Bug description: I am currently building my own kernel with bootloader and qemu crashed after I have set an IDT in protected mode and then create a invalid opcode exception with the opcode 0xff. My code is here: https://github.com/Luis- Hebendanz/svm_kernel/blob/qemu_crash/svm_kernel/external/bootloader/src/main.rs#L80 Build instructions are here: https://github.com/Luis- Hebendanz/svm_kernel/tree/qemu_crash A precompiled binary is here: https://cloud.gchq.icu/s/LcjoDWRW2CbxJ5i I executed the following command: qemu-system-x86_64 -smp cores=4 -cdrom target/x86_64-os/debug/bootimage-svm_kernel.iso -serial stdio -display none -m 4G I am running QEMU emulator version 5.1.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1921138/+subscriptions
[Bug 1923861] Re: Hardfault when accessing FPSCR register
https://gitlab.com/qemu-project/qemu/-/commit/330ef14e6e749919c5c https://gitlab.com/qemu-project/qemu/-/commit/1df0878cff267128393 ** 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/1923861 Title: Hardfault when accessing FPSCR register Status in QEMU: Fix Released Bug description: QEMU release version: v6.0.0-rc2 command line: qemu-system-arm -machine mps3-an547 -nographic -kernel .elf -semihosting -semihosting-config enable=on,target=native host operating system: Linux ISCNR90TMR1S 5.4.72-microsoft-standard- WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux guest operating system: none (bare metal) Observation: I am simulating embedded firmware for a Cortex-M55 device, using MPS3-AN547 machine. In the startup code I am accessing the FPSCR core register: unsigned int fpscr =__get_FPSCR(); fpscr = fpscr & (~FPU_FPDSCR_AHP_Msk); __set_FPSCR(fpscr); where the register access functions __get_FPSCR() and __set_FPSCR(fpscr) are taken from CMSIS_5 at ./CMSIS/Core/include/cmsis_gcc.h I observe hardfaults upon __get_FPSCR() and __set_FPSCR(fpscr). The same startup code works fine on the Arm Corstone-300 FVP (MPS3-AN547). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1923861/+subscriptions
Re: [PATCH] virtio-blk: drop deprecated scsi=on|off property
Eduardo Habkost writes: > On Thu, Apr 29, 2021 at 04:52:21PM +0100, Stefan Hajnoczi wrote: >> The scsi=on|off property was deprecated in QEMU 5.0 and can be removed >> completely at this point. >> >> Drop the scsi=on|off option. It was only available on Legacy virtio-blk >> devices. Linux v5.6 already dropped support for it. >> >> Remove the hw_compat_2_4[] property assignment since scsi=on|off no >> longer exists. Old guests with Legacy virtio-blk devices no longer see >> the SCSI host features bit. >> > > This means pc-2.4 will now break guest ABI if using virtio-blk > devices, correct? > > This looks like a sign we should have deprecated pc-2.4 a long > time ago. The last batch of PC machine type retiring was pc-1.0 to pc-1.3: deprecated in 5.0 (commit 30d2a17b4, Dec 2019), dropped in 6.0 (commit f862ddbb1, just weeks ago). pc-1.3 was a bit over seven years old when we released 5.0. pc-2.4 will be six years old by the time we release 6.1. Fair game? >> Live migrating old guests from an old QEMU with the SCSI feature bit >> enabled will fail with "Features 0x... unsupported. Allowed features: >> 0x...". We've followed the QEMU deprecation policy so users have been >> warned... >> > > Were they really warned, though? People running > "-machine pc-i440fx-2.4" might be completely unaware that it was > silently enabling a deprecated feature. We've gotten better at documenting deprecations, but we're still bad at warning on use of deprecated features. [...]
Re: [PATCH v2 1/2] meson: Select 'have_system' when virtiofsd is enabled
On 29/04/21 10:44, Peter Maydell wrote:
On Thu, 29 Apr 2021 at 09:33, Philippe Mathieu-Daudé wrote:
When not explicitly select a sysemu target and building virtiofsd,
the seccomp/cap-ng libraries are not resolved, leading to this error:
$ configure --target-list=i386-linux-user --disable-tools --enable-virtiofsd
tools/meson.build:12:6: ERROR: Problem encountered: virtiofsd requires
libcap-ng-devel and seccomp-devel
Fix by enabling sysemu (have_system) when virtiofsd is built.
Reported-by: Mahmoud Mandour
Signed-off-by: Philippe Mathieu-Daudé
---
meson.build | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meson.build b/meson.build
index c6f4b0cf5e8..f858935ad95 100644
--- a/meson.build
+++ b/meson.build
@@ -51,6 +51,8 @@
have_system = have_system or target.endswith('-softmmu')
endforeach
have_tools = 'CONFIG_TOOLS' in config_host
+# virtiofsd depends on sysemu
+have_system = have_system or not get_option('virtiofsd').disabled()
This looks odd. The natural assumption is that "have_system" ought to mean
"we are building a system emulator", not "we are building a system emulator
or virtiofsd".
I agree this is a bit jarring.
If virtiofsd requires libcap-ng-devel and seccomp-devel, those tests
only should use
have_system or not get_option('virtiofsd').disabled()
instead of just have_system. (The reason why we have those complicated
expressions is to avoid getting warnings on static builds, for libraries
that are only available as shared libraries. There are plans to make it
look a bit nicer in upstream Meson which the maintainers have already
accepted; however, I haven't been able to contribute much to it lately).
Thanks,
Paolo
Re: [PATCH] meson: Set implicit_include_directories to false
On 29/04/21 04:43, Katsuhiro Ueno wrote:
Without this, libvixl cannot be compiled with macOS 11.3 SDK due to
include file name conflict (usr/include/c++/v1/version conflicts with
VERSION).
Signed-off-by: Katsuhiro Ueno
---
meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/meson.build b/meson.build
index c6f4b0cf5e..d007bff8c3 100644
--- a/meson.build
+++ b/meson.build
@@ -2129,6 +2129,7 @@ common_all = common_ss.apply(config_all, strict: false)
common_all = static_library('common',
build_by_default: false,
sources: common_all.sources() + genh,
+implicit_include_directories: false,
dependencies: common_all.dependencies(),
name_suffix: 'fa')
Can you include the difference in the include paths (the -I and -iquote
arguments)? There are many cases in which we rely on having the current
source directory in the build path, for example all inclusions of "trace.h".
Paolo
[PATCH] oslib-win32: do not rely on macro to get redefined function name
On Windows with glib <2.50, g_poll is redefined to use the variant
defined in util/oslib-win32.c. Use the same name in the declaration
and definition for ease of grepping.
Signed-off-by: Paolo Bonzini
---
util/oslib-win32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/util/oslib-win32.c b/util/oslib-win32.c
index f68b8012bb..13418f68c0 100644
--- a/util/oslib-win32.c
+++ b/util/oslib-win32.c
@@ -472,7 +472,7 @@ static int poll_rest(gboolean poll_msgs, HANDLE *handles,
gint nhandles,
return 0;
}
-gint g_poll(GPollFD *fds, guint nfds, gint timeout)
+gint g_poll_fixed(GPollFD *fds, guint nfds, gint timeout)
{
HANDLE handles[MAXIMUM_WAIT_OBJECTS];
gboolean poll_msgs = FALSE;
--
2.30.1
Re: [PATCH] virtio-blk: drop deprecated scsi=on|off property
On Fri, Apr 30, 2021 at 09:42:05 +0200, Markus Armbruster wrote: > Eduardo Habkost writes: > > > On Thu, Apr 29, 2021 at 04:52:21PM +0100, Stefan Hajnoczi wrote: > >> The scsi=on|off property was deprecated in QEMU 5.0 and can be removed > >> completely at this point. > >> > >> Drop the scsi=on|off option. It was only available on Legacy virtio-blk > >> devices. Linux v5.6 already dropped support for it. > >> > >> Remove the hw_compat_2_4[] property assignment since scsi=on|off no > >> longer exists. Old guests with Legacy virtio-blk devices no longer see > >> the SCSI host features bit. > >> > > > > This means pc-2.4 will now break guest ABI if using virtio-blk > > devices, correct? > > > > This looks like a sign we should have deprecated pc-2.4 a long > > time ago. > > The last batch of PC machine type retiring was pc-1.0 to pc-1.3: > deprecated in 5.0 (commit 30d2a17b4, Dec 2019), dropped in 6.0 (commit > f862ddbb1, just weeks ago). pc-1.3 was a bit over seven years old when > we released 5.0. pc-2.4 will be six years old by the time we release > 6.1. Fair game? As a data-point, libvirt will be dropping support for
Re: [PATCH 2/2] ui/cocoa: add option to swap Option and Command, enable by default
> @@ -797,12 +806,22 @@ - (bool) handleEventLocked:(NSEvent *)event
> qkbd_state_key_event(kbd, Q_KEY_CODE_CTRL_R, false);
> }
> if (!(modifiers & NSEventModifierFlagOption)) {
> -qkbd_state_key_event(kbd, Q_KEY_CODE_ALT, false);
> -qkbd_state_key_event(kbd, Q_KEY_CODE_ALT_R, false);
> +if ([self isSwapOptionCommandEnabled]) {
> +qkbd_state_key_event(kbd, Q_KEY_CODE_META_L, false);
> +qkbd_state_key_event(kbd, Q_KEY_CODE_META_R, false);
> +} else {
> +qkbd_state_key_event(kbd, Q_KEY_CODE_ALT, false);
> +qkbd_state_key_event(kbd, Q_KEY_CODE_ALT_R, false);
> +}
> }
> if (!(modifiers & NSEventModifierFlagCommand)) {
> -qkbd_state_key_event(kbd, Q_KEY_CODE_META_L, false);
> -qkbd_state_key_event(kbd, Q_KEY_CODE_META_R, false);
> +if ([self isSwapOptionCommandEnabled]) {
> +qkbd_state_key_event(kbd, Q_KEY_CODE_ALT, false);
> +qkbd_state_key_event(kbd, Q_KEY_CODE_ALT_R, false);
> +} else {
> +qkbd_state_key_event(kbd, Q_KEY_CODE_META_L, false);
> +qkbd_state_key_event(kbd, Q_KEY_CODE_META_R, false);
> +}
> }
Wouldn't it be easier to swap the bits in the modifiers variable once
instead of having lots of isSwapOptionCommandEnabled checks in the code?
take care,
Gerd
Re: [PATCH 1/2] ui/cocoa: capture all keys and combos when mouse is grabbed
On Thu, Apr 29, 2021 at 08:47:04PM -0300, gust...@noronha.eti.br wrote: > From: Gustavo Noronha Silva > > Applications such as Gnome may use Alt-Tab and Super-Tab for different > purposes, some use Ctrl-arrows so we want to allow qemu to handle > everything when it captures the mouse/keyboard. > > However, Mac OS handles some combos like Command-Tab and Ctrl-arrows > at an earlier part of the event handling chain, not letting qemu see it. > > We add a global Event Tap that allows qemu to see all events when the > mouse is grabbed. Note that this requires additional permissions. > > See: > > https://developer.apple.com/documentation/coregraphics/1454426-cgeventtapcreate?language=objc#discussion > https://support.apple.com/en-in/guide/mac-help/mh32356/mac Looks all sensible to me, I'd like to have the opinion from the MacOS experts for this one though. thanks, Gerd
[Bug 1919036] Re: Assertion failure in fifo8_push_all() through am53c974
** 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/1919036 Title: Assertion failure in fifo8_push_all() through am53c974 Status in QEMU: Fix Released Bug description: Hello, Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. This was found in version 5.2.0 (master, 3f8d1885e4) ``` qemu-system-i386: ../util/fifo8.c:43: fifo8_push_all: Assertion `fifo->num + num <= fifo->capacity' failed. #0 0x70218fb7 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x7021a921 in __GI_abort () at abort.c:79 #2 0x7020a48a in __assert_fail_base (fmt=0x70391750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x58ed2400 "fifo->num + num <= fifo->capacity", file=file@entry=0x58ed2380 "../util/fifo8.c", line=line@entry=0x2b, function=function@entry=0x58ed2560 <__PRETTY_FUNCTION__.16583> "fifo8_push_all") at assert.c:92 #3 0x7020a502 in __GI___assert_fail (assertion=assertion@entry=0x58ed2400 "fifo->num + num <= fifo->capacity", file=file@entry=0x58ed2380 "../util/fifo8.c", line=line@entry=0x2b, function=function@entry=0x58ed2560 <__PRETTY_FUNCTION__.16583> "fifo8_push_all") at assert.c:101 #4 0x587749c4 in fifo8_push_all (fifo=fifo@entry=0x61f05200, data=data@entry=0x7fff72bfa640 "", num=num@entry=0x24) at ../util/fifo8.c:43 #5 0x572bd13e in esp_do_dma (s=s@entry=0x61f05088) at ../hw/scsi/esp.c:577 #6 0x572bfc8f in handle_ti (s=0x61f05088) at ../hw/scsi/esp.c:845 #7 0x572c419c in esp_reg_write (s=0x61f05088, saddr=saddr@entry=0x3, val=) at ../hw/scsi/esp.c:987 #8 0x57bb916a in esp_pci_io_write (opaque=0x61f04680, addr=, val=, size=) at ../hw/scsi/esp-pci.c:214 #9 0x5817ea28 in memory_region_write_accessor (mr=0x61f04f70, addr=, value=, size=, shift=, mask=, attrs=...) at ../softmmu/memory.c:491 #10 0x58176671 in access_with_adjusted_size (addr=addr@entry=0xc, value=value@entry=0x7fff72bfb2a8, size=size@entry=0x1, access_size_min=, access_size_max=, access_fn= 0x5817e7c0 , mr=0x61f04f70, attrs=...) at ../softmmu/memory.c:552 #11 0x581892aa in memory_region_dispatch_write (mr=mr@entry=0x61f04f70, addr=, data=, data@entry=0xff90, op=op@entry=MO_8, attrs=..., attrs@entry=...) at ../softmmu/memory.c:1508 #12 0x58024b66 in address_space_stb (as=, addr=, val=, attrs=..., result=0x0) at /home/cwmyung/prj/hyfuzz/src/qemu-master/memory_ldst.c.inc:382 #13 0x7fff9323641c in code_gen_buffer () #14 0x57e793bb in cpu_tb_exec (tb_exit=, itb=, cpu=0x62e004b4) at ../accel/tcg/cpu-exec.c:190 #15 0x57e793bb in cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x62e004b4) at ../accel/tcg/cpu-exec.c:673 #16 0x57e793bb in cpu_exec (cpu=cpu@entry=0x62e00400) at ../accel/tcg/cpu-exec.c:798 #17 0x57f5fc5a in tcg_cpus_exec (cpu=cpu@entry=0x62e00400) at ../accel/tcg/tcg-accel-ops.c:68 #18 0x582260af in mttcg_cpu_thread_fn (arg=arg@entry=0x62e00400) at ../accel/tcg/tcg-accel-ops-mttcg.c:70 #19 0x58777b05 in qemu_thread_start (args=) at ../util/qemu-thread-posix.c:521 #20 0x705d26db in start_thread (arg=0x7fff72bff700) at pthread_create.c:463 #21 0x702fb71f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 ``` To reproduce the assertion failure, please run the QEMU with the following command line. ``` $ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img ``` Please let me know if I can provide any further info. Thank you. - Cheolwoo, Myung (Seoul National University) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1919036/+subscriptions
[Bug 1916112] Re: Illegal instruction crash of QEMU on Jetson Nano
** 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/1916112 Title: Illegal instruction crash of QEMU on Jetson Nano Status in QEMU: Fix Released Bug description: I have a jetson nano (arm64 SBC) and I want to check the native emulation performance of Raspbian Buster. I used the info available here: https://github.com/dhruvvyas90/qemu-rpi-kernel/tree/master/native- emuation I have Xubuntut 20.04 with KVM enabled kernel running on the Jetson Nano However QEMU crashes with "Illegal Instruction" during kernel boot. I have a built latest QEMU from sources with following configuration ./configure --prefix=/usr/local --target-list=aarch64-softmmu,arm- softmmu --enable-guest-agent --enable-vnc --enable-vnc-jpeg --enable-vnc-png --enable-kvm --enable-spice --enable-sdl --enable-gtk --enable-virglrenderer --enable-opengl qemu-system-aarch64 --version QEMU emulator version 5.2.50 (v5.2.0-1731-g5b19cb63d9) When I run as follows: ../build/qemu-system-aarch64 -M raspi3 -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1" -dtb ./bcm2710-rpi-3-b-plus.dtb -sd /media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.qcow2 -kernel ./kernel8.img -m 1G -smp 4 -serial stdio -usb -device usb-mouse -device usb-kbd I get : [ 74.994834] systemd[1]: Condition check resulted in FUSE Control File System being skipped. [ 76.281274] systemd[1]: Starting Apply Kernel Variables... Starting Apply Kernel Variables... Illegal instruction (core dumped) When I use GDB I see this: Thread 8 "qemu-system-aar" received signal SIGILL, Illegal instruction. [Switching to Thread 0x7fad7f9ba0 (LWP 28037)] 0x007f888ac690 in code_gen_buffer () (gdb) bt #0 0x007f888ac690 in code_gen_buffer () #1 0x00d7c038 in cpu_tb_exec (tb_exit=, itb=, cpu=0x7fb4502c40) at ../accel/tcg/cpu-exec.c:191 #2 cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x7fb4502c40) at ../accel/tcg/cpu-exec.c:708 #3 cpu_exec (cpu=cpu@entry=0x7fb4502c40) at ../accel/tcg/cpu-exec.c:819 .. I have just two questions: Is this a problem with QEMU or is there anything specific build or options I need to use. Any specific version of QEMU should be used ? Why is TCG used as the accelerator when KVM is present. Is it possible and how to use KVM ? If I enabled the KVM then I get this error: ../build/qemu-system-aarch64 -M raspi3 -enable-kvm -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootdelay=1" -dtb ./bcm2710-rpi-3-b-plus.dtb -sd /media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.qcow2 -kernel ./kernel8.img -m 1G -smp 4 -serial stdio -usb -device usb-mouse -device usb-kbd WARNING: Image format was not specified for '/media/96747D21747D0571/JetsonNano/2020-08-20-raspios-buster-armhf-full.img' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. qemu-system-aarch64: ../softmmu/physmem.c:750: cpu_address_space_init: Assertion `asidx == 0 || !kvm_enabled()' failed. Thanks a lot. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916112/+subscriptions
[Bug 1914849] Re: mprotect fails after MacOS 11.2 on arm mac
Fixed here: https://gitlab.com/qemu-project/qemu/-/commit/c118881ee607dcac ** 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/1914849 Title: mprotect fails after MacOS 11.2 on arm mac Status in QEMU: Fix Released Bug description: I got the following error when I ran qemu on arm mac(MacOS 11.2). ``` $ ./qemu-system-x86_64 qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied ** ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) [1]34898 abort ./qemu-system-x86_64 ``` I tested the same version of qemu on intel mac(MacOS 11.2), but it works fine. And my friend told me that they did not have this error with MacOS 11.1. So, I think it is CPU architecture or an OS version dependent error. Environment: Qemu commit id: d0dddab40e472ba62b5f43f11cc7dba085dabe71 OS: MacOS 11.2(20D64) Hardware: MacBook Air (M1, 2020) How to build: ``` mkdir build/ cd build/ ../configure --target-list=aarch64-softmmu,x86_64-softmmu make ``` How to reproduce: ``` ./qemu-system-x86_64 ``` Error message: ``` $ ./qemu-system-x86_64 qemu-system-x86_64: qemu_mprotect__osdep: mprotect failed: Permission denied ** ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) Bail out! ERROR:../tcg/tcg.c:844:tcg_region_init: assertion failed: (!rc) [1]34898 abort ./qemu-system-x86_64 ``` To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1914849/+subscriptions
[Bug 1879531] Re: Stack-overflow in _eth_get_rss_ex_dst_addr
https://gitlab.com/qemu-project/qemu/-/commit/7d6a4f123e00c9dbd ** 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/1879531 Title: Stack-overflow in _eth_get_rss_ex_dst_addr Status in QEMU: Fix Released Bug description: Hello, While fuzzing, I found a 1-byte stack-overflow (read) through the e1000e. ==10318==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdb76c16c2 at pc 0x55594f1a69e1 bp 0x7ffdb76c15a0 sp 0x7ffdb76c1598 READ of size 1 at 0x7ffdb76c16c2 thread T0 #0 0x55594f1a69e0 in _eth_get_rss_ex_dst_addr /home/alxndr/Development/qemu/net/eth.c:410:17 #1 0x55594f1a39da in eth_parse_ipv6_hdr /home/alxndr/Development/qemu/net/eth.c:532:17 #2 0x55594ebc34f2 in net_tx_pkt_parse_headers /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:228:14 #3 0x55594ebc2149 in net_tx_pkt_parse /home/alxndr/Development/qemu/hw/net/net_tx_pkt.c:273:9 #4 0x55594ec1ba76 in e1000e_process_tx_desc /home/alxndr/Development/qemu/hw/net/e1000e_core.c:737:29 #5 0x55594ec1aea4 in e1000e_start_xmit /home/alxndr/Development/qemu/hw/net/e1000e_core.c:934:9 #6 0x55594ec0e70e in e1000e_set_tdt /home/alxndr/Development/qemu/hw/net/e1000e_core.c:2451:9 #7 0x55594ebec435 in e1000e_core_write /home/alxndr/Development/qemu/hw/net/e1000e_core.c:3261:9 #8 0x55594ebdf11b in e1000e_mmio_write /home/alxndr/Development/qemu/hw/net/e1000e.c:109:5 #9 0x55594dfd98b1 in memory_region_write_accessor /home/alxndr/Development/qemu/memory.c:483:5 #10 0x55594dfd9211 in access_with_adjusted_size /home/alxndr/Development/qemu/memory.c:544:18 #11 0x55594dfd7c30 in memory_region_dispatch_write /home/alxndr/Development/qemu/memory.c:1476:16 #12 0x55594dde24b8 in flatview_write_continue /home/alxndr/Development/qemu/exec.c:3137:23 #13 0x55594ddd12dc in flatview_write /home/alxndr/Development/qemu/exec.c:3177:14 #14 0x55594ddd0dec in address_space_write /home/alxndr/Development/qemu/exec.c:3268:18 #15 0x55594dfcdbdc in qtest_process_command /home/alxndr/Development/qemu/qtest.c:567:9 #16 0x55594dfc3700 in qtest_process_inbuf /home/alxndr/Development/qemu/qtest.c:710:9 #17 0x55594dfc2cc8 in qtest_read /home/alxndr/Development/qemu/qtest.c:722:5 #18 0x55594f74b259 in qemu_chr_be_write_impl /home/alxndr/Development/qemu/chardev/char.c:183:9 #19 0x55594f74b3ee in qemu_chr_be_write /home/alxndr/Development/qemu/chardev/char.c:195:9 #20 0x55594f7556fc in fd_chr_read /home/alxndr/Development/qemu/chardev/char-fd.c:68:9 #21 0x55594f7ea488 in qio_channel_fd_source_dispatch /home/alxndr/Development/qemu/io/channel-watch.c:84:12 #22 0x7f43f6c1d897 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4e897) #23 0x55594f9dea5d in glib_pollfds_poll /home/alxndr/Development/qemu/util/main-loop.c:219:9 #24 0x55594f9dd1d7 in os_host_main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:242:5 #25 0x55594f9dcd6e in main_loop_wait /home/alxndr/Development/qemu/util/main-loop.c:518:11 #26 0x55594e44cd01 in qemu_main_loop /home/alxndr/Development/qemu/softmmu/vl.c:1664:9 #27 0x55594f803c21 in main /home/alxndr/Development/qemu/softmmu/main.c:49:5 #28 0x7f43f57b4e0a in __libc_start_main /build/glibc-GwnBeO/glibc-2.30/csu/../csu/libc-start.c:308:16 #29 0x55594dd03889 in _start (/home/alxndr/Development/qemu/build/i386-softmmu/qemu-system-i386+0xdbd889) Address 0x7ffdb76c16c2 is located in stack of thread T0 at offset 34 in frame #0 0x55594f1a303f in eth_parse_ipv6_hdr /home/alxndr/Development/qemu/net/eth.c:486 This frame has 1 object(s): [32, 34) 'ext_hdr' (line 487) <== Memory access at offset 34 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /home/alxndr/Development/qemu/net/eth.c:410:17 in _eth_get_rss_ex_dst_addr Shadow bytes around the buggy address: 0x100036ed0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100036ed0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100036ed02a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100036ed02b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100036ed02c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x100036ed02d0: 00 00 00 00 f1 f1 f1 f1[02]f3 f3 f3 00 00 00 00 0x100036ed02e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100036ed02f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100036ed0300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100036ed0310: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100036ed0320: 00 00 00 00 0
[Bug 1922617] Re: qemu-aarch64-static "Illegal instruction" with debootstrap
** 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/1922617 Title: qemu-aarch64-static "Illegal instruction" with debootstrap Status in QEMU: Fix Released Bug description: This is reproducible against QEMU master. I apologize for the long reproduction steps, I tried to distill it down as much as possible. System info: # qemu-aarch64-static --version qemu-aarch64 version 5.2.91 (v6.0.0-rc1-68-gee82c086ba) Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers # cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/"; # head -n 26 /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz stepping: 7 microcode : 0x5002f01 cpu MHz : 1000.716 cache size : 22528 KB physical id : 0 siblings: 32 core id : 0 cpu cores : 16 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single intel_ppin ssbd mba ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke avx512_vnni md_clear flush_l1d arch_capabilities bugs: spectre_v1 spectre_v2 spec_store_bypass swapgs taa itlb_multihit bogomips: 4600.00 clflush size: 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management: My reproduction steps: # apt-get install --no-install-recommends -y \ build-essential \ ca-certificates \ debootstrap \ git \ libglib2.0-dev \ libpixman-1-dev \ ninja-build \ pkg-config \ python3 \ zstd # git clone https://github.com/qemu/qemu # mkdir qemu/build # cd qemu/build # ../configure \ --enable-debug \ --enable-linux-user \ --disable-bsd-user \ --disable-werror \ --disable-system \ --disable-tools \ --disable-docs \ --disable-gtk \ --disable-gnutls \ --disable-nettle \ --disable-gcrypt \ --disable-glusterfs \ --disable-libnfs \ --disable-libiscsi \ --disable-vnc \ --disable-kvm \ --disable-libssh \ --disable-libxml2 \ --disable-vde \ --disable-sdl \ --disable-opengl \ --disable-xen \ --disable-fdt \ --disable-vhost-net \ --disable-vhost-crypto \ --disable-vhost-user \ --disable-vhost-vsock \ --disable-vhost-scsi \ --disable-tpm \ --disable-qom-cast-debug \ --disable-capstone \ --disable-zstd \ --disable-linux-io-uring \ --static \ --target-list-exclude=hexagon-linux-user # ninja qemu-aarch64 # install -Dm755 qemu-aarch64 /usr/local/bin/qemu-aarch64-static # cat <<'EOF' >/proc/sys/fs/binfmt_misc/register :qemu-aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/local/bin/qemu-aarch64-static:CF EOF # debootstrap --arch arm64 --foreign buster debian-rootfs # chroot debian-rootfs /debootstrap/debootstrap --second-stage Illegal instruction This prevents me from building an arm64 Debian image on x86_64. If I am doing something wrong, please let me know. The binary has been uploaded for your convenience. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1922617/+subscriptions
[Bug 1913012] Re: Installed firmware descriptor files contain (invalid) relative paths
Fixed here: https://gitlab.com/qemu-project/qemu/-/commit/4b956a399969c0c497a ** 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/1913012 Title: Installed firmware descriptor files contain (invalid) relative paths Status in QEMU: Fix Released Bug description: After building and installing QEMU, the resulting installed firmware descriptor files contain relative paths for their `mapping.filename` properties. These relative paths are causing errors when using tools based on `libvirt` like `virt-install`, resulting in the inability to configure new VMs which reference these firmware descriptors. # QEMU version $ qemu-system-x86_64 -version QEMU emulator version 5.2.0 (I've also reproduced the issue with QEMU built from Git master @ v5.2.0-1300-g0e32462630, see next comment.) # OS version Void Linux x86_64 (glibc) Steps to reproduce (with results on my system): # Verify the symptom $ virt-install --boot firmware=efi --disk none --memory 2048 Using default --name vm4 WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results. Starting install... ERRORFailed to open file 'share/qemu/edk2-i386-vars.fd': No such file or directory Domain installation does not appear to have been successful. If it was, you can restart your domain by running: virsh --connect qemu:///session start vm4 otherwise, please restart your installation. # Verify that the file does exist on the system and is accessible $ ls -l /usr/share/qemu/edk2-i386-vars.fd -rw-r--r-- 1 root root 540672 12 dec 18:47 /usr/share/qemu/edk2-i386-vars.fd # Verify most likely cause $ grep filename /usr/share/qemu/firmware/*i386*.json /usr/share/qemu/firmware/50-edk2-i386-secure.json:"filename": "share/qemu/edk2-i386-secure-code.fd", /usr/share/qemu/firmware/50-edk2-i386-secure.json:"filename": "share/qemu/edk2-i386-vars.fd", /usr/share/qemu/firmware/60-edk2-i386.json:"filename": "share/qemu/edk2-i386-code.fd", /usr/share/qemu/firmware/60-edk2-i386.json:"filename": "share/qemu/edk2-i386-vars.fd", Note that all the paths are relative and are missing , i.e. `/usr`. # Workaround Manually editing the firmware descriptor files in `/usr/share/qemu/firmware` to contain full absolute paths to the firmware blobs resolves the issue: $ sudo sed -i.bak -e 's,"share/qemu/,"/usr/share/qemu/,' /usr/share/qemu/firmware/*.json $ virt-install --boot firmware=efi --disk none --memory 2048 [...VM boots normally...] To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1913012/+subscriptions
[Bug 1910826] Re: [OSS-Fuzz] Issue 29224 rtl8139: Stack-overflow in rtlNUMBER_transmit_one
https://gitlab.com/qemu-project/qemu/-/commit/5311fb805a4403bba ** 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/1910826 Title: [OSS-Fuzz] Issue 29224 rtl8139: Stack-overflow in rtlNUMBER_transmit_one Status in QEMU: Fix Released Bug description: === Reproducer === cat << EOF | ../build/qemu-system-i386 -machine q35 \ -nodefaults -device rtl8139,netdev=net0 \ -netdev user,id=net0 -display none -qtest stdio outl 0xcf8 0x8804 outb 0xcfc 0x26 outl 0xcf8 0x8817 outb 0xcfc 0xff write 0x1 0x1 0x42 write 0x5 0x1 0x42 write 0x9 0x1 0x42 write 0xd 0x1 0x42 write 0xff44 0x4 0x11 write 0xff37 0x1 0x1c writel 0xff30 0xff00 write 0xff40 0x4 0x16 write 0xff10 0x4 0x01020 EOF === Stack Trace === ==2819215==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd2c714040 (pc 0x5639b3a933d9 bp 0x7ffd2c716210 sp 0x7ffd2c714040 T0) #0 rtl8139_transmit_one /src/qemu/hw/net/rtl8139.c:1815 #1 rtl8139_transmit /src/qemu/hw/net/rtl8139.c:2388:9 #2 rtl8139_TxStatus_write /src/qemu/hw/net/rtl8139.c:2442:5 #3 rtl8139_io_writel /src/qemu/hw/net/rtl8139.c:2865:13 #4 rtl8139_ioport_write /src/qemu/hw/net/rtl8139.c:3290:9 #5 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 #6 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 #7 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 #8 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 #9 flatview_write /src/qemu/softmmu/physmem.c:2799:14 #10 address_space_write /src/qemu/softmmu/physmem.c:2891:18 #11 address_space_rw /src/qemu/softmmu/physmem.c:2901:16 #12 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12 #13 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12 #14 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12 #15 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12 #16 rtl8139_write_buffer /src/qemu/hw/net/rtl8139.c:778:5 #17 rtl8139_do_receive /src/qemu/hw/net/rtl8139.c:1172:9 #18 rtl8139_transfer_frame /src/qemu/hw/net/rtl8139.c:1798:9 #19 rtl8139_transmit_one /src/qemu/hw/net/rtl8139.c:1845:5 #20 rtl8139_transmit /src/qemu/hw/net/rtl8139.c:2388:9 #21 rtl8139_TxStatus_write /src/qemu/hw/net/rtl8139.c:2442:5 #22 rtl8139_io_writel /src/qemu/hw/net/rtl8139.c:2865:13 #23 rtl8139_ioport_write /src/qemu/hw/net/rtl8139.c:3290:9 #24 memory_region_write_accessor /src/qemu/softmmu/memory.c:491:5 #25 access_with_adjusted_size /src/qemu/softmmu/memory.c:552:18 #26 memory_region_dispatch_write /src/qemu/softmmu/memory.c:0:13 #27 flatview_write_continue /src/qemu/softmmu/physmem.c:2759:23 #28 flatview_write /src/qemu/softmmu/physmem.c:2799:14 #29 address_space_write /src/qemu/softmmu/physmem.c:2891:18 #30 address_space_rw /src/qemu/softmmu/physmem.c:2901:16 #31 dma_memory_rw_relaxed /src/qemu/include/sysemu/dma.h:88:12 #32 dma_memory_rw /src/qemu/include/sysemu/dma.h:127:12 #33 pci_dma_rw /src/qemu/include/hw/pci/pci.h:801:12 #34 pci_dma_write /src/qemu/include/hw/pci/pci.h:837:12 #35 rtl8139_write_buffer /src/qemu/hw/net/rtl8139.c:778:5 #36 rtl8139_do_receive /src/qemu/hw/net/rtl8139.c:1172:9 #37 rtl8139_transfer_frame /src/qemu/hw/net/rtl8139.c:1798:9 Repeat until we run out of stack https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=29224 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1910826/+subscriptions
[Bug 1773743] Re: qemu-user -g xxx -E LD_PROFILE=xxx segfault
https://gitlab.com/qemu-project/qemu/-/commit/3ddd9036389f5f577e09 ** 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/1773743 Title: qemu-user -g xxx -E LD_PROFILE=xxx segfault Status in QEMU: Fix Released Bug description: Here is two simple steps to reproduce the bug: $ qemu-x86_64 -E LD_PROFILE=libc.so.6 -E LD_PROFILE_OUTPUT=. -g 12345 -L / /bin/ls (libc.so and /bin/ls might change on your system, in this case we just need a binary with a profilable needed library) In a other window launch: $ gdb (gdb) target remote :12345 (gdb) c At this point qemu will segfault. It seems this problem is appends when sigprof passed to gdb. One way I have found to bypass this: patch gdbstub.c gdb_handlesig and ignore sig if sig == TARGET_SIGPROF (which means now I can't catch sigprof on gdb anymore) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1773743/+subscriptions
[Bug 1914353] Re: QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID
Fix has been included here:
https://gitlab.com/qemu-project/qemu/-/commit/edfe2eb4360cde4ed5d95bd
** 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/1914353
Title:
QEMU: aarch64: :GIC: out-of-bounds access via interrupt ID
Status in QEMU:
Fix Released
Bug description:
Via [qemu-security] list
+-- On Sun, 31 Jan 2021, Philippe Mathieu-Daudé wrote --+
| On 1/31/21 11:34 AM, Philippe Mathieu-Daudé wrote:
| > Per the ARM Generic Interrupt Controller Architecture specification
| > (document "ARM IHI 0048B.b (ID072613)"), the SGIINTID field is 4 bit,
| > not 10:
| >
| >- Table 4-21 GICD_SGIR bit assignments
| >
| >The Interrupt ID of the SGI to forward to the specified CPU
| >interfaces. The value of this field is the Interrupt ID, in
| >the range 0-15, for example a value of 0b0011 specifies
| >Interrupt ID 3.
| >
...
| > Correct the irq mask to fix an undefined behavior (which eventually
| > lead to a heap-buffer-overflow, see [Buglink]):
| >
| >$ echo 'writel 0x8000f00 0xff4affb0' | qemu-system-aarch64 -M
virt,accel=qtest -qtest stdio
| >[I 1612088147.116987] OPENED
| > [R +0.278293] writel 0x8000f00 0xff4affb0
| > ../hw/intc/arm_gic.c:1498:13: runtime error: index 944 out of bounds for
type 'uint8_t [16][8]'
| > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior
../hw/intc/arm_gic.c:1498:13
| >
| > Cc: qemu-sta...@nongnu.org
| > Fixes: 9ee6e8bb853 ("ARMv7 support.")
| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913916
| > Buglink: https://bugs.launchpad.net/qemu/+bug/1913917
...
On 210202 1221, Peter Maydell wrote:
> In both cases the overrun is on the first writel to 0x8000f00,
> but the fuzzer has for some reason not reported that but instead
> blundered on until it happens to trigger some other issue that
> resulted from the memory corruption it induced with the first write.
>
...
> On the CVE:
>
> Since this can affect systems using KVM, this is a security bug for
> us. However, it only affects an uncommon configuration:
> you are only vulnerable if you are using "kernel-irqchip=off"
> (the default is 'on', and turning it off is an odd thing to do).
>
> thanks
> -- PMM
>
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1914353/+subscriptions
[Bug 1605123] Re: PEXT returns wrong values, seemingly switches arguments
** 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/1605123 Title: PEXT returns wrong values, seemingly switches arguments Status in QEMU: Fix Released Bug description: Hi, I fiddled with BMI2 instructions and discovered that pext instructions emulated with "qemu-x86_64 -cpu Haswell" return the wrong value. It seemingly switches up its arguments. I suspect that the error is around the gen_helper_pext(...) call in target-i386/translate.c. I checked helper_pext in target-i386/int_helper.c and it works fine. I ran my program on a CPU with BMI2 instruction set too, and it indeed returns different values. I didn't check pdep, it could have the same problem. $ qemu-x86_64 --version qemu-x86_64 version 2.6.50 (v2.6.0-2095-ge66b05e-dirty), Copyright (c) 2003-2008 Fabrice Bellard $ uname -a Linux lenard-hp 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux I compiled the attached file with the command line "gcc -o main -g -mbmi2 main.c". $ gcc --version gcc (Debian 5.4.0-6) 5.4.0 20160609 Best regards, Lénárd Szolnoki To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1605123/+subscriptions
Re: [PATCH v1] tests/migration: introduce multifd into guestperf
On Sat, Mar 20, 2021 at 01:04:56AM +0800, huang...@chinatelecom.cn wrote: > From: Hyman > > Guestperf tool does not cover the multifd-enabled migration > currently, it is worth supporting so that developers can > analysis the migration performance with all kinds of > migration. > > To request that multifd is enabled, with 4 channels: > $ ./tests/migration/guestperf.py \ > --multifd --multifd-channels 4 --output output.json > > To run the entire standardized set of multifd-enabled > comparisons, with unix migration: > $ ./tests/migration/guestperf-batch.py \ > --dst-host localhost --transport unix \ > --filter compr-multifd* --output outputdir > > Signed-off-by: Hyman Huang(黄勇) > --- > tests/migration/guestperf/comparison.py | 14 ++ > tests/migration/guestperf/engine.py | 16 > tests/migration/guestperf/scenario.py | 12 ++-- > tests/migration/guestperf/shell.py | 10 +- > 4 files changed, 49 insertions(+), 3 deletions(-) Reviewed-by: Daniel P. Berrangé I'll queue it, sorry for the delay in responding to this. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
[Bug 1774412] Re: -icount sleep=on|off documentation is confusing
** 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/1774412 Title: -icount sleep=on|off documentation is confusing Status in QEMU: Fix Released Bug description: The documentation for the -icount option in the qemu man page says: "When the virtual cpu is sleeping, the virtual time will advance at default speed unless sleep=on|off is specified. With sleep=on|off, the virtual time will jump to the next timer deadline instantly whenever the virtual cpu goes to sleep mode and will not advance if no timer is enabled." Taking this literally and specifying "sleep=on|off" on the command line does not work, so presumably the two instances of "sleep=on|off" should be either "sleep=on" or "sleep=off", whichever is correct :) Also, the synopsis line "-icount [shift=N|auto][,rr=record|replay,rrfile=filename,rrsnapshot=snapshot" fails to mention the sleep keyword at all. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1774412/+subscriptions
[Bug 1407808] Re: virtual console gives strange response to ANSI DSR
** 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/1407808 Title: virtual console gives strange response to ANSI DSR Status in QEMU: Fix Released Bug description: With "-serial vc" (which is the default), qemu make strange responses to the ANSI DSR escape sequence (\033[6n) which can confuse guests. Terminal emulators supporting the ANSI escape sequences usually support the "Device Status Report" escape sequence, \033[6n, to which as a response the terminal injects as input the response \033[n;mR, containing the current cursor position. An application running in the guest can use this escape sequence to, for example, figure out the size of the terminal it is running under, which can be useful as the guest has no other standard way to figure out a "size" for the serial port. Unfortunately, it seems that qemu when run with "-serial vc" (which appears to be the default), when qemu gets the \033[6n escape sequence on the serial port, it just responds with a single \033, and that's it! This can confuse an application, could concievably assume that a terminal either supports this escape sequence and injects the correct response (\033[n;mR), or doesn't support it and injects absolutely nothing as input - but not something in between. This caused a problem on one shell implementation on OSv that tried to figure out the terminal's size, and had to work around this unexpected behavior (see https://github.com/cloudius- systems/osv/commit/b79223584be40459861d1c12e1cb67e3e49e2a12). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1407808/+subscriptions
[Bug 1907817] Re: qemu-aarch64 tcg assertion 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/1907817 Title: qemu-aarch64 tcg assertion v5.2.0 Status in QEMU: Fix Released Bug description: After updating to 5.2 I am getting following assertion error: qemu-aarch64: ../tcg/tcg-op-gvec.c:54: check_size_align: Assertion `(maxsz & max_align) == 0' failed. I think it was introduced by commit: e2e7168a214b0ed98dc357bba96816486a289762 Becasue before this change, in function simd_desc only maxsz % 8 == 0 was checked, but after this change qemu check for following: max_align = maxsz >= 16 ? 15 : 7; tcg_debug_assert((maxsz & max_align) == 0); <--- here assertion happens in my case maxsz=56. Whole backtrace: #4 0x004000314770 in check_size_align (oprsz=56, maxsz=56, ofs=0) at ../tcg/tcg-op-gvec.c:54 #5 0x004000314950 in simd_desc (oprsz=56, maxsz=56, data=0) at ../tcg/tcg-op-gvec.c:89 #6 0x004000316270 in do_dup (vece=0, dofs=3144, oprsz=56, maxsz=56, in_32=0x0, in_64=0x0, in_c=0) at ../tcg/tcg-op-gvec.c:630 #7 0x0040003164d0 in expand_clr (dofs=3144, maxsz=56) at ../tcg/tcg-op-gvec.c:679 #8 0x004000319bb0 in tcg_gen_gvec_mov (vece=3, dofs=3136, aofs=3136, oprsz=8, maxsz=64) at ../tcg/tcg-op-gvec.c:1538 #9 0x004000200dc0 in clear_vec_high (s=0x40021a8180, is_q=false, rd=0) at ../target/arm/translate-a64.c:592 #10 0x004000200e40 in write_fp_dreg (s=0x40021a8180, reg=0, v=0x1108) at ../target/arm/translate-a64.c:600 --Type for more, q to quit, c to continue without paging-- #11 0x004000200e90 in write_fp_sreg (s=0x40021a8180, reg=0, v=0x1060) at ../target/arm/translate-a64.c:608 #12 0x004000214210 in handle_fpfpcvt (s=0x40021a8180, rd=0, rn=0, opcode=2, itof=true, rmode=0, scale=64, sf=0, type=0) at ../target/arm/translate-a64.c:6988 #13 0x004000214f90 in disas_fp_int_conv (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7299 #14 0x004000215350 in disas_data_proc_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:7389 #15 0x00400022aa70 in disas_data_proc_simd_fp (s=0x40021a8180, insn=505544704) at ../target/arm/translate-a64.c:14494 #16 0x00400022af90 in disas_a64_insn (env=0x7fac59b6b490, s=0x40021a8180) at ../target/arm/translate-a64.c:14663 #17 0x00400022b750 in aarch64_tr_translate_insn (dcbase=0x40021a8180, cpu=0x7fac59b63150) at ../target/arm/translate-a64.c:14823 #18 0x0040002e8630 in translator_loop (ops=0x4000902e00 , db=0x40021a8180, cpu=0x7fac59b63150, tb=0x7fac3419c5c0, max_insns=512) at ../accel/tcg/translator.c:103 #19 0x0040002e3a60 in gen_intermediate_code (cpu=0x7fac59b63150, tb=0x7fac3419c5c0, max_insns=512) at ../target/arm/translate.c:9283 #20 0x0040002fed30 in tb_gen_code (cpu=0x7fac59b63150, pc=4458820, cs_base=0, flags=2148544819, cflags=-16777216) at ../accel/tcg/translate-all.c:1744 #21 0x00400036a6e0 in tb_find (cpu=0x7fac59b63150, last_tb=0x7fac3419c400, tb_exit=0, cf_mask=0) at ../accel/tcg/cpu-exec.c:414 --Type for more, q to quit, c to continue without paging-- #22 0x00400036b040 in cpu_exec (cpu=0x7fac59b63150) at ../accel/tcg/cpu-exec.c:770 #23 0x004000113a90 in cpu_loop (env=0x7fac59b6b490) at ../linux-user/aarch64/cpu_loop.c:84 #24 0x0040002fb8c0 in main (argc=2, argv=0x40021a8e68, envp=0x40021a8e80) at ../linux-user/main.c:864 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1907817/+subscriptions
[Bug 1904331] Re: Coding bug in the function serial_ioport_write in serial.c
https://gitlab.com/qemu-project/qemu/-/commit/29daa894b6c31eae074d
** 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/1904331
Title:
Coding bug in the function serial_ioport_write in serial.c
Status in QEMU:
Fix Released
Bug description:
Branch hash: b50ea0d (pulled from github).
I was reviewing the code and noticed the following in the function
serial_ioport_write:
assert(size == 1 && addr < 8);
.
.
.
switch(addr) {
default:
case 0:
if (s->lcf & UART_LCR_DLAB) {
if (size == 1) {
s->divider = (s->divider & 0xff00) | val;
} else {
s->divider = val;
}
}
The assert will trigger if the size is > 1, so the else of the if
(size == 1) will never be executed and an attempt to specify a size >
1 will trigger an assert.
The documentation for the UART indicates that the 16-bit divisor is
broken up amongst 2 8-bit registers (DLL and DLM). There already is
code to handle the DLL and DLM portions of the divider register (as
coded).
This is not exactly going to cause a bug, as there is no code that
calls this function with a value for size other than 1. It is just
unnecessary code.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1904331/+subscriptions
[Bug 1906905] Re: qemu-system-sparc stucked while booting using ss20_v2.25_rom
Fix has been included here: https://gitlab.com/qemu-project/qemu/-/commit/62a9b228b5fefe0f9e364d ** 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/1906905 Title: qemu-system-sparc stucked while booting using ss20_v2.25_rom Status in QEMU: Fix Released Bug description: I cannot boot up OBP using the current (5.1) version of qemu with ss20_v2.25_rom. It just stuck at "Power-ON reset" and hanged. However using the previous version from 2015 I can successfully both up the OBP. qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25.rom -nographic Power-ON Reset (*hang) regards Yap KV To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1906905/+subscriptions
[Bug 1906693] Re: Assertion Failure in bdrv_co_write_req_prepare through megasas
https://gitlab.com/qemu-project/qemu/-/commit/86b1cf322789b79c8a ** 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/1906693 Title: Assertion Failure in bdrv_co_write_req_prepare through megasas Status in QEMU: Fix Released Bug description: affects qemu subscribe h...@suse.com subscribe phi...@redhat.com subscribe stefa...@redhat.com subscribe kw...@redhat.com === Stack Trace === qemu-fuzz-i386: block/io.c:1835: int bdrv_co_write_req_prepare(BdrvChild *, int64_t, uint64_t, BdrvTrackedRequest *, int): Assertion `child->perm & BLK_PERM_WRITE' failed. ==1505128== ERROR: libFuzzer: deadly signal #0 0x55a083b92cee in __sanitizer_print_stack_trace (qemu-fuzz-i386+0x793cee) #1 0x55a083b6c1d1 in fuzzer::PrintStackTrace() (qemu-fuzz-i386+0x76d1d1) #2 0x55a083b4f0d6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (qemu-fuzz-i386+0x7500d6) #3 0x55a083b4f19b in fuzzer::Fuzzer::StaticCrashSignalCallback() (qemu-fuzz-i386+0x75019b) #4 0x7f8d24ed6a8f (/lib64/libpthread.so.0+0x14a8f) #5 0x7f8d24d079e4 in raise (/lib64/libc.so.6+0x3c9e4) #6 0x7f8d24cf0894 in abort (/lib64/libc.so.6+0x25894) #7 0x7f8d24cf0768 in __assert_fail_base.cold (/lib64/libc.so.6+0x25768) #8 0x7f8d24cffe75 in __assert_fail (/lib64/libc.so.6+0x34e75) #9 0x55a08423763f in bdrv_co_write_req_prepare block/io.c:1835:13 #10 0x55a0842343a8 in bdrv_aligned_pwritev block/io.c:1915:11 #11 0x55a084233765 in bdrv_co_pwritev_part block/io.c:2104:11 #12 0x55a084260d1a in blk_do_pwritev_part block/block-backend.c:1260:11 #13 0x55a08426163e in blk_aio_write_entry block/block-backend.c:1476:17 #14 0x55a0843b0d23 in coroutine_trampoline util/coroutine-ucontext.c:173:9 #15 0x7f8d24d1d22f (/lib64/libc.so.6+0x5222f) === Reproducer=== cat << EOF | ./qemu-system-i386 -M q35 \ -device megasas-gen2 -device scsi-cd,drive=null0 \ -blockdev driver=null-co,read-zeroes=on,node-name=null0 \ -monitor none -serial none -display none \ -machine accel=qtest -m 64 -qtest stdio outl 0xcf8 0x80001804 outl 0xcfc 0xff outl 0xcf8 0x8000181b outl 0xcfc 0x7052005 write 0x5cc0 0x1 0x03 write 0x5cc7 0x1 0x40 write 0x5ce0 0x1 0x0a write 0x5cf3 0x1 0x01 write 0x5cf7 0x1 0x40 write 0x5cf8 0x1 0x0a write 0x5cff 0x1 0x05 write 0x5d03 0x1 0x5b write 0x5d06 0x1 0x4f write 0x5d0b 0x1 0x01 write 0x5d0f 0x1 0x40 write 0x5d10 0x1 0x0a write 0x5d17 0x1 0x05 write 0x5d1b 0x1 0x5b write 0x5d1e 0x1 0x4f write 0x5d23 0x1 0x01 write 0x5d27 0x1 0x40 write 0x5d28 0x1 0x0a write 0x5d2f 0x1 0x05 write 0x5d33 0x1 0x5b write 0x5d36 0x1 0x4f write 0x5d3b 0x1 0x01 write 0x5d3f 0x1 0x40 write 0x5d40 0x1 0x0a write 0x5d47 0x1 0x05 write 0x5d4b 0x1 0x5b write 0x5d4e 0x1 0x4f write 0x5d53 0x1 0x01 write 0x5d57 0x1 0x40 write 0x5d58 0x1 0x0a write 0x5d5f 0x1 0x05 write 0x5d63 0x1 0x5b write 0x5d66 0x1 0x4f write 0x5d6b 0x1 0x01 write 0x5d6f 0x1 0x40 write 0x5d70 0x1 0x0a write 0x5d77 0x1 0x05 write 0x5d7b 0x1 0x5b write 0x5d7e 0x1 0x4f write 0x5d83 0x1 0x01 write 0x5d87 0x1 0x40 write 0x5d88 0x1 0x0a write 0x5d8f 0x1 0x05 write 0x5d93 0x1 0x5b write 0x5d96 0x1 0x4f write 0x5d9b 0x1 0x01 write 0x5d9f 0x1 0x40 write 0x5da0 0x1 0x0a write 0x5da7 0x1 0x05 write 0x5dab 0x1 0x5b write 0x5dae 0x1 0x4f write 0x5db3 0x1 0x01 write 0x5db7 0x1 0x40 write 0x5db8 0x1 0x0a write 0x5dbf 0x1 0x05 write 0x5dc3 0x1 0x5b write 0x5dc6 0x1 0x4f write 0x5dcb 0x1 0x01 write 0x5dcf 0x1 0x40 write 0x5dd0 0x1 0x0a write 0x5dd7 0x1 0x05 write 0x5ddb 0x1 0x5b write 0x5dde 0x1 0x4f write 0x5de3 0x1 0x01 write 0x5de7 0x1 0x40 write 0x5de8 0x1 0x0a write 0x5def 0x1 0x05 write 0x5df3 0x1 0x5b write 0x5df6 0x1 0x4f write 0x5dfb 0x1 0x01 write 0x5dff 0x1 0x40 write 0x5e00 0x1 0x0a write 0x5e07 0x1 0x05 write 0x5e0b 0x1 0x5b write 0x5e0e 0x1 0x4f write 0x5e13 0x1 0x01 write 0x5e17 0x1 0x40 write 0x5e18 0x1 0x0a write 0x5e1f 0x1 0x05 write 0x5e23 0x1 0x5b write 0x5e26 0x1 0x4f write 0x5e2b 0x1 0x01 write 0x5e2f 0x1 0x40 write 0x5e30 0x1 0x0a write 0x5e37 0x1 0x05 write 0x5e3b 0x1 0x5b write 0x5e3e 0x1 0x4f write 0x5e43 0x1 0x01 write 0x5e47 0x1 0x40 write 0x5e48 0x1 0x0a write 0x5e4f 0x1 0x05 write 0x5e53 0x1 0x5b write 0x5e56 0x1 0x4f write 0x5e5b 0x1 0x01 write 0x5e5f 0x1 0x40 write 0x5e60 0x1 0x0a write 0x5e67 0x1 0x05 write 0x5e6b 0x1 0x5b write 0x5e6e 0x1 0x4f write 0x5e73 0x1 0x01 write 0x5e77 0x1 0x40 write 0x5e78 0x1 0x0a write 0x5e7f 0x1 0x05 write 0x5e83 0x1 0x5b write 0x5e86 0x1 0x4f write 0x5e8b 0x1 0x01 write 0x5e8f 0x1 0x40 write 0x5e90 0x1 0x0a write 0x5e97 0x1 0x05 write 0x5e9b 0x1 0x5b write 0x5e9e 0x1 0x4f write 0x5ea3 0x1 0
Re: [RFC PATCH v2 2/4] hw/arm/virt: Parse -smp cluster parameter in virt_smp_parse
On 2021/4/30 14:41, Andrew Jones wrote:
On Fri, Apr 30, 2021 at 01:09:00PM +0800, wangyanan (Y) wrote:
Hi Drew,
On 2021/4/29 19:02, Andrew Jones wrote:
On Thu, Apr 29, 2021 at 04:56:06PM +0800, wangyanan (Y) wrote:
On 2021/4/29 15:16, Andrew Jones wrote:
On Thu, Apr 29, 2021 at 10:14:37AM +0800, wangyanan (Y) wrote:
On 2021/4/28 18:31, Andrew Jones wrote:
On Tue, Apr 13, 2021 at 04:31:45PM +0800, Yanan Wang wrote:
} else if (sockets == 0) {
threads = threads > 0 ? threads : 1;
-sockets = cpus / (cores * threads);
+sockets = cpus / (clusters * cores * threads);
sockets = sockets > 0 ? sockets : 1;
If we initialize clusters to zero instead of one and add lines in
'cpus == 0 || cores == 0' and 'sockets == 0' like
'clusters = clusters > 0 ? clusters : 1' as needed, then I think we can
add
} else if (clusters == 0) {
threads = threads > 0 ? threads : 1;
clusters = cpus / (sockets * cores * thread);
clusters = clusters > 0 ? clusters : 1;
}
here.
I have thought about this kind of format before, but there is a little bit
difference between these two ways. Let's chose the better and more
reasonable one of the two.
Way A currently in this patch:
If value of clusters is not explicitly specified in -smp command line, we
assume
that users don't want to support clusters, for compatibility we initialized
the
value to 1. So that with cmdline "-smp cpus=24, sockets=2, cores=6", we will
parse out the topology description like below:
cpus=24, sockets=2, clusters=1, cores=6, threads=2
Way B that you suggested for this patch:
Whether value of clusters is explicitly specified in -smp command line or
not,
we assume that clusters are supported and calculate the value. So that with
cmdline "-smp cpus=24, sockets=2, cores=6", we will parse out the topology
description like below:
cpus =24, sockets=2, clusters=2, cores=6, threads=1
But I think maybe we should not assume too much about what users think
through the -smp command line. We should just assume that all levels of
cpu topology are supported and calculate them, and users should be more
careful if they want to get the expected results with not so complete
cmdline.
If I'm right, then Way B should be better. :)
Hi Yanan,
We're already assuming the user wants to describe clusters to the guest
because we require at least one per socket. If we want the user to have a
choice between using clusters or not, then I guess we need to change the
logic in the PPTT and the cpu-map to only generate the cluster level when
the number of clusters is not zero. And then change this parser to not
require clusters at all.
Hi Drew,
I think this kind of change will introduce more complexity and actually is
not necessary.
Not generating cluster level at all and generating cluster level (one per
socket) are same
to kernel. Without cluster description provided, kernel will initialize all
cores in the same
cluster which also means one cluster per socket.
Which kernel? All kernels? One without the cluster support patches [1]?
[1]
https://lore.kernel.org/lkml/20210420001844.9116-1-song.bao@hisilicon.com/#t
I'm sorry, I didn't make it clear. :)
I actually mean the ARM64 kernel, with or without [1].
Without [1]: Kernel doesn't care about cluster. When populating cpu
topology, it directly
finds the hierarchy node with "physical package flag" as package when
parsing ACPI, and
finds the core node's parent as package when parsing DT. So even we provide
cluster level
description (one per socket), the parsing results will be the same as not
providing at all.
With [1]: Kernel finds the core hierarchy node's parent as cluster when
parsing ACPI. So if
we don't provide cluster level description, package will be taken as
cluster. And if we provide
the description (one per socket), the parsing result will also be the same.
That's why I said that we just need to provide description of cluster (one
per socket) if we
don't want to make use of it in VMs.
OK, that sounds good.
[1]
https://lore.kernel.org/lkml/20210420001844.9116-1-song.bao@hisilicon.com/#t
So we should only ensure value of clusters per socket is one if we don't
want to use clusters,
and don't need to care about whether or not to generate description in PPTT
and cpu-map.
Is this right?
Depends on your answer to my 'which kernel' questions.
I'm not a big fan of these auto-calculated values either, but the
documentation says that it'll do that, and it's been done that way
forever, so I think we're stuck with it for the -smp option. Hmm, I was
just about to say that x86 computes all its values, but I see the most
recently added one, 'dies', is implemented the way you're proposing we
implement 'clusters', i.e. default to one and don't calculate it when it's
missing. I actually consider that either a documentation bug or an smp
parsing bug, though.
My propose originally came from implementation of x86.
Anothe
[Bug 1912065] Re: Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d
https://gitlab.com/qemu-project/qemu/-/commit/ae30e86661b0f4 ** 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/1912065 Title: Segfaults in tcg/optimize.c:212 after commit 7c79721606be11b5bc556449e5bcbc331ef6867d Status in QEMU: Fix Released Bug description: QEMU segfaults to NULL dereference in tcg/optimize.c:212 semi-randomly after commit 7c79721606be11b5bc556449e5bcbc331ef6867d Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0020 Exception Note:EXC_CORPSE_NOTIFY ... Thread 4 Crashed: 0 qemu-system-ppc 0x000109cd26d2 tcg_opt_gen_mov + 178 (optimize.c:212) 1 qemu-system-ppc 0x000109ccf838 tcg_optimize + 5656 2 qemu-system-ppc 0x000109c27600 tcg_gen_code + 64 (tcg.c:4490) 3 qemu-system-ppc 0x000109c17b6d tb_gen_code + 493 (translate-all.c:1952) 4 qemu-system-ppc 0x000109c16085 tb_find + 41 (cpu-exec.c:454) [inlined] 5 qemu-system-ppc 0x000109c16085 cpu_exec + 2117 (cpu-exec.c:810) 6 qemu-system-ppc 0x000109c09ac3 tcg_cpus_exec + 35 (tcg-cpus.c:57) 7 qemu-system-ppc 0x000109c75edd rr_cpu_thread_fn + 445 (tcg-cpus-rr.c:217) 8 qemu-system-ppc 0x000109e41fae qemu_thread_start + 126 (qemu-thread-posix.c:521) 9 libsystem_pthread.dylib 0x7fff2038e950 _pthread_start + 224 10 libsystem_pthread.dylib 0x7fff2038a47b thread_start + 15 Here the crash is in tcg/optimize.c line 212: mask = si->mask; "si" is NULL. The NULL value arises from tcg/optimize.c line 198: si = ts_info(src_ts); I did not attempt to determine the root cause of this issue, however. It clearly is related to the "tcg/optimize" changes in this commit. The previous commit c0dd6654f207810b16a75b673258f5ce2ceffbf0 doesn't crash. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1912065/+subscriptions
[Bug 1915925] Re: ARM semihosting HEAPINFO results wrote to wrong address
** 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/1915925 Title: ARM semihosting HEAPINFO results wrote to wrong address Status in QEMU: Fix Released Bug description: This affects latest development branch of QEMU. According to the ARM spec of the HEAPINFO semihosting call: https://developer.arm.com/documentation/100863/0300/Semihosting- operations/SYS-HEAPINFO--0x16-?lang=en > the PARAMETER REGISTER contains the address of a pointer to a four- field data block. However, QEMU treated the PARAMETER REGISTER as pointing to a four- field data block directly. Here is a simple program that can demonstrate this problem: https://github.com/iNvEr7/qemu-learn/tree/newlib-bug/semihosting- newlib This code links with newlib with semihosting mode, which will call the HEAPINFO SVC during crt0 routine. When running in QEMU (make run), it may crash the program either because of invalid write or memory curruption, depending on the compiled program structure. Also refer to my discussion with newlib folks: https://sourceware.org/pipermail/newlib/2021/018260.html To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1915925/+subscriptions
[Bug 1908551] Re: aarch64 SVE emulation breaks strnlen and strrchr
https://gitlab.com/qemu-project/qemu/-/commit/70acaafef2e053a3
** 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/1908551
Title:
aarch64 SVE emulation breaks strnlen and strrchr
Status in QEMU:
Fix Released
Bug description:
arm optimized-routines have sve string functions with test code.
the test worked up until recently: with qemu-5.2.0 i see
$ qemu-aarch64 build/bin/test/strnlen
PASS strnlen
PASS __strnlen_aarch64
__strnlen_aarch64_sve (0x490fa0, 32) len 32 returned 64, expected 32
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80"
__strnlen_aarch64_sve (0x490fa0, 32) len 33 returned 64, expected 32
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a"
__strnlen_aarch64_sve (0x490fa0, 33) len 33 returned 64, expected 33
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a"
__strnlen_aarch64_sve (0x490fa0, 32) len 34 returned 64, expected 32
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab"
__strnlen_aarch64_sve (0x490fa0, 33) len 34 returned 64, expected 33
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab"
__strnlen_aarch64_sve (0x490fa0, 34) len 34 returned 64, expected 34
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab"
__strnlen_aarch64_sve (0x490fa0, 32) len 35 returned 64, expected 32
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80a\x00c"
__strnlen_aarch64_sve (0x490fa0, 33) len 35 returned 64, expected 33
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80ab\x00"
__strnlen_aarch64_sve (0x490fa0, 34) len 35 returned 64, expected 34
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc"
__strnlen_aarch64_sve (0x490fa0, 35) len 35 returned 64, expected 35
input: "abcdefghijklmnopqrstuvwxyz\{|}~\x7f\x80abc"
FAIL __strnlen_aarch64_sve
however the test passes with
qemu-aarch64 -cpu max,sve-max-vq=2
there should be nothing vector length specific in the code.
i haven't debugged it further, to reproduce the issue clone
https://github.com/ARM-software/optimized-routines
and run 'make build/bin/test/strnlen' with a config.mk like
SUBS = string
ARCH = aarch64
CROSS_COMPILE = aarch64-none-linux-gnu-
CC = $(CROSS_COMPILE)gcc
CFLAGS = -std=c99 -pipe -O3
CFLAGS += -march=armv8.2-a+sve
EMULATOR = qemu-aarch64
(native compilation works too, and you can run 'make check' to
run all string tests) this will build a static linked executable
into build/bin/test. if you want a smaller test case edit
string/test/strnlen.c
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1908551/+subscriptions
[Bug 1907137] Re: LDTR not properly emulated when MTE tag checks enabled at EL0
https://gitlab.com/qemu-project/qemu/-/commit/cc97b0019bb590b9b3c ** 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/1907137 Title: LDTR not properly emulated when MTE tag checks enabled at EL0 Status in QEMU: Fix Released Bug description: I am trying to boot Android (just the non-GUI parts for now) under QEMU with MTE enabled. This can be done by following the instructions here to build the fvp-eng target with MTE support: https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fvpbase/ and launching QEMU with the following command: qemu-system-aarch64 -kernel $ANDROID_PRODUCT_OUT/kernel -initrd $ANDROID_PRODUCT_OUT/combined-ramdisk.img -machine virt,mte=on -cpu max -drive driver=raw,file=$ANDROID_PRODUCT_OUT/system- qemu.img,if=none,id=system -device virtio-blk-device,drive=system -append "console=ttyAMA0 earlyprintk=ttyAMA0 androidboot.hardware=fvpbase androidboot.boot_devices=a003e00.virtio_mmio loglevel=9 printk.devkmsg=on buildvariant=eng" -m 512 -nographic -no-reboot If I do this then QEMU crashes like so: ** ERROR:../target/arm/mte_helper.c:558:mte_check_fail: code should not be reached Bail out! ERROR:../target/arm/mte_helper.c:558:mte_check_fail: code should not be reached The error is caused by an MTE tag check fault from an LDTR instruction in __arch_copy_from_user. At this point TCF=0 and TCF0=2. I have this patch that gets me past the error but it is unclear whether this is the correct fix since there may be other confusion between TCF and TCF0 elsewhere. diff --git a/target/arm/mte_helper.c b/target/arm/mte_helper.c index 153bd1e9df..aa5db4eac4 100644 --- a/target/arm/mte_helper.c +++ b/target/arm/mte_helper.c @@ -552,10 +552,8 @@ static void mte_check_fail(CPUARMState *env, uint32_t desc, case 0: /* * Tag check fail does not affect the PE. - * We eliminate this case by not setting MTE_ACTIVE - * in tb_flags, so that we never make this runtime call. */ -g_assert_not_reached(); +break; case 2: /* Tag check fail causes asynchronous flag set. */ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1907137/+subscriptions
[Bug 1523811] Re: USB assert failure on dev-storage.c
https://gitlab.com/qemu-project/qemu/-/commit/39912c14da07a2d ** 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/1523811 Title: USB assert failure on dev-storage.c Status in QEMU: Fix Released Bug description: On executing the attached python script in the guest OS, QEMU dies with assert failure: [run python script in guest root shell] # python a.py [host message] qemu-system-x86_64: hw/usb/dev-storage.c:445: usb_msd_handle_data: Assertion `le32_to_cpu(s->csw.residue) == 0' failed. Aborted (core dumped) When I detach the kernel driver and send CBW and reattach it again, without conforming to the command/data/status protocol, QEMU dies. I think this is due to misimplementation of Command/Data/Status protocol in Bulk-only transfer. This kind of assert failure can be misused by malwares to avoid being analyzed by terminating only in the virtual environments and still execute the malicious code in real machines. Before running python script, make sure to change a.py that it should points to usb mass storage's vid and pid. QEMU was running on these environment : [CPU model]Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz [qemu version] QEMU 2.5.0-rc2 (compiled from source, gcc 4.8.4) [host info]Ubuntu 14.04.3, x86_64, 3.19.0-32-generic [guest info] Ubuntu 14.04.3, x86_64, 3.19.0-28-generic [QEMU argument] x86_64-softmmu/qemu-system-x86_64 -hda /media/hdd/img/ubuntu1404.qcow2.5 \ -m 512 \ --usbdevice disk:format=qcow2:../usb.img.5 \ --enable-kvm To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1523811/+subscriptions
[Bug 1614609] Re: alphabetical order of monitor options
** 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/1614609 Title: alphabetical order of monitor options Status in QEMU: Fix Released Bug description: Looking for the 'continue'/'resume' option I found this order that was not quite 'alphabetical'. It had me overlook the 'cont' option at glance. Which is just a little impractical. ... boot_set bootdevice -- define new values for the boot device list change device filename [format [read-only-mode]] -- change a removable medium, optional format chardev-add args -- add chardev chardev-remove id -- remove chardev client_migrate_info protocol hostname port tls-port cert-subject -- set migration information for remote display closefd closefd name -- close a file descriptor previously passed via SCM rights commit device|all -- commit changes to the disk images (if -snapshot is used) or backing files cpu index -- set the default CPU cpu-add id -- add cpu c|cont -- resume emulation delvm tag|id -- delete a VM snapshot from its tag or id ... I tested this list with 'sort' just to make sure and make a point: $ cat Desktop/order-orig.txt boot_set change chardev-add chardev-remove client_migrate_info closefd commit cpu cpu-add c|cont delvm $ cat Desktop/order-orig.txt | sort boot_set c|cont change chardev-add chardev-remove client_migrate_info closefd commit cpu cpu-add delvm $ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1614609/+subscriptions
[Bug 1294227] Re: migration wrong handling of KVM_GET_DIRTY_LOG ioctl
** 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/1294227
Title:
migration wrong handling of KVM_GET_DIRTY_LOG ioctl
Status in QEMU:
Fix Released
Bug description:
In the code below kvm_vm_ioctl(...) can return --errno != -1 from ioctl call,
but return only checks for -1.
Found during KVM-ARM migration which apperead to go through but was actually
failing getting
memslot dirty bitmap.
static int kvm_physical_sync_dirty_bitmap()
{
if(kvm_vm_ioctl(s, KVM_GET_DIRTY_LOG, &d) == -1) {
- err out
}
... continue
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1294227/+subscriptions
[Bug 1913341] Re: Chardev behavior breaks polling based devices
commit f2c0fb93a44972a96f93510311c93ff4c2c6fab5 ** 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/1913341 Title: Chardev behavior breaks polling based devices Status in QEMU: Fix Released Bug description: Currently in latest QEMU (9cd69f1a270235b652766f00b94114f48a2d603f at this time) the behavior of chardev sources is that when processed (before IO polling occurs), the chardev source will check the amount of space for reading. If it reports more than 0 bytes available to accept the read and a callback is not set, the code will set a child source connected to the QIOChannel submitted to the original source. If there's no buffer space reported, it will check for an active source, if registered it will detach this source. Next time the loop fires, if the buffer now reports space (most likely the guest has run, emptying some bytes from the buffer), it will setup the callback again. However, if we have a stupid simple device (or driver) that doesn't have buffers big enough to fit an available write when one is sent (say a single byte buffer, polled serial port), then the poll will be set, the poll will occur and return quickly, then the callback will (depending on the backend chardev used) most likely read the 1 byte it has space for from the source, push it over to the frontend hardware side, and the IO loop will run again. Most likely the guest will not clear this byte before the next io loop cycle, meaning that the next prepare call on the source will see a full buffer in the guest and remove the poll for the data source, to allow the guest time to run to clear the buffer. Except, without a poll or a timeout set, the io loop might now block forever, since there's no report from the guest after clearing that buffer. This only returns in a sane amount of time because often some other device/timer is scheduled which sets a timeout on the poll to a reasonable time. I don't have a simple submittable bit of code to replicate at the moment but connecting a serial port to a pty then writing a large amount of data, while a guest that doesn't enable the fifo spins on an rx ready register, you can observe that RX on the guest takes anywhere from 1s to forever per byte. This logic all occurs in chardev/char-io.c Fixing this can be as simple as removing the logic to detach the child event source and changing the attach logic to only occur if there's buffer space and the poll isn't already setup. That fix could cause flow control issues potentially if the io runs on the same thread as the emulated guest (I am not sure about the details of this) and the guest is in a tight loop doing the poll. I don't see that as happening but the logic might be there for a reason. Another option is to set a timeout when the source gets removed, forcing the poll to exit with a fixed delay, this delay could potentially be derived from something like the baud rate set, forcing a minimum time before forward progress. If removing the logic isn't an option, another solution is to make the emulated hardware code itself kick the IO loop and trigger it to reschedule the poll. Similar to how the non-blocking write logic works, the read logic could recognize when the buffer has been emptied and reschedule the hw on the guest. In theory this sounds nice, but for it to work would require adding logic to all the emulated chardev frontends and in reality would likely be going through the effort to remove the callback only to within a few nanoseconds potentially want to add it back. I'm planning to submit a patch with just outright removing the logic, but am filing this bug as a place to reference since tracking down this problem is non-obvious. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1913341/+subscriptions
[Bug 1916501] Re: qemu-img convert segfaults with specific URL
https://gitlab.com/qemu-project/qemu/-/commit/0f418a207696b37f05d ** 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/1916501 Title: qemu-img convert segfaults with specific URL Status in QEMU: Fix Released Bug description: Using what is currently the latest git: (commit 00d8ba9e0d62ea1c7459c25aeabf9c8bb7659462, Date: Sun Feb 21 19:52:58 2021 +) $ ./build/qemu-img convert -f qcow2 -O raw https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img out.img Segmentation fault (core dumped) Backtrace for convenience: qemu: qemu_mutex_lock_impl: Invalid argument Thread 1 "qemu-img" received signal SIGABRT, Aborted. 0x777c59d5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x777c59d5 in raise () from /lib64/libc.so.6 #1 0x777ae8a4 in abort () from /lib64/libc.so.6 #2 0x556705b2 in error_exit (err=, msg=msg@entry=0x556b69a0 <__func__.31> "qemu_mutex_lock_impl") at ../util/qemu-thread-posix.c:37 #3 0x55670945 in qemu_mutex_lock_impl (mutex=0x55ae3758, file=0x556827a2 "../block/curl.c", line=406) at ../util/qemu-thread-posix.c:81 #4 0x5559a05b in curl_multi_do (arg=0x55aad2a0) at ../block/curl.c:406 #5 0x5566193a in aio_dispatch_handler (ctx=ctx@entry=0x55737790, node=0x55b14150) at ../util/aio-posix.c:329 #6 0x55662072 in aio_dispatch_handlers (ctx=0x55737790) at ../util/aio-posix.c:372 #7 aio_dispatch (ctx=0x55737790) at ../util/aio-posix.c:382 #8 0x5564442e in aio_ctx_dispatch (source=, callback=, user_data=) at ../util/async.c:306 #9 0x77cfda9f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #10 0x5566f2c8 in glib_pollfds_poll () at ../util/main-loop.c:232 #11 os_host_main_loop_wait (timeout=439700) at ../util/main-loop.c:255 #12 main_loop_wait (nonblocking=nonblocking@entry=0) at ../util/main-loop.c:531 #13 0x55581edd in convert_do_copy (s=0x7fffd3a0) at ../qemu-img.c:2139 #14 img_convert (argc=, argv=) at ../qemu-img.c:2738 #15 0x555783b1 in main (argc=7, argv=) at ../qemu-img.c:5536 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1916501/+subscriptions
[Bug 1914236] Re: QEMU: scsi: use-after-free in mptsas_process_scsi_io_request() of mptsas1068 emulator
** 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/1914236 Title: QEMU: scsi: use-after-free in mptsas_process_scsi_io_request() of mptsas1068 emulator Status in QEMU: Fix Released Bug description: * Cheolwoo Myung of Seoul National University reported a use-after-free issue in the SCSI Megaraid emulator of the QEMU. * It occurs while handling mptsas_process_scsi_io_request(), as it does not check a list in s->pending. * This was found in version 5.2.0 (master) ==31872==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000107568 at pc 0x564514950c7c bp 0x7fff524ef4b0 sp 0x7fff524ef4a0 WRITE of size 8 at 0x60c000107568 thread T0 #0 0x564514950c7b in mptsas_process_scsi_io_request ../hw/scsi/mptsas.c:306 #1 0x564514950c7b in mptsas_fetch_request ../hw/scsi/mptsas.c:775 #2 0x564514950c7b in mptsas_fetch_requests ../hw/scsi/mptsas.c:790 #3 0x56451585c25d in aio_bh_poll ../util/async.c:164 #4 0x5645158d7e7d in aio_dispatch ../util/aio-posix.c:381 #5 0x56451585be2d in aio_ctx_dispatch ../util/async.c:306 #6 0x7f1cc8af4416 in g_main_context_dispatch (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x4c416) #7 0x56451583f059 in glib_pollfds_poll ../util/main-loop.c:221 #8 0x56451583f059 in os_host_main_loop_wait ../util/main-loop.c:244 #9 0x56451583f059 in main_loop_wait ../util/main-loop.c:520 #10 0x56451536b181 in qemu_main_loop ../softmmu/vl.c:1537 #11 0x5645143ddd3d in main ../softmmu/main.c:50 #12 0x7f1cc2650b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96) #13 0x5645143eece9 in _start (/home/cwmyung/prj/hyfuzz/src/qemu-repro/build/qemu-system-i386+0x1d55ce9) 0x60c000107568 is located 104 bytes inside of 120-byte region [0x60c000107500,0x60c000107578) freed by thread T0 here: #0 0x7f1cca9777a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) #1 0x56451495008b in mptsas_process_scsi_io_request ../hw/scsi/mptsas.c:358 #2 0x56451495008b in mptsas_fetch_request ../hw/scsi/mptsas.c:775 #3 0x56451495008b in mptsas_fetch_requests ../hw/scsi/mptsas.c:790 #4 0x7fff524ef8bf () previously allocated by thread T0 here: #0 0x7f1cca977d28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7f1cc8af9b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10) #2 0x7fff524ef8bf () SUMMARY: AddressSanitizer: heap-use-after-free ../hw/scsi/mptsas.c:306 in mptsas_process_scsi_io_request Shadow bytes around the buggy address: 0x0c1880018e50: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c1880018e60: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa 0x0c1880018e70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c1880018e80: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd 0x0c1880018e90: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa =>0x0c1880018ea0: fd fd fd fd fd fd fd fd fd fd fd fd fd[fd]fd fa 0x0c1880018eb0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c1880018ec0: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa 0x0c1880018ed0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1880018ee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c1880018ef0: 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 ==31872==ABORTING To reproduce this issue, please run the QEMU with the following command line. # To enable ASan option, please set configuration with the following command $ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers $ make # To reproduce this issue, please run the QEMU process with the following command line. $ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device mptsas1068,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1914236/+subscriptions
[Bug 1913344] Re: Exynos4210 UART peripheral data loss
commit 40b4c2ae90e4f864a1015ff748a4af00518ff0c0 ** 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/1913344 Title: Exynos4210 UART peripheral data loss Status in QEMU: Fix Released Bug description: Currently the Exynos4210 UART (hw/char/exynos4210_uart.c) incorrectly reports however many empty bytes are available in the FIFO when queried for receive capacity. However this peripheral supports a polled mode where only a single byte can be submitted at a time and the FIFO is unused, meaning that in polled mode data is lost since it's written into the FIFO and the polling code in FIFO disabled mode only returns the value in the RX data register. Even worse, potentially enabling the FIFO without a FIFO reset will create a weird situation where data is already in the FIFO whenever data came in faster than the polling could pick it up (which is basically always). This change obscured the issue in https://bugs.launchpad.net/qemu/+bug/1913341, which instead presented as strange data loss until I locally resolved this issue. I have a patch ready for the bug and will submit it later today, I'm just filing for clarity. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1913344/+subscriptions
[Bug 1912846] Re: Assertion hit on hot-unplugging virtio iommu enabled device
Fixed here:
https://gitlab.com/qemu-project/qemu/-/commit/f6ab64c05f8a6229bf6
** 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/1912846
Title:
Assertion hit on hot-unplugging virtio iommu enabled device
Status in QEMU:
Fix Released
Bug description:
From commit ("2d24a646 device-core: use RCU for
list of children of a bus") an assertion is hit when
removing a iommu aware virtio device, since as->listeners
are not properly removed. To reproduce:
/home/qemu/build/x86_64-softmmu/qemu-system-x86_64 -qmp
tcp:0:,server,nowait ... \
-netdev tap,id=hostnet0,vhostforce=on,vhost=on \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:14:18:cc,bus=pci.1,addr=0x0,iommu_platform=on,ats=on
In QMP:
{'execute': 'qmp_capabilities'}
{"execute": "device_del", "arguments": {"id": "net0"} }
And crash:
../softmmu/memory.c:2818: do_address_space_destroy: Assertion
`QTAILQ_EMPTY(&as->listeners)' failed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1912846/+subscriptions
[Bug 1910723] Re: NULL pointer dereference issues in am53c974 SCSI host bus adapter
** 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/1910723 Title: NULL pointer dereference issues in am53c974 SCSI host bus adapter Status in QEMU: Fix Released Bug description: Two NULL pointer dereference issues were found in the am53c974 SCSI host bus adapter emulation of QEMU. They could occur while handling the 'Information Transfer' command (CMD_TI) in function handle_ti() in hw/scsi/esp.c, and could be abused by a malicious guest to crash the QEMU process on the host resulting in a denial of service. Both issues were reported by Cheolwoo Myung (Seoul National University). To reproduce them, configure and run QEMU as follows. Please find attached the required disk images. $ ./configure --target-list=x86_64-softmmu --enable-kvm --enable-sanitizers $ make $ ./qemu-system-x86_64 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ -device am53c974,id=scsi -device scsi-hd,drive=SysDisk \ -drive id=SysDisk,if=none,file=./disk.img Additional info: RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1909766 RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1909769 ASAN logs: ==672133== hw/scsi/scsi-bus.c:1385:12: runtime error: member access within null pointer of type 'struct SCSIRequest' AddressSanitizer:DEADLYSIGNAL = ==672133==ERROR: AddressSanitizer: SEGV on unknown address 0x0171 (pc 0x55bd63e20b85 bp 0x7f4b6fffdfa0 sp 0x7f4b6fffdf70 T7) ==672133==The signal is caused by a READ memory access. ==672133==Hint: address points to the zero page. #0 0x55bd63e20b85 in scsi_req_continue hw/scsi/scsi-bus.c:1385 #1 0x55bd63ab34fb in esp_do_dma hw/scsi/esp.c:453 #2 0x55bd63ab4b3c in handle_ti hw/scsi/esp.c:549 #3 0x55bd63ab72a9 in esp_reg_write hw/scsi/esp.c:691 #4 0x55bd63d7b5dd in esp_pci_io_write hw/scsi/esp-pci.c:206 #5 0x55bd645d55a3 in memory_region_write_accessor softmmu/memory.c:491 #6 0x55bd645d5a24 in access_with_adjusted_size softmmu/memory.c:552 #7 0x55bd645e2baa in memory_region_dispatch_write softmmu/memory.c:1501 #8 0x55bd646b75ff in flatview_write_continue softmmu/physmem.c:2759 #9 0x55bd646b79d1 in flatview_write softmmu/physmem.c:2799 #10 0x55bd646b8341 in address_space_write softmmu/physmem.c:2891 #11 0x55bd646b83f9 in address_space_rw softmmu/physmem.c:2901 #12 0x55bd648c4736 in kvm_handle_io accel/kvm/kvm-all.c:2285 #13 0x55bd648c69c8 in kvm_cpu_exec accel/kvm/kvm-all.c:2531 #14 0x55bd647b2413 in kvm_vcpu_thread_fn accel/kvm/kvm-cpus.c:49 #15 0x55bd64f560de in qemu_thread_start util/qemu-thread-posix.c:521 #16 0x7f4b981763f8 in start_thread (/lib64/libpthread.so.0+0x93f8) #17 0x7f4b980a3902 in __GI___clone (/lib64/libc.so.6+0x101902) --- ==672020== hw/scsi/esp.c:196:62: runtime error: member access within null pointer of type 'struct SCSIDevice' AddressSanitizer:DEADLYSIGNAL = ==672020==ERROR: AddressSanitizer: SEGV on unknown address 0x0098 (pc 0x559bc99946fd bp 0x7f08bd737fb0 sp 0x7f08bd737f70 T7) ==672020==The signal is caused by a READ memory access. ==672020==Hint: address points to the zero page. #0 0x559bc99946fd in do_busid_cmd hw/scsi/esp.c:196 #1 0x559bc9994e71 in do_cmd hw/scsi/esp.c:220 #2 0x559bc999ae81 in handle_ti hw/scsi/esp.c:555 #3 0x559bc999d2a9 in esp_reg_write hw/scsi/esp.c:691 #4 0x559bc9c615dd in esp_pci_io_write hw/scsi/esp-pci.c:206 #5 0x559bca4bb5a3 in memory_region_write_accessor softmmu/memory.c:491 #6 0x559bca4bba24 in access_with_adjusted_size softmmu/memory.c:552 #7 0x559bca4c8baa in memory_region_dispatch_write softmmu/memory.c:1501 #8 0x559bca59d5ff in flatview_write_continue softmmu/physmem.c:2759 #9 0x559bca59d9d1 in flatview_write softmmu/physmem.c:2799 #10 0x559bca59e341 in address_space_write softmmu/physmem.c:2891 #11 0x559bca59e3f9 in address_space_rw softmmu/physmem.c:2901 #12 0x559bca7aa736 in kvm_handle_io accel/kvm/kvm-all.c:2285 #13 0x559bca7ac9c8 in kvm_cpu_exec accel/kvm/kvm-all.c:2531 #14 0x559bca698413 in kvm_vcpu_thread_fn accel/kvm/kvm-cpus.c:49 #15 0x559bcae3c0de in qemu_thread_start util/qemu-thread-posix.c:521 #16 0x7f08e57ba3f8 in start
Re: [PATCH v2] monitor: hmp_qemu_io: acquire aio contex, fix crash
On 23.04.21 15:42, Vladimir Sementsov-Ogievskiy wrote:
Max reported the following bug:
$ ./qemu-img create -f raw src.img 1G
$ ./qemu-img create -f raw dst.img 1G
$ (echo '
{"execute":"qmp_capabilities"}
{"execute":"blockdev-mirror",
"arguments":{"job-id":"mirror",
"device":"source",
"target":"target",
"sync":"full",
"filter-node-name":"mirror-top"}}
'; sleep 3; echo'
{"execute":"human-monitor-command",
"arguments":{"command-line":
"qemu-io mirror-top \"write 0 1G\""}}') \
| x86_64-softmmu/qemu-system-x86_64 \
-qmp stdio \
-blockdev file,node-name=source,filename=src.img \
-blockdev file,node-name=target,filename=dst.img \
-object iothread,id=iothr0 \
-device virtio-blk,drive=source,iothread=iothr0
crashes:
0 raise () at /usr/lib/libc.so.6
1 abort () at /usr/lib/libc.so.6
2 error_exit
(err=,
msg=msg@entry=0x55fbb1634790 <__func__.27> "qemu_mutex_unlock_impl")
at ../util/qemu-thread-posix.c:37
3 qemu_mutex_unlock_impl
(mutex=mutex@entry=0x55fbb25ab6e0,
file=file@entry=0x55fbb1636957 "../util/async.c",
line=line@entry=650)
at ../util/qemu-thread-posix.c:109
4 aio_context_release (ctx=ctx@entry=0x55fbb25ab680) at ../util/async.c:650
5 bdrv_do_drained_begin
(bs=bs@entry=0x55fbb3a87000, recursive=recursive@entry=false,
parent=parent@entry=0x0,
ignore_bds_parents=ignore_bds_parents@entry=false,
poll=poll@entry=true) at ../block/io.c:441
6 bdrv_do_drained_begin
(poll=true, ignore_bds_parents=false, parent=0x0, recursive=false,
bs=0x55fbb3a87000) at ../block/io.c:448
7 blk_drain (blk=0x55fbb26c5a00) at ../block/block-backend.c:1718
8 blk_unref (blk=0x55fbb26c5a00) at ../block/block-backend.c:498
9 blk_unref (blk=0x55fbb26c5a00) at ../block/block-backend.c:491
10 hmp_qemu_io (mon=0x7fffaf3fc7d0, qdict=)
at ../block/monitor/block-hmp-cmds.c:628
man pthread_mutex_unlock
...
EPERM The mutex type is PTHREAD_MUTEX_ERRORCHECK or
PTHREAD_MUTEX_RECURSIVE, or the mutex is a robust mutex, and the
current thread does not own the mutex.
So, thread doesn't own the mutex. And we have iothread here.
Next, note that AIO_WAIT_WHILE() documents that ctx must be acquired
exactly once by caller. But where is it acquired in the call stack?
Seems nowhere.
qemuio_command do acquire aio context.. But we need context acquired
around blk_unref() as well and actually around blk_insert_bs() too.
Let's refactor qemuio_command so that it doesn't acquire aio context
but callers do that instead. This way we can cleanly acquire aio
context in hmp_qemu_io() around all three calls.
Reported-by: Max Reitz
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
v2: rewrite, to cleanly acquire aio-context around all needed things in
hmp_qemu_io
block/monitor/block-hmp-cmds.c | 31 +--
qemu-io-cmds.c | 8
qemu-io.c | 17 +++--
3 files changed, 40 insertions(+), 16 deletions(-)
Thanks, applied to my block branch:
https://github.com/XanClic/qemu/commits/block
(With the change below:)
diff --git a/qemu-io-cmds.c b/qemu-io-cmds.c
index 97611969cb..19149e014d 100644
--- a/qemu-io-cmds.c
+++ b/qemu-io-cmds.c
@@ -2457,9 +2457,12 @@ static const cmdinfo_t help_cmd = {
.oneline= "help for one or all commands",
};
+/*
+ * Called with aio context of blk acquired. Or with qemu_get_aio_context()
+ * context acquired if no blk is NULL.
-no
+ */
int qemuio_command(BlockBackend *blk, const char *cmd)
{
-AioContext *ctx;
char *input;
const cmdinfo_t *ct;
char **v;
[Bug 1911666] Re: ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU Privilege Escalation Vulnerability
** 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/1911666 Title: ZDI-CAN-10904: QEMU Plan 9 File System TOCTOU Privilege Escalation Vulnerability Status in QEMU: Fix Released Bug description: -- CVSS - 7.5: AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H -- ABSTRACT - Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: QEMU - QEMU -- VULNERABILITY DETAILS Version tested:5.0.0-rc3 Installer file:qemu-5.0.0-rc3.tar.xz Platform tested:ubuntu 18.04 x64 desktop Analysis Basically v9fs* functions called from guest kernel are executed under specific thread(I call it main thread later). But when it calls some file related system calls, qemu uses its own coroutine thread(worker thread). Then it returns(yield return) without waiting result of system call and start to execute next v9fs* function. In v9fsmarkfidsunreclaim() function, it stores fidlist member (head of singly linked list) to its stack. -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L506 And if it uses coroutine, it restore fid_list from stack and restart whole loop. -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L526 v9fsclunk() function calls clunkfid() which unlink fid from list, and free it. -> https://github.com/qemu/qemu/blob/f3bac27cc1e303e1860cc55b9b6889ba39dee587/hw/9pfs/9p.c#L2060-L2091 So if v9fsclunk() is called while v9fsmarkfidsunreclaim()'s coroutine is being executed, it restores "FREED" fidp from stack and use it. it can be reproduced with the qemu binary, which is given it can also be reproduced with own ASAN build (5.0.0-rc3 and 4.2.0 are tested) ../qemu-5.0.0-rc3/x86_64-softmmu/qemu-system-x86_64 -M pc -kernel ./bzImage -initrd ./rootfs.cpio -append "root=/dev/ram console=tty1 console=ttyS0 rdinit=/bin/sh" -nographic -enable-kvm -fsdev local,id=test_dev,path=/home/xxx/sandbox,security_model=none -device virtio-9p-pci,fsdev=test_dev,mount_tag=victim_tag $ ./do.sh expected ASAN report is printed the race is in coroutine, so the threads are the same one = ==46645==ERROR: AddressSanitizer: heap-use-after-free on address 0x61047948 at pc 0x5563d8c28f0f bp0 READ of size 2 at 0x61047948 thread T0 #0 0x5563d8c28f0e in v9fs_mark_fids_unreclaim hw/9pfs/9p.c:508 #1 0x5563d8c3e9e3 in v9fs_remove hw/9pfs/9p.c:2988 #2 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 #3 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) 0x61047948 is located 8 bytes inside of 192-byte region [0x61047940,0x61047a00) freed by thread T0 here: #0 0x7fadafa5f7a8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7a8) #1 0x5563d8c27a60 in free_fid hw/9pfs/9p.c:371 #2 0x5563d8c27fcc in put_fid hw/9pfs/9p.c:396 #3 0x5563d8c37267 in v9fs_clunk hw/9pfs/9p.c:2085 #4 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 #5 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) previously allocated by thread T0 here: #0 0x7fadafa5fd28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28) #1 0x7fadaf0c8b10 in g_malloc0 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x51b10) #2 0x5563d8c30ecc in v9fs_attach hw/9pfs/9p.c:1412 #3 0x5563d98d310d in coroutine_trampoline util/coroutine-ucontext.c:115 #4 0x7fadac6396af (/lib/x86_64-linux-gnu/libc.so.6+0x586af) This vulnerability was discovered by: Ryota Shiga(@Garyo) of Flatt Security working with Trend Micro Zero Day Initiative To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1911666/+subscriptions
[Bug 1906193] Re: riscv32 user mode emulation: fork return values broken
** 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/1906193
Title:
riscv32 user mode emulation: fork return values broken
Status in QEMU:
Fix Released
Bug description:
When running in a chroot with riscv32 (on x86_64; qemu git master as
of today):
The following short program forks; the child immediately returns with
exit(42). The parent checks for the return value - and obtains 40!
gcc-10.2
===
#include
#include
#include
#include
main(c, v)
int c;
char **v;
{
pid_t pid, p;
int s, i, n;
s = 0;
pid = fork();
if (pid == 0)
exit(42);
/* wait for the process */
p = wait(&s);
if (p != pid)
exit (255);
if (WIFEXITED(s))
{
int r=WEXITSTATUS(s);
if (r!=42) {
printf("child wants to return %i (0x%X), parent received %i (0x%X),
difference %i\n",42,42,r,r,r-42);
}
}
}
===
(riscv-ilp32 chroot) farino /tmp # ./wait-test-short
child wants to return 42 (0x2A), parent received 40 (0x28), difference -2
===
(riscv-ilp32 chroot) farino /tmp # gcc --version
gcc (Gentoo 10.2.0-r1 p2) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für MARKTGÄNGIGKEIT oder FÜR SPEZIELLE ZWECKE.
(riscv-ilp32 chroot) farino /tmp # ld --version
GNU ld (Gentoo 2.34 p6) 2.34.0
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1906193/+subscriptions
[Bug 1715203] Re: Maintain Haiku support
** 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/1715203 Title: Maintain Haiku support Status in QEMU: Fix Released Bug description: It was pointed out that the 2.10 release notes are pushing to drop Haiku support. The qemu port is currently working as-is under Haiku. Was there a reason this was recommended? Is there anything Haiku can do to keep it from being dropped? We're working on a docker container to cross-compile rust-lang for Haiku, could this be of some use to qemu when complete? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1715203/+subscriptions
Re: [PATCH v2] vhost-user-blk: Fail gracefully on too large queue size
Am 13.04.2021 um 18:56 hat Kevin Wolf geschrieben: > virtio_add_queue() aborts when queue_size > VIRTQUEUE_MAX_SIZE, so > vhost_user_blk_device_realize() should check this before calling it. > > Simple reproducer: > > qemu-system-x86_64 \ > -chardev null,id=foo \ > -device vhost-user-blk-pci,queue-size=4096,chardev=foo > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1935014 > Signed-off-by: Kevin Wolf Thanks for the review, applied to the block branch. Kevin
[Bug 1909247] Re: QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c
** 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/1909247 Title: QEMU: use after free vulnerability in esp_do_dma() in hw/scsi/esp.c Status in QEMU: Fix Released Bug description: A use-after-free vulnerability was found in the am53c974 SCSI host bus adapter emulation of QEMU. It could occur in the esp_do_dma() function in hw/scsi/esp.c while handling the 'Information Transfer' command (CMD_TI). A privileged guest user may abuse this flaw to crash the QEMU process on the host, resulting in a denial of service or potential code execution with the privileges of the QEMU process. This issue was reported by Cheolwoo Myung (Seoul National University). Original report: Using hypervisor fuzzer, hyfuzz, I found a use-after-free issue in am53c974 emulator of QEMU enabled ASan. It occurs while transferring information, as it does not check the buffer to be transferred. A malicious guest user/process could use this flaw to crash the QEMU process resulting in DoS scenario. To reproduce this issue, please run the QEMU with the following command line. # To enable ASan option, please set configuration with the following $ ./configure --target-list=i386-softmmu --disable-werror --enable-sanitizers $ make # To reproduce this issue, please run the QEMU process with the following command line $ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw \ -device am53c974,id=scsi -device scsi-hd,drive=SysDisk \ -drive id=SysDisk,if=none,file=./disk.img Please find attached the disk images to reproduce this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1909247/+subscriptions
[Bug 1748296] Re: TCG throws Invalid Opcode when executing x86 BMI shlx instruction
Fix has been included here: https://gitlab.com/qemu-project/qemu/-/commit/51909241d26fe6fe18a ** 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/1748296 Title: TCG throws Invalid Opcode when executing x86 BMI shlx instruction Status in QEMU: Fix Released Bug description: I am unable to use BMI in my project when running under TCG. I narrowed the problem down to incorrect instruction decoding for BMI instructions (which have a 2 byte VEX prefix). The gen_sse function in translate.c reaches the goto label do_0f_38_fx, but b does not equal 0x1f7, 0x2f7, or 0x3f7, so the switch takes the default path and raises an invalid opcode exception. The code executes correctly and passes the test under KVM. I have created a complete repro here: https://github.com/doug65536 /qemu-bmibug The makefile has the following utility targets: debug-kvm: Build and run the VM using KVM and wait for gdbstub attach run: Run the test case with TCG, make fails if the test fails. (It will fail) run-kvm: Run the test case with KVM, make fails if the test fails. (It will succeed) debug: Build and run the VM with TCG and wait for GDB attach attach-gdb: Run GDB and attach to QEMU gdbstub The VM runs with -cpu max. CPUID reports support for BMI, BMI2, and ABM. You can quickly verify the issue by executing `make run-kvm` to confirm that KVM passes, then `make run` to confirm that TCG fails. I believe the bug affects other BMI, BMI2, and ABM instructions, but I have only completely verified incorrect execution of SHLX. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1748296/+subscriptions
[Bug 1919035] Re: Assertion failure in fifo8_pop_buf() through am53c974
** 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/1919035 Title: Assertion failure in fifo8_pop_buf() through am53c974 Status in QEMU: Fix Released Bug description: Hello, Using hypervisor fuzzer, hyfuzz, I found an assertion failure through am53c974 emulator. A malicious guest user/process could use this flaw to abort the QEMU process on the host, resulting in a denial of service. This was found in version 5.2.0 (master, 3f8d1885e4) ``` qemu-system-i386: ../util/fifo8.c:73: fifo8_pop_buf: Assertion `max > 0 && max <= fifo->num' failed. #0 0x70218fb7 in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x7021a921 in __GI_abort () at abort.c:79 #2 0x7020a48a in __assert_fail_base (fmt=0x70391750 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x58ed24a0 "max > 0 && max <= fifo->num", file=file@entry=0x58ed2380 "../util/fifo8.c", line=line@entry=0x49, function=function@entry=0x58ed24e0 <__PRETTY_FUNCTION__.16603> "fifo8_pop_buf") at assert.c:92 #3 0x7020a502 in __GI___assert_fail (assertion=assertion@entry=0x58ed24a0 "max > 0 && max <= fifo->num", file=file@entry=0x58ed2380 "../util/fifo8.c", line=line@entry=0x49, function=function@entry=0x58ed24e0 <__PRETTY_FUNCTION__.16603> "fifo8_pop_buf") at assert.c:101 #4 0x5877519a in fifo8_pop_buf (fifo=fifo@entry=0x61f05200, max=max@entry=0xff, num=num@entry=0x7fff72bfa550) at ../util/fifo8.c:73 #5 0x572b7d9a in do_cmd (s=s@entry=0x61f05088) at ../hw/scsi/esp.c:328 #6 0x572b879a in esp_do_nodma (s=s@entry=0x61f05088) at ../hw/scsi/esp.c:701 #7 0x572bfd79 in handle_ti (s=0x61f05088) at ../hw/scsi/esp.c:848 #8 0x572c419c in esp_reg_write (s=0x61f05088, saddr=saddr@entry=0x3, val=) at ../hw/scsi/esp.c:987 #9 0x57bb916a in esp_pci_io_write (opaque=0x61f04680, addr=, val=, size=) at ../hw/scsi/esp-pci.c:214 #10 0x5817ea28 in memory_region_write_accessor (mr=0x61f04f70, addr=, value=, size=, shift=, mask=, attrs=...) at ../softmmu/memory.c:491 #11 0x58176671 in access_with_adjusted_size (addr=addr@entry=0xc, value=value@entry=0x7fff72bfb2a8, size=size@entry=0x1, access_size_min=, access_size_max=, access_fn= 0x5817e7c0 , mr=0x61f04f70, attrs=...) at ../softmmu/memory.c:552 #12 0x581892aa in memory_region_dispatch_write (mr=mr@entry=0x61f04f70, addr=, data=, data@entry=0x10, op=op@entry=MO_8, attrs=..., attrs@entry=...) at ../softmmu/memory.c:1508 #13 0x58024b66 in address_space_stb (as=, addr=, val=, attrs=..., result=0x0) at /home/cwmyung/prj/hyfuzz/src/qemu-master/memory_ldst.c.inc:382 #14 0x7fff93236d3c in code_gen_buffer () #15 0x57e793bb in cpu_tb_exec (tb_exit=, itb=, cpu=0x62e004b4) at ../accel/tcg/cpu-exec.c:190 #16 0x57e793bb in cpu_loop_exec_tb (tb_exit=, last_tb=, tb=, cpu=0x62e004b4) at ../accel/tcg/cpu-exec.c:673 #17 0x57e793bb in cpu_exec (cpu=cpu@entry=0x62e00400) at ../accel/tcg/cpu-exec.c:798 #18 0x57f5fc5a in tcg_cpus_exec (cpu=cpu@entry=0x62e00400) at ../accel/tcg/tcg-accel-ops.c:68 #19 0x582260af in mttcg_cpu_thread_fn (arg=arg@entry=0x62e00400) at ../accel/tcg/tcg-accel-ops-mttcg.c:70 #20 0x58777b05 in qemu_thread_start (args=) at ../util/qemu-thread-posix.c:521 #21 0x705d26db in start_thread (arg=0x7fff72bff700) at pthread_create.c:463 #22 0x702fb71f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 ``` To reproduce the assertion failure, please run the QEMU with the following command line. ``` $ ./qemu-system-i386 -m 512 -drive file=./hyfuzz.img,index=0,media=disk,format=raw -device am53c974,id=scsi -device scsi-hd,drive=SysDisk -drive id=SysDisk,if=none,file=./disk.img ``` Please let me know if I can provide any further info. Thank you. - Cheolwoo, Myung (Seoul National University) To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1919035/+subscriptions
[Bug 1923693] Re: Lack of architecture in gdbstub makes debugging confusing
Is there still anything left to do here? ** Changed in: qemu Status: Fix Committed => 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/1923693 Title: Lack of architecture in gdbstub makes debugging confusing Status in QEMU: Incomplete Bug description: I spent some quality time debugging GEF and came to a conclusion here: https://github.com/hugsy/gef/issues/598#issuecomment-819174169 tldr; * gdb_arch_name was undefined on riscv * this bug was fixed recently via https://github.com/qemu/qemu/commit/edf647864bdab84ed4b1a4f47ea05be6bb075c69 * An undefined gdb_arch_name results in qemu's gdbstub omitting the xml. * gdb translates a missing as "auto" which breaks a lot of stuff. * tracking down where "auto" comes from is a bit confusing and time consuming. It might be better to report a missing / blank gdb_arch_name as "unknown" instead of omitting the block completely. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1923693/+subscriptions
[Bug 1923689] Re: sig-abort / coredump observed from aio_ctx_finalize
** 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/1923689 Title: sig-abort / coredump observed from aio_ctx_finalize Status in QEMU: Fix Released Bug description: Observing occasional sig-abort based on v5.2.0 (tag) of QEMU. The VMM is configured for Kata use case, launching with a nvdimm/pmem based rootfs, and a set of workloads which are heavily utilizing virtio-fs. Sample qemu-cmdline: /usr/bin/qemu-kata-system-x86_64 -name sandbox-9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c -uuid cd58d78d-ad44-4d26-9eab-66efab3fb23b -machine pc,accel=kvm,kernel_irqchip,nvdimm=on -cpu host,pmu=off -qmp unix:/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/qmp.sock,server,nowait -m 2048M,slots=10,maxmem=386381M -device pci-bridge,bus=pci.0,id=pci-bridge-0,chassis_nr=1,shpc=on,addr=2,romfile= -device virtio-serial-pci,disable-modern=false,id=serial0,romfile=,max_ports=2 -device virtconsole,chardev=charconsole0,id=console0 -chardev socket,id=charconsole0,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/console.sock,server,nowait -device nvdimm,id=nv0,memdev=mem0 -object memory-backend-file,id=mem0,mem-path=/usr/share/kata-containers/kata-containers.img,size=536870912 -object rng-random,id=rng0,filename=/dev/urandom -device virtio-rng-pci,rng=rng0,romfile= -device vhost-vsock-pci,disable-modern=false,vhostfd=3,id=vsock-3054067214,guest-cid=3054067214,romfile= -chardev socket,id=char-770bb156466e8ed5,path=/run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/vhost-fs.sock -device vhost-user-fs-pci,chardev=char-770bb156466e8ed5,tag=kataShared,romfile= -netdev tap,id=network-0,vhost=on,vhostfds=4,fds=5 -device driver=virtio-net-pci,netdev=network-0,mac=9e:ad:0c:d1:58:e0,disable-modern=false,mq=on,vectors=4,romfile= -rtc base=utc,driftfix=slew,clock=host -global kvm-pit.lost_tick_policy=discard -vga none -no-user-config -nodefaults -nographic --no-reboot -daemonize -object memory-backend-file,id=dimm1,size=2048M,mem-path=/dev/shm,share=on -numa node,memdev=dimm1 -kernel /usr/share/kata-containers/vmlinuz -append tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 cryptomgr.notests net.ifnames=0 pci=lastbus=0 root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro ro rootfstype=ext4 quiet systemd.show_status=false panic=1 nr_cpus=32 systemd.unit=kata-containers.target systemd.mask=systemd-networkd.service systemd.mask=systemd-networkd.socket -pidfile /run/vc/vm/9dc314445bbb2cd02e6d30126ea8355a4f8acd36c866ea32171486931dc2b99c/pid -smp 1,cores=1,threads=1,sockets=32,maxcpus=32 From the core file I was able to obtain a backtrace: ``` (gdb) info thread Id Target Id Frame 6Thread 0x7f92feffd700 (LWP 14678) 0x7f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5Thread 0x7f92f700 (LWP 13860) 0x7f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4Thread 0x7f930dcff700 (LWP 13572) 0x7f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3Thread 0x7f92ff7fe700 (LWP 14179) 0x7f93b23a0a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2Thread 0x7f93aed03700 (LWP 13565) 0x7f93b20bfd19 in syscall () from /lib64/libc.so.6 * 1Thread 0x7f93c718dcc0 (LWP 13564) 0x7f93b1ffd3d7 in raise () from /lib64/libc.so.6 (gdb) bt trace No symbol table is loaded. Use the "file" command. (gdb) bt #0 0x7f93b1ffd3d7 in raise () from /lib64/libc.so.6 #1 0x7f93b1ffeac8 in abort () from /lib64/libc.so.6 #2 0x7f93b1ff61a6 in __assert_fail_base () from /lib64/libc.so.6 #3 0x7f93b1ff6252 in __assert_fail () from /lib64/libc.so.6 #4 0x007c6955 in aio_ctx_finalize () #5 0x7f93c64223d1 in g_source_unref_internal () from /lib64/libglib-2.0.so.0 #6 0x7f93c64225f5 in g_source_iter_next () from /lib64/libglib-2.0.so.0 #7 0x7f93c642362d in g_main_context_unref () from /lib64/libglib-2.0.so.0 #8 0x7f93c6425628 in g_main_loop_unref () from /lib64/libglib-2.0.so.0 #9 0x006dbaa0 in iothread_instance_finalize () #10 0x006c01e9 in object_unref () #11 0x006be647 in object_property_del_child () #12 0x0075ad79 in monitor_cleanup () #13 0x00630635 in qemu_cleanup () #14 0x0040fed3 in main () ``` I *think* we're hitting this assert: https://github.com/qemu/qemu/blob/master/util/async.c#L339 based on ``` (gdb) up #4 0x007c6955 in aio_ctx_finalize () ``` The error is re
[Bug 1918302] Re: qemu-system-arm segfaults while servicing SYS_HEAPINFO
The state of this bug is "Fix committed", but the last comments look like there is still work to do ... should this get reset to "New" or can we close this bug now? ** Changed in: qemu Status: Fix Committed => 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/1918302 Title: qemu-system-arm segfaults while servicing SYS_HEAPINFO Status in QEMU: Incomplete Bug description: I compiled QEMU version 5.2.0 from source on Ubuntu 18.04, and tried to use it to run the attached bare-metal Arm hello-world image, using the command line qemu-system-arm -M microbit -semihosting -nographic -device loader,file=hello.hex The result was that qemu-system-arm itself died of a segfault. Compiling it for debugging, the location of the segfault was in target/arm/arm-semi.c, in the case handler for the semihosting call TARGET_SYS_HEAPINFO, on line 1020 which assigns to 'rambase': const struct arm_boot_info *info = env->boot_info; target_ulong rambase = info->loader_start; and the problem seems to be that 'info', aka env->boot_info, is NULL in this context. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1918302/+subscriptions
[Bug 1920672] Re: Compilation fails with "ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)"
** 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/1920672 Title: Compilation fails with "ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)" Status in QEMU: Fix Released Bug description: It compiles until the end and then just: [6102/6103] Linking target qemu-system-alpha [6103/6103] Linking target qemu-system-aarch64 make[1]: Leaving directory '/home/t/.cache/kiss/proc/32129/build/qemu/build' make: *** [GNUmakefile:11: all] Error 2 Attached is the complete log including configure. I can't find why this is happening maybe I have a wrong version of a required library? Any ideas? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1920672/+subscriptions
[Bug 1914696] Re: aarch64: migration failed: Segmentation fault (core dumped)
** 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 the bug report.
https://bugs.launchpad.net/bugs/1914696
Title:
aarch64: migration failed: Segmentation fault (core dumped)
Status in QEMU:
Fix Released
Bug description:
reproduce:
arch: aarch64
source qemu: v4.2.0
destination qemu: 1ed9228f63ea4bcc0ae240365305ee264e9189ce
cmdline:
source:
$ ./aarch64-softmmu/qemu-system-aarch64 -name 'avocado-vt-vm1'
-machine virt-4.2,gic-version=host,graphics=on -nodefaults -m 1024
-smp 2 -cpu 'host' -vnc :10 -enable-kvm -monitor stdio
(qemu)
(qemu) migrate -d tcp:10.19.241.167:888
(qemu) info status
VM status: paused (postmigrate)
destination:
./build/aarch64-softmmu/qemu-system-aarch64 -name 'avocado-vt-vm1' -machine
virt-4.2,gic-version=host,graphics=on -nodefaults -m 1024 -smp 2
-cpu 'host' -vnc :10 -enable-kvm -monitor stdio -incoming
tcp:0:888
QEMU 5.2.50 monitor - type 'help' for more information
(qemu) Segmentation fault (core dumped)
i have bisected and confirmed that the first bad commit is:
[f9506e162c33e87b609549157dd8431fcc732085] target/arm: Remove ARM_FEATURE_VFP*
bisect log:
git bisect log
# bad: [1ed9228f63ea4bcc0ae240365305ee264e9189ce] Merge remote-tracking
branch 'remotes/ericb/tags/pull-nbd-2021-02-02-v2' into staging
git bisect bad 1ed9228f63ea4bcc0ae240365305ee264e9189ce
# good: [b0ca999a43a22b38158a33d3f5881648bb4f] Update version for v4.2.0
release
git bisect good b0ca999a43a22b38158a33d3f5881648bb4f
# bad: [59093cc407cb044c72aa786006a07bd404eb36b9] hw/char: Convert the Ibex
UART to use the registerfields API
git bisect bad 59093cc407cb044c72aa786006a07bd404eb36b9
# bad: [4dabf39592e92d692c6f2a1633571114ae25d843] aspeed/smc: Fix DMA support
for AST2600
git bisect bad 4dabf39592e92d692c6f2a1633571114ae25d843
# good: [93c86fff53a267f657e79ec07dcd04b63882e330] Merge remote-tracking
branch 'remotes/pmaydell/tags/pull-target-arm-20200207' into staging
git bisect good 93c86fff53a267f657e79ec07dcd04b63882e330
# bad: [2ac031d171ccd18c973014d9978b4a63f0ad5fb0] Merge remote-tracking
branch 'remotes/palmer/tags/riscv-for-master-5.0-sf3' into staging
git bisect bad 2ac031d171ccd18c973014d9978b4a63f0ad5fb0
# good: [4036b7d1cd9fb1097a5f4bc24d7d31744256260f] target/arm: Use
isar_feature function for testing AA32HPD feature
git bisect good 4036b7d1cd9fb1097a5f4bc24d7d31744256260f
# good: [002375895c10df40615fc615e2639f49e0c442fe] tests/iotests: be a little
more forgiving on the size test
git bisect good 002375895c10df40615fc615e2639f49e0c442fe
# good: [c695724868ce4049fd79c5a509880dbdf171e744] target/riscv: Emulate TIME
CSRs for privileged mode
git bisect good c695724868ce4049fd79c5a509880dbdf171e744
# good: [f67957e17cbf8fc3cc5d1146a2db2023404578b0] target/arm: Add
isar_feature_aa32_{fpsp_v2, fpsp_v3, fpdp_v3}
git bisect good f67957e17cbf8fc3cc5d1146a2db2023404578b0
# bad: [a1229109dec4375259d3fff99f362405aab7917a] target/arm: Implement
v8.4-RCPC
git bisect bad a1229109dec4375259d3fff99f362405aab7917a
# bad: [906b60facc3d3dd3af56cb1a7860175d805e10a3] target/arm: Add formats for
some vfp 2 and 3-register insns
git bisect bad 906b60facc3d3dd3af56cb1a7860175d805e10a3
# good: [c52881bbc22b50db99a6c37171ad3eea7d959ae6] target/arm: Replace
ARM_FEATURE_VFP4 with isar_feature_aa32_simdfmac
git bisect good c52881bbc22b50db99a6c37171ad3eea7d959ae6
# good: [f0f6d5c81be47d593e5ece7f06df6fba4c15738b] target/arm: Move the vfp
decodetree calls next to the base isa
git bisect good f0f6d5c81be47d593e5ece7f06df6fba4c15738b
# bad: [f9506e162c33e87b609549157dd8431fcc732085] target/arm: Remove
ARM_FEATURE_VFP*
git bisect bad f9506e162c33e87b609549157dd8431fcc732085
# good: [bfa8a370d2f5d4ed03f7a7e2987982f15fe73758] linux-user/arm: Replace
ARM_FEATURE_VFP* tests for HWCAP
git bisect good bfa8a370d2f5d4ed03f7a7e2987982f15fe73758
# first bad commit: [f9506e162c33e87b609549157dd8431fcc732085] target/arm:
Remove ARM_FEATURE_VFP*
the root cause is that, some feature bit is not consistent any more with
below changes in this commit:
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index b29b0eddfc..05aa9711cd 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1880,7 +1880,6 @@ QEMU_BUILD_BUG_ON(ARRAY_SIZE(((ARMCPU *)0)->ccsidr) <=
R_V7M_CSSELR_INDEX_MASK);
* mapping in linux-user/elfload.c:get_elf_hwcap().
*/
enum arm_features {
-ARM_FEATURE_VFP,
ARM_FEATURE_AUXCR, /* ARM1026 Auxiliary control register. */
ARM_FEATURE_XSCALE, /* Intel XScale extensions. */
ARM_FEATURE_IWMMXT, /* Intel iwMMXt extension. */
@@ -1889,7 +1888,6 @@ enum arm_features {
ARM_FEATURE_V7,
ARM_FEATURE_THUMB2,
ARM_FEATURE_PMSA, /* no MMU; may h
[Bug 1909256] Re: compile failure if gnutls headers not on default include path
** 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/1909256 Title: compile failure if gnutls headers not on default include path Status in QEMU: Fix Released Bug description: If the gnutls headers are not on the default compiler include path, then configure correctly finds them and config-host.mak sets up the variables: GNUTLS_CFLAGS=-I/opt/homebrew/Cellar/gnutls/3.6.15/include -I/opt/homebrew/Cellar/nettle/3.6/include -I/opt/homebrew/Cellar/libtasn1/4.16.0/include -I/opt/homebrew/Cellar/libidn2/2.3.0/include -I/opt/homebrew/Cellar/p11-kit/0.23.22/include/p11-kit-1 GNUTLS_LIBS=-L/opt/homebrew/Cellar/gnutls/3.6.15/lib -lgnutls but meson fails to put GNUTLS_CFLAGS in the compiler arguments and so you get compile failures like: [2/1865] Compiling C object qemu-nbd.p/qemu-nbd.c.o FAILED: qemu-nbd.p/qemu-nbd.c.o cc -Iqemu-nbd.p -I. -I../.. -Iqapi -Itrace -Iui -Iui/shader -I/opt/homebrew/Cellar/glib/2.66.4/include -I/opt/homebrew/Cellar/glib/2.66.4/include/glib-2.0 -I/opt/homebrew/Cellar/glib/2.66.4/lib/glib-2.0/include -I/opt/homebrew/opt/gettext/include -I/opt/homebrew/Cellar/pcre/8.44/include -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -std=gnu99 -g -DOS_OBJECT_USE_OBJC=0 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined -Wno-initializer-overrides -Wno-missing-include-dirs -Wno-shift-negative-value -Wno-string-plus-int -Wno-typedef-redefinition -Wno-tautological-type-limit-compare -fstack-protector-strong -iquote /Users/pm215/qemu/tcg/aarch64 -iquote . -iquote /Users/pm215/qemu -iquote /Users/pm215/qemu/accel/tcg -iquote /Users/pm215/qemu/include -iquote /Users/pm215/qemu/disas/libvixl -MD -MQ qemu-nbd.p/qemu-nbd.c.o -MF qemu-nbd.p/qemu-nbd.c.o.d -o qemu-nbd.p/qemu-nbd.c.o -c ../../qemu-nbd.c In file included from ../../qemu-nbd.c:30: In file included from /Users/pm215/qemu/include/block/nbd.h:25: /Users/pm215/qemu/include/crypto/tlscreds.h:28:10: fatal error: 'gnutls/gnutls.h' file not found #include ^ 1 error generated. The compiler errors happen for any .c file that includes block/nbd.h and also for files in tests that include gnutls.h directly, and for files that directly or indirectly include crypto/tlssession.c. My meson-foo is insufficient to suggest the correct fix... To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1909256/+subscriptions
Re: [RFC PATCH v2 2/4] hw/arm/virt: Parse -smp cluster parameter in virt_smp_parse
On 2021/4/30 15:01, Andrew Jones wrote: On Fri, Apr 30, 2021 at 08:41:25AM +0200, Andrew Jones wrote: On Fri, Apr 30, 2021 at 01:09:00PM +0800, wangyanan (Y) wrote: But I think the requirement for ARM "if even one parameter other than cpus or maxcpus is provided then all parameters must be provided" will be better. This can ensure the whole accurate users-specified topology. As you mentioned, if anybody who bothers to specify one, why not also specify the others. I can add the requirement for ARM in the documentation, and also check the parameters in virt_smp_parse. Will this be fine? We sort of have to support command lines that are missing 'maxcpus' and 'clusters', unless we work together with libvirt to make the change. Currently libvirt will generate '-smp 16,sockets=16,cores=1,threads=1' from '16'. That's sufficient for our stricter, but not completely strict requirements. And, I still think 'threads' could be optional, because there's a good chance the user doesn't want to describe them, so a default of 1 is good enough. Also, given maxcpus, but not cpus, it's pretty obvious that cpus should equal maxcpus. We also still need just 'cpus' or just 'maxcpus' to work, since that already works now. So, at least these should work -smp N -smp maxcpus=N -smp N,maxcpus=M -smp N,sockets=N,cores=1,threads=1 -smp N,maxcpus=M,sockets=M,cores=1,threads=1 since they work today, even though no topology is described. Yes. I forgot this point that we should consider the compat. If we want to describe a topology for the first three, then we'll have to pick one, which brings us back to the sockets over cores stuff. Or, we could choose to just not generate topology descriptions when none is provided. I find that both preferring cores over sockets and not generating topology descriptions when none is provided can't solve everything. We can only ensure guest will get one socket with multiple cores with qemu cmdline "-smp N". But if we specify N cpus without any other parameters in libvirt xml, a qemu cmdline like "-smp N, sockets=N, cores=1,threads=1" will be generated, and as a result guest will get N sockets. In this case, we still can't avoid the silent change. So maybe we should just prefer sockets over cores like the general smp_parse() and libvirt, and let users use "-smp N, sockets=1, cores=N,threads=1" to get what they want if they use version 6.0 or later. Thanks, Yanan Thanks, drew .
Re: [RFC PATCH 01/27] virtio-snd: Add virtio sound header file
On Thu, Apr 29, 2021 at 05:34:19PM +0530, Shreyansh Chouhan wrote: > Added device configuration and common definitions to the header > file. > > Signed-off-by: Shreyansh Chouhan > --- > include/hw/virtio/virtio-snd.h | 97 ++ This is the place for the data structures used by qemu internally. The structs and #defines for the guest/host protocol should go to include/standard-headers/linux/ instead. There is a script (scripts/update-linux-headers.sh) to sync the files with the linux source tree content. As far I know the linux guest driver is scheduled for merge in the 5.13 merge window, so once 5.13-rc1 is out of the door this should start working. Syncing against a development tree is possible too as temporary stopgap, but some extra care is needed then to avoid unwanted changes to non-virtio-sound files slipping in. Possibly it makes sense to also sync other linux header files that way (for hda jacks maybe?). We also import the input headers to get all the KEY_* #defines for example. take care, Gerd
[Bug 1886076] Re: risc-v pmp implementation error
Fix has been included here:
https://gitlab.com/qemu-project/qemu/-/commit/af3fc195e3c8e98b
** 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/1886076
Title:
risc-v pmp implementation error
Status in QEMU:
Fix Released
Bug description:
QEMU Commit fc1bff958998910ec8d25db86cd2f53ff125f7ab
RISC-V PMP implementation is not correct on QEMU.
When an access is granted there is no more PMP check on the 4KB memory range
of the accessed location.
A cache flush is needed in order to force a PMP check on next access to this
4KB memory range.
A correct implementation would be to grant access to the maximum allowed area
around the accessed location within the 4KB memory range.
For instance, if PMP is configured to block all accesses from 0x80003000 to
0x800037FF and from 0x80003C00 to 0x80003FFF:
1st case:
1) A read access is done @0x80003900 --> access OK as expected
2) Then a read access is done @0x80003400 --> access OK while it must be
blocked!
2nd case:
1) A read access is done @0x80003900 --> access OK as expected
2) Cache is flushed (__asm__ __volatile__ ("sfence.vma" : : : "memory");)
3) A read access is done @0x80003400 --> access blocked as expected
Analysis:
After the 1st read @0x80003900 QEMU add the memory range 0x80003000 to
0x80003FFF into a TLB entry.
Then no more PMP check is done from 0x80003000 to 0x80003FFF until the
TLB is flushed.
What should be done:
Only the range 0x80003800 to 0x80003BFF should be added to the TLB entry.
The 4KB range is the default size of a TLB page on QEMU for RISCV.
The minimum size that can be set is 64Bytes. However the PMP granularity can
be as low as 4Bytes.
I tested a quick fix and PMP is working as expected.
The quick fix consist in replacing this line:
tlb_set_page(cs, address & TARGET_PAGE_MASK, pa & TARGET_PAGE_MASK, prot,
mmu_idx, TARGET_PAGE_SIZE);
By this one in target/riscv/cpu_helper.c:
tlb_set_page(cs, address & ~0x3, pa & ~0x3, prot, mmu_idx, size);
This quick fix has to be optimized in order to consume less HW
resources, as explained at the beginning.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1886076/+subscriptions
Re: [PATCH 1/2] ui/cocoa: capture all keys and combos when mouse is grabbed
Hey Gerd, On Fri, Apr 30, 2021, at 5:05 AM, 'Gerd Hoffmann ' wrote: > Looks all sensible to me, I'd like to have the opinion from the MacOS > experts for this one though. Thanks for the reviews, I'll send a v2 later today! Are there any other people I should CC for the MacOS expertise? It's the firs time I contribute to qemu (the first time I use the send-email process even), so if you have any suggestions on that front I'd appreciate as well =) Cheers, Gustavo
Re: [PATCH v4] hw/smbios: support for type 41 (onboard devices extended information)
❦ 1 avril 2021 19:11 +02, Vincent Bernat: > Type 41 defines the attributes of devices that are onboard. The > original intent was to imply the BIOS had some level of control over > the enablement of the associated devices. Now that QEMU 6 is released, I think this patch is ready (it still applies). It already contains the fixes discussed previously (notably bailing out when the PCI bus is not a root one). If you still find it useful on its own, it could be merged. Thanks. -- Use free-form input when possible. - The Elements of Programming Style (Kernighan & Plauger)
Re: [PATCH v4 05/12] qtest/arm-cpu-features: Restrict sve_tests_sve_off_kvm test to KVM
Philippe Mathieu-Daudé writes:
> The sve_tests_sve_off_kvm() test is KVM specific.
> Only run it if KVM is available.
>
> Suggested-by: Andrew Jones
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
> ---
> tests/qtest/arm-cpu-features.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/qtest/arm-cpu-features.c b/tests/qtest/arm-cpu-features.c
> index 7f4b2521277..66300c3bc20 100644
> --- a/tests/qtest/arm-cpu-features.c
> +++ b/tests/qtest/arm-cpu-features.c
> @@ -604,6 +604,8 @@ int main(int argc, char **argv)
> if (g_str_equal(qtest_get_arch(), "aarch64") && qtest_has_accel("kvm")) {
> qtest_add_data_func("/arm/kvm/query-cpu-model-expansion",
> NULL, test_query_cpu_model_expansion_kvm);
> +qtest_add_data_func("/arm/kvm/query-cpu-model-expansion/sve-off",
> +NULL, sve_tests_sve_off_kvm);
> }
>
> if (g_str_equal(qtest_get_arch(), "aarch64")) {
> @@ -611,8 +613,6 @@ int main(int argc, char **argv)
> NULL, sve_tests_sve_max_vq_8);
> qtest_add_data_func("/arm/max/query-cpu-model-expansion/sve-off",
> NULL, sve_tests_sve_off);
> -qtest_add_data_func("/arm/kvm/query-cpu-model-expansion/sve-off",
> -NULL, sve_tests_sve_off_kvm);
> }
>
> return g_test_run();
--
Alex Bennée
Re: [RFC PATCH 09/27] virtio-snd: Add code for set config function
On Thu, Apr 29, 2021 at 05:34:27PM +0530, Shreyansh Chouhan wrote:
> Signed-off-by: Shreyansh Chouhan
> ---
> hw/audio/virtio-snd.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/hw/audio/virtio-snd.c b/hw/audio/virtio-snd.c
> index afa38adee7..edaeffd6b7 100644
> --- a/hw/audio/virtio-snd.c
> +++ b/hw/audio/virtio-snd.c
> @@ -54,6 +54,14 @@ static void virtio_snd_get_config(VirtIODevice *vdev,
> uint8_t *config)
>
> static void virtio_snd_set_config(VirtIODevice *vdev, const uint8_t *config)
> {
> +VirtIOSound *s = VIRTIO_SOUND(vdev);
> +virtio_snd_config sndcfg;
> +
> +memcpy(&sndcfg, config, sizeof(virtio_snd_config));
> +
> +memcpy(&s->snd_conf.jacks, &sndcfg.jacks, sizeof(uint32_t));
> +memcpy(&s->snd_conf.streams, &sndcfg.streams, sizeof(uint32_t));
> +memcpy(&s->snd_conf.chmaps, &sndcfg.streams, sizeof(uint32_t));
This is static device information for the driver, the driver should not
be able to change those. I think you can simply leave the set_config
empty (i.e. just drop this patch).
take care,
Gerd
Re: [RFC PATCH 11/27] virtio-snd: Add macros for logging
On Thu, Apr 29, 2021 at 05:34:29PM +0530, Shreyansh Chouhan wrote:
> Signed-off-by: Shreyansh Chouhan
> ---
> hw/audio/virtio-snd.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/hw/audio/virtio-snd.c b/hw/audio/virtio-snd.c
> index caad157705..a93674ea72 100644
> --- a/hw/audio/virtio-snd.c
> +++ b/hw/audio/virtio-snd.c
> @@ -39,6 +39,10 @@
> #define VIRTIO_SOUND_HDA_FN_NID_OUT 0
> #define VIRTIO_SOUND_HDA_FN_NID_IN 1
>
> +#define virtio_snd_log(...) AUD_log("virtio sound info", __VA_ARGS__)
> +#define virtio_snd_warn(...) AUD_log("virtio sound warn", __VA_ARGS__)
> +#define virtio_snd_err(...) AUD_log("virtio sound err", __VA_ARGS__)
Warnings and errors meant for the user should use error_report() and
warn_report().
For most debug messages it is better to use tracepoints instead.
take care,
Gerd
Re: [RFC PATCH 12/27] virtio-snd: Add control virtqueue handler
Hi,
> +} else if (ctrl.code == VIRTIO_SND_R_JACK_INFO) {
> +virtio_snd_log("VIRTIO_SND_R_JACK_INFO");
For that kind of tracing / debug logging it is useful to have
enum -> string mapping helper function(s).
take care,
Gerd
Re: [PATCH 1/2] ui/cocoa: capture all keys and combos when mouse is grabbed
Hey Markus, On Fri, Apr 30, 2021, at 4:20 AM, Markus Armbruster wrote: > Please indent like this > ># @full-grab: Capture all key presses, including system combos. This ># requires accessibility permissions, since it performs ># a global grab on key events. (default: off) ># See > https://support.apple.com/en-in/guide/mac-help/mh32356/mac Will do, but just to be sure, the surrounding comments have the second to last lines lined up to the C in Capture there, I assume that is what you mean? > I hope the link is permanent. So do I. I have found Apple to be fairly consistent in providing at least proper redirection to newer versions of the documentation while learning about Cocoa and the Mac itself (first timer, just interested in the M1 to be quite honest), so I'm fairly confident it will survive. Thanks for the review! I'll send a v2 later today. Cheers, Gustavo
Re: [PATCH] block: simplify write-threshold and drop write notifiers
On 22.04.21 00:09, Vladimir Sementsov-Ogievskiy wrote:
write-notifiers are used only for write-threshold. New code for such
purpose should create filters.
Let's handle write-threshold simply in generic code and drop write
notifiers at all.
Also move part of write-threshold API that is used only for testing to
the test.
Signed-off-by: Vladimir Sementsov-Ogievskiy
---
I agree that this could be split into 2-3 parts and not combining
everything into one. But I'm tired now.
Er... You should have put it off until the next day then? O:)
It should be multiple patches. At least one to move the write threshold
update to block/io.c, and then another to drop write notifiers.
I can send v2 if needed, so
consider it as RFC. Or take as is if you think it's not too much-in-one.
I also suggest this as a prepartion (and partly substitution) for
"[PATCH v2 0/8] Block layer thread-safety, continued"
include/block/block_int.h | 12 -
include/block/write-threshold.h | 24 -
block.c | 1 -
block/io.c| 21 +---
block/write-threshold.c | 87 ++-
tests/unit/test-write-threshold.c | 38 ++
6 files changed, 54 insertions(+), 129 deletions(-)
[...]
diff --git a/block/io.c b/block/io.c
index ca2dca3007..e0aa775952 100644
--- a/block/io.c
+++ b/block/io.c
@@ -36,6 +36,8 @@
#include "qemu/main-loop.h"
#include "sysemu/replay.h"
+#include "qapi/qapi-events-block-core.h"
+
/* Maximum bounce buffer for copy-on-read and write zeroes, in bytes */
#define MAX_BOUNCE_BUFFER (32768 << BDRV_SECTOR_BITS)
@@ -1974,6 +1976,8 @@ bdrv_co_write_req_prepare(BdrvChild *child, int64_t offset, int64_t bytes,
child->perm & BLK_PERM_RESIZE);
switch (req->type) {
+uint64_t write_threshold;
+
Works, but I think this is the first time I see a variable declared in a
switch block. What I usually do for such cases is to put a block after
the label. (i.e. case X: { uint64_t write_threshold; ... })
But it wouldn’t hurt to just declare this at the beginning of
bdrv_co_write_req_prepare(), I think.
case BDRV_TRACKED_WRITE:
case BDRV_TRACKED_DISCARD:
if (flags & BDRV_REQ_WRITE_UNCHANGED) {
@@ -1981,8 +1985,15 @@ bdrv_co_write_req_prepare(BdrvChild *child, int64_t
offset, int64_t bytes,
} else {
assert(child->perm & BLK_PERM_WRITE);
}
-return notifier_with_return_list_notify(&bs->before_write_notifiers,
-req);
+write_threshold = qatomic_read(&bs->write_threshold_offset);
+if (write_threshold > 0 && offset + bytes > write_threshold) {
+qapi_event_send_block_write_threshold(
+bs->node_name,
+offset + bytes - write_threshold,
+write_threshold);
+qatomic_set(&bs->write_threshold_offset, 0);
+}
I’d put all of this into a function in block/write-threshold.c that’s
called from here.
Max
+return 0;
case BDRV_TRACKED_TRUNCATE:
assert(child->perm & BLK_PERM_RESIZE);
return 0;
@@ -3137,12 +3148,6 @@ bool bdrv_qiov_is_aligned(BlockDriverState *bs,
QEMUIOVector *qiov)
return true;
}
-void bdrv_add_before_write_notifier(BlockDriverState *bs,
-NotifierWithReturn *notifier)
-{
-notifier_with_return_list_add(&bs->before_write_notifiers, notifier);
-}
-
void bdrv_io_plug(BlockDriverState *bs)
{
BdrvChild *child;
[Bug 1907952] Re: qemu-system-aarch64: with "-display gtk" arrow keys are received as just ^[ on ttyAMA0
** 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/1907952
Title:
qemu-system-aarch64: with "-display gtk" arrow keys are received as
just ^[ on ttyAMA0
Status in QEMU:
Fix Released
Status in qemu package in Debian:
Confirmed
Bug description:
I originally observed this on Debian packaged qemu 5.2 at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976808
Today I checked out the latest git source at
Sun, 13 Dec 2020 19:21:09 +0900
and configured the source as follows:
./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/qemu \
--localstatedir=/var --disable-blobs --disable-strip --localstatedir=/var \
--libdir=/usr/lib/aarch64-linux-gnu \
--firmwarepath=/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu \
--target-list=aarch64-softmmu,arm-softmmu --disable-werror \
--disable-user --enable-gtk --enable-vnc
then executed "make" on an ARM64 (not an x86_64) host,
running the latest Debian testing.
I did the following commands on an arm64 host with the Debian Installer Alpha
3 at
https://cdimage.debian.org/cdimage/bullseye_di_alpha3/arm64/iso-cd/debian-bullseye-DI-alpha3-arm64-netinst.iso
#!/bin/sh
ARCH=arm64
IMAGE=`pwd`/qemu-disk-${ARCH}.qcow2
CDROM=`pwd`/debian-bullseye-DI-alpha3-${ARCH}-netinst.iso
rm -f $IMAGE
qemu-img create -f qcow2 -o compat=1.1 -o lazy_refcounts=on -o
preallocation=off $IMAGE 20G
cd /var/tmp
cp /usr/share/AAVMF/AAVMF_VARS.fd .
$HOME/qemu-git/qemu/build/qemu-system-aarch64 \
-display gtk -enable-kvm -machine virt -cpu host -m 3072 -smp 2\
-net nic,model=virtio -net user -object
rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0,id=rng-device0 \
-drive
if=virtio,file=${IMAGE},index=0,format=qcow2,discard=unmap,detect-zeroes=unmap,media=disk
\
-drive if=virtio,file=${CDROM},index=1,format=raw,readonly=on,media=cdrom
\
-drive
if=pflash,format=raw,unit=0,file=/usr/share/AAVMF/AAVMF_CODE.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=`pwd`/AAVMF_VARS.fd
Then 4 arrow keys on the physical keyboard are received as just "^[".
This symptom was not observed on qemu-system-x86_64.
This symptom was not observed with virt-manager on my arm64 host, neither.
This seems unique to -display gtk of qemu-system-aarch64.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1907952/+subscriptions
Re: [PATCH v2 1/8] hw/intc: GICv3 ITS initial framework
On Fri, 30 Apr 2021 at 00:36, wrote: > > On Fri, 2021-04-16 at 18:21 +0100, Peter Maydell wrote: > > On Thu, 1 Apr 2021 at 03:41, Shashi Mallela < > > shashi.mall...@linaro.org> wrote: > > > +#define GITS_PIDR2 0xFFE8 > > > > You probably don't want an offset for GITS_PIDR2 specifically. > > Compare handling of GICD_IDREGS in the distributor emulation. > > Tried re-using the GICD_IDREGS offset for GITS_PIDR2,but from testing > > observed that the linux kernel driver and kvm-unit-tests both relied > > on using the 0xFFE8 offset instead of 0xFFD0 (used by GICD & GICR) to > > complete ITS initialization and setup I didn't mean "just put PIDR2 at the GICD_IDREGS offset", which obviously won't work, I meant "implement the whole set of ID registers (of which PIDR2 is one in the middle) in the same way we implement that set on the other GIC components". -- PMM
Re: [PATCH 1/2] ui/cocoa: capture all keys and combos when mouse is grabbed
Oh by the way, On Fri, Apr 30, 2021, at 7:02 AM, Gustavo Noronha Silva wrote: > ># @full-grab: Capture all key presses, including system combos. This > ># requires accessibility permissions, since it performs > ># a global grab on key events. (default: off) > ># See > > https://support.apple.com/en-in/guide/mac-help/mh32356/mac I did not add a Since: here because I wasn't sure how that is handled. Should I add something or is that taken care of at the time of release somehow? Thanks again, Gustavo
Re: [RFC PATCH 13/27] virtio-snd: Add VIRTIO_SND_R_JACK_INFO handler
Hi,
> +virtio_snd_query_info req;
> +size_t sz = iov_to_buf(elem->out_sg, elem->out_num, 0, &req,
> sizeof(req));
> +assert(sz == sizeof(virtio_snd_query_info));
This assert looks like the guest can trigger it by sending broken
messages. This should be avoided, the guest should not be able to
kill qemu that way.
> +jack_info[i - req.start_id].hdr.hda_fn_nid = jack->hda_fn_nid;
> +jack_info[i - req.start_id].features = jack->features;
> +jack_info[i - req.start_id].hda_reg_defconf = jack->hda_reg_defconf;
> +jack_info[i - req.start_id].hda_reg_caps = jack->hda_reg_caps;
> +jack_info[i - req.start_id].connected = jack->connected;
Disclaimer: didn't check the structs.
If any of these fields is larger than a byte you need to take care of
byte ordering here. virtio is little endian, so cpu_to_le{16,32}() will
do the job here (if needed).
Same thing elsewhere I suspect.
> } else if (ctrl.code == VIRTIO_SND_R_JACK_INFO) {
> -virtio_snd_log("VIRTIO_SND_R_JACK_INFO");
> +sz = virtio_snd_handle_jack_info(s, elem);
> +goto done;
Ah, you add the actual command handing here. Hmm. I guess a tracepoint
in virtio_snd_handle_jack_info() would be good for debugging. You could
also log the jack id then.
Also: I'd suggest using "switch(ctrl.code)" here. Is more readable than
else-if chains (personal opinion though). Also has the advantage that
gcc will warn in case you forget to handle one of the enums in the
switch.
take care,
Gerd
[Bug 1826175] Re: Compilation on MSYS2/MinGW-w64 fails with error: "No rule to make target capstone.lib"
As far as I can see we're using a capstone version now that contains the commit with the fix, so I'm closing this bug. If you are still having problems, please open again or file a new bug ticket. ** 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/1826175 Title: Compilation on MSYS2/MinGW-w64 fails with error: "No rule to make target capstone.lib" Status in QEMU: Fix Released Bug description: I submitted this bug to Capstone directly but I figured it'd be useful to post it here too. The IS_MINGW check in the Makefile for Capstone fails under MSYS2 MinGW-w64 because cc --version doesn't have mingw in the output anymore: $ whereis cc cc: /mingw64/bin/cc.exe $ cc --version cc.exe (Rev2, Built by MSYS2 project) 8.3.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Really simple patch: diff --git "a/Makefile" "b/Makefile" index 063f50db..1d9f042e 100644 --- "a/Makefile" +++ "b/Makefile" @@ -288,7 +288,7 @@ CFLAGS := $(CFLAGS:-fPIC=) # On Windows we need the shared library to be executable else # mingw? -IS_MINGW := $(shell $(CC) --version | grep -i mingw | wc -l) +IS_MINGW := $(shell $(CC) --version | grep -i msys2 | wc -l) ifeq ($(IS_MINGW),1) EXT = dll AR_EXT = lib To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1826175/+subscriptions
[Bug 1826568] Re: RISC-V Disassembler/translator instruction decoding disagreement
This is an automated cleanup. This bug report has been moved to QEMU's new bug tracker on gitlab.com and thus gets marked as 'expired' now. Please continue with the discussion here: https://gitlab.com/qemu-project/qemu/-/issues/53 ** Changed in: qemu Status: New => Expired ** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #53 https://gitlab.com/qemu-project/qemu/-/issues/53 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1826568 Title: RISC-V Disassembler/translator instruction decoding disagreement Status in QEMU: Expired Bug description: When running QEMU V3.1.0 for platform RISC-V, 64bit, Spike V1.10 with "-d in_asm -singlestep -D qemu_log.txt", my (faulty) test code brought up this message in the logs: 0x8002cade: 05139517e2bf illegal Disassembler disagrees with translator over instruction decoding Please report this to qemu-devel@nongnu.org You may want to resolve the disagreement. Axel To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1826568/+subscriptions
[Bug 1826401] Re: qemu-system-aarch64 has a high cpu usage on windows
Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays? Also, what guest operating systems were you running ? ** 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/1826401 Title: qemu-system-aarch64 has a high cpu usage on windows Status in QEMU: Incomplete Bug description: Running qemu-system-aarch64 leads to a high CPU consumption on windows 10. Tested with qemu: 4.0.0-rc4 & 3.1.0 & 2.11.0 Command: qemu_start_command = [ qemu-system-aarch64, "-pidfile", target_path + "/qemu" + str(instance) + ".pid", "-machine", "virt", "-cpu", "cortex-a57", "-nographic", "-smp", "2", "-m", "2048", "-kernel", kernel_path, "--append", "console=ttyAMA0 root=/dev/vda2 rw ipx=" + qemu_instance_ip + "/64 net.ifnames=0 biosdevname=0", "-drive", "file=" + qemu_instance_img_path + ",if=none,id=blk", "-device", "virtio-blk-device,drive=blk", "-netdev", "socket,id=mynet0,udp=127.0.0.1:2000,localaddr=127.0.0.1:" + qemu_instance_port, "-device", "virtio-net-device,netdev=mynet0", "-serial", "file:" + target_path + "/qemu" + str(instance) + ".log" ] *The cpu consumption is ~70%. *No acceleration used. *This CPU consumption is obtained only by running the above command. No workload on the guest OS. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1826401/+subscriptions
[PATCH] ui: Fix memory leak in qemu_xkeymap_mapping_table()
Refactor qemu_xkeymap_mapping_table() to have a single exit point,
so we can easily free the memory allocated by XGetAtomName(),
This fixes when running a binary configured with --enable-sanitizers:
Direct leak of 22 byte(s) in 1 object(s) allocated from:
#0 0x561344a7473f in malloc (qemu-system-x86_64+0x1dab73f)
#1 0x7fa4d9dc08aa in XGetAtomName (/lib64/libX11.so.6+0x2a8aa)
Fixes: 2ec78706d18 ("ui: convert GTK and SDL1 frontends to keycodemapdb")
Signed-off-by: Philippe Mathieu-Daudé
---
ui/x_keymap.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/ui/x_keymap.c b/ui/x_keymap.c
index 555086fb6bd..2ce7b899615 100644
--- a/ui/x_keymap.c
+++ b/ui/x_keymap.c
@@ -56,6 +56,7 @@ const guint16 *qemu_xkeymap_mapping_table(Display *dpy,
size_t *maplen)
{
XkbDescPtr desc;
const gchar *keycodes = NULL;
+const guint16 *map;
/* There is no easy way to determine what X11 server
* and platform & keyboard driver is in use. Thus we
@@ -83,21 +84,21 @@ const guint16 *qemu_xkeymap_mapping_table(Display *dpy,
size_t *maplen)
if (check_for_xwin(dpy)) {
trace_xkeymap_keymap("xwin");
*maplen = qemu_input_map_xorgxwin_to_qcode_len;
-return qemu_input_map_xorgxwin_to_qcode;
+map = qemu_input_map_xorgxwin_to_qcode;
} else if (check_for_xquartz(dpy)) {
trace_xkeymap_keymap("xquartz");
*maplen = qemu_input_map_xorgxquartz_to_qcode_len;
-return qemu_input_map_xorgxquartz_to_qcode;
+map = qemu_input_map_xorgxquartz_to_qcode;
} else if ((keycodes && g_str_has_prefix(keycodes, "evdev")) ||
(XKeysymToKeycode(dpy, XK_Page_Up) == 0x70)) {
trace_xkeymap_keymap("evdev");
*maplen = qemu_input_map_xorgevdev_to_qcode_len;
-return qemu_input_map_xorgevdev_to_qcode;
+map = qemu_input_map_xorgevdev_to_qcode;
} else if ((keycodes && g_str_has_prefix(keycodes, "xfree86")) ||
(XKeysymToKeycode(dpy, XK_Page_Up) == 0x63)) {
trace_xkeymap_keymap("kbd");
*maplen = qemu_input_map_xorgkbd_to_qcode_len;
-return qemu_input_map_xorgkbd_to_qcode;
+map = qemu_input_map_xorgkbd_to_qcode;
} else {
trace_xkeymap_keymap("NULL");
g_warning("Unknown X11 keycode mapping '%s'.\n"
@@ -109,6 +110,10 @@ const guint16 *qemu_xkeymap_mapping_table(Display *dpy,
size_t *maplen)
" - xprop -root\n"
" - xdpyinfo\n",
keycodes ? keycodes : "");
-return NULL;
+map = NULL;
}
+if (keycodes) {
+XFree((void *)keycodes);
+}
+return map;
}
--
2.26.3
Re: [PATCH v4 06/12] qtest/arm-cpu-features: Remove TCG fallback to KVM specific tests
Philippe Mathieu-Daudé writes: > sve_tests_sve_off_kvm() and test_query_cpu_model_expansion_kvm() > tests are now only being run if KVM is available. Drop the TCG > fallback. > > Suggested-by: Andrew Jones > Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Alex Bennée -- Alex Bennée
