Re: [RFC PATCH 0/2] Pegasos2 emulation

[no-reply]

Patchew URL: https://patchew.org/QEMU/cover.1609973005.git.bala...@eik.bme.hu/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: cover.1609973005.git.bala...@eik.bme.hu
Subject: [RFC PATCH 0/2] Pegasos2 emulation

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 - [tag update]  patchew/cover.1609973005.git.bala...@eik.bme.hu -> 
patchew/cover.1609973005.git.bala...@eik.bme.hu
Switched to a new branch 'test'
3d24553 hw/ppc: Add emulation of Genesi/bPlan Pegasos II
ac7efd0 hw/pci-host: Add emulation of Marvell MV64361 PPC system controller

=== OUTPUT BEGIN ===
1/2 Checking commit ac7efd0619df (hw/pci-host: Add emulation of Marvell MV64361 
PPC system controller)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#43: 
new file mode 100644

WARNING: line over 80 characters
#299: FILE: hw/pci-host/mv64361.c:252:
+trace_mv64361_region_enable(!(val & mask) ? "enable" : "disable", 
i);

ERROR: code indent should never use tabs
#1024: FILE: hw/pci-host/mv643xx.h:5:
+ * ^IAuthor: Matthew Dharm $

WARNING: architecture specific defines should be avoided
#1032: FILE: hw/pci-host/mv643xx.h:13:
+#ifndef __ASM_MV643XX_H

WARNING: Block comments use a leading /* on a separate line
#1094: FILE: hw/pci-host/mv643xx.h:75:
+/* Enables the CS , DEV_CS , PCI 0 and PCI 1

WARNING: Block comments use * on subsequent lines
#1095: FILE: hw/pci-host/mv643xx.h:76:
+/* Enables the CS , DEV_CS , PCI 0 and PCI 1
+   windows above */

WARNING: Block comments use a trailing */ on a separate line
#1095: FILE: hw/pci-host/mv643xx.h:76:
+   windows above */

ERROR: code indent should never use tabs
#1198: FILE: hw/pci-host/mv643xx.h:179:
+/*  CPU Interface Debug Registers ^I*/$

ERROR: code indent should never use tabs
#1275: FILE: hw/pci-host/mv643xx.h:256:
+/* Device Parameters^I^I^I*/$

ERROR: code indent should never use tabs
#1278: FILE: hw/pci-host/mv643xx.h:259:
+#define MV64340_DEVICE_BANK0_PARAMETERS^I^I^I^I0x45c$

ERROR: code indent should never use tabs
#1279: FILE: hw/pci-host/mv643xx.h:260:
+#define MV64340_DEVICE_BANK1_PARAMETERS^I^I^I^I0x460$

ERROR: code indent should never use tabs
#1280: FILE: hw/pci-host/mv643xx.h:261:
+#define MV64340_DEVICE_BANK2_PARAMETERS^I^I^I^I0x464$

ERROR: code indent should never use tabs
#1281: FILE: hw/pci-host/mv643xx.h:262:
+#define MV64340_DEVICE_BANK3_PARAMETERS^I^I^I^I0x468$

ERROR: code indent should never use tabs
#1282: FILE: hw/pci-host/mv643xx.h:263:
+#define MV64340_DEVICE_BOOT_BANK_PARAMETERS^I^I^I0x46c$

ERROR: code indent should never use tabs
#1289: FILE: hw/pci-host/mv643xx.h:270:
+/* Device interrupt registers^I^I*/$

ERROR: code indent should never use tabs
#1292: FILE: hw/pci-host/mv643xx.h:273:
+#define MV64340_DEVICE_INTERRUPT_CAUSE^I^I^I^I0x4d0$

ERROR: code indent should never use tabs
#1293: FILE: hw/pci-host/mv643xx.h:274:
+#define MV64340_DEVICE_INTERRUPT_MASK^I^I^I^I0x4d4$

ERROR: code indent should never use tabs
#1294: FILE: hw/pci-host/mv643xx.h:275:
+#define MV64340_DEVICE_ERROR_ADDR^I^I^I^I0x4d8$

ERROR: code indent should never use tabs
#1295: FILE: hw/pci-host/mv643xx.h:276:
+#define MV64340_DEVICE_ERROR_DATA   ^I^I^I^I0x4dc$

ERROR: code indent should never use tabs
#1296: FILE: hw/pci-host/mv643xx.h:277:
+#define MV64340_DEVICE_ERROR_PARITY ^I^I^I0x4e0$

ERROR: code indent should never use tabs
#1299: FILE: hw/pci-host/mv643xx.h:280:
+/* Device debug registers   ^I^I*/$

ERROR: code indent should never use tabs
#1302: FILE: hw/pci-host/mv643xx.h:283:
+#define MV64340_DEVICE_DEBUG_LOW ^I^I^I^I0x4e4$

ERROR: code indent should never use tabs
#1303: FILE: hw/pci-host/mv643xx.h:284:
+#define MV64340_DEVICE_DEBUG_HIGH ^I^I^I^I0x4e8$

ERROR: code indent should never use tabs
#1342: FILE: hw/pci-host/mv643xx.h:323:
+#define MV64340_PCI_0_CS_0_BASE_ADDR_REMAP^I^I^I0xc48$

ERROR: code indent should never use tabs
#1343: FILE: hw/pci-host/mv643xx.h:324:
+#define MV64340_PCI_1_CS_0_BASE_ADDR_REMAP^I^I^I0xcc8$

ERROR: code indent should never use tabs
#1344: FILE: hw/pci-host/mv643xx.h:325:
+#define MV64340_PCI_0_CS_1_BASE_ADDR_REMAP^I^I^I0xd48$

ERROR: code indent should never use tabs
#1345: FILE: hw/pci-host/mv643xx.h:326:
+#define MV64340_PCI_1_CS_1_BASE_ADDR_REMAP^I^I^I0xdc8$

ERROR: code indent should never use tabs
#1346: FILE: hw/pci-host/mv643xx.h:327:
+#define MV64340_PCI_0_CS_2_BASE_ADDR_REMAP^I^I^I0xc4c$

ERROR: code indent should never use tabs
#1347: FILE: hw/pci-host/mv643xx.h:328:
+#define MV64340_PCI_1_CS_2_BASE_ADDR_REMAP^I^I^I0xccc$

ERROR: 

Re: [RFC PATCH 0/2] Pegasos2 emulation

[Philippe Mathieu-Daudé]

On 1/7/21 2:15 AM, BALATON Zoltan wrote:
> On Wed, 6 Jan 2021, BALATON Zoltan wrote:
>> Hello,
>>
>> This is adding a new PPC board called pegasos2 currently posted as RFC
>> because it depends on not yet merged VT8231 emulation currently on the
>> list:
>>
>> https://patchew.org/QEMU/cover.1609967638.git.bala...@eik.bme.hu/

This note ^^^ ...

>>
>> and may need some changes like a test case but I'm posting it now for
>> getting feedback on what's needed to merge this. More info on it can
>> be found at:
>>
>> https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2
>>
>> Currently it needs a firmware ROM image that I cannot include due to
>> original copyright holder (bPlan) did not release it under a free
>> licence but I have plans to write a replacement in the future. With
>> that firmware it can boot MorphOS now as:
>>
>> qemu-system-ppc -M pegasos2 -cdrom morphos.iso -device
>> ati-vga,romfile="" -serial stdio
>>
>> then enter "boot cd boot.img" at the firmware "ok" prompt as described
>> in the MorphOS.readme. To boot Linux use same command line with e.g.
>> -cdrom debian-8.11.0-powerpc-netinst.iso then enter
>> "boot cd install/pegasos"
>>
>> Patch 2 adds the actual board code after patch 1 adding MV64361 system
>> controller chip. The mv643xx.h header file is taken from Linux and
>> produces a bunch of checkpatch warnings due to different formatting
>> rules it follows, I'm not sure we want to adopt it or keep it as it is
>> given that it does not appear any more in recent Linux versions so we
>> could reformat it as it's unlikely to get updated in the future.
> 
> Interestingly it applies for patchew while this was accidentally based
> on my previous series that has hw/ppc/Kconfig reverts so it does not
> apply on current master.

... can be passed as hint to patchew as a tag:

Based-on: 

> Also missing a file so does not compile but
> other than that the content could be reviewed. I've now updated this repo:
> 
> https://osdn.net/projects/qmiga/scm/git/qemu/tree/pegasos2/
> 
> which contains all the needed patches over QEMU master at one place in
> case somebody wants to try this. I'll send an updated version later
> after I get some feedback.
> 
> The command lines above also need -bios /path/to/firmware.rom

An integration test similar to the Fuloong PMON would be highly
appreciated :)

https://www.mail-archive.com/qemu-devel@nongnu.org/msg752605.html

Regards,

Phil.

[PATCH] tests/docker: Remove Debian 9 remnant lines

[Philippe Mathieu-Daudé]

Debian 9 base container has been removed in commits
e3755276d1f and c9d78b06c06. Remove the last remnants.

Fixes: e3755276d1f ("tests/docker: Remove old Debian 9 containers")
Signed-off-by: Philippe Mathieu-Daudé 
---
 tests/docker/Makefile.include | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tests/docker/Makefile.include b/tests/docker/Makefile.include
index c254ac38d0a..0779dab5b96 100644
--- a/tests/docker/Makefile.include
+++ b/tests/docker/Makefile.include
@@ -108,7 +108,6 @@ ifneq ($(HOST_ARCH),x86_64)
 DOCKER_PARTIAL_IMAGES += debian-mips-cross debian-mipsel-cross 
debian-mips64el-cross
 DOCKER_PARTIAL_IMAGES += debian-ppc64el-cross
 DOCKER_PARTIAL_IMAGES += debian-s390x-cross
-DOCKER_PARTIAL_IMAGES += debian-win32-cross debian-win64-cross
 DOCKER_PARTIAL_IMAGES += fedora travis
 endif
 
-- 
2.26.2

Re: [PATCH 3/4] whpx: Fixes include of whp-dispatch.h in whpx.h

[Philippe Mathieu-Daudé]

On 1/7/21 6:38 AM, Yonggang Luo wrote:
> Signed-off-by: Yonggang Luo 
> ---
>  include/sysemu/whpx.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/sysemu/whpx.h b/include/sysemu/whpx.h
> index 9346fd92e9..0e6c9faaf6 100644
> --- a/include/sysemu/whpx.h
> +++ b/include/sysemu/whpx.h
> @@ -15,7 +15,7 @@
>  
>  #ifdef CONFIG_WHPX
>  
> -#include "whp-dispatch.h"
> +#include "target/i386/whpx/whp-dispatch.h"

"sysemu" should not include target/...

$ git grep target/ include/sysemu/ | wc -l
0

Maybe what you want is:

-- >8 --
diff --git a/include/sysemu/whpx.h b/include/sysemu/whpx.h
index 9346fd92e93..4f38784d7e4 100644
--- a/include/sysemu/whpx.h
+++ b/include/sysemu/whpx.h
@@ -15,7 +15,7 @@

 #ifdef CONFIG_WHPX

-#include "whp-dispatch.h"
+#include 

 struct whpx_state {
 uint64_t mem_quota;
---

Re: [PATCH 4/4] maintainers: Add me as Windows Hosted Continuous Integration maintainer

[Philippe Mathieu-Daudé]

On 1/7/21 6:38 AM, Yonggang Luo wrote:
> Signed-off-by: Yonggang Luo 
> ---
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4be087b88e..4d9df874a1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3198,6 +3198,12 @@ S: Maintained
>  F: .cirrus.yml
>  W: https://cirrus-ci.com/github/qemu/qemu
>  
> +Windows Hosted Continuous Integration
> +M: Yonggang Luo 
> +S: Maintained
> +F: .cirrus.yml
> +W: https://cirrus-ci.com/github/qemu/qemu

Thanks for stepping forward!

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 1/4] cirrus/msys2: Exit powershell with $LastExitCode

[Philippe Mathieu-Daudé]

On 1/7/21 6:38 AM, Yonggang Luo wrote:
> Currently if we don't exit with $LastExitCode manually,
> the cirrus would not report the build/testing failure.
> 
> Signed-off-by: Yonggang Luo 
> ---
>  .cirrus.yml | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v4] gdb: riscv: Add target description

[Philippe Mathieu-Daudé]

On 1/6/21 9:41 PM, Sylvain Pelissier wrote:
> Target description is not currently implemented in RISC-V
> architecture. Thus GDB won't set it properly when attached.
> The patch implements the target description response.
> 
> Signed-off-by: Sylvain Pelissier 
> Reviewed-by: Bin Meng 
> Reviewed-by: Alistair Francis 
> ---
>  target/riscv/cpu.c | 13 +
>  1 file changed, 13 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v3 1/3] update-linux-headers: Include const.h

[Philippe Mathieu-Daudé]

On 1/4/21 9:20 PM, Eric Farman wrote:
> Kernel commit a85cbe6159ff ("uapi: move constants from
>  to ") breaks our script
> because of the unrecognized include. Let's add that to
> our processing.
> 
> Signed-off-by: Eric Farman 
> ---
>  scripts/update-linux-headers.sh | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH] docs/system: Remove deprecated 'fulong2e' machine alias

[Thomas Huth]

Am Wed,  6 Jan 2021 19:46:02 +0100
schrieb Philippe Mathieu-Daudé :

> The 'fulong2e' machine alias has been marked as deprecated since
> QEMU v5.1 (commit c3a09ff68dd, the machine is renamed 'fuloong2e').
> Time to remove it now.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  docs/system/deprecated.rst   | 5 -
>  docs/system/removed-features.rst | 5 +
>  hw/mips/fuloong2e.c  | 1 -
>  3 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index bacd76d7a58..e20bfcb17a4 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -309,11 +309,6 @@ The 'scsi-disk' device is deprecated. Users
> should use 'scsi-hd' or System emulator machines
>  
>  
> -mips ``fulong2e`` machine (since 5.1)
> -'
> -
> -This machine has been renamed ``fuloong2e``.
> -
>  ``pc-1.0``, ``pc-1.1``, ``pc-1.2`` and ``pc-1.3`` (since 5.0)
>  '
>  
> diff --git a/docs/system/removed-features.rst
> b/docs/system/removed-features.rst index 8b20d78a4d0..430fc33ca18
> 100644 --- a/docs/system/removed-features.rst
> +++ b/docs/system/removed-features.rst
> @@ -120,6 +120,11 @@ mips ``r4k`` platform (removed in 5.2)
>  This machine type was very old and unmaintained. Users should use
> the ``malta`` machine type instead.
>  
> +mips ``fulong2e`` machine alias (removed in 6.0)
> +
> +
> +This machine has been renamed ``fuloong2e``.
> +
>  Related binaries
>  
>  
> diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
> index 29805242caa..bac2adbd5ae 100644
> --- a/hw/mips/fuloong2e.c
> +++ b/hw/mips/fuloong2e.c
> @@ -383,7 +383,6 @@ static void mips_fuloong2e_init(MachineState
> *machine) static void mips_fuloong2e_machine_init(MachineClass *mc)
>  {
>  mc->desc = "Fuloong 2e mini pc";
> -mc->alias = "fulong2e"; /* Incorrect name used up to
> QEMU 4.2 */ mc->init = mips_fuloong2e_init;
>  mc->block_default_type = IF_IDE;
>  mc->default_cpu_type = MIPS_CPU_TYPE_NAME("Loongson-2E");

Reviewed-by: Thomas Huth 

Re: [PATCH] docs/system: Remove deprecated 'fulong2e' machine alias

[Huacai Chen]

Reviewed-by: Huacai Chen 

On Thu, Jan 7, 2021 at 2:46 AM Philippe Mathieu-Daudé  wrote:
>
> The 'fulong2e' machine alias has been marked as deprecated since
> QEMU v5.1 (commit c3a09ff68dd, the machine is renamed 'fuloong2e').
> Time to remove it now.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  docs/system/deprecated.rst   | 5 -
>  docs/system/removed-features.rst | 5 +
>  hw/mips/fuloong2e.c  | 1 -
>  3 files changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> index bacd76d7a58..e20bfcb17a4 100644
> --- a/docs/system/deprecated.rst
> +++ b/docs/system/deprecated.rst
> @@ -309,11 +309,6 @@ The 'scsi-disk' device is deprecated. Users should use 
> 'scsi-hd' or
>  System emulator machines
>  
>
> -mips ``fulong2e`` machine (since 5.1)
> -'
> -
> -This machine has been renamed ``fuloong2e``.
> -
>  ``pc-1.0``, ``pc-1.1``, ``pc-1.2`` and ``pc-1.3`` (since 5.0)
>  '
>
> diff --git a/docs/system/removed-features.rst 
> b/docs/system/removed-features.rst
> index 8b20d78a4d0..430fc33ca18 100644
> --- a/docs/system/removed-features.rst
> +++ b/docs/system/removed-features.rst
> @@ -120,6 +120,11 @@ mips ``r4k`` platform (removed in 5.2)
>  This machine type was very old and unmaintained. Users should use the 
> ``malta``
>  machine type instead.
>
> +mips ``fulong2e`` machine alias (removed in 6.0)
> +
> +
> +This machine has been renamed ``fuloong2e``.
> +
>  Related binaries
>  
>
> diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
> index 29805242caa..bac2adbd5ae 100644
> --- a/hw/mips/fuloong2e.c
> +++ b/hw/mips/fuloong2e.c
> @@ -383,7 +383,6 @@ static void mips_fuloong2e_init(MachineState *machine)
>  static void mips_fuloong2e_machine_init(MachineClass *mc)
>  {
>  mc->desc = "Fuloong 2e mini pc";
> -mc->alias = "fulong2e"; /* Incorrect name used up to QEMU 
> 4.2 */
>  mc->init = mips_fuloong2e_init;
>  mc->block_default_type = IF_IDE;
>  mc->default_cpu_type = MIPS_CPU_TYPE_NAME("Loongson-2E");
> --
> 2.26.2
>

Re: [PATCH v3 3/8] acpi/gpex: Inform os to keep firmware resource map

[Jiahui Cen]

On 2021/1/6 21:29, Igor Mammedov wrote:
> On Tue, 5 Jan 2021 09:53:49 +0800
> Jiahui Cen  wrote:
> 
>> On 2021/1/5 8:35, Igor Mammedov wrote:
>>> On Wed, 30 Dec 2020 16:22:08 -0500
>>> "Michael S. Tsirkin"  wrote:
>>>   
 On Tue, Dec 29, 2020 at 02:41:42PM +0100, Igor Mammedov wrote:  
> On Wed, 23 Dec 2020 17:08:31 +0800
> Jiahui Cen  wrote:
> 
>> There may be some differences in pci resource assignment between guest os
>> and firmware.
>>
>> Eg. A Bridge with Bus [d2]
>> -+-[:d2]---01.0-[d3]01.0
>>
>> where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, 
>> non-pref) [size=256]
>>   [d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) 
>> [size=128K]
>>   BAR4 (mem, 64-bit, pref) 
>> [size=64M]
>>
>> In EDK2, the Resource Map would be:
>> PciBus: Resource Map for Bridge [D2|01|00]
>> Type = PMem64; Base = 0x800400; Length = 0x410; 
>> Alignment = 0x3FF
>>Base = 0x800400; Length = 0x400; Alignment = 
>> 0x3FF;  Owner = PCI [D3|01|00:20]
>>Base = 0x800800; Length = 0x2;   Alignment = 
>> 0x1;Owner = PCI [D3|01|00:10]
>> Type =  Mem64; Base = 0x800810; Length = 0x100; 
>> Alignment = 0xFFF
>> It would use 0x410 to calculate the root bus's PMem64 resource 
>> window.
>>
>> While in Linux, kernel will use 0x1FF as the alignment to 
>> calculate
>> the PMem64 size, which would be 0x600. So kernel would try to
>> allocate 0x600 from the PMem64 resource window, but since the 
>> window
>> size is 0x410 as assigned by EDK2, the allocation would fail.
>>
>> The diffences could result in resource assignment failure.
>>
>> Using _DSM #5 method to inform guest os not to ignore the PCI 
>> configuration
>> that firmware has done at boot time could handle the differences.
>
> I'm not sure about this one, 
> OS should able to reconfigure PCI resources according to what and where 
> is plugged
> (and it even more true is hotplug is taken into account)

 spec says this:

 0: No (The operating system must not ignore the PCI configuration that 
 firmware has done
 at boot time. However, the operating system is free to configure the 
 devices in this hierarchy
 that have not been configured by the firmware. There may be a reduced 
 level of hot plug
 capability support in this hierarchy due to resource constraints. This 
 situation is the same as
 the legacy situation where this _DSM is not provided.)
 1: Yes (The operating system may ignore the PCI configuration that the 
 firmware has done
 at boot time, and reconfigure/rebalance the resources in the hierarchy.)  
>>> I sort of convinced my self that's is just hotplug work might need to 
>>> implement reconfiguration
>>> in guest kernel and maybe QEMU
>>>
>>> Though I have a question,
>>>
>>>  1. does it work for PC machine with current kernel, if so why?
>>>  2. what it would take to make it work for arm/virt?
>>>   
>>
>> 1. For x86, it generally keeps the configuration by firmware,
>> so there is nothing wrong for PC machine.
>>
>> 2. We add DSM method in DSDT to inform guest to keep
>> firmware's configuration, just like x86.
>>
 and

 IMPLEMENTATION NOTE
 This _DSM function provides backwards compatibility on platforms that can 
 run legacy operating
 systems.
 Operating systems for two different architectures (e.g., x86 and x64) can 
 be installed on a platform.
 The firmware cannot distinguish the operating system in time to change the 
 boot configuration of
 devices. Say for instance, an x86 operating system in non-PAE mode is 
 installed on a system. The
 x86 operating system cannot access device resource space above 4 GiB. So 
 the firmware is required
 to configure devices at boot time using addresses below 4 GiB. On the 
 other hand, if an x64
 operating system is installed on this system, it can access device 
 resources above the 4 GiB so it does
 not want the firmware to constrain the resource assignment below 4 GiB 
 that the firmware
 configures at boot time. It is not possible for the firmware to change 
 this by the time it boots the
 operating system. Ignoring the configurations done by firmware at boot 
 time will allow the
 operating system to push resource assignment using addresses above 4 GiB 
 for an x64 operating
 system while constrain it to addresses below 4 GiB for an x86 operating 
 system.

 so fundamentally, saying "1" here just means "you can ignore what
 firmware configured if you like".


 I have a different 

Re: [PATCH v4 6/7] fuzz: add minimization options

[Alexander Bulekov]

On 201229 1240, Qiuhao Li wrote:
> -M1: loop around the remove minimizer
> -M2: try setting bits in operand of write/out to zero
> Signed-off-by: Qiuhao Li 

Reviewed-by: Alexander Bulekov 

> ---
>  scripts/oss-fuzz/minimize_qtest_trace.py | 32 +++-
>  1 file changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/scripts/oss-fuzz/minimize_qtest_trace.py 
> b/scripts/oss-fuzz/minimize_qtest_trace.py
> index 70ac0c5366..a681984076 100755
> --- a/scripts/oss-fuzz/minimize_qtest_trace.py
> +++ b/scripts/oss-fuzz/minimize_qtest_trace.py
> @@ -16,6 +16,10 @@ QEMU_PATH = None
>  TIMEOUT = 5
>  CRASH_TOKEN = None
>  
> +# Minimization levels
> +M1 = False # loop around the remove minimizer
> +M2 = False # try setting bits in operand of write/out to zero
> +
>  write_suffix_lookup = {"b": (1, "B"),
> "w": (2, "H"),
> "l": (4, "L"),
> @@ -23,10 +27,20 @@ write_suffix_lookup = {"b": (1, "B"),
>  
>  def usage():
>  sys.exit("""\
> -Usage: QEMU_PATH="/path/to/qemu" QEMU_ARGS="args" {} input_trace output_trace
> +Usage:
> +
> +QEMU_PATH="/path/to/qemu" QEMU_ARGS="args" {} [Options] input_trace 
> output_trace
> +
>  By default, will try to use the second-to-last line in the output to identify
>  whether the crash occred. Optionally, manually set a string that idenitifes 
> the
>  crash by setting CRASH_TOKEN=
> +
> +Options:
> +
> +-M1: enable a loop around the remove minimizer, which may help decrease some
> + timing dependant instructions. Off by default.
> +-M2: try setting bits in operand of write/out to zero. Off by default.
> +
>  """.format((sys.argv[0])))
>  
>  deduplication_note = """\n\
> @@ -213,24 +227,30 @@ def minimize_trace(inpath, outpath):
>  print("Setting the timeout for {} seconds".format(TIMEOUT))
>  
>  newtrace = trace[:]
> -
> +global M1, M2
>  # remove minimizer
>  old_len = len(newtrace) + 1
>  while(old_len > len(newtrace)):
>  old_len = len(newtrace)
> +print("trace lenth = ", old_len)
>  remove_minimizer(newtrace, outpath)
> +if not M1 and not M2:
> +break
>  newtrace = list(filter(lambda s: s != "", newtrace))
>  assert(check_if_trace_crashes(newtrace, outpath))
>  
> -# set zero minimizer
> -set_zero_minimizer(newtrace, outpath)
> +if M2:
> +set_zero_minimizer(newtrace, outpath)
>  assert(check_if_trace_crashes(newtrace, outpath))
>  
>  
>  if __name__ == '__main__':
>  if len(sys.argv) < 3:
>  usage()
> -
> +if "-M1" in sys.argv:
> +M1 = True
> +if "-M2" in sys.argv:
> +M2 = True
>  QEMU_PATH = os.getenv("QEMU_PATH")
>  QEMU_ARGS = os.getenv("QEMU_ARGS")
>  if QEMU_PATH is None or QEMU_ARGS is None:
> @@ -239,4 +259,4 @@ if __name__ == '__main__':
>  # QEMU_ARGS += " -accel qtest"
>  CRASH_TOKEN = os.getenv("CRASH_TOKEN")
>  QEMU_ARGS += " -qtest stdio -monitor none -serial none "
> -minimize_trace(sys.argv[1], sys.argv[2])
> +minimize_trace(sys.argv[-2], sys.argv[-1])
> -- 
> 2.25.1
> 

[PATCH 4/4] maintainers: Add me as Windows Hosted Continuous Integration maintainer

[Yonggang Luo]

Signed-off-by: Yonggang Luo 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4be087b88e..4d9df874a1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3198,6 +3198,12 @@ S: Maintained
 F: .cirrus.yml
 W: https://cirrus-ci.com/github/qemu/qemu
 
+Windows Hosted Continuous Integration
+M: Yonggang Luo 
+S: Maintained
+F: .cirrus.yml
+W: https://cirrus-ci.com/github/qemu/qemu
+
 GitLab Continuous Integration
 M: Thomas Huth 
 M: Philippe Mathieu-Daud?? 
-- 
2.29.2.windows.3

[PATCH 2/4] cirrus/msys2: Cache msys2 mingw in a better way.

[Yonggang Luo]

Signed-off-by: Yonggang Luo 
---
 .cirrus.yml | 117 ++--
 1 file changed, 68 insertions(+), 49 deletions(-)

diff --git a/.cirrus.yml b/.cirrus.yml
index ff6adabd0d..6f2a958472 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -58,23 +58,61 @@ windows_msys2_task:
 CIRRUS_SHELL: powershell
 MSYS: winsymlinks:nativestrict
 MSYSTEM: MINGW64
+MSYS2_URL: 
https://github.com/msys2/msys2-installer/releases/download/2021-01-05/msys2-base-x86_64-20210105.sfx.exe
+MSYS2_FINGERPRINT: 0
+MSYS2_PACKAGES: "
+  diffutils git grep make pkg-config sed
+  mingw-w64-x86_64-python
+  mingw-w64-x86_64-python-sphinx
+  mingw-w64-x86_64-toolchain
+  mingw-w64-x86_64-SDL2
+  mingw-w64-x86_64-SDL2_image
+  mingw-w64-x86_64-gtk3
+  mingw-w64-x86_64-glib2
+  mingw-w64-x86_64-ninja
+  mingw-w64-x86_64-jemalloc
+  mingw-w64-x86_64-lzo2
+  mingw-w64-x86_64-zstd
+  mingw-w64-x86_64-libjpeg-turbo
+  mingw-w64-x86_64-pixman
+  mingw-w64-x86_64-libgcrypt
+  mingw-w64-x86_64-libpng
+  mingw-w64-x86_64-libssh
+  mingw-w64-x86_64-libxml2
+  mingw-w64-x86_64-snappy
+  mingw-w64-x86_64-libusb
+  mingw-w64-x86_64-usbredir
+  mingw-w64-x86_64-libtasn1
+  mingw-w64-x86_64-nettle
+  mingw-w64-x86_64-cyrus-sasl
+  mingw-w64-x86_64-curl
+  mingw-w64-x86_64-gnutls
+  mingw-w64-x86_64-libnfs
+"
 CHERE_INVOKING: 1
-  setup_script:
-- choco install -y --no-progress 7zip
-- Write-Output $env:PATH
   msys2_cache:
 folder: C:\tools\archive
 reupload_on_changes: false
-fingerprint_script: cat .cirrus.yml
+# These env variables are used to generate fingerprint to trigger the 
cache procedure
+# If wanna to force re-populate msys2, increase MSYS2_FINGERPRINT
+fingerprint_script:
+  - |
+echo $env:CIRRUS_TASK_NAME
+echo $env:MSYS2_URL
+echo $env:MSYS2_FINGERPRINT
+echo $env:MSYS2_PACKAGES
 populate_script:
   - |
-md C:\tools
-md C:\tools\archive
+md -Force C:\tools\archive\pkg
 $start_time = Get-Date
+bitsadmin /transfer msys_download /dynamic /download /priority 
FOREGROUND $env:MSYS2_URL C:\tools\archive\base.exe
+Write-Output "Download time taken: $((Get-Date).Subtract($start_time))"
 cd C:\tools
-bitsadmin /transfer msys_download /dynamic /download /priority 
FOREGROUND 
https://github.com/msys2/msys2-installer/releases/download/2020-09-03/msys2-base-x86_64-20200903.sfx.exe
 C:\tools\base.exe
-Write-Output "Download time taken: 
$((Get-Date).Subtract($start_time).Seconds) second(s)"
-C:\tools\base.exe -y
+C:\tools\archive\base.exe -y
+del -Force C:\tools\archive\base.exe
+Write-Output "Base install time taken: 
$((Get-Date).Subtract($start_time))"
+$start_time = Get-Date
+
 ((Get-Content -path 
C:\tools\msys64\etc\\post-install\\07-pacman-key.post -Raw) -replace 
'--refresh-keys', '--version') | Set-Content -Path 
C:\tools\msys64\etc\\post-install\\07-pacman-key.post
 C:\tools\msys64\usr\bin\bash.exe -lc "sed -i 
's/^CheckSpace/#CheckSpace/g' /etc/pacman.conf"
 C:\tools\msys64\usr\bin\bash.exe -lc "export"
@@ -84,49 +122,30 @@ windows_msys2_task:
 tasklist
 C:\tools\msys64\usr\bin\bash.exe -lc "mv -f /etc/pacman.conf.pacnew 
/etc/pacman.conf || true"
 C:\tools\msys64\usr\bin\bash.exe -lc "pacman --noconfirm -Suu 
--overwrite=*"
-C:\tools\msys64\usr\bin\bash.exe -lc "pacman --noconfirm -S --needed \
-  diffutils git grep make pkg-config sed \
-  mingw-w64-x86_64-python \
-  mingw-w64-x86_64-toolchain \
-  mingw-w64-x86_64-SDL2 \
-  mingw-w64-x86_64-SDL2_image \
-  mingw-w64-x86_64-gtk3 \
-  mingw-w64-x86_64-glib2 \
-  mingw-w64-x86_64-ninja \
-  mingw-w64-x86_64-jemalloc \
-  mingw-w64-x86_64-lzo2 \
-  mingw-w64-x86_64-zstd \
-  mingw-w64-x86_64-libjpeg-turbo \
-  mingw-w64-x86_64-pixman \
-  mingw-w64-x86_64-libgcrypt \
-  mingw-w64-x86_64-libpng \
-  mingw-w64-x86_64-libssh \
-  mingw-w64-x86_64-libxml2 \
-  mingw-w64-x86_64-snappy \
-  mingw-w64-x86_64-libusb \
-  mingw-w64-x86_64-usbredir \
-  mingw-w64-x86_64-libtasn1 \
-  mingw-w64-x86_64-nettle \
-  mingw-w64-x86_64-cyrus-sasl \
-  mingw-w64-x86_64-curl \
-  mingw-w64-x86_64-gnutls \
-  mingw-w64-x86_64-libnfs \
-  "
-bitsadmin /transfer msys_download /dynamic /download /priority 
FOREGROUND `
-  
https://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-python-sphinx-2.3.1-1-any.pkg.tar.xz
 `
-  C:\tools\mingw-w64-x86_64-python-sphinx-2.3.1-1-any.pkg.tar.xz
-C:\tools\msys64\usr\bin\bash.exe -lc "pacman --noconfirm -U 

[PATCH 3/4] whpx: Fixes include of whp-dispatch.h in whpx.h

[Yonggang Luo]

Signed-off-by: Yonggang Luo 
---
 include/sysemu/whpx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/sysemu/whpx.h b/include/sysemu/whpx.h
index 9346fd92e9..0e6c9faaf6 100644
--- a/include/sysemu/whpx.h
+++ b/include/sysemu/whpx.h
@@ -15,7 +15,7 @@
 
 #ifdef CONFIG_WHPX
 
-#include "whp-dispatch.h"
+#include "target/i386/whpx/whp-dispatch.h"
 
 struct whpx_state {
 uint64_t mem_quota;
-- 
2.29.2.windows.3

[PATCH 1/4] cirrus/msys2: Exit powershell with $LastExitCode

[Yonggang Luo]

Currently if we don't exit with $LastExitCode manually,
the cirrus would not report the build/testing failure.

Signed-off-by: Yonggang Luo 
---
 .cirrus.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.cirrus.yml b/.cirrus.yml
index 62a9b57530..ff6adabd0d 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -131,5 +131,7 @@ windows_msys2_task:
 - C:\tools\msys64\usr\bin\bash.exe -lc "mkdir build"
 - C:\tools\msys64\usr\bin\bash.exe -lc "cd build && ../configure 
--python=python3"
 - C:\tools\msys64\usr\bin\bash.exe -lc "cd build && make -j8"
+- exit $LastExitCode
   test_script:
 - C:\tools\msys64\usr\bin\bash.exe -lc "cd build && make V=1 check"
+- exit $LastExitCode
-- 
2.29.2.windows.3

[PATCH 0/4] Fixes whpx build and improve Windows host CI

[Yonggang Luo]

Exit powershell with $LastExitCode so that the CI
would report the build/testing failure
Fixes include of whp-dispatch.h
Cache msys2 mingw with a proper fingerprint so
that only when msys2 packages are changed need
trigger the re-populate the cache

Yonggang Luo (4):
  cirrus/msys2: Exit powershell with $LastExitCode
  cirrus/msys2: Cache msys2 mingw in a better way.
  whpx: Fixes include of whp-dispatch.h in whpx.h
  maintainers: Add me as Windows Hosted Continuous Integration
maintainer

 .cirrus.yml   | 119 +-
 MAINTAINERS   |   6 +++
 include/sysemu/whpx.h |   2 +-
 3 files changed, 77 insertions(+), 50 deletions(-)

-- 
2.29.2.windows.3

Re: [PATCH v4 5/7] fuzz: set bits in operand of write/out to zero

[Alexander Bulekov]

On 201229 1240, Qiuhao Li wrote:
> Simplifying the crash cases by opportunistically setting bits in operands of
> out/write to zero may help to debug, since usually bit one means turn on or
> trigger a function while zero is the default turn-off setting.
> 
> Tested Bug 1908062.
> 
> Signed-off-by: Qiuhao Li 

Reviewed-by: Alexander Bulekov 

> ---
>  scripts/oss-fuzz/minimize_qtest_trace.py | 39 
>  1 file changed, 39 insertions(+)
> 
> diff --git a/scripts/oss-fuzz/minimize_qtest_trace.py 
> b/scripts/oss-fuzz/minimize_qtest_trace.py
> index 378a7ccec6..70ac0c5366 100755
> --- a/scripts/oss-fuzz/minimize_qtest_trace.py
> +++ b/scripts/oss-fuzz/minimize_qtest_trace.py
> @@ -164,6 +164,42 @@ def remove_minimizer(newtrace, outpath):
>  i += 1
>  
>  
> +def set_zero_minimizer(newtrace, outpath):
> +# try setting bits in operands of out/write to zero
> +i = 0
> +while i < len(newtrace):
> +if (not newtrace[i].startswith("write ") and not
> +   newtrace[i].startswith("out")):
> +   i += 1
> +   continue
> +# write ADDR SIZE DATA
> +# outx ADDR VALUE
> +print("\nzero setting bits: {}".format(newtrace[i]))
> +
> +prefix = " ".join(newtrace[i].split()[:-1])
> +data = newtrace[i].split()[-1]
> +data_bin = bin(int(data, 16))
> +data_bin_list = list(data_bin)
> +
> +for j in range(2, len(data_bin_list)):
> +prior = newtrace[i]
> +if (data_bin_list[j] == '1'):
> +data_bin_list[j] = '0'
> +data_try = hex(int("".join(data_bin_list), 2))
> +# It seems qtest only accepts padded hex-values.
> +if len(data_try) % 2 == 1:
> +data_try = data_try[:2] + "0" + data_try[2:-1]
> +
> +newtrace[i] = "{prefix} {data_try}\n".format(
> +prefix=prefix,
> +data_try=data_try)
> +
> +if not check_if_trace_crashes(newtrace, outpath):
> +data_bin_list[j] = '1'
> +newtrace[i] = prior
> +i += 1
> +
> +
>  def minimize_trace(inpath, outpath):
>  global TIMEOUT
>  with open(inpath) as f:
> @@ -184,7 +220,10 @@ def minimize_trace(inpath, outpath):
>  old_len = len(newtrace)
>  remove_minimizer(newtrace, outpath)
>  newtrace = list(filter(lambda s: s != "", newtrace))
> +assert(check_if_trace_crashes(newtrace, outpath))
>  
> +# set zero minimizer
> +set_zero_minimizer(newtrace, outpath)
>  assert(check_if_trace_crashes(newtrace, outpath))
>  
>  
> -- 
> 2.25.1
> 

Re: [PATCH v4 4/7] fuzz: loop the remove minimizer and refactoring

[Alexander Bulekov]

On 201229 1240, Qiuhao Li wrote:
> Now we use a one-time scan and remove strategy in the remval minimizer,
> which is not suitable for timing dependent instructions.
> 
> For example, instruction A will indicate an address where the config
> chunk locates, and instruction B will make the configuration active. If
> we have the following instruction sequence:
> 
> ...
> A1
> B1
> A2
> B2
> ...
> 
> A2 and B2 are the actual instructions that trigger the bug.
> 
> If we scan from top to bottom, after we remove A1, the behavior of B1
> might be unknowable, including not to crash the program. But we will
> successfully remove B1 later cause A2 and B2 will crash the process
> anyway:
> 
> ...
> A1
> A2
> B2
> ...
> 
> Now one more trimming will remove A1.
> 
> In the perfect case, we would need to be able to remove A and B (or C!) at
> the same time. But for now, let's just add a loop around the minimizer.
> 
> Since we only remove instructions, this iterative algorithm is converging.
> 
> Tested with Bug 1908062.
> 
> Signed-off-by: Qiuhao Li 

Small note below, but otherwise:
Reviewed-by: Alexander Bulekov 

> ---
>  scripts/oss-fuzz/minimize_qtest_trace.py | 41 +++-
>  1 file changed, 26 insertions(+), 15 deletions(-)
> 
> diff --git a/scripts/oss-fuzz/minimize_qtest_trace.py 
> b/scripts/oss-fuzz/minimize_qtest_trace.py
> index 1a26bf5b93..378a7ccec6 100755
> --- a/scripts/oss-fuzz/minimize_qtest_trace.py
> +++ b/scripts/oss-fuzz/minimize_qtest_trace.py
> @@ -71,21 +71,9 @@ def check_if_trace_crashes(trace, path):
>  return False
>  
>  
> -def minimize_trace(inpath, outpath):
> -global TIMEOUT
> -with open(inpath) as f:
> -trace = f.readlines()
> -start = time.time()
> -if not check_if_trace_crashes(trace, outpath):
> -sys.exit("The input qtest trace didn't cause a crash...")
> -end = time.time()
> -print("Crashed in {} seconds".format(end-start))
> -TIMEOUT = (end-start)*5
> -print("Setting the timeout for {} seconds".format(TIMEOUT))
> -
> -i = 0
> -newtrace = trace[:]
> +def remove_minimizer(newtrace, outpath):

Maybe a different name for this function?
e.g. minimize_each_line or minimize_iter

-Alex

>  remove_step = 1
> +i = 0
>  while i < len(newtrace):
>  # 1.) Try to remove lines completely and reproduce the crash.
>  # If it works, we're done.
> @@ -174,7 +162,30 @@ def minimize_trace(inpath, outpath):
>  newtrace[i] = prior[0]
>  del newtrace[i+1]
>  i += 1
> -check_if_trace_crashes(newtrace, outpath)
> +
> +
> +def minimize_trace(inpath, outpath):
> +global TIMEOUT
> +with open(inpath) as f:
> +trace = f.readlines()
> +start = time.time()
> +if not check_if_trace_crashes(trace, outpath):
> +sys.exit("The input qtest trace didn't cause a crash...")
> +end = time.time()
> +print("Crashed in {} seconds".format(end-start))
> +TIMEOUT = (end-start)*5
> +print("Setting the timeout for {} seconds".format(TIMEOUT))
> +
> +newtrace = trace[:]
> +
> +# remove minimizer
> +old_len = len(newtrace) + 1
> +while(old_len > len(newtrace)):
> +old_len = len(newtrace)
> +remove_minimizer(newtrace, outpath)
> +newtrace = list(filter(lambda s: s != "", newtrace))
> +
> +assert(check_if_trace_crashes(newtrace, outpath))
>  
>  
>  if __name__ == '__main__':
> -- 
> 2.25.1
> 

Re: [PATCH v4 3/7] fuzz: split write operand using binary approach

[Alexander Bulekov]

On 201229 1240, Qiuhao Li wrote:
> Currently, we split the write commands' data from the middle. If it does not
> work, try to move the pivot left by one byte and retry until there is no
> space.
> 
> But, this method has two flaws:
> 
> 1. It may fail to trim all unnecessary bytes on the right side.
> 
> For example, there is an IO write command:
> 
>   write addr uuuu
> 
> u is the unnecessary byte for the crash. Unlike ram write commands, in most
> case, a split IO write won't trigger the same crash, So if we split from the
> middle, we will get:
> 
>   write addr uu (will be removed in next round)
>   write addr uu
> 
> For uu, since split it from the middle and retry to the leftmost byte
> won't get the same crash, we will be stopped from removing the last two
> bytes.
> 
> 2. The algorithm complexity is O(n) since we move the pivot byte by byte.
> 
> To solve the first issue, we can try a symmetrical position on the right if
> we fail on the left. As for the second issue, instead moving by one byte, we
> can approach the boundary exponentially, achieving O(log(n)).
> 
> Give an example:
> 
>uu len=6
> +
> |
> +
>  xxx,xuu 6/2=3 fail
> +
>  +--+-+
>  ||
>  ++
>   xx,xxuu 6/2^2=1 fail u,u 6-1=5 success
>  +   +
>  +--++   |
>  |  |+-+ u removed
>  +  +
>xx,xxu 5/2=2 fail  ,u 6-2=4 success
>+
>|
>+---+ u removed
> 
> In some rare case, this algorithm will fail to trim all unnecessary bytes:
> 
>   xuxx
>   -xuxx Fail
>   -xuxx Fail
>   xuxx- Fail
>   ...
> 
> I think the trade-off is worth it.
> 
> Signed-off-by: Qiuhao Li 

Reviewed-by: Alexander Bulekov 

> ---
>  scripts/oss-fuzz/minimize_qtest_trace.py | 29 
>  1 file changed, 20 insertions(+), 9 deletions(-)
> 
> diff --git a/scripts/oss-fuzz/minimize_qtest_trace.py 
> b/scripts/oss-fuzz/minimize_qtest_trace.py
> index 0b665ae657..1a26bf5b93 100755
> --- a/scripts/oss-fuzz/minimize_qtest_trace.py
> +++ b/scripts/oss-fuzz/minimize_qtest_trace.py
> @@ -94,7 +94,7 @@ def minimize_trace(inpath, outpath):
>  prior = newtrace[i:i+remove_step]
>  for j in range(i, i+remove_step):
>  newtrace[j] = ""
> -print("Removing {lines} ...".format(lines=prior))
> +print("Removing {lines} ...\n".format(lines=prior))
>  if check_if_trace_crashes(newtrace, outpath):
>  i += remove_step
>  # Double the number of lines to remove for next round
> @@ -107,9 +107,11 @@ def minimize_trace(inpath, outpath):
>  remove_step = 1
>  continue
>  newtrace[i] = prior[0] # remove_step = 1
> +
>  # 2.) Try to replace write{bwlq} commands with a write addr, len
>  # command. Since this can require swapping endianness, try both LE 
> and
>  # BE options. We do this, so we can "trim" the writes in (3)
> +
>  if (newtrace[i].startswith("write") and not
>  newtrace[i].startswith("write ")):
>  suffix = newtrace[i].split()[0][-1]
> @@ -130,11 +132,15 @@ def minimize_trace(inpath, outpath):
>  newtrace[i] = prior[0]
>  
>  # 3.) If it is a qtest write command: write addr len data, try to 
> split
> -# it into two separate write commands. If splitting the write down 
> the
> -# middle does not work, try to move the pivot "left" and retry, until
> -# there is no space left. The idea is to prune unneccessary bytes 
> from
> -# long writes, while accommodating arbitrary MemoryRegion access 
> sizes
> -# and alignments.
> +# it into two separate write commands. If splitting the data operand
> +# from length/2^n bytes to the left does not work, try to move the 
> pivot
> +# to the right side, then add one to n, until length/2^n == 0. The 
> idea
> +# is to prune unneccessary bytes from long writes, while 
> accommodating
> +# arbitrary MemoryRegion access sizes and alignments.
> +
> +# This algorithm will fail under some rare situations.
> +# e.g., xuxx (u is the unnecessary byte)
> +
>  if newtrace[i].startswith("write "):
>  addr = int(newtrace[i].split()[1], 16)
>  length = int(newtrace[i].split()[2], 16)
> @@ -143,6 +149,7 @@ def minimize_trace(inpath, outpath):
>  leftlength = int(length/2)
>  rightlength = length - leftlength
>  newtrace.insert(i+1, "")
> +

Re: [PATCH v4 2/7] fuzz: double the IOs to remove for every loop

[Alexander Bulekov]

On 201229 1240, Qiuhao Li wrote:
> Instead of removing IO instructions one by one, we can try deleting multiple
> instructions at once. According to the locality of reference, we double the
> number of instructions to remove for the next round and recover it to one
> once we fail.
> 
> This patch is usually significant for large input.
> 
> Test with quadrupled trace input at:
>   https://bugs.launchpad.net/qemu/+bug/1890333/comments/1
> 
> Patched 1/6 version:
>   real  0m45.904s
>   user  0m16.874s
>   sys   0m10.042s
> 
> Refined version:
>   real  0m11.412s
>   user  0m6.888s
>   sys   0m3.325s
> 
> Signed-off-by: Qiuhao Li 

Reviewed-by: Alexander Bulekov 

> ---
>  scripts/oss-fuzz/minimize_qtest_trace.py | 33 +++-
>  1 file changed, 21 insertions(+), 12 deletions(-)
> 
> diff --git a/scripts/oss-fuzz/minimize_qtest_trace.py 
> b/scripts/oss-fuzz/minimize_qtest_trace.py
> index aa69c7963e..0b665ae657 100755
> --- a/scripts/oss-fuzz/minimize_qtest_trace.py
> +++ b/scripts/oss-fuzz/minimize_qtest_trace.py
> @@ -85,19 +85,28 @@ def minimize_trace(inpath, outpath):
>  
>  i = 0
>  newtrace = trace[:]
> -# For each line
> +remove_step = 1
>  while i < len(newtrace):
> -# 1.) Try to remove it completely and reproduce the crash. If it 
> works,
> -# we're done.
> -prior = newtrace[i]
> -print("Trying to remove {}".format(newtrace[i]))
> -# Try to remove the line completely
> -newtrace[i] = ""
> +# 1.) Try to remove lines completely and reproduce the crash.
> +# If it works, we're done.
> +if (i+remove_step) >= len(newtrace):
> +remove_step = 1
> +prior = newtrace[i:i+remove_step]
> +for j in range(i, i+remove_step):
> +newtrace[j] = ""
> +print("Removing {lines} ...".format(lines=prior))
>  if check_if_trace_crashes(newtrace, outpath):
> -i += 1
> +i += remove_step
> +# Double the number of lines to remove for next round
> +remove_step *= 2
>  continue
> -newtrace[i] = prior
> -
> +# Failed to remove multiple IOs, fast recovery
> +if remove_step > 1:
> +for j in range(i, i+remove_step):
> +newtrace[j] = prior[j-i]
> +remove_step = 1
> +continue
> +newtrace[i] = prior[0] # remove_step = 1
>  # 2.) Try to replace write{bwlq} commands with a write addr, len
>  # command. Since this can require swapping endianness, try both LE 
> and
>  # BE options. We do this, so we can "trim" the writes in (3)
> @@ -118,7 +127,7 @@ def minimize_trace(inpath, outpath):
>  if(check_if_trace_crashes(newtrace, outpath)):
>  break
>  else:
> -newtrace[i] = prior
> +newtrace[i] = prior[0]
>  
>  # 3.) If it is a qtest write command: write addr len data, try to 
> split
>  # it into two separate write commands. If splitting the write down 
> the
> @@ -151,7 +160,7 @@ def minimize_trace(inpath, outpath):
>  if check_if_trace_crashes(newtrace, outpath):
>  i -= 1
>  else:
> -newtrace[i] = prior
> +newtrace[i] = prior[0]
>  del newtrace[i+1]
>  i += 1
>  check_if_trace_crashes(newtrace, outpath)
> -- 
> 2.25.1
> 

Re: [PATCH v4 1/7] fuzz: accelerate non-crash detection

[Alexander Bulekov]

On 201229 1240, Qiuhao Li wrote:
> We spend much time waiting for the timeout program during the minimization
> process until it passes a time limit. This patch hacks the CLOSED (indicates
> the redirection file closed) notification in QTest's output if it doesn't
> crash.
> 
> Test with quadrupled trace input at:
>   https://bugs.launchpad.net/qemu/+bug/1890333/comments/1
> 
> Original version:
>   real1m37.246s
>   user0m13.069s
>   sys 0m8.399s
> 
> Refined version:
>   real0m45.904s
>   user0m16.874s
>   sys 0m10.042s
> 
> Signed-off-by: Qiuhao Li 
> ---
>  scripts/oss-fuzz/minimize_qtest_trace.py | 41 
>  1 file changed, 28 insertions(+), 13 deletions(-)
> 
> diff --git a/scripts/oss-fuzz/minimize_qtest_trace.py 
> b/scripts/oss-fuzz/minimize_qtest_trace.py
> index 5e405a0d5f..aa69c7963e 100755
> --- a/scripts/oss-fuzz/minimize_qtest_trace.py
> +++ b/scripts/oss-fuzz/minimize_qtest_trace.py
> @@ -29,30 +29,46 @@ whether the crash occred. Optionally, manually set a 
> string that idenitifes the
>  crash by setting CRASH_TOKEN=
>  """.format((sys.argv[0])))
>  
> +deduplication_note = """\n\
> +Note: While trimming the input, sometimes the mutated trace triggers a 
> different
> +crash output but indicates the same bug. Under this situation, our minimizer 
> is
> +incapable of recognizing and stopped from removing it. In the future, we may
> +use a more sophisticated crash case deduplication method.
> +\n"""
> +
>  def check_if_trace_crashes(trace, path):
> -global CRASH_TOKEN
>  with open(path, "w") as tracefile:
>  tracefile.write("".join(trace))
>  
> -rc = subprocess.Popen("timeout -s 9 {timeout}s {qemu_path} {qemu_args} 
> 2>&1\
> +proc = subprocess.Popen("timeout {timeout}s {qemu_path} {qemu_args} 2>&1\

Why remove the -s 9 here? I ran into a case where the minimizer got
stuck on one iteration. Adding back "sigkill" to the timeout can be a
safety net to catch those bad cases.
-Alex

>  < {trace_path}".format(timeout=TIMEOUT,
> qemu_path=QEMU_PATH,
> qemu_args=QEMU_ARGS,
> trace_path=path),
>shell=True,
>stdin=subprocess.PIPE,
> -  stdout=subprocess.PIPE)
> -stdo = rc.communicate()[0]
> -output = stdo.decode('unicode_escape')
> -if rc.returncode == 137:# Timed Out
> -return False
> -if len(output.splitlines()) < 2:
> -return False
> -
> +  stdout=subprocess.PIPE,
> +  encoding="utf-8")
> +global CRASH_TOKEN
>  if CRASH_TOKEN is None:
> -CRASH_TOKEN = output.splitlines()[-2]
> +try:
> +outs, _ = proc.communicate(timeout=5)
> +CRASH_TOKEN = outs.splitlines()[-2]
> +except subprocess.TimeoutExpired:
> +print("subprocess.TimeoutExpired")
> +return False
> +print("Identifying Crashes by this string: {}".format(CRASH_TOKEN))
> +global deduplication_note
> +print(deduplication_note)
> +return True
>  
> -return CRASH_TOKEN in output
> +for line in iter(proc.stdout.readline, b''):
> +if "CLOSED" in line:
> +return False
> +if CRASH_TOKEN in line:
> +return True
> +
> +return False
>  
>  
>  def minimize_trace(inpath, outpath):
> @@ -66,7 +82,6 @@ def minimize_trace(inpath, outpath):
>  print("Crashed in {} seconds".format(end-start))
>  TIMEOUT = (end-start)*5
>  print("Setting the timeout for {} seconds".format(TIMEOUT))
> -print("Identifying Crashes by this string: {}".format(CRASH_TOKEN))
>  
>  i = 0
>  newtrace = trace[:]
> -- 
> 2.25.1
> 

Re: [PATCH v2 02/24] target/mips/translate: Expose check_mips_64() to 32-bit mode

[Jiaxun Yang]

在 2021/1/7 上午2:37, Philippe Mathieu-Daudé 写道:

On Wed, Jan 6, 2021 at 7:20 PM Philippe Mathieu-Daudé  wrote:

Hi,

ping for code review? :)

FWIW the full series (rebased on mips-next) is available here:
https://gitlab.com/philmd/qemu/-/commits/mips_msa_decodetree


Reviewed-by: Jiaxun Yang 

- Jiaxun




Due to the "Simplify ISA definitions"
https://www.mail-archive.com/qemu-devel@nongnu.org/msg770056.html
patch #3 is not necessary.

This is the last patch unreviewed.

On 12/15/20 11:57 PM, Philippe Mathieu-Daudé wrote:

To allow compiling 64-bit specific translation code more
generically (and removing #ifdef'ry), allow compiling
check_mips_64() on 32-bit targets.
If ever called on 32-bit, we obviously emit a reserved
instruction exception.

Signed-off-by: Philippe Mathieu-Daudé 
---
  target/mips/translate.h | 2 --
  target/mips/translate.c | 8 +++-
  2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/target/mips/translate.h b/target/mips/translate.h
index a9eab69249f..942d803476c 100644
--- a/target/mips/translate.h
+++ b/target/mips/translate.h
@@ -127,9 +127,7 @@ void generate_exception_err(DisasContext *ctx, int excp, 
int err);
  void generate_exception_end(DisasContext *ctx, int excp);
  void gen_reserved_instruction(DisasContext *ctx);
  void check_insn(DisasContext *ctx, uint64_t flags);
-#ifdef TARGET_MIPS64
  void check_mips_64(DisasContext *ctx);
-#endif
  void check_cp1_enabled(DisasContext *ctx);

  void gen_base_offset_addr(DisasContext *ctx, TCGv addr, int base, int offset);
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 5c62b32c6ae..af543d1f375 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -2972,18 +2972,16 @@ static inline void check_ps(DisasContext *ctx)
  check_cp1_64bitmode(ctx);
  }

-#ifdef TARGET_MIPS64
  /*
- * This code generates a "reserved instruction" exception if 64-bit
- * instructions are not enabled.
+ * This code generates a "reserved instruction" exception if cpu is not
+ * 64-bit or 64-bit instructions are not enabled.
   */
  void check_mips_64(DisasContext *ctx)
  {
-if (unlikely(!(ctx->hflags & MIPS_HFLAG_64))) {
+if (unlikely((TARGET_LONG_BITS != 64) || !(ctx->hflags & MIPS_HFLAG_64))) {

Since TARGET_LONG_BITS is known at build time, this can be simplified
as:

if ((TARGET_LONG_BITS != 64) || unlikely!(ctx->hflags & MIPS_HFLAG_64)))


  gen_reserved_instruction(ctx);
  }
  }
-#endif

  #ifndef CONFIG_USER_ONLY
  static inline void check_mvh(DisasContext *ctx)

Re: [PATCH v4 1/7] fuzz: accelerate non-crash detection

[Alexander Bulekov]

On 201229 1240, Qiuhao Li wrote:
> We spend much time waiting for the timeout program during the minimization
> process until it passes a time limit. This patch hacks the CLOSED (indicates
> the redirection file closed) notification in QTest's output if it doesn't
> crash.
> 
> Test with quadrupled trace input at:
>   https://bugs.launchpad.net/qemu/+bug/1890333/comments/1
> 
> Original version:
>   real1m37.246s
>   user0m13.069s
>   sys 0m8.399s
> 
> Refined version:
>   real0m45.904s
>   user0m16.874s
>   sys 0m10.042s
> 
> Signed-off-by: Qiuhao Li 

This makes a huge difference, thanks! Maybe there is some edge-case
where the crash happens after "CLOSED" (e.g. a timer fires after the
last command), but I haven't found such an example among existing
reproducers.

Reviewed-by: Alexander Bulekov 

> ---
>  scripts/oss-fuzz/minimize_qtest_trace.py | 41 
>  1 file changed, 28 insertions(+), 13 deletions(-)
> 
> diff --git a/scripts/oss-fuzz/minimize_qtest_trace.py 
> b/scripts/oss-fuzz/minimize_qtest_trace.py
> index 5e405a0d5f..aa69c7963e 100755
> --- a/scripts/oss-fuzz/minimize_qtest_trace.py
> +++ b/scripts/oss-fuzz/minimize_qtest_trace.py
> @@ -29,30 +29,46 @@ whether the crash occred. Optionally, manually set a 
> string that idenitifes the
>  crash by setting CRASH_TOKEN=
>  """.format((sys.argv[0])))
>  
> +deduplication_note = """\n\
> +Note: While trimming the input, sometimes the mutated trace triggers a 
> different
> +crash output but indicates the same bug. Under this situation, our minimizer 
> is
> +incapable of recognizing and stopped from removing it. In the future, we may
> +use a more sophisticated crash case deduplication method.
> +\n"""
> +
>  def check_if_trace_crashes(trace, path):
> -global CRASH_TOKEN
>  with open(path, "w") as tracefile:
>  tracefile.write("".join(trace))
>  
> -rc = subprocess.Popen("timeout -s 9 {timeout}s {qemu_path} {qemu_args} 
> 2>&1\
> +proc = subprocess.Popen("timeout {timeout}s {qemu_path} {qemu_args} 2>&1\
>  < {trace_path}".format(timeout=TIMEOUT,
> qemu_path=QEMU_PATH,
> qemu_args=QEMU_ARGS,
> trace_path=path),
>shell=True,
>stdin=subprocess.PIPE,
> -  stdout=subprocess.PIPE)
> -stdo = rc.communicate()[0]
> -output = stdo.decode('unicode_escape')
> -if rc.returncode == 137:# Timed Out
> -return False
> -if len(output.splitlines()) < 2:
> -return False
> -
> +  stdout=subprocess.PIPE,
> +  encoding="utf-8")
> +global CRASH_TOKEN
>  if CRASH_TOKEN is None:
> -CRASH_TOKEN = output.splitlines()[-2]
> +try:
> +outs, _ = proc.communicate(timeout=5)
> +CRASH_TOKEN = outs.splitlines()[-2]
> +except subprocess.TimeoutExpired:
> +print("subprocess.TimeoutExpired")
> +return False
> +print("Identifying Crashes by this string: {}".format(CRASH_TOKEN))
> +global deduplication_note
> +print(deduplication_note)
> +return True
>  
> -return CRASH_TOKEN in output
> +for line in iter(proc.stdout.readline, b''):
> +if "CLOSED" in line:
> +return False
> +if CRASH_TOKEN in line:
> +return True
> +
> +return False
>  
>  
>  def minimize_trace(inpath, outpath):
> @@ -66,7 +82,6 @@ def minimize_trace(inpath, outpath):
>  print("Crashed in {} seconds".format(end-start))
>  TIMEOUT = (end-start)*5
>  print("Setting the timeout for {} seconds".format(TIMEOUT))
> -print("Identifying Crashes by this string: {}".format(CRASH_TOKEN))
>  
>  i = 0
>  newtrace = trace[:]
> -- 
> 2.25.1
> 

[Bug 1909418] Re: QEMU: Heap Overflow vulnerability in SDHCI Component

[Muhammad Ramdhan]

** Information type changed from Private Security to Public Security

-- 
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:
  New

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:1501
  #15 0x55f8049419ce in flatview_write_continue 

Re: [RFC PATCH 0/2] Pegasos2 emulation

[BALATON Zoltan]

On Wed, 6 Jan 2021, BALATON Zoltan wrote:

Hello,

This is adding a new PPC board called pegasos2 currently posted as RFC
because it depends on not yet merged VT8231 emulation currently on the
list:

https://patchew.org/QEMU/cover.1609967638.git.bala...@eik.bme.hu/

and may need some changes like a test case but I'm posting it now for
getting feedback on what's needed to merge this. More info on it can
be found at:

https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2

Currently it needs a firmware ROM image that I cannot include due to
original copyright holder (bPlan) did not release it under a free
licence but I have plans to write a replacement in the future. With
that firmware it can boot MorphOS now as:

qemu-system-ppc -M pegasos2 -cdrom morphos.iso -device ati-vga,romfile="" 
-serial stdio

then enter "boot cd boot.img" at the firmware "ok" prompt as described
in the MorphOS.readme. To boot Linux use same command line with e.g.
-cdrom debian-8.11.0-powerpc-netinst.iso then enter
"boot cd install/pegasos"

Patch 2 adds the actual board code after patch 1 adding MV64361 system
controller chip. The mv643xx.h header file is taken from Linux and
produces a bunch of checkpatch warnings due to different formatting
rules it follows, I'm not sure we want to adopt it or keep it as it is
given that it does not appear any more in recent Linux versions so we
could reformat it as it's unlikely to get updated in the future.


Interestingly it applies for patchew while this was accidentally based on 
my previous series that has hw/ppc/Kconfig reverts so it does not apply on 
current master. Also missing a file so does not compile but other than 
that the content could be reviewed. I've now updated this repo:


https://osdn.net/projects/qmiga/scm/git/qemu/tree/pegasos2/

which contains all the needed patches over QEMU master at one place in 
case somebody wants to try this. I'll send an updated version later after 
I get some feedback.


The command lines above also need -bios /path/to/firmware.rom

Regards,
BALATON Zoltan


BALATON Zoltan (2):
 hw/pci-host: Add emulation of Marvell MV64361 PPC system controller
 hw/ppc: Add emulation of Genesi/bPlan Pegasos II

default-configs/devices/ppc-softmmu.mak |   2 +
hw/pci-host/Kconfig |   3 +
hw/pci-host/meson.build |   2 +
hw/pci-host/mv64361.c   | 966 
hw/pci-host/mv643xx.h   | 919 ++
hw/pci-host/trace-events|   6 +
hw/ppc/Kconfig  |  10 +
hw/ppc/meson.build  |   2 +
hw/ppc/pegasos2.c   | 144 
9 files changed, 2054 insertions(+)
create mode 100644 hw/pci-host/mv64361.c
create mode 100644 hw/pci-host/mv643xx.h
create mode 100644 hw/ppc/pegasos2.c

[Bug 1901359] Re: ignore bit 0 in pci CONFIG_ADDRESS register write for Type 1 access

[cinap_lenrek]

is anybody home?

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

Title:
  ignore bit 0 in pci CONFIG_ADDRESS register write for Type 1 access

Status in QEMU:
  New

Bug description:
  I'v recently stumbled upon a bug in the Plan9 PCI config space access
  routines for config mode #1.

  The code used to set bit 0 in the CONFIG_ADDRESS register for a Type 1
  access.

  This was most likely a misreading of the PCI local bus specification
  on our side.

  However, in the PCI local bus specification 3.0, it states the
  following:

  > 3.2.2.3.2 Software Generation of Configuration Transactions
  > ...
  > For Type 1 translations, the host bridge directly copies the contents of the
  > CONFIG_ADDRESS register (excluding bits 31 and 0) onto the PCI AD lines 
during the
  > address phase of a configuration transaction making sure that AD[1::0] is 
"01".

  note the: "excluding bits 31 and 0"

  What happens in qemu instead is that it uses bit 0 of the CONFIG_ADDRESS
  register as part of the register offset (when it probably should ignore it)
  when translating from Type 1 to Type 0 address. So once it reaches the device
  behind the bridge the register address is off by one.

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

Re: [RFC PATCH 0/2] Pegasos2 emulation

[no-reply]

Patchew URL: https://patchew.org/QEMU/cover.1609973005.git.bala...@eik.bme.hu/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: cover.1609973005.git.bala...@eik.bme.hu
Subject: [RFC PATCH 0/2] Pegasos2 emulation

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/cover.1609973005.git.bala...@eik.bme.hu -> 
patchew/cover.1609973005.git.bala...@eik.bme.hu
Switched to a new branch 'test'
2d34410 hw/ppc: Add emulation of Genesi/bPlan Pegasos II
f987fbe hw/pci-host: Add emulation of Marvell MV64361 PPC system controller

=== OUTPUT BEGIN ===
1/2 Checking commit f987fbe9b10b (hw/pci-host: Add emulation of Marvell MV64361 
PPC system controller)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#42: 
new file mode 100644

WARNING: line over 80 characters
#298: FILE: hw/pci-host/mv64361.c:252:
+trace_mv64361_region_enable(!(val & mask) ? "enable" : "disable", 
i);

ERROR: code indent should never use tabs
#1023: FILE: hw/pci-host/mv643xx.h:5:
+ * ^IAuthor: Matthew Dharm $

WARNING: architecture specific defines should be avoided
#1031: FILE: hw/pci-host/mv643xx.h:13:
+#ifndef __ASM_MV643XX_H

WARNING: Block comments use a leading /* on a separate line
#1093: FILE: hw/pci-host/mv643xx.h:75:
+/* Enables the CS , DEV_CS , PCI 0 and PCI 1

WARNING: Block comments use * on subsequent lines
#1094: FILE: hw/pci-host/mv643xx.h:76:
+/* Enables the CS , DEV_CS , PCI 0 and PCI 1
+   windows above */

WARNING: Block comments use a trailing */ on a separate line
#1094: FILE: hw/pci-host/mv643xx.h:76:
+   windows above */

ERROR: code indent should never use tabs
#1197: FILE: hw/pci-host/mv643xx.h:179:
+/*  CPU Interface Debug Registers ^I*/$

ERROR: code indent should never use tabs
#1274: FILE: hw/pci-host/mv643xx.h:256:
+/* Device Parameters^I^I^I*/$

ERROR: code indent should never use tabs
#1277: FILE: hw/pci-host/mv643xx.h:259:
+#define MV64340_DEVICE_BANK0_PARAMETERS^I^I^I^I0x45c$

ERROR: code indent should never use tabs
#1278: FILE: hw/pci-host/mv643xx.h:260:
+#define MV64340_DEVICE_BANK1_PARAMETERS^I^I^I^I0x460$

ERROR: code indent should never use tabs
#1279: FILE: hw/pci-host/mv643xx.h:261:
+#define MV64340_DEVICE_BANK2_PARAMETERS^I^I^I^I0x464$

ERROR: code indent should never use tabs
#1280: FILE: hw/pci-host/mv643xx.h:262:
+#define MV64340_DEVICE_BANK3_PARAMETERS^I^I^I^I0x468$

ERROR: code indent should never use tabs
#1281: FILE: hw/pci-host/mv643xx.h:263:
+#define MV64340_DEVICE_BOOT_BANK_PARAMETERS^I^I^I0x46c$

ERROR: code indent should never use tabs
#1288: FILE: hw/pci-host/mv643xx.h:270:
+/* Device interrupt registers^I^I*/$

ERROR: code indent should never use tabs
#1291: FILE: hw/pci-host/mv643xx.h:273:
+#define MV64340_DEVICE_INTERRUPT_CAUSE^I^I^I^I0x4d0$

ERROR: code indent should never use tabs
#1292: FILE: hw/pci-host/mv643xx.h:274:
+#define MV64340_DEVICE_INTERRUPT_MASK^I^I^I^I0x4d4$

ERROR: code indent should never use tabs
#1293: FILE: hw/pci-host/mv643xx.h:275:
+#define MV64340_DEVICE_ERROR_ADDR^I^I^I^I0x4d8$

ERROR: code indent should never use tabs
#1294: FILE: hw/pci-host/mv643xx.h:276:
+#define MV64340_DEVICE_ERROR_DATA   ^I^I^I^I0x4dc$

ERROR: code indent should never use tabs
#1295: FILE: hw/pci-host/mv643xx.h:277:
+#define MV64340_DEVICE_ERROR_PARITY ^I^I^I0x4e0$

ERROR: code indent should never use tabs
#1298: FILE: hw/pci-host/mv643xx.h:280:
+/* Device debug registers   ^I^I*/$

ERROR: code indent should never use tabs
#1301: FILE: hw/pci-host/mv643xx.h:283:
+#define MV64340_DEVICE_DEBUG_LOW ^I^I^I^I0x4e4$

ERROR: code indent should never use tabs
#1302: FILE: hw/pci-host/mv643xx.h:284:
+#define MV64340_DEVICE_DEBUG_HIGH ^I^I^I^I0x4e8$

ERROR: code indent should never use tabs
#1341: FILE: hw/pci-host/mv643xx.h:323:
+#define MV64340_PCI_0_CS_0_BASE_ADDR_REMAP^I^I^I0xc48$

ERROR: code indent should never use tabs
#1342: FILE: hw/pci-host/mv643xx.h:324:
+#define MV64340_PCI_1_CS_0_BASE_ADDR_REMAP^I^I^I0xcc8$

ERROR: code indent should never use tabs
#1343: FILE: hw/pci-host/mv643xx.h:325:
+#define MV64340_PCI_0_CS_1_BASE_ADDR_REMAP^I^I^I0xd48$

ERROR: code indent should never use tabs
#1344: FILE: hw/pci-host/mv643xx.h:326:
+#define MV64340_PCI_1_CS_1_BASE_ADDR_REMAP^I^I^I0xdc8$

ERROR: code indent should never use tabs
#1345: FILE: hw/pci-host/mv643xx.h:327:
+#define MV64340_PCI_0_CS_2_BASE_ADDR_REMAP^I^I^I0xc4c$

ERROR: code indent should never use tabs
#1346: FILE: hw/pci-host/mv643xx.h:328:
+#define MV64340_PCI_1_CS_2_BASE_ADDR_REMAP^I^I^I0xccc$

ERROR: 

[RFC PATCH 2/2] hw/ppc: Add emulation of Genesi/bPlan Pegasos II

[BALATON Zoltan]

Add new machine called pegasos2 emulating the Genesi/bPlan Pegasos II,
a PowerPC board based on the Marvell MV64361 system controller and the
VIA VT8231 integrated south bridge/superio chips. It can run Linux,
AmigaOS and a wide range of MorphOS versions. Currently a firmware ROM
image is needed to boot and only MorphOS has a video driver to produce
graphics output. Linux could work too but distros that supported this
machine don't include usual video drivers so those only run with
serial console for now.

Signed-off-by: BALATON Zoltan 
---
 default-configs/devices/ppc-softmmu.mak |   2 +
 hw/ppc/Kconfig  |  10 ++
 hw/ppc/meson.build  |   2 +
 hw/ppc/pegasos2.c   | 144 
 4 files changed, 158 insertions(+)
 create mode 100644 hw/ppc/pegasos2.c

diff --git a/default-configs/devices/ppc-softmmu.mak 
b/default-configs/devices/ppc-softmmu.mak
index 61b78b844d..4535993d8d 100644
--- a/default-configs/devices/ppc-softmmu.mak
+++ b/default-configs/devices/ppc-softmmu.mak
@@ -14,5 +14,7 @@ CONFIG_SAM460EX=y
 CONFIG_MAC_OLDWORLD=y
 CONFIG_MAC_NEWWORLD=y
 
+CONFIG_PEGASOS2=y
+
 # For PReP
 CONFIG_PREP=y
diff --git a/hw/ppc/Kconfig b/hw/ppc/Kconfig
index d11dc30509..98d8dd1a84 100644
--- a/hw/ppc/Kconfig
+++ b/hw/ppc/Kconfig
@@ -68,6 +68,16 @@ config SAM460EX
 select USB_OHCI
 select FDT_PPC
 
+config PEGASOS2
+bool
+select MV64361
+select VT82C686
+select IDE_VIA
+select SMBUS_EEPROM
+# These should come with VT82C686
+select APM
+select ACPI_X86
+
 config PREP
 bool
 imply PCI_DEVICES
diff --git a/hw/ppc/meson.build b/hw/ppc/meson.build
index ffa2ec37fa..66a69898d2 100644
--- a/hw/ppc/meson.build
+++ b/hw/ppc/meson.build
@@ -77,5 +77,7 @@ ppc_ss.add(when: 'CONFIG_E500', if_true: files(
 ))
 # PowerPC 440 Xilinx ML507 reference board.
 ppc_ss.add(when: 'CONFIG_VIRTEX', if_true: files('virtex_ml507.c'))
+# Pegasos2
+ppc_ss.add(when: 'CONFIG_PEGASOS2', if_true: files('pegasos2.c'))
 
 hw_arch += {'ppc': ppc_ss}
diff --git a/hw/ppc/pegasos2.c b/hw/ppc/pegasos2.c
new file mode 100644
index 00..49c440cfc5
--- /dev/null
+++ b/hw/ppc/pegasos2.c
@@ -0,0 +1,144 @@
+/*
+ * QEMU PowerPC CHRP (Genesi/bPlan Pegasos II) hardware System Emulator
+ *
+ * Copyright (c) 2018-2020 BALATON Zoltan
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "hw/ppc/ppc.h"
+#include "hw/sysbus.h"
+#include "hw/pci/pci_host.h"
+#include "hw/irq.h"
+#include "hw/pci-host/mv64361.h"
+#include "hw/isa/vt82c686.h"
+#include "hw/ide/pci.h"
+#include "hw/i2c/smbus_eeprom.h"
+#include "hw/qdev-properties.h"
+#include "sysemu/reset.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "hw/fw-path-provider.h"
+#include "elf.h"
+#include "qemu/log.h"
+#include "qemu/error-report.h"
+#include "sysemu/kvm.h"
+#include "kvm_ppc.h"
+#include "exec/address-spaces.h"
+#include "trace.h"
+#include "qemu/datadir.h"
+#include "sysemu/device_tree.h"
+
+#define PROM_FILENAME "pegrom.bin"
+#define PROM_ADDR 0xfff0
+#define PROM_SIZE 0x8
+
+#define BUS_FREQ 1
+
+static void pegasos2_reset(void *opaque)
+{
+PowerPCCPU *cpu = opaque;
+
+cpu_reset(CPU(cpu));
+cpu->env.spr[SPR_HID1] = 7ULL << 28;
+}
+
+static void pegasos2_init(MachineState *machine)
+{
+PowerPCCPU *cpu = NULL;
+MemoryRegion *rom = g_new(MemoryRegion, 1);
+DeviceState *mv;
+PCIBus *pci_bus;
+PCIDevice *dev;
+I2CBus *i2c_bus;
+const char *fwname = machine->firmware ?: PROM_FILENAME;
+char *filename;
+int sz;
+uint8_t *spd_data;
+
+/* init CPU */
+cpu = POWERPC_CPU(cpu_create(machine->cpu_type));
+if (PPC_INPUT(>env) != PPC_FLAGS_INPUT_6xx) {
+error_report("Incompatible CPU, only 6xx bus supported");
+exit(1);
+}
+
+/* Set time-base frequency */
+cpu_ppc_tb_init(>env, BUS_FREQ / 4);
+qemu_register_reset(pegasos2_reset, cpu);
+
+/* RAM */
+memory_region_add_subregion(get_system_memory(), 0, machine->ram);
+
+/* allocate and load firmware */
+filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, fwname);
+if (!filename) {
+error_report("Could not find firmware '%s'", fwname);
+exit(1);
+}
+memory_region_init_rom(rom, NULL, "pegasos2.rom", PROM_SIZE, _fatal);
+memory_region_add_subregion(get_system_memory(), PROM_ADDR, rom);
+sz = load_elf(filename, NULL, NULL, NULL, NULL, NULL, NULL, NULL, 1,
+  PPC_ELF_MACHINE, 0, 0);
+if (sz <= 0) {
+sz = load_image_targphys(filename, PROM_ADDR, PROM_SIZE);
+}
+if (sz <= 0 || sz > PROM_SIZE) {
+error_report("Could not load firmware '%s'", filename);
+exit(1);
+}
+g_free(filename);
+
+/* Marvell Discovery II system controller */
+mv = 

[RFC PATCH 1/2] hw/pci-host: Add emulation of Marvell MV64361 PPC system controller

[BALATON Zoltan]

The Marvell Discovery II aka. MV64361 is a PowerPC system controller
chip that is used on the pegasos2 PPC board. This adds emulation of it
that models the device enough to boot guests on this board. The
mv643xx.h header with register definitions is taken from Linux 4.15.10
only fixing end of line white space errors and removing not needed
parts, it's otherwise keeps Linux formatting.

Signed-off-by: BALATON Zoltan 
---
 hw/pci-host/Kconfig  |   3 +
 hw/pci-host/meson.build  |   2 +
 hw/pci-host/mv64361.c| 966 +++
 hw/pci-host/mv643xx.h| 919 +
 hw/pci-host/trace-events |   6 +
 5 files changed, 1896 insertions(+)
 create mode 100644 hw/pci-host/mv64361.c
 create mode 100644 hw/pci-host/mv643xx.h

diff --git a/hw/pci-host/Kconfig b/hw/pci-host/Kconfig
index eb03f0489d..a3b0e4ec65 100644
--- a/hw/pci-host/Kconfig
+++ b/hw/pci-host/Kconfig
@@ -65,3 +65,6 @@ config PCI_POWERNV
 select PCI_EXPRESS
 select MSI_NONBROKEN
 select PCIE_PORT
+
+config MV64361
+bool
diff --git a/hw/pci-host/meson.build b/hw/pci-host/meson.build
index da9d1a9964..cc7f2c1c0c 100644
--- a/hw/pci-host/meson.build
+++ b/hw/pci-host/meson.build
@@ -17,6 +17,8 @@ pci_ss.add(when: 'CONFIG_GRACKLE_PCI', if_true: 
files('grackle.c'))
 pci_ss.add(when: 'CONFIG_UNIN_PCI', if_true: files('uninorth.c'))
 # PowerPC E500 boards
 pci_ss.add(when: 'CONFIG_PPCE500_PCI', if_true: files('ppce500.c'))
+# Pegasos2
+pci_ss.add(when: 'CONFIG_MV64361', if_true: files('mv64361.c'))
 
 # ARM devices
 pci_ss.add(when: 'CONFIG_VERSATILE_PCI', if_true: files('versatile.c'))
diff --git a/hw/pci-host/mv64361.c b/hw/pci-host/mv64361.c
new file mode 100644
index 00..b8df34b337
--- /dev/null
+++ b/hw/pci-host/mv64361.c
@@ -0,0 +1,966 @@
+/*
+ * Marvell Discovery II MV64361 System Controller for
+ * QEMU PowerPC CHRP (Genesi/bPlan Pegasos II) hardware System Emulator
+ *
+ * Copyright (c) 2018-2020 BALATON Zoltan
+ *
+ * This work is licensed under the GNU GPL license version 2 or later.
+ *
+ */
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "hw/sysbus.h"
+#include "hw/pci/pci.h"
+#include "hw/pci/pci_host.h"
+#include "hw/irq.h"
+#include "hw/intc/i8259.h"
+#include "hw/qdev-properties.h"
+#include "exec/address-spaces.h"
+#include "qemu/log.h"
+#include "qemu/error-report.h"
+#include "trace.h"
+#include "hw/pci-host/mv64361.h"
+#include "mv643xx.h"
+
+#define TYPE_MV64361_PCI_BRIDGE "mv64361-pcibridge"
+
+static void mv64361_pcibridge_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+
+k->vendor_id = PCI_VENDOR_ID_MARVELL;
+k->device_id = 0x6460;
+k->class_id = PCI_CLASS_BRIDGE_HOST;
+/*
+ * PCI-facing part of the host bridge,
+ * not usable without the host-facing part
+ */
+dc->user_creatable = false;
+}
+
+static const TypeInfo mv64361_pcibridge_info = {
+.name  = TYPE_MV64361_PCI_BRIDGE,
+.parent= TYPE_PCI_DEVICE,
+.instance_size = sizeof(PCIDevice),
+.class_init= mv64361_pcibridge_class_init,
+.interfaces = (InterfaceInfo[]) {
+{ INTERFACE_CONVENTIONAL_PCI_DEVICE },
+{ },
+},
+};
+
+
+#define TYPE_MV64361_PCI "mv64361-pcihost"
+OBJECT_DECLARE_SIMPLE_TYPE(MV64361PCIState, MV64361_PCI)
+
+struct MV64361PCIState {
+PCIHostState parent_obj;
+
+uint8_t index;
+MemoryRegion io;
+MemoryRegion mem;
+qemu_irq irq[PCI_NUM_PINS];
+
+uint32_t io_base;
+uint32_t io_size;
+uint32_t mem_base[4];
+uint32_t mem_size[4];
+uint64_t remap[5];
+};
+
+static int mv64361_pcihost_map_irq(PCIDevice *pci_dev, int n)
+{
+return (n + PCI_SLOT(pci_dev->devfn)) % PCI_NUM_PINS;
+}
+
+static void mv64361_pcihost_set_irq(void *opaque, int n, int level)
+{
+MV64361PCIState *s = opaque;
+qemu_set_irq(s->irq[n], level);
+}
+
+static void mv64361_pcihost_realize(DeviceState *dev, Error **errp)
+{
+MV64361PCIState *s = MV64361_PCI(dev);
+PCIHostState *h = PCI_HOST_BRIDGE(dev);
+char *name;
+
+name = g_strdup_printf("pci%d-io", s->index);
+memory_region_init(>io, OBJECT(dev), name, 0x1);
+g_free(name);
+name = g_strdup_printf("pci%d-mem", s->index);
+memory_region_init(>mem, OBJECT(dev), name, 1ULL << 32);
+g_free(name);
+name = g_strdup_printf("pci.%d", s->index);
+h->bus = pci_register_root_bus(dev, name, mv64361_pcihost_set_irq,
+   mv64361_pcihost_map_irq, dev,
+   >mem, >io, 0, 4, TYPE_PCI_BUS);
+g_free(name);
+pci_create_simple(h->bus, 0, TYPE_MV64361_PCI_BRIDGE);
+}
+
+static Property mv64361_pcihost_props[] = {
+DEFINE_PROP_UINT8("index", MV64361PCIState, index, 0),
+DEFINE_PROP_END_OF_LIST()
+};
+
+static void 

[RFC PATCH 0/2] Pegasos2 emulation

[BALATON Zoltan]

Hello,

This is adding a new PPC board called pegasos2 currently posted as RFC
because it depends on not yet merged VT8231 emulation currently on the
list:

https://patchew.org/QEMU/cover.1609967638.git.bala...@eik.bme.hu/

and may need some changes like a test case but I'm posting it now for
getting feedback on what's needed to merge this. More info on it can
be found at:

https://osdn.net/projects/qmiga/wiki/SubprojectPegasos2

Currently it needs a firmware ROM image that I cannot include due to
original copyright holder (bPlan) did not release it under a free
licence but I have plans to write a replacement in the future. With
that firmware it can boot MorphOS now as:

qemu-system-ppc -M pegasos2 -cdrom morphos.iso -device ati-vga,romfile="" 
-serial stdio

then enter "boot cd boot.img" at the firmware "ok" prompt as described
in the MorphOS.readme. To boot Linux use same command line with e.g.
-cdrom debian-8.11.0-powerpc-netinst.iso then enter
"boot cd install/pegasos"

Patch 2 adds the actual board code after patch 1 adding MV64361 system
controller chip. The mv643xx.h header file is taken from Linux and
produces a bunch of checkpatch warnings due to different formatting
rules it follows, I'm not sure we want to adopt it or keep it as it is
given that it does not appear any more in recent Linux versions so we
could reformat it as it's unlikely to get updated in the future.

Regards,
BALATON Zoltan

BALATON Zoltan (2):
  hw/pci-host: Add emulation of Marvell MV64361 PPC system controller
  hw/ppc: Add emulation of Genesi/bPlan Pegasos II

 default-configs/devices/ppc-softmmu.mak |   2 +
 hw/pci-host/Kconfig |   3 +
 hw/pci-host/meson.build |   2 +
 hw/pci-host/mv64361.c   | 966 
 hw/pci-host/mv643xx.h   | 919 ++
 hw/pci-host/trace-events|   6 +
 hw/ppc/Kconfig  |  10 +
 hw/ppc/meson.build  |   2 +
 hw/ppc/pegasos2.c   | 144 
 9 files changed, 2054 insertions(+)
 create mode 100644 hw/pci-host/mv64361.c
 create mode 100644 hw/pci-host/mv643xx.h
 create mode 100644 hw/ppc/pegasos2.c

-- 
2.21.3

[Bug 1909921] Re: Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e

[Snoobz]

** Attachment added: "core.282"
   
https://bugs.launchpad.net/qemu/+bug/1909921/+attachment/5449852/+files/core.282

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

Title:
   Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU
  context @ pc=0x87709b0e

Status in QEMU:
  New

Bug description:
  Hello,

  I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM 
Edition).
  I created a CentOS 7 VM on it and I'm using a Docker container which is 
running qemu inside it.

  This container is a Debian Bullseye OS and I'm using qemu-i386 to start my 
application inside it.
  The error given by qemu is the following :

  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x9d5f9b0e
  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x82f29b0e

  (The pc= value is always different, I guess it is randomly generated).

  My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1)

  Could you please help me? Why am I facing this error?

  Feel free to ask any questions regarding this matter in order to find
  a solution to it!

  Regards

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

[Bug 1909921] Re: Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e

[Snoobz]

** Attachment added: "core.300"
   
https://bugs.launchpad.net/qemu/+bug/1909921/+attachment/5449851/+files/core.300

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

Title:
   Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU
  context @ pc=0x87709b0e

Status in QEMU:
  New

Bug description:
  Hello,

  I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM 
Edition).
  I created a CentOS 7 VM on it and I'm using a Docker container which is 
running qemu inside it.

  This container is a Debian Bullseye OS and I'm using qemu-i386 to start my 
application inside it.
  The error given by qemu is the following :

  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x9d5f9b0e
  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x82f29b0e

  (The pc= value is always different, I guess it is randomly generated).

  My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1)

  Could you please help me? Why am I facing this error?

  Feel free to ask any questions regarding this matter in order to find
  a solution to it!

  Regards

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

[Bug 1909921] Re: Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e

[Snoobz]

If you can't see the core dumps, provide me with a file hoster where I
can upload them. They are around 180mb each.

Feel free to ask more test to find a solution to this matter.

Thank you!

Regards,

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

Title:
   Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU
  context @ pc=0x87709b0e

Status in QEMU:
  New

Bug description:
  Hello,

  I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM 
Edition).
  I created a CentOS 7 VM on it and I'm using a Docker container which is 
running qemu inside it.

  This container is a Debian Bullseye OS and I'm using qemu-i386 to start my 
application inside it.
  The error given by qemu is the following :

  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x9d5f9b0e
  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x82f29b0e

  (The pc= value is always different, I guess it is randomly generated).

  My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1)

  Could you please help me? Why am I facing this error?

  Feel free to ask any questions regarding this matter in order to find
  a solution to it!

  Regards

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

[Bug 1909921] Re: Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e

[Snoobz]

Hello,

If I do as mentionned this command: qemu-i386 -d unimp ./ts3server

I get this output :

2021-01-06 22:45:26.201997|INFO|ServerLibPriv |   |TeamSpeak 3 Server 
3.13.3 (2020-12-16 14:17:05)
2021-01-06 22:45:26.225836|INFO|ServerLibPriv |   |SystemInformation: Linux 
4.18.0-193.28.1.el7.aarch64 #1 SMP Wed Oct 21 16:25:35 UTC 2020 i686 Binary: 
32bit
2021-01-06 22:45:26.227507|WARNING |ServerLibPriv |   |The system locale is set 
to "C" this can cause unexpected behavior. We advice you to repair your locale!
qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x81b99b0e
Trace/breakpoint trap (core dumped)


(Forget about the system local WARNING.)

I attached the generated core dumps, if that helps. I don't have other
logs to add.

Thank you for your help!

Regards,


** Attachment added: "core.316"
   
https://bugs.launchpad.net/qemu/+bug/1909921/+attachment/5449850/+files/core.316

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

Title:
   Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU
  context @ pc=0x87709b0e

Status in QEMU:
  New

Bug description:
  Hello,

  I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM 
Edition).
  I created a CentOS 7 VM on it and I'm using a Docker container which is 
running qemu inside it.

  This container is a Debian Bullseye OS and I'm using qemu-i386 to start my 
application inside it.
  The error given by qemu is the following :

  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x9d5f9b0e
  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x82f29b0e

  (The pc= value is always different, I guess it is randomly generated).

  My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1)

  Could you please help me? Why am I facing this error?

  Feel free to ask any questions regarding this matter in order to find
  a solution to it!

  Regards

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

[Bug 1909921] Re: Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e

[Peter Maydell]

If you run QEMU with the '-d unimp' option (if that's awkward, set the
environment variable QEMU_LOG to 'unimp' instead) does QEMU print any
messages about unimplemented functionality? (In
https://bugs.launchpad.net/qemu/+bug/1619896 somebody else was trying to
run TeamSpeak 3 Server, which fails because of some unimplemented parts
of the Linux syscall API in QEMU, but it doesn't actually crash
apparently.)

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

Title:
   Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU
  context @ pc=0x87709b0e

Status in QEMU:
  New

Bug description:
  Hello,

  I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM 
Edition).
  I created a CentOS 7 VM on it and I'm using a Docker container which is 
running qemu inside it.

  This container is a Debian Bullseye OS and I'm using qemu-i386 to start my 
application inside it.
  The error given by qemu is the following :

  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x9d5f9b0e
  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x82f29b0e

  (The pc= value is always different, I guess it is randomly generated).

  My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1)

  Could you please help me? Why am I facing this error?

  Feel free to ask any questions regarding this matter in order to find
  a solution to it!

  Regards

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

[Bug 1909921] Re: Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffff87709b0e

[Snoobz]

Hello,

Can I get any help please?

Thank you.

Regards,

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

Title:
   Raspberry Pi 4 qemu:handle_cpu_signal received signal outside vCPU
  context @ pc=0x87709b0e

Status in QEMU:
  New

Bug description:
  Hello,

  I have a Raspberry Pi 4 with an ESXi hypervisor installed on it (ESXi ARM 
Edition).
  I created a CentOS 7 VM on it and I'm using a Docker container which is 
running qemu inside it.

  This container is a Debian Bullseye OS and I'm using qemu-i386 to start my 
application inside it.
  The error given by qemu is the following :

  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x9d5f9b0e
  qemu:handle_cpu_signal received signal outside vCPU context @ 
pc=0x82f29b0e

  (The pc= value is always different, I guess it is randomly generated).

  My qemu version is : qemu-i386 version 5.1.0 (Debian 1:5.1+dfsg-4+b1)

  Could you please help me? Why am I facing this error?

  Feel free to ask any questions regarding this matter in order to find
  a solution to it!

  Regards

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

[PATCH 08/12] vt82c686: Fix superio_cfg_{read,write}() functions

[BALATON Zoltan]

These functions are memory region callbacks so we have to check
against relative address not the mapped address. Also reduce
indentation by returning early and log unimplemented accesses.
Additionally we remove separate index value from SuperIOConfig and
store the index at reg 0 which is reserved and returns 0 on read. This
simpilifies object state.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 63 ++-
 1 file changed, 35 insertions(+), 28 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 3a45056226..1a876a1fbf 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -26,6 +26,7 @@
 #include "hw/acpi/acpi.h"
 #include "hw/i2c/pm_smbus.h"
 #include "qapi/error.h"
+#include "qemu/log.h"
 #include "qemu/module.h"
 #include "qemu/range.h"
 #include "qemu/timer.h"
@@ -250,7 +251,6 @@ static const TypeInfo vt8231_pm_info = {
 
 typedef struct SuperIOConfig {
 uint8_t regs[0x100];
-uint8_t index;
 MemoryRegion io;
 } SuperIOConfig;
 
@@ -258,42 +258,49 @@ static void superio_cfg_write(void *opaque, hwaddr addr, 
uint64_t data,
   unsigned size)
 {
 SuperIOConfig *sc = opaque;
+uint8_t idx = sc->regs[0];
 
-if (addr == 0x3f0) { /* config index register */
-sc->index = data & 0xff;
-} else {
-bool can_write = true;
-/* 0x3f1, config data register */
-trace_via_superio_write(sc->index, data & 0xff);
-switch (sc->index) {
-case 0x00 ... 0xdf:
-case 0xe4:
-case 0xe5:
-case 0xe9 ... 0xed:
-case 0xf3:
-case 0xf5:
-case 0xf7:
-case 0xf9 ... 0xfb:
-case 0xfd ... 0xff:
-can_write = false;
-break;
-/* case 0xe6 ... 0xe8: Should set base port of parallel and serial */
-default:
-break;
+if (addr == 0) { /* config index register */
+sc->regs[0] = data;
+return;
+}
 
-}
-if (can_write) {
-sc->regs[sc->index] = data & 0xff;
-}
+/* config data register */
+trace_via_superio_write(idx, data);
+switch (idx) {
+case 0x00 ... 0xdf:
+case 0xe4:
+case 0xe5:
+case 0xe9 ... 0xed:
+case 0xf3:
+case 0xf5:
+case 0xf7:
+case 0xf9 ... 0xfb:
+case 0xfd ... 0xff:
+/* ignore write to read only registers */
+return;
+/* case 0xe6 ... 0xe8: Should set base port of parallel and serial */
+default:
+qemu_log_mask(LOG_UNIMP,
+  "via_superio_cfg: unimplemented register 0x%x\n", idx);
+break;
 }
+sc->regs[idx] = data;
 }
 
 static uint64_t superio_cfg_read(void *opaque, hwaddr addr, unsigned size)
 {
 SuperIOConfig *sc = opaque;
-uint8_t val = sc->regs[sc->index];
+uint8_t idx = sc->regs[0];
+uint8_t val = sc->regs[idx];
 
-trace_via_superio_read(sc->index, val);
+if (addr == 0) {
+return idx;
+}
+if (addr == 1 && idx == 0) {
+val = 0; /* reading reg 0 where we store index value */
+}
+trace_via_superio_read(idx, val);
 return val;
 }
 
-- 
2.21.3

[PATCH 02/12] vt82c686: Reorganise code

[BALATON Zoltan]

Move lines around so that object definitions become consecutive and
not scattered around. This brings functions belonging to an object
together so it's clearer what is defined and what parts belong to
which object.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 279 +++---
 1 file changed, 140 insertions(+), 139 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 30fe02f4c6..fe8961b057 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -26,112 +26,7 @@
 #include "exec/address-spaces.h"
 #include "trace.h"
 
-typedef struct SuperIOConfig {
-uint8_t regs[0x100];
-uint8_t index;
-MemoryRegion io;
-} SuperIOConfig;
-
-struct VT82C686BISAState {
-PCIDevice dev;
-SuperIOConfig superio_cfg;
-};
-
-OBJECT_DECLARE_SIMPLE_TYPE(VT82C686BISAState, VT82C686B_ISA)
-
-static void superio_cfg_write(void *opaque, hwaddr addr, uint64_t data,
-  unsigned size)
-{
-SuperIOConfig *sc = opaque;
-
-if (addr == 0x3f0) { /* config index register */
-sc->index = data & 0xff;
-} else {
-bool can_write = true;
-/* 0x3f1, config data register */
-trace_via_superio_write(sc->index, data & 0xff);
-switch (sc->index) {
-case 0x00 ... 0xdf:
-case 0xe4:
-case 0xe5:
-case 0xe9 ... 0xed:
-case 0xf3:
-case 0xf5:
-case 0xf7:
-case 0xf9 ... 0xfb:
-case 0xfd ... 0xff:
-can_write = false;
-break;
-/* case 0xe6 ... 0xe8: Should set base port of parallel and serial */
-default:
-break;
-
-}
-if (can_write) {
-sc->regs[sc->index] = data & 0xff;
-}
-}
-}
-
-static uint64_t superio_cfg_read(void *opaque, hwaddr addr, unsigned size)
-{
-SuperIOConfig *sc = opaque;
-uint8_t val = sc->regs[sc->index];
-
-trace_via_superio_read(sc->index, val);
-return val;
-}
-
-static const MemoryRegionOps superio_cfg_ops = {
-.read = superio_cfg_read,
-.write = superio_cfg_write,
-.endianness = DEVICE_NATIVE_ENDIAN,
-.impl = {
-.min_access_size = 1,
-.max_access_size = 1,
-},
-};
-
-static void vt82c686b_isa_reset(DeviceState *dev)
-{
-VT82C686BISAState *s = VT82C686B_ISA(dev);
-uint8_t *pci_conf = s->dev.config;
-
-pci_set_long(pci_conf + PCI_CAPABILITY_LIST, 0x00c0);
-pci_set_word(pci_conf + PCI_COMMAND, PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
- PCI_COMMAND_MASTER | PCI_COMMAND_SPECIAL);
-pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_DEVSEL_MEDIUM);
-
-pci_conf[0x48] = 0x01; /* Miscellaneous Control 3 */
-pci_conf[0x4a] = 0x04; /* IDE interrupt Routing */
-pci_conf[0x4f] = 0x03; /* DMA/Master Mem Access Control 3 */
-pci_conf[0x50] = 0x2d; /* PnP DMA Request Control */
-pci_conf[0x59] = 0x04;
-pci_conf[0x5a] = 0x04; /* KBC/RTC Control*/
-pci_conf[0x5f] = 0x04;
-pci_conf[0x77] = 0x10; /* GPIO Control 1/2/3/4 */
-
-s->superio_cfg.regs[0xe0] = 0x3c; /* Device ID */
-s->superio_cfg.regs[0xe2] = 0x03; /* Function select */
-s->superio_cfg.regs[0xe3] = 0xfc; /* Floppy ctrl base addr */
-s->superio_cfg.regs[0xe6] = 0xde; /* Parallel port base addr */
-s->superio_cfg.regs[0xe7] = 0xfe; /* Serial port 1 base addr */
-s->superio_cfg.regs[0xe8] = 0xbe; /* Serial port 2 base addr */
-}
-
-/* write config pci function0 registers. PCI-ISA bridge */
-static void vt82c686b_write_config(PCIDevice *d, uint32_t addr,
-   uint32_t val, int len)
-{
-VT82C686BISAState *s = VT82C686B_ISA(d);
-
-trace_via_isa_write(addr, val, len);
-pci_default_write_config(d, addr, val, len);
-if (addr == 0x85) {
-/* BIT(1): enable or disable superio config io ports */
-memory_region_set_enabled(>superio_cfg.io, val & BIT(1));
-}
-}
+OBJECT_DECLARE_SIMPLE_TYPE(VT686PMState, VT82C686B_PM)
 
 struct VT686PMState {
 PCIDevice dev;
@@ -142,30 +37,6 @@ struct VT686PMState {
 uint32_t smb_io_base;
 };
 
-OBJECT_DECLARE_SIMPLE_TYPE(VT686PMState, VT82C686B_PM)
-
-static void pm_update_sci(VT686PMState *s)
-{
-int sci_level, pmsts;
-
-pmsts = acpi_pm1_evt_get_sts(>ar);
-sci_level = (((pmsts & s->ar.pm1.evt.en) &
-  (ACPI_BITMASK_RT_CLOCK_ENABLE |
-   ACPI_BITMASK_POWER_BUTTON_ENABLE |
-   ACPI_BITMASK_GLOBAL_LOCK_ENABLE |
-   ACPI_BITMASK_TIMER_ENABLE)) != 0);
-pci_set_irq(>dev, sci_level);
-/* schedule a timer interruption if needed */
-acpi_pm_tmr_update(>ar, (s->ar.pm1.evt.en & ACPI_BITMASK_TIMER_ENABLE) 
&&
-   !(pmsts & ACPI_BITMASK_TIMER_STATUS));
-}
-
-static void pm_tmr_timer(ACPIREGS *ar)
-{
-VT686PMState *s = container_of(ar, VT686PMState, ar);
-pm_update_sci(s);
-}
-
 static void pm_io_space_update(VT686PMState *s)
 {
 uint32_t 

[PATCH 03/12] vt82c686: Fix SMBus IO base and configuration registers

[BALATON Zoltan]

The base address of the SMBus io ports and its enabled status is set
by registers in the PCI config space but this was not correctly
emulated. Instead the SMBus registers were mapped on realize to the
base address set by a property to the address expected by fuloong2e
firmware.

Fix the base and config register handling to more closely model
hardware which allows to remove the property and allows the guest to
control this mapping. Do all this in reset instead of realize so it's
correctly updated on reset.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c   | 49 +
 hw/mips/fuloong2e.c |  4 +---
 2 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index fe8961b057..9c4d153022 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -22,6 +22,7 @@
 #include "hw/i2c/pm_smbus.h"
 #include "qapi/error.h"
 #include "qemu/module.h"
+#include "qemu/range.h"
 #include "qemu/timer.h"
 #include "exec/address-spaces.h"
 #include "trace.h"
@@ -34,7 +35,6 @@ struct VT686PMState {
 ACPIREGS ar;
 APMState apm;
 PMSMBus smb;
-uint32_t smb_io_base;
 };
 
 static void pm_io_space_update(VT686PMState *s)
@@ -50,11 +50,22 @@ static void pm_io_space_update(VT686PMState *s)
 memory_region_transaction_commit();
 }
 
+static void smb_io_space_update(VT686PMState *s)
+{
+uint32_t smbase = pci_get_long(s->dev.config + 0x90) & 0xfff0UL;
+
+memory_region_transaction_begin();
+memory_region_set_address(>smb.io, smbase);
+memory_region_set_enabled(>smb.io, s->dev.config[0xd2] & BIT(0));
+memory_region_transaction_commit();
+}
+
 static int vmstate_acpi_post_load(void *opaque, int version_id)
 {
 VT686PMState *s = opaque;
 
 pm_io_space_update(s);
+smb_io_space_update(s);
 return 0;
 }
 
@@ -77,8 +88,18 @@ static const VMStateDescription vmstate_acpi = {
 
 static void pm_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int len)
 {
+VT686PMState *s = VT82C686B_PM(d);
+
 trace_via_pm_write(addr, val, len);
 pci_default_write_config(d, addr, val, len);
+if (ranges_overlap(addr, len, 0x90, 4)) {
+uint32_t v = pci_get_long(s->dev.config + 0x90);
+pci_set_long(s->dev.config + 0x90, (v & 0xfff0UL) | 1);
+}
+if (range_covers_byte(addr, len, 0xd2)) {
+s->dev.config[0xd2] &= 0xf;
+smb_io_space_update(s);
+}
 }
 
 static void pm_update_sci(VT686PMState *s)
@@ -103,6 +124,17 @@ static void pm_tmr_timer(ACPIREGS *ar)
 pm_update_sci(s);
 }
 
+static void vt82c686b_pm_reset(DeviceState *d)
+{
+VT686PMState *s = VT82C686B_PM(d);
+
+/* SMBus IO base */
+pci_set_long(s->dev.config + 0x90, 1);
+s->dev.config[0xd2] = 0;
+
+smb_io_space_update(s);
+}
+
 static void vt82c686b_pm_realize(PCIDevice *dev, Error **errp)
 {
 VT686PMState *s = VT82C686B_PM(dev);
@@ -116,13 +148,9 @@ static void vt82c686b_pm_realize(PCIDevice *dev, Error 
**errp)
 /* 0x48-0x4B is Power Management I/O Base */
 pci_set_long(pci_conf + 0x48, 0x0001);
 
-/* SMB ports:0xeee0~0xeeef */
-s->smb_io_base = ((s->smb_io_base & 0xfff0) + 0x0);
-pci_conf[0x90] = s->smb_io_base | 1;
-pci_conf[0x91] = s->smb_io_base >> 8;
-pci_conf[0xd2] = 0x90;
 pm_smbus_init(DEVICE(s), >smb, false);
-memory_region_add_subregion(get_system_io(), s->smb_io_base, >smb.io);
+memory_region_add_subregion(pci_address_space_io(dev), 0, >smb.io);
+memory_region_set_enabled(>smb.io, false);
 
 apm_init(dev, >apm, NULL, s);
 
@@ -135,11 +163,6 @@ static void vt82c686b_pm_realize(PCIDevice *dev, Error 
**errp)
 acpi_pm1_cnt_init(>ar, >io, false, false, 2);
 }
 
-static Property via_pm_properties[] = {
-DEFINE_PROP_UINT32("smb_io_base", VT686PMState, smb_io_base, 0),
-DEFINE_PROP_END_OF_LIST(),
-};
-
 static void via_pm_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
@@ -151,10 +174,10 @@ static void via_pm_class_init(ObjectClass *klass, void 
*data)
 k->device_id = PCI_DEVICE_ID_VIA_ACPI;
 k->class_id = PCI_CLASS_BRIDGE_OTHER;
 k->revision = 0x40;
+dc->reset = vt82c686b_pm_reset;
 dc->desc = "PM";
 dc->vmsd = _acpi;
 set_bit(DEVICE_CATEGORY_BRIDGE, dc->categories);
-device_class_set_props(dc, via_pm_properties);
 }
 
 static const TypeInfo via_pm_info = {
diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index 29805242ca..fbdd6122b3 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -251,9 +251,7 @@ static void vt82c686b_southbridge_init(PCIBus *pci_bus, int 
slot, qemu_irq intc,
 pci_create_simple(pci_bus, PCI_DEVFN(slot, 2), "vt82c686b-usb-uhci");
 pci_create_simple(pci_bus, PCI_DEVFN(slot, 3), "vt82c686b-usb-uhci");
 
-dev = pci_new(PCI_DEVFN(slot, 4), TYPE_VT82C686B_PM);
-qdev_prop_set_uint32(DEVICE(dev), "smb_io_base", 0xeee1);
-pci_realize_and_unref(dev, pci_bus, _fatal);
+dev = 

[PATCH 09/12] vt82c686: Implement control of serial port io ranges via config regs

[BALATON Zoltan]

In VIA super south bridge the io ranges of superio components
(parallel and serial ports and FDC) can be controlled by superio
config registers to set their base address and enable/disable them.
This is not easy to implement in QEMU because ISA emulation is only
designed to set io base address once on creating the device and io
ranges are registered at creation and cannot easily be disabled or
moved later.

In this patch we hack around that but only for serial ports because
those have a single io range at port base that's relatively easy to
handle and it's what guests actually use and set address different
than the default.

We do not attempt to handle controlling the parallel and FDC regions
because those have multiple io ranges so handling them would be messy
and guests either don't change their deafult or don't care. We could
even get away with disabling and not emulating them, but since they
are already there, this patch leaves them mapped at their default
address just in case this could be useful for a guest in the future.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 84 +--
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 1a876a1fbf..26db1a18e2 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -252,8 +252,24 @@ static const TypeInfo vt8231_pm_info = {
 typedef struct SuperIOConfig {
 uint8_t regs[0x100];
 MemoryRegion io;
+ISASuperIODevice *superio;
+MemoryRegion *serial_io[SUPERIO_MAX_SERIAL_PORTS];
 } SuperIOConfig;
 
+static MemoryRegion *find_subregion(ISADevice *d, MemoryRegion *parent,
+int offs)
+{
+MemoryRegion *subregion, *mr = NULL;
+
+QTAILQ_FOREACH(subregion, >subregions, subregions_link) {
+if (subregion->addr == offs) {
+mr = subregion;
+break;
+}
+}
+return mr;
+}
+
 static void superio_cfg_write(void *opaque, hwaddr addr, uint64_t data,
   unsigned size)
 {
@@ -279,7 +295,53 @@ static void superio_cfg_write(void *opaque, hwaddr addr, 
uint64_t data,
 case 0xfd ... 0xff:
 /* ignore write to read only registers */
 return;
-/* case 0xe6 ... 0xe8: Should set base port of parallel and serial */
+case 0xe2:
+{
+data &= 0x1f;
+if (data & BIT(2)) { /* Serial port 1 enable */
+ISADevice *dev = sc->superio->serial[0];
+if (!memory_region_is_mapped(sc->serial_io[0])) {
+memory_region_add_subregion(isa_address_space_io(dev),
+dev->ioport_id, sc->serial_io[0]);
+}
+} else {
+MemoryRegion *io = isa_address_space_io(sc->superio->serial[0]);
+if (memory_region_is_mapped(sc->serial_io[0])) {
+memory_region_del_subregion(io, sc->serial_io[0]);
+}
+}
+if (data & BIT(3)) { /* Serial port 2 enable */
+ISADevice *dev = sc->superio->serial[1];
+if (!memory_region_is_mapped(sc->serial_io[1])) {
+memory_region_add_subregion(isa_address_space_io(dev),
+dev->ioport_id, sc->serial_io[1]);
+}
+} else {
+MemoryRegion *io = isa_address_space_io(sc->superio->serial[1]);
+if (memory_region_is_mapped(sc->serial_io[1])) {
+memory_region_del_subregion(io, sc->serial_io[1]);
+}
+}
+break;
+}
+case 0xe7: /* Serial port 1 io base address */
+{
+data &= 0xfe;
+sc->superio->serial[0]->ioport_id = data << 2;
+if (memory_region_is_mapped(sc->serial_io[0])) {
+memory_region_set_address(sc->serial_io[0], data << 2);
+}
+break;
+}
+case 0xe8: /* Serial port 2 io base address */
+{
+data &= 0xfe;
+sc->superio->serial[1]->ioport_id = data << 2;
+if (memory_region_is_mapped(sc->serial_io[1])) {
+memory_region_set_address(sc->serial_io[1], data << 2);
+}
+break;
+}
 default:
 qemu_log_mask(LOG_UNIMP,
   "via_superio_cfg: unimplemented register 0x%x\n", idx);
@@ -385,6 +447,7 @@ static void vt82c686b_realize(PCIDevice *d, Error **errp)
 DeviceState *dev = DEVICE(d);
 ISABus *isa_bus;
 qemu_irq *isa_irq;
+ISASuperIOClass *ic;
 int i;
 
 qdev_init_gpio_out(dev, >cpu_intr, 1);
@@ -394,7 +457,9 @@ static void vt82c686b_realize(PCIDevice *d, Error **errp)
 isa_bus_irqs(isa_bus, i8259_init(isa_bus, *isa_irq));
 i8254_pit_init(isa_bus, 0x40, 0, NULL);
 i8257_dma_init(isa_bus, 0);
-isa_create_simple(isa_bus, TYPE_VT82C686B_SUPERIO);
+s->superio_cfg.superio = ISA_SUPERIO(isa_create_simple(isa_bus,
+  TYPE_VT82C686B_SUPERIO));
+ic = 

[PATCH 12/12] vt82c686: Add emulation of VT8231 south bridge

[BALATON Zoltan]

Add emulation of VT8231 south bridge ISA part based on the similar
VT82C686B but implemented in a separate subclass that holds the
differences while reusing parts that can be shared.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 152 ++
 include/hw/isa/vt82c686.h |   1 +
 2 files changed, 123 insertions(+), 30 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 0390782d1d..604ab4a55e 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -8,6 +8,9 @@
  *
  * Contributions after 2012-01-13 are licensed under the terms of the
  * GNU GPL, version 2 or (at your option) any later version.
+ *
+ * VT8231 south bridge support and general clean up to allow it
+ * Copyright (c) 2018-2020 BALATON Zoltan
  */
 
 #include "qemu/osdep.h"
@@ -609,24 +612,48 @@ static const TypeInfo vt8231_superio_info = {
 };
 
 
-OBJECT_DECLARE_SIMPLE_TYPE(VT82C686BISAState, VT82C686B_ISA)
+#define TYPE_VIA_ISA "via-isa"
+OBJECT_DECLARE_SIMPLE_TYPE(ViaISAState, VIA_ISA)
 
-struct VT82C686BISAState {
+struct ViaISAState {
 PCIDevice dev;
 qemu_irq cpu_intr;
 ViaSuperIOState *via_sio;
 };
 
+static const VMStateDescription vmstate_via = {
+.name = "via-isa",
+.version_id = 1,
+.minimum_version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_PCI_DEVICE(dev, ViaISAState),
+VMSTATE_END_OF_LIST()
+}
+};
+
+static const TypeInfo via_isa_info = {
+.name  = TYPE_VIA_ISA,
+.parent= TYPE_PCI_DEVICE,
+.instance_size = sizeof(ViaISAState),
+.abstract  = true,
+.interfaces= (InterfaceInfo[]) {
+{ INTERFACE_CONVENTIONAL_PCI_DEVICE },
+{ },
+},
+};
+
 static void via_isa_request_i8259_irq(void *opaque, int irq, int level)
 {
-VT82C686BISAState *s = opaque;
+ViaISAState *s = opaque;
 qemu_set_irq(s->cpu_intr, level);
 }
 
+/* TYPE_VT82C686B_ISA */
+
 static void vt82c686b_write_config(PCIDevice *d, uint32_t addr,
uint32_t val, int len)
 {
-VT82C686BISAState *s = VT82C686B_ISA(d);
+ViaISAState *s = VIA_ISA(d);
 
 trace_via_isa_write(addr, val, len);
 pci_default_write_config(d, addr, val, len);
@@ -636,19 +663,9 @@ static void vt82c686b_write_config(PCIDevice *d, uint32_t 
addr,
 }
 }
 
-static const VMStateDescription vmstate_via = {
-.name = "vt82c686b",
-.version_id = 1,
-.minimum_version_id = 1,
-.fields = (VMStateField[]) {
-VMSTATE_PCI_DEVICE(dev, VT82C686BISAState),
-VMSTATE_END_OF_LIST()
-}
-};
-
 static void vt82c686b_isa_reset(DeviceState *dev)
 {
-VT82C686BISAState *s = VT82C686B_ISA(dev);
+ViaISAState *s = VIA_ISA(dev);
 uint8_t *pci_conf = s->dev.config;
 
 pci_set_long(pci_conf + PCI_CAPABILITY_LIST, 0x00c0);
@@ -668,7 +685,7 @@ static void vt82c686b_isa_reset(DeviceState *dev)
 
 static void vt82c686b_realize(PCIDevice *d, Error **errp)
 {
-VT82C686BISAState *s = VT82C686B_ISA(d);
+ViaISAState *s = VIA_ISA(d);
 DeviceState *dev = DEVICE(d);
 ISABus *isa_bus;
 qemu_irq *isa_irq;
@@ -692,7 +709,7 @@ static void vt82c686b_realize(PCIDevice *d, Error **errp)
 }
 }
 
-static void via_class_init(ObjectClass *klass, void *data)
+static void vt82c686b_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
@@ -706,22 +723,95 @@ static void via_class_init(ObjectClass *klass, void *data)
 dc->reset = vt82c686b_isa_reset;
 dc->desc = "ISA bridge";
 dc->vmsd = _via;
-/*
- * Reason: part of VIA VT82C686 southbridge, needs to be wired up,
- * e.g. by mips_fuloong2e_init()
- */
+/* Reason: part of VIA VT82C686 southbridge, needs to be wired up */
 dc->user_creatable = false;
 }
 
-static const TypeInfo via_info = {
+static const TypeInfo vt82c686b_isa_info = {
 .name  = TYPE_VT82C686B_ISA,
-.parent= TYPE_PCI_DEVICE,
-.instance_size = sizeof(VT82C686BISAState),
-.class_init= via_class_init,
-.interfaces = (InterfaceInfo[]) {
-{ INTERFACE_CONVENTIONAL_PCI_DEVICE },
-{ },
-},
+.parent= TYPE_VIA_ISA,
+.instance_size = sizeof(ViaISAState),
+.class_init= vt82c686b_class_init,
+};
+
+/* TYPE_VT8231_ISA */
+
+static void vt8231_write_config(PCIDevice *d, uint32_t addr,
+uint32_t val, int len)
+{
+ViaISAState *s = VIA_ISA(d);
+
+trace_via_isa_write(addr, val, len);
+pci_default_write_config(d, addr, val, len);
+if (addr == 0x50) {
+/* BIT(2): enable or disable superio config io ports */
+via_superio_io_enable(s->via_sio, val & BIT(2));
+}
+}
+
+static void vt8231_isa_reset(DeviceState *dev)
+{
+ViaISAState *s = VIA_ISA(dev);
+uint8_t *pci_conf = s->dev.config;
+
+pci_set_long(pci_conf + PCI_CAPABILITY_LIST, 0x00c0);
+pci_set_word(pci_conf + 

[PATCH 07/12] vt82c686: Move creation of ISA devices to the ISA bridge

[BALATON Zoltan]

Currently the ISA devices that are part of the VIA south bridge,
superio chip are wired up by board code. Move creation of these ISA
devices to the VIA ISA bridge model so that board code does not need
to access ISA bus. This also allows vt82c686b-superio to be made
internal to vt82c686 which allows implementing its configuration via
registers in subseqent commits.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c   | 20 
 hw/mips/fuloong2e.c | 29 +
 2 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index ead60310fe..3a45056226 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -16,6 +16,11 @@
 #include "hw/qdev-properties.h"
 #include "hw/isa/isa.h"
 #include "hw/isa/superio.h"
+#include "hw/intc/i8259.h"
+#include "hw/irq.h"
+#include "hw/dma/i8257.h"
+#include "hw/timer/i8254.h"
+#include "hw/rtc/mc146818rtc.h"
 #include "migration/vmstate.h"
 #include "hw/isa/apm.h"
 #include "hw/acpi/acpi.h"
@@ -307,9 +312,16 @@ OBJECT_DECLARE_SIMPLE_TYPE(VT82C686BISAState, 
VT82C686B_ISA)
 
 struct VT82C686BISAState {
 PCIDevice dev;
+qemu_irq cpu_intr;
 SuperIOConfig superio_cfg;
 };
 
+static void via_isa_request_i8259_irq(void *opaque, int irq, int level)
+{
+VT82C686BISAState *s = opaque;
+qemu_set_irq(s->cpu_intr, level);
+}
+
 static void vt82c686b_write_config(PCIDevice *d, uint32_t addr,
uint32_t val, int len)
 {
@@ -365,10 +377,18 @@ static void vt82c686b_realize(PCIDevice *d, Error **errp)
 VT82C686BISAState *s = VT82C686B_ISA(d);
 DeviceState *dev = DEVICE(d);
 ISABus *isa_bus;
+qemu_irq *isa_irq;
 int i;
 
+qdev_init_gpio_out(dev, >cpu_intr, 1);
+isa_irq = qemu_allocate_irqs(via_isa_request_i8259_irq, s, 1);
 isa_bus = isa_bus_new(dev, get_system_memory(), pci_address_space_io(d),
   _fatal);
+isa_bus_irqs(isa_bus, i8259_init(isa_bus, *isa_irq));
+i8254_pit_init(isa_bus, 0x40, 0, NULL);
+i8257_dma_init(isa_bus, 0);
+isa_create_simple(isa_bus, TYPE_VT82C686B_SUPERIO);
+mc146818_rtc_init(isa_bus, 2000, NULL);
 
 for (i = 0; i < PCI_CONFIG_HEADER_SIZE; i++) {
 if (i < PCI_COMMAND || i >= PCI_REVISION_ID) {
diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index fbdd6122b3..0fc3288556 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -25,9 +25,6 @@
 #include "qapi/error.h"
 #include "cpu.h"
 #include "hw/clock.h"
-#include "hw/intc/i8259.h"
-#include "hw/dma/i8257.h"
-#include "hw/isa/superio.h"
 #include "net/net.h"
 #include "hw/boards.h"
 #include "hw/i2c/smbus_eeprom.h"
@@ -38,13 +35,13 @@
 #include "qemu/log.h"
 #include "hw/loader.h"
 #include "hw/ide/pci.h"
+#include "hw/qdev-properties.h"
 #include "elf.h"
 #include "hw/isa/vt82c686.h"
-#include "hw/rtc/mc146818rtc.h"
-#include "hw/timer/i8254.h"
 #include "exec/address-spaces.h"
 #include "sysemu/qtest.h"
 #include "sysemu/reset.h"
+#include "sysemu/sysemu.h"
 #include "qemu/error-report.h"
 
 #define ENVP_PADDR  0x2000
@@ -224,26 +221,13 @@ static void main_cpu_reset(void *opaque)
 }
 
 static void vt82c686b_southbridge_init(PCIBus *pci_bus, int slot, qemu_irq 
intc,
-   I2CBus **i2c_bus, ISABus **p_isa_bus)
+   I2CBus **i2c_bus)
 {
-qemu_irq *i8259;
-ISABus *isa_bus;
 PCIDevice *dev;
 
 dev = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(slot, 0), true,
   TYPE_VT82C686B_ISA);
-isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(dev), "isa.0"));
-assert(isa_bus);
-*p_isa_bus = isa_bus;
-/* Interrupt controller */
-/* The 8259 -> IP5  */
-i8259 = i8259_init(isa_bus, intc);
-isa_bus_irqs(isa_bus, i8259);
-/* init other devices */
-i8254_pit_init(isa_bus, 0x40, 0, NULL);
-i8257_dma_init(isa_bus, 0);
-/* Super I/O */
-isa_create_simple(isa_bus, TYPE_VT82C686B_SUPERIO);
+qdev_connect_gpio_out(DEVICE(dev), 0, intc);
 
 dev = pci_create_simple(pci_bus, PCI_DEVFN(slot, 1), "via-ide");
 pci_ide_create_devs(dev);
@@ -290,7 +274,6 @@ static void mips_fuloong2e_init(MachineState *machine)
 uint64_t kernel_entry;
 PCIDevice *pci_dev;
 PCIBus *pci_bus;
-ISABus *isa_bus;
 I2CBus *smbus;
 Clock *cpuclk;
 MIPSCPU *cpu;
@@ -357,7 +340,7 @@ static void mips_fuloong2e_init(MachineState *machine)
 
 /* South bridge -> IP5 */
 vt82c686b_southbridge_init(pci_bus, FULOONG2E_VIA_SLOT, env->irq[5],
-   , _bus);
+   );
 
 /* GPU */
 if (vga_interface_type != VGA_NONE) {
@@ -372,8 +355,6 @@ static void mips_fuloong2e_init(MachineState *machine)
 spd_data = spd_data_generate(DDR, machine->ram_size);
 smbus_eeprom_init_one(smbus, 0x50, spd_data);
 
-mc146818_rtc_init(isa_bus, 2000, NULL);
-
 /* 

[PATCH 01/12] vt82c686: Move superio memory region to SuperIOConfig struct

[BALATON Zoltan]

The superio memory region holds the io space index/data registers used
to access the superio config registers that are implemented in struct
SuperIOConfig. To keep these related things together move the memory
region to SuperIOConfig and rename it accordingly.
Also remove the unused "data" member of SuperIOConfig which is not
needed as we store actual data values in the regs array.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index a6f5a0843d..30fe02f4c6 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -29,12 +29,11 @@
 typedef struct SuperIOConfig {
 uint8_t regs[0x100];
 uint8_t index;
-uint8_t data;
+MemoryRegion io;
 } SuperIOConfig;
 
 struct VT82C686BISAState {
 PCIDevice dev;
-MemoryRegion superio;
 SuperIOConfig superio_cfg;
 };
 
@@ -128,8 +127,9 @@ static void vt82c686b_write_config(PCIDevice *d, uint32_t 
addr,
 
 trace_via_isa_write(addr, val, len);
 pci_default_write_config(d, addr, val, len);
-if (addr == 0x85) {  /* enable or disable super IO configure */
-memory_region_set_enabled(>superio, val & 0x2);
+if (addr == 0x85) {
+/* BIT(1): enable or disable superio config io ports */
+memory_region_set_enabled(>superio_cfg.io, val & BIT(1));
 }
 }
 
@@ -311,15 +311,15 @@ static void vt82c686b_realize(PCIDevice *d, Error **errp)
 }
 }
 
-memory_region_init_io(>superio, OBJECT(d), _cfg_ops,
-  >superio_cfg, "superio", 2);
-memory_region_set_enabled(>superio, false);
+memory_region_init_io(>superio_cfg.io, OBJECT(d), _cfg_ops,
+  >superio_cfg, "superio_cfg", 2);
+memory_region_set_enabled(>superio_cfg.io, false);
 /*
  * The floppy also uses 0x3f0 and 0x3f1.
  * But we do not emulate a floppy, so just set it here.
  */
 memory_region_add_subregion(isa_bus->address_space_io, 0x3f0,
->superio);
+>superio_cfg.io);
 }
 
 static void via_class_init(ObjectClass *klass, void *data)
-- 
2.21.3

[PATCH 06/12] vt82c686: Simplify vt82c686b_realize()

[BALATON Zoltan]

Remove unneeded variables and setting value to 0 on zero initialised
data and replace check for error with error_fatal. Rationalise loop
that sets PCI config header fields read only.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index a989e29fe5..ead60310fe 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -363,24 +363,16 @@ static void vt82c686b_isa_reset(DeviceState *dev)
 static void vt82c686b_realize(PCIDevice *d, Error **errp)
 {
 VT82C686BISAState *s = VT82C686B_ISA(d);
-uint8_t *pci_conf;
+DeviceState *dev = DEVICE(d);
 ISABus *isa_bus;
-uint8_t *wmask;
 int i;
 
-isa_bus = isa_bus_new(DEVICE(d), get_system_memory(),
-  pci_address_space_io(d), errp);
-if (!isa_bus) {
-return;
-}
-
-pci_conf = d->config;
-pci_config_set_prog_interface(pci_conf, 0x0);
+isa_bus = isa_bus_new(dev, get_system_memory(), pci_address_space_io(d),
+  _fatal);
 
-wmask = d->wmask;
-for (i = 0x00; i < 0xff; i++) {
-if (i <= 0x03 || (i >= 0x08 && i <= 0x3f)) {
-wmask[i] = 0x00;
+for (i = 0; i < PCI_CONFIG_HEADER_SIZE; i++) {
+if (i < PCI_COMMAND || i >= PCI_REVISION_ID) {
+d->wmask[i] = 0;
 }
 }
 
-- 
2.21.3

[PATCH 04/12] vt82c686: Fix up power management io base and config

[BALATON Zoltan]

Similar to the SMBus io registers there is a power management io range
that is set via similar base address reg and enable bit. Some handling
of this was already there but with several problems: using the wrong
registers and bits, wrong size range, not acually updating mapping and
handling reset correctly, nor emulating any of the actual io
registers. Some of these errors are fixed up here.

After this patch we use the correct base address register, enable bit
and region size and allow guests to map/unmap this region and
correctly reset all registers to default values on reset but we still
don't emulate any of the registers in this range.

Previously just an empty RAM region was mapped on realize, now we add
an empty io range logging access instead. I think the pm timer should
be hooked up here but not sure guests need it. PMON on fuloong2e sets
a base address but does not seem to enable region; the pegasos2
firmware pokes some regs but continues anyway so don't know if
anything would make use of these facilities. Therefore this is just a
clean up of previous state for now and not intending to fully
implement missing functionality which could be done later if some
guests need it.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/trace-events |  2 ++
 hw/isa/vt82c686.c   | 56 -
 2 files changed, 42 insertions(+), 16 deletions(-)

diff --git a/hw/isa/trace-events b/hw/isa/trace-events
index d267d3e652..641d69eedf 100644
--- a/hw/isa/trace-events
+++ b/hw/isa/trace-events
@@ -17,5 +17,7 @@ apm_io_write(uint8_t addr, uint8_t val) "write addr=0x%x 
val=0x%02x"
 # vt82c686.c
 via_isa_write(uint32_t addr, uint32_t val, int len) "addr 0x%x val 0x%x len 
0x%x"
 via_pm_write(uint32_t addr, uint32_t val, int len) "addr 0x%x val 0x%x len 
0x%x"
+via_pm_io_read(uint32_t addr, uint32_t val, int len) "addr 0x%x val 0x%x len 
0x%x"
+via_pm_io_write(uint32_t addr, uint32_t val, int len) "addr 0x%x val 0x%x len 
0x%x"
 via_superio_read(uint8_t addr, uint8_t val) "addr 0x%x val 0x%x"
 via_superio_write(uint8_t addr, uint32_t val) "addr 0x%x val 0x%x"
diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 9c4d153022..fc2a1f4430 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -39,14 +39,11 @@ struct VT686PMState {
 
 static void pm_io_space_update(VT686PMState *s)
 {
-uint32_t pm_io_base;
-
-pm_io_base = pci_get_long(s->dev.config + 0x40);
-pm_io_base &= 0xffc0;
+uint32_t pmbase = pci_get_long(s->dev.config + 0x48) & 0xff80UL;
 
 memory_region_transaction_begin();
-memory_region_set_enabled(>io, s->dev.config[0x80] & 1);
-memory_region_set_address(>io, pm_io_base);
+memory_region_set_address(>io, pmbase);
+memory_region_set_enabled(>io, s->dev.config[0x41] & BIT(7));
 memory_region_transaction_commit();
 }
 
@@ -92,6 +89,13 @@ static void pm_write_config(PCIDevice *d, uint32_t addr, 
uint32_t val, int len)
 
 trace_via_pm_write(addr, val, len);
 pci_default_write_config(d, addr, val, len);
+if (ranges_overlap(addr, len, 0x48, 4)) {
+uint32_t v = pci_get_long(s->dev.config + 0x48);
+pci_set_long(s->dev.config + 0x48, (v & 0xff80UL) | 1);
+}
+if (range_covers_byte(addr, len, 0x41)) {
+pm_io_space_update(s);
+}
 if (ranges_overlap(addr, len, 0x90, 4)) {
 uint32_t v = pci_get_long(s->dev.config + 0x90);
 pci_set_long(s->dev.config + 0x90, (v & 0xfff0UL) | 1);
@@ -102,6 +106,27 @@ static void pm_write_config(PCIDevice *d, uint32_t addr, 
uint32_t val, int len)
 }
 }
 
+static void pm_io_write(void *op, hwaddr addr, uint64_t data, unsigned size)
+{
+trace_via_pm_io_write(addr, data, size);
+}
+
+static uint64_t pm_io_read(void *op, hwaddr addr, unsigned size)
+{
+trace_via_pm_io_read(addr, 0, size);
+return 0;
+}
+
+static const MemoryRegionOps pm_io_ops = {
+.read = pm_io_read,
+.write = pm_io_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.impl = {
+.min_access_size = 1,
+.max_access_size = 1,
+},
+};
+
 static void pm_update_sci(VT686PMState *s)
 {
 int sci_level, pmsts;
@@ -128,35 +153,34 @@ static void vt82c686b_pm_reset(DeviceState *d)
 {
 VT686PMState *s = VT82C686B_PM(d);
 
+memset(s->dev.config + PCI_CONFIG_HEADER_SIZE, 0,
+   PCI_CONFIG_SPACE_SIZE - PCI_CONFIG_HEADER_SIZE);
+/* Power Management IO base */
+pci_set_long(s->dev.config + 0x48, 1);
 /* SMBus IO base */
 pci_set_long(s->dev.config + 0x90, 1);
-s->dev.config[0xd2] = 0;
 
+pm_io_space_update(s);
 smb_io_space_update(s);
 }
 
 static void vt82c686b_pm_realize(PCIDevice *dev, Error **errp)
 {
 VT686PMState *s = VT82C686B_PM(dev);
-uint8_t *pci_conf;
 
-pci_conf = s->dev.config;
-pci_set_word(pci_conf + PCI_COMMAND, 0);
-pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_FAST_BACK |
+pci_set_word(dev->config + PCI_STATUS, PCI_STATUS_FAST_BACK |
  PCI_STATUS_DEVSEL_MEDIUM);
 
-   

[PATCH 11/12] vt82c686: Add VT8231_SUPERIO based on VIA_SUPERIO

[BALATON Zoltan]

The VT8231 south bridge is very similar to VT82C686B but there are
some differences in register addresses and functionality, e.g. the
VT8231 only has one serial port. This commit adds VT8231_SUPERIO
subclass based on the abstract VIA_SUPERIO class to emulate the
superio part of VT8231.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 121 ++
 1 file changed, 121 insertions(+)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index a755896b8e..0390782d1d 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -489,6 +489,126 @@ static const TypeInfo vt82c686b_superio_info = {
 };
 
 
+#define TYPE_VT8231_SUPERIO "vt8231-superio"
+
+static void vt8231_superio_cfg_write(void *opaque, hwaddr addr,
+ uint64_t data, unsigned size)
+{
+ViaSuperIOState *sc = opaque;
+uint8_t idx = sc->regs[0];
+
+if (addr == 0) { /* config index register */
+sc->regs[0] = data;
+return;
+}
+
+/* config data register */
+trace_via_superio_write(idx, data);
+switch (idx) {
+case 0x00 ... 0xdf:
+case 0xe7 ... 0xef:
+case 0xf0 ... 0xf1:
+case 0xf5:
+case 0xf8:
+case 0xfd:
+/* ignore write to read only registers */
+return;
+case 0xf2: /* Function select */
+{
+data &= 0x17;
+if (data & BIT(2)) { /* Serial port enable */
+ISADevice *dev = sc->superio.serial[0];
+if (!memory_region_is_mapped(sc->serial_io[0])) {
+memory_region_add_subregion(isa_address_space_io(dev),
+dev->ioport_id, sc->serial_io[0]);
+}
+} else {
+MemoryRegion *io = isa_address_space_io(sc->superio.serial[0]);
+if (memory_region_is_mapped(sc->serial_io[0])) {
+memory_region_del_subregion(io, sc->serial_io[0]);
+}
+}
+break;
+}
+case 0xf4: /* Serial port io base address */
+{
+data &= 0xfe;
+sc->superio.serial[0]->ioport_id = data << 2;
+if (memory_region_is_mapped(sc->serial_io[0])) {
+memory_region_set_address(sc->serial_io[0], data << 2);
+}
+break;
+}
+default:
+qemu_log_mask(LOG_UNIMP,
+  "via_superio_cfg: unimplemented register 0x%x\n", idx);
+break;
+}
+sc->regs[idx] = data;
+}
+
+static const MemoryRegionOps vt8231_superio_cfg_ops = {
+.read = via_superio_cfg_read,
+.write = vt8231_superio_cfg_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+.impl = {
+.min_access_size = 1,
+.max_access_size = 1,
+},
+};
+
+static void vt8231_superio_reset(DeviceState *dev)
+{
+ViaSuperIOState *s = VIA_SUPERIO(dev);
+
+memset(s->regs, 0, sizeof(s->regs));
+/* Device ID */
+s->regs[0xf0] = 0x3c;
+/* Device revision */
+s->regs[0xf1] = 0x01;
+/* Function select - all disabled */
+vt8231_superio_cfg_write(s, 0, 0xf2, 1);
+vt8231_superio_cfg_write(s, 1, 0x03, 1);
+/* Serial port base addr */
+vt8231_superio_cfg_write(s, 0, 0xf4, 1);
+vt8231_superio_cfg_write(s, 1, 0xfe, 1);
+/* Parallel port base addr */
+vt8231_superio_cfg_write(s, 0, 0xf6, 1);
+vt8231_superio_cfg_write(s, 1, 0xde, 1);
+/* Floppy ctrl base addr */
+vt8231_superio_cfg_write(s, 0, 0xf7, 1);
+vt8231_superio_cfg_write(s, 1, 0xfc, 1);
+
+vt8231_superio_cfg_write(s, 0, 0, 1);
+}
+
+static void vt8231_superio_init(Object *obj)
+{
+VIA_SUPERIO(obj)->io_ops = _superio_cfg_ops;
+}
+
+static void vt8231_superio_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISASuperIOClass *sc = ISA_SUPERIO_CLASS(klass);
+
+dc->reset = vt8231_superio_reset;
+sc->serial.count = 1;
+sc->parallel.count = 1;
+sc->ide.count = 0; /* emulated by via-ide */
+sc->floppy.count = 1;
+}
+
+static const TypeInfo vt8231_superio_info = {
+.name  = TYPE_VT8231_SUPERIO,
+.parent= TYPE_VIA_SUPERIO,
+.instance_size = sizeof(ViaSuperIOState),
+.instance_init = vt8231_superio_init,
+.class_size= sizeof(ISASuperIOClass),
+.class_init= vt8231_superio_class_init,
+};
+
+
 OBJECT_DECLARE_SIMPLE_TYPE(VT82C686BISAState, VT82C686B_ISA)
 
 struct VT82C686BISAState {
@@ -612,6 +732,7 @@ static void vt82c686b_register_types(void)
 type_register_static(_pm_info);
 type_register_static(_superio_info);
 type_register_static(_superio_info);
+type_register_static(_superio_info);
 type_register_static(_info);
 }
 
-- 
2.21.3

[PATCH 05/12] vt82c686: Make vt82c686b-pm an abstract base class and add vt8231-pm based on it

[BALATON Zoltan]

The vt82c686b-pm model can be shared between VT82C686B and VT8231. The
only difference between the two is the device id in what we emulate so
make an abstract via-pm model by renaming appropriately and add types
for vt82c686b-pm and vt8231-pm based on it.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 87 ++-
 include/hw/isa/vt82c686.h |  1 +
 2 files changed, 59 insertions(+), 29 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index fc2a1f4430..a989e29fe5 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -27,9 +27,10 @@
 #include "exec/address-spaces.h"
 #include "trace.h"
 
-OBJECT_DECLARE_SIMPLE_TYPE(VT686PMState, VT82C686B_PM)
+#define TYPE_VIA_PM "via-pm"
+OBJECT_DECLARE_SIMPLE_TYPE(ViaPMState, VIA_PM)
 
-struct VT686PMState {
+struct ViaPMState {
 PCIDevice dev;
 MemoryRegion io;
 ACPIREGS ar;
@@ -37,7 +38,7 @@ struct VT686PMState {
 PMSMBus smb;
 };
 
-static void pm_io_space_update(VT686PMState *s)
+static void pm_io_space_update(ViaPMState *s)
 {
 uint32_t pmbase = pci_get_long(s->dev.config + 0x48) & 0xff80UL;
 
@@ -47,7 +48,7 @@ static void pm_io_space_update(VT686PMState *s)
 memory_region_transaction_commit();
 }
 
-static void smb_io_space_update(VT686PMState *s)
+static void smb_io_space_update(ViaPMState *s)
 {
 uint32_t smbase = pci_get_long(s->dev.config + 0x90) & 0xfff0UL;
 
@@ -59,7 +60,7 @@ static void smb_io_space_update(VT686PMState *s)
 
 static int vmstate_acpi_post_load(void *opaque, int version_id)
 {
-VT686PMState *s = opaque;
+ViaPMState *s = opaque;
 
 pm_io_space_update(s);
 smb_io_space_update(s);
@@ -72,20 +73,20 @@ static const VMStateDescription vmstate_acpi = {
 .minimum_version_id = 1,
 .post_load = vmstate_acpi_post_load,
 .fields = (VMStateField[]) {
-VMSTATE_PCI_DEVICE(dev, VT686PMState),
-VMSTATE_UINT16(ar.pm1.evt.sts, VT686PMState),
-VMSTATE_UINT16(ar.pm1.evt.en, VT686PMState),
-VMSTATE_UINT16(ar.pm1.cnt.cnt, VT686PMState),
-VMSTATE_STRUCT(apm, VT686PMState, 0, vmstate_apm, APMState),
-VMSTATE_TIMER_PTR(ar.tmr.timer, VT686PMState),
-VMSTATE_INT64(ar.tmr.overflow_time, VT686PMState),
+VMSTATE_PCI_DEVICE(dev, ViaPMState),
+VMSTATE_UINT16(ar.pm1.evt.sts, ViaPMState),
+VMSTATE_UINT16(ar.pm1.evt.en, ViaPMState),
+VMSTATE_UINT16(ar.pm1.cnt.cnt, ViaPMState),
+VMSTATE_STRUCT(apm, ViaPMState, 0, vmstate_apm, APMState),
+VMSTATE_TIMER_PTR(ar.tmr.timer, ViaPMState),
+VMSTATE_INT64(ar.tmr.overflow_time, ViaPMState),
 VMSTATE_END_OF_LIST()
 }
 };
 
 static void pm_write_config(PCIDevice *d, uint32_t addr, uint32_t val, int len)
 {
-VT686PMState *s = VT82C686B_PM(d);
+ViaPMState *s = VIA_PM(d);
 
 trace_via_pm_write(addr, val, len);
 pci_default_write_config(d, addr, val, len);
@@ -127,7 +128,7 @@ static const MemoryRegionOps pm_io_ops = {
 },
 };
 
-static void pm_update_sci(VT686PMState *s)
+static void pm_update_sci(ViaPMState *s)
 {
 int sci_level, pmsts;
 
@@ -145,13 +146,13 @@ static void pm_update_sci(VT686PMState *s)
 
 static void pm_tmr_timer(ACPIREGS *ar)
 {
-VT686PMState *s = container_of(ar, VT686PMState, ar);
+ViaPMState *s = container_of(ar, ViaPMState, ar);
 pm_update_sci(s);
 }
 
-static void vt82c686b_pm_reset(DeviceState *d)
+static void via_pm_reset(DeviceState *d)
 {
-VT686PMState *s = VT82C686B_PM(d);
+ViaPMState *s = VIA_PM(d);
 
 memset(s->dev.config + PCI_CONFIG_HEADER_SIZE, 0,
PCI_CONFIG_SPACE_SIZE - PCI_CONFIG_HEADER_SIZE);
@@ -164,9 +165,9 @@ static void vt82c686b_pm_reset(DeviceState *d)
 smb_io_space_update(s);
 }
 
-static void vt82c686b_pm_realize(PCIDevice *dev, Error **errp)
+static void via_pm_realize(PCIDevice *dev, Error **errp)
 {
-VT686PMState *s = VT82C686B_PM(dev);
+ViaPMState *s = VIA_PM(dev);
 
 pci_set_word(dev->config + PCI_STATUS, PCI_STATUS_FAST_BACK |
  PCI_STATUS_DEVSEL_MEDIUM);
@@ -177,8 +178,7 @@ static void vt82c686b_pm_realize(PCIDevice *dev, Error 
**errp)
 
 apm_init(dev, >apm, NULL, s);
 
-memory_region_init_io(>io, OBJECT(dev), _io_ops, s,
-  "vt82c686-pm", 0x100);
+memory_region_init_io(>io, OBJECT(dev), _io_ops, s, "via-pm", 0x100);
 memory_region_add_subregion(pci_address_space_io(dev), 0, >io);
 memory_region_set_enabled(>io, false);
 
@@ -187,34 +187,61 @@ static void vt82c686b_pm_realize(PCIDevice *dev, Error 
**errp)
 acpi_pm1_cnt_init(>ar, >io, false, false, 2);
 }
 
+typedef struct via_pm_init_info {
+uint16_t device_id;
+} ViaPMInitInfo;
+
 static void via_pm_class_init(ObjectClass *klass, void *data)
 {
 DeviceClass *dc = DEVICE_CLASS(klass);
 PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
+ViaPMInitInfo *info = data;
 
-k->realize = vt82c686b_pm_realize;
+k->realize = via_pm_realize;
 

[PATCH 10/12] vt82c686: QOM-ify superio related functionality

[BALATON Zoltan]

Collect superio functionality and its controlling config registers
handling in an abstract VIA_SUPERIO class that is a subclass of
ISA_SUPERIO and put vt82c686b specific parts in a subclass of this
abstract class.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c | 240 --
 include/hw/isa/vt82c686.h |   1 -
 2 files changed, 150 insertions(+), 91 deletions(-)

diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 26db1a18e2..a755896b8e 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -249,12 +249,21 @@ static const TypeInfo vt8231_pm_info = {
 };
 
 
-typedef struct SuperIOConfig {
+#define TYPE_VIA_SUPERIO "via-superio"
+OBJECT_DECLARE_SIMPLE_TYPE(ViaSuperIOState, VIA_SUPERIO)
+
+struct ViaSuperIOState {
+ISASuperIODevice superio;
 uint8_t regs[0x100];
+const MemoryRegionOps *io_ops;
 MemoryRegion io;
-ISASuperIODevice *superio;
 MemoryRegion *serial_io[SUPERIO_MAX_SERIAL_PORTS];
-} SuperIOConfig;
+};
+
+static inline void via_superio_io_enable(ViaSuperIOState *s, bool enable)
+{
+memory_region_set_enabled(>io, enable);
+}
 
 static MemoryRegion *find_subregion(ISADevice *d, MemoryRegion *parent,
 int offs)
@@ -270,10 +279,76 @@ static MemoryRegion *find_subregion(ISADevice *d, 
MemoryRegion *parent,
 return mr;
 }
 
-static void superio_cfg_write(void *opaque, hwaddr addr, uint64_t data,
-  unsigned size)
+static void via_superio_realize(DeviceState *d, Error **errp)
+{
+ViaSuperIOState *s = VIA_SUPERIO(d);
+ISASuperIOClass *ic = ISA_SUPERIO_GET_CLASS(s);
+int i;
+
+assert(s->io_ops);
+ic->parent_realize(d, errp);
+if (*errp) {
+return;
+}
+/* Grab io regions of serial devices so we can control them */
+for (i = 0; i < ic->serial.count; i++) {
+ISADevice *sd = s->superio.serial[i];
+MemoryRegion *io = isa_address_space_io(sd);
+MemoryRegion *mr = find_subregion(sd, io, sd->ioport_id);
+if (!mr) {
+error_setg(errp, "Could not get io region for serial %d", i);
+return;
+}
+s->serial_io[i] = mr;
+}
+
+memory_region_init_io(>io, OBJECT(d), s->io_ops, s, "via-superio", 2);
+memory_region_set_enabled(>io, false);
+/* The floppy also uses 0x3f0 and 0x3f1 but this seems to work anyway */
+memory_region_add_subregion(isa_address_space_io(ISA_DEVICE(s)), 0x3f0,
+>io);
+}
+
+static uint64_t via_superio_cfg_read(void *opaque, hwaddr addr, unsigned size)
+{
+ViaSuperIOState *sc = opaque;
+uint8_t idx = sc->regs[0];
+uint8_t val = sc->regs[idx];
+
+if (addr == 0) {
+return idx;
+}
+if (addr == 1 && idx == 0) {
+val = 0; /* reading reg 0 where we store index value */
+}
+trace_via_superio_read(idx, val);
+return val;
+}
+
+static void via_superio_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+ISASuperIOClass *sc = ISA_SUPERIO_CLASS(klass);
+
+sc->parent_realize = dc->realize;
+dc->realize = via_superio_realize;
+}
+
+static const TypeInfo via_superio_info = {
+.name  = TYPE_VIA_SUPERIO,
+.parent= TYPE_ISA_SUPERIO,
+.instance_size = sizeof(ViaSuperIOState),
+.class_size= sizeof(ISASuperIOClass),
+.class_init= via_superio_class_init,
+.abstract  = true,
+};
+
+#define TYPE_VT82C686B_SUPERIO "vt82c686b-superio"
+
+static void vt82c686b_superio_cfg_write(void *opaque, hwaddr addr,
+uint64_t data, unsigned size)
 {
-SuperIOConfig *sc = opaque;
+ViaSuperIOState *sc = opaque;
 uint8_t idx = sc->regs[0];
 
 if (addr == 0) { /* config index register */
@@ -295,29 +370,29 @@ static void superio_cfg_write(void *opaque, hwaddr addr, 
uint64_t data,
 case 0xfd ... 0xff:
 /* ignore write to read only registers */
 return;
-case 0xe2:
+case 0xe2: /* Function select */
 {
 data &= 0x1f;
 if (data & BIT(2)) { /* Serial port 1 enable */
-ISADevice *dev = sc->superio->serial[0];
+ISADevice *dev = sc->superio.serial[0];
 if (!memory_region_is_mapped(sc->serial_io[0])) {
 memory_region_add_subregion(isa_address_space_io(dev),
 dev->ioport_id, sc->serial_io[0]);
 }
 } else {
-MemoryRegion *io = isa_address_space_io(sc->superio->serial[0]);
+MemoryRegion *io = isa_address_space_io(sc->superio.serial[0]);
 if (memory_region_is_mapped(sc->serial_io[0])) {
 memory_region_del_subregion(io, sc->serial_io[0]);
 }
 }
 if (data & BIT(3)) { /* Serial port 2 enable */
-ISADevice *dev = sc->superio->serial[1];
+ISADevice *dev = sc->superio.serial[1];
 

[PATCH 00/12] vt82c686b clean ups and vt8231 emulation

[BALATON Zoltan]

These are the remaining patches for VT8231 emulation after the first
half of it was merged. After patch 3 fuloong2e will need the Bonito
REG_MASK fix to be able to map SMBus registers because it's no longer
mapped at fixed address (firmware will do this if it can access the
right register).

BALATON Zoltan (12):
  vt82c686: Move superio memory region to SuperIOConfig struct
  vt82c686: Reorganise code
  vt82c686: Fix SMBus IO base and configuration registers
  vt82c686: Fix up power management io base and config
  vt82c686: Make vt82c686b-pm an abstract base class and add vt8231-pm
based on it
  vt82c686: Simplify vt82c686b_realize()
  vt82c686: Move creation of ISA devices to the ISA bridge
  vt82c686: Fix superio_cfg_{read,write}() functions
  vt82c686: Implement control of serial port io ranges via config regs
  vt82c686: QOM-ify superio related functionality
  vt82c686: Add VT8231_SUPERIO based on VIA_SUPERIO
  vt82c686: Add emulation of VT8231 south bridge

 hw/isa/trace-events   |   2 +
 hw/isa/vt82c686.c | 889 --
 hw/mips/fuloong2e.c   |  33 +-
 include/hw/isa/vt82c686.h |   3 +-
 4 files changed, 679 insertions(+), 248 deletions(-)

-- 
2.21.3

Re: [PATCH] vl: initialize displays _after_ exiting preconfiguration

[BALATON Zoltan]

On Wed, 6 Jan 2021, Paolo Bonzini wrote:

Il mer 6 gen 2021, 18:06 BALATON Zoltan  ha scritto:


On Thu, 17 Dec 2020, Paolo Bonzini wrote:

Due to the renumbering of text consoles when graphical consoles are
created, init_displaystate must be called after all QemuConsoles are
created, i.e. after devices are created.

vl.c calls it from qemu_init_displays, while qmp_x_exit_preconfig is
where devices are created.  If qemu_init_displays is called before it,
the VGA graphical console does not come up.


Tested-by: BALATON Zoltan 

This still seems to be missing from master, who should take care of this?



It's in now, I think.


Yes, got merges with the misc fixes series.

Thanks,
BALATON Zoltan


Paolo



Regards,
BALATON Zoltan


Reported-by: Howard Spoelstra 
Signed-off-by: Paolo Bonzini 
---
softmmu/vl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/softmmu/vl.c b/softmmu/vl.c
index 0ed5c5ba93..7ddf405d76 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -3529,10 +3529,10 @@ void qemu_init(int argc, char **argv, char

**envp)

exit(0);
}

-qemu_init_displays();
if (!preconfig_requested) {
qmp_x_exit_preconfig(_fatal);
}
+qemu_init_displays();
accel_setup_post(current_machine);
os_setup_post();
resume_mux_open();

Re: [PATCH V2 05/22] vl: memfd-alloc option

[Steven Sistare]

On 1/6/2021 3:10 PM, Paolo Bonzini wrote:
> Il mer 6 gen 2021, 17:37 Steven Sistare  > ha scritto:
> 
> Yes, I considered that, but there are other memory regions that cannot be 
> controlled
> by the command line but which must be preserved, such as vram, bios, and 
> rom.  If vram
> is not preserved, parts of the screen will be blank until the user 
> performs some action
> which refreshes the display.  bios and rom should be preserved rather 
> than re-recreated
> with potentially different contents from the firmware images in the 
> updated qemu package.
> 
> However, your comment reminds me that I must add a few lines of code to 
> preserve the
> memory-backend-memfd.
> 
> 
> A new option specific to memory is the wrong way to do this. If a special 
> mode must be specified when starting QEMU, you can make it a -machine option 
> and block the QMP commands unless it's specified. Otherwise you can use 
> "normal" migration to marshal and unmarshal across the update those memory 
> regions that aren't backed by shared memory or memfd.
> 
> Also, because of the mess that vl.c had grown into, adding new "simple" 
> options is going to be very very hard. In fact I am working on turning many 
> options like -smp or -m into syntactic sugar for -machine; at some point I 
> would like to (almost) forbid adding _any_ new option.

Will do.  Thanks for the heads up on the future of vl.c.

I defined the option independently of cpr for generality.  Do you think this 
could be useful?
If yes, I will name and define the -machine option to use memfd;
if no, I will name and define it to enable cpr, and implicitly enable memfd 
without saying so.

- Steve
 

[PATCH v4] gdb: riscv: Add target description

[Sylvain Pelissier]

Target description is not currently implemented in RISC-V
architecture. Thus GDB won't set it properly when attached.
The patch implements the target description response.

Signed-off-by: Sylvain Pelissier 
Reviewed-by: Bin Meng 
Reviewed-by: Alistair Francis 
---
 target/riscv/cpu.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 254cd83f8b..ed4971978b 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -556,6 +556,18 @@ static Property riscv_cpu_properties[] = {
 DEFINE_PROP_END_OF_LIST(),
 };
 
+static gchar *riscv_gdb_arch_name(CPUState *cs)
+{
+RISCVCPU *cpu = RISCV_CPU(cs);
+CPURISCVState *env = >env;
+
+if (riscv_cpu_is_32bit(env)) {
+return g_strdup("riscv:rv32");
+} else {
+return g_strdup("riscv:rv64");
+}
+}
+
 static void riscv_cpu_class_init(ObjectClass *c, void *data)
 {
 RISCVCPUClass *mcc = RISCV_CPU_CLASS(c);
@@ -591,6 +603,7 @@ static void riscv_cpu_class_init(ObjectClass *c, void *data)
 /* For now, mark unmigratable: */
 cc->vmsd = _riscv_cpu;
 #endif
+cc->gdb_arch_name = riscv_gdb_arch_name;
 #ifdef CONFIG_TCG
 cc->tcg_initialize = riscv_translate_init;
 cc->tlb_fill = riscv_cpu_tlb_fill;
-- 
2.25.1

[PATCH V1] gdbstub: suspended state support

[Steve Sistare]

Modify the gdb server so a continue command appears to resume execution
when in RUN_STATE_SUSPENDED.  Do not print the next gdb prompt, but do not
actually resume instruction fetch.  While in this "fake" running mode, a
ctrl-C returns the user to the gdb prompt.

Signed-off-by: Steve Sistare 
---
 gdbstub.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gdbstub.c b/gdbstub.c
index f3a318c..2f0d9ff 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -461,7 +461,9 @@ static inline void gdb_continue(void)
 #else
 if (!runstate_needs_reset()) {
 trace_gdbstub_op_continue();
-vm_start();
+if (!runstate_check(RUN_STATE_SUSPENDED)) {
+vm_start();
+}
 }
 #endif
 }
@@ -490,7 +492,7 @@ static int gdb_continue_partial(char *newstates)
 int flag = 0;
 
 if (!runstate_needs_reset()) {
-if (vm_prepare_start()) {
+if (!runstate_check(RUN_STATE_SUSPENDED) && vm_prepare_start()) {
 return 0;
 }
 
@@ -2835,6 +2837,9 @@ static void gdb_read_byte(uint8_t ch)
 /* when the CPU is running, we cannot do anything except stop
it when receiving a char */
 vm_stop(RUN_STATE_PAUSED);
+} else if (runstate_check(RUN_STATE_SUSPENDED) && ch == 3) {
+/* Received ctrl-c from gdb */
+gdb_vm_state_change(0, 0, RUN_STATE_PAUSED);
 } else
 #endif
 {
@@ -3282,6 +3287,8 @@ static void gdb_sigterm_handler(int signal)
 {
 if (runstate_is_running()) {
 vm_stop(RUN_STATE_PAUSED);
+} else if (runstate_check(RUN_STATE_SUSPENDED)) {
+gdb_vm_state_change(0, 0, RUN_STATE_PAUSED);
 }
 }
 #endif
-- 
1.8.3.1

[PATCH v3] vl: pause option

[Steve Sistare]

Provide the -pause command-line parameter and the QEMU_PAUSE environment
variable to pause QEMU during process startup and allow a developer to
attach a debugger, or observe the process using tools such as strace.
Useful when QEMU has been launched with some other entity, such as libvirt.
QEMU_PAUSE is checked in a constructor at the highest priority, and can
be used to debug other constructors.  The -pause option is checked later,
during argument processing in main, but is useful if passing an environment
variable from a launcher to qemu is awkard.

Usage:
  qemu -pause, or QEMU_PAUSE=1
  After attaching a debugger, send SIGCONT to the qemu process to continue.

Example:

  $ QEMU_PAUSE=1 qemu-system-x86_64 ...
  QEMU pid 18371 is stopped.

 $ gdb -p 18371
 (gdb) break rcu_init
 (gdb) signal SIGCONT
 Breakpoint 1, rcu_init () at util/rcu.c:380

Signed-off-by: Steve Sistare 
---
 qemu-options.hx | 14 ++
 softmmu/vl.c| 32 
 2 files changed, 46 insertions(+)

diff --git a/qemu-options.hx b/qemu-options.hx
index 708583b..212a270 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3668,6 +3668,20 @@ SRST
 option is experimental.
 ERST
 
+DEF("pause", 0, QEMU_OPTION_pause, \
+"-pause  pause the qemu process in main. to continue, send 
SIGCONT.\n"
+"to pause earlier, before constructors are run, set the\n"
+"environment variable QEMU_PAUSE=1 before starting 
qemu.\n",
+QEMU_ARCH_ALL)
+
+SRST
+``-pause``
+Pause the qemu process in main.  This is useful for attaching a debugger
+after QEMU has been launched by some other entity.  After attaching, send
+SIGCONT to continue.  To pause earlier, before constructors are run, set
+the environment variable QEMU_PAUSE=1 before starting qemu.
+ERST
+
 DEF("S", 0, QEMU_OPTION_S, \
 "-S  freeze CPU at startup (use 'c' to start execution)\n",
 QEMU_ARCH_ALL)
diff --git a/softmmu/vl.c b/softmmu/vl.c
index 4eb9d1f..251465d 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -2829,6 +2829,35 @@ static void create_default_memdev(MachineState *ms, 
const char *path)
 _fatal);
 }
 
+static void pause_me(void)
+{
+int sig;
+sigset_t set, oldset;
+
+sigemptyset();
+sigaddset(, SIGCONT);
+printf("QEMU pid %d is stopped.  Send SIGCONT to continue.\n", getpid());
+sigprocmask(SIG_BLOCK, , );
+sigwait(, );
+sigprocmask(SIG_SETMASK, , 0);
+}
+
+static __attribute__((constructor(101))) void maybe_pause(void)
+{
+const char *pause = getenv("QEMU_PAUSE");
+
+if (pause) {
+if (!pause[0] || !strcmp(pause, "1")) {
+pause_me();
+} else if (strcmp(pause, "0")) {
+fprintf(stderr, "error: QEMU_PAUSE bad value %s. Must be 1 or "
+"null to enable, 0 or unset to disable.\n",
+pause);
+exit(1);
+}
+}
+}
+
 void qemu_init(int argc, char **argv, char **envp)
 {
 int i;
@@ -3191,6 +3220,9 @@ void qemu_init(int argc, char **argv, char **envp)
 case QEMU_OPTION_gdb:
 add_device_config(DEV_GDB, optarg);
 break;
+case QEMU_OPTION_pause:
+pause_me();
+break;
 case QEMU_OPTION_L:
 if (is_help_option(optarg)) {
 list_data_dirs = true;
-- 
1.8.3.1

Re: [PATCH V2] vl: pause option

[Steven Sistare]

On 11/5/2020 9:55 AM, Steven Sistare wrote:
> On 11/4/2020 4:40 PM, Alex Bennée wrote:
>> Eric Blake  writes:
>>> On 11/2/20 9:50 AM, Steve Sistare wrote:
 Provide the -pause command-line parameter and the QEMU_PAUSE environment
 variable to pause QEMU during process startup using SIGSTOP and allow a
 developer to attach a debugger, or observe the process using tools such as
 strace.  Useful when the QEMU has been launched with some other entity, 
 such
 as libvirt.  QEMU_PAUSE is checked in a constructor at the highest 
 priority,
 and can be used to debug other constructors.  The -pause option is checked
 later, during argument processing in main, but is useful if passing an
 environment variable from a launcher to qemu is awkard.

 Usage: qemu -pause, or QEMU_PAUSE=1
 After attaching a debugger, send SIGCONT to the qemu process to continue.
>>>
>>> Changing behavior via a new environment variable is awkward.  What
>>> happens, for example, if libvirt inherits this variable set, but is not
>>> aware of its impact to alter how qemu starts up?  Can we get by with
>>> ONLY a command line option?
>>>
>>> Also, how does this option differ from what we already have with qemu
>>> --preconfig?
>>
>> In the original discussion:
>>
>>   Subject: [PATCH V1 12/32] vl: pause option
>>   Date: Thu, 30 Jul 2020 08:14:16 -0700
>>   Message-Id: <1596122076-341293-13-git-send-email-steven.sist...@oracle.com>
>>
>> it seems the idea was to stop qemu as early as possible for debugging
>> when launched by some other launcher which wasn't modifiable except by
>> pass through configuration to QEMU's command line.
>>
>> 
>>
>>> Isn't it always possible to provide a wrapper qemu process to be invoked
>>> by whatever third-party management app (like libvirt), where your
>>> wrapper then starts the real qemu under gdb to begin with, rather than
>>> having to hack qemu itself to have a special start-up mode?
>>
>> I agree - this feels like a bit of an over complication as a debug
>> helper. How many times can a failure to launch by some binary blob not
>> be debugged by either a gdb follow-fork or a copying of the command line
>> and running gdb --args?
> 
> Follow fork is awkward and error prone when the launcher performs many forks 
> before forking
> qemu. gdb --args does not work when the launcher sets up an environment for 
> qemu to run
> in, pre-opening fd's being just one example.  For developers, often the 
> "launcher" is a 
> script that performs setup and passes the myriad qemu options.  Even in that 
> case, it is
> easier to add a flag or set an env var to enable debugging. The pause option 
> is fast 
> (for the user) and reliable.  
> 
> I have a new version of the patch that handles the signal more smoothly, so 
> the handshake
> with gdb is easier:
> 
> $ QEMU_PAUSE=1 qemu-system-x86_64 ...
> QEMU pid 18371 is stopped.
> 
>  $ gdb -p 18371
>  (gdb) break rcu_init
>  (gdb) signal SIGCONT
>  Breakpoint 1, rcu_init () at 
> util/rcu.c:380
> 
> The implementation does not even send a signal to qemu, so the launcher is 
> none the wiser:
> 
> static void pause_me(void)
> {
> int sig;
> sigset_t set, oldset;
> sigemptyset();
> sigaddset(, SIGCONT);
> printf("QEMU pid %d is stopped.  Send SIGCONT to continue.\n", getpid());
> sigprocmask(SIG_BLOCK, , );
> sigwait(, );  <-- PAUSES HERE
> sigprocmask(SIG_SETMASK, , 0);
> }
> 
> 
> I will post it if you are still open to the idea.  Please let me know.

I am posting a V3 version of the patch with the above change.  I have found it 
easy to
use and robust. See your inboxes shortly.

- Steve

[PULL v4 4/4] cirrus: don't run full qtest on macOS

[Alex Bennée]

From: Daniel P. Berrangé 

The Cirrus CI macOS build hosts have exhibited a serious performance
degradation in recent months. For example the "qom-test" qtest takes
over an hour for only the qemu-system-aarch64 binary. This is as much
20-40 times slower than other environments. The other qtests all show
similar performance degradation, as do many of the unit tests.

This does not appear related to QEMU code changes, since older git
commits which were known to fully complete in less than 1 hour on
Cirrus CI now also show similar bad performance. Either Cirrus CI
performance has degraded, or an change in its environment has exposed
a latent bug widely affecting all of QEMU. Debugging the qom-test
showed no easily identified large bottleneck - every step of the
test execution was simply slower.

macOS builds/tests run outside Cirrus CI show normal performance.

With an inability to identify any obvious problem, the only viable
way to get a reliably completing Cirrus CI macOS job is to cut out
almost all of the qtests. We choose to run the x86_64 target only,
since that has very few machine types and thus is least badly
impacted in the qom-test execution.

With this change, the macOS jobs complete in approx 35 minutes.

Signed-off-by: Daniel P. Berrangé 
Reviewed-by: Thomas Huth 
Reviewed-by: Willian Rampazzo 
Message-Id: <20210106114159.981538-1-berra...@redhat.com>
Signed-off-by: Alex Bennée 

diff --git a/.cirrus.yml b/.cirrus.yml
index 62a9b57530..3907e036da 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -18,7 +18,6 @@ freebsd_12_task:
 - gmake -j$(sysctl -n hw.ncpu) check V=1
 
 macos_task:
-  timeout_in: 90m
   osx_instance:
 image: catalina-base
   install_script:
@@ -30,10 +29,13 @@ macos_task:
--extra-cflags='-Wno-error=deprecated-declarations'
|| { cat config.log meson-logs/meson-log.txt; exit 1; }
 - gmake -j$(sysctl -n hw.ncpu)
-- gmake check V=1
+- gmake check-unit V=1
+- gmake check-block V=1
+- gmake check-qapi-schema V=1
+- gmake check-softfloat V=1
+- gmake check-qtest-x86_64 V=1
 
 macos_xcode_task:
-  timeout_in: 90m
   osx_instance:
 # this is an alias for the latest Xcode
 image: catalina-xcode
@@ -45,7 +47,11 @@ macos_xcode_task:
 - ../configure --extra-cflags='-Wno-error=deprecated-declarations' 
--enable-modules
--enable-werror --cc=clang || { cat config.log 
meson-logs/meson-log.txt; exit 1; }
 - gmake -j$(sysctl -n hw.ncpu)
-- gmake check V=1
+- gmake check-unit V=1
+- gmake check-block V=1
+- gmake check-qapi-schema V=1
+- gmake check-softfloat V=1
+- gmake check-qtest-x86_64 V=1
 
 windows_msys2_task:
   timeout_in: 90m
-- 
2.20.1

[PULL v4 0/4] more testing fixes (all green now)

[Alex Bennée]

The following changes since commit aadac5b3d9fdce28030495f80fc76a4336e97328:

  Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into 
staging (2021-01-06 15:55:29 +)

are available in the Git repository at:

  https://github.com/stsquad/qemu.git tags/pull-testing-060121-4

for you to fetch changes up to af229fc367021e361cebaf84acceb01f28922cc4:

  cirrus: don't run full qtest on macOS (2021-01-06 17:30:02 +)


Testing updates (back to green)

  - include ccache in Debian 10 docker image
  - iotests: drop 312 from auto group
  - bound reading of s390x framebuffer file
  - cirrus: drop non-x86 tests so we complete


Alex Bennée (2):
  tests/iotests: drop test 312 from auto group
  tests/acceptance: bound the size of readline in s390_ccw_virtio

Daniel P. Berrangé (1):
  cirrus: don't run full qtest on macOS

Philippe Mathieu-Daudé (1):
  tests/docker: Include 'ccache' in Debian base image

 .cirrus.yml | 14 ++
 tests/acceptance/machine_s390_ccw_virtio.py |  2 +-
 tests/docker/dockerfiles/debian10.docker|  1 +
 tests/qemu-iotests/group|  2 +-
 4 files changed, 13 insertions(+), 6 deletions(-)

-- 
2.20.1

[PULL v4 3/4] tests/acceptance: bound the size of readline in s390_ccw_virtio

[Alex Bennée]

The read binary data as text via a PPM export of the frame buffer
seems a bit sketchy and it did blow up in the real world when the
assertion failed:

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

However short of cleaning up the test to be more binary focused at
least limit the attempt to dump the whole file as hexified zeros in
the logs.

Signed-off-by: Alex Bennée 
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Willian Rampazzo 
Acked-by: Halil Pasic 
Acked-by: Thomas Huth 
Message-Id: <20210105124405.15424-1-alex.ben...@linaro.org>

diff --git a/tests/acceptance/machine_s390_ccw_virtio.py 
b/tests/acceptance/machine_s390_ccw_virtio.py
index 0f81af9950..eccf26b262 100644
--- a/tests/acceptance/machine_s390_ccw_virtio.py
+++ b/tests/acceptance/machine_s390_ccw_virtio.py
@@ -241,7 +241,7 @@ class S390CCWVirtioMachine(Test):
 self.assertEqual(line, b"1024 768\n")
 line = ppmfile.readline()
 self.assertEqual(line, b"255\n")
-line = ppmfile.readline()
+line = ppmfile.readline(256)
 self.assertEqual(line, b"The quick fox jumps over a lazy dog\n")
 
 # Hot-plug a virtio-crypto device and see whether it gets accepted
-- 
2.20.1

[PULL v4 2/4] tests/iotests: drop test 312 from auto group

[Alex Bennée]

The "auto" documentation states:

  That means they should run with every QEMU binary (also non-x86)

which is not the case as the check-system-fedora build which only
includes a rag tag group of rare and deprecated targets doesn't
support the virtio device required.

Fixes: ef9bba1484b ("quorum: Implement bdrv_co_block_status()")
Signed-off-by: Alex Bennée 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20210105100402.12350-1-alex.ben...@linaro.org>

diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index e4fb6327ae..bc5bc324fe 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -318,4 +318,4 @@
 307 rw quick export
 308 rw
 309 rw auto quick
-312 rw auto quick
+312 rw quick
-- 
2.20.1

[PULL v4 1/4] tests/docker: Include 'ccache' in Debian base image

[Alex Bennée]

From: Philippe Mathieu-Daudé 

Include the 'ccache' package to speed up compilation.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20201213211601.253530-1-f4...@amsat.org>
Fixes: d6db2a1cdf ("docker: add debian-buster-arm64-cross")
Signed-off-by: Alex Bennée 

diff --git a/tests/docker/dockerfiles/debian10.docker 
b/tests/docker/dockerfiles/debian10.docker
index 73a3caac9c..9d42b5a4b8 100644
--- a/tests/docker/dockerfiles/debian10.docker
+++ b/tests/docker/dockerfiles/debian10.docker
@@ -20,6 +20,7 @@ RUN apt update && \
 bc \
 build-essential \
 ca-certificates \
+ccache \
 clang \
 dbus \
 gdb-multiarch \
-- 
2.20.1

Re: [PATCH V2 05/22] vl: memfd-alloc option

[Paolo Bonzini]

Il mer 6 gen 2021, 17:37 Steven Sistare  ha
scritto:

> Yes, I considered that, but there are other memory regions that cannot be
> controlled
> by the command line but which must be preserved, such as vram, bios, and
> rom.  If vram
> is not preserved, parts of the screen will be blank until the user
> performs some action
> which refreshes the display.  bios and rom should be preserved rather than
> re-recreated
> with potentially different contents from the firmware images in the
> updated qemu package.
>
> However, your comment reminds me that I must add a few lines of code to
> preserve the
> memory-backend-memfd.
>

A new option specific to memory is the wrong way to do this. If a special
mode must be specified when starting QEMU, you can make it a -machine
option and block the QMP commands unless it's specified. Otherwise you can
use "normal" migration to marshal and unmarshal across the update those
memory regions that aren't backed by shared memory or memfd.

Also, because of the mess that vl.c had grown into, adding new "simple"
options is going to be very very hard. In fact I am working on turning many
options like -smp or -m into syntactic sugar for -machine; at some point I
would like to (almost) forbid adding _any_ new option.

Paolo



> - Steve
>
>

Re: [PATCH v2 1/1] vl.c: do not execute trace_init_backends() before daemonizing

[Paolo Bonzini]

Il mer 6 gen 2021, 17:59 Stefan Hajnoczi  ha scritto:

> Acked-by: Stefan Hajnoczi 

Re: [PATCH] vl: initialize displays _after_ exiting preconfiguration

[Paolo Bonzini]

Il mer 6 gen 2021, 18:06 BALATON Zoltan  ha scritto:

> On Thu, 17 Dec 2020, Paolo Bonzini wrote:
> > Due to the renumbering of text consoles when graphical consoles are
> > created, init_displaystate must be called after all QemuConsoles are
> > created, i.e. after devices are created.
> >
> > vl.c calls it from qemu_init_displays, while qmp_x_exit_preconfig is
> > where devices are created.  If qemu_init_displays is called before it,
> > the VGA graphical console does not come up.
>
> Tested-by: BALATON Zoltan 
>
> This still seems to be missing from master, who should take care of this?
>

It's in now, I think.

Paolo


> Regards,
> BALATON Zoltan
>
> > Reported-by: Howard Spoelstra 
> > Signed-off-by: Paolo Bonzini 
> > ---
> > softmmu/vl.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/softmmu/vl.c b/softmmu/vl.c
> > index 0ed5c5ba93..7ddf405d76 100644
> > --- a/softmmu/vl.c
> > +++ b/softmmu/vl.c
> > @@ -3529,10 +3529,10 @@ void qemu_init(int argc, char **argv, char
> **envp)
> > exit(0);
> > }
> >
> > -qemu_init_displays();
> > if (!preconfig_requested) {
> > qmp_x_exit_preconfig(_fatal);
> > }
> > +qemu_init_displays();
> > accel_setup_post(current_machine);
> > os_setup_post();
> > resume_mux_open();
> >
>
>

[Bug 1829459] Re: qemu seems to lack support for pid namespace.

[-]

The same issue persists in qemu-5.2.0.

-
# qemu-aarch64 --version
qemu-aarch64 version 5.2.0
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
-

Symptoms when running inside the aarch64 chroot, with both aarch64 and x86_64 
binaries:
-
# which unshare bash
/usr/bin/unshare
/bin/bash
# file $(!!)
file $(which unshare bash)
/usr/bin/unshare: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 
3.7.0, stripped
/bin/bash:ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), 
dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 
3.7.0, stripped
# unshare --pid -- bash -c 'echo hello world'
qemu: qemu_thread_create: Invalid argument
Aborted (core dumped)
# # --- switch to an x86_64 shell _inside_ the chroot
# LD_LIBRARY_PATH=/x86_64/lib64 PATH=/x86_64/bin:$PATH bash 
# which unshare bash
/x86_64/bin/unshare
/x86_64/bin/bash
# file $(!!)
file $(which unshare bash)
/x86_64/bin/unshare: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, stripped
/x86_64/bin/bash:ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), 
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 
3.2.0, stripped
# unshare --pid -- bash -c 'echo hello world' 
hello world
# 
-

I can share the core dump, in case that's useful.

On this system, the qemu-aarch64 binary on the host is statically built
and binfmt_misc is configured as follows:
-
:aarch64:M::\x7f\x45\x4c\x46\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7:\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff:/usr/bin/qemu-aarch64:CF
-

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

Title:
  qemu seems to lack support for pid namespace.

Status in QEMU:
  New

Bug description:
  # Version

  qemu-4.0.0
  glibc-2.28

  # commands used to launch qemu-aarch64 in user mode.

  : ${QEMU_BINFMT_FLAGS:=OC}

  printf '%s\n' ':qemu-
  
aarch64:M::\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin
  /qemu-aarch64:'"${QEMU_BINFMT_FLAGS}"
  >/proc/sys/fs/binfmt_misc/register

  > sudo cp /usr/bin/qemu-aarch64 $RPI/usr/bin
  > sudo chroot $RPI /bin/ksh -l

  # host

  Gentoo Linux amd64

  # Guest

  Gentoo Linux aarch64

  # The problem that I have

  "emerge" program fails due to the error, "qemu: qemu_thread_create: Invalid 
argument".
  "emerge" is Gentoo's package manager that compiles and installs packages.

  # Workaround

  Disable pid-sandbox in emerge.

  # How to reproduce the issue

  Execute

  unshare --pid -- echo hello world

  or

  python -c "import portage.process; portage.process.spawn(['echo',
  'hello', 'world'], unshare_pid=True)"

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

Re: [Linuxarm] Re: [RFC PATCH v2 07/32] hw/cxl/device: Implement basic mailbox (8.2.8.4)

[Ben Widawsky]

On 21-01-06 10:05:57, Ben Widawsky wrote:
> On 21-01-06 17:40:14, Jonathan Cameron wrote:
> > On Wed, 6 Jan 2021 13:21:23 +
> > Jonathan Cameron  wrote:
> > 
> > > On Tue, 5 Jan 2021 08:52:58 -0800
> > > Ben Widawsky  wrote:
> > > 

[snip]

> 
> I'm sorry you had to debug this. I had fixed this previously and it got lost.
> I'm currently between test applications, so my regression testing isn't great.
> 
> I think the fix should be something like this, but I can't easily test at the
> moment:
> 
> diff --git a/hw/cxl/cxl-device-utils.c b/hw/cxl/cxl-device-utils.c
> index c515d45d20..b38e9b4c17 100644
> --- a/hw/cxl/cxl-device-utils.c
> +++ b/hw/cxl/cxl-device-utils.c
> @@ -102,6 +102,9 @@ static void mailbox_reg_write(void *opaque, hwaddr 
> offset, uint64_t value,
>  {
>  CXLDeviceState *cxl_dstate = opaque;
> 
> +if (offset >= A_CXL_DEV_CMD_PAYLOAD)
> +stn_le_p(cxl_dstate->mbox_reg_state, size, value);
> +
>  /*
>   * Lock is needed to prevent concurrent writes as well as to prevent 
> writes
>   * coming in while the firmware is processing. Without background 
> commands
> 
> 
> 

+if (offset >= A_CXL_DEV_CMD_PAYLOAD) {
+stn_le_p(cxl_dstate->mbox_reg_state, size, value);
+return;
+}
+

[snip]

> 

Re: [PATCH v3 1/3] update-linux-headers: Include const.h

[Peter Xu]

On Mon, Jan 04, 2021 at 09:20:55PM +0100, Eric Farman wrote:
> Kernel commit a85cbe6159ff ("uapi: move constants from
>  to ") breaks our script
> because of the unrecognized include. Let's add that to
> our processing.
> 
> Signed-off-by: Eric Farman 
> ---
>  scripts/update-linux-headers.sh | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/update-linux-headers.sh b/scripts/update-linux-headers.sh
> index 9efbaf2f84..fa6f2b6272 100755
> --- a/scripts/update-linux-headers.sh
> +++ b/scripts/update-linux-headers.sh
> @@ -41,6 +41,7 @@ cp_portable() {
>   -e 'pvrdma_verbs' \
>   -e 'drm.h' \
>   -e 'limits' \
> + -e 'linux/const' \
>   -e 'linux/kernel' \
>   -e 'linux/sysinfo' \
>   -e 'asm-generic/kvm_para' \
> @@ -190,7 +191,9 @@ for i in "$tmpdir"/include/linux/*virtio*.h \
>   "$tmpdir/include/linux/input.h" \
>   "$tmpdir/include/linux/input-event-codes.h" \
>   "$tmpdir/include/linux/pci_regs.h" \
> - "$tmpdir/include/linux/ethtool.h" "$tmpdir/include/linux/kernel.h" \
> + "$tmpdir/include/linux/ethtool.h" \
> + "$tmpdir/include/linux/const.h" \
> + "$tmpdir/include/linux/kernel.h" \
>   "$tmpdir/include/linux/vhost_types.h" \
>   "$tmpdir/include/linux/sysinfo.h"; do
>  cp_portable "$i" "$output/include/standard-headers/linux"
> -- 
> 2.17.1

So I think I came to the same change when trying to update the headers. :)

Reviewed-by: Peter Xu 

Could I ask why the const.h is installed into include/standard-headers/linux
rather than linux-headers/linux?  When I was working on my version I failed to
figure out the difference.

One answer is ethtool.h is there which included const.h, but I guess that's not
the real one.

Thanks,

-- 
Peter Xu

[PATCH] docs/system: Remove deprecated 'fulong2e' machine alias

[Philippe Mathieu-Daudé]

The 'fulong2e' machine alias has been marked as deprecated since
QEMU v5.1 (commit c3a09ff68dd, the machine is renamed 'fuloong2e').
Time to remove it now.

Signed-off-by: Philippe Mathieu-Daudé 
---
 docs/system/deprecated.rst   | 5 -
 docs/system/removed-features.rst | 5 +
 hw/mips/fuloong2e.c  | 1 -
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
index bacd76d7a58..e20bfcb17a4 100644
--- a/docs/system/deprecated.rst
+++ b/docs/system/deprecated.rst
@@ -309,11 +309,6 @@ The 'scsi-disk' device is deprecated. Users should use 
'scsi-hd' or
 System emulator machines
 
 
-mips ``fulong2e`` machine (since 5.1)
-'
-
-This machine has been renamed ``fuloong2e``.
-
 ``pc-1.0``, ``pc-1.1``, ``pc-1.2`` and ``pc-1.3`` (since 5.0)
 '
 
diff --git a/docs/system/removed-features.rst b/docs/system/removed-features.rst
index 8b20d78a4d0..430fc33ca18 100644
--- a/docs/system/removed-features.rst
+++ b/docs/system/removed-features.rst
@@ -120,6 +120,11 @@ mips ``r4k`` platform (removed in 5.2)
 This machine type was very old and unmaintained. Users should use the ``malta``
 machine type instead.
 
+mips ``fulong2e`` machine alias (removed in 6.0)
+
+
+This machine has been renamed ``fuloong2e``.
+
 Related binaries
 
 
diff --git a/hw/mips/fuloong2e.c b/hw/mips/fuloong2e.c
index 29805242caa..bac2adbd5ae 100644
--- a/hw/mips/fuloong2e.c
+++ b/hw/mips/fuloong2e.c
@@ -383,7 +383,6 @@ static void mips_fuloong2e_init(MachineState *machine)
 static void mips_fuloong2e_machine_init(MachineClass *mc)
 {
 mc->desc = "Fuloong 2e mini pc";
-mc->alias = "fulong2e"; /* Incorrect name used up to QEMU 4.2 
*/
 mc->init = mips_fuloong2e_init;
 mc->block_default_type = IF_IDE;
 mc->default_cpu_type = MIPS_CPU_TYPE_NAME("Loongson-2E");
-- 
2.26.2

Re: [PATCH v2 02/24] target/mips/translate: Expose check_mips_64() to 32-bit mode

[Philippe Mathieu-Daudé]

On Wed, Jan 6, 2021 at 7:20 PM Philippe Mathieu-Daudé  wrote:
>
> Hi,
>
> ping for code review? :)

FWIW the full series (rebased on mips-next) is available here:
https://gitlab.com/philmd/qemu/-/commits/mips_msa_decodetree

>
> Due to the "Simplify ISA definitions"
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg770056.html
> patch #3 is not necessary.
>
> This is the last patch unreviewed.
>
> On 12/15/20 11:57 PM, Philippe Mathieu-Daudé wrote:
> > To allow compiling 64-bit specific translation code more
> > generically (and removing #ifdef'ry), allow compiling
> > check_mips_64() on 32-bit targets.
> > If ever called on 32-bit, we obviously emit a reserved
> > instruction exception.
> >
> > Signed-off-by: Philippe Mathieu-Daudé 
> > ---
> >  target/mips/translate.h | 2 --
> >  target/mips/translate.c | 8 +++-
> >  2 files changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/target/mips/translate.h b/target/mips/translate.h
> > index a9eab69249f..942d803476c 100644
> > --- a/target/mips/translate.h
> > +++ b/target/mips/translate.h
> > @@ -127,9 +127,7 @@ void generate_exception_err(DisasContext *ctx, int 
> > excp, int err);
> >  void generate_exception_end(DisasContext *ctx, int excp);
> >  void gen_reserved_instruction(DisasContext *ctx);
> >  void check_insn(DisasContext *ctx, uint64_t flags);
> > -#ifdef TARGET_MIPS64
> >  void check_mips_64(DisasContext *ctx);
> > -#endif
> >  void check_cp1_enabled(DisasContext *ctx);
> >
> >  void gen_base_offset_addr(DisasContext *ctx, TCGv addr, int base, int 
> > offset);
> > diff --git a/target/mips/translate.c b/target/mips/translate.c
> > index 5c62b32c6ae..af543d1f375 100644
> > --- a/target/mips/translate.c
> > +++ b/target/mips/translate.c
> > @@ -2972,18 +2972,16 @@ static inline void check_ps(DisasContext *ctx)
> >  check_cp1_64bitmode(ctx);
> >  }
> >
> > -#ifdef TARGET_MIPS64
> >  /*
> > - * This code generates a "reserved instruction" exception if 64-bit
> > - * instructions are not enabled.
> > + * This code generates a "reserved instruction" exception if cpu is not
> > + * 64-bit or 64-bit instructions are not enabled.
> >   */
> >  void check_mips_64(DisasContext *ctx)
> >  {
> > -if (unlikely(!(ctx->hflags & MIPS_HFLAG_64))) {
> > +if (unlikely((TARGET_LONG_BITS != 64) || !(ctx->hflags & 
> > MIPS_HFLAG_64))) {
>
> Since TARGET_LONG_BITS is known at build time, this can be simplified
> as:
>
> if ((TARGET_LONG_BITS != 64) || unlikely!(ctx->hflags & MIPS_HFLAG_64)))
>
> >  gen_reserved_instruction(ctx);
> >  }
> >  }
> > -#endif
> >
> >  #ifndef CONFIG_USER_ONLY
> >  static inline void check_mvh(DisasContext *ctx)
> >

Re: [PATCH v2 02/24] target/mips/translate: Expose check_mips_64() to 32-bit mode

[Philippe Mathieu-Daudé]

Hi,

ping for code review? :)

Due to the "Simplify ISA definitions"
https://www.mail-archive.com/qemu-devel@nongnu.org/msg770056.html
patch #3 is not necessary.

This is the last patch unreviewed.

On 12/15/20 11:57 PM, Philippe Mathieu-Daudé wrote:
> To allow compiling 64-bit specific translation code more
> generically (and removing #ifdef'ry), allow compiling
> check_mips_64() on 32-bit targets.
> If ever called on 32-bit, we obviously emit a reserved
> instruction exception.
> 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  target/mips/translate.h | 2 --
>  target/mips/translate.c | 8 +++-
>  2 files changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/target/mips/translate.h b/target/mips/translate.h
> index a9eab69249f..942d803476c 100644
> --- a/target/mips/translate.h
> +++ b/target/mips/translate.h
> @@ -127,9 +127,7 @@ void generate_exception_err(DisasContext *ctx, int excp, 
> int err);
>  void generate_exception_end(DisasContext *ctx, int excp);
>  void gen_reserved_instruction(DisasContext *ctx);
>  void check_insn(DisasContext *ctx, uint64_t flags);
> -#ifdef TARGET_MIPS64
>  void check_mips_64(DisasContext *ctx);
> -#endif
>  void check_cp1_enabled(DisasContext *ctx);
>  
>  void gen_base_offset_addr(DisasContext *ctx, TCGv addr, int base, int 
> offset);
> diff --git a/target/mips/translate.c b/target/mips/translate.c
> index 5c62b32c6ae..af543d1f375 100644
> --- a/target/mips/translate.c
> +++ b/target/mips/translate.c
> @@ -2972,18 +2972,16 @@ static inline void check_ps(DisasContext *ctx)
>  check_cp1_64bitmode(ctx);
>  }
>  
> -#ifdef TARGET_MIPS64
>  /*
> - * This code generates a "reserved instruction" exception if 64-bit
> - * instructions are not enabled.
> + * This code generates a "reserved instruction" exception if cpu is not
> + * 64-bit or 64-bit instructions are not enabled.
>   */
>  void check_mips_64(DisasContext *ctx)
>  {
> -if (unlikely(!(ctx->hflags & MIPS_HFLAG_64))) {
> +if (unlikely((TARGET_LONG_BITS != 64) || !(ctx->hflags & 
> MIPS_HFLAG_64))) {

Since TARGET_LONG_BITS is known at build time, this can be simplified
as:

if ((TARGET_LONG_BITS != 64) || unlikely!(ctx->hflags & MIPS_HFLAG_64)))

>  gen_reserved_instruction(ctx);
>  }
>  }
> -#endif
>  
>  #ifndef CONFIG_USER_ONLY
>  static inline void check_mvh(DisasContext *ctx)
> 

Re: [PATCH 6/6] spapr: Model DR connectors as simple objects

[Greg Kurz]

On Mon, 28 Dec 2020 19:28:39 +1100
David Gibson  wrote:

> On Fri, Dec 18, 2020 at 11:34:00AM +0100, Greg Kurz wrote:
> > Modeling DR connectors as individual devices raises some
> > concerns, as already discussed a year ago in this thread:
> > 
> > https://patchew.org/QEMU/20191017205953.13122-1-chel...@linux.vnet.ibm.com/
> > 
> > First, high maxmem settings creates too many DRC devices.
> > This causes scalability issues. It severely increase boot
> > time because the multiple traversals of the DRC list that
> > are performed during machine setup are quadratic operations.
> > This is directly related to the fact that DRCs are modeled
> > as individual devices and added to the composition tree.
> > 
> > Second, DR connectors are really an internal concept of
> > PAPR. They aren't something that the user or management
> > layer can manipulate in any way. We already don't allow
> > their creation with device_add by clearing user_creatable.
> > 
> > DR connectors don't even need to be modeled as actual
> > devices since they don't sit in a bus. They just need
> > to be associated to an 'owner' object and to have the
> > equivalent of realize/unrealize functions.
> > 
> > Downgrade them to be simple objects. Convert the existing
> > realize() and unrealize() to be methods of the DR connector
> > base class. Also have the base class to inherit from the
> > vmstate_if interface directly. The get_id() hook simply
> > returns NULL, just as device_vmstate_if_get_id() does for
> > devices that don't sit in a bus. The DR connector is no
> > longer made a child object. This means that it must be
> > explicitely freed when no longer needed. This is only
> > required for PHBs and PCI bridges actually : have them to
> > free the DRC with spapr_dr_connector_free() instead of
> > object_unparent().
> > 
> > No longer add the DRCs to the QOM composition tree. Track
> > them with a glib hash table using the global DRC index as
> > the key instead. This makes traversal a linear operation.
> 
> I have some reservations about this one.  The main thing is that
> attaching migration state to something that's not a device seems a bit
> odd to me.  AFAICT exactly one other non-device implements
> TYPE_VMSTATE_IF, and what it does isn't very clear to me.
> 

Even with your proposal below, the current SpaprDrc type, which is
used all over the place, will stop being a TYPE_DEVICE but we still
need to support migration with existing machine types for which DRC
are devices. Implementing TYPE_VMSTATE_IF is essentially a hack that
allows to do that without keeping the current TYPE_DEVICE based
implementation around.

> As I might have mentioned to you I had a different idea for how to
> address this problem: still use a TYPE_DEVICE, but have it manage a
> whole array of DRCs as one unit, rather than just a single one.
> Specifically I was thinking:
> 
> * one array per PCI bus (DRCs for each function on the bus)
> * one array for each block of memory (so one for base memory, one for
>   each DIMM)
> * one array for all the cpus
> * one array for all the PHBs
> 
> It has some disadvantages compared to your scheme: it still leaves
> (less) devices which can't be user managed, which is a bit ugly.  On
> the other hand, each of those arrays can reasonably be dense, so we
> can use direct indexing rather than a hash table, which is a bit
> nicer.
> 
> Thoughts?
> 

I find it a bit overkill to introduce a new TYPE_DEVICE (let's
call it a DRC manager) for something that:
- doesn't sit on a bus
- can't be user managed
- isn't directly represented to the guest as a full node
  in the DT unlike all other devices, but just as indexes
  in some properties of actual DR capable devices.

Given that the DRC index space is global and this is what
the guest passes to DR RTAS calls, we can't do direct
indexing, strictly speaking. We need at least some logic
to dispatch operations on individual DRC states to the
appropriate DRC manager. This logic belongs to the machine
IMHO.

This shouldn't be too complex for CPUs and PHBs since they
sit directly under the machine and have 1:1 relation with
the attached device. It just boils down to instantiate
some DRC managers during machine init:

- range [ 0x1000 ... 0x1000 + ${max_cpus} [
  for CPUs
- range [ 0x2000 ... 0x2000 + 31 [
  for PHBs

For memory, the code currently generates DRC indexes in the range:

[ 0x8000 ... 0x8000 + ${base_ram_size}/256M ... ${max_ram_size}/256M [

ie. it doesn't generate DRC indexes for the base memory AFAICT. Also
each DIMM can be of arbitrary size, ie. consume an arbitrary amount
of DRC indexes. So the machine would instantiate SPAPR_MAX_RAM_SLOTS (32)
DRC managers, each capable of managing the full set of LMB DRCs, just
in case ? Likely a lot of zeroes with high maxmem settings but I guess
we can live with it.

PCI busses would need some extra care though since the machine
doesn't know about them. This would require to be able to
register/unregister DRC 

Re: [Linuxarm] Re: [RFC PATCH v2 07/32] hw/cxl/device: Implement basic mailbox (8.2.8.4)

[Ben Widawsky]

On 21-01-06 17:40:14, Jonathan Cameron wrote:
> On Wed, 6 Jan 2021 13:21:23 +
> Jonathan Cameron  wrote:
> 
> > On Tue, 5 Jan 2021 08:52:58 -0800
> > Ben Widawsky  wrote:
> > 
> > > This is the beginning of implementing mailbox support for CXL 2.0
> > > devices.
> > > 
> > > v2: Use register alignment helper (Ben)
> > > Minor cleanups (Jonathan)
> > > Rename error codes to match spec (Jonathan)
> > > Update cap count from 1 to 2 (Jonathan)
> > > Add infra to support CEL (Ben)
> > > Add more of the actual mailbox handling from later patch (Ben)
> > > 
> > > Signed-off-by: Ben Widawsky   
> > 
> > Hi Ben,
> > 
> > I hacked support in for ARM64 to give this a spin and ran into an
> > interesting problem around read sizes.
> > 
> > The mailbox registers space allows 4 or 8 byte reads, but in the kernel
> > driver (I think I have the right version from your github) you do
> > the payload drain with
> > memcpy_from_io()
> > 
> > If the size of the payload is not a multiple of 8 bytes, on ARM64 that
> > results in byte reads and an exception.  This happens with some of the
> > existing calls which happen to have non multiple of 8 payload sizes.
> > 
> > I hacked below to allow 1 byte reads from that region but that's probably
> > not the right fix.  I found a statement in the CXL spec saying maximum read
> > size from this register block was 8 bytes but couldn't immediately see a 
> > minimum.
> > (I haven't looked that hard yet though!)
> > 
> > Various approaches in kernel could also be used:
> > 1) Change the payload drain to have specific handling for the end few bytes.
> > 2) Pad the various structures to ensure payloads are always 8 byte multiples
> > in length (nasty).
> 
> Bit more testing an another little thing below.
> 
> J
> 
> > 
> > > ---
> > >  hw/cxl/cxl-device-utils.c   | 122 -
> > >  hw/cxl/cxl-mailbox-utils.c  | 173 
> > >  hw/cxl/meson.build  |   1 +
> > >  include/hw/cxl/cxl.h|   3 +
> > >  include/hw/cxl/cxl_device.h |  27 +-
> > >  5 files changed, 322 insertions(+), 4 deletions(-)
> > >  create mode 100644 hw/cxl/cxl-mailbox-utils.c
> > > 
> > > diff --git a/hw/cxl/cxl-device-utils.c b/hw/cxl/cxl-device-utils.c
> > > index b86e5466bd..642e3c2617 100644
> > > --- a/hw/cxl/cxl-device-utils.c
> > > +++ b/hw/cxl/cxl-device-utils.c
> > > @@ -44,6 +44,108 @@ static uint64_t dev_reg_read(void *opaque, hwaddr 
> > > offset, unsigned size)
> > >  return ldn_le_p(, size);
> > >  }
> > >  
> > > +static uint64_t mailbox_reg_read(void *opaque, hwaddr offset, unsigned 
> > > size)
> > > +{
> > > +CXLDeviceState *cxl_dstate = opaque;
> > > +
> > > +if (cxl_device_check_register_alignment(offset, size)) {
> > > +qemu_log_mask(LOG_UNIMP, "Unaligned register read\n");
> > > +return 0;
> > > +}
> > > +
> > > +return ldn_le_p(cxl_dstate->mbox_reg_state + offset, size);
> > > +}
> > > +
> > > +static void mailbox_mem_writel(uint32_t *reg_state, hwaddr offset,
> > > +   uint64_t value)
> > > +{
> > > +switch (offset) {
> > > +case A_CXL_DEV_MAILBOX_CTRL:
> > > +/* fallthrough */
> > > +case A_CXL_DEV_MAILBOX_CAP:
> > > +/* RO register */
> > > +break;
> > > +default:
> > > +qemu_log_mask(LOG_UNIMP,
> > > +  "%s Unexpected 32-bit access to 0x%" PRIx64 " 
> > > (WI)\n",
> > > +  __func__, offset);
> > > +break;
> > > +}
> > > +
> > > +stl_le_p((uint8_t *)reg_state + offset, value);
> > > +}
> > > +
> > > +static void mailbox_mem_writeq(uint8_t *reg_state, hwaddr offset,
> > > +   uint64_t value)
> > > +{
> > > +switch (offset) {
> > > +case A_CXL_DEV_MAILBOX_CMD:
> > > +break;
> > > +case A_CXL_DEV_BG_CMD_STS:
> > > +/* BG not supported */
> > > +/* fallthrough */
> > > +case A_CXL_DEV_MAILBOX_STS:
> > > +/* Read only register, will get updated by the state machine */
> > > +return;
> > > +default:
> > > +qemu_log_mask(LOG_UNIMP,
> > > +  "%s Unexpected 64-bit access to 0x%" PRIx64 " 
> > > (WI)\n",
> > > +  __func__, offset);
> 
> I've been debugging mail box issues and it seems we can hit this path if
> a payload is written by the OS.  Result is it never gets written into the 
> memory
> and hence isn't available when we try to read it below.
> 

I'm sorry you had to debug this. I had fixed this previously and it got lost.
I'm currently between test applications, so my regression testing isn't great.

I think the fix should be something like this, but I can't easily test at the
moment:

diff --git a/hw/cxl/cxl-device-utils.c b/hw/cxl/cxl-device-utils.c
index c515d45d20..b38e9b4c17 100644
--- a/hw/cxl/cxl-device-utils.c
+++ b/hw/cxl/cxl-device-utils.c
@@ -102,6 +102,9 @@ static void mailbox_reg_write(void 

Re: [PATCH v3 00/15] target/mips/mips-defs: Simplify ISA definitions

[Philippe Mathieu-Daudé]

On 1/4/21 11:11 PM, Philippe Mathieu-Daudé wrote:
> Philippe Mathieu-Daud=C3=A9 (15):
>   target/mips/mips-defs: Remove USE_HOST_FLOAT_REGS comment
>   target/mips/mips-defs: Reorder CPU_MIPS5 definition
>   target/mips/mips-defs: Rename CPU_MIPSxx Release 1 as CPU_MIPSxxR1
>   target/mips/mips-defs: Introduce CPU_MIPS64 and cpu_type_is_64bit()
>   hw/mips/boston: Check 64-bit support with cpu_type_is_64bit()
>   target/mips/mips-defs: Use ISA_MIPS32 definition to check Release 1
>   target/mips/mips-defs: Use ISA_MIPS32R2 definition to check Release 2
>   target/mips/mips-defs: Use ISA_MIPS32R3 definition to check Release 3
>   target/mips/mips-defs: Use ISA_MIPS32R5 definition to check Release 5
>   target/mips/mips-defs: Use ISA_MIPS32R6 definition to check Release 6
>   target/mips/mips-defs: Rename ISA_MIPS32 as ISA_MIPS_R1
>   target/mips/mips-defs: Rename ISA_MIPS32R2 as ISA_MIPS_R2
>   target/mips/mips-defs: Rename ISA_MIPS32R3 as ISA_MIPS_R3
>   target/mips/mips-defs: Rename ISA_MIPS32R5 as ISA_MIPS_R5
>   target/mips/mips-defs: Rename ISA_MIPS32R6 as ISA_MIPS_R6
> 
>  target/mips/cpu.h|   5 +
>  target/mips/internal.h   |   8 +-
>  target/mips/mips-defs.h  |  46 +--
>  hw/mips/boston.c |   6 +-
>  linux-user/mips/cpu_loop.c   |   6 +-
>  target/mips/cp0_helper.c |  18 +-
>  target/mips/cp0_timer.c  |   4 +-
>  target/mips/cpu.c|   6 +-
>  target/mips/fpu_helper.c |   4 +-
>  target/mips/helper.c |  12 +-
>  target/mips/translate.c  | 620 +++
>  target/mips/translate_init.c.inc |  14 +-
>  12 files changed, 370 insertions(+), 379 deletions(-)

Series queued to mips-next.

Re: [PATCH v3 04/15] target/mips/mips-defs: Introduce CPU_MIPS64 and cpu_type_is_64bit()

[Philippe Mathieu-Daudé]

On 1/5/21 5:01 PM, Richard Henderson wrote:
> On 1/5/21 12:05 AM, Philippe Mathieu-Daudé wrote:
>> I'm not sure it is worth the effort, as I plan to check each ISA /
>> ASE bit from the CP0_ConfigX bits (similarly target/arm/ does), so
>> these definitions should disappear eventually.
> 
> Excellent.
> 
>> Might I keep your R-b tag for this patch (eventually improving the
>> commit description with some of the info added in this mail) and
>> keep going?
> 
> Yes.

Thanks :)

Re: [PATCH v2 0/8] MIPS Bootloader helper

[Philippe Mathieu-Daudé]

On 1/3/21 9:42 PM, Philippe Mathieu-Daudé wrote:
> On 12/15/20 7:41 AM, Jiaxun Yang wrote:
>> v2:
>> A big reconstruction. rewrite helpers with CPU feature and sepreate
>> changesets.
>>
>> Jiaxun Yang (8):
>>   hw/mips: Make bootloader addresses unsgined
>>   hw/mips/malta: Use address translation helper to calculate
>> bootloader_run_addr
>>   hw/mips: Use address translation helper to handle ENVP_ADDR
>>   hw/mips: Add a bootloader helper
>>   hw/mips: Use bl_gen_kernel_jump to generate bootloaders
>>   target/mips/addr: Add translation helpers for KSEG1
>>   hw/mips/malta: Use bootloader helper to set BAR resgiters
>>   hw/mips/boston: Use bootloader helper to set GCRs
>>
>>  hw/mips/bootloader.c | 157 
>>  hw/mips/boston.c |  62 +++--
>>  hw/mips/fuloong2e.c  |  48 +++---
>>  hw/mips/malta.c  | 171 ---
>>  hw/mips/meson.build  |   2 +-
>>  include/hw/mips/bootloader.h |  48 ++
>>  target/mips/addr.c   |  10 ++
>>  target/mips/cpu.h|   2 +
>>  8 files changed, 306 insertions(+), 194 deletions(-)
>>  create mode 100644 hw/mips/bootloader.c
>>  create mode 100644 include/hw/mips/bootloader.h
> 
> Patches 1-3 queued to mips-next.

Patch 6 queued to mips-next.

Re: [PATCH v2 5/8] hw/mips: Use bl_gen_kernel_jump to generate bootloaders

[Philippe Mathieu-Daudé]

+Alex

On 12/15/20 7:45 AM, Jiaxun Yang wrote:
> Replace embedded binary with generated code.
> 
> Signed-off-by: Jiaxun Yang 
> ---
>  hw/mips/boston.c| 17 ++---
>  hw/mips/fuloong2e.c | 28 
>  hw/mips/malta.c | 41 ++---
>  3 files changed, 16 insertions(+), 70 deletions(-)
> 
> diff --git a/hw/mips/boston.c b/hw/mips/boston.c
> index c3b94c68e1..b62c7d 100644
> --- a/hw/mips/boston.c
> +++ b/hw/mips/boston.c
> @@ -27,6 +27,7 @@
>  #include "hw/ide/ahci.h"
>  #include "hw/loader.h"
>  #include "hw/loader-fit.h"
> +#include "hw/mips/bootloader.h"
>  #include "hw/mips/cps.h"
>  #include "hw/pci-host/xilinx-pcie.h"
>  #include "hw/qdev-clock.h"
> @@ -324,21 +325,7 @@ static void gen_firmware(uint32_t *p, hwaddr 
> kernel_entry, hwaddr fdt_addr,
>   * a2/$6 = 0
>   * a3/$7 = 0
>   */
> -stl_p(p++, 0x2404fffe); /* li   $4, -2 */
> -/* lui  $5, hi(fdt_addr) */
> -stl_p(p++, 0x3c05 | ((fdt_addr >> 16) & 0x));
> -if (fdt_addr & 0x) {/* ori  $5, lo(fdt_addr) */
> -stl_p(p++, 0x34a5 | (fdt_addr & 0x));
> -}
> -stl_p(p++, 0x3406); /* li   $6, 0 */
> -stl_p(p++, 0x3407); /* li   $7, 0 */
> -
> -/* Load kernel entry address & jump to it */
> -/* lui  $25, 
> hi(kernel_entry) */
> -stl_p(p++, 0x3c19 | ((kernel_entry >> 16) & 0x));
> -/* ori  $25, 
> lo(kernel_entry) */
> -stl_p(p++, 0x3739 | (kernel_entry & 0x));
> -stl_p(p++, 0x0329); /* jr   $25 */

Eh, no delay slot NOP :)

> +bl_gen_jump_kernel(, 0, (int32_t)-2, fdt_addr, 0, 0, kernel_entry);
>  }
>  
...

> diff --git a/hw/mips/malta.c b/hw/mips/malta.c
> index 9afc0b427b..ffd67b8293 100644
> --- a/hw/mips/malta.c
> +++ b/hw/mips/malta.c
> @@ -37,6 +37,7 @@
>  #include "hw/i2c/smbus_eeprom.h"
>  #include "hw/block/flash.h"
>  #include "hw/mips/mips.h"
> +#include "hw/mips/bootloader.h"
>  #include "hw/mips/cpudevs.h"
>  #include "hw/pci/pci.h"
>  #include "sysemu/sysemu.h"
> @@ -844,6 +845,7 @@ static void write_bootloader_nanomips(uint8_t *base, 
> uint64_t run_addr,
>  static void write_bootloader(uint8_t *base, uint64_t run_addr,
>   uint64_t kernel_entry)
>  {
> +target_ulong a0;
>  uint32_t *p;
>  
>  /* Small bootloader */
> @@ -872,30 +874,6 @@ static void write_bootloader(uint8_t *base, uint64_t 
> run_addr,
>  /* Second part of the bootloader */
>  p = (uint32_t *) (base + 0x580);
>  
> -if (semihosting_get_argc()) {
> -/* Preserve a0 content as arguments have been passed */
> -stl_p(p++, 0x);  /* nop */
> -} else {
> -stl_p(p++, 0x24040002);  /* addiu a0, zero, 2 */
> -}
> -
> -/* lui sp, high(ENVP_VADDR) */
> -stl_p(p++, 0x3c1d | (((ENVP_VADDR - 64) >> 16) & 0x));
> -/* ori sp, sp, low(ENVP_VADDR) */
> -stl_p(p++, 0x37bd | ((ENVP_VADDR - 64) & 0x));
> -/* lui a1, high(ENVP_VADDR) */
> -stl_p(p++, 0x3c05 | ((ENVP_VADDR >> 16) & 0x));
> -/* ori a1, a1, low(ENVP_VADDR) */
> -stl_p(p++, 0x34a5 | (ENVP_VADDR & 0x));
> -/* lui a2, high(ENVP_VADDR + 8) */
> -stl_p(p++, 0x3c06 | (((ENVP_VADDR + 8) >> 16) & 0x));
> -/* ori a2, a2, low(ENVP_VADDR + 8) */
> -stl_p(p++, 0x34c6 | ((ENVP_VADDR + 8) & 0x));
> -/* lui a3, high(ram_low_size) */
> -stl_p(p++, 0x3c07 | (loaderparams.ram_low_size >> 16));
> -/* ori a3, a3, low(ram_low_size) */
> -stl_p(p++, 0x34e7 | (loaderparams.ram_low_size & 0x));
> -
>  /* Load BAR registers as done by YAMON */
>  stl_p(p++, 0x3c09b400);  /* lui t1, 0xb400 */
>  
> @@ -947,13 +925,14 @@ static void write_bootloader(uint8_t *base, uint64_t 
> run_addr,
>  #endif
>  stl_p(p++, 0xad280088);  /* sw t0, 0x0088(t1) */
>  
> -/* Jump to kernel code */
> -stl_p(p++, 0x3c1f |
> -  ((kernel_entry >> 16) & 0x));  /* lui ra, high(kernel_entry) */
> -stl_p(p++, 0x37ff |
> -  (kernel_entry & 0x));  /* ori ra, ra, 
> low(kernel_entry) */
> -stl_p(p++, 0x03e9);  /* jalr ra */
> -stl_p(p++, 0x);  /* nop */
> +if (semihosting_get_argc()) {
> +a0 = 0;

I never used semihosting with Malta, but it seems you are
clearing $a0 content.

> +} else {
> +a0 = 2;
> +}
> +bl_gen_jump_kernel(, ENVP_VADDR - 64, a0, ENVP_VADDR,
> +   ENVP_VADDR + 8, loaderparams.ram_low_size,
> +   kernel_entry);
>  
>  /* YAMON subroutines */
>  p = (uint32_t *) (base + 0x800);
> 

Re: [Linuxarm] Re: [RFC PATCH v2 07/32] hw/cxl/device: Implement basic mailbox (8.2.8.4)

[Jonathan Cameron]

On Wed, 6 Jan 2021 13:21:23 +
Jonathan Cameron  wrote:

> On Tue, 5 Jan 2021 08:52:58 -0800
> Ben Widawsky  wrote:
> 
> > This is the beginning of implementing mailbox support for CXL 2.0
> > devices.
> > 
> > v2: Use register alignment helper (Ben)
> > Minor cleanups (Jonathan)
> > Rename error codes to match spec (Jonathan)
> > Update cap count from 1 to 2 (Jonathan)
> > Add infra to support CEL (Ben)
> > Add more of the actual mailbox handling from later patch (Ben)
> > 
> > Signed-off-by: Ben Widawsky   
> 
> Hi Ben,
> 
> I hacked support in for ARM64 to give this a spin and ran into an
> interesting problem around read sizes.
> 
> The mailbox registers space allows 4 or 8 byte reads, but in the kernel
> driver (I think I have the right version from your github) you do
> the payload drain with
> memcpy_from_io()
> 
> If the size of the payload is not a multiple of 8 bytes, on ARM64 that
> results in byte reads and an exception.  This happens with some of the
> existing calls which happen to have non multiple of 8 payload sizes.
> 
> I hacked below to allow 1 byte reads from that region but that's probably
> not the right fix.  I found a statement in the CXL spec saying maximum read
> size from this register block was 8 bytes but couldn't immediately see a 
> minimum.
> (I haven't looked that hard yet though!)
> 
> Various approaches in kernel could also be used:
> 1) Change the payload drain to have specific handling for the end few bytes.
> 2) Pad the various structures to ensure payloads are always 8 byte multiples
> in length (nasty).

Bit more testing an another little thing below.

J

> 
> > ---
> >  hw/cxl/cxl-device-utils.c   | 122 -
> >  hw/cxl/cxl-mailbox-utils.c  | 173 
> >  hw/cxl/meson.build  |   1 +
> >  include/hw/cxl/cxl.h|   3 +
> >  include/hw/cxl/cxl_device.h |  27 +-
> >  5 files changed, 322 insertions(+), 4 deletions(-)
> >  create mode 100644 hw/cxl/cxl-mailbox-utils.c
> > 
> > diff --git a/hw/cxl/cxl-device-utils.c b/hw/cxl/cxl-device-utils.c
> > index b86e5466bd..642e3c2617 100644
> > --- a/hw/cxl/cxl-device-utils.c
> > +++ b/hw/cxl/cxl-device-utils.c
> > @@ -44,6 +44,108 @@ static uint64_t dev_reg_read(void *opaque, hwaddr 
> > offset, unsigned size)
> >  return ldn_le_p(, size);
> >  }
> >  
> > +static uint64_t mailbox_reg_read(void *opaque, hwaddr offset, unsigned 
> > size)
> > +{
> > +CXLDeviceState *cxl_dstate = opaque;
> > +
> > +if (cxl_device_check_register_alignment(offset, size)) {
> > +qemu_log_mask(LOG_UNIMP, "Unaligned register read\n");
> > +return 0;
> > +}
> > +
> > +return ldn_le_p(cxl_dstate->mbox_reg_state + offset, size);
> > +}
> > +
> > +static void mailbox_mem_writel(uint32_t *reg_state, hwaddr offset,
> > +   uint64_t value)
> > +{
> > +switch (offset) {
> > +case A_CXL_DEV_MAILBOX_CTRL:
> > +/* fallthrough */
> > +case A_CXL_DEV_MAILBOX_CAP:
> > +/* RO register */
> > +break;
> > +default:
> > +qemu_log_mask(LOG_UNIMP,
> > +  "%s Unexpected 32-bit access to 0x%" PRIx64 " 
> > (WI)\n",
> > +  __func__, offset);
> > +break;
> > +}
> > +
> > +stl_le_p((uint8_t *)reg_state + offset, value);
> > +}
> > +
> > +static void mailbox_mem_writeq(uint8_t *reg_state, hwaddr offset,
> > +   uint64_t value)
> > +{
> > +switch (offset) {
> > +case A_CXL_DEV_MAILBOX_CMD:
> > +break;
> > +case A_CXL_DEV_BG_CMD_STS:
> > +/* BG not supported */
> > +/* fallthrough */
> > +case A_CXL_DEV_MAILBOX_STS:
> > +/* Read only register, will get updated by the state machine */
> > +return;
> > +default:
> > +qemu_log_mask(LOG_UNIMP,
> > +  "%s Unexpected 64-bit access to 0x%" PRIx64 " 
> > (WI)\n",
> > +  __func__, offset);

I've been debugging mail box issues and it seems we can hit this path if
a payload is written by the OS.  Result is it never gets written into the memory
and hence isn't available when we try to read it below.

> > +return;
> > +}
> > +
> > +stq_le_p(reg_state + offset, value);
> > +}
> > +
> > +static void mailbox_reg_write(void *opaque, hwaddr offset, uint64_t value,
> > +  unsigned size)
> > +{
> > +CXLDeviceState *cxl_dstate = opaque;
> > +
> > +/*
> > + * Lock is needed to prevent concurrent writes as well as to prevent 
> > writes
> > + * coming in while the firmware is processing. Without background 
> > commands
> > + * or the second mailbox implemented, this serves no purpose since the
> > + * memory access is synchronized at a higher level (per memory region).
> > + */
> > +RCU_READ_LOCK_GUARD();
> > +
> > +switch (size) {
> > +case 4:
> > +if (unlikely(offset 

Re: [PATCH v2 8/8] hw/mips/boston: Use bootloader helper to set GCRs

[Philippe Mathieu-Daudé]

On Wed, Jan 6, 2021 at 6:30 PM Philippe Mathieu-Daudé  wrote:
> On Wed, Jan 6, 2021 at 6:28 PM Philippe Mathieu-Daudé  wrote:
> > On 12/15/20 7:46 AM, Jiaxun Yang wrote:
> > > Translate embedded assembly into IO writes which is more
> > > readable.
> > >
> > > Also hardcode cm_base at boot time instead of reading from CP0.
> > >
> > > Signed-off-by: Jiaxun Yang 
> > > ---
> > >  hw/mips/boston.c | 45 -
> > >  1 file changed, 12 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/hw/mips/boston.c b/hw/mips/boston.c
> > > index b62c7d..9f08aa7285 100644
> > > --- a/hw/mips/boston.c
> > > +++ b/hw/mips/boston.c
> > > @@ -281,42 +281,21 @@ static void gen_firmware(uint32_t *p, hwaddr 
> > > kernel_entry, hwaddr fdt_addr,
> > >  const uint32_t gic_base = 0x1612;
> > >  const uint32_t cpc_base = 0x1620;
> > >
> > > -/* Move CM GCRs */
> > >  if (is_64b) {
> > > -stl_p(p++, 0x40287803); /* dmfc0 $8, CMGCRBase */
> > > -stl_p(p++, 0x00084138); /* dsll $8, $8, 4 */
> > > +bl_gen_write_u64(, cm_base,
> > > +cpu_mips_phys_to_kseg1(NULL, GCR_BASE_ADDR + 
> > > GCR_BASE_OFS));
> > > +bl_gen_write_u64(, gic_base | GCR_GIC_BASE_GICEN_MSK,
> > > +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> > > GCR_GIC_BASE_OFS));
> > > +bl_gen_write_u64(, cpc_base | GCR_CPC_BASE_CPCEN_MSK,
> > > +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> > > GCR_CPC_BASE_OFS));
> > >  } else {
> > > -stl_p(p++, 0x40087803); /* mfc0 $8, CMGCRBase */
> > > -stl_p(p++, 0x00084100); /* sll  $8, $8, 4 */
> > > +bl_gen_write_u32(, cm_base,
> > > +cpu_mips_phys_to_kseg1(NULL, GCR_BASE_ADDR + 
> > > GCR_BASE_OFS));
> > > +bl_gen_write_u32(, gic_base | GCR_GIC_BASE_GICEN_MSK,
> > > +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> > > GCR_GIC_BASE_OFS));
> > > +bl_gen_write_u32(, cpc_base | GCR_CPC_BASE_CPCEN_MSK,
> > > +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> > > GCR_CPC_BASE_OFS));
> > >  }
> >
> > What about simplifying adding bl_gen_write_target_ulong() or
> > bl_gen_write_ulong()?
>
> bl_gen_store_ulong() similarly to bl_gen_load_ulong()?

bl_gen_write_ulong(). Anyway, can be done later, so:
Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v2 8/8] hw/mips/boston: Use bootloader helper to set GCRs

[Philippe Mathieu-Daudé]

On Wed, Jan 6, 2021 at 6:28 PM Philippe Mathieu-Daudé  wrote:
>
> On 12/15/20 7:46 AM, Jiaxun Yang wrote:
> > Translate embedded assembly into IO writes which is more
> > readable.
> >
> > Also hardcode cm_base at boot time instead of reading from CP0.
> >
> > Signed-off-by: Jiaxun Yang 
> > ---
> >  hw/mips/boston.c | 45 -
> >  1 file changed, 12 insertions(+), 33 deletions(-)
> >
> > diff --git a/hw/mips/boston.c b/hw/mips/boston.c
> > index b62c7d..9f08aa7285 100644
> > --- a/hw/mips/boston.c
> > +++ b/hw/mips/boston.c
> > @@ -281,42 +281,21 @@ static void gen_firmware(uint32_t *p, hwaddr 
> > kernel_entry, hwaddr fdt_addr,
> >  const uint32_t gic_base = 0x1612;
> >  const uint32_t cpc_base = 0x1620;
> >
> > -/* Move CM GCRs */
> >  if (is_64b) {
> > -stl_p(p++, 0x40287803); /* dmfc0 $8, CMGCRBase */
> > -stl_p(p++, 0x00084138); /* dsll $8, $8, 4 */
> > +bl_gen_write_u64(, cm_base,
> > +cpu_mips_phys_to_kseg1(NULL, GCR_BASE_ADDR + 
> > GCR_BASE_OFS));
> > +bl_gen_write_u64(, gic_base | GCR_GIC_BASE_GICEN_MSK,
> > +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> > GCR_GIC_BASE_OFS));
> > +bl_gen_write_u64(, cpc_base | GCR_CPC_BASE_CPCEN_MSK,
> > +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> > GCR_CPC_BASE_OFS));
> >  } else {
> > -stl_p(p++, 0x40087803); /* mfc0 $8, CMGCRBase */
> > -stl_p(p++, 0x00084100); /* sll  $8, $8, 4 */
> > +bl_gen_write_u32(, cm_base,
> > +cpu_mips_phys_to_kseg1(NULL, GCR_BASE_ADDR + 
> > GCR_BASE_OFS));
> > +bl_gen_write_u32(, gic_base | GCR_GIC_BASE_GICEN_MSK,
> > +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> > GCR_GIC_BASE_OFS));
> > +bl_gen_write_u32(, cpc_base | GCR_CPC_BASE_CPCEN_MSK,
> > +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> > GCR_CPC_BASE_OFS));
> >  }
>
> What about simplifying adding bl_gen_write_target_ulong() or
> bl_gen_write_ulong()?

bl_gen_store_ulong() similarly to bl_gen_load_ulong()?

Re: [PATCH v2 8/8] hw/mips/boston: Use bootloader helper to set GCRs

[Philippe Mathieu-Daudé]

On 12/15/20 7:46 AM, Jiaxun Yang wrote:
> Translate embedded assembly into IO writes which is more
> readable.
> 
> Also hardcode cm_base at boot time instead of reading from CP0.
> 
> Signed-off-by: Jiaxun Yang 
> ---
>  hw/mips/boston.c | 45 -
>  1 file changed, 12 insertions(+), 33 deletions(-)
> 
> diff --git a/hw/mips/boston.c b/hw/mips/boston.c
> index b62c7d..9f08aa7285 100644
> --- a/hw/mips/boston.c
> +++ b/hw/mips/boston.c
> @@ -281,42 +281,21 @@ static void gen_firmware(uint32_t *p, hwaddr 
> kernel_entry, hwaddr fdt_addr,
>  const uint32_t gic_base = 0x1612;
>  const uint32_t cpc_base = 0x1620;
>  
> -/* Move CM GCRs */
>  if (is_64b) {
> -stl_p(p++, 0x40287803); /* dmfc0 $8, CMGCRBase */
> -stl_p(p++, 0x00084138); /* dsll $8, $8, 4 */
> +bl_gen_write_u64(, cm_base,
> +cpu_mips_phys_to_kseg1(NULL, GCR_BASE_ADDR + 
> GCR_BASE_OFS));
> +bl_gen_write_u64(, gic_base | GCR_GIC_BASE_GICEN_MSK,
> +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> GCR_GIC_BASE_OFS));
> +bl_gen_write_u64(, cpc_base | GCR_CPC_BASE_CPCEN_MSK,
> +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> GCR_CPC_BASE_OFS));
>  } else {
> -stl_p(p++, 0x40087803); /* mfc0 $8, CMGCRBase */
> -stl_p(p++, 0x00084100); /* sll  $8, $8, 4 */
> +bl_gen_write_u32(, cm_base,
> +cpu_mips_phys_to_kseg1(NULL, GCR_BASE_ADDR + 
> GCR_BASE_OFS));
> +bl_gen_write_u32(, gic_base | GCR_GIC_BASE_GICEN_MSK,
> +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> GCR_GIC_BASE_OFS));
> +bl_gen_write_u32(, cpc_base | GCR_CPC_BASE_CPCEN_MSK,
> +cpu_mips_phys_to_kseg1(NULL, cm_base + 
> GCR_CPC_BASE_OFS));
>  }

What about simplifying adding bl_gen_write_target_ulong() or
bl_gen_write_ulong()?

Re: [PULL v3 00/52] Misc patches for 2020-12-21

[Peter Maydell]

On Wed, 6 Jan 2021 at 14:57, Paolo Bonzini  wrote:
>
> The following changes since commit 41192db338588051f21501abc13743e62b0a5605:
>
>   Merge remote-tracking branch 
> 'remotes/ehabkost-gl/tags/machine-next-pull-request' into staging (2021-01-01 
> 22:57:15 +)
>
> are available in the Git repository at:
>
>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to c8b2b7fed9850356f5d88bc7da2f1cefe57289bf:
>
>   win32: drop fd registration to the main-loop on setting non-block 
> (2021-01-06 10:21:20 +0100)
>
> 
> From Alex's pull request:
> * improve cross-build KVM coverage
> * new --without-default-features configure flag
> * add __repr__ for ConsoleSocket for debugging
> * build tcg tests with -Werror
> * test 32 bit builds with fedora
> * remove last traces of debian9
> * hotfix for centos8 powertools repo
>
> * Move lots of feature detection code to meson (Alex, myself)
> * CFI and LTO support (Daniele)
> * test-char dangling pointer (Eduardo)
> * Build system and win32 fixes (Marc-André)
> * Initialization fixes (myself)
> * TCG include cleanup (Richard, myself)
> * x86 'int N' fix (Peter)
>


Applied, thanks.

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

-- PMM

Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types

[Eduardo Habkost]

On Wed, Jan 06, 2021 at 05:45:42PM +0100, Igor Mammedov wrote:
> On Wed, 06 Jan 2021 14:38:56 +0100
> Vitaly Kuznetsov  wrote:
> 
> > Igor Mammedov  writes:
> > 
> > > On Tue, 05 Jan 2021 17:31:43 +0100
> > > Vitaly Kuznetsov  wrote:
> > >  
> > >> Igor Mammedov  writes:
> > >>   
> > >> > On Tue, 05 Jan 2021 12:50:05 +0100
> > >> >
> > >> > I think there is a misunderstanding, idea was:
> > >> >
> > >> > cpu_initfn() {
> > >> > //current set
> > >> > cpu->default_hyperv_cpu_features = ACD
> > >> > }
> > >> >
> > >> > compat_props_5.1 {
> > >> >cpu.default_hyperv_cpu_features = AB
> > >> > }
> > >> >
> > >> > compat_props_5.2 {
> > >> >cpu.default_hyperv_cpu_features = ABC
> > >> > }
> > >> >
> > >> 
> > >> ...
> > >>   
> > >> > I was talking about CPU features/properties only, it doesn't apply to 
> > >> > other devices.
> > >> > It makes sense for machine to have a knob to create onboard hyperv 
> > >> > specific
> > >> > devices if there is any (do we have any?).
> > >> >
> > >> > If there aren't any currently, I wouldn't bother with machine knob
> > >> > and just use -cpu foo,hv_default=on or -device cpu,hv_default=on
> > >> > like any other cpu feature.
> > >> >
> > >> 
> > >> We don't currently have any devices which are not 'CPU features' (in
> > >> QEMU terminology), however, we already have Vmbus and I can easily
> > >> imagine us implementing e.g. hartbeat/kvp/vss/... devices on top. We
> > >> *may* want to enable these 'automatically' and that's what make
> > >> '-machine' option preferable. It is, however, not a *must* right now and
> > >> we can indeed wait until these devices appear and be happy with
> > >> 'hv_default' -cpu option for now. We will, however, need to teach upper
> > >> layers about the change when/if it happens.  
> > >
> > > which makes me think we are trying to bite something that we shouldn't.
> > > Do we really need this patch (QEMU knob) to magically enable subset of
> > > features and/or devices for a specific OS flavor?
> > >
> > > It's job of upper layers to abstract low level QEMU details in to coarse
> > > grained knobs (libvirt/virt-install/virt-manager/...).
> > > For example virt-install may know that it installing a specific Windows
> > > version, and can build a tailored for that OS configuration including
> > > needed hyperv CPU features and hyperv specific devices.
> > > (if I'm not mistaken libosinfo is used to get metadata for preferred
> > > configuration, so perhaps this should become a patch for that library
> > > and its direct users).
> > >
> > > What we actually lack is a documentation for preferred configuration
> > > in docs/hyperv.txt, currently it just enumerates possible features.
> > > We can just document a recommended 'best practices' there without
> > > putting it in QEMU code and let upper layers to do their job in
> > > the stack.  
> > 
> > The problem we're facing here is that when a new enlightenment is
> > implemented it takes forever to propagate to the whole stack. We don't
> It's true not only for Hyper-V, I guess it's price to pay for modular 
> solution.

Yes, this discussion applies to other features as well.

> 
> > have any different recommendations for different Windows versions,
> > neither does genuine Hyper-V. The 'fine grained' mechanis we have just
> > contributes to the creation of various Frankenstein configurations
> > (which look nothing like real Hyper-V), people just google for 'Windows
> > KVM slow', add something to their scripts and this keeps propagating.
> That's why I mentioned lack of documentation.
> If someone manually configures QEMU, one should understand what they do
> enable and why or enlist help of virt-install and likes.

Why?

QEMU's lack of usability is an unfortunate accident, not a
desirable goal.

> 
> > Every time I see a configuration with only a few 'hv_*' options I ask
> > 'why don't you enable the rest?' and I'm yet to receive an answer
> > different from 'hm, I don't know, I copied it from somewhere and it
> > worked'.
> 
> If individual features are are composed by virt-install or other tools
> based on libosinfo data, then we don't have to maintain versioning
> of new default_set_features per machine type, which will only become
> worse if we include hv specific devices into it.

Versioning is extra work for us QEMU developers, but it has a
purpose.  It saves everybody else's valuable time.


> 
> Also with libosinfo approach, old machine types and old QEMU versions
> can also benefit from it without need to change whole stack.

Except that you need to update the whole stack (QEMU + libvirt +
libosinfo + the glue code between libosinfo and libvirt) every
time a new feature is available.

This is unnecessary overhead, and this is not working.


> And no versioning is necessary since chosen config set is stored in
> domain XML at the moment VM is created.

I don't even think that is a good thing.

I would agree completely with you if the people maintaining the
upper 

Re: [PATCH v3] acpi: Permit OEM ID and OEM table ID fields to be changed

[Igor Mammedov]

On Thu, 31 Dec 2020 00:13:01 +0200
Marian Posteuca  wrote:

> Qemu's ACPI table generation sets the fields OEM ID and OEM table ID
> to "BOCHS " and "BXPC" where "" is replaced by the ACPI
> table name.
> 
> Some games like Red Dead Redemption 2 seem to check the ACPI OEM ID
> and OEM table ID for the strings "BOCHS" and "BXPC" and if they are
> found, the game crashes(this may be an intentional detection
> mechanism to prevent playing the game in a virtualized environment).
> 
> This patch allows you to override these default values.
> 
> The feature can be used in this manner:
> qemu -machine oem-id=ABCDEF,oem-table-id=GHIJKLMN
> 
> The oem-id string can be up to 6 bytes in size, and the
> oem-table-id string can be up to 8 bytes in size. If the string are
> smaller than their respective sizes they will be padded with space.
> If either of these parameters is not set, the current default values
> will be used for the one missing.
> 
> Note that the the OEM Table ID field will not be extended with the
> name of the table, but will use either the default name or the user
> provided one.
> 
> This does not affect the -acpitable option (for user-defined ACPI
> tables), which has precedence over -machine option.

overall looks good.
Please add a test case for it, see
tests/qtest/bios-tables-test.c for description how to do it
an/or at
  "[PATCH v3 08/12] tests/acpi: allow updates for expected data files"
and follow up patches on the list.

Other than that, only my nitpicking below remains.

> 
> Signed-off-by: Marian Posteuca 

PS:
here under ---
should be changelog if it's not v1

> ---
>  hw/acpi/hmat.h  |  3 +-
>  hw/i386/acpi-common.h   |  3 +-
>  include/hw/acpi/acpi-defs.h |  2 +-
>  include/hw/acpi/aml-build.h |  8 ++--
>  include/hw/acpi/ghes.h  |  3 +-
>  include/hw/acpi/pci.h   |  3 +-
>  include/hw/acpi/vmgenid.h   |  2 +-
>  include/hw/arm/virt.h   |  2 +
>  include/hw/i386/microvm.h   |  4 ++
>  include/hw/i386/pc.h|  5 ++-
>  include/hw/mem/nvdimm.h |  3 +-
>  hw/acpi/aml-build.c | 43 +++
>  hw/acpi/ghes.c  |  5 ++-
>  hw/acpi/hmat.c  |  5 ++-
>  hw/acpi/nvdimm.c| 18 +---
>  hw/acpi/pci.c   |  5 ++-
>  hw/acpi/vmgenid.c   |  4 +-
>  hw/arm/virt-acpi-build.c| 40 +++--
>  hw/arm/virt.c   | 57 
>  hw/i386/acpi-build.c| 86 +
>  hw/i386/acpi-common.c   |  5 ++-
>  hw/i386/acpi-microvm.c  | 13 +++---
>  hw/i386/microvm.c   | 60 ++
>  hw/i386/pc.c| 58 +
>  24 files changed, 344 insertions(+), 93 deletions(-)
> 
> diff --git a/hw/acpi/hmat.h b/hw/acpi/hmat.h
> index e9031cac01..b57f0e7e80 100644
> --- a/hw/acpi/hmat.h
> +++ b/hw/acpi/hmat.h
> @@ -37,6 +37,7 @@
>   */
>  #define HMAT_PROXIMITY_INITIATOR_VALID  0x1
>  
> -void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState 
> *numa_state);
> +void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState 
> *numa_state,
> +const char *oem_id, const char *oem_table_id);
>  
>  #endif
> diff --git a/hw/i386/acpi-common.h b/hw/i386/acpi-common.h
> index c30e461f18..b12cd73ea5 100644
> --- a/hw/i386/acpi-common.h
> +++ b/hw/i386/acpi-common.h
> @@ -9,6 +9,7 @@
>  #define ACPI_BUILD_IOAPIC_ID 0x0
>  
>  void acpi_build_madt(GArray *table_data, BIOSLinker *linker,
> - X86MachineState *x86ms, AcpiDeviceIf *adev);
> + X86MachineState *x86ms, AcpiDeviceIf *adev,
> + const char *oem_id, const char *oem_table_id);
>  
>  #endif
> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
> index 38a42f409a..cf9f44299c 100644
> --- a/include/hw/acpi/acpi-defs.h
> +++ b/include/hw/acpi/acpi-defs.h
> @@ -41,7 +41,7 @@ enum {
>  };
>  
>  typedef struct AcpiRsdpData {
> -uint8_t oem_id[6] QEMU_NONSTRING; /* OEM identification */
> +char *oem_id; /* OEM identification */
>  uint8_t revision; /* Must be 0 for 1.0, 2 for 2.0 */
>  
>  unsigned *rsdt_tbl_offset;
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index e727bea1bc..e22983bba1 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -8,7 +8,7 @@
>  #define ACPI_BUILD_TABLE_MAX_SIZE 0x20
>  
>  #define ACPI_BUILD_APPNAME6 "BOCHS "
> -#define ACPI_BUILD_APPNAME4 "BXPC"
> +#define ACPI_BUILD_APPNAME8 "BXPC"
>  
>  #define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
>  #define ACPI_BUILD_RSDP_FILE "etc/acpi/rsdp"
> @@ -457,10 +457,12 @@ Aml *build_crs(PCIHostState *host, CrsRangeSet 
> *range_set);
>  void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
> uint64_t len, int node, MemoryAffinityFlags flags);
>  
> -void build_slit(GArray *table_data, 

Re: [PATCH v2 7/8] hw/mips/malta: Use bootloader helper to set BAR resgiters

[Philippe Mathieu-Daudé]

On 12/15/20 7:45 AM, Jiaxun Yang wrote:
> Translate embedded assembly into IO writes which is more
> readable.
> 
> Signed-off-by: Jiaxun Yang 
> ---
>  hw/mips/malta.c | 68 ++---
>  1 file changed, 19 insertions(+), 49 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v2 2/2] tests: Collapse echoed JSON input to a single line

[David Edmondson]

On Wednesday, 2021-01-06 at 10:49:06 +01, Max Reitz wrote:

> On 21.12.20 14:49, David Edmondson wrote:
>> When sending JSON to running qemu, qemu-io, etc. instances, flatten
>> the echoed input to a single line to ensure that comparisons with the
>> expected input (which is always a single line) are successful.
>> Signed-off-by: David Edmondson 
>> ---
>>   tests/qemu-iotests/common.filter | 6 ++
>>   tests/qemu-iotests/common.qemu   | 2 +-
>>   2 files changed, 7 insertions(+), 1 deletion(-)
>
> I think this is superseded now by commit 0e72078128229bf9efb54.

Yes, agreed.

dme.
-- 
Here I am, a rabbit-hearted girl.

Re: [RFC PATCH v2 05/32] hw/cxl/device: Implement the CAP array (8.2.8.1-2)

[Ben Widawsky]

On 21-01-06 17:06:41, Jonathan Cameron wrote:
> On Wed, 6 Jan 2021 08:49:48 -0800
> Ben Widawsky  wrote:
> 
> > On 21-01-06 13:28:05, Jonathan Cameron wrote:
> > > On Tue, 5 Jan 2021 08:52:56 -0800
> > > Ben Widawsky  wrote:
> > >   
> > > > This implements all device MMIO up to the first capability .That
> > > > includes the CXL Device Capabilities Array Register, as well as all of
> > > > the CXL Device Capability Header Registers. The latter are filled in as
> > > > they are implemented in the following patches.
> > > > 
> > > > v2: Break out register alignment checks (Jonathan)
> > > > 
> > > > Signed-off-by: Ben Widawsky   
> > > Hi Ben,
> > > 
> > > One buglet / inconsistency inline that I spotted whilst chasing that issue
> > > with size of reads.
> > > 
> > > Will get to a full review after messing around ('testing') this a bit 
> > > more ;)
> > > 
> > > Jonathan
> > >   
> > > > ---
> > > >  hw/cxl/cxl-device-utils.c | 72 +++
> > > >  hw/cxl/meson.build|  1 +
> > > >  2 files changed, 73 insertions(+)
> > > >  create mode 100644 hw/cxl/cxl-device-utils.c
> > > > 
> > > > diff --git a/hw/cxl/cxl-device-utils.c b/hw/cxl/cxl-device-utils.c
> > > > new file mode 100644
> > > > index 00..d1b1371e66
> > > > --- /dev/null
> > > > +++ b/hw/cxl/cxl-device-utils.c
> > > > @@ -0,0 +1,72 @@
> > > > +/*
> > > > + * CXL Utility library for devices
> > > > + *
> > > > + * Copyright(C) 2020 Intel Corporation.
> > > > + *
> > > > + * This work is licensed under the terms of the GNU GPL, version 2. 
> > > > See the
> > > > + * COPYING file in the top-level directory.
> > > > + */
> > > > +
> > > > +#include "qemu/osdep.h"
> > > > +#include "qemu/log.h"
> > > > +#include "hw/cxl/cxl.h"
> > > > +
> > > > +static int cxl_device_check_register_alignment(hwaddr offset, unsigned 
> > > > size)
> > > > +{
> > > > +if (unlikely(offset & (size - 1))) {
> > > > +return 1;
> > > > +}
> > > > +
> > > > +return 0;
> > > > +}
> > > > +
> > > > +static uint64_t caps_reg_read(void *opaque, hwaddr offset, unsigned 
> > > > size)
> > > > +{
> > > > +CXLDeviceState *cxl_dstate = opaque;
> > > > +
> > > > +if (cxl_device_check_register_alignment(offset, size)) {
> > > > +qemu_log_mask(LOG_UNIMP, "Unaligned register read\n");
> > > > +return 0;
> > > > +}
> > > > +
> > > > +return ldn_le_p(cxl_dstate->caps_reg_state + offset, size);
> > > > +}
> > > > +
> > > > +static const MemoryRegionOps caps_ops = {
> > > > +.read = caps_reg_read,
> > > > +.write = NULL,
> > > > +.endianness = DEVICE_LITTLE_ENDIAN,
> > > > +.valid = {
> > > > +.min_access_size = 4,
> > > > +.max_access_size = 8,
> > > > +},
> > > > +.impl = {
> > > > +.min_access_size = 4,
> > > > +.max_access_size = 8,
> > > > +},
> > > > +};
> > > > +
> > > > +void cxl_device_register_block_init(Object *obj, CXLDeviceState 
> > > > *cxl_dstate)
> > > > +{
> > > > +/* This will be a BAR, so needs to be rounded up to pow2 for PCI 
> > > > spec */
> > > > +memory_region_init(
> > > > +_dstate->device_registers, obj, "device-registers",
> > > > +pow2ceil(CXL_MAILBOX_REGISTERS_LENGTH + 
> > > > CXL_MAILBOX_REGISTERS_OFFSET));  
> > > 
> > > I can see why you jumped directly to sizing this for the whole region, 
> > > but the snag
> > > is that means I think you missed the fact that patch 8 adds a region 
> > > after the end
> > > of the mailbox.   Doesn't result in an actual bug because the ceil above 
> > > takes
> > > you way past the space needed though (the memory device region is only 8 
> > > bytes long).
> > > 
> > >   
> > 
> > Maybe I misunderstand, but this is the intended behavior.
> > cxl_dstate->device_registers is the MemoryRegion container for all the
> > subregions that are the actual device MMIO.
> > 
> >  +--+
> >   ^  |  |
> >   |  |  unused  |
> >   |  
> >   |  |   memdev regs|
> >   |  
> >   |  |  |
> >   |  | +--+ |
> >  cxl_dstate-> |  | |  | |
> >  device_registers |  | |  | |
> >   |  | |payload   | |
> >   |  | |(2k currently)| |
> >   |  | |  | |
> >   |  | |  | |
> >   |  | +--+ |
> >   |  |   mailbox regs   |
> >   |  
> >   |  |device regs   |
> >   v  
> >  | caps regs|
> >  BAR --> +--+
> > 
> > 
> > Perhaps I should add this as a comment in the code?
> 
> I agree with intent but above it is setting limit to the top of

Re: [PULL v2 00/53] Misc patches for 2020-12-21

[Paolo Bonzini]

I have already sent the v3, so you may want to wait a day or two. The good
thing of conversion patches is that if they break something you can just
drop them. :)

Paolo

Il mer 6 gen 2021, 17:56 Alex Bennée  ha scritto:

>
> Peter Maydell  writes:
>
> > On Mon, 4 Jan 2021 at 14:44, Paolo Bonzini  wrote:
> >>
> >> The following changes since commit
> 41192db338588051f21501abc13743e62b0a5605:
> >>
> >>   Merge remote-tracking branch
> 'remotes/ehabkost-gl/tags/machine-next-pull-request' into staging
> (2021-01-01 22:57:15 +)
> >>
> >> are available in the Git repository at:
> >>
> >>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
> >>
> >> for you to fetch changes up to bac87e979fcca9f884e1c9190132c51d99a86984:
> >>
> >>   win32: drop fd registration to the main-loop on setting non-block
> (2021-01-02 21:03:38 +0100)
> >>
> >> 
> >> From Alex's pull request:
> >> * improve cross-build KVM coverage
> >> * new --without-default-features configure flag
> >> * add __repr__ for ConsoleSocket for debugging
> >> * build tcg tests with -Werror
> >> * test 32 bit builds with fedora
> >> * remove last traces of debian9
> >> * hotfix for centos8 powertools repo
>
> Given this might take awhile to get in and the fact I've got more fixes
> for regressions since Christmas I might as well include these in a only
> testing PR. I'm giving it a final run on the CI systems now before I
> send the email, tag for reference:
>
> : To github.com:stsquad/qemu.git
> :  * [new tag]   pull-testing-060121-3 -> pull-testing-060121-3
> : To gitlab.com:stsquad/qemu.git
> :  * [new tag]   pull-testing-060121-3 -> pull-testing-060121-3
> : pushed pull-testing-060121-3
>
> --
> Alex Bennée
>
>

Re: [RFC PATCH v2 05/32] hw/cxl/device: Implement the CAP array (8.2.8.1-2)

[Jonathan Cameron]

On Wed, 6 Jan 2021 08:49:48 -0800
Ben Widawsky  wrote:

> On 21-01-06 13:28:05, Jonathan Cameron wrote:
> > On Tue, 5 Jan 2021 08:52:56 -0800
> > Ben Widawsky  wrote:
> >   
> > > This implements all device MMIO up to the first capability .That
> > > includes the CXL Device Capabilities Array Register, as well as all of
> > > the CXL Device Capability Header Registers. The latter are filled in as
> > > they are implemented in the following patches.
> > > 
> > > v2: Break out register alignment checks (Jonathan)
> > > 
> > > Signed-off-by: Ben Widawsky   
> > Hi Ben,
> > 
> > One buglet / inconsistency inline that I spotted whilst chasing that issue
> > with size of reads.
> > 
> > Will get to a full review after messing around ('testing') this a bit more 
> > ;)
> > 
> > Jonathan
> >   
> > > ---
> > >  hw/cxl/cxl-device-utils.c | 72 +++
> > >  hw/cxl/meson.build|  1 +
> > >  2 files changed, 73 insertions(+)
> > >  create mode 100644 hw/cxl/cxl-device-utils.c
> > > 
> > > diff --git a/hw/cxl/cxl-device-utils.c b/hw/cxl/cxl-device-utils.c
> > > new file mode 100644
> > > index 00..d1b1371e66
> > > --- /dev/null
> > > +++ b/hw/cxl/cxl-device-utils.c
> > > @@ -0,0 +1,72 @@
> > > +/*
> > > + * CXL Utility library for devices
> > > + *
> > > + * Copyright(C) 2020 Intel Corporation.
> > > + *
> > > + * This work is licensed under the terms of the GNU GPL, version 2. See 
> > > the
> > > + * COPYING file in the top-level directory.
> > > + */
> > > +
> > > +#include "qemu/osdep.h"
> > > +#include "qemu/log.h"
> > > +#include "hw/cxl/cxl.h"
> > > +
> > > +static int cxl_device_check_register_alignment(hwaddr offset, unsigned 
> > > size)
> > > +{
> > > +if (unlikely(offset & (size - 1))) {
> > > +return 1;
> > > +}
> > > +
> > > +return 0;
> > > +}
> > > +
> > > +static uint64_t caps_reg_read(void *opaque, hwaddr offset, unsigned size)
> > > +{
> > > +CXLDeviceState *cxl_dstate = opaque;
> > > +
> > > +if (cxl_device_check_register_alignment(offset, size)) {
> > > +qemu_log_mask(LOG_UNIMP, "Unaligned register read\n");
> > > +return 0;
> > > +}
> > > +
> > > +return ldn_le_p(cxl_dstate->caps_reg_state + offset, size);
> > > +}
> > > +
> > > +static const MemoryRegionOps caps_ops = {
> > > +.read = caps_reg_read,
> > > +.write = NULL,
> > > +.endianness = DEVICE_LITTLE_ENDIAN,
> > > +.valid = {
> > > +.min_access_size = 4,
> > > +.max_access_size = 8,
> > > +},
> > > +.impl = {
> > > +.min_access_size = 4,
> > > +.max_access_size = 8,
> > > +},
> > > +};
> > > +
> > > +void cxl_device_register_block_init(Object *obj, CXLDeviceState 
> > > *cxl_dstate)
> > > +{
> > > +/* This will be a BAR, so needs to be rounded up to pow2 for PCI 
> > > spec */
> > > +memory_region_init(
> > > +_dstate->device_registers, obj, "device-registers",
> > > +pow2ceil(CXL_MAILBOX_REGISTERS_LENGTH + 
> > > CXL_MAILBOX_REGISTERS_OFFSET));  
> > 
> > I can see why you jumped directly to sizing this for the whole region, but 
> > the snag
> > is that means I think you missed the fact that patch 8 adds a region after 
> > the end
> > of the mailbox.   Doesn't result in an actual bug because the ceil above 
> > takes
> > you way past the space needed though (the memory device region is only 8 
> > bytes long).
> > 
> >   
> 
> Maybe I misunderstand, but this is the intended behavior.
> cxl_dstate->device_registers is the MemoryRegion container for all the
> subregions that are the actual device MMIO.
> 
>  +--+
>   ^  |  |
>   |  |  unused  |
>   |  
>   |  |   memdev regs|
>   |  
>   |  |  |
>   |  | +--+ |
>  cxl_dstate-> |  | |  | |
>  device_registers |  | |  | |
>   |  | |payload   | |
>   |  | |(2k currently)| |
>   |  | |  | |
>   |  | |  | |
>   |  | +--+ |
>   |  |   mailbox regs   |
>   |  
>   |  |device regs   |
>   v  
>  | caps regs|
>  BAR --> +--+
> 
> 
> Perhaps I should add this as a comment in the code?

I agree with intent but above it is setting limit to the top of
the mailbox regs, not the memdev regs which I'd expect to see.

> 
> > > +
> > > +memory_region_init_io(_dstate->caps, obj, _ops, cxl_dstate,
> > > +  "cap-array", CXL_DEVICE_REGISTERS_OFFSET - 0);
> > > +
> > > +memory_region_add_subregion(_dstate->device_registers, 0,
> > > +  

Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types

[Eduardo Habkost]

On Wed, Jan 06, 2021 at 02:38:56PM +0100, Vitaly Kuznetsov wrote:
> Igor Mammedov  writes:
> 
> > On Tue, 05 Jan 2021 17:31:43 +0100
> > Vitaly Kuznetsov  wrote:
> >
> >> Igor Mammedov  writes:
> >> 
> >> > On Tue, 05 Jan 2021 12:50:05 +0100
> >> >
> >> > I think there is a misunderstanding, idea was:
> >> >
> >> > cpu_initfn() {
> >> > //current set
> >> > cpu->default_hyperv_cpu_features = ACD
> >> > }
> >> >
> >> > compat_props_5.1 {
> >> >cpu.default_hyperv_cpu_features = AB
> >> > }
> >> >
> >> > compat_props_5.2 {
> >> >cpu.default_hyperv_cpu_features = ABC
> >> > }
> >> >  
> >> 
> >> ...
> >> 
> >> > I was talking about CPU features/properties only, it doesn't apply to 
> >> > other devices.
> >> > It makes sense for machine to have a knob to create onboard hyperv 
> >> > specific
> >> > devices if there is any (do we have any?).
> >> >
> >> > If there aren't any currently, I wouldn't bother with machine knob
> >> > and just use -cpu foo,hv_default=on or -device cpu,hv_default=on
> >> > like any other cpu feature.
> >> >  
> >> 
> >> We don't currently have any devices which are not 'CPU features' (in
> >> QEMU terminology), however, we already have Vmbus and I can easily
> >> imagine us implementing e.g. hartbeat/kvp/vss/... devices on top. We
> >> *may* want to enable these 'automatically' and that's what make
> >> '-machine' option preferable. It is, however, not a *must* right now and
> >> we can indeed wait until these devices appear and be happy with
> >> 'hv_default' -cpu option for now. We will, however, need to teach upper
> >> layers about the change when/if it happens.
> >
> > which makes me think we are trying to bite something that we shouldn't.
> > Do we really need this patch (QEMU knob) to magically enable subset of
> > features and/or devices for a specific OS flavor?

I think we really want this, yes.  It's not for a specific OS
flavor, it is just a machine feature.

> >
> > It's job of upper layers to abstract low level QEMU details in to coarse
> > grained knobs (libvirt/virt-install/virt-manager/...).
> > For example virt-install may know that it installing a specific Windows
> > version, and can build a tailored for that OS configuration including
> > needed hyperv CPU features and hyperv specific devices.
> > (if I'm not mistaken libosinfo is used to get metadata for preferred
> > configuration, so perhaps this should become a patch for that library
> > and its direct users).

virt-install/libosinfo/etc can be used to enable a feature
automatically, but the coarse grained knob may be provided by
QEMU.

> >
> > What we actually lack is a documentation for preferred configuration
> > in docs/hyperv.txt, currently it just enumerates possible features.
> > We can just document a recommended 'best practices' there without
> > putting it in QEMU code and let upper layers to do their job in
> > the stack.
> 
> The problem we're facing here is that when a new enlightenment is
> implemented it takes forever to propagate to the whole stack. We don't
> have any different recommendations for different Windows versions,
> neither does genuine Hyper-V. The 'fine grained' mechanis we have just
> contributes to the creation of various Frankenstein configurations
> (which look nothing like real Hyper-V), people just google for 'Windows
> KVM slow', add something to their scripts and this keeps propagating.

Exactly.  Requiring new code to be added to all other components
in the stack every time we add a low level feature to KVM or QEMU
is not working.  It's even worse when we require users to
manually update their configurations with low level bits.

> 
> Every time I see a configuration with only a few 'hv_*' options I ask
> 'why don't you enable the rest?' and I'm yet to receive an answer
> different from 'hm, I don't know, I copied it from somewhere and it
> worked'.
> 
> Setting 'hv_*' options individually should be considered debug only.

They can also be useful in production to work around
unexpected issues (not just debugging).

I don't think we should prevent other layers from controlling low
level knobs.  We just shouldn't make the low level knobs
necessary for making the feature work.

-- 
Eduardo

Re: [PATCH] vl: initialize displays _after_ exiting preconfiguration

[BALATON Zoltan]

On Thu, 17 Dec 2020, Paolo Bonzini wrote:

Due to the renumbering of text consoles when graphical consoles are
created, init_displaystate must be called after all QemuConsoles are
created, i.e. after devices are created.

vl.c calls it from qemu_init_displays, while qmp_x_exit_preconfig is
where devices are created.  If qemu_init_displays is called before it,
the VGA graphical console does not come up.


Tested-by: BALATON Zoltan 

This still seems to be missing from master, who should take care of this?

Regards,
BALATON Zoltan


Reported-by: Howard Spoelstra 
Signed-off-by: Paolo Bonzini 
---
softmmu/vl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/softmmu/vl.c b/softmmu/vl.c
index 0ed5c5ba93..7ddf405d76 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -3529,10 +3529,10 @@ void qemu_init(int argc, char **argv, char **envp)
exit(0);
}

-qemu_init_displays();
if (!preconfig_requested) {
qmp_x_exit_preconfig(_fatal);
}
+qemu_init_displays();
accel_setup_post(current_machine);
os_setup_post();
resume_mux_open();

Re: [PATCH v2] Docs/RCU: Correct sample code of qatomic_rcu_set

[Stefan Hajnoczi]

On Wed, Jan 06, 2021 at 03:17:10PM +0800, Keqian Zhu wrote:
> Correct sample code to avoid confusing readers.
> 
> Signed-off-by: Keqian Zhu 
> Cc: qemu-triv...@nongnu.org
> Reviewed-by: Paolo Bonzini 
> Reviewed-by: Peter Xu 
> ---
> 
> v2:
>  - Add Cc and R-b.
> 
> ---
>  docs/devel/rcu.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PATCH v2 1/1] vl.c: do not execute trace_init_backends() before daemonizing

[Stefan Hajnoczi]

On Tue, Jan 05, 2021 at 03:14:37PM -0300, Daniel Henrique Barboza wrote:
> Commit v5.2.0-190-g0546c0609c ("vl: split various early command line
> options to a separate function") moved the trace backend init code to
> the qemu_process_early_options(). Which is now being called before
> os_daemonize() via qemu_maybe_daemonize().
> 
> Turns out that this change of order causes a problem when executing
> QEMU in daemon mode and with CONFIG_TRACE_SIMPLE. The trace thread
> is now being created by the parent, and the parent is left waiting for
> a trace file flush that was registered via st_init(). The result is
> that the parent process never exits.
> 
> To reproduce, fire up a QEMU process with -daemonize and with
> CONFIG_TRACE_SIMPLE enabled. Two QEMU process will be left in the
> host:
> 
> $ sudo ./x86_64-softmmu/qemu-system-x86_64 -S -no-user-config -nodefaults \
>   -nographic -machine none,accel=kvm:tcg -daemonize
> 
> $ ps axf | grep qemu
>  529710 pts/3S+ 0:00  |   \_ grep --color=auto qemu
>  529697 ?Ssl0:00  \_ ./x86_64-softmmu/qemu-system-x86_64 -S 
> -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -daemonize
>  529699 ?Sl 0:00  \_ ./x86_64-softmmu/qemu-system-x86_64 -S 
> -no-user-config -nodefaults -nographic -machine none,accel=kvm:tcg -daemonize
> 
> The parent thread is hang in flush_trace_file:
> 
> $ sudo gdb ./x86_64-softmmu/qemu-system-x86_64 529697
> (..)
> (gdb) bt
>  #0  0x7f9dac6a137d in syscall () at /lib64/libc.so.6
>  #1  0x7f9dacc3c4f3 in g_cond_wait () at /lib64/libglib-2.0.so.0
>  #2  0x555d12f952da in flush_trace_file (wait=true) at 
> ../trace/simple.c:140
>  #3  0x555d12f95b4c in st_flush_trace_buffer () at ../trace/simple.c:383
>  #4  0x7f9dac5e43a7 in __run_exit_handlers () at /lib64/libc.so.6
>  #5  0x7f9dac5e4550 in on_exit () at /lib64/libc.so.6
>  #6  0x555d12d454de in os_daemonize () at ../os-posix.c:255
>  #7  0x555d12d0bd5c in qemu_maybe_daemonize (pid_file=0x0) at 
> ../softmmu/vl.c:2408
>  #8  0x555d12d0e566 in qemu_init (argc=8, argv=0x7fffc594d9b8, 
> envp=0x7fffc594da00) at ../softmmu/vl.c:3459
>  #9  0x555d128edac1 in main (argc=8, argv=0x7fffc594d9b8, 
> envp=0x7fffc594da00) at ../softmmu/main.c:49
> (gdb)
> 
> Aside from the 'zombie' process in the host, this is directly impacting
> Libvirt. Libvirt waits for the parent process to exit to be sure that the
> QMP monitor is available in the daemonized process to fetch QEMU
> capabilities, and as is now Libvirt hangs at daemon start waiting
> for the parent thread to exit.
> 
> The fix is simple: just move the trace backend related code back to
> be executed after daemonizing.
> 
> Fixes: 0546c0609cb5a8d90c1cbac8e0d64b5a048bbb19
> Reviewed-by: Paolo Bonzini 
> Signed-off-by: Daniel Henrique Barboza 
> ---
>  softmmu/vl.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)

Acked-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature

Re: [PULL v2 00/53] Misc patches for 2020-12-21

[Alex Bennée]

Peter Maydell  writes:

> On Mon, 4 Jan 2021 at 14:44, Paolo Bonzini  wrote:
>>
>> The following changes since commit 41192db338588051f21501abc13743e62b0a5605:
>>
>>   Merge remote-tracking branch 
>> 'remotes/ehabkost-gl/tags/machine-next-pull-request' into staging 
>> (2021-01-01 22:57:15 +)
>>
>> are available in the Git repository at:
>>
>>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
>>
>> for you to fetch changes up to bac87e979fcca9f884e1c9190132c51d99a86984:
>>
>>   win32: drop fd registration to the main-loop on setting non-block 
>> (2021-01-02 21:03:38 +0100)
>>
>> 
>> From Alex's pull request:
>> * improve cross-build KVM coverage
>> * new --without-default-features configure flag
>> * add __repr__ for ConsoleSocket for debugging
>> * build tcg tests with -Werror
>> * test 32 bit builds with fedora
>> * remove last traces of debian9
>> * hotfix for centos8 powertools repo

Given this might take awhile to get in and the fact I've got more fixes
for regressions since Christmas I might as well include these in a only
testing PR. I'm giving it a final run on the CI systems now before I
send the email, tag for reference:

: To github.com:stsquad/qemu.git
:  * [new tag]   pull-testing-060121-3 -> pull-testing-060121-3
: To gitlab.com:stsquad/qemu.git
:  * [new tag]   pull-testing-060121-3 -> pull-testing-060121-3
: pushed pull-testing-060121-3

-- 
Alex Bennée

CDOS 386 keyboard handling

[LE LIEGARD, Stephane]

Hello,

Host : centos 7
Guest : Concurrent DOS 386 v3.00 (problem also happen on DOS 3.0)
QEMU : v5.1.0
Virtualbox : v6.1.14
Seabios : seabios-rel-1.13.0

I first started to run some tests to debug the alt-gr behavior, and I ended up 
noticing something strange.
This issue is the same as this one: https://bugs.launchpad.net/qemu/+bug/1574246

So I have an old computer with CDOS installed directly on it (i486-DX2 
processeur), and I have to virtualize it with QEMU. Lets call this computer 
“antique”.

When I run the command ‘n’ in cdos, I select French and I install AZERTY 102 
keys 8 bit keyboard.
Then when i press alt-gr + 3, on antique and vbox it display ‘#’, but on QEMU 
,it doesn’t, it print the gibberish ^@ sequence.
So VBox handle keyboard input properly, but not qemu.

I investigated to see if the problem was how QEMU interpret the alt-gr, and I 
thought it was, because the flags set in registers AH and AL when I press 
alt-gr are the same as when I press Alt (AH=0x2, AL=0x8) according to this site:
http://helppc.netcore2k.net/table/bda : AH – 40:18 AL – 40:17

So I launched qemu and vbox in debug mode, with gdb for qemu and the included 
debbuger for vbox. By breaking on 0xF000:0xFFF0 and inspecting the IVT, I could 
see that CDOS replaces the IRQ handler because the address stored at 0x24 (irq 
9) change after I resume execution, and when I inspect the machine code at 
0xAF:0x618 (address of the IRQ 9 stored in 0x24 after cdos has started), it’s 
the same on qemu and vbox.

The behavior and scancodes received are the same on QEMU and VBox in the CDOS 
irq 1 handler. I break on the respective BIOS irq 1 handler, called from the 
CDOS irq 1 handler, and at this point the byte read on 0x60 differs. Exemple 
for alt-gr, so 0xE038:

  *   …
  *   %113f   e4 60   in AL, 060h // CDOS 
read 0xE0 from port 0x60
  *   …
  *   CDOS call bios handler
  *   …
  *   %000fe987   e4 60   in AL, 060h // VBOX 
bios read 0xE0, QEMU bios read 0x38
  *   …

I didn’t see any command from CDOS irq 1 handler that would tell the PS2 
controller to refeed the last byte read on the port 0x60, and all the BIOS does 
before the read is to deactivate the keyboard by writing 0xAD to port 0x64, so 
I think the issue could be from how the ps2 controller is emulated on QEMU. 
Somehow, VBOX knows that it has to keep the value in it’s output buffer after 
the first read, or maybe some kind of timer, idk.

I join to this mail the asm of the CDOS irq 1 handler that I extracted from the 
debugger.
If someone could help me to create a fix, even not official, that we could use 
on our project.

Thanks a lot.
This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is intended only for the person to whom 
it is addressed. If you are not the intended recipient, you are not authorized 
to read, print, retain, copy, disseminate, distribute, or use this message or 
any part thereof. If you receive this message in error, please notify the 
sender immediately and delete all copies of this message.


irq1_cdos_handler
Description: irq1_cdos_handler

Re: [RFC PATCH v2 05/32] hw/cxl/device: Implement the CAP array (8.2.8.1-2)

[Ben Widawsky]

On 21-01-06 13:28:05, Jonathan Cameron wrote:
> On Tue, 5 Jan 2021 08:52:56 -0800
> Ben Widawsky  wrote:
> 
> > This implements all device MMIO up to the first capability .That
> > includes the CXL Device Capabilities Array Register, as well as all of
> > the CXL Device Capability Header Registers. The latter are filled in as
> > they are implemented in the following patches.
> > 
> > v2: Break out register alignment checks (Jonathan)
> > 
> > Signed-off-by: Ben Widawsky 
> Hi Ben,
> 
> One buglet / inconsistency inline that I spotted whilst chasing that issue
> with size of reads.
> 
> Will get to a full review after messing around ('testing') this a bit more ;)
> 
> Jonathan
> 
> > ---
> >  hw/cxl/cxl-device-utils.c | 72 +++
> >  hw/cxl/meson.build|  1 +
> >  2 files changed, 73 insertions(+)
> >  create mode 100644 hw/cxl/cxl-device-utils.c
> > 
> > diff --git a/hw/cxl/cxl-device-utils.c b/hw/cxl/cxl-device-utils.c
> > new file mode 100644
> > index 00..d1b1371e66
> > --- /dev/null
> > +++ b/hw/cxl/cxl-device-utils.c
> > @@ -0,0 +1,72 @@
> > +/*
> > + * CXL Utility library for devices
> > + *
> > + * Copyright(C) 2020 Intel Corporation.
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2. See the
> > + * COPYING file in the top-level directory.
> > + */
> > +
> > +#include "qemu/osdep.h"
> > +#include "qemu/log.h"
> > +#include "hw/cxl/cxl.h"
> > +
> > +static int cxl_device_check_register_alignment(hwaddr offset, unsigned 
> > size)
> > +{
> > +if (unlikely(offset & (size - 1))) {
> > +return 1;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +static uint64_t caps_reg_read(void *opaque, hwaddr offset, unsigned size)
> > +{
> > +CXLDeviceState *cxl_dstate = opaque;
> > +
> > +if (cxl_device_check_register_alignment(offset, size)) {
> > +qemu_log_mask(LOG_UNIMP, "Unaligned register read\n");
> > +return 0;
> > +}
> > +
> > +return ldn_le_p(cxl_dstate->caps_reg_state + offset, size);
> > +}
> > +
> > +static const MemoryRegionOps caps_ops = {
> > +.read = caps_reg_read,
> > +.write = NULL,
> > +.endianness = DEVICE_LITTLE_ENDIAN,
> > +.valid = {
> > +.min_access_size = 4,
> > +.max_access_size = 8,
> > +},
> > +.impl = {
> > +.min_access_size = 4,
> > +.max_access_size = 8,
> > +},
> > +};
> > +
> > +void cxl_device_register_block_init(Object *obj, CXLDeviceState 
> > *cxl_dstate)
> > +{
> > +/* This will be a BAR, so needs to be rounded up to pow2 for PCI spec 
> > */
> > +memory_region_init(
> > +_dstate->device_registers, obj, "device-registers",
> > +pow2ceil(CXL_MAILBOX_REGISTERS_LENGTH + 
> > CXL_MAILBOX_REGISTERS_OFFSET));
> 
> I can see why you jumped directly to sizing this for the whole region, but 
> the snag
> is that means I think you missed the fact that patch 8 adds a region after 
> the end
> of the mailbox.   Doesn't result in an actual bug because the ceil above takes
> you way past the space needed though (the memory device region is only 8 
> bytes long).
> 
> 

Maybe I misunderstand, but this is the intended behavior.
cxl_dstate->device_registers is the MemoryRegion container for all the
subregions that are the actual device MMIO.

 +--+
  ^  |  |
  |  |  unused  |
  |  
  |  |   memdev regs|
  |  
  |  |  |
  |  | +--+ |
 cxl_dstate-> |  | |  | |
 device_registers |  | |  | |
  |  | |payload   | |
  |  | |(2k currently)| |
  |  | |  | |
  |  | |  | |
  |  | +--+ |
  |  |   mailbox regs   |
  |  
  |  |device regs   |
  v  
 | caps regs|
 BAR --> +--+


Perhaps I should add this as a comment in the code?

> > +
> > +memory_region_init_io(_dstate->caps, obj, _ops, cxl_dstate,
> > +  "cap-array", CXL_DEVICE_REGISTERS_OFFSET - 0);
> > +
> > +memory_region_add_subregion(_dstate->device_registers, 0,
> > +_dstate->caps);
> > +}
> > +
> > +void cxl_device_register_init_common(CXLDeviceState *cxl_dstate)
> > +{
> > +uint32_t *cap_hdrs = cxl_dstate->caps_reg_state32;
> > +const int cap_count = 0;
> > +
> > +/* CXL Device Capabilities Array Register */
> > +ARRAY_FIELD_DP32(cap_hdrs, CXL_DEV_CAP_ARRAY, CAP_ID, 0);
> > +ARRAY_FIELD_DP32(cap_hdrs, CXL_DEV_CAP_ARRAY, CAP_VERSION, 1);
> > +ARRAY_FIELD_DP32(cap_hdrs, CXL_DEV_CAP_ARRAY2, CAP_COUNT, 

Re: [PATCH v2] tracetool: also strip %l and %ll from systemtap format strings

[Philippe Mathieu-Daudé]

On 1/6/21 3:36 PM, Laurent Vivier wrote:
> On 06/01/2021 14:02, Daniel P. Berrangé wrote:
>> All variables are 64-bit and so %l / %ll are not required, and the
>> latter is actually invalid:
>>
>>   $ sudo stap -e 'probe begin{printf ("BEGIN")}'  -I .
>>   parse error: invalid or missing conversion specifier
>>   saw: operator ',' at ./qemu-system-x86_64-log.stp:15118:101
>>source: printf("%d@%d vhost_vdpa_set_log_base dev: %p base: 0x%x 
>> size: %llu
>> refcnt: %d fd: %d log: %p\n", pid(), gettimeofday_ns(), dev, base, size, 
>> refcnt, fd, log)
>>
>>^
>>
>> Signed-off-by: Daniel P. Berrangé 
>> ---
>>  scripts/tracetool/format/log_stap.py | 7 ++-
>>  1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> In v2:
>>
>>  - Change existing logic that stripped %z to handle %l/%ll too
>>
>> diff --git a/scripts/tracetool/format/log_stap.py 
>> b/scripts/tracetool/format/log_stap.py
>> index b486beb672..fac911a0f4 100644
>> --- a/scripts/tracetool/format/log_stap.py
>> +++ b/scripts/tracetool/format/log_stap.py
>> @@ -77,7 +77,12 @@ def c_fmt_to_stap(fmt):
>>  elif state == STATE_LITERAL:
>>  bits.append(literal)
>>  
>> -fmt = re.sub("%(\d*)z(x|u|d)", "%\\1\\2", "".join(bits))
>> +# All variables in systemtap are 64-bit in size
>> +# The "%l" integer size qualifier is thus redundant
>> +# and "%ll" is not valid at all. Simiarly the size_t
> 
> Didn't see the typo the first time:
> 
> s/Simiarly/Similarly/

Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCHv3] arm-virt: add secure pl061 for reset/power down

[Philippe Mathieu-Daudé]

On 1/6/21 5:34 PM, Maxim Uvarov wrote:
> Add secure pl061 for reset/power down machine from
> the secure world (Arm Trusted Firmware).
> Use the same gpio 3 and gpio 4 which were used by
> non acpi variant of linux power control gpios.
> 
> Signed-off-by: Maxim Uvarov 
> ---
>  v3: added missed include qemu/log.h for qemu_log(.. 
>  v2: replace printf with qemu_log (Philippe Mathieu-Daudé)

Thanks!

Reviewed-by: Philippe Mathieu-Daudé 

> 
>  hw/arm/Kconfig|  1 +
>  hw/arm/virt.c | 24 
>  hw/gpio/Kconfig   |  3 ++
>  hw/gpio/gpio_pwr.c| 85 +++
>  hw/gpio/meson.build   |  1 +
>  include/hw/arm/virt.h |  1 +
>  6 files changed, 115 insertions(+)
>  create mode 100644 hw/gpio/gpio_pwr.

Re: [PATCH 5/5] i386: provide simple 'hyperv=on' option to x86 machine types

[Igor Mammedov]

On Wed, 06 Jan 2021 14:38:56 +0100
Vitaly Kuznetsov  wrote:

> Igor Mammedov  writes:
> 
> > On Tue, 05 Jan 2021 17:31:43 +0100
> > Vitaly Kuznetsov  wrote:
> >  
> >> Igor Mammedov  writes:
> >>   
> >> > On Tue, 05 Jan 2021 12:50:05 +0100
> >> >
> >> > I think there is a misunderstanding, idea was:
> >> >
> >> > cpu_initfn() {
> >> > //current set
> >> > cpu->default_hyperv_cpu_features = ACD
> >> > }
> >> >
> >> > compat_props_5.1 {
> >> >cpu.default_hyperv_cpu_features = AB
> >> > }
> >> >
> >> > compat_props_5.2 {
> >> >cpu.default_hyperv_cpu_features = ABC
> >> > }
> >> >
> >> 
> >> ...
> >>   
> >> > I was talking about CPU features/properties only, it doesn't apply to 
> >> > other devices.
> >> > It makes sense for machine to have a knob to create onboard hyperv 
> >> > specific
> >> > devices if there is any (do we have any?).
> >> >
> >> > If there aren't any currently, I wouldn't bother with machine knob
> >> > and just use -cpu foo,hv_default=on or -device cpu,hv_default=on
> >> > like any other cpu feature.
> >> >
> >> 
> >> We don't currently have any devices which are not 'CPU features' (in
> >> QEMU terminology), however, we already have Vmbus and I can easily
> >> imagine us implementing e.g. hartbeat/kvp/vss/... devices on top. We
> >> *may* want to enable these 'automatically' and that's what make
> >> '-machine' option preferable. It is, however, not a *must* right now and
> >> we can indeed wait until these devices appear and be happy with
> >> 'hv_default' -cpu option for now. We will, however, need to teach upper
> >> layers about the change when/if it happens.  
> >
> > which makes me think we are trying to bite something that we shouldn't.
> > Do we really need this patch (QEMU knob) to magically enable subset of
> > features and/or devices for a specific OS flavor?
> >
> > It's job of upper layers to abstract low level QEMU details in to coarse
> > grained knobs (libvirt/virt-install/virt-manager/...).
> > For example virt-install may know that it installing a specific Windows
> > version, and can build a tailored for that OS configuration including
> > needed hyperv CPU features and hyperv specific devices.
> > (if I'm not mistaken libosinfo is used to get metadata for preferred
> > configuration, so perhaps this should become a patch for that library
> > and its direct users).
> >
> > What we actually lack is a documentation for preferred configuration
> > in docs/hyperv.txt, currently it just enumerates possible features.
> > We can just document a recommended 'best practices' there without
> > putting it in QEMU code and let upper layers to do their job in
> > the stack.  
> 
> The problem we're facing here is that when a new enlightenment is
> implemented it takes forever to propagate to the whole stack. We don't
It's true not only for Hyper-V, I guess it's price to pay for modular solution.

> have any different recommendations for different Windows versions,
> neither does genuine Hyper-V. The 'fine grained' mechanis we have just
> contributes to the creation of various Frankenstein configurations
> (which look nothing like real Hyper-V), people just google for 'Windows
> KVM slow', add something to their scripts and this keeps propagating.
That's why I mentioned lack of documentation.
If someone manually configures QEMU, one should understand what they do
enable and why or enlist help of virt-install and likes.

> Every time I see a configuration with only a few 'hv_*' options I ask
> 'why don't you enable the rest?' and I'm yet to receive an answer
> different from 'hm, I don't know, I copied it from somewhere and it
> worked'.

If individual features are are composed by virt-install or other tools
based on libosinfo data, then we don't have to maintain versioning
of new default_set_features per machine type, which will only become
worse if we include hv specific devices into it.

Also with libosinfo approach, old machine types and old QEMU versions
can also benefit from it without need to change whole stack.
And no versioning is necessary since chosen config set is stored in
domain XML at the moment VM is created.

> Setting 'hv_*' options individually should be considered debug only.
that's how cpu's features were designed, a helper knob on top is fine
as long as it doesn't mess the way it used to work and preferably is
build on top of existing features.

PS:
another wild idea how to implement it using '-machine hyperv=on',
based on compat props idea:

// replaces bit set in your version
hv_default_set[] =
  "hv_feat1", "hv_feat2",
 ...
};

// probably should be done before -cpu is parsed
then if machine hyperv=on
   foreach in hv_default_set[]
  object_register_sugar_prop(hv_default_set[i], "on")

PS2:
my preferred approach is still -cpu hyperv=on, since it doesn't
depend on order CLI is currently parsed (which is fragile thing),
but rather on what user asked us to do with CPU.

Re: [PATCH V2 05/22] vl: memfd-alloc option

[Steven Sistare]

On 1/5/2021 11:27 AM, Daniel P. Berrangé wrote:
> On Tue, Jan 05, 2021 at 07:41:53AM -0800, Steve Sistare wrote:
>> Allocate anonymous memory using memfd_create if the memfd-alloc option is
>> set.
>>
>> Signed-off-by: Steve Sistare 
>> ---
>>  exec.c  | 38 ++
>>  include/sysemu/sysemu.h |  1 +
>>  qemu-options.hx | 11 +++
>>  softmmu/vl.c|  4 
>>  trace-events|  1 +
>>  5 files changed, 47 insertions(+), 8 deletions(-)
> 
>> diff --git a/qemu-options.hx b/qemu-options.hx
>> index 708583b..455b43b7 100644
>> --- a/qemu-options.hx
>> +++ b/qemu-options.hx
>> @@ -4094,6 +4094,17 @@ SRST
>>  an unmigratable state.
>>  ERST
>>  
>> +#ifdef __linux__
>> +DEF("memfd-alloc", 0,  QEMU_OPTION_memfd_alloc, \
>> +"-memfd-alloc allocate anonymous memory using memfd_create\n",
>> +QEMU_ARCH_ALL)
>> +#endif
>> +
>> +SRST
>> +``-memfd-alloc``
>> +Allocate anonymous memory using memfd_create (Linux only).
>> +ERST
> 
> Do we really need a new arg for this ? It is already possible to request
> use of memfd for the guest RAM using
> 
>   -object memory-backend-memfd,id=ram-node0,size=
> 
> this memory backend object framework was intended to remove the need to
> add new ad-hoc CLI args for controlling memory allocation.

Yes, I considered that, but there are other memory regions that cannot be 
controlled
by the command line but which must be preserved, such as vram, bios, and rom.  
If vram
is not preserved, parts of the screen will be blank until the user performs 
some action
which refreshes the display.  bios and rom should be preserved rather than 
re-recreated
with potentially different contents from the firmware images in the updated 
qemu package.

However, your comment reminds me that I must add a few lines of code to 
preserve the 
memory-backend-memfd.

- Steve

Re: [PATCHv3] arm-virt: add secure pl061 for reset/power down

[Maxim Uvarov]

Please skip v2 and use v3. I had to check that one line change code
compiles. qemu_log() requires include header for that function.

Best regards,
Maxim.

On Wed, 6 Jan 2021 at 19:34, Maxim Uvarov  wrote:
>
> Add secure pl061 for reset/power down machine from
> the secure world (Arm Trusted Firmware).
> Use the same gpio 3 and gpio 4 which were used by
> non acpi variant of linux power control gpios.
>
> Signed-off-by: Maxim Uvarov 
> ---
>  v3: added missed include qemu/log.h for qemu_log(..
>  v2: replace printf with qemu_log (Philippe Mathieu-Daudé)
>
>  hw/arm/Kconfig|  1 +
>  hw/arm/virt.c | 24 
>  hw/gpio/Kconfig   |  3 ++
>  hw/gpio/gpio_pwr.c| 85 +++
>  hw/gpio/meson.build   |  1 +
>  include/hw/arm/virt.h |  1 +
>  6 files changed, 115 insertions(+)
>  create mode 100644 hw/gpio/gpio_pwr.c
>
> diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
> index 0a242e4c5d..13cc42dcc8 100644
> --- a/hw/arm/Kconfig
> +++ b/hw/arm/Kconfig
> @@ -17,6 +17,7 @@ config ARM_VIRT
>  select PL011 # UART
>  select PL031 # RTC
>  select PL061 # GPIO
> +select GPIO_PWR
>  select PLATFORM_BUS
>  select SMBIOS
>  select VIRTIO_MMIO
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 96985917d3..eff0345303 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -147,6 +147,7 @@ static const MemMapEntry base_memmap[] = {
>  [VIRT_RTC] ={ 0x0901, 0x1000 },
>  [VIRT_FW_CFG] = { 0x0902, 0x0018 },
>  [VIRT_GPIO] =   { 0x0903, 0x1000 },
> +[VIRT_SECURE_GPIO] ={ 0x09031000, 0x1000 },
>  [VIRT_SECURE_UART] ={ 0x0904, 0x1000 },
>  [VIRT_SMMU] =   { 0x0905, 0x0002 },
>  [VIRT_PCDIMM_ACPI] ={ 0x0907, MEMORY_HOTPLUG_IO_LEN },
> @@ -189,6 +190,7 @@ static const int a15irqmap[] = {
>  [VIRT_GPIO] = 7,
>  [VIRT_SECURE_UART] = 8,
>  [VIRT_ACPI_GED] = 9,
> +[VIRT_SECURE_GPIO] = 10,
>  [VIRT_MMIO] = 16, /* ...to 16 + NUM_VIRTIO_TRANSPORTS - 1 */
>  [VIRT_GIC_V2M] = 48, /* ...to 48 + NUM_GICV2M_SPIS - 1 */
>  [VIRT_SMMU] = 74,/* ...to 74 + NUM_SMMU_IRQS - 1 */
> @@ -864,6 +866,24 @@ static void create_gpio(const VirtMachineState *vms)
>  g_free(nodename);
>  }
>
> +static void create_gpio_secure(const VirtMachineState *vms)
> +{
> +DeviceState *pl061_dev;
> +static DeviceState *gpio_pwr_dev;
> +
> +hwaddr base = vms->memmap[VIRT_SECURE_GPIO].base;
> +int irq = vms->irqmap[VIRT_SECURE_GPIO];
> +
> +pl061_dev = sysbus_create_simple("pl061", base,
> + qdev_get_gpio_in(vms->gic, irq));
> +
> +gpio_pwr_dev = sysbus_create_simple("gpio-pwr", -1,
> +qdev_get_gpio_in(pl061_dev, 3));
> +
> +qdev_connect_gpio_out(pl061_dev, 3, qdev_get_gpio_in(gpio_pwr_dev, 3));
> +qdev_connect_gpio_out(pl061_dev, 4, qdev_get_gpio_in(gpio_pwr_dev, 4));
> +}
> +
>  static void create_virtio_devices(const VirtMachineState *vms)
>  {
>  int i;
> @@ -1993,6 +2013,10 @@ static void machvirt_init(MachineState *machine)
>  create_gpio(vms);
>  }
>
> +if (vms->secure) {
> +create_gpio_secure(vms);
> +}
> +
>   /* connect powerdown request */
>   vms->powerdown_notifier.notify = virt_powerdown_req;
>   qemu_register_powerdown_notifier(>powerdown_notifier);
> diff --git a/hw/gpio/Kconfig b/hw/gpio/Kconfig
> index b6fdaa2586..f0e7405f6e 100644
> --- a/hw/gpio/Kconfig
> +++ b/hw/gpio/Kconfig
> @@ -8,5 +8,8 @@ config PL061
>  config GPIO_KEY
>  bool
>
> +config GPIO_PWR
> +bool
> +
>  config SIFIVE_GPIO
>  bool
> diff --git a/hw/gpio/gpio_pwr.c b/hw/gpio/gpio_pwr.c
> new file mode 100644
> index 00..0d0680c9f7
> --- /dev/null
> +++ b/hw/gpio/gpio_pwr.c
> @@ -0,0 +1,85 @@
> +/*
> + * GPIO qemu power controller
> + *
> + * Copyright (c) 2020 Linaro Limited
> + *
> + * Author: Maxim Uvarov 
> + *
> + * Virtual gpio driver which can be used on top of pl061
> + * to reboot and shutdown qemu virtual machine. One of use
> + * case is gpio driver for secure world application (ARM
> + * Trusted Firmware.).
> + *
> + * This work is licensed under the terms of the GNU GPL, version 2 or later.
> + * See the COPYING file in the top-level directory.
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#include "qemu/osdep.h"
> +#include "qemu/log.h"
> +#include "hw/irq.h"
> +#include "hw/sysbus.h"
> +#include "sysemu/runstate.h"
> +
> +#define TYPE_GPIOPWR "gpio-pwr"
> +OBJECT_DECLARE_SIMPLE_TYPE(GPIO_PWR_State, GPIOPWR)
> +
> +struct GPIO_PWR_State {
> +SysBusDevice parent_obj;
> +qemu_irq irq;
> +};
> +
> +static void gpio_pwr_set_irq(void *opaque, int irq, int level)
> +{
> +GPIO_PWR_State *s = (GPIO_PWR_State *)opaque;
> +
> +qemu_set_irq(s->irq, 1);
> +
> +if (level) {
> +return;
> +}
> +
> +