[Qemu-devel] [Bug 1824528] Re: qemu fails to compile on gcc 9 `error: taking address of packed member of ‘struct ’ may result in an unaligned pointer value [-Werror=address-of-packed-member
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1824528 Title: qemu fails to compile on gcc 9 `error: taking address of packed member of ‘struct ’ may result in an unaligned pointer value [-Werror=address-of-packed-member]` Status in QEMU: Fix Released Bug description: Qemu compilation fails with below error on ppc64le host with gcc 9(9.0.1 20190328) repo: https://github.com/qemu/qemu.git branch: master commit e1be98540ee672ef93292b65a986055512237c35 CC net/dump.o hw/usb/dev-mtp.c: In function ‘usb_mtp_write_metadata’: hw/usb/dev-mtp.c:1708:36: error: taking address of packed member of ‘struct ’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 1708 | dataset->filename); | ~~~^~ cc1: all warnings being treated as errors CC net/eth.o make: *** [/home/kvmci/qemu-main/rules.mak:69: hw/usb/dev-mtp.o] Error 1 make: *** Waiting for unfinished jobs CC net/announce.o To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1824528/+subscriptions
[Qemu-devel] [Bug 1826172] Re: Compilation on MSYS2/MinGW-w64 fails with error: "__USE_MINGW_ANSI_STDIO" redefined
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1826172 Title: Compilation on MSYS2/MinGW-w64 fails with error: "__USE_MINGW_ANSI_STDIO" redefined Status in QEMU: Fix Released Bug description: Compilation against GIT master fails at the following step: CC qga/commands.o In file included from qga/commands.c:13: C:/Tempy-chan/qemu/include/qemu/osdep.h:97: error: "__USE_MINGW_ANSI_STDIO" redefined [-Werror] #define __USE_MINGW_ANSI_STDIO 1 In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/vadefs.h:9, from C:/msys64/mingw64/x86_64-w64-mingw32/include/_mingw_stdarg.h:14, from C:/msys64/mingw64/x86_64-w64-mingw32/include/stdarg.h:140, from C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/8.3.0/include/stdarg.h:1, from C:/Tempy-chan/qemu/include/qemu/osdep.h:88, from qga/commands.c:13: C:/msys64/mingw64/x86_64-w64-mingw32/include/_mingw.h:431: note: this is the location of the previous definition #define __USE_MINGW_ANSI_STDIO 0 /* was not defined so it should be 0 */ cc1.exe: all warnings being treated as errors make: *** [/c/Tempy-chan/qemu/rules.mak:69: qga/commands.o] Error 1 Passing --extra-cflags="-D__USE_MINGW_ANSI_STDIO" to configure resolves the error. Digging deeper in x86_64-w64-mingw32/include/_mingw.h, it looks like __USE_MINGW_ANSI_STDIO is only defined for _GNU_SOURCE in C++ compilation. With C only code it's ignored and doesn't define __USE_MINGW_ANSI_STDIO as expected: /* We are activating __USE_MINGW_ANSI_STDIO for various define indicators. Note that we enable it also for _GNU_SOURCE in C++, but not for C case. */ #if (defined (_POSIX) || defined (_POSIX_SOURCE) || defined (_POSIX_C_SOURCE) \ || defined (_ISOC99_SOURCE) \ || defined (_XOPEN_SOURCE) || defined (_XOPEN_SOURCE_EXTENDED) \ || (defined (_GNU_SOURCE) && defined (__cplusplus)) \ || defined (_SVID_SOURCE)) \ && !defined(__USE_MINGW_ANSI_STDIO) /* Enable __USE_MINGW_ANSI_STDIO if _POSIX defined * and If user did _not_ specify it explicitly... */ # define __USE_MINGW_ANSI_STDIO 1 #endif To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1826172/+subscriptions
[Qemu-devel] [Bug 1834613] Re: Crypto related operations failing on Alpine Linux on QEMU 4.0
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1834613 Title: Crypto related operations failing on Alpine Linux on QEMU 4.0 Status in QEMU: Fix Released Bug description: I'm unable to boot the netboot image of Alpine Linux using QEMU 4.0. Steps to reproduce: curl -O http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/ppc64le/netboot/vmlinuz-vanilla curl -O http://dl-cdn.alpinelinux.org/alpine/v3.10/releases/ppc64le/netboot/initramfs-vanilla qemu-system-ppc64 -kernel vmlinuz-vanilla -initrd initramfs-vanilla -nographic -append "console=hvc0 ip=dhcp alpine_repo=http://dl-cdn.alpinelinux.org/alpine/v3.10/main; The init script will automatically download and install an in-memory Alpine Linux environment. However, with QEMU 4.0, the installation process will fail with "BAD signature" errors: (1/20) Installing musl (1.1.22-r2) ERROR: musl-1.1.22-r2: BAD signature (2/20) Installing busybox (1.30.1-r2) ERROR: busybox-1.30.1-r2: BAD signature (3/20) Installing alpine-baselayout (3.1.2-r0) Executing alpine-baselayout-3.1.2-r0.pre-install ERROR: alpine-baselayout-3.1.2-r0.pre-install: script exited with error 127 ERROR: alpine-baselayout-3.1.2-r0: BAD signature (4/20) Installing openrc (0.41.2-r1) ERROR: openrc-0.41.2-r1: BAD signature (5/20) Installing alpine-conf (3.8.3-r0) ERROR: alpine-conf-3.8.3-r0: BAD signature (6/20) Installing libcrypto1.1 (1.1.1c-r0) ERROR: libcrypto1.1-1.1.1c-r0: BAD signature (7/20) Installing libssl1.1 (1.1.1c-r0) ERROR: libssl1.1-1.1.1c-r0: BAD signature (8/20) Installing ca-certificates-cacert (20190108-r0) ERROR: ca-certificates-cacert-20190108-r0: BAD signature (9/20) Installing libtls-standalone (2.9.1-r0) ERROR: libtls-standalone-2.9.1-r0: BAD signature (10/20) Installing ssl_client (1.30.1-r2) ERROR: ssl_client-1.30.1-r2: BAD signature (11/20) Installing zlib (1.2.11-r1) ERROR: zlib-1.2.11-r1: BAD signature (12/20) Installing apk-tools (2.10.4-r1) ERROR: apk-tools-2.10.4-r1: BAD signature (13/20) Installing busybox-suid (1.30.1-r2) ERROR: busybox-suid-1.30.1-r2: BAD signature (14/20) Installing busybox-initscripts (3.1-r7) ERROR: busybox-initscripts-3.1-r7: BAD signature (15/20) Installing scanelf (1.2.3-r0) ERROR: scanelf-1.2.3-r0: BAD signature (16/20) Installing musl-utils (1.1.22-r2) ERROR: musl-utils-1.1.22-r2: BAD signature (17/20) Installing libc-utils (0.7.1-r0) ERROR: libc-utils-0.7.1-r0: BAD signature (18/20) Installing alpine-keys (2.1-r2) ERROR: alpine-keys-2.1-r2: BAD signature (19/20) Installing alpine-base (3.10.0-r0) ERROR: alpine-base-3.10.0-r0: BAD signature (20/20) Installing openssl (1.1.1c-r0) ERROR: openssl-1.1.1c-r0: BAD signature 20 errors; 0 MiB in 0 packages ok. grep: /sysroot/etc/inittab: No such file or directory /sbin/init not found in new root. Launching emergency recovery shell Type exit to continue boot. sh: can't access tty; job control turned off / # If I boot up a disk image created by a previous version of QEMU, crypto related operations like verifying a RSA signature using the "openssl" command will also fail. I didn't see these errors on previous QEMU versions or other architectures on QEMU 4.0 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1834613/+subscriptions
[Qemu-devel] [Bug 1838946] Re: qemu 3.10 golang crash
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838946 Title: qemu 3.10 golang crash Status in QEMU: Fix Released Bug description: Encountered below crashes in qemu 3.10 arm Also have raised the same in golang groups. But seems like in ARM32 hardware, the below commands works fine, only in qemu if crashes. https://groups.google.com/forum/?utm_medium=email_source=footer#!topic/golang-nuts/1txPOGa4aGc Need some pointers to narrow down Please see log below. $ qemu-arm-static --version qemu-arm version 3.1.0 (qemu-3.1.0-6.fc30) Copyright (c) 2003-2018 Fabrice Bellard and the QEMU Project developers arheneus@bbdee4f6f57d:/sonic/src/telemetry/test$ /usr/local/go/bin/go get -v github.com/Azure/sonic-telemetry/dialout/dialout_client_cli github.com/openconfig/ygot (download) github.com/kylelemons/godebug (download) github.com/openconfig/goyang (download) SIGSEGV: segmentation violation PC=0x4512c m=12 sigcode=1 goroutine 15 [syscall]: syscall.Syscall6(0x118, 0x1, 0x11c3, 0xf513b0, 0x104, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe280a0) /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 fp=0xf51380 sp=0xf5137c pc=0x88298 os.(*Process).blockUntilWaitable(0xf80300, 0xf80300, 0x0, 0x0) /usr/local/go/src/os/wait_waitid.go:31 +0x64 fp=0xf51438 sp=0xf51380 pc=0xa94a0 os.(*Process).wait(0xf80300, 0x13, 0xe6e1d0, 0xeba010) /usr/local/go/src/os/exec_unix.go:22 +0x2c fp=0xf51470 sp=0xf51438 pc=0xa2d58 os.(*Process).Wait(0xf80300, 0x4d5f58, 0x4d5f5c, 0x4d5f54) /usr/local/go/src/os/exec.go:125 +0x1c fp=0xf51484 sp=0xf51470 pc=0xa2494 os/exec.(*Cmd).Wait(0xe14000, 0x0, 0x0) /usr/local/go/src/os/exec/exec.go:465 +0x40 fp=0xf514bc sp=0xf51484 pc=0xf8620 os/exec.(*Cmd).Run(0xe14000, 0xd5c720, 0xf3) /usr/local/go/src/os/exec/exec.go:309 +0x44 fp=0xf514cc sp=0xf514bc pc=0xf7e1c cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x497ee2, 0x7, 0x2c, 0x116f8e0) /usr/local/go/src/cmd/go/internal/work/buildid.go:193 +0x2e0 fp=0xf515bc sp=0xf514cc pc=0x3549bc cmd/go/internal/work.(*Builder).buildActionID(0xd5cf60, 0x1177d90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) /usr/local/go/src/cmd/go/internal/work/exec.go:223 +0xb8c fp=0xf51978 sp=0xf515bc pc=0x3594fc cmd/go/internal/work.(*Builder).build(0xd5cf60, 0x1177d90, 0x0, 0x0) /usr/local/go/src/cmd/go/internal/work/exec.go:373 +0x3d3c fp=0xf51f44 sp=0xf51978 pc=0x35e374 cmd/go/internal/work.(*Builder).Do.func1(0x1177d90) /usr/local/go/src/cmd/go/internal/work/exec.go:107 +0x58 fp=0xf51f84 sp=0xf51f44 pc=0x38287c cmd/go/internal/work.(*Builder).Do.func2(0xdf0070, 0xd5cf60, 0x10427a0) /usr/local/go/src/cmd/go/internal/work/exec.go:165 +0x84 fp=0xf51fdc sp=0xf51f84 pc=0x382b24 runtime.goexit() /usr/local/go/src/runtime/asm_arm.s:867 +0x4 fp=0xf51fdc sp=0xf51fdc pc=0x67f44 created by cmd/go/internal/work.(*Builder).Do /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x2e4 goroutine 1 [semacquire]: sync.runtime_Semacquire(0xdf0078) /usr/local/go/src/runtime/sema.go:56 +0x2c sync.(*WaitGroup).Wait(0xdf0070) /usr/local/go/src/sync/waitgroup.go:130 +0x84 cmd/go/internal/work.(*Builder).Do(0xd5cf60, 0x1177290) /usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x304 cmd/go/internal/work.InstallPackages(0xc82078, 0x1, 0x1, 0xc0e938, 0x1, 0x2) /usr/local/go/src/cmd/go/internal/work/build.go:506 +0xa88 cmd/go/internal/get.runGet(0x810d78, 0xc82078, 0x1, 0x1) /usr/local/go/src/cmd/go/internal/get/get.go:196 +0x1b0 main.main() /usr/local/go/src/cmd/go/main.go:219 +0x93c goroutine 19 [syscall]: os/signal.signal_recv(0x0) /usr/local/go/src/runtime/sigqueue.go:139 +0x130 os/signal.loop() /usr/local/go/src/os/signal/signal_unix.go:23 +0x14 created by os/signal.init.0 /usr/local/go/src/os/signal/signal_unix.go:29 +0x30 goroutine 13 [syscall]: syscall.Syscall6(0x118, 0x1, 0x11ec, 0x10153b0, 0x104, 0x0, 0x0, 0x1c63c, 0x15e54, 0xe001e0) /usr/local/go/src/syscall/asm_linux_arm.s:45 +0x8 os.(*Process).blockUntilWaitable(0xe62840, 0xe62840, 0x0, 0x0) /usr/local/go/src/os/wait_waitid.go:31 +0x64 os.(*Process).wait(0xe62840, 0x1, 0xc0e360, 0xe00160) /usr/local/go/src/os/exec_unix.go:22 +0x2c os.(*Process).Wait(0xe62840, 0x4d5f58, 0x4d5f5c, 0x4d5f54) /usr/local/go/src/os/exec.go:125 +0x1c os/exec.(*Cmd).Wait(0xf8e0b0, 0x0, 0x0) /usr/local/go/src/os/exec/exec.go:465 +0x40 os/exec.(*Cmd).Run(0xf8e0b0, 0xca8060, 0xe6cd00) /usr/local/go/src/os/exec/exec.go:309 +0x44 cmd/go/internal/work.(*Builder).toolID(0xd5cf60, 0x49631b, 0x3, 0x11, 0x1015890)
[Qemu-devel] [Bug 1834113] Re: QEMU touchpad input erratic after wakeup from sleep
** Changed in: qemu Status: New => Incomplete -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1834113 Title: QEMU touchpad input erratic after wakeup from sleep Status in QEMU: Incomplete Status in libvirt package in Ubuntu: Incomplete Status in qemu package in Ubuntu: Incomplete Bug description: Using Ubuntu host and guest. Normally the touchpad works great. Within the last few days, suddenly, apparently after a wake from sleep, the touchpad will behave erratically. For example, it will take two clicks to select something, and when moving the cursor it will act as though it is dragging even with the button not clicked. A reboot fixes the issue temporarily. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: qemu 1:3.1+dfsg-2ubuntu3.1 Uname: Linux 5.1.14-050114-generic x86_64 ApportVersion: 2.20.10-0ubuntu27 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Jun 24 20:55:44 2019 Dependencies: EcryptfsInUse: Yes InstallationDate: Installed on 2019-02-20 (124 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 8087:0025 Intel Corp. Bus 001 Device 003: ID 0c45:671d Microdia Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. Precision 5530 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.1.14-050114-generic root=UUID=18e8777c-1764-41e4-a19f-62476055de23 ro mem_sleep_default=deep mem_sleep_default=deep acpi_rev_override=1 scsi_mod.use_blk_mq=1 nouveau.modeset=0 nouveau.runpm=0 nouveau.blacklist=1 acpi_backlight=none acpi_osi=Linux acpi_osi=! SourcePackage: qemu UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/26/2019 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.10.1 dmi.board.name: 0FP2W2 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.10.1:bd04/26/2019:svnDellInc.:pnPrecision5530:pvr:rvnDellInc.:rn0FP2W2:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: Precision dmi.product.name: Precision 5530 dmi.product.sku: 087D dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1834113/+subscriptions
[Qemu-devel] [Bug 1836451] Re: 'make info' fails due to errors in qemu-tech.texi
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1836451 Title: 'make info' fails due to errors in qemu-tech.texi Status in QEMU: Fix Released Bug description: git tag: v4.1.0-rc0 host: Fedora 29, x86_64 $ make info make[1]: Entering directory 'qemu/slirp' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory 'qemu/slirp' GEN docs/version.texi GEN qemu-options.texi GEN qemu-monitor.texi GEN qemu-img-cmds.texi GEN qemu-monitor-info.texi GEN qemu-doc.info qemu/qemu-tech.texi:6: @menu reference to nonexistent node `Translator Internals' qemu/qemu-tech.texi:7: @menu reference to nonexistent node `QEMU compared to other emulators' qemu/qemu-tech.texi:9: @menu reference to nonexistent node `Bibliography' Makefile:960: recipe for target 'qemu-doc.info' failed make: *** [qemu-doc.info] Error 1 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1836451/+subscriptions
[Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8c79b288513587e960b
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1830872
Title:
AARCH64 to ARMv7 mistranslation in TCG
Status in QEMU:
Fix Released
Bug description:
The following guest code:
https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S
implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI
Development Kit II) library function. (CopyMem() basically has memmove()
semantics, to provide a standard C analog here.) The relevant functions
are InternalMemCopyMem() and __memcpy().
When TCG translates this aarch64 code to x86_64, everything works
fine.
When TCG translates this aarch64 code to ARMv7, the destination area of
the translated CopyMem() function becomes corrupted -- it differs from
the intended source contents. Namely, in every 4096 byte block, the
8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,
instead of receiving the intended source value.
I'm attaching two hexdumps of the same destination area:
- "good.txt" is a hexdump of the destination area when CopyMem() was
translated to x86_64,
- "bad.txt" is a hexdump of the destination area when CopyMem() was
translated to ARMv7.
In order to assist with the analysis of this issue, I disassembled the
aarch64 binary with "objdump". Please find the listing in
"DxeCore.objdump", attached. The InternalMemCopyMem() function starts at
hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.
And, I ran the guest on the ARMv7 host with "-d
in_asm,op,op_opt,op_ind,out_asm". Please find the log in
"tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached.
The TBs that correspond to (parts of) the InternalMemCopyMem() and
__memcpy() functions are scattered over the TCG log file, but the offset
between the "nice" disassembly from "DxeCore.objdump", and the in-RAM
TBs in the TCG log, can be determined from the fact that there is a
single prfm instruction in the entire binary. The instruction's offset
is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy()
function --, and its RAM address is 0x472d2180 in the TCG log. Thus the
difference (= the load address of DxeCore.efi) is 0x472a7000.
QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch
'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21).
The reproducer command line is (on an ARMv7 host):
qemu-system-aarch64 \
-display none \
-machine virt,accel=tcg \
-nodefaults \
-nographic \
-drive
if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \
-drive
if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \
-cpu cortex-a57 \
-chardev stdio,signal=off,mux=on,id=char0 \
-mon chardev=char0,mode=readline \
-serial chardev:char0
The apparent symptom is an assertion failure *in the guest*, such as
> ASSERT [DxeCore]
>
/home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):
> Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength
but that is only a (distant) consequence of the CopyMem()
mistranslation, and resultant destination area corruption.
Originally reported in the following two mailing list messages:
- http://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com
- http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1830872/+subscriptions
[Qemu-devel] [Bug 1836078] Re: Regressions on arm-linux-gnueabihf target with some GCC tests
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=45b1a243b81a7c9ae562 ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1836078 Title: Regressions on arm-linux-gnueabihf target with some GCC tests Status in QEMU: Fix Released Bug description: Hi, After trying qemu master: commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde Merge: 68d7ff0 14f5d87 Author: Peter Maydell Date: Fri Jun 21 15:40:50 2019 +0100 even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite. I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. All tests used to pass w/o error, but with a recent qemu, all of them make qemu crash. This was noticed with GCC master configured with --target arm-none-linux-gnueabihf --with-cpu cortex-a57 --with-fpu crypto-neon-fp-armv8 Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1836078/+subscriptions
[Qemu-devel] [Bug 1738545] Re: Go binaries panic with "mmap errno 9" on qemu-user
I'm marking this bug as "fix released" now since the Arm problem has
been fixed. If there is something else to do for sh4, please open a new
bug as suggested by Peter.
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1738545
Title:
Go binaries panic with "mmap errno 9" on qemu-user
Status in QEMU:
Fix Released
Bug description:
Go binaries panic with "mmap errno 9" on qemu-user.
root@nofan:/# cat hello.go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
root@nofan:/# gccgo-7 hello.go -o hello
root@nofan:/# ./hello
mmap errno 9
fatal error: mmap
runtime stack:
mmap errno 9
fatal error: mmap
panic during panic
runtime stack:
mmap errno 9
fatal error: mmap
stack trace unavailable
root@nofan:/#
Tested with qemu from git master with Debian unstable for armel.
Same binaries work fine on real hardware.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1738545/+subscriptions
[Qemu-devel] [Bug 1836192] Re: Regressions on arm926 target with some GCC tests
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=cb7cef8b32033f6284a47d797 ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1836192 Title: Regressions on arm926 target with some GCC tests Status in QEMU: Fix Released Bug description: Hi, After trying qemu master: commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde Merge: 68d7ff0 14f5d87 Author: Peter Maydell Date: Fri Jun 21 15:40:50 2019 +0100 even with the fix for https://bugs.launchpad.net/qemu/+bug/1834496, I've noticed several regressions compared to qemu-3.1 when running the GCC testsuite, with GCC configured to generate arm10tdmi code by default, and using qemu's --cpu arm926. I'm attaching a tarball containing one of the GCC tests (binaries), needed shared libs, and a short script to run the test. This was noticed with GCC master configured with --target arm-none-linux-gnueabi --with-cpu arm10tdmi --with-fpu vfp Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1836192/+subscriptions
[Qemu-devel] [Bug 1831545] Re: "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1831545 Title: "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host Status in QEMU: Fix Released Bug description: As described in https://lists.gnu.org/archive/html/qemu- devel//2019-05/msg07362.html I run into TCG regression in qemu-git. Unfortunately, fix from bug https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn- effective for my case. For reproduction (on 32-bit x86 host, in my case Slackware with gcc 5.5.0): ./configure --target-list=x86_64-softmmu --disable-werror --enable- debug-tcg make (-j5 in my case) try to boot any 64-bit kernel: x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64 -accel tcg result is - qemu appear to hang right after "Booting the kernel" line. Decompression (xz) was ok. Tested with qemu-git commit e2a58ff493a2e00db3e963c1839c5374500110f2 32-bit OS can be booted fine, and -enable-kvm also allow 64 bit kernel/os to boot. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1831545/+subscriptions
[Qemu-devel] [Bug 1794187] Re: improve error message, when using raspi3 and RAM>4G
Fixed here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ff3dcf28c0b7a3ac261 ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1794187 Title: improve error message, when using raspi3 and RAM>4G Status in QEMU: Fix Released Bug description: Running `qemu-system-aarch64 image-aarch64.iso --machine raspi3 -m 8G` prints this error message: ``` Unexpected error in visit_type_uintN() at /builddir/build/BUILD/qemu-3.0.0/qapi/qapi-visit-core.c:164: qemu-system-aarch64: Parameter 'vcram-base' expects uint32_t ``` The problem is, that you musn't use more than 4 GB RAM for machine raspi3. As it took me some time to figure that out, I'd be glad, if you can print better error message, like you do, when using more than 4 CPU cores with machine raspi3: ``` Invalid SMP CPUs 8. The max CPUs supported by machine 'raspi3' is 4 ``` To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1794187/+subscriptions
[Qemu-devel] [Bug 1817345] Re: configure script breaks when $source_path contains white spaces
Patch included here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=4ace32e22713ffd79deb22 ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1817345 Title: configure script breaks when $source_path contains white spaces Status in QEMU: Fix Released Bug description: Hi, I noticed that the configure script breaks when the qemu source directory is in a path containing white spaces, in particular the list of targets is not correctly generated when calling "./configure --help". Steps to reproduce the problem: $ mkdir "dir with spaces" $ cd dir\ with\ spaces/ $ git clone https://git.qemu.org/git/qemu.git $ cd qemu/ $ ./configure --help | grep -A3 target-list Actual result: --target-list=LIST set target list (default: build everything) Available targets: dir with *-softmmu dir with *-linux-user Expected result: --target-list=LIST set target list (default: build everything) Available targets: aarch64-softmmu alpha-softmmu arm-softmmu cris-softmmu hppa-softmmu i386-softmmu lm32-softmmu m68k-softmmu microblaze-softmmu This happens because the $mak_wilds variable uses spaces to separate different paths, maybe newlines may be used, which are less likely to be in directory names. BTW "shellcheck" may help finding some other problems. Qemu version: $ git describe v3.1.0-1960-ga05838cb2a Thanks, Antonio To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1817345/+subscriptions
[Qemu-devel] [Bug 1826422] Re: Regression: QEMU 4.0 hangs the host (*bisect included*)
Fix has been included here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=c87759ce876a7a0b17c2b ** Changed in: qemu Status: In Progress => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1826422 Title: Regression: QEMU 4.0 hangs the host (*bisect included*) Status in QEMU: Fix Released Bug description: The commit b2fc91db84470a78f8e93f5b5f913c17188792c8 seemingly introduced a regression on my system. When I start QEMU, the guest and the host hang (I need a hard reset to get back to a working system), before anything shows on the guest. I use QEMU with GPU passthrough (which worked perfectly until the commit above). This is the command I use: ``` /path/to/qemu-system-x86_64 -drive if=pflash,format=raw,readonly,file=/path/to/OVMF_CODE.fd -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd.tmp -enable-kvm -machine q35,accel=kvm,mem-merge=off -cpu host,kvm=off,hv_vendor_id=vgaptrocks,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time -smp 4,cores=4,sockets=1,threads=1 -m 10240 -vga none -rtc base=localtime -serial none -parallel none -usb -device usb-tablet -device vfio-pci,host=01:00.0,multifunction=on -device vfio-pci,host=01:00.1 -device usb-host,vendorid=,productid= -device usb-host,vendorid=,productid= -device usb-host,vendorid=,productid= -device usb-host,vendorid=,productid= -device usb-host,vendorid=,productid= -device usb-host,vendorid=,productid= -device virtio-scsi-pci,id=scsi -drive file=/path/to/guest.img,id=hdd1,format=qcow2,if=none,cache=writeback -device scsi-hd,drive=hdd1 -net nic,model=virtio -net user,smb=/path/to/shared ``` If I run QEMU without GPU passthrough, it runs fine. Some details about my system: - O/S: Mint 19.1 x86-64 (it's based on Ubuntu 18.04) - Kernel: 4.15 - `configure` options: `--target-list=x86_64-softmmu --enable-gtk --enable-spice --audio-drv-list=pa` - EDK2 version: 1a734ed85fda71630c795832e6d24ea560caf739 (20/Apr/2019) - CPU: i7-6700k - Motherboard: ASRock Z170 Gaming-ITX/ac - VGA: Gigabyte GTX 960 Mini-ITX To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1826422/+subscriptions
[Qemu-devel] [Bug 1832353] Re: cpu_exec: Assertion !have_mmap_lock() failed
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=52ba13f042714c4086416 ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1832353 Title: cpu_exec: Assertion !have_mmap_lock() failed Status in QEMU: Fix Released Bug description: Hi, I have isolated a testcase from the GCC testsuite (actually gfortran, test proc_ptr_51.f90) which produces tons of: qemu-arm: /home/christophe.lyon/src/qemu/accel/tcg/cpu-exec.c:701: cpu_exec: Assertion `!have_mmap_lock()' failed. including with master qemu as of today. I'm attaching a tarball containing: qemu-assert: cmd lib proc_ptr_51.exe qemu-assert/lib: ld-linux-armhf.so.3 libc.so.6 libgcc_s.so.1 libgfortran.so.5 libm.so.6 where cmd is the basic command used to launch the test & reproduce the failure. Note that the test or the generated may actually be buggy: I have reported failures on native aarch64 and arm machines. Yet, qemu should not fail with a loop of asserts. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1832353/+subscriptions
[Qemu-devel] [Bug 1825311] Re: mips_cpu_handle_mmu_fault renders all accessed pages executable
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1825311 Title: mips_cpu_handle_mmu_fault renders all accessed pages executable Status in QEMU: Fix Released Bug description: On MIPS, data accesses to pages mapped in the TLB result in mips_cpu_handle_mmu_fault() marking the page unconditionally executable, even if the TLB entry has the XI bit set. Later on, when there is an attempt to execute this page, no exception is generated, even though TLBXI is expected. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1825311/+subscriptions
[Qemu-devel] [Bug 1574327] Re: qemu-system-x86_64 -net nic, model=help outputs to stderr instead of std
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1574327 Title: qemu-system-x86_64 -net nic,model=help outputs to stderr instead of std Status in QEMU: Fix Released Bug description: qemu-system-x86_64 -net nic,model=help output comes to stderr instead of std qemu-system-x86_64 -net nic,model=help -> stdout qemu-system-x86_64 -machine help -> stdout qemu-system-x86_64 -cpu help -> stdout as of https://github.com/qemu/qemu/blob/044d65525f6ac2093042ae18dbf8c1300b5c1c18/net/net.c#L831 I run qemu 2.5 on x86_64 kind regards To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1574327/+subscriptions
[Qemu-devel] [Bug 1701835] Re: floating-point operation bugs in qemu-alpha
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=21ba856499f9c0ccdc ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1701835 Title: floating-point operation bugs in qemu-alpha Status in QEMU: Fix Released Bug description: When running the gnulib testsuite, I'm seeing test failures in the tests for libm functions cbrt cbrtf ceil ceilf coshf exp2 exp2f floor floorf fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf isnan isnand isnanf ldexp ldexpf ldexpl log1p log1pf log2 log2f logb logbf logbl rint rintf rintl signbit sqrt sqrtf strtod that I don't see when running the same (statically linked) executables in a VM, through qemu-system-alpha. How to reproduce: - Using gnulib, run ./gnulib-tool --create-testdir --dir=../testdir-math --single-configure cbrt cbrtf ceil ceilf coshf exp2 exp2f float floor floorf fma fmaf fmal frexp frexpf hypot hypotf hypotl ilogb ilogbf isfinite isinf isnan isnand isnanf ldexp ldexpf ldexpl log1p log1pf log2 log2f logb logbf logbl math printf-frexp rint rintf rintl round roundf signbit sqrt sqrtf strtod trunc truncf - Copy the resulting directory to a VM running Linux 2.6.26 with qemu-system-alpha. - There, configure and build the package: mkdir build-native-static; cd build-native-static; ../configure CPPFLAGS="-Wall" LDFLAGS="-static"; make; make check Only 4 tests fail. - Copy the resulting binaries back to the original x86_64 machine. - Set environment variables for using qemu-alpha. - Here, 50 tests fail that did not fail originally: $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-cbrt ../../gltests/test-cbrt.h:39: assertion 'err > - L_(4.0) * L_(16.0) / TWO_MANT_DIG && err < L_(4.0) * L_(16.0) / TWO_MANT_DIG' failed Aborted (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil1 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceil2 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf1 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ceilf2 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-coshf ../../gltests/test-coshf.c:37: assertion 'y >= 1.1854652f && y <= 1.1854653f' failed Aborted (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-float Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor1 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floor2 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf1 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-floorf2 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma1 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fma2 ../../gltests/test-fma2.h:116: assertion 'result == expected' failed Aborted (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf1 Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmaf2 ../../gltests/test-fma2.h:116: assertion 'result == expected' failed Aborted (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-fmal2 ../../gltests/test-fma2.h:116: assertion 'result == expected' failed Aborted (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexp Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-frexpf Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypot Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotf Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-hypotl ../../gltests/test-hypot.h:41: assertion 'z == HUGEVAL' failed Aborted (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogb Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-ilogbf Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isfinite Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isinf Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnan Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand-nolibm Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnand Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf-nolibm Floating point exception (core dumped) $ ~/inst-qemu/2.9.0/bin/qemu-alpha test-isnanf Floating point exception (core
[Qemu-devel] [Bug 1696773] Re: golang calls to exec crash user emulation
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1696773 Title: golang calls to exec crash user emulation Status in QEMU: Fix Released Bug description: An example program can be found here: https://github.com/willnewton/qemucrash This code starts a goroutine (thread) and calls exec repeatedly. This works ok natively but when run under ARM user emulation it segfaults (usually, there are occasionally other failures). To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1696773/+subscriptions
[Qemu-devel] [Bug 1823998] Re: qemu-system-aarch64: support kernels bigger than 128MiB
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5e6dbe1e8cbbe4b6f74 ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1823998 Title: qemu-system-aarch64: support kernels bigger than 128MiB Status in QEMU: Fix Released Bug description: Presently QEMU reserves up to 128MiB of space for an arm64 Linux kernel, placing the initrd following this, and the dtb following the initrd. This is not sufficient for some debug configurations of the kernel, which can be larger than 128MiB. Depending on the relative size of the kernel Image and unpopulated BSS, the dtb (or kernel) will be clobbered by the other, resulting in a silent boot failure. Since v3.17, the kernel Image header exposes a field called image_size, which describes the entire size of the kernel (including unpopulated sections such as the BSS) as a 64-bit little-endian value. For kernels prior to v3.17, this field is zero. This is documented at: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt?h=v5.0#n68 It would be great if QEMU could take the image_size field into account when placing the initrd and dtb to avoid overlap with the kernel. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1823998/+subscriptions
[Qemu-devel] [Bug 1824853] Re: 4.0.0-rc3 crashes with tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] == off' failed
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1824853
Title:
4.0.0-rc3 crashes with tcg/tcg.c:3952: tcg_gen_code: Assertion
`s->gen_insn_end_off[num_insns] == off' failed
Status in QEMU:
Fix Released
Bug description:
I tried to bootstrap and regtested gcc trunk (gcc svn rev 270278,
datestamp 20190411) inside my arm64-gentoo installation under qemu-
system-aarch64.
Qemu version was 4.0.0-rc3 and -cpu cortex-a57. Qemu configured with
only --target-list=aarch64-softmmu,aarch64-linux-user and compiled
using gcc "version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1~16.04)".
Executable created from gcc/testsuite/gcc.target/aarch64/advsimd-
intrinsics/vldX.c compiled with -O2 crashed the whole qemu-system.
To investigate a bit I also manually run
~/gcc/inst/trunk/bin/gcc
~/gcc/src/trunk/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/vldX.c
with different options like:
-O0 -lm -o d0.exe
-O1 -lm -o d1.exe
-O2 -lm -o d2.exe
-O0 -static -lm -o s0.exe
-O1 -static -lm -o s1.exe
-O2 -static -lm -o s2.exe
So, now I have 6 different arm64 executables created with different
optimization levels. O0 and O1 versions run ok.
Three sN.exe static executables I've also tried in qemu user mode (with same
-cpu), no issue in user mode.
And inside qemu-system I can see that
running "d2.exe" (attached) gives:
tcg/tcg.c:3952: tcg_gen_code: Assertion `s->gen_insn_end_off[num_insns] ==
off' failed.
And running "s2.exe" gives:
tcg/tcg.c:320: set_jmp_reset_offset: Assertion `s->tb_jmp_reset_offset[which]
== off' failed.
It seems like this test is an counter-example for logic that
"tcg_ctx->nb_ops < 4000" implies tcg will fit into 16-bit signed size
(see tcg_op_buf_full comments).
Richard's changes in abebf92597186 and 9f754620651d were not enough,
translation block must be smaller, or we have to find some proper way to bail
out when buffer overflows.
I don't know why this situation is not caught by code_gen_highwater logic in
tcg.c
I've also tried this "bail out" patch
diff --git a/tcg/tcg.c b/tcg/tcg.c
--- a/tcg/tcg.c
+++ b/tcg/tcg.c
@@ -3949,7 +3949,8 @@ int tcg_gen_code(TCGContext *s, TranslationBlock *tb)
size_t off = tcg_current_code_size(s);
s->gen_insn_end_off[num_insns] = off;
/* Assert that we do not overflow our stored offset. */
-assert(s->gen_insn_end_off[num_insns] == off);
+if (s->gen_insn_end_off[num_insns] != off)
+ return -1;
}
num_insns++;
for (i = 0; i < TARGET_INSN_START_WORDS; ++i) {
But then running "d2.exe" just hangs the whole qemu-system. It seems
that when tcg_gen_code return -1 (like in highwater logic mentioned
before), we just re-call it again and again.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1824853/+subscriptions
[Qemu-devel] [Bug 1581976] Re: man qemu contains a bug in description of "-virtfs" command line argument
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1581976 Title: man qemu contains a bug in description of "-virtfs" command line argument Status in QEMU: Fix Released Bug description: The description of command line argument https://github.com/qemu/qemu/blob/63d3145aadbecaa7e8be1e74b5d6b5cbbeb4e153/qemu-options.hx#L796-L799 looks like this: -virtfs fsdriver[,path=path],mount_tag=mount_tag[,security_model=security_model][,writeout=writeout][,readonly][,socket=socket|sock_fd=sock_fd] note, that there is no "id" attribute in the list of parameters. later on the man there the "id" attribute is documented, as it were present: id=id Specifies identifier for this device i think that it was copied from above section (about "-fsdev") without reviewing. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1581976/+subscriptions
[Qemu-devel] [Bug 1830864] Re: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu); isar_feature_arm_div(_->isar); })' failed
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=8f4821d77e465bc
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1830864
Title:
Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu);
isar_feature_arm_div(_->isar); })' failed
Status in QEMU:
Fix Released
Bug description:
The following assertion:
assert(no_aa32 || cpu_isar_feature(arm_div, cpu));
introduced in commit 0f8d06f16c9d ("target/arm: Conditionalize some
asserts on aarch32 support", 2018-11-02), fails for me. I intended to
launch a 32-bit ARM guest (with KVM acceleration) on my AArch64 host
(APM Mustang A3).
Libvirt generated the following QEMU command line:
> LC_ALL=C \
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin \
> QEMU_AUDIO_DRV=none \
> /opt/qemu-installed-optimized/bin/qemu-system-aarch64 \
> -name guest=f28.32bit,debug-threads=on \
> -S \
> -object
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-f28.32bit/master-key.aes
\
> -machine virt-4.1,accel=kvm,usb=off,dump-guest-core=off,gic-version=2 \
> -cpu host,aarch64=off \
> -drive
file=/root/QEMU_EFI.fd.padded,if=pflash,format=raw,unit=0,readonly=on \
> -drive
file=/var/lib/libvirt/qemu/nvram/f28.32bit_VARS.fd,if=pflash,format=raw,unit=1 \
> -m 8192 \
> -realtime mlock=off \
> -smp 8,sockets=8,cores=1,threads=1 \
> -uuid d525042e-1b37-4058-86ca-c6a2086e8485 \
> -no-user-config \
> -nodefaults \
> -chardev socket,id=charmonitor,fd=27,server,nowait \
> -mon chardev=charmonitor,id=monitor,mode=control \
> -rtc base=utc \
> -no-shutdown \
> -boot strict=on \
> -device
pcie-root-port,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1
\
> -device
pcie-root-port,port=0x9,chassis=2,id=pci.2,bus=pcie.0,addr=0x1.0x1 \
> -device
pcie-root-port,port=0xa,chassis=3,id=pci.3,bus=pcie.0,addr=0x1.0x2 \
> -device
pcie-root-port,port=0xb,chassis=4,id=pci.4,bus=pcie.0,addr=0x1.0x3 \
> -device
pcie-root-port,port=0xc,chassis=5,id=pci.5,bus=pcie.0,addr=0x1.0x4 \
> -device
pcie-root-port,port=0xd,chassis=6,id=pci.6,bus=pcie.0,addr=0x1.0x5 \
> -device qemu-xhci,id=usb,bus=pci.1,addr=0x0 \
> -device virtio-scsi-pci,id=scsi0,bus=pci.2,addr=0x0 \
> -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
> -drive
file=/var/lib/libvirt/images/f28.32bit.root.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,werror=enospc,cache=writeback,discard=unmap
\
> -device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1,write-cache=on
\
> -drive
file=/var/lib/libvirt/images/f28.32bit.home.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-1,werror=enospc,cache=writeback,discard=unmap
\
> -device
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,write-cache=on
\
> -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 \
> -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:6f:d1:c8,bus=pci.4,addr=0x0,romfile=
\
> -chardev pty,id=charserial0 \
> -serial chardev:charserial0 \
> -chardev socket,id=charchannel0,fd=31,server,nowait \
> -device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
\
> -device usb-tablet,id=input0,bus=usb.0,port=1 \
> -device usb-kbd,id=input1,bus=usb.0,port=2 \
> -vnc 127.0.0.1:0 \
> -device virtio-gpu-pci,id=video0,max_outputs=1,bus=pci.5,addr=0x0 \
> -object rng-random,id=objrng0,filename=/dev/urandom \
> -device
virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1048576,period=1000,bus=pci.6,addr=0x0
\
> -msg timestamp=on
and then I got:
> qemu-system-aarch64: /root/src/upstream/qemu/target/arm/cpu.c:986:
> arm_cpu_realizefn: Assertion `no_aa32 || ({ ARMCPU *cpu_ = (cpu);
> isar_feature_arm_div(_->isar); })' failed.
QEMU was built at commit 8dc7fd56dd4f ("Merge remote-tracking branch
'remotes/philmd-gitlab/tags/fw_cfg-20190523-pull-request' into staging",
2019-05-23).
(Originally reported on the mailing list in the following thread:
.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1830864/+subscriptions
[Qemu-devel] [Bug 1821884] Re: Extend uefi-test-tools to report SMBIOS location
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1821884 Title: Extend uefi-test-tools to report SMBIOS location Status in QEMU: Fix Released Bug description: UEFI helper app exposes the pointer to RSDP ACPI table that firmware allocates in guest's RAM but it doesn't do so for SMBIOS tables. Hence bios table test would skip testing SMBIOS tables to workaround shortcoming. This bug is a request to expose two new entry point fields (one for SMBIOS 2 and another for SMBIOS 3) so test could check SMBIOS tables when guest is started a with UEFI firmware. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1821884/+subscriptions
[Qemu-devel] [Bug 1838277] Re: qemu-system-aarch64: regression in 3.1: breakpoint instructions always routed to EL_D even when current EL is higher
Fix included here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=987a23224218fa3bb ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838277 Title: qemu-system-aarch64: regression in 3.1: breakpoint instructions always routed to EL_D even when current EL is higher Status in QEMU: Fix Released Bug description: Affects 3.1.0 (latest stable release) and latest commit (893dc8300c80e3dc32f31e968cf7aa0904da50c3) but did *not* affect 2.11 (qemu from bionic ubuntu LTS). With the following code and shell commands: test.s: .text mov x0, #0x6000 msr vbar_el2, x0 dsb sy isb sy $ aarch64-none-elf-as test.s -o test.o $ aarch64-none-elf-objcopy -S -O binary test.o test.bin $ qemu-system-aarch64 -nographic -machine virt,virtualization=on -cpu cortex-a57 -kernel test.bin -s -S vbar_el2 is still 0 after the code, instead of being the expected 0x6000. (see screenshot). This regression doesn't seem to happen for vbar_el1 & virtualization=off. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838277/+subscriptions
[Qemu-devel] [Bug 1825002] Re: "qemu: Unexpected FPU mode" since 0c1bbedc10e86ea9366b6af8c5520fafa3266b2f
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1825002 Title: "qemu: Unexpected FPU mode" since 0c1bbedc10e86ea9366b6af8c5520fafa3266b2f Status in QEMU: Fix Released Bug description: This happens every time I attempt to chroot into a gentoo-mips image unless I load the executable via ld.so /home (root)# chroot gentoo-mips32r2el /bin/sh qemu: Unexpected FPU mode /home (root)# chroot gentoo-mips32r2el /lib/ld-2.19.so /bin/sh sh-4.2# exit /home (root)# I don't know the underlying cause, but keep in mind that we may lie and claim to have an FPU when our CPU doesn't because of kernel emulation that may not be present in the host kernel. Don't know if that's related. I get this with various gentoo-mips stage3 tarballs, but not with OpenWRT. (e.g., https://gentoo.osuosl.org/experimental/mips/stages/mips32r2el/2014) # emerge --info app-emulation/qemu Portage 2.3.51 (python 3.6.5-final-0, default/linux/amd64/17.0/desktop/plasma, gcc-8.2.0, glibc-2.27-r6, 4.14.96-gentoo x86_64) = System Settings = System uname: Linux-4.14.96-gentoo-x86_64-AMD_Ryzen_7_2700X_Eight-Core_Processor-with-gentoo-2.6 KiB Mem:32890732 total, 3480024 free KiB Swap: 16777212 total, 10575592 free Timestamp of repository gentoo: Thu, 11 Apr 2019 06:00:01 + Head commit of repository gentoo: 66eaaa28926103e690db0699466a274a17ab1979 sh bash 4.4_p23-r1 ld GNU ld (Gentoo 2.30 p5) 2.30.0 distcc 3.3.2 x86_64-pc-linux-gnu [disabled] ccache version 3.3.4 [disabled] app-shells/bash: 4.4_p23-r1::gentoo dev-java/java-config: 2.2.0-r4::gentoo dev-lang/perl:5.26.2::gentoo dev-lang/python: 2.7.15::gentoo, 3.6.5::gentoo dev-util/ccache: 3.3.4-r1::gentoo dev-util/cmake: 3.9.6::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.38.3-r1::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.64-r1::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.11.6-r3::gentoo, 1.13.4-r2::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo sys-devel/binutils: 2.30-r4::gentoo sys-devel/gcc:4.9.4::gentoo, 5.4.0-r6::gentoo, 6.4.0-r5::gentoo, 7.3.0-r6::gentoo, 8.1.0-r3::gentoo, 8.2.0-r6::gentoo, 8.3.0::gentoo sys-devel/gcc-config: 2.0::gentoo sys-devel/libtool:2.4.6-r3::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers) sys-libs/glibc: 2.27-r6::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 sync-rsync-verify-jobs: 1 sync-rsync-extra-opts: sync-rsync-verify-metamanifest: yes sync-rsync-verify-max-age: 24 love-local location: /usr/local/portage masters: gentoo priority: 0 chaoslab location: /var/lib/layman/chaoslab masters: gentoo priority: 50 java location: /var/lib/layman/java masters: gentoo priority: 50 steam-overlay location: /var/lib/layman/steam-overlay masters: gentoo priority: 50 zugaina location: /var/lib/layman/zugaina masters: gentoo priority: 50 ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -ggdb3 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -ggdb3 -pipe" DISTDIR="/mnt/large/distfiles" EMERGE_DEFAULT_OPTS="-j3 --load-average=17.5 --with-bdeps=y --autounmask=n" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildpkg candy cgroup compress-build-logs compressdebug config-protect-if-modified distlocks ebuild-locks fixlafiles installsources ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch preserve-libs protect-owned sandbox sfperms split-elog split-log splitdebug strict strict-keepdir unknown-features-warn unmerge-logs unmerge-orphans
[Qemu-devel] [Bug 1831477] Re: update edk2 submodule & binaries to edk2-stable201905
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1831477 Title: update edk2 submodule & binaries to edk2-stable201905 Status in QEMU: Fix Released Bug description: The edk2 project will soon release edk2-stable201905. Update the edk2 submodule in QEMU, and the bundled edk2 binaries, accordingly. https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201905-tag-planning https://github.com/tianocore/edk2/releases/tag/edk2-stable201905 [upcoming link] To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1831477/+subscriptions
[Qemu-devel] [Bug 1838475] Re: qemu-system-arm exits when cortex-m4 floating point used and irq occurs
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=02ac2f7f613b47f6a5b3 ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838475 Title: qemu-system-arm exits when cortex-m4 floating point used and irq occurs Status in QEMU: Fix Released Bug description: qemu-system-arm exits with "...Secure UsageFault with CFSR.NOCP because NSACR.CP10 prevents stacking FP regs ...taking pending nonsecure exception 3 Taking exception 7 [Breakpoint] qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)" when emulating Cortex-m4, executing at least 1 floating point instruction, and then an irq (e.g. sys tick) occurring. CPACR.CP10 and CPACR.CP11 are set to 0x3 respectively prior to executing the fp instructions. NOTE: NSACR does not appear to be a cortex m4 register. Attached is a simplified elf to repro the issue. The qemu command line is: "qemu-system-arm --gdb tcp::1234 -cpu cortex-m4 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel QemuExitWhenUsingFPAndIRQOccurs.elf -d int" To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838475/+subscriptions
[Qemu-devel] [Bug 1825359] Re: cpu_ld*_code() triggers MMU_DATA_LOAD i.s.o. MMU_INST_FETCH
** Changed in: qemu
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1825359
Title:
cpu_ld*_code() triggers MMU_DATA_LOAD i.s.o. MMU_INST_FETCH
Status in QEMU:
Fix Released
Bug description:
commit 377b155bde451d5ac545fbdcdfbf6ca17a4228f5
Merge: c876180938 328eb60dc1
Author: Peter Maydell ; masked for anti-spamming purposes
Date: Mon Mar 11 18:26:37 2019 +
https://github.com/qemu/qemu/commit/377b155bde451d5ac545fbdcdfbf6ca17a4228f5
--
cpu_ld*_code() is used for loading code data as the name suggests. Although,
it begins accessing memory with MMU_INST_FETCH access type, somewhere down
the road, when the "io_readx(..., access_type=MMU_INST_FETCH, ...)" is
called, it is ignoring this "access_type" while calling the "tlb_fill()"
with a _hardcoded_ MMU_DATA_LOAD:
cputlb.c
static uint64_t io_readx(..., MMUAccessType access_type, ...)
{
if (recheck) {
CPUTLBEntry *entry;
target_ulong tlb_addr;
tlb_fill(cpu, addr, size, MMU_DATA_LOAD, mmu_idx, retaddr);
...
}
This is an issue, because there can exist _small_ regions of memory (smaller
than the TARGET_PAGE_SIZE) that are only executable and not readable.
TL;DR
What happens is at first, a "tlb_fill(..., access_type=MMU_INST_FETCH, ...)"
is triggered by "tb_lookup_cpu_state()". To be precise, this is the call
stack which is good behavior:
---
#0 tlb_fill (cs=..., vaddr=684, size=0, access_type=MMU_INST_FETCH,
mmu_idx=0, retaddr=0) at target/arc/mmu.c:602
#1 get_page_addr_code (env=..., addr=684) at accel/tcg/cputlb.c:1045
#2 tb_htable_lookup (cpu=..., pc=684, cs_base=0, flags=0,
cf_mask=4278190080) at accel/tcg/cpu-exec.c:337
#3 tb_lookup__cpu_state (cpu=..., pc=..., cs_base=..., flags=...,
cf_mask=4278190080) at include/exec/tb-lookup.h:43
#4 tb_find (cpu=..., last_tb=... , tb_exit=0,
cf_mask=0) at accel/tcg/cpu-exec.c:404
#5 cpu_exec (cpu=...) at accel/tcg/cpu-exec.c:729
#6 tcg_cpu_exec (cpu=...) at cpus.c:1430
#7 qemu_tcg_rr_cpu_thread_fn (arg=...) at cpus.c:1531
#8 qemu_thread_start (args=...) at util/qemu-thread-posix.c:502
---
After this call, TLB is filled with an entry that its size field is small,
say 32 bytes. This causes a TLB_RECHECK for consequent memory accesses, which
is logical. However, in our decoder, we use cpu_lduw_code() to read the
instructions and decode them. As mentioned, in the beginning, the
access_type=MMU_INST_FETCH is lost in "io_readx()" while calling tlb_fill()",
and now THIS CAUSES A GUEST EXCEPTION BECAUSE THAT REGION IS NOT ALLOWED TO
BE READ. Here, comes that trace call of the _bad_ behavior:
---
#0 tlb_fill (..., access_type=MMU_DATA_LOAD, ...) at target/arc/mmu.c:605
#1 io_readx (..., access_type=MMU_INST_FETCH, size=2) at
accel/tcg/cputlb.c:881
#2 io_readw (..., access_type=MMU_INST_FETCH) at
accel/tcg/softmmu_template.h:106
#3 helper_le_ldw_cmmu (..., oi=16, retaddr=0) at
accel/tcg/softmmu_template.h:146
#4 cpu_lduw_code_ra (env=..., ptr=684, retaddr=0) at
include/exec/cpu_ldst_template.h:102
#5 cpu_lduw_code (env=..., ptr=684) at include/exec/cpu_ldst_template.h:114
#6 read_and_decode_context (ctx=..., opcode_p=...) at
target/arc/arc-decoder.c:1479
#7 arc_decode (ctx=...) at target/arc/arc-decoder.c:1736
#8 decode_opc (env=..., ctx=...) at target/arc/translate.c:313
#9 arc_tr_translate_insn (dcbase=..., cpu=...) at target/arc/translate.c:335
#10 translator_loop (.. ) at accel/tcg/translator.c:107
#11 gen_intermediate_code (cpu=..., tb=... ) at
target/arc/translate.c:413
#12 tb_gen_code (cpu=..., pc=684, cs_base=0, flags=0, cflags=-16711679) at
accel/tcg/translate-all.c:1723
#13 tb_find (cpu=..., last_tb=... , tb_exit=0,
cf_mask=0) at accel/tcg/cpu-exec.c:407
#14 cpu_exec (cpu=...) at accel/tcg/cpu-exec.c:729
#15 tcg_cpu_exec (cpu=...) at cpus.c:1430
---
Do you confirm if this is an issue? Maybe there are other ways to read
an instruction with MMU_INST_FETCH access that I don't know about.
Last but not least, although this is not a security issue for QEMU per
se, but it is hindering a security feature for the guest.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1825359/+subscriptions
[Qemu-devel] [Bug 1838703] Re: Makefile BUG in edk2 firmware install 4.1.0-rc3
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1838703 Title: Makefile BUG in edk2 firmware install 4.1.0-rc3 Status in QEMU: Fix Released Bug description: DESTDIR installs end up with wrong paths in JSON files installed to $prefix/share/qemu/firmware. For example, the file: 50-edk2-x86_64-secure.json ends up incorrectly with: "filename": "/build/qemu/pkg/qemu/usr/share/qemu/edk2-x86_64-secure- code.fd", instead of the correct: "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd", To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1838703/+subscriptions
[Qemu-devel] [Bug 1834496] Re: Regressions on arm target with some GCC tests
** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1834496 Title: Regressions on arm target with some GCC tests Status in QEMU: Fix Released Bug description: Hi, After trying qemu master: commit 474f3938d79ab36b9231c9ad3b5a9314c2aeacde Merge: 68d7ff0 14f5d87 Author: Peter Maydell Date: Fri Jun 21 15:40:50 2019 +0100 I found several regressions compared to qemu-3.1 when running the GCC testsuite. I'm attaching a tarball containing several GCC tests (binaries), needed shared libs, and a short script to run all the tests. All tests used to pass w/o error (one of them is verbose), but with a recent qemu, all of them make qemu crash: qemu: uncaught target signal 6 (Aborted) - core dumped This was noticed with GCC master configured with --target arm-none-linux-gnueabi --with-mode arm --with-cpu cortex-a9 and calling qemu with --cpu cortex-a9 (the script uses "any", this makes no difference). I have noticed other failures with arm-v8 code, but this is probably the same root cause. Since it's a bit tedious to manually rebuild & extract the testcases, I'd prefer to start with this subset, and I can extract more if needed later. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1834496/+subscriptions
[Qemu-devel] [PATCH] isa/pc87312: use device_class_set_parent_realize
Signed-off-by: Mao Zhongyi --- hw/isa/pc87312.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/isa/pc87312.c b/hw/isa/pc87312.c index 85dbc94439..e95176c148 100644 --- a/hw/isa/pc87312.c +++ b/hw/isa/pc87312.c @@ -336,8 +336,8 @@ static void pc87312_class_init(ObjectClass *klass, void *data) DeviceClass *dc = DEVICE_CLASS(klass); ISASuperIOClass *sc = ISA_SUPERIO_CLASS(klass); -sc->parent_realize = dc->realize; -dc->realize = pc87312_realize; +device_class_set_parent_realize(dc, pc87312_realize, +>parent_realize); dc->reset = pc87312_reset; dc->vmsd = _pc87312; dc->props = pc87312_properties; -- 2.17.1
Re: [Qemu-devel] [PATCH for-4.2 v10 07/15] virtio-iommu: Implement attach/detach command
On Tue, Jul 30, 2019 at 07:21:29PM +0200, Eric Auger wrote:
> This patch implements the endpoint attach/detach to/from
> a domain.
>
> Signed-off-by: Eric Auger
>
> ---
> ---
> hw/virtio/virtio-iommu.c | 40 ++--
> 1 file changed, 34 insertions(+), 6 deletions(-)
>
> diff --git a/hw/virtio/virtio-iommu.c b/hw/virtio/virtio-iommu.c
> index 77dccecc0a..5ea0930cc2 100644
> --- a/hw/virtio/virtio-iommu.c
> +++ b/hw/virtio/virtio-iommu.c
> @@ -80,8 +80,8 @@ static void
> virtio_iommu_detach_endpoint_from_domain(viommu_endpoint *ep)
> ep->domain = NULL;
> }
>
> -viommu_endpoint *virtio_iommu_get_endpoint(VirtIOIOMMU *s, uint32_t ep_id);
> -viommu_endpoint *virtio_iommu_get_endpoint(VirtIOIOMMU *s, uint32_t ep_id)
These lines were just introduced in previous patch, I wanted to ask
why the definition was needed but I don't know whether it'll be used
in follow up patches. Looks like it wasn't really used.
I would prefer patches like these to be squashed together not only to
avoid the maintainance of diffs like this between patches, but also as
a reviewer it'll be easier too when with all the contexts together.
But I won't ask for it because it can be a personal preference only...
> +static viommu_endpoint *virtio_iommu_get_endpoint(VirtIOIOMMU *s,
> + uint32_t ep_id)
> {
> viommu_endpoint *ep;
>
> @@ -110,8 +110,8 @@ static void virtio_iommu_put_endpoint(gpointer data)
> g_free(ep);
> }
>
> -viommu_domain *virtio_iommu_get_domain(VirtIOIOMMU *s, uint32_t domain_id);
> -viommu_domain *virtio_iommu_get_domain(VirtIOIOMMU *s, uint32_t domain_id)
> +static viommu_domain *virtio_iommu_get_domain(VirtIOIOMMU *s,
> + uint32_t domain_id)
> {
> viommu_domain *domain;
>
> @@ -187,10 +187,27 @@ static int virtio_iommu_attach(VirtIOIOMMU *s,
> {
> uint32_t domain_id = le32_to_cpu(req->domain);
> uint32_t ep_id = le32_to_cpu(req->endpoint);
> +viommu_domain *domain;
> +viommu_endpoint *ep;
>
> trace_virtio_iommu_attach(domain_id, ep_id);
>
> -return VIRTIO_IOMMU_S_UNSUPP;
> +ep = virtio_iommu_get_endpoint(s, ep_id);
> +if (ep->domain) {
> +/*
> + * the device is already attached to a domain,
> + * detach it first
> + */
> +virtio_iommu_detach_endpoint_from_domain(ep);
Hmm... so this can be called without virtio_iommu_put_endpoint().
Then I think we'd better move:
g_tree_unref(ep->domain->mappings);
>From virtio_iommu_put_endpoint() to inside
virtio_iommu_detach_endpoint_from_domain() otherwise domain refs might
leak?
> +}
> +
> +domain = virtio_iommu_get_domain(s, domain_id);
> +QLIST_INSERT_HEAD(>endpoint_list, ep, next);
> +
> +ep->domain = domain;
> +g_tree_ref(domain->mappings);
> +
> +return VIRTIO_IOMMU_S_OK;
> }
Regards,
--
Peter Xu
Re: [Qemu-devel] [PATCH for-4.2 v10 06/15] virtio-iommu: Endpoint and domains structs and helpers
On Tue, Jul 30, 2019 at 07:21:28PM +0200, Eric Auger wrote:
> static void virtio_iommu_device_realize(DeviceState *dev, Error **errp)
> {
> VirtIODevice *vdev = VIRTIO_DEVICE(dev);
> @@ -334,6 +444,8 @@ static void virtio_iommu_device_realize(DeviceState *dev,
> Error **errp)
> virtio_add_feature(>features, VIRTIO_IOMMU_F_BYPASS);
> virtio_add_feature(>features, VIRTIO_IOMMU_F_MMIO);
>
> +qemu_mutex_init(>mutex);
It's a bit strange to init a mutex which has already been used in
patch 3. :)
Thanks,
> +
> memset(s->as_by_bus_num, 0, sizeof(s->as_by_bus_num));
> s->as_by_busptr = g_hash_table_new(NULL, NULL);
>
> @@ -342,11 +454,20 @@ static void virtio_iommu_device_realize(DeviceState
> *dev, Error **errp)
> } else {
> error_setg(errp, "VIRTIO-IOMMU is not attached to any PCI bus!");
> }
> +
> +s->domains = g_tree_new_full((GCompareDataFunc)int_cmp,
> + NULL, NULL, virtio_iommu_put_domain);
> +s->endpoints = g_tree_new_full((GCompareDataFunc)int_cmp,
> + NULL, NULL, virtio_iommu_put_endpoint);
> }
--
Peter Xu
Re: [Qemu-devel] [PATCH for-4.2 v10 05/15] virtio-iommu: Add the iommu regions
On Tue, Jul 30, 2019 at 07:21:27PM +0200, Eric Auger wrote:
[...]
> static void virtio_iommu_get_config(VirtIODevice *vdev, uint8_t *config_data)
> {
> VirtIOIOMMU *dev = VIRTIO_IOMMU(vdev);
> @@ -266,6 +333,15 @@ static void virtio_iommu_device_realize(DeviceState
> *dev, Error **errp)
> virtio_add_feature(>features, VIRTIO_IOMMU_F_MAP_UNMAP);
> virtio_add_feature(>features, VIRTIO_IOMMU_F_BYPASS);
> virtio_add_feature(>features, VIRTIO_IOMMU_F_MMIO);
> +
> +memset(s->as_by_bus_num, 0, sizeof(s->as_by_bus_num));
> +s->as_by_busptr = g_hash_table_new(NULL, NULL);
VT-d was using g_hash_table_new_full() so that potentially VTDBus can
still be freed. Here for IOMMUPCIBus allocated in
virtio_iommu_find_add_as() I think it'll be leaked if we remove
entries in the hash table?
So I started to wonder whether PCI/PCIe buses are allowed to be
plugged/unplugged after all because I never tried. With latest
5.3.0-rc4 guest I gave it a shot and I see the error below. It could
be something that I did wrong or it could be simply that it's not
working at all. Have you tried anything like that? Michael/Alex?
bin=x86_64-softmmu/qemu-system-x86_64
$bin -M q35,accel=kvm,kernel-irqchip=on -smp 8 -m 2G -cpu host \
-monitor telnet::,server,nowait -nographic \
-device e1000,netdev=net0 \
-netdev user,id=net0,hostfwd=tcp::-:22 \
-device pcie-pci-bridge,bus=pcie.0,id=pci.1 \
-drive file=/images/default.qcow2,if=none,cache=none,id=drive0 \
-device virtio-blk,drive=drive0
(qemu) device_add pci-bridge,bus=pci.1,id=pci.2,chassis_nr=1,addr=1.0
[ 66.172352] pci :01:01.0: [1b36:0001] type 01 class 0x060400
[ 66.176897] pci :01:01.0: reg 0x10: [mem 0x-0x00ff 64bit]
[ 66.186130] pci :01:01.0: No bus number available for hot-added bridge
[ 66.189489] shpchp :00:03.0: BAR 14: assigned [mem 0x8000-0x800f]
[ 66.193235] pci :01:01.0: BAR 0: assigned [mem 0x8000-0x80ff
64bit]
[ 66.198587] shpchp :00:03.0: PCI bridge to [bus 01]
[ 66.204113] shpchp :00:03.0: bridge window [mem 0x8000-0x800f]
[ 66.215212] shpchp :01:01.0: HPC vendor_id 1b36 device_id 1 ss_vid 0
ss_did 0
[ 66.218531] shpchp :01:01.0: enabling device ( -> 0002)
[ 66.229204] BUG: kernel NULL pointer dereference, address: 00e2
[ 66.232124] #PF: supervisor write access in kernel mode
[ 66.234369] #PF: error_code(0x0002) - not-present page
[ 66.236585] PGD 0 P4D 0
[ 66.237431] Oops: 0002 [#1] SMP PTI
[ 66.238617] CPU: 2 PID: 277 Comm: kworker/2:1 Kdump: loaded Not tainted
5.3.0-rc4 #85
[ 66.241200] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 66.244916] Workqueue: shpchp-1 shpchp_pushbutton_thread
[ 66.246583] RIP: 0010:shpc_init.cold+0x5c3/0x8a1
[ 66.248041] Code: 24 90 01 00 00 8b 49 08 40 80 fe 02 0f 85 f4 01 00 00 f7
c1 00 00 00 f0 0f 84 b2 01 00 00 b9 13 00 00 00 80 3d 33 40 38 02 00 <88> 8a e26
[ 66.253771] RSP: 0018:c925bb68 EFLAGS: 00010246
[ 66.255418] RAX: 00ff RBX: RCX:
[ 66.257763] RDX: RSI: 826bcd01 RDI: 826bcd60
[ 66.260065] RBP: R08: 0001 R09:
[ 66.263184] R10: 0005 R11: R12: 888032425400
[ 66.265706] R13: c917109c R14: 888033da7000 R15: 001f
[ 66.268200] FS: () GS:88807fc8()
knlGS:
[ 66.270826] CS: 0010 DS: ES: CR0: 80050033
[ 66.272731] CR2: 00e2 CR3: 33afc002 CR4: 00360ee0
[ 66.275373] DR0: DR1: DR2:
[ 66.277947] DR3: DR6: fffe0ff0 DR7: 0400
[ 66.279965] Call Trace:
[ 66.280627] shpc_probe+0x91/0x32b
[ 66.281644] local_pci_probe+0x42/0x80
[ 66.282752] pci_device_probe+0x107/0x1a0
[ 66.283877] really_probe+0xf0/0x380
[ 66.284862] driver_probe_device+0x59/0xd0
[ 66.285988] ? driver_allows_async_probing+0x50/0x50
[ 66.287937] bus_for_each_drv+0x7e/0xc0
[ 66.289752] __device_attach+0xe1/0x160
[ 66.292076] pci_bus_add_device+0x4b/0x70
[ 66.295244] pci_bus_add_devices+0x2c/0x64
[ 66.297429] shpchp_configure_device+0xc1/0xe0
[ 66.299692] board_added+0x117/0x240
[ 66.301589] shpchp_enable_slot+0x121/0x2e0
[ 66.303686] shpchp_pushbutton_thread+0x70/0xa0
[ 66.305941] process_one_work+0x221/0x500
[ 66.308253] worker_thread+0x50/0x3b0
[ 66.310512] kthread+0xfb/0x130
[ 66.312422] ? process_one_work+0x500/0x500
[ 66.314617] ? kthread_park+0x80/0x80
[ 66.316489] ret_from_fork+0x3a/0x50
[ 66.318293] Modules linked in: intel_rapl_msr intel_rapl_common kvm_intel
kvm crct10dif_pclmul bochs_drm crc32_pclmul drm_vram_helper ghash_clmulni_intel
o
[
[Qemu-devel] RISCV: when will the CLIC be ready?
Hi, Palmer When Michael Clark still was the maintainer of RISCV QEMU, he wrote in the mail list, "the CLIC interrupt controller is under testing, and will be included in QEMU 3.1 or 3.2". It is pity that the CLIC is not in included even in QEMU 4.1.0. As we have cpus using CLIC, I have to use the out of tree qemu code in SIFIVE a long time. Could you tell me when it will be upstreamed? Best Regards Zhiwei
Re: [Qemu-devel] [edk2-devel] CPU hotplug using SMM with QEMU+OVMF
Comment below: > -Original Message- > From: Paolo Bonzini [mailto:pbonz...@redhat.com] > Sent: Friday, August 16, 2019 12:21 AM > To: Laszlo Ersek ; de...@edk2.groups.io; Yao, Jiewen > > Cc: edk2-rfc-groups-io ; qemu devel list > ; Igor Mammedov ; > Chen, Yingwen ; Nakajima, Jun > ; Boris Ostrovsky ; > Joao Marcal Lemos Martins ; Phillip Goerl > > Subject: Re: [edk2-devel] CPU hotplug using SMM with QEMU+OVMF > > On 15/08/19 17:00, Laszlo Ersek wrote: > > On 08/14/19 16:04, Paolo Bonzini wrote: > >> On 14/08/19 15:20, Yao, Jiewen wrote: > - Does this part require a new branch somewhere in the OVMF SEC > code? > How do we determine whether the CPU executing SEC is BSP or > hot-plugged AP? > >>> [Jiewen] I think this is blocked from hardware perspective, since the > >>> first > instruction. > >>> There are some hardware specific registers can be used to determine if > the CPU is new added. > >>> I don’t think this must be same as the real hardware. > >>> You are free to invent some registers in device model to be used in > OVMF hot plug driver. > >> > >> Yes, this would be a new operation mode for QEMU, that only applies to > >> hot-plugged CPUs. In this mode the AP doesn't reply to INIT or SMI, in > >> fact it doesn't reply to anything at all. > >> > - How do we tell the hot-plugged AP where to start execution? (I.e. > that > it should execute code at a particular pflash location.) > >>> [Jiewen] Same real mode reset vector at :FFF0. > >> > >> You do not need a reset vector or INIT/SIPI/SIPI sequence at all in > >> QEMU. The AP does not start execution at all when it is unplugged, so > >> no cache-as-RAM etc. > >> > >> We only need to modify QEMU so that hot-plugged APIs do not reply to > >> INIT/SIPI/SMI. > >> > >>> I don’t think there is problem for real hardware, who always has CAR. > >>> Can QEMU provide some CPU specific space, such as MMIO region? > >> > >> Why is a CPU-specific region needed if every other processor is in SMM > >> and thus trusted. > > > > I was going through the steps Jiewen and Yingwen recommended. > > > > In step (02), the new CPU is expected to set up RAM access. In step > > (03), the new CPU, executing code from flash, is expected to "send board > > message to tell host CPU (GPIO->SCI) -- I am waiting for hot-add > > message." For that action, the new CPU may need a stack (minimally if we > > want to use C function calls). > > > > Until step (03), there had been no word about any other (= pre-plugged) > > CPUs (more precisely, Jiewen even confirmed "No impact to other > > processors"), so I didn't assume that other CPUs had entered SMM. > > > > Paolo, I've attempted to read Jiewen's response, and yours, as carefully > > as I can. I'm still very confused. If you have a better understanding, > > could you please write up the 15-step process from the thread starter > > again, with all QEMU customizations applied? Such as, unnecessary steps > > removed, and platform specifics filled in. > > Sure. > > (01a) QEMU: create new CPU. The CPU already exists, but it does not > start running code until unparked by the CPU hotplug controller. > > (01b) QEMU: trigger SCI > > (02-03) no equivalent > > (04) Host CPU: (OS) execute GPE handler from DSDT > > (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU > will not enter CPU because SMI is disabled) > > (06) Host CPU: (SMM) Save 38000, Update 38000 -- fill simple SMM > rebase code. > > (07a) Host CPU: (SMM) Write to CPU hotplug controller to enable > new CPU > > (07b) Host CPU: (SMM) Send INIT/SIPI/SIPI to new CPU. [Jiewen] NOTE: INIT/SIPI/SIPI can be sent by a malicious CPU. There is no restriction that INIT/SIPI/SIPI can only be sent in SMM. > (08a) New CPU: (Low RAM) Enter protected mode. [Jiewen] NOTE: The new CPU still cannot use any physical memory, because the INIT/SIPI/SIPI may be sent by malicious CPU in non-SMM environment. > (08b) New CPU: (Flash) Signals host CPU to proceed and enter cli;hlt loop. > > (09) Host CPU: (SMM) Send SMI to the new CPU only. > > (10) New CPU: (SMM) Run SMM code at 38000, and rebase SMBASE to > TSEG. > > (11) Host CPU: (SMM) Restore 38000. > > (12) Host CPU: (SMM) Update located data structure to add the new CPU > information. (This step will involve CPU_SERVICE protocol) > > (13) New CPU: (Flash) do whatever other initialization is needed > > (14) New CPU: (Flash) Deadloop, and wait for INIT-SIPI-SIPI. > > (15) Host CPU: (OS) Send INIT-SIPI-SIPI to pull new CPU in.. > > > In other words, the cache-as-RAM phase of 02-03 is replaced by the > INIT-SIPI-SIPI sequence of 07b-08a-08b. [Jiewen] I am OK with this proposal. I think the rule is same - the new CPU CANNOT touch any system memory, no matter it is from reset-vector or from INIT/SIPI/SIPI. Or I would say: if the new CPU want to touch some memory before first SMI, the memory should be CPU specific or on the flash. > >> The
[Qemu-devel] [Bug 1814352] Re: SIOCGIFNAME takes a struct ifreq not an integer
Released as part of v4.1.0. ** Changed in: qemu Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1814352 Title: SIOCGIFNAME takes a struct ifreq not an integer Status in QEMU: Fix Released Bug description: The ioctl SIOCGIFNAME takes a pointer to a struct ifreq, not an integer. This leads to if_indextoname() not correctly returning interface names (well, not if they're longer than 4 characters including the trailing NULL ;-). This is observed on v3.1.0. The following one-line patch will be sent to the qemu-devel mailing list: """ diff --git a/linux-user/ioctls.h b/linux-user/ioctls.h index ae8951625f..37501f575c 100644 --- a/linux-user/ioctls.h +++ b/linux-user/ioctls.h @@ -178,7 +178,7 @@ #endif /* CONFIG_USBFS */ IOCTL(SIOCATMARK, IOC_R, MK_PTR(TYPE_INT)) - IOCTL(SIOCGIFNAME, IOC_RW, MK_PTR(TYPE_INT)) + IOCTL(SIOCGIFNAME, IOC_RW, MK_PTR(MK_STRUCT(STRUCT_int_ifreq))) IOCTL(SIOCGIFFLAGS, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_short_ifreq))) IOCTL(SIOCSIFFLAGS, IOC_W, MK_PTR(MK_STRUCT(STRUCT_short_ifreq))) IOCTL(SIOCGIFADDR, IOC_W | IOC_R, MK_PTR(MK_STRUCT(STRUCT_sockaddr_ifreq))) """ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1814352/+subscriptions
Re: [Qemu-devel] [PATCH for-4.2 02/13] qcow2: Keep unknown extra snapshot data
On 31.07.19 10:54, Max Reitz wrote:
> On 30.07.19 19:56, Eric Blake wrote:
>> On 7/30/19 12:24 PM, Max Reitz wrote:
[...]
>>> +if (sn->extra_data_size > sizeof(extra)) {
>>> +/* Store unknown extra data */
>>> +size_t unknown_extra_data_size =
>>> +sn->extra_data_size - sizeof(extra);
>>> +
>>> +sn->unknown_extra_data = g_malloc(unknown_extra_data_size);
>>> +ret = bdrv_pread(bs->file, offset, sn->unknown_extra_data,
>>> + unknown_extra_data_size);
>>
>> We're doing two separate bdrv_pread()s. Would it be better to do a
>> single bdrv_preadv into a vector composed of and
>> _extra_data, for less I/O? (Then again, this micro-optimization
>> is probably in the noise in the long run)
>
> Interesting idea, we could even add the ID and name string into that
> vector. But I’m not sure whether it’s really useful.
>
> (I’ll take a look anyway, because it sounds interesting.)
I did, and it was actually really nice. I liked it. (I don’t hink the
performance is important, but it was actually just simpler.)
But then it turned out that it won’t work with patch 8, because after
that we may want to skip parts of the unknown extra data – and skipping
doesn’t work with bdrv_preadv()...
(So all the simplicity is lost, and that’s what I was interested in.)
But it was indeed quite cool. :-/
Max
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 0/3] colo: Add support for continious replication
> -Original Message- > From: Lukas Straub [mailto:lukasstra...@web.de] > Sent: Friday, August 16, 2019 3:48 AM > To: Dr. David Alan Gilbert > Cc: qemu-devel ; Zhang, Chen > ; Jason Wang ; Xie > Changlong ; Wen Congyang > > Subject: Re: [Qemu-devel] [PATCH v2 0/3] colo: Add support for continious > replication > > On Thu, 15 Aug 2019 19:57:37 +0100 > "Dr. David Alan Gilbert" wrote: > > > * Lukas Straub (lukasstra...@web.de) wrote: > > > Hello Everyone, > > > These Patches add support for continious replication to colo. > > > Please review. > > > > > > OK, for those who haven't followed COLO for so long; 'continuous > > replication' is when after the first primary fails, you can promote > > the original secondary to a new primary and start replicating again; > > > > i.e. current COLO gives you > > > > p<->s > > > > s > > > > with your patches you can do > > > > s becomes p2 > > p2<->s2 > > > > and you're back to being resilient again. > > > > Which is great; because that was always an important missing piece. > > > > Do you have some test scripts/setup for this - it would be great to > > automate some testing. > > My Plan is to write a Pacemaker Resource Agent[1] for qemu-colo and then do > some long-term testing in my small cluster here. Writing standalone tests > using > that Resource Agent should be easy, it just needs to be provided with the > right > arguments and environment Variables. Thanks Dave's explanation. It looks good for me and I will test this series in my side. Another question: Is "Pacemaker Resource Agent[1] " like a heartbeat module? I have wrote an internal heartbeat module running on Qemu, it make COLO can detect fail and trigger failover automatically, no need external APP to call the QMP command "x-colo-lost-heartbeat". If you need it, I can send a RFC version recently. Thanks Zhang Chen > > Regards, > Lukas Straub > > [1] https://github.com/ClusterLabs/resource-agents/blob/master/doc/dev- > guides/ra-dev-guide.asc#what-is-a-resource-agent
Re: [Qemu-devel] [PATCH v4 3/3] hw/gpio: Add in AST2600 specific implementation
On Wed, 2019-08-14 at 14:37 +0200, Cédric Le Goater wrote:
> On 14/08/2019 09:14, Rashmica Gupta wrote:
...
> > +static void aspeed_2600_gpio_realize(DeviceState *dev, Error
> > **errp)
> > +{
> > +AspeedGPIOState *s = ASPEED_GPIO(dev);
> > +AspeedGPIOState *s_1_8, *s_3_6;
> > +SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
> > +AspeedGPIOClass *agc, *agc2;
> > +int pin;
> > +void *obj;
> > +
> > +/* Create and setup the 1.8V gpio state/class */
> > +obj = object_new(TYPE_ASPEED_GPIO "-ast2600");
> > +s_1_8 = ASPEED_GPIO(obj);
> > +object_property_add_child(OBJECT(dev), TYPE_ASPEED_GPIO "-
> > ast2600-1.8v",
> > + obj, errp);
> > +if (error_abort) {
> > +error_propagate(errp, error_abort);
> > +}
>
> This looks wrong.
>
> Shouldn't we instantiate 2 GPIOs devices under the AST2600 SoC with
> different
> types ?
>
We were trying to keep one GPIO device with two states, one state for
3.6V gpios and one for the 1.8V gpios. As you can see I couldn't find
a nice way to do that. I'll have a go at just making two seperate
devices.
> C.
>
>
> > +agc = ASPEED_GPIO_GET_CLASS(s_1_8);
> > +agc->ctrl = (void *)_gpio_ast2600_1_8v_controller;
> > +aspeed_gpio_init(obj);
> > +
> > +/* Create and setup the 3.6V gpio state/class */
> > +obj = object_new(TYPE_ASPEED_GPIO "-ast2600");
> > +s_3_6 = ASPEED_GPIO(obj);
> > +object_property_add_child(OBJECT(dev), TYPE_ASPEED_GPIO "-
> > ast2600-3.6v",
> > + obj, errp);
> > +if (error_abort) {
> > +error_propagate(errp, error_abort);
> > +}
> > +agc2 = ASPEED_GPIO_GET_CLASS(s_3_6);
> > +agc2->ctrl = (void *)_gpio_ast2600_3_6v_controller;
> > +aspeed_gpio_init(obj);
> > +
> > +for (pin = 0; pin < agc->ctrl->nr_gpio_pins; pin++) {
> > +sysbus_init_irq(sbd, >gpios[pin]);
> > +}
> > +
> > +memory_region_init_io(_3_6->iomem, OBJECT(s_3_6),
> > _gpio_ops, s_3_6,
> > +TYPE_ASPEED_GPIO, GPIO_3_6V_MEM_SIZE +
> > GPIO_1_8V_MEM_SIZE);
> > +s_3_6->lookup = aspeed_3_6v_gpios;
> > +
> > +memory_region_init_io(_1_8->iomem, OBJECT(s_1_8),
> > _gpio_ops, s_1_8,
> > +TYPE_ASPEED_GPIO, GPIO_1_8V_MEM_SIZE);
> > +memory_region_add_subregion(_3_6->iomem,
> > GPIO_1_8V_REG_OFFSET,
> > +_1_8->iomem);
> > +s_1_8->lookup = aspeed_1_8v_gpios;
> > +
> > +sysbus_init_mmio(sbd, _3_6->iomem);
> > +sysbus_init_mmio(sbd, _1_8->iomem);
> > +}
> > +
> > static const VMStateDescription vmstate_gpio_regs = {
> > .name = TYPE_ASPEED_GPIO"/regs",
> > .version_id = 1,
> > @@ -830,6 +991,16 @@ static const VMStateDescription
> > vmstate_aspeed_gpio = {
> > }
> > };
> >
> > +static void aspeed_gpio_ast2600_class_init(ObjectClass *klass,
> > void *data)
> > +{
> > +DeviceClass *dc = DEVICE_CLASS(klass);
> > +
> > +dc->realize = aspeed_2600_gpio_realize;
> > +dc->reset = aspeed_gpio_reset;
> > +dc->desc = "Aspeed GPIO Controller";
> > +dc->vmsd = _aspeed_gpio;
> > +}
> > +
> > static void aspeed_gpio_class_init(ObjectClass *klass, void *data)
> > {
> > DeviceClass *dc = DEVICE_CLASS(klass);
> > @@ -866,11 +1037,18 @@ static const TypeInfo
> > aspeed_gpio_ast2500_info = {
> > .class_data = (void *)_gpio_ast2500_controller,
> > };
> >
> > +static const TypeInfo aspeed_gpio_ast2600_info = {
> > +.name = TYPE_ASPEED_GPIO "-ast2600",
> > +.parent = TYPE_ASPEED_GPIO,
> > +.class_init = aspeed_gpio_ast2600_class_init,
> > +};
> > +
> > static void aspeed_gpio_register_types(void)
> > {
> > type_register_static(_gpio_info);
> > type_register_static(_gpio_ast2400_info);
> > type_register_static(_gpio_ast2500_info);
> > +type_register_static(_gpio_ast2600_info);
> > }
> >
> > type_init(aspeed_gpio_register_types);
> > diff --git a/slirp b/slirp
> > index f0da672620..126c04acba 16
> > --- a/slirp
> > +++ b/slirp
> > @@ -1 +1 @@
> > -Subproject commit f0da6726207b740f6101028b2992f918477a4b08
> > +Subproject commit 126c04acbabd7ad32c2b018fe10dfac2a3bc1210
> >
Re: [Qemu-devel] [PATCH 1/3] pc: Fix error message on die-id validation
Hi,
On 2019/8/16 2:38, Eduardo Habkost wrote:
The error message for die-id range validation is incorrect. Example:
$ qemu-system-x86_64 -smp 1,sockets=6,maxcpus=6 \
-device qemu64-x86_64-cpu,socket-id=1,die-id=1,core-id=0,thread-id=0
qemu-system-x86_64: -device
qemu64-x86_64-cpu,socket-id=1,die-id=1,core-id=0,thread-id=0: \
Invalid CPU die-id: 1 must be in range 0:5
The actual range for die-id in this example is 0:0.
There is one die per socket by default.
The case sockets=6 means there are 6 dies by default
and the range for die-id is 0:5.
Fix the error message to use smp_dies and print the correct range.
Signed-off-by: Eduardo Habkost
---
hw/i386/pc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 549c437050..24b03bb49c 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2412,7 +2412,7 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
return;
} else if (cpu->die_id > pcms->smp_dies - 1) {
error_setg(errp, "Invalid CPU die-id: %u must be in range 0:%u",
- cpu->die_id, max_socket);
+ cpu->die_id, pcms->smp_dies - 1);
return;
}
if (cpu->core_id < 0) {
Re: [Qemu-devel] [Qemu-block] [PATCH v5 6/6] iotests: extend sleeping time under Valgrind
On 7/19/19 12:30 PM, Andrey Shinkevich wrote:
> To synchronize the time when QEMU is running longer under the Valgrind,
> increase the sleeping time in the test 247.
>
> Signed-off-by: Andrey Shinkevich
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/247 | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tests/qemu-iotests/247 b/tests/qemu-iotests/247
> index 546a794..c853b73 100755
> --- a/tests/qemu-iotests/247
> +++ b/tests/qemu-iotests/247
> @@ -57,7 +57,11 @@ TEST_IMG="$TEST_IMG.4" _make_test_img $size
> {"execute":"block-commit",
> "arguments":{"device":"format-4", "top-node": "format-2",
> "base-node":"format-0", "job-id":"job0"}}
> EOF
> -sleep 1
> +if [ "${VALGRIND_QEMU}" == "y" ]; then
> +sleep 10
> +else
> +sleep 1
> +fi
> echo '{"execute":"quit"}'
> ) | $QEMU -qmp stdio -nographic -nodefaults \
> -blockdev file,node-name=file-0,filename=$TEST_IMG.0,auto-read-only=on \
>
This makes me nervous, though. Won't this race terribly? (Wait, why
doesn't it race already?)
Re: [Qemu-devel] [Qemu-block] [PATCH v5 5/6] iotests: extended timeout under Valgrind
On 7/19/19 12:30 PM, Andrey Shinkevich wrote:
> As the iotests run longer under the Valgrind, the QEMU_COMM_TIMEOUT is
> to be increased in the test cases 028, 183 and 192 when running under
> the Valgrind.
>
> Suggested-by: Roman Kagan
> Signed-off-by: Andrey Shinkevich
> Reviewed-by: Vladimir Sementsov-Ogievskiy
> ---
> tests/qemu-iotests/028 | 6 +-
> tests/qemu-iotests/183 | 9 -
> tests/qemu-iotests/192 | 6 +-
> 3 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/tests/qemu-iotests/028 b/tests/qemu-iotests/028
> index 01f4959..71301ec 100755
> --- a/tests/qemu-iotests/028
> +++ b/tests/qemu-iotests/028
> @@ -110,7 +110,11 @@ echo
> qemu_comm_method="monitor"
> _launch_qemu -drive file="${TEST_IMG}",cache=${CACHEMODE},id=disk
> h=$QEMU_HANDLE
> -QEMU_COMM_TIMEOUT=1
> +if [ "${VALGRIND_QEMU}" == "y" ]; then
> +QEMU_COMM_TIMEOUT=7
> +else
> +QEMU_COMM_TIMEOUT=1
> +fi
>
> # Silence output since it contains the disk image path and QEMU's readline
> # character echoing makes it very hard to filter the output. Plus, there
> diff --git a/tests/qemu-iotests/183 b/tests/qemu-iotests/183
> index fbe5a99..04fb344 100755
> --- a/tests/qemu-iotests/183
> +++ b/tests/qemu-iotests/183
> @@ -94,8 +94,15 @@ if echo "$reply" | grep "compiled without old-style" >
> /dev/null; then
> _notrun "migrate -b support not compiled in"
> fi
>
> -QEMU_COMM_TIMEOUT=0.1 qemu_cmd_repeat=50 silent=yes \
> +timeout_comm=$QEMU_COMM_TIMEOUT
> +if [ "${VALGRIND_QEMU}" == "y" ]; then
> +QEMU_COMM_TIMEOUT=4
> +else
> +QEMU_COMM_TIMEOUT=0.1
> +fi
> +qemu_cmd_repeat=50 silent=yes \
> _send_qemu_cmd $src "{ 'execute': 'query-migrate' }" '"status":
> "completed"'
> +QEMU_COMM_TIMEOUT=$timeout_comm
> _send_qemu_cmd $src "{ 'execute': 'query-status' }" "return"
>
> echo
> diff --git a/tests/qemu-iotests/192 b/tests/qemu-iotests/192
> index 6193257..0344322 100755
> --- a/tests/qemu-iotests/192
> +++ b/tests/qemu-iotests/192
> @@ -60,7 +60,11 @@ fi
> qemu_comm_method="monitor"
> _launch_qemu -drive $DRIVE_ARG -incoming defer
> h=$QEMU_HANDLE
> -QEMU_COMM_TIMEOUT=1
> +if [ "${VALGRIND_QEMU}" == "y" ]; then
> +QEMU_COMM_TIMEOUT=7
> +else
> +QEMU_COMM_TIMEOUT=1
> +fi
>
> _send_qemu_cmd $h "nbd_server_start unix:$TEST_DIR/nbd" "(qemu)"
> _send_qemu_cmd $h "nbd_server_add -w drive0" "(qemu)"
>
I guess we're adding some more magic numbers to join the magic numbers
we already have.
Ah, well, perfection is a good way to make sure nothing good ever happens:
Reviewed-by: John Snow
Re: [Qemu-devel] [Qemu-block] [PATCH v5 4/6] iotests: Valgrind fails with nonexistent directory
On 7/19/19 12:30 PM, Andrey Shinkevich wrote:
> The Valgrind uses the exported variable TMPDIR and fails if the
> directory does not exist. Let us exclude such a test case from
> being run under the Valgrind and notify the user of it.
>
> Suggested-by: Kevin Wolf
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/051 | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tests/qemu-iotests/051 b/tests/qemu-iotests/051
> index ce942a5..f8141ca 100755
> --- a/tests/qemu-iotests/051
> +++ b/tests/qemu-iotests/051
> @@ -377,6 +377,10 @@ printf %b "qemu-io $device_id \"write -P 0x33 0
> 4k\"\ncommit $device_id\n" |
> $QEMU_IO -c "read -P 0x33 0 4k" "$TEST_IMG" | _filter_qemu_io
>
> # Using snapshot=on with a non-existent TMPDIR
> +if [ "${VALGRIND_QEMU}" == "y" ]; then
> +_casenotrun "Valgrind needs a valid TMPDIR for itself"
> +fi
> +VALGRIND_QEMU="" \
> TMPDIR=/nonexistent run_qemu -drive driver=null-co,snapshot=on
>
> # Using snapshot=on together with read-only=on
>
The only other way around this would be a complicated mechanism to set
the TMPDIR for valgrind's sub-processes only, with e.g.
valgrind ... env TMPDIR=/nonexistent qemu ...
... It's probably not worth trying to concoct such a thing; but I
suppose it is possible. You'd have to set up a generic layer for setting
environment variables, then in the qemu shim, you could either set them
directly (non-valgrind invocation) or set them as part of the valgrind
command-line.
Or you could just take my R-B:
Reviewed-by: John Snow
Re: [Qemu-devel] [Qemu-block] [PATCH v5 3/6] iotests: Add casenotrun report to bash tests
On 7/19/19 12:30 PM, Andrey Shinkevich wrote:
> The new function _casenotrun() is to be invoked if a test case cannot
> be run for some reason. The user will be notified by a message passed
> to the function.
>
Oh, I assume this is a sub-test granularity; if we need to skip
individual items.
I'm good with this, but we should CC Cleber Rosa, who has struggled
against this in the past, too.
> Suggested-by: Kevin Wolf
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/common.rc | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
> index 6e461a1..1089050 100644
> --- a/tests/qemu-iotests/common.rc
> +++ b/tests/qemu-iotests/common.rc
> @@ -428,6 +428,13 @@ _notrun()
> exit
> }
>
> +# bail out, setting up .casenotrun file
> +#
> +_casenotrun()
> +{
> +echo "[case not run] $*" >>"$OUTPUT_DIR/$seq.casenotrun"
> +}
> +
> # just plain bail out
> #
> _fail()
>
seems fine to me otherwise.
Reviewed-by: John Snow
Re: [Qemu-devel] [Qemu-block] [PATCH v5 2/6] iotests: exclude killed processes from running under Valgrind
On 7/19/19 12:30 PM, Andrey Shinkevich wrote: > The Valgrind tool fails to manage its termination when QEMU raises the > signal SIGKILL in the multi-threaded process. The bug has been > reported to the Valgrind maintainers and was registered as Bug 409141. > Let's exclude such test cases from running under the Valgrind until > new release of it because checking for the memory issues is covered by > other test cases. > Link to the bug in the commit message, please: https://bugs.kde.org/show_bug.cgi?id=409141 ...Hey! It looks like they may have fixed it. However, we don't know if the user has a properly fixed version of valgrind or not. How long do we keep these workarounds in-tree? > Signed-off-by: Andrey Shinkevich > --- > tests/qemu-iotests/039 | 5 + > tests/qemu-iotests/061 | 2 ++ > tests/qemu-iotests/137 | 1 + > 3 files changed, 8 insertions(+) > > diff --git a/tests/qemu-iotests/039 b/tests/qemu-iotests/039 > index 0d4e963..95115e2 100755 > --- a/tests/qemu-iotests/039 > +++ b/tests/qemu-iotests/039 > @@ -65,6 +65,7 @@ echo "== Creating a dirty image file ==" > IMGOPTS="compat=1.1,lazy_refcounts=on" > _make_test_img $size > > +VALGRIND_QEMU="" \ > $QEMU_IO -c "write -P 0x5a 0 512" \ > -c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 \ > | _filter_qemu_io > @@ -100,6 +101,7 @@ echo "== Opening a dirty image read/write should repair > it ==" > IMGOPTS="compat=1.1,lazy_refcounts=on" > _make_test_img $size > This seems like the sort of thing that's going to get forgotten about quickly. It's not clear (if you're reading the test source) why we're setting VALGRIND_QEMU="" before these invocations. Is it possible to create some kind of _NO_VALGRIND() shim that has some comment in it, like: # Valgrind bug #409141 https://bugs.kde.org/show_bug.cgi?id=409141 # Until valgrind 3.16+ is ubiquitous, we must work around a hang in # valgrind when issuing sigkill. Disable valgrind for this invocation. VALGRIND_QEMU="" exec "$@" (something like that.) This way: (1) The workaround is being clearly demonstrated as a bit of a hack (2) The shim explains what the hack is for (3) When we decide we no longer need the hack, we can pull it out of a central location and easily grep to find callers of the shim. > +VALGRIND_QEMU="" \ > $QEMU_IO -c "write -P 0x5a 0 512" \ > -c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 \ > | _filter_qemu_io > @@ -118,6 +120,7 @@ echo "== Creating an image file with lazy_refcounts=off > ==" > IMGOPTS="compat=1.1,lazy_refcounts=off" > _make_test_img $size > > +VALGRIND_QEMU="" \ > $QEMU_IO -c "write -P 0x5a 0 512" \ > -c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 \ > | _filter_qemu_io > @@ -151,6 +154,7 @@ echo "== Changing lazy_refcounts setting at runtime ==" > IMGOPTS="compat=1.1,lazy_refcounts=off" > _make_test_img $size > > +VALGRIND_QEMU="" \ > $QEMU_IO -c "reopen -o lazy-refcounts=on" \ > -c "write -P 0x5a 0 512" \ > -c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 \ > @@ -163,6 +167,7 @@ _check_test_img > IMGOPTS="compat=1.1,lazy_refcounts=on" > _make_test_img $size > > +VALGRIND_QEMU="" \ > $QEMU_IO -c "reopen -o lazy-refcounts=off" \ > -c "write -P 0x5a 0 512" \ > -c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 \ > diff --git a/tests/qemu-iotests/061 b/tests/qemu-iotests/061 > index d7dbd7e..5d0724c 100755 > --- a/tests/qemu-iotests/061 > +++ b/tests/qemu-iotests/061 > @@ -73,6 +73,7 @@ echo > echo "=== Testing dirty version downgrade ===" > echo > IMGOPTS="compat=1.1,lazy_refcounts=on" _make_test_img 64M > +VALGRIND_QEMU="" \ > $QEMU_IO -c "write -P 0x2a 0 128k" -c flush \ > -c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 | _filter_qemu_io > $PYTHON qcow2.py "$TEST_IMG" dump-header > @@ -107,6 +108,7 @@ echo > echo "=== Testing dirty lazy_refcounts=off ===" > echo > IMGOPTS="compat=1.1,lazy_refcounts=on" _make_test_img 64M > +VALGRIND_QEMU="" \ > $QEMU_IO -c "write -P 0x2a 0 128k" -c flush \ > -c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 | _filter_qemu_io > $PYTHON qcow2.py "$TEST_IMG" dump-header > diff --git a/tests/qemu-iotests/137 b/tests/qemu-iotests/137 > index 0c3d2a1..a442fc8 100755 > --- a/tests/qemu-iotests/137 > +++ b/tests/qemu-iotests/137 > @@ -130,6 +130,7 @@ echo > > # Whether lazy-refcounts was actually enabled can easily be tested: Check if > # the dirty bit is set after a crash > +VALGRIND_QEMU="" \ > $QEMU_IO \ > -c "reopen -o lazy-refcounts=on,overlap-check=blubb" \ > -c "write -P 0x5a 0 512" \ >
Re: [Qemu-devel] [Qemu-block] [PATCH v5 1/6] iotests: allow Valgrind checking all QEMU processes
On 7/19/19 12:30 PM, Andrey Shinkevich wrote:
> With the '-valgrind' option, let all the QEMU processes be run under
> the Valgrind tool. The Valgrind own parameters may be set with its
> environment variable VALGRIND_OPTS, e.g.
> VALGRIND_OPTS="--leak-check=yes" ./check -qcow2 -valgrind
> or they may be listed in the Valgrind checked file ./.valgrindrc or
> ~/.valgrindrc like
> --memcheck:leak-check=no
> --memcheck:track-origins=yes
> When QEMU-IO process is being killed, the shell report refers to the
> text of the command in _qemu_io_wrapper(), which was modified with this
> patch. So, the benchmark output for the tests 039, 061 and 137 is to be
> changed also.
>
Oh, weird. "VALGRIND_QEMU=y" actually has just meant ... valgrind
qemu-io. OK.
> Signed-off-by: Andrey Shinkevich
> ---
> tests/qemu-iotests/039.out | 30 ---
> tests/qemu-iotests/061.out | 12 ++--
> tests/qemu-iotests/137.out | 6 +---
> tests/qemu-iotests/common.rc | 69
>
> 4 files changed, 59 insertions(+), 58 deletions(-)
>
> diff --git a/tests/qemu-iotests/039.out b/tests/qemu-iotests/039.out
> index 724d7b2..972c6c0 100644
> --- a/tests/qemu-iotests/039.out
> +++ b/tests/qemu-iotests/039.out
> @@ -11,11 +11,7 @@ No errors were found on the image.
> Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
> wrote 512/512 bytes at offset 0
> 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -./common.rc: Killed ( if [ "${VALGRIND_QEMU}" == "y" ]; then
> -exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99
> "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -else
> -exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -fi )
> +./common.rc: Killed ( _qemu_proc_wrapper
> "${VALGRIND_LOGFILE}" "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@" )
> incompatible_features 0x1
> ERROR cluster 5 refcount=0 reference=1
> ERROR OFLAG_COPIED data cluster: l2_entry=8005 refcount=0
> @@ -50,11 +46,7 @@ read 512/512 bytes at offset 0
> Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
> wrote 512/512 bytes at offset 0
> 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -./common.rc: Killed ( if [ "${VALGRIND_QEMU}" == "y" ]; then
> -exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99
> "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -else
> -exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -fi )
> +./common.rc: Killed ( _qemu_proc_wrapper
> "${VALGRIND_LOGFILE}" "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@" )
> incompatible_features 0x1
> ERROR cluster 5 refcount=0 reference=1
> Rebuilding refcount structure
> @@ -68,11 +60,7 @@ incompatible_features 0x0
> Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
> wrote 512/512 bytes at offset 0
> 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -./common.rc: Killed ( if [ "${VALGRIND_QEMU}" == "y" ]; then
> -exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99
> "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -else
> -exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -fi )
> +./common.rc: Killed ( _qemu_proc_wrapper
> "${VALGRIND_LOGFILE}" "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@" )
> incompatible_features 0x0
> No errors were found on the image.
>
> @@ -91,11 +79,7 @@ No errors were found on the image.
> Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
> wrote 512/512 bytes at offset 0
> 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -./common.rc: Killed ( if [ "${VALGRIND_QEMU}" == "y" ]; then
> -exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99
> "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -else
> -exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -fi )
> +./common.rc: Killed ( _qemu_proc_wrapper
> "${VALGRIND_LOGFILE}" "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@" )
> incompatible_features 0x1
> ERROR cluster 5 refcount=0 reference=1
> ERROR OFLAG_COPIED data cluster: l2_entry=8005 refcount=0
> @@ -105,11 +89,7 @@ Data may be corrupted, or further writes to the image may
> corrupt it.
> Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
> wrote 512/512 bytes at offset 0
> 512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> -./common.rc: Killed ( if [ "${VALGRIND_QEMU}" == "y" ]; then
> -exec valgrind --log-file="${VALGRIND_LOGFILE}" --error-exitcode=99
> "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -else
> -exec "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@";
> -fi )
> +./common.rc: Killed ( _qemu_proc_wrapper
> "${VALGRIND_LOGFILE}" "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@" )
> incompatible_features 0x0
> No errors were found on the image.
> *** done
> diff --git a/tests/qemu-iotests/061.out b/tests/qemu-iotests/061.out
> index 1aa7d37..8cb57eb 100644
> --- a/tests/qemu-iotests/061.out
> +++
Re: [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections
Patchew URL: https://patchew.org/QEMU/20190815185024.7010-1-ebl...@redhat.com/ Hi, This series failed build test on s390x host. Please find the details below. === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked under the git checkout with # HEAD pointing to a commit that has the patches applied on top of "base" # branch set -e echo echo "=== ENV ===" env echo echo "=== PACKAGES ===" rpm -qa echo echo "=== UNAME ===" uname -a CC=$HOME/bin/cc INSTALL=$PWD/install BUILD=$PWD/build mkdir -p $BUILD $INSTALL SRC=$PWD cd $BUILD $SRC/configure --cc=$CC --prefix=$INSTALL make -j4 # XXX: we need reliable clean up # make check -j4 V=1 make install === TEST SCRIPT END === CC mips64-softmmu/trace/control-target.o CC mips64-softmmu/trace/generated-helpers.o LINKmips64-softmmu/qemu-system-mips64 collect2: error: ld returned 1 exit status make[1]: *** [Makefile:209: qemu-system-mips64] Error 1 make: *** [Makefile:472: mips64-softmmu/all] Error 2 make: *** Waiting for unfinished jobs The full log is available at http://patchew.org/logs/20190815185024.7010-1-ebl...@redhat.com/testing.s390x/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
[Qemu-devel] [PATCH 2/3] ati-vga: Support unaligned access to hardware cursor registers
This fixes horizontal mouse movement and pointer color with MacOS that
writes these registers with access size less than 4 so previously only
the last portion of access was effective overwriting previous partial
writes.
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 87 +---
1 file changed, 58 insertions(+), 29 deletions(-)
diff --git a/hw/display/ati.c b/hw/display/ati.c
index 87ad18664d..5e2c4ba4aa 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -385,22 +385,28 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr,
unsigned int size)
case 0xf00 ... 0xfff:
val = pci_default_read_config(>dev, addr - 0xf00, size);
break;
-case CUR_OFFSET:
-val = s->regs.cur_offset;
-break;
-case CUR_HORZ_VERT_POSN:
-val = s->regs.cur_hv_pos;
-val |= s->regs.cur_offset & BIT(31);
+case CUR_OFFSET ... CUR_OFFSET + 3:
+val = ati_reg_read_offs(s->regs.cur_offset, addr - CUR_OFFSET, size);
+break;
+case CUR_HORZ_VERT_POSN ... CUR_HORZ_VERT_POSN + 3:
+val = ati_reg_read_offs(s->regs.cur_hv_pos,
+addr - CUR_HORZ_VERT_POSN, size);
+if (addr + size > CUR_HORZ_VERT_POSN + 3) {
+val |= (s->regs.cur_offset & BIT(31)) >> (4 - size);
+}
break;
-case CUR_HORZ_VERT_OFF:
-val = s->regs.cur_hv_offs;
-val |= s->regs.cur_offset & BIT(31);
+case CUR_HORZ_VERT_OFF ... CUR_HORZ_VERT_OFF + 3:
+val = ati_reg_read_offs(s->regs.cur_hv_offs,
+addr - CUR_HORZ_VERT_OFF, size);
+if (addr + size > CUR_HORZ_VERT_OFF + 3) {
+val |= (s->regs.cur_offset & BIT(31)) >> (4 - size);
+}
break;
-case CUR_CLR0:
-val = s->regs.cur_color0;
+case CUR_CLR0 ... CUR_CLR0 + 3:
+val = ati_reg_read_offs(s->regs.cur_color0, addr - CUR_CLR0, size);
break;
-case CUR_CLR1:
-val = s->regs.cur_color1;
+case CUR_CLR1 ... CUR_CLR1 + 3:
+val = ati_reg_read_offs(s->regs.cur_color1, addr - CUR_CLR1, size);
break;
case DST_OFFSET:
val = s->regs.dst_offset;
@@ -672,48 +678,71 @@ static void ati_mm_write(void *opaque, hwaddr addr,
case 0xf00 ... 0xfff:
/* read-only copy of PCI config space so ignore writes */
break;
-case CUR_OFFSET:
-if (s->regs.cur_offset != (data & 0x87f0)) {
-s->regs.cur_offset = data & 0x87f0;
+case CUR_OFFSET ... CUR_OFFSET + 3:
+{
+uint32_t t = s->regs.cur_offset;
+
+ati_reg_write_offs(, addr - CUR_OFFSET, data, size);
+t &= 0x87f0;
+if (s->regs.cur_offset != t) {
+s->regs.cur_offset = t;
ati_cursor_define(s);
}
break;
-case CUR_HORZ_VERT_POSN:
-s->regs.cur_hv_pos = data & 0x3fff0fff;
-if (data & BIT(31)) {
-s->regs.cur_offset |= data & BIT(31);
+}
+case CUR_HORZ_VERT_POSN ... CUR_HORZ_VERT_POSN + 3:
+{
+uint32_t t = s->regs.cur_hv_pos | (s->regs.cur_offset & BIT(31));
+
+ati_reg_write_offs(, addr - CUR_HORZ_VERT_POSN, data, size);
+s->regs.cur_hv_pos = t & 0x3fff0fff;
+if (t & BIT(31)) {
+s->regs.cur_offset |= t & BIT(31);
} else if (s->regs.cur_offset & BIT(31)) {
s->regs.cur_offset &= ~BIT(31);
ati_cursor_define(s);
}
if (!s->cursor_guest_mode &&
-(s->regs.crtc_gen_cntl & CRTC2_CUR_EN) && !(data & BIT(31))) {
+(s->regs.crtc_gen_cntl & CRTC2_CUR_EN) && !(t & BIT(31))) {
dpy_mouse_set(s->vga.con, s->regs.cur_hv_pos >> 16,
s->regs.cur_hv_pos & 0x, 1);
}
break;
+}
case CUR_HORZ_VERT_OFF:
-s->regs.cur_hv_offs = data & 0x3f003f;
-if (data & BIT(31)) {
-s->regs.cur_offset |= data & BIT(31);
+{
+uint32_t t = s->regs.cur_hv_offs | (s->regs.cur_offset & BIT(31));
+
+ati_reg_write_offs(, addr - CUR_HORZ_VERT_OFF, data, size);
+s->regs.cur_hv_offs = t & 0x3f003f;
+if (t & BIT(31)) {
+s->regs.cur_offset |= t & BIT(31);
} else if (s->regs.cur_offset & BIT(31)) {
s->regs.cur_offset &= ~BIT(31);
ati_cursor_define(s);
}
break;
-case CUR_CLR0:
-if (s->regs.cur_color0 != (data & 0xff)) {
-s->regs.cur_color0 = data & 0xff;
+}
+case CUR_CLR0 ... CUR_CLR0 + 3:
+{
+uint32_t t = s->regs.cur_color0;
+
+ati_reg_write_offs(, addr - CUR_CLR0, data, size);
+t &= 0xff;
+if (s->regs.cur_color0 != t) {
+s->regs.cur_color0 = t;
ati_cursor_define(s);
}
break;
-case CUR_CLR1:
+}
+case CUR_CLR1 ... CUR_CLR1 + 3:
/*
* Update cursor
[Qemu-devel] [PATCH 0/3] ati-vga fixes for MacOS driver
Hello, These are some fixes to get MacOS driver closer to working. Patch 1 adds a simple VBlank interrupt (this could be refined later as MacOS seems to poll it frequently enough to get 100% CPU usage when enabled). Patch 2 fixes problems with mouse pointer color and movement due to byte and word access to HW cursor regs and Patch 3 removes some annoying trace messages that are frequent enough to flood the log when traces are enabled. With these fixes MacOS shows desktop and the mouse pointer can be moved around but it does not seem to fully boot yet as nothing can be clicked so it may still miss something somewhere. (Also to get to this point one needs to run an FCode ROM which needs patches to OpenBIOS currently.) Regards, BALATON Zoltan BALATON Zoltan (3): ati-vga: Implement dummy VBlank IRQ ati-vga: Support unaligned access to hardware cursor registers ati-vga: Silence some noisy traces hw/display/ati.c | 147 +++--- hw/display/ati_dbg.c | 1 + hw/display/ati_int.h | 4 ++ hw/display/ati_regs.h | 6 +++ 4 files changed, 128 insertions(+), 30 deletions(-) -- 2.13.7
[Qemu-devel] [PATCH 1/3] ati-vga: Implement dummy VBlank IRQ
The MacOS driver exits if the card does not have an interrupt. If we
set PCI_INTERRUPT_PIN to 1 then it enables VBlank interrupts and it
boots but the mouse pointer cannot be moved. This patch implements a
dummy VBlank interrupt triggered by a 60 Hz timer. With this the
pointer now moves but MacOS still hangs somewhere before completely
finishing boot.
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 44
hw/display/ati_dbg.c | 1 +
hw/display/ati_int.h | 4
hw/display/ati_regs.h | 6 ++
4 files changed, 55 insertions(+)
diff --git a/hw/display/ati.c b/hw/display/ati.c
index a365e2455d..87ad18664d 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -243,6 +243,21 @@ static uint64_t ati_i2c(bitbang_i2c_interface *i2c,
uint64_t data, int base)
return data;
}
+static void ati_vga_update_irq(ATIVGAState *s)
+{
+pci_set_irq(>dev, !!(s->regs.gen_int_status & s->regs.gen_int_cntl));
+}
+
+static void ati_vga_vblank_irq(void *opaque)
+{
+ATIVGAState *s = opaque;
+
+timer_mod(>vblank_timer, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) +
+ NANOSECONDS_PER_SECOND / 60);
+s->regs.gen_int_status |= CRTC_VBLANK_INT;
+ati_vga_update_irq(s);
+}
+
static inline uint64_t ati_reg_read_offs(uint32_t reg, int offs,
unsigned int size)
{
@@ -283,6 +298,12 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr,
unsigned int size)
addr - (BIOS_0_SCRATCH + i * 4), size);
break;
}
+case GEN_INT_CNTL:
+val = s->regs.gen_int_cntl;
+break;
+case GEN_INT_STATUS:
+val = s->regs.gen_int_status;
+break;
case CRTC_GEN_CNTL ... CRTC_GEN_CNTL + 3:
val = ati_reg_read_offs(s->regs.crtc_gen_cntl,
addr - CRTC_GEN_CNTL, size);
@@ -512,6 +533,21 @@ static void ati_mm_write(void *opaque, hwaddr addr,
addr - (BIOS_0_SCRATCH + i * 4), data, size);
break;
}
+case GEN_INT_CNTL:
+s->regs.gen_int_cntl = data;
+if (data & CRTC_VBLANK_INT) {
+ati_vga_vblank_irq(s);
+} else {
+timer_del(>vblank_timer);
+ati_vga_update_irq(s);
+}
+break;
+case GEN_INT_STATUS:
+data &= (s->dev_id == PCI_DEVICE_ID_ATI_RAGE128_PF ?
+ 0x000f040fUL : 0xfc080effUL);
+s->regs.gen_int_status &= ~data;
+ati_vga_update_irq(s);
+break;
case CRTC_GEN_CNTL ... CRTC_GEN_CNTL + 3:
{
uint32_t val = s->regs.crtc_gen_cntl;
@@ -902,12 +938,19 @@ static void ati_vga_realize(PCIDevice *dev, Error **errp)
pci_register_bar(dev, 0, PCI_BASE_ADDRESS_MEM_PREFETCH, >vram);
pci_register_bar(dev, 1, PCI_BASE_ADDRESS_SPACE_IO, >io);
pci_register_bar(dev, 2, PCI_BASE_ADDRESS_SPACE_MEMORY, >mm);
+
+/* most interrupts are not yet emulated but MacOS needs at least VBlank */
+dev->config[PCI_INTERRUPT_PIN] = 1;
+timer_init_ns(>vblank_timer, QEMU_CLOCK_VIRTUAL, ati_vga_vblank_irq, s);
}
static void ati_vga_reset(DeviceState *dev)
{
ATIVGAState *s = ATI_VGA(dev);
+timer_del(>vblank_timer);
+ati_vga_update_irq(s);
+
/* reset vga */
vga_common_reset(>vga);
s->mode = VGA_MODE;
@@ -917,6 +960,7 @@ static void ati_vga_exit(PCIDevice *dev)
{
ATIVGAState *s = ATI_VGA(dev);
+timer_del(>vblank_timer);
graphic_console_close(s->vga.con);
}
diff --git a/hw/display/ati_dbg.c b/hw/display/ati_dbg.c
index 7e59c41ac2..0ebbd36f14 100644
--- a/hw/display/ati_dbg.c
+++ b/hw/display/ati_dbg.c
@@ -16,6 +16,7 @@ static struct ati_regdesc ati_reg_names[] = {
{"BUS_CNTL", 0x0030},
{"BUS_CNTL1", 0x0034},
{"GEN_INT_CNTL", 0x0040},
+{"GEN_INT_STATUS", 0x0044},
{"CRTC_GEN_CNTL", 0x0050},
{"CRTC_EXT_CNTL", 0x0054},
{"DAC_CNTL", 0x0058},
diff --git a/hw/display/ati_int.h b/hw/display/ati_int.h
index 5b4d3be1e6..2a16708e4f 100644
--- a/hw/display/ati_int.h
+++ b/hw/display/ati_int.h
@@ -9,6 +9,7 @@
#ifndef ATI_INT_H
#define ATI_INT_H
+#include "qemu/timer.h"
#include "hw/pci/pci.h"
#include "hw/i2c/bitbang_i2c.h"
#include "vga_int.h"
@@ -33,6 +34,8 @@
typedef struct ATIVGARegs {
uint32_t mm_index;
uint32_t bios_scratch[8];
+uint32_t gen_int_cntl;
+uint32_t gen_int_status;
uint32_t crtc_gen_cntl;
uint32_t crtc_ext_cntl;
uint32_t dac_cntl;
@@ -89,6 +92,7 @@ typedef struct ATIVGAState {
uint16_t cursor_size;
uint32_t cursor_offset;
QEMUCursor *cursor;
+QEMUTimer vblank_timer;
bitbang_i2c_interface bbi2c;
MemoryRegion io;
MemoryRegion mm;
diff --git a/hw/display/ati_regs.h b/hw/display/ati_regs.h
index 02046e97c2..ebd37ee30d 100644
--- a/hw/display/ati_regs.h
+++ b/hw/display/ati_regs.h
@@ -34,6 +34,7 @@
#define BUS_CNTL0x0030
#define BUS_CNTL1
[Qemu-devel] [PATCH 3/3] ati-vga: Silence some noisy traces
Some registers are accessed very frequently so exclude these from
traces to avoid flooding output with a lot of trace logs when traces
are enabled thus helping debugging.
Signed-off-by: BALATON Zoltan
---
hw/display/ati.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/hw/display/ati.c b/hw/display/ati.c
index 5e2c4ba4aa..36d2a75f71 100644
--- a/hw/display/ati.c
+++ b/hw/display/ati.c
@@ -489,7 +489,14 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr,
unsigned int size)
default:
break;
}
-if (addr < CUR_OFFSET || addr > CUR_CLR1 || ATI_DEBUG_HW_CURSOR) {
+if ((addr < CUR_OFFSET || addr > CUR_CLR1 + 3 || (ATI_DEBUG_HW_CURSOR &&
+(addr >= CUR_OFFSET && addr <= CUR_CLR1 + 3))) &&
+(addr < GEN_INT_CNTL || addr > GEN_INT_STATUS + 3) &&
+(addr < GPIO_MONID || addr > GPIO_MONID + 3) &&
+(addr < AMCGPIO_MASK_MIR || addr > AMCGPIO_EN_MIR + 3) &&
+(addr < 0x908 || addr > 0x90f) && (addr < 0xc4c || addr > 0xc53) &&
+addr != RBBM_STATUS && addr != 0x1714 &&
+addr != 0x7b8 && addr > MM_DATA + 3) {
trace_ati_mm_read(size, addr, ati_reg_name(addr & ~3ULL), val);
}
return val;
@@ -511,7 +518,14 @@ static void ati_mm_write(void *opaque, hwaddr addr,
{
ATIVGAState *s = opaque;
-if (addr < CUR_OFFSET || addr > CUR_CLR1 || ATI_DEBUG_HW_CURSOR) {
+if addr < CUR_OFFSET || addr > CUR_CLR1 + 3) &&
+ addr != CRTC_GEN_CNTL + 2) || (ATI_DEBUG_HW_CURSOR &&
+ addr >= CUR_OFFSET && addr <= CUR_CLR1 + 3)) &&
+ (addr < GEN_INT_CNTL || addr > GEN_INT_STATUS + 3) &&
+ (addr < GPIO_MONID || addr > GPIO_MONID + 3) &&
+ (addr < AMCGPIO_MASK_MIR || addr > AMCGPIO_EN_MIR + 3) &&
+ (addr < 0x908 || addr > 0x90f) && (addr < 0xc4c || addr > 0xc53) &&
+ addr != 0x1714 && addr > MM_DATA + 3) {
trace_ati_mm_write(size, addr, ati_reg_name(addr & ~3ULL), data);
}
switch (addr) {
--
2.13.7
Re: [Qemu-devel] [PULL 04/32] target/riscv: Implement riscv_cpu_unassigned_access
On Thu, 15 Aug 2019 14:39:18 PDT (-0700), alistai...@gmail.com wrote: On Tue, Aug 13, 2019 at 3:44 PM Palmer Dabbelt wrote: On Thu, 01 Aug 2019 08:39:17 PDT (-0700), Peter Maydell wrote: > On Wed, 3 Jul 2019 at 09:41, Palmer Dabbelt wrote: >> >> From: Michael Clark >> >> This patch adds support for the riscv_cpu_unassigned_access call >> and will raise a load or store access fault. >> >> Signed-off-by: Michael Clark >> [Changes by AF: >> - Squash two patches and rewrite commit message >> - Set baddr to the access address >> ] >> Signed-off-by: Alistair Francis >> Reviewed-by: Palmer Dabbelt >> Signed-off-by: Palmer Dabbelt > > Oops, I missed seeing this go by. The do_unassigned_access > hook is deprecated and you should drop this and use > the do_transaction_failed hook instead. Argh! > > The distinction between the two is that do_unassigned_access > will end up being called for any failing access, including > not just "normal" guest accesses but also for bad accesses > that happen during page table walks (which often want to > be reported to the guest differently) and also accesses > by random devices like DMA controllers (where throwing a > cpu exception is always a bug). > > Changing the hook implementation itself should be straightforward; > commit 6ad4d7eed05a1e23537f is an example of doing that on Alpha. > You also want to check all the places in your target code that > do physical memory accesses, determine what the right behaviour > if they get a bus fault is, and implement that (or at least put > in TODO comments). Sorry, updating that has been on my TODO list for a while now. I figured it was better to have the deprecated version in there than nothing at all. I've written some patches to fix this, but I want to give them another look before sending them out. I was going to start looking into this, but if you already have patches I won't bother. Let me know if you want a hand with the conversion. You're more than welcome to take them over. I've got something that boots Linux on my unassigned_access branch (github.com/palmer-dabbelt/qemu), but I haven't sanitized the whole port for physical accesses and I haven't convinced myself that my hook implementation is correct.
Re: [Qemu-devel] [PATCH v3 0/7] RISC-V: Hypervisor prep work part 2
Patchew URL: https://patchew.org/QEMU/cover.1565904855.git.alistair.fran...@wdc.com/ Hi, This series failed build test on s390x host. Please find the details below. === TEST SCRIPT BEGIN === #!/bin/bash # Testing script will be invoked under the git checkout with # HEAD pointing to a commit that has the patches applied on top of "base" # branch set -e echo echo "=== ENV ===" env echo echo "=== PACKAGES ===" rpm -qa echo echo "=== UNAME ===" uname -a CC=$HOME/bin/cc INSTALL=$PWD/install BUILD=$PWD/build mkdir -p $BUILD $INSTALL SRC=$PWD cd $BUILD $SRC/configure --cc=$CC --prefix=$INSTALL make -j4 # XXX: we need reliable clean up # make check -j4 V=1 make install === TEST SCRIPT END === CC mips-softmmu/hw/vfio/display.o CC mips-softmmu/hw/virtio/virtio.o GEN nios2-softmmu/hmp-commands.h collect2: error: ld returned 1 exit status GEN nios2-softmmu/hmp-commands-info.h GEN nios2-softmmu/config-devices.h GEN nios2-softmmu/config-target.h --- CC aarch64-softmmu/hw/misc/nrf51_rng.o CC aarch64-softmmu/hw/net/virtio-net.o CC aarch64-softmmu/hw/nvram/nrf51_nvm.o collect2: error: ld returned 1 exit status make[1]: *** [Makefile:209: qemu-system-nios2] Error 1 make: *** [Makefile:472: nios2-softmmu/all] Error 2 CC aarch64-softmmu/hw/pcmcia/pxa2xx.o --- make[1]: *** [/var/tmp/patchew-tester-tmp-ma8jqv0u/src/rules.mak:69: hw/vfio/pci.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:472: aarch64-softmmu/all] Error 2 collect2: error: ld returned 1 exit status make[1]: *** [Makefile:209: qemu-system-mips] Error 1 make: *** [Makefile:472: mips-softmmu/all] Error 2 === OUTPUT END === The full log is available at http://patchew.org/logs/cover.1565904855.git.alistair.fran...@wdc.com/testing.s390x/?type=message. --- Email generated automatically by Patchew [https://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections
On 8/15/19 5:54 PM, Eric Blake wrote:
> On 8/15/19 4:45 PM, John Snow wrote:
>>
>>
>> On 8/15/19 2:50 PM, Eric Blake wrote:
>>> The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
>>> advertised when the server promises cache consistency between
>>> simultaneous clients (basically, rules that determine what FUA and
>>> flush from one client are able to guarantee for reads from another
>>> client). When we don't permit simultaneous clients (such as qemu-nbd
>>> without -e), the bit makes no sense; and for writable images, we
>>> probably have a lot more work before we can declare that actions from
>>> one client are cache-consistent with actions from another. But for
>>> read-only images, where flush isn't changing any data, we might as
>>> well advertise multi-conn support. What's more, advertisement of the
>>> bit makes it easier for clients to determine if 'qemu-nbd -e' was in
>>> use, where a second connection will succeed rather than hang until the
>>> first client goes away.
>>>
>>> This patch affects qemu as server in advertising the bit. We may want
>>> to consider patches to qemu as client to attempt parallel connections
>>> for higher throughput by spreading the load over those connections
>>> when a server advertises multi-conn, but for now sticking to one
>>> connection per nbd:// BDS is okay.
>>>
>
>>> +++ b/blockdev-nbd.c
>>> @@ -189,7 +189,7 @@ void qmp_nbd_server_add(const char *device, bool
>>> has_name, const char *name,
>>> }
>>>
>>> exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
>>> - writable ? 0 : NBD_FLAG_READ_ONLY,
>>> + writable ? 0 : NBD_FLAG_READ_ONLY, true,
>>> NULL, false, on_eject_blk, errp);
>>
>> Why is it okay to force the share bit on regardless of the value of
>> 'writable' ?
>
> Well, it's probably not, except that...
>
>
>>> @@ -1486,6 +1486,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs,
>>> uint64_t dev_offset,
>>> perm = BLK_PERM_CONSISTENT_READ;
>>> if ((nbdflags & NBD_FLAG_READ_ONLY) == 0) {
>>> perm |= BLK_PERM_WRITE;
>>> +} else if (shared) {
>>> +nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
>>> }
>
> requesting shared=true has no effect for a writable export.
>
> I can tweak it for less confusion, though.
>
"Yes John, when it's an else-if it really does matter what specific
condition it's following."
(Ah, there it is.)
Yeah, I think if you have hopes to support this flag in the future for
writable exports, I think it might be nicer to reject this bit for RW;
and adjust the caller to only request it conditionally.
Or not. I guess we don't have to maintain backwards compatibility for
internal API like that, so ... dealer's choice:
Reviewed-by: John Snow
Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections
On 8/15/19 4:45 PM, John Snow wrote:
>
>
> On 8/15/19 2:50 PM, Eric Blake wrote:
>> The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
>> advertised when the server promises cache consistency between
>> simultaneous clients (basically, rules that determine what FUA and
>> flush from one client are able to guarantee for reads from another
>> client). When we don't permit simultaneous clients (such as qemu-nbd
>> without -e), the bit makes no sense; and for writable images, we
>> probably have a lot more work before we can declare that actions from
>> one client are cache-consistent with actions from another. But for
>> read-only images, where flush isn't changing any data, we might as
>> well advertise multi-conn support. What's more, advertisement of the
>> bit makes it easier for clients to determine if 'qemu-nbd -e' was in
>> use, where a second connection will succeed rather than hang until the
>> first client goes away.
>>
>> This patch affects qemu as server in advertising the bit. We may want
>> to consider patches to qemu as client to attempt parallel connections
>> for higher throughput by spreading the load over those connections
>> when a server advertises multi-conn, but for now sticking to one
>> connection per nbd:// BDS is okay.
>>
>> +++ b/blockdev-nbd.c
>> @@ -189,7 +189,7 @@ void qmp_nbd_server_add(const char *device, bool
>> has_name, const char *name,
>> }
>>
>> exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
>> - writable ? 0 : NBD_FLAG_READ_ONLY,
>> + writable ? 0 : NBD_FLAG_READ_ONLY, true,
>> NULL, false, on_eject_blk, errp);
>
> Why is it okay to force the share bit on regardless of the value of
> 'writable' ?
Well, it's probably not, except that...
>> @@ -1486,6 +1486,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs,
>> uint64_t dev_offset,
>> perm = BLK_PERM_CONSISTENT_READ;
>> if ((nbdflags & NBD_FLAG_READ_ONLY) == 0) {
>> perm |= BLK_PERM_WRITE;
>> +} else if (shared) {
>> +nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
>> }
requesting shared=true has no effect for a writable export.
I can tweak it for less confusion, though.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [Qemu-block] [PATCH] nbd: Advertise multi-conn for shared read-only connections
On 8/15/19 2:50 PM, Eric Blake wrote:
> The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
> advertised when the server promises cache consistency between
> simultaneous clients (basically, rules that determine what FUA and
> flush from one client are able to guarantee for reads from another
> client). When we don't permit simultaneous clients (such as qemu-nbd
> without -e), the bit makes no sense; and for writable images, we
> probably have a lot more work before we can declare that actions from
> one client are cache-consistent with actions from another. But for
> read-only images, where flush isn't changing any data, we might as
> well advertise multi-conn support. What's more, advertisement of the
> bit makes it easier for clients to determine if 'qemu-nbd -e' was in
> use, where a second connection will succeed rather than hang until the
> first client goes away.
>
> This patch affects qemu as server in advertising the bit. We may want
> to consider patches to qemu as client to attempt parallel connections
> for higher throughput by spreading the load over those connections
> when a server advertises multi-conn, but for now sticking to one
> connection per nbd:// BDS is okay.
>
> See also: https://bugzilla.redhat.com/1708300
> Signed-off-by: Eric Blake
> ---
> docs/interop/nbd.txt | 1 +
> include/block/nbd.h | 2 +-
> blockdev-nbd.c | 2 +-
> nbd/server.c | 4 +++-
> qemu-nbd.c | 2 +-
> 5 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
> index fc64473e02b2..6dfec7f47647 100644
> --- a/docs/interop/nbd.txt
> +++ b/docs/interop/nbd.txt
> @@ -53,3 +53,4 @@ the operation of that feature.
> * 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
> * 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
> NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
> +* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports
> diff --git a/include/block/nbd.h b/include/block/nbd.h
> index 7b36d672f046..991fd52a5134 100644
> --- a/include/block/nbd.h
> +++ b/include/block/nbd.h
> @@ -326,7 +326,7 @@ typedef struct NBDClient NBDClient;
>
> NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
>uint64_t size, const char *name, const char *desc,
> - const char *bitmap, uint16_t nbdflags,
> + const char *bitmap, uint16_t nbdflags, bool shared,
>void (*close)(NBDExport *), bool writethrough,
>BlockBackend *on_eject_blk, Error **errp);
> void nbd_export_close(NBDExport *exp);
> diff --git a/blockdev-nbd.c b/blockdev-nbd.c
> index 66eebab31875..e5d228771292 100644
> --- a/blockdev-nbd.c
> +++ b/blockdev-nbd.c
> @@ -189,7 +189,7 @@ void qmp_nbd_server_add(const char *device, bool
> has_name, const char *name,
> }
>
> exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
> - writable ? 0 : NBD_FLAG_READ_ONLY,
> + writable ? 0 : NBD_FLAG_READ_ONLY, true,
> NULL, false, on_eject_blk, errp);
Why is it okay to force the share bit on regardless of the value of
'writable' ?
> if (!exp) {
> return;
> diff --git a/nbd/server.c b/nbd/server.c
> index a2cf085f7635..a602d85070ff 100644
> --- a/nbd/server.c
> +++ b/nbd/server.c
> @@ -1460,7 +1460,7 @@ static void nbd_eject_notifier(Notifier *n, void *data)
>
> NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
>uint64_t size, const char *name, const char *desc,
> - const char *bitmap, uint16_t nbdflags,
> + const char *bitmap, uint16_t nbdflags, bool shared,
>void (*close)(NBDExport *), bool writethrough,
>BlockBackend *on_eject_blk, Error **errp)
> {
> @@ -1486,6 +1486,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs,
> uint64_t dev_offset,
> perm = BLK_PERM_CONSISTENT_READ;
> if ((nbdflags & NBD_FLAG_READ_ONLY) == 0) {
> perm |= BLK_PERM_WRITE;
> +} else if (shared) {
> +nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
> }
> blk = blk_new(bdrv_get_aio_context(bs), perm,
>BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
> diff --git a/qemu-nbd.c b/qemu-nbd.c
> index 049645491dab..55f5ceaf5c92 100644
> --- a/qemu-nbd.c
> +++ b/qemu-nbd.c
> @@ -1173,7 +1173,7 @@ int main(int argc, char **argv)
> }
>
> export = nbd_export_new(bs, dev_offset, fd_size, export_name,
> -export_description, bitmap, nbdflags,
> +export_description, bitmap, nbdflags, shared > 1,
> nbd_export_closed, writethrough, NULL,
> _fatal);
>
Re: [Qemu-devel] RISC-V: Vector && DSP Extension
On Thu, Aug 15, 2019 at 2:07 AM Peter Maydell wrote: > > On Thu, 15 Aug 2019 at 09:53, Aleksandar Markovic > wrote: > > > > > We can accept draft > > > extensions in QEMU as long as they are disabled by default. > > > Hi, Alistair, Palmer, > > > > Is this an official stance of QEMU community, or perhaps Alistair's > > personal judgement, or maybe a rule within risv subcomunity? > > Alistair asked on a previous thread; my view was: > https://lists.gnu.org/archive/html/qemu-devel/2019-07/msg03364.html > and nobody else spoke up disagreeing (summary: should at least be > disabled-by-default and only enabled by setting an explicit > property whose name should start with the 'x-' prefix). Agreed! > > In general QEMU does sometimes introduce experimental extensions > (we've had them in the block layer, for example) and so the 'x-' > property to enable them is a reasonably established convention. > I think it's a reasonable compromise to allow this sort of work > to start and not have to live out-of-tree for a long time, without > confusing users or getting into a situation where some QEMU > versions behave differently or to obsolete drafts of a spec > without it being clear from the command line that experimental > extensions are being enabled. > > There is also an element of "submaintainer judgement" to be applied > here -- upstream is probably not the place for a draft extension > to be implemented if it is: > * still fast moving or subject to major changes of design direction > * major changes to the codebase (especially if it requires >changes to core code) that might later need to be redone >entirely differently > * still experimental Yep, agreed. For RISC-V I think this would extend to only allowing extensions that have backing from the foundation and are under active discussion. Alistair > > thanks > -- PMM
[Qemu-devel] [PATCH v3 5/7] target/riscv: Use both register name and ABI name
From: Atish Patra
Use both the generic register name and ABI name for the general purpose
registers and floating point registers.
Signed-off-by: Atish Patra
Signed-off-by: Alistair Francis
---
target/riscv/cpu.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index f8d07bd20a..60b95daf60 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -33,17 +33,20 @@
static const char riscv_exts[26] = "IEMAFDQCLBJTPVNSUHKORWXYZG";
const char * const riscv_int_regnames[] = {
- "zero", "ra", "sp", "gp", "tp", "t0", "t1", "t2",
- "s0", "s1", "a0", "a1", "a2", "a3", "a4", "a5",
- "a6", "a7", "s2", "s3", "s4", "s5", "s6", "s7",
- "s8", "s9", "s10", "s11", "t3", "t4", "t5", "t6"
+ "x0/zero", "x1/ra", "x2/sp", "x3/gp", "x4/tp", "x5/t0", "x6/t1",
+ "x7/t2", "x8/s0", "x9/s1", "x10/a0", "x11/a1", "x12/a2", "x13/a3",
+ "x14/a4", "x15/a5", "x16/a6", "x17/a7", "x18/s2", "x19/s3", "x20/s4",
+ "x21/s5", "x22/s6", "x23/s7", "x24/s8", "x25/s9", "x26/s10", "x27/s11",
+ "x28/t3", "x29/t4", "x30/t5", "x31/t6"
};
const char * const riscv_fpr_regnames[] = {
- "ft0", "ft1", "ft2", "ft3", "ft4", "ft5", "ft6", "ft7",
- "fs0", "fs1", "fa0", "fa1", "fa2", "fa3", "fa4", "fa5",
- "fa6", "fa7", "fs2", "fs3", "fs4", "fs5", "fs6", "fs7",
- "fs8", "fs9", "fs10", "fs11", "ft8", "ft9", "ft10", "ft11"
+ "f0/ft0", "f1/ft1", "f2/ft2", "f3/ft3", "f4/ft4", "f5/ft5",
+ "f6/ft6", "f7/ft7", "f8/fs0", "f9/fs1", "f10/fa0", "f11/fa1",
+ "f12/fa2", "f13/fa3", "f14/fa4", "f15/fa5", "f16/fa6", "f17/fa7",
+ "f18/fs2", "f19/fs3", "f20/fs4", "f21/fs5", "f22/fs6", "f23/fs7",
+ "f24/fs8", "f25/fs9", "f26/fs10", "f27/fs11", "f28/ft8", "f29/ft9",
+ "f30/ft10", "f31/ft11"
};
const char * const riscv_excp_names[] = {
--
2.22.0
Re: [Qemu-devel] [Qemu-block] [PATCH 02/13] qcrypto-luks: misc refactoring
On 8/14/19 4:22 PM, Maxim Levitsky wrote:
> This is also a preparation for key read/write/erase functions
>
This is a matter of taste and I am not usually reviewing LUKS patches
(So don't take me too seriously), but I would prefer not to have "misc"
patches and instead split things out by individual changes along with a
nice commit message for each change.
> * use master key len from the header
This touches enough lines that you could make it its own patch, I think.
> * prefer to use crypto params in the QCryptoBlockLUKS
> over passing them as function arguments
I think the same is true here, and highlighting which variables you are
sticking into state instead of leaving as functional parameters would be
nice to see without all the other changes.
> * define QCRYPTO_BLOCK_LUKS_DEFAULT_ITER_TIME
This can likely be squashed with whichever patch of yours first needs to
use it, because it's so short.
> * Add comments to various crypto parameters in the QCryptoBlockLUKS
>
Can probably be squashed with item #2.
> Signed-off-by: Maxim Levitsky
> ---
> crypto/block-luks.c | 213 ++--
> 1 file changed, 105 insertions(+), 108 deletions(-)
>
> diff --git a/crypto/block-luks.c b/crypto/block-luks.c
> index 409ab50f20..48213abde7 100644
> --- a/crypto/block-luks.c
> +++ b/crypto/block-luks.c
> @@ -70,6 +70,8 @@ typedef struct QCryptoBlockLUKSKeySlot
> QCryptoBlockLUKSKeySlot;
>
> #define QCRYPTO_BLOCK_LUKS_SECTOR_SIZE 512LL
>
> +#define QCRYPTO_BLOCK_LUKS_DEFAULT_ITER_TIME 2000
> +
> static const char qcrypto_block_luks_magic[QCRYPTO_BLOCK_LUKS_MAGIC_LEN] = {
> 'L', 'U', 'K', 'S', 0xBA, 0xBE
> };
> @@ -199,13 +201,25 @@ QEMU_BUILD_BUG_ON(sizeof(struct QCryptoBlockLUKSHeader)
> != 592);
> struct QCryptoBlockLUKS {
> QCryptoBlockLUKSHeader header;
>
> -/* Cache parsed versions of what's in header fields,
> - * as we can't rely on QCryptoBlock.cipher being
> - * non-NULL */
> +/* Main encryption algorithm used for encryption*/
> QCryptoCipherAlgorithm cipher_alg;
> +
> +/* Mode of encryption for the selected encryption algorithm */
> QCryptoCipherMode cipher_mode;
> +
> +/* Initialization vector generation algorithm */
> QCryptoIVGenAlgorithm ivgen_alg;
> +
> +/* Hash algorithm used for IV generation*/
> QCryptoHashAlgorithm ivgen_hash_alg;
> +
> +/*
> + * Encryption algorithm used for IV generation.
> + * Usually the same as main encryption algorithm
> + */
> +QCryptoCipherAlgorithm ivgen_cipher_alg;
> +
> +/* Hash algorithm used in pbkdf2 function */
> QCryptoHashAlgorithm hash_alg;
> };
>
> @@ -397,6 +411,12 @@ qcrypto_block_luks_essiv_cipher(QCryptoCipherAlgorithm
> cipher,
> }
> }
>
> +static int masterkeylen(QCryptoBlockLUKS *luks)
> +{
> +return luks->header.key_bytes;
> +}
> +
> +
generally QEMU uses snake_case_names; please spell as "master_key_len".
> /*
> * Given a key slot, and user password, this will attempt to unlock
> * the master encryption key from the key slot.
> @@ -410,21 +430,15 @@ qcrypto_block_luks_essiv_cipher(QCryptoCipherAlgorithm
> cipher,
> */
> static int
> qcrypto_block_luks_load_key(QCryptoBlock *block,
> -QCryptoBlockLUKSKeySlot *slot,
> +uint slot_idx,
> const char *password,
> -QCryptoCipherAlgorithm cipheralg,
> -QCryptoCipherMode ciphermode,
> -QCryptoHashAlgorithm hash,
> -QCryptoIVGenAlgorithm ivalg,
> -QCryptoCipherAlgorithm ivcipheralg,
> -QCryptoHashAlgorithm ivhash,
> uint8_t *masterkey,
> -size_t masterkeylen,
> QCryptoBlockReadFunc readfunc,
> void *opaque,
> Error **errp)
> {
> QCryptoBlockLUKS *luks = block->opaque;
> +QCryptoBlockLUKSKeySlot *slot = >header.key_slots[slot_idx];
> uint8_t *splitkey;
> size_t splitkeylen;
> uint8_t *possiblekey;
> @@ -439,9 +453,9 @@ qcrypto_block_luks_load_key(QCryptoBlock *block,
> return 0;
> }
>
> -splitkeylen = masterkeylen * slot->stripes;
> +splitkeylen = masterkeylen(luks) * slot->stripes;
> splitkey = g_new0(uint8_t, splitkeylen);
> -possiblekey = g_new0(uint8_t, masterkeylen);
> +possiblekey = g_new0(uint8_t, masterkeylen(luks));
>
> /*
> * The user password is used to generate a (possible)
> @@ -450,11 +464,11 @@ qcrypto_block_luks_load_key(QCryptoBlock *block,
> * the key is correct and validate the results of
> * decryption later.
> */
> -if (qcrypto_pbkdf2(hash,
> +if (qcrypto_pbkdf2(luks->hash_alg,
> (const uint8_t *)password,
Re: [Qemu-devel] [PULL 04/32] target/riscv: Implement riscv_cpu_unassigned_access
On Tue, Aug 13, 2019 at 3:44 PM Palmer Dabbelt wrote: > > On Thu, 01 Aug 2019 08:39:17 PDT (-0700), Peter Maydell wrote: > > On Wed, 3 Jul 2019 at 09:41, Palmer Dabbelt wrote: > >> > >> From: Michael Clark > >> > >> This patch adds support for the riscv_cpu_unassigned_access call > >> and will raise a load or store access fault. > >> > >> Signed-off-by: Michael Clark > >> [Changes by AF: > >> - Squash two patches and rewrite commit message > >> - Set baddr to the access address > >> ] > >> Signed-off-by: Alistair Francis > >> Reviewed-by: Palmer Dabbelt > >> Signed-off-by: Palmer Dabbelt > > > > Oops, I missed seeing this go by. The do_unassigned_access > > hook is deprecated and you should drop this and use > > the do_transaction_failed hook instead. Argh! > > > > The distinction between the two is that do_unassigned_access > > will end up being called for any failing access, including > > not just "normal" guest accesses but also for bad accesses > > that happen during page table walks (which often want to > > be reported to the guest differently) and also accesses > > by random devices like DMA controllers (where throwing a > > cpu exception is always a bug). > > > > Changing the hook implementation itself should be straightforward; > > commit 6ad4d7eed05a1e23537f is an example of doing that on Alpha. > > You also want to check all the places in your target code that > > do physical memory accesses, determine what the right behaviour > > if they get a bus fault is, and implement that (or at least put > > in TODO comments). > > Sorry, updating that has been on my TODO list for a while now. I figured it > was better to have the deprecated version in there than nothing at all. I've > written some patches to fix this, but I want to give them another look before > sending them out. I was going to start looking into this, but if you already have patches I won't bother. Let me know if you want a hand with the conversion. Alistair >
[Qemu-devel] [PATCH v3 7/7] target/riscv: Convert mip to target_ulong
The mip register is an MXLEN-bit long register. Convert it to a
target_ulong type instead of uint32_t.
Signed-off-by: Alistair Francis
---
target/riscv/cpu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 2dc9b17678..0a7985c3f7 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -130,7 +130,7 @@ struct CPURISCVState {
* wuth the invariant that CPU_INTERRUPT_HARD is set iff mip is non-zero.
* mip is 32-bits to allow atomic_read on 32-bit hosts.
*/
-uint32_t mip;
+target_ulong mip;
uint32_t miclaim;
target_ulong mie;
--
2.22.0
[Qemu-devel] [PATCH v3 3/7] target/riscv: Create function to test if FP is enabled
Let's create a function that tests if floating point support is
enabled. We can then protect all floating point operations based on if
they are enabled.
This patch so far doesn't change anything, it's just preparing for the
Hypervisor support for floating point operations.
Signed-off-by: Alistair Francis
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Christophe de Dinechin
Reviewed-by: Chih-Min Chao
---
target/riscv/cpu.h| 6 +-
target/riscv/cpu_helper.c | 10 ++
target/riscv/csr.c| 20 +++-
3 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 0adb307f32..2dc9b17678 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -255,6 +255,7 @@ void riscv_cpu_do_interrupt(CPUState *cpu);
int riscv_cpu_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
int riscv_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
bool riscv_cpu_exec_interrupt(CPUState *cs, int interrupt_request);
+bool riscv_cpu_fp_enabled(CPURISCVState *env);
int riscv_cpu_mmu_index(CPURISCVState *env, bool ifetch);
hwaddr riscv_cpu_get_phys_page_debug(CPUState *cpu, vaddr addr);
void riscv_cpu_do_unaligned_access(CPUState *cs, vaddr addr,
@@ -298,7 +299,10 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState
*env, target_ulong *pc,
#ifdef CONFIG_USER_ONLY
*flags = TB_FLAGS_MSTATUS_FS;
#else
-*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
+*flags = cpu_mmu_index(env, 0);
+if (riscv_cpu_fp_enabled(env)) {
+*flags |= env->mstatus & MSTATUS_FS;
+}
#endif
}
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index f027be7f16..225e407cff 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -71,6 +71,16 @@ bool riscv_cpu_exec_interrupt(CPUState *cs, int
interrupt_request)
#if !defined(CONFIG_USER_ONLY)
+/* Return true is floating point support is currently enabled */
+bool riscv_cpu_fp_enabled(CPURISCVState *env)
+{
+if (env->mstatus & MSTATUS_FS) {
+return true;
+}
+
+return false;
+}
+
int riscv_cpu_claim_interrupts(RISCVCPU *cpu, uint32_t interrupts)
{
CPURISCVState *env = >env;
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index e0d4586760..2789215b5e 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -46,7 +46,7 @@ void riscv_set_csr_ops(int csrno, riscv_csr_operations *ops)
static int fs(CPURISCVState *env, int csrno)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
return -1;
}
#endif
@@ -108,7 +108,7 @@ static int pmp(CPURISCVState *env, int csrno)
static int read_fflags(CPURISCVState *env, int csrno, target_ulong *val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
return -1;
}
#endif
@@ -119,7 +119,7 @@ static int read_fflags(CPURISCVState *env, int csrno,
target_ulong *val)
static int write_fflags(CPURISCVState *env, int csrno, target_ulong val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
return -1;
}
env->mstatus |= MSTATUS_FS;
@@ -131,7 +131,7 @@ static int write_fflags(CPURISCVState *env, int csrno,
target_ulong val)
static int read_frm(CPURISCVState *env, int csrno, target_ulong *val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
return -1;
}
#endif
@@ -142,7 +142,7 @@ static int read_frm(CPURISCVState *env, int csrno,
target_ulong *val)
static int write_frm(CPURISCVState *env, int csrno, target_ulong val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
return -1;
}
env->mstatus |= MSTATUS_FS;
@@ -154,7 +154,7 @@ static int write_frm(CPURISCVState *env, int csrno,
target_ulong val)
static int read_fcsr(CPURISCVState *env, int csrno, target_ulong *val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
return -1;
}
#endif
@@ -166,7 +166,7 @@ static int read_fcsr(CPURISCVState *env, int csrno,
target_ulong *val)
static int write_fcsr(CPURISCVState *env, int csrno, target_ulong val)
{
#if !defined(CONFIG_USER_ONLY)
-if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
+if (!env->debugger && !riscv_cpu_fp_enabled(env)) {
return -1;
}
env->mstatus |= MSTATUS_FS;
@@ -307,6 +307,7 @@ static int write_mstatus(CPURISCVState *env, int csrno,
target_ulong val)
{
target_ulong mstatus = env->mstatus;
target_ulong mask
[Qemu-devel] [PATCH v3 2/7] riscv: plic: Remove unused interrupt functions
Signed-off-by: Alistair Francis
Reviewed-by: Jonathan Behrens
Reviewed-by: Philippe Mathieu-Daudé
Reviewed-by: Chih-Min Chao
---
hw/riscv/sifive_plic.c | 12
include/hw/riscv/sifive_plic.h | 3 ---
2 files changed, 15 deletions(-)
diff --git a/hw/riscv/sifive_plic.c b/hw/riscv/sifive_plic.c
index 0950e89e15..864a1bed42 100644
--- a/hw/riscv/sifive_plic.c
+++ b/hw/riscv/sifive_plic.c
@@ -161,18 +161,6 @@ static void sifive_plic_update(SiFivePLICState *plic)
}
}
-void sifive_plic_raise_irq(SiFivePLICState *plic, uint32_t irq)
-{
-sifive_plic_set_pending(plic, irq, true);
-sifive_plic_update(plic);
-}
-
-void sifive_plic_lower_irq(SiFivePLICState *plic, uint32_t irq)
-{
-sifive_plic_set_pending(plic, irq, false);
-sifive_plic_update(plic);
-}
-
static uint32_t sifive_plic_claim(SiFivePLICState *plic, uint32_t addrid)
{
int i, j;
diff --git a/include/hw/riscv/sifive_plic.h b/include/hw/riscv/sifive_plic.h
index ce8907f6aa..3b8a623919 100644
--- a/include/hw/riscv/sifive_plic.h
+++ b/include/hw/riscv/sifive_plic.h
@@ -69,9 +69,6 @@ typedef struct SiFivePLICState {
uint32_t aperture_size;
} SiFivePLICState;
-void sifive_plic_raise_irq(SiFivePLICState *plic, uint32_t irq);
-void sifive_plic_lower_irq(SiFivePLICState *plic, uint32_t irq);
-
DeviceState *sifive_plic_create(hwaddr addr, char *hart_config,
uint32_t num_sources, uint32_t num_priorities,
uint32_t priority_base, uint32_t pending_base,
--
2.22.0
[Qemu-devel] [PATCH v3 4/7] target/riscv: Update the Hypervisor CSRs to v0.4
Update the Hypervisor CSR addresses to match the v0.4 spec. Signed-off-by: Alistair Francis Reviewed-by: Chih-Min Chao --- target/riscv/cpu_bits.h | 35 ++- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h index 11f971ad5d..e99834856c 100644 --- a/target/riscv/cpu_bits.h +++ b/target/riscv/cpu_bits.h @@ -173,6 +173,24 @@ #define CSR_SPTBR 0x180 #define CSR_SATP0x180 +/* Hpervisor CSRs */ +#define CSR_HSTATUS 0x600 +#define CSR_HEDELEG 0x602 +#define CSR_HIDELEG 0x603 +#define CSR_HCOUNTERNEN 0x606 +#define CSR_HGATP 0x680 + +#if defined(TARGET_RISCV32) +#define HGATP_MODE SATP32_MODE +#define HGATP_VMID SATP32_ASID +#define HGATP_PPNSATP32_PPN +#endif +#if defined(TARGET_RISCV64) +#define HGATP_MODE SATP64_MODE +#define HGATP_VMID SATP64_ASID +#define HGATP_PPNSATP64_PPN +#endif + /* Physical Memory Protection */ #define CSR_PMPCFG0 0x3a0 #define CSR_PMPCFG1 0x3a1 @@ -206,23 +224,6 @@ #define CSR_DPC 0x7b1 #define CSR_DSCRATCH0x7b2 -/* Hpervisor CSRs */ -#define CSR_HSTATUS 0xa00 -#define CSR_HEDELEG 0xa02 -#define CSR_HIDELEG 0xa03 -#define CSR_HGATP 0xa80 - -#if defined(TARGET_RISCV32) -#define HGATP_MODE SATP32_MODE -#define HGATP_ASID SATP32_ASID -#define HGATP_PPNSATP32_PPN -#endif -#if defined(TARGET_RISCV64) -#define HGATP_MODE SATP64_MODE -#define HGATP_ASID SATP64_ASID -#define HGATP_PPNSATP64_PPN -#endif - /* Performance Counters */ #define CSR_MHPMCOUNTER30xb03 #define CSR_MHPMCOUNTER40xb04 -- 2.22.0
[Qemu-devel] [PATCH v3 0/7] RISC-V: Hypervisor prep work part 2
The first three patches are ones that I have pulled out of my original Hypervisor series at an attempt to reduce the number of patches in the series. These three patches all make sense without the Hypervisor series so can be merged seperatley and will reduce the review burden of the next version of the patches. The fource patch is a prep patch for the new v0.4 Hypervisor spec. The fifth patch is unreleated to Hypervisor that I'm just slipping in here because it seems easier then sending it by itself. The final two patches are issues I discovered while adding the v0.4 Hypervisor extension. v3: - Change names of all GP registers - Add two more patches v2: - Small corrections based on feedback - Remove the CSR permission check patch Alistair Francis (6): target/riscv: Don't set write permissions on dirty PTEs riscv: plic: Remove unused interrupt functions target/riscv: Create function to test if FP is enabled target/riscv: Update the Hypervisor CSRs to v0.4 target/riscv: Fix mstatus dirty mask target/riscv: Convert mip to target_ulong Atish Patra (1): target/riscv: Use both register name and ABI name hw/riscv/sifive_plic.c | 12 include/hw/riscv/sifive_plic.h | 3 --- target/riscv/cpu.c | 19 ++ target/riscv/cpu.h | 8 ++-- target/riscv/cpu_bits.h| 35 +- target/riscv/cpu_helper.c | 16 target/riscv/csr.c | 22 +++-- 7 files changed, 59 insertions(+), 56 deletions(-) -- 2.22.0
[Qemu-devel] [PATCH v3 6/7] target/riscv: Fix mstatus dirty mask
Signed-off-by: Alistair Francis --- target/riscv/csr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/riscv/csr.c b/target/riscv/csr.c index 2789215b5e..f767ad24be 100644 --- a/target/riscv/csr.c +++ b/target/riscv/csr.c @@ -335,7 +335,7 @@ static int write_mstatus(CPURISCVState *env, int csrno, target_ulong val) * RV32: MPV and MTL are not in mstatus. The current plan is to * add them to mstatush. For now, we just don't support it. */ -mask |= MSTATUS_MPP | MSTATUS_MPV; +mask |= MSTATUS_MTL | MSTATUS_MPV; #endif } -- 2.22.0
[Qemu-devel] [PATCH v3 1/7] target/riscv: Don't set write permissions on dirty PTEs
Setting write permission on dirty PTEs results in userspace inside a
Hypervisor guest (VU) becoming corrupted. This appears to be because it
ends up with write permission in the second stage translation in cases
where we aren't doing a store.
Signed-off-by: Alistair Francis
---
target/riscv/cpu_helper.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index e32b6126af..f027be7f16 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -340,10 +340,8 @@ restart:
if ((pte & PTE_X)) {
*prot |= PAGE_EXEC;
}
-/* add write permission on stores or if the page is already dirty,
- so that we TLB miss on later writes to update the dirty bit */
-if ((pte & PTE_W) &&
-(access_type == MMU_DATA_STORE || (pte & PTE_D))) {
+/* add write permission on stores */
+if ((pte & PTE_W) && (access_type == MMU_DATA_STORE)) {
*prot |= PAGE_WRITE;
}
return TRANSLATE_SUCCESS;
--
2.22.0
[Qemu-devel] [ANNOUNCE] QEMU 4.1.0 is now available
Hello, On behalf of the QEMU Team, I'd like to announce the availability of the QEMU 4.1.0 release. This release contains 2000+ commits from 176 authors. You can grab the tarball from our download page here: https://www.qemu.org/download/#source The full list of changes are available at: https://wiki.qemu.org/ChangeLog/4.1 Highlights include: * ARM: FPU emulation support for Cortex-M CPUs, FPU fixes for Cortex-R5F * ARM: ARMv8.5-RNG extension support for CPU-generated random numbers * ARM: board build options now configurable via new Kconfig-based system * ARM: Exynos4210 SoC model now supports PL330 DMA controllers * MIPS: improved emulation performance of numerous MSA instructions, mostly integer and data permuting operations * MIPS: improved support for MSA ASE instructions on big-endian hosts, handling for 'division by zero' cases now matches reference hardware * PowerPC: pseries: support for NVIDIA V100 GPU/NVLink2 passthrough via VFIO * PowerPC: pseries: in-kernel acceleration for XIVE interrupt controller * PowerPC: pseries: supporting for hot-plugging PCI host bridges * PowerPC: emulation optimizations for vector (Altivec/VSX) instructions * RISC-V: support for new "spike" machine model * RISC-V: ISA 1.11.0 support for privileged architectures * RISC-V: improvements for 32-bit syscall ABI, illegal instruction handling, and built-in debugger * RISC-V: support for CPU topology in device trees * s390: bios support for booting from ECKD DASD assigned to guest via vfio-ccw * s390: emulation support for all "Vector Facility" instructions * s390: additional facilities and support for gen15 machines, including support for AP Queue Interruption Facility for using interrupts for vfio-ap devices * SPARC: sun4m: sun4u: fixes when running with -vga none (OpenBIOS) * x86: emulation support for new Hygon Dhyana and Intel SnowRidge CPU models * x86: emulation support for RDRAND extension * x86: md-clear/mds-no feature flags, for detection/mitigation of MDS vulnerabilities (CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091) * x86: CPU die topology now configurable using -smp ...,dies= * Xtensa: support for memory protection unit (MPU) option * Xtensa: support for Exclusive Access option * GUI: virtio-gpu 2D/3D rendering may now be offloaded to an external vhost-user process, such as QEMU vhost-user-gpu * GUI: semihosting output can now be redirected to a chardev backend with -semihosting-config enable=on,target=native,chardev=[ID] * qemu-img: added a --salvage option to qemu-img convert, which prevents the conversion process from aborting on I/O errors (can be used for example to salvage partially corrupted qcow2 files) * qemu-img: qemu-img rebase works now even when the input file doesn't have a backing file yet * VMDK block driver now has read-only support for the seSparse subformat * GPIO: support for SiFive GPIO controller * and lots more... Thank you to everyone involved!
Re: [Qemu-devel] [libvirt] [PATCH 1/2] qapi: deprecate drive-mirror and drive-backup
On 8/15/19 3:44 AM, Peter Krempa wrote:
> On Wed, Aug 14, 2019 at 15:22:15 -0400, John Snow wrote:
>>
>>
>> On 8/14/19 6:07 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> It's hard and not necessary to maintain outdated versions of these
>>> commands.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>>> ---
>>> qemu-deprecated.texi | 4
>>> qapi/block-core.json | 4
>>> qapi/transaction.json | 2 +-
>>> blockdev.c| 10 ++
>>> 4 files changed, 19 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
>>> index fff07bb2a3..2753fafd0b 100644
>>> --- a/qemu-deprecated.texi
>>> +++ b/qemu-deprecated.texi
>>> @@ -179,6 +179,10 @@ and accurate ``query-qmp-schema'' command.
>>> Character devices creating sockets in client mode should not specify
>>> the 'wait' field, which is only applicable to sockets in server mode
>>>
>>> +@subsection drive-mirror, drive-backup and drive-backup transaction action
>>> (since 4.2)
>>> +
>>> +Use blockdev-mirror and blockdev-backup instead.
>>> +
>>> @section Human Monitor Protocol (HMP) commands
>>>
>>> @subsection The hub_id parameter of 'hostfwd_add' / 'hostfwd_remove'
>>> (since 3.1)
>
> [...]
>
>>> @@ -3831,6 +3838,9 @@ void qmp_drive_mirror(DriveMirror *arg, Error **errp)
>>> const char *format = arg->format;
>>> int ret;
>>>
>>> +warn_report("drive-mirror command is deprecated and will disappear in "
>>> +"future. Use blockdev-mirror instead");
>>> +
>>> bs = qmp_get_root_bs(arg->device, errp);
>>> if (!bs) {
>>> return;
>>>
>>
>> Hm!
>>
>> I wonder if this is ever-so-slightly too soon for our friends over at
>> the libvirt project.
>>
>> I don't think they have fully moved away from the non-blockdev
>> interfaces *just yet*, and I might encourage seeing the first full
>> libvirt release that does support and use it before we start the
>> deprecation clock.
>>
>> (Jst in case.)
>>
>> That's just me being very, very cautious though.
>>
>> Peter Krempa, how do you feel about this?
>
> Thanks for the heads up!
>
You're welcome!
> Currently libvirt does not use 'drive-backup' at all so that one can be
> deprecated immediately.
>
> In case of 'drive-mirror' the situation is a bit more complex:
>
> Libvirt uses 'drive-mirror' currently in the following places
>
> 1) virDomainBlockCopy API
> With blockdev integration enabled this will go away. Pathces are being
> reviewed:
>
> https://www.redhat.com/archives/libvir-list/2019-August/msg00295.html
>
> 2) VM migration with non-shared storage
> Currently uses 'drive-mirror' in most cases but there is pre-existing
> integration for blockdev-mirror for nbd+tls. I need to make sure that
> the blockdev version will be used unconditionally once the integration
> is enabled. This is a TODO.
>
> There is also one gotcha. In case when an 'sd' card device is used for
> the VM, libvirt disables all of blockdev, because SD cards can't be
> expressed with blockdev. There's too many code paths which would need
> checking to be worth it. To be fair, I'm not even sure when a sd card
> can be emulated by qemu as all of my basic tests failed and I did not
> care more.
>
> For libvirt to enable blockdev there's one more part missing and that's
> snapshot integration. I'm currently testing patches to integrate it with
> external snapshots, which should be posted soon.
>
> I also found a bug in qemu, which prevents creation of internal
> snapshots when -blockdev is used:
>
> When savevm HMP command is used (via QMP->HMP bridge) qemu invokes
> save_snapshot(), which calls bdrv_all_can_snapshot(). That function uses
> bdrv_next() to iterate all nodes which correspond to a block backend
> first, but then also iterates any other node which is monitor-owned.
>
> Since with blockdev all nodes including the ones for the 'file' protocol
> are monitor-owned, and 'file' does not support snapshots that check
> fails. A simple hack of skipping the second part in bdrv_next() allows
> to do a snapshot actually. Kevin told me that the idea is that also
> non-attached nodes should be considered for internal snapshod which is
> okay in my opinion, but given how the snapshot works for the files
> attached to backeds (and also in pre-blockdev use) only the top level of
> a chain should ever be considered for snapshot.
>
> So the summary is, that I'm pretty hopeful that we should be able to get
> rid of all reasonable uses of drive-mirror very soon after I finish
> snapshot integration. The only question is how much
> we care about SD card users being able to do a drive-mirror in the
> future.
>
OK. It sounds like we should hold off on deprecating these for now
because it's not certain which libvirt release will no longer need them,
but it sounds like it's hopefully not far off.
--js
Re: [Qemu-devel] [PATCH v2 0/7] vmdk: Misc fixes
On 8/15/19 11:36 AM, Max Reitz wrote: > I made the mistake of trying to run the iotests with all non-default > subformats our vmdk driver has to offer: > - monolithicFlat > - twoGbMaxExtentSparse > - twoGbMaxExtentFlat > - streamOptimized > > Many things broke, so this series fixes what I found. It’s mostly just > iotest fixes, but there are actually two real fixes in here. > > > v2: > - Patch 2: Don’t treat extent filenames with protocol prefixes as > absolute filenames – this may be the right thing to do, but: > (1) path_combine() doesn’t (it just ignores whether the supposed > relative filename has a potential protocol prefix), so this is how > we handled it so far, > (2) It would break other cases (when a filename contains a colon for > no particular reason), as seen in iotest 126. > That means you cannot have an extent file e.g. on an http server while > the descriptor is on a local filesystem, but I hope nobody would ever > want to do that. > I guess we'll fix it if it comes up. > - Patch 3: Fix paste-o [John] > > - Patch 7: twoGbMaxExtentSparse works now with the change to patch 2, so > we no longer have to mark it unsupported [Thanks for the insistent > inquiry, John :-)] > Thanks for fixing the "weird" formats! Reviewed-by: John Snow > > git-backport-diff against v1: > > Key: > [] : patches are identical > [] : number of functional differences between upstream/downstream patch > [down] : patch is downstream-only > The flags [FC] indicate (F)unctional and (C)ontextual differences, > respectively > > 001/7:[] [--] 'iotests: Fix _filter_img_create()' > 002/7:[0002] [FC] 'vmdk: Use bdrv_dirname() for relative extent paths' > 003/7:[0002] [FC] 'iotests: Keep testing broken relative extent paths' > 004/7:[] [--] 'vmdk: Reject invalid compressed writes' > 005/7:[] [--] 'iotests: Disable broken streamOptimized tests' > 006/7:[] [--] 'iotests: Disable 110 for vmdk.twoGbMaxExtentSparse' > 007/7:[0006] [FC] 'iotests: Disable 126 for some vmdk subformats' > > > Max Reitz (7): > iotests: Fix _filter_img_create() > vmdk: Use bdrv_dirname() for relative extent paths > iotests: Keep testing broken relative extent paths > vmdk: Reject invalid compressed writes > iotests: Disable broken streamOptimized tests > iotests: Disable 110 for vmdk.twoGbMaxExtentSparse > iotests: Disable 126 for flat vmdk subformats > > block/vmdk.c | 64 ++-- > tests/qemu-iotests/002 | 1 + > tests/qemu-iotests/003 | 1 + > tests/qemu-iotests/005 | 3 +- > tests/qemu-iotests/009 | 1 + > tests/qemu-iotests/010 | 1 + > tests/qemu-iotests/011 | 1 + > tests/qemu-iotests/017 | 3 +- > tests/qemu-iotests/018 | 3 +- > tests/qemu-iotests/019 | 3 +- > tests/qemu-iotests/020 | 3 +- > tests/qemu-iotests/027 | 1 + > tests/qemu-iotests/032 | 1 + > tests/qemu-iotests/033 | 1 + > tests/qemu-iotests/034 | 3 +- > tests/qemu-iotests/037 | 3 +- > tests/qemu-iotests/059 | 34 - > tests/qemu-iotests/059.out | 24 +++- > tests/qemu-iotests/063 | 3 +- > tests/qemu-iotests/072 | 1 + > tests/qemu-iotests/105 | 3 +- > tests/qemu-iotests/110 | 3 +- > tests/qemu-iotests/126 | 2 + > tests/qemu-iotests/197 | 1 + > tests/qemu-iotests/215 | 1 + > tests/qemu-iotests/251 | 1 + > tests/qemu-iotests/common.filter | 4 +- > 27 files changed, 127 insertions(+), 43 deletions(-) > -- —js
[Qemu-devel] [Bug 1839428] Re: qemu core dumped when repeat "system_reset" multiple times during guest boot
** Changed in: qemu Status: New => Confirmed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1839428 Title: qemu core dumped when repeat "system_reset" multiple times during guest boot Status in QEMU: Confirmed Bug description: commit 864ab314f1d924129d06ac7b571f105a2b76a4b2 (HEAD, tag: v4.1.0-rc4, origin/master, origin/HEAD, master) Test arch:x86 and power Steps: 1.Boot up guest with command power cmdline: /usr/libexec/backup/qemu-kvm \ -smp 8 \ -m 4096 \ -nodefaults \ -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x7 \ -drive file=rhel77-ppc64le-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none \ -chardev stdio,mux=on,id=serial_id_serial0,server,nowait,signal=off \ -device spapr-vty,id=serial111,chardev=serial_id_serial0 \ -mon chardev=serial_id_serial0,mode=readline \ x86 cmdline: /usr/libexec/qemu-kvm \ -m 4096 -smp 8 \ -boot menu=on \ -device virtio-blk-pci,id=image1,drive=drive_image1\ -drive file=rhel77-64-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none \ -vga std \ -vnc :9 \ -nographic \ -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:84 \ -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on \ 2.when guest start to boot up kernel(when no output infomation),run hmp command "system_reset" Result: Sometimes,qemu core dumped with error as following: system_reset (qemu) qemu-system-ppc64: /root/qemu/hw/virtio/virtio.c:225: vring_get_region_caches: Assertion `caches != NULL' failed. b.sh: line 11: 73679 Aborted (core dumped) /usr/local/bin/qemu-system-ppc64 -enable-kvm -smp 8 -m 4096 -nodefaults -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x7 -drive file=rhel77-ppc64le-virtio.qcow2,if=none,id=drive_image1,format=qcow2,cache=none -chardev stdio,mux=on,id=serial_id_serial0,server,nowait,signal=off -device spapr-vty,id=serial111,chardev=serial_id_serial0 -mon chardev=serial_id_serial0,mode=readline To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1839428/+subscriptions
Re: [Qemu-devel] current QEMU can't start pc-q35-2.12 SEV guest
On Thu, 2019-08-15 at 15:43 -0300, Eduardo Habkost wrote:
> On Thu, Aug 15, 2019 at 12:49:58AM +, Bruce Rogers wrote:
> > Hi,
> >
> > I ran into a case where a guest on a SEV capable host, which was
> > enabled to use SEV and using an older machine type was no longer
> > able
> > to run when the QEMU version had been updated.
> >
> > Specifically, when the guest was installed and running under a
> > v2.12
> > QEMU, set up for SEV (ok it was v2.11 with SEV support backported,
> > but
> > the details still apply), using a command line such as follows:
> >
> > qemu-system-x86_64 -cpu EPYC-IBRS \
> > -machine pc-q35-2.12,accel=kvm,memory-encryption=sev0 \
> > -object sev-guest,id=sev0,...
> >
> > The guest ran fine, using SEV memory enryption.
> >
> > Later the version of QEMU was updated to v3.1.0, and the same guest
> > now
> > hung at boot, when using the exact same command line. (Current QEMU
> > still has the same problem.)
> >
> > Upon investigation, I find that the handling of xlevel in
> > target/i386/cpu.c relies includes an explicit detection of SEV
> > being
> > enabled and sets the cpuid_min_xlevel in the CPUX86State structure
> > to
> > 0x801F as the required minimum for SEV support. This normally
> > is
> > used to set the xlevel the guest sees, allowing it to use SEV.
> >
> > The compat settings for the v2.12 machine type include an xlevel
> > value
> > associated with it (0x800A). Unfortunately the processing of
> > the
> > compat settings gets conflated with the logic of handling a user
> > explicitly specifying an xlevel on the command line, which is
> > treated
> > as an "override" condition, overriding the other xlevel selections
> > which would otherwise be done in the QEMU cpu code.
> >
> > So, in the scenario I describe above, the original, working case
> > would
> > provide an cpuid xlevel value of 0x801F to the guest (correct),
> > and
> > the failing case ends up providing the value 0x800A
> > (incorrect).
> >
> > It seems to me that the handling of the compat settings and the
> > explicit xlevel setting by the user should be processed separately,
> > but
> > I don't see how to do that easily.
> >
> > How should this problem be resolved?
> >
> > In my case, I've added to the code which is for checking a user
> > provided xlevel value, the check again for sev_enabled(), and if
> > that's
> > the case, I still apply the cpuid_min_xlevel value. This works for
> > the
> > time being, but doesn't seem to be the right solution.
> >
>
> I believe this is my fault. On commit e00516475c27 ("i386:
> Enable TOPOEXT feature on AMD EPYC CPU"), I had added
> xlevel=0x800A compat entries, but they were supposed to be
> min-xlevel=0x800A.
>
> Does this patch solve the problem?
>
> ---
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 549c437050..11d5a3cd3a 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -154,8 +154,8 @@ const size_t pc_compat_3_0_len =
> G_N_ELEMENTS(pc_compat_3_0);
> GlobalProperty pc_compat_2_12[] = {
> { TYPE_X86_CPU, "legacy-cache", "on" },
> { TYPE_X86_CPU, "topoext", "off" },
> -{ "EPYC-" TYPE_X86_CPU, "xlevel", "0x800a" },
> -{ "EPYC-IBPB-" TYPE_X86_CPU, "xlevel", "0x800a" },
> +{ "EPYC-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
> +{ "EPYC-IBPB-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
> };
> const size_t pc_compat_2_12_len = G_N_ELEMENTS(pc_compat_2_12);
>
>
Yes that does the trick.
My analysis was a bit off the mark. This makes more sense than what I
was doing.
Thanks!
Bruce
Re: [Qemu-devel] [RFC v2] hw/sd/aspeed_sdhci: New device
On 8/15/19 3:13 PM, Eddie James wrote:
On 8/15/19 3:05 AM, Cédric Le Goater wrote:
Hello Eddie,
On 14/08/2019 22:27, Eddie James wrote:
+ sdhci->slots[0].capareg = (uint64_t)(uint32_t)val;
+ break;
+ case ASPEED_SDHCI_SDIO_148:
+ sdhci->slots[0].maxcurr = (uint64_t)(uint32_t)val;
+ break;
+ case ASPEED_SDHCI_SDIO_240:
+ sdhci->slots[1].capareg = (uint64_t)(uint32_t)val;
+ break;
+ case ASPEED_SDHCI_SDIO_248:
+ sdhci->slots[1].maxcurr = (uint64_t)(uint32_t)val;
+ break;
I think these regs are readonly.
Well the actual regs at slot + 0x40/0x48 are indeed, but not the
Aspeed-specific ones that mirror there. I think the idea is that
Aspeed-specific code can set it's capabilities differently if desired.
This may prevent the use of alias regions here.
Actually I could be wrong after reading the specs again. It's a little
confusing. I'm fine with making it read-only anyway, I doubt there will
be any code that needs to write it.
+ default:
+ if (addr < ASPEED_SDHCI_REG_SIZE) {
+ sdhci->regs[TO_REG(addr)] = (uint32_t)val;
+ }
+ }
+}
+
+static const MemoryRegionOps aspeed_sdhci_ops = {
+ .read = aspeed_sdhci_read,
+ .write = aspeed_sdhci_write,
+ .endianness = DEVICE_NATIVE_ENDIAN,
+ .valid.min_access_size = 4,
Re: [Qemu-devel] [RFC v2] hw/sd/aspeed_sdhci: New device
On 8/15/19 3:05 AM, Cédric Le Goater wrote:
Hello Eddie,
On 14/08/2019 22:27, Eddie James wrote:
The Aspeed SOCs have two SD/MMC controllers. Add a device that
encapsulates both of these controllers and models the Aspeed-specific
registers and behavior.
Tested by reading from mmcblk0 in Linux:
qemu-system-arm -machine romulus-bmc -nographic -serial mon:stdio \
-drive file=_tmp/flash-romulus,format=raw,if=mtd \
-device sd-card,drive=sd0 -drive file=_tmp/kernel,format=raw,if=sd
Signed-off-by: Eddie James
---
This patch applies on top of Cedric's set of recent Aspeed changes. Therefore,
I'm sending as an RFC rather than a patch.
yes. we can worked that out when the patch is reviewed. You can base on
mainline when ready. My tree serves as an overall test base.
Changes since v1:
- Move slot realize code into the Aspeed SDHCI realize function
- Fix interrupt handling by creating input irqs and connecting them to the
slot irqs.
- Removed card device creation code
I think all the code is here but it needs some more reshuffling :)
The raspi machine is a good source for modelling pratices.
hw/arm/aspeed.c | 1 -
hw/arm/aspeed_soc.c | 24 ++
hw/sd/Makefile.objs | 1 +
hw/sd/aspeed_sdhci.c | 190 +++
include/hw/arm/aspeed_soc.h | 3 +
include/hw/sd/aspeed_sdhci.h | 35
6 files changed, 253 insertions(+), 1 deletion(-)
create mode 100644 hw/sd/aspeed_sdhci.c
create mode 100644 include/hw/sd/aspeed_sdhci.h
diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 2574425..aeed5b6 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -480,7 +480,6 @@ static void aspeed_machine_class_init(ObjectClass *oc, void
*data)
mc->desc = board->desc;
mc->init = aspeed_machine_init;
mc->max_cpus = ASPEED_CPUS_NUM;
-mc->no_sdcard = 1;
mc->no_floppy = 1;
mc->no_cdrom = 1;
mc->no_parallel = 1;
diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index 8df96f2..a12f14a 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -22,6 +22,7 @@
#include "qemu/error-report.h"
#include "hw/i2c/aspeed_i2c.h"
#include "net/net.h"
+#include "sysemu/blockdev.h"
I would expect block devices to be handled at the machine level in
aspeed.c, like the flash devices are. Something like :
OK, I did have that in v1 but Peter mentioned it was typically done at
the command line? I guess it can go in aspeed.c too.
/* Create and plug in the SD cards */
for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; i++) {
BusState *bus;
DriveInfo *di = drive_get_next(IF_SD);
BlockBackend *blk = di ? blk_by_legacy_dinfo(di) : NULL;
DeviceState *carddev;
bus = qdev_get_child_bus(DEVICE(>soc), "sd-bus");
if (!bus) {
error_report("No SD bus found for SD card %d", i);
exit(1);
}
carddev = qdev_create(bus, TYPE_SD_CARD);
qdev_prop_set_drive(carddev, "drive", blk, _fatal);
object_property_set_bool(OBJECT(carddev), true, "realized",
_fatal);
}
#define ASPEED_SOC_IOMEM_SIZE 0x0020
@@ -62,6 +63,7 @@ static const hwaddr aspeed_soc_ast2500_memmap[] = {
[ASPEED_XDMA] = 0x1E6E7000,
[ASPEED_ADC]= 0x1E6E9000,
[ASPEED_SRAM] = 0x1E72,
+[ASPEED_SDHCI] = 0x1E74,
[ASPEED_GPIO] = 0x1E78,
[ASPEED_RTC]= 0x1E781000,
[ASPEED_TIMER1] = 0x1E782000,
@@ -100,6 +102,7 @@ static const hwaddr aspeed_soc_ast2600_memmap[] = {
[ASPEED_XDMA] = 0x1E6E7000,
[ASPEED_ADC]= 0x1E6E9000,
[ASPEED_VIDEO] = 0x1E70,
+[ASPEED_SDHCI] = 0x1E74,
[ASPEED_GPIO] = 0x1E78,
[ASPEED_RTC]= 0x1E781000,
[ASPEED_TIMER1] = 0x1E782000,
@@ -146,6 +149,7 @@ static const int aspeed_soc_ast2400_irqmap[] = {
[ASPEED_ETH1] = 2,
[ASPEED_ETH2] = 3,
[ASPEED_XDMA] = 6,
+[ASPEED_SDHCI] = 26,
};
#define aspeed_soc_ast2500_irqmap aspeed_soc_ast2400_irqmap
@@ -163,6 +167,7 @@ static const int aspeed_soc_ast2600_irqmap[] = {
[ASPEED_SDMC] = 0,
[ASPEED_SCU]= 12,
[ASPEED_XDMA] = 6,
+[ASPEED_SDHCI] = 43,
[ASPEED_ADC]= 46,
[ASPEED_GPIO] = 40,
[ASPEED_RTC]= 13,
@@ -350,6 +355,15 @@ static void aspeed_soc_init(Object *obj)
sysbus_init_child_obj(obj, "fsi[*]", OBJECT(>fsi[0]),
sizeof(s->fsi[0]), TYPE_ASPEED_FSI);
}
+
+sysbus_init_child_obj(obj, "sdhci", OBJECT(>sdhci), sizeof(s->sdhci),
+ TYPE_ASPEED_SDHCI);
This is the Aspeed SD host interface. May be we should call it sdhost ?
I suppose this is our "sd-bus" device ?
+/* Init sd card slot class here so that they're under the correct parent */
+for (i = 0; i < ASPEED_SDHCI_NUM_SLOTS; ++i) {
and these are the slots, I
Re: [Qemu-devel] [PATCH 2/3] pc: Improve error message when die-id is omitted
Reviewed-by: Vanderson M. do Rosario
Vanderson M. Rosario
On Thu, Aug 15, 2019 at 3:43 PM Eduardo Habkost wrote:
> The error message when die-id is omitted doesn't make sense:
>
> $ qemu-system-x86_64 -smp 1,sockets=6,maxcpus=6 \
> -device qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0
> qemu-system-x86_64: -device
> qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0: \
> Invalid CPU die-id: 4294967295 must be in range 0:0
>
> Fix it, so it will now read:
>
> qemu-system-x86_64: -device
> qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0: \
> CPU die-id is not set
>
> Signed-off-by: Eduardo Habkost
> ---
> hw/i386/pc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 24b03bb49c..fb4ac5ca90 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -2410,6 +2410,10 @@ static void pc_cpu_pre_plug(HotplugHandler
> *hotplug_dev,
> error_setg(errp, "Invalid CPU socket-id: %u must be in range
> 0:%u",
> cpu->socket_id, max_socket);
> return;
> +}
> +if (cpu->die_id < 0) {
> +error_setg(errp, "CPU die-id is not set");
> +return;
> } else if (cpu->die_id > pcms->smp_dies - 1) {
> error_setg(errp, "Invalid CPU die-id: %u must be in range
> 0:%u",
> cpu->die_id, pcms->smp_dies - 1);
> --
> 2.21.0
>
>
>
Re: [Qemu-devel] [PATCH 1/3] pc: Fix error message on die-id validation
Reviewed-by: Vanderson M. do Rosario
Vanderson M. Rosario
On Thu, Aug 15, 2019 at 3:48 PM Eduardo Habkost wrote:
> The error message for die-id range validation is incorrect. Example:
>
> $ qemu-system-x86_64 -smp 1,sockets=6,maxcpus=6 \
> -device qemu64-x86_64-cpu,socket-id=1,die-id=1,core-id=0,thread-id=0
> qemu-system-x86_64: -device
> qemu64-x86_64-cpu,socket-id=1,die-id=1,core-id=0,thread-id=0: \
> Invalid CPU die-id: 1 must be in range 0:5
>
> The actual range for die-id in this example is 0:0.
>
> Fix the error message to use smp_dies and print the correct range.
>
> Signed-off-by: Eduardo Habkost
> ---
> hw/i386/pc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 549c437050..24b03bb49c 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -2412,7 +2412,7 @@ static void pc_cpu_pre_plug(HotplugHandler
> *hotplug_dev,
> return;
> } else if (cpu->die_id > pcms->smp_dies - 1) {
> error_setg(errp, "Invalid CPU die-id: %u must be in range
> 0:%u",
> - cpu->die_id, max_socket);
> + cpu->die_id, pcms->smp_dies - 1);
> return;
> }
> if (cpu->core_id < 0) {
> --
> 2.21.0
>
>
>
Re: [Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections
On Thu, Aug 15, 2019 at 01:50:24PM -0500, Eric Blake wrote:
> The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
> advertised when the server promises cache consistency between
> simultaneous clients (basically, rules that determine what FUA and
> flush from one client are able to guarantee for reads from another
> client). When we don't permit simultaneous clients (such as qemu-nbd
> without -e), the bit makes no sense; and for writable images, we
> probably have a lot more work before we can declare that actions from
> one client are cache-consistent with actions from another. But for
> read-only images, where flush isn't changing any data, we might as
> well advertise multi-conn support. What's more, advertisement of the
> bit makes it easier for clients to determine if 'qemu-nbd -e' was in
> use, where a second connection will succeed rather than hang until the
> first client goes away.
>
> This patch affects qemu as server in advertising the bit. We may want
> to consider patches to qemu as client to attempt parallel connections
> for higher throughput by spreading the load over those connections
> when a server advertises multi-conn, but for now sticking to one
> connection per nbd:// BDS is okay.
>
> See also: https://bugzilla.redhat.com/1708300
> Signed-off-by: Eric Blake
> ---
> docs/interop/nbd.txt | 1 +
> include/block/nbd.h | 2 +-
> blockdev-nbd.c | 2 +-
> nbd/server.c | 4 +++-
> qemu-nbd.c | 2 +-
> 5 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
> index fc64473e02b2..6dfec7f47647 100644
> --- a/docs/interop/nbd.txt
> +++ b/docs/interop/nbd.txt
> @@ -53,3 +53,4 @@ the operation of that feature.
> * 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
> * 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
> NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
> +* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports
> diff --git a/include/block/nbd.h b/include/block/nbd.h
> index 7b36d672f046..991fd52a5134 100644
> --- a/include/block/nbd.h
> +++ b/include/block/nbd.h
> @@ -326,7 +326,7 @@ typedef struct NBDClient NBDClient;
>
> NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
>uint64_t size, const char *name, const char *desc,
> - const char *bitmap, uint16_t nbdflags,
> + const char *bitmap, uint16_t nbdflags, bool shared,
>void (*close)(NBDExport *), bool writethrough,
>BlockBackend *on_eject_blk, Error **errp);
> void nbd_export_close(NBDExport *exp);
> diff --git a/blockdev-nbd.c b/blockdev-nbd.c
> index 66eebab31875..e5d228771292 100644
> --- a/blockdev-nbd.c
> +++ b/blockdev-nbd.c
> @@ -189,7 +189,7 @@ void qmp_nbd_server_add(const char *device, bool
> has_name, const char *name,
> }
>
> exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
> - writable ? 0 : NBD_FLAG_READ_ONLY,
> + writable ? 0 : NBD_FLAG_READ_ONLY, true,
> NULL, false, on_eject_blk, errp);
> if (!exp) {
> return;
> diff --git a/nbd/server.c b/nbd/server.c
> index a2cf085f7635..a602d85070ff 100644
> --- a/nbd/server.c
> +++ b/nbd/server.c
> @@ -1460,7 +1460,7 @@ static void nbd_eject_notifier(Notifier *n, void *data)
>
> NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
>uint64_t size, const char *name, const char *desc,
> - const char *bitmap, uint16_t nbdflags,
> + const char *bitmap, uint16_t nbdflags, bool shared,
>void (*close)(NBDExport *), bool writethrough,
>BlockBackend *on_eject_blk, Error **errp)
> {
> @@ -1486,6 +1486,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs,
> uint64_t dev_offset,
> perm = BLK_PERM_CONSISTENT_READ;
> if ((nbdflags & NBD_FLAG_READ_ONLY) == 0) {
> perm |= BLK_PERM_WRITE;
> +} else if (shared) {
> +nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
> }
> blk = blk_new(bdrv_get_aio_context(bs), perm,
>BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
> diff --git a/qemu-nbd.c b/qemu-nbd.c
> index 049645491dab..55f5ceaf5c92 100644
> --- a/qemu-nbd.c
> +++ b/qemu-nbd.c
> @@ -1173,7 +1173,7 @@ int main(int argc, char **argv)
> }
>
> export = nbd_export_new(bs, dev_offset, fd_size, export_name,
> -export_description, bitmap, nbdflags,
> +export_description, bitmap, nbdflags, shared > 1,
> nbd_export_closed, writethrough, NULL,
> _fatal);
>
Multi-conn is a no-brainer. For nbdkit it more than doubled
throughput:
Re: [Qemu-devel] [PATCH v2 0/3] colo: Add support for continious replication
On Thu, 15 Aug 2019 19:57:37 +0100 "Dr. David Alan Gilbert" wrote: > * Lukas Straub (lukasstra...@web.de) wrote: > > Hello Everyone, > > These Patches add support for continious replication to colo. > > Please review. > > > OK, for those who haven't followed COLO for so long; 'continuous > replication' is when after the first primary fails, you can promote the > original secondary to a new primary and start replicating again; > > i.e. current COLO gives you > > p<->s > > s > > with your patches you can do > > s becomes p2 > p2<->s2 > > and you're back to being resilient again. > > Which is great; because that was always an important missing piece. > > Do you have some test scripts/setup for this - it would be great > to automate some testing. My Plan is to write a Pacemaker Resource Agent[1] for qemu-colo and then do some long-term testing in my small cluster here. Writing standalone tests using that Resource Agent should be easy, it just needs to be provided with the right arguments and environment Variables. Regards, Lukas Straub [1] https://github.com/ClusterLabs/resource-agents/blob/master/doc/dev-guides/ra-dev-guide.asc#what-is-a-resource-agent
Re: [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit filters
Kevin Wolf writes:
> Am 15.08.2019 um 18:07 hat John Snow geschrieben:
>>
>>
>> On 8/15/19 6:49 AM, Kevin Wolf wrote:
>> > Am 14.08.2019 um 21:27 hat John Snow geschrieben:
>> >>
>> >>
>> >> On 8/14/19 6:07 AM, Vladimir Sementsov-Ogievskiy wrote:
>> >>> To get rid of implicit filters related workarounds in future let's
>> >>> deprecate them now.
>> >>>
>> >>> Signed-off-by: Vladimir Sementsov-Ogievskiy
>> >>> ---
>> >>> qemu-deprecated.texi | 7 +++
>> >>> qapi/block-core.json | 6 --
>> >>> include/block/block_int.h | 10 +-
>> >>> blockdev.c| 10 ++
>> >>> 4 files changed, 30 insertions(+), 3 deletions(-)
>> >>>
>> >>> diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
>> >>> index 2753fafd0b..8222440148 100644
>> >>> --- a/qemu-deprecated.texi
>> >>> +++ b/qemu-deprecated.texi
>> >>> @@ -183,6 +183,13 @@ the 'wait' field, which is only applicable to
>> >>> sockets in server mode
>> >>>
>> >>> Use blockdev-mirror and blockdev-backup instead.
>> >>>
>> >>> +@subsection implicit filters (since 4.2)
>> >>> +
>> >>> +Mirror and commit jobs inserts filters, which becomes implicit if user
>> >>> +omitted filter-node-name parameter. So omitting it is deprecated, set it
>> >>> +always. Note, that drive-mirror don't have this parameter, so it will
>> >>> +create implicit filter anyway, but drive-mirror is deprecated itself
>> >>> too.
>> >>> +
>> >>> @section Human Monitor Protocol (HMP) commands
>> >>>
>> >>> @subsection The hub_id parameter of 'hostfwd_add' / 'hostfwd_remove'
>> >>> (since 3.1)
>> >>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>> >>> index 4e35526634..0505ac9d8b 100644
>> >>> --- a/qapi/block-core.json
>> >>> +++ b/qapi/block-core.json
>> >>> @@ -1596,7 +1596,8 @@
>> >>> # @filter-node-name: the node name that should be assigned to the
>> >>> #filter driver that the commit job inserts into the
>> >>> graph
>> >>> #above @top. If this option is not given, a node
>> >>> name is
>> >>> -#autogenerated. (Since: 2.9)
>> >>> +#autogenerated. Omitting this option is deprecated,
>> >>> it will
>> >>> +#be required in future. (Since: 2.9)
>> >>> #
>> >>> # @auto-finalize: When false, this job will wait in a PENDING state
>> >>> after it has
>> >>> # finished its work, waiting for @block-job-finalize
>> >>> before
>> >>> @@ -2249,7 +2250,8 @@
>> >>> # @filter-node-name: the node name that should be assigned to the
>> >>> #filter driver that the mirror job inserts into the
>> >>> graph
>> >>> #above @device. If this option is not given, a node
>> >>> name is
>> >>> -#autogenerated. (Since: 2.9)
>> >>> +#autogenerated. Omitting this option is deprecated,
>> >>> it will
>> >>> +#be required in future. (Since: 2.9)
>> >>> #
>> >>> # @copy-mode: when to copy data to the destination; defaults to
>> >>> 'background'
>> >>> # (Since: 3.0)
>> >>> diff --git a/include/block/block_int.h b/include/block/block_int.h
>> >>> index 3aa1e832a8..624da0b4a2 100644
>> >>> --- a/include/block/block_int.h
>> >>> +++ b/include/block/block_int.h
>> >>> @@ -762,7 +762,15 @@ struct BlockDriverState {
>> >>> bool sg;/* if true, the device is a /dev/sg* */
>> >>> bool probed;/* if true, format was probed rather than specified
>> >>> */
>> >>> bool force_share; /* if true, always allow all shared permissions */
>> >>> -bool implicit; /* if true, this filter node was automatically
>> >>> inserted */
>> >>> +
>> >>> +/*
>> >>> + * @implicit field is deprecated, don't set it to true for new
>> >>> filters.
>> >>> + * If true, this filter node was automatically inserted and user
>> >>> don't
>> >>> + * know about it and unprepared for any effects of it. So, implicit
>> >>> + * filters are workarounded and skipped in many places of the block
>> >>> + * layer code.
>> >>> + */
>> >>> +bool implicit;
>> >>>
>> >>> BlockDriver *drv; /* NULL means no media */
>> >>> void *opaque;
>> >>> diff --git a/blockdev.c b/blockdev.c
>> >>> index 36e9368e01..b3cfaccce1 100644
>> >>> --- a/blockdev.c
>> >>> +++ b/blockdev.c
>> >>> @@ -3292,6 +3292,11 @@ void qmp_block_commit(bool has_job_id, const char
>> >>> *job_id, const char *device,
>> >>> BlockdevOnError on_error = BLOCKDEV_ON_ERROR_REPORT;
>> >>> int job_flags = JOB_DEFAULT;
>> >>>
>> >>> +if (!has_filter_node_name) {
>> >>> +warn_report("Omitting filter-node-name parameter is deprecated,
>> >>> it "
>> >>> +"will be required in future");
>> >>> +}
>> >>> +
>> >>> if (!has_speed) {
>> >>> speed = 0;
>> >>> }
>> >>> @@ -3990,6 +3995,11 @@ void qmp_blockdev_mirror(bool has_job_id, const
>> >>> char *job_id,
>> >>>
[Qemu-devel] [Bug 1836453] Re: "qemu-nsis\*.bmp" -> no files found" when building with MXE
Fix has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=b3ce38dcf93a1203
** Changed in: qemu
Status: New => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1836453
Title:
"qemu-nsis\*.bmp" -> no files found" when building with MXE
Status in QEMU:
Fix Released
Bug description:
Already reported for 4.0:
https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg07005.html
host: Docker qemu:debian-win32-cross
$ make installer
(cd /tmp/qemu-nsis; \
for i in qemu-system-*.exe; do \
arch=${i%.exe}; \
arch=${arch#qemu-system-}; \
echo Section \"$arch\" Section_$arch; \
echo SetOutPath \"\$INSTDIR\"; \
echo File \"\${BINDIR}\\$i\"; \
echo SectionEnd; \
done \
) >/tmp/qemu-nsis/system-emulations.nsh
makensis -V2 -NOCD \
-DCONFIG_DOCUMENTATION="y" \
\
-DBINDIR="/tmp/qemu-nsis" \
\
-DSRCDIR="/source/qemu" \
-DOUTFILE="qemu-setup-4.0.90.exe" \
-DDISPLAYVERSION="4.0.90" \
/source/qemu/qemu.nsi
File: "/tmp/qemu-nsis\*.bmp" -> no files found.
Usage: File [/nonfatal] [/a] ([/r] [/x filespec [...]] filespec [...] |
/oname=outfile one_file_only)
Error in script "/source/qemu/qemu.nsi" on line 122 -- aborting creation
process
Makefile:1077: recipe for target 'qemu-setup-4.0.90.exe' failed
make: *** [qemu-setup-4.0.90.exe] Error 1
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1836453/+subscriptions
Re: [Qemu-devel] [PATCH v2 1/3] Replication: Ignore requests after failover
* Lukas Straub (lukasstra...@web.de) wrote:
> After failover the Secondary side of replication shouldn't change state,
> because
> it now functions as our primary disk.
>
> In replication_start, replication_do_checkpoint, replication_stop, ignore
> the request if current state is BLOCK_REPLICATION_DONE (sucessful failover) or
> BLOCK_REPLICATION_FAILOVER (failover in progres i.e. currently merging active
> and hidden images into the base image).
>
> Signed-off-by: Lukas Straub
We should add some block people to this one to review it; cc'ing in
Kevin and Max.
Dave
> ---
> block/replication.c | 38 +++---
> 1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/block/replication.c b/block/replication.c
> index 3d4dedddfc..97cc65c0cf 100644
> --- a/block/replication.c
> +++ b/block/replication.c
> @@ -454,6 +454,17 @@ static void replication_start(ReplicationState *rs,
> ReplicationMode mode,
> aio_context_acquire(aio_context);
> s = bs->opaque;
>
> +if (s->stage == BLOCK_REPLICATION_DONE ||
> +s->stage == BLOCK_REPLICATION_FAILOVER) {
> +/*
> + * This case happens when a secondary is promoted to primary.
> + * Ignore the request because the secondary side of replication
> + * doesn't have to do anything anymore.
> + */
> +aio_context_release(aio_context);
> +return;
> +}
> +
> if (s->stage != BLOCK_REPLICATION_NONE) {
> error_setg(errp, "Block replication is running or done");
> aio_context_release(aio_context);
> @@ -529,8 +540,7 @@ static void replication_start(ReplicationState *rs,
> ReplicationMode mode,
> "Block device is in use by internal backup job");
>
> top_bs = bdrv_lookup_bs(s->top_id, s->top_id, NULL);
> -if (!top_bs || !bdrv_is_root_node(top_bs) ||
> -!check_top_bs(top_bs, bs)) {
> +if (!top_bs || !check_top_bs(top_bs, bs)) {
> error_setg(errp, "No top_bs or it is invalid");
> reopen_backing_file(bs, false, NULL);
> aio_context_release(aio_context);
> @@ -577,6 +587,17 @@ static void replication_do_checkpoint(ReplicationState
> *rs, Error **errp)
> aio_context_acquire(aio_context);
> s = bs->opaque;
>
> +if (s->stage == BLOCK_REPLICATION_DONE ||
> +s->stage == BLOCK_REPLICATION_FAILOVER) {
> +/*
> + * This case happens when a secondary was promoted to primary.
> + * Ignore the request because the secondary side of replication
> + * doesn't have to do anything anymore.
> + */
> +aio_context_release(aio_context);
> +return;
> +}
> +
> if (s->mode == REPLICATION_MODE_SECONDARY) {
> secondary_do_checkpoint(s, errp);
> }
> @@ -593,7 +614,7 @@ static void replication_get_error(ReplicationState *rs,
> Error **errp)
> aio_context_acquire(aio_context);
> s = bs->opaque;
>
> -if (s->stage != BLOCK_REPLICATION_RUNNING) {
> +if (s->stage == BLOCK_REPLICATION_NONE) {
> error_setg(errp, "Block replication is not running");
> aio_context_release(aio_context);
> return;
> @@ -635,6 +656,17 @@ static void replication_stop(ReplicationState *rs, bool
> failover, Error **errp)
> aio_context_acquire(aio_context);
> s = bs->opaque;
>
> +if (s->stage == BLOCK_REPLICATION_DONE ||
> +s->stage == BLOCK_REPLICATION_FAILOVER) {
> +/*
> + * This case happens when a secondary was promoted to primary.
> + * Ignore the request because the secondary side of replication
> + * doesn't have to do anything anymore.
> + */
> +aio_context_release(aio_context);
> +return;
> +}
> +
> if (s->stage != BLOCK_REPLICATION_RUNNING) {
> error_setg(errp, "Block replication is not running");
> aio_context_release(aio_context);
> --
> 2.20.1
>
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [Qemu-devel] [PATCH v2 0/3] colo: Add support for continious replication
* Lukas Straub (lukasstra...@web.de) wrote: > Hello Everyone, > These Patches add support for continious replication to colo. > Please review. OK, for those who haven't followed COLO for so long; 'continuous replication' is when after the first primary fails, you can promote the original secondary to a new primary and start replicating again; i.e. current COLO gives you p<->s s with your patches you can do s becomes p2 p2<->s2 and you're back to being resilient again. Which is great; because that was always an important missing piece. Do you have some test scripts/setup for this - it would be great to automate some testing. Dave > Regards, > Lukas Straub > > v2: > - fix email formating > - fix checkpatch.pl warnings > - fix patchew error > - clearer commit messages > > Lukas Straub (3): > Replication: Ignore requests after failover > net/filter.c: Add Options to insert filters anywhere in the filter > list > Update Documentation > > block/replication.c | 38 - > docs/COLO-FT.txt | 185 --- > include/net/filter.h | 2 + > net/filter.c | 71 - > qemu-options.hx | 10 +-- > 5 files changed, 250 insertions(+), 56 deletions(-) > > -- > 2.20.1 > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
[Qemu-devel] [Bug 1832914] Re: Wrong error log when drive is specified qcow but qcow2 image file used.
Fix has been included here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=197bfa7da7c8eeb39aa5 ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1832914 Title: Wrong error log when drive is specified qcow but qcow2 image file used. Status in QEMU: Fix Released Bug description: On archlinux qemu version 4.0.0 when I type: $ qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ... I get this output in stderr qemu-system-x86_64 -drive format=qcow,file=image.qcow2 ...: Unsupported qcow version 3 image.qcow2 is a qcow2 image created by qemu-img. error states that problem is with lack support with qcow3 format but real problem is that foramt=qcow is wrong option. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1832914/+subscriptions
[Qemu-devel] [PATCH v2 0/3] colo: Add support for continious replication
Hello Everyone, These Patches add support for continious replication to colo. Please review. Regards, Lukas Straub v2: - fix email formating - fix checkpatch.pl warnings - fix patchew error - clearer commit messages Lukas Straub (3): Replication: Ignore requests after failover net/filter.c: Add Options to insert filters anywhere in the filter list Update Documentation block/replication.c | 38 - docs/COLO-FT.txt | 185 --- include/net/filter.h | 2 + net/filter.c | 71 - qemu-options.hx | 10 +-- 5 files changed, 250 insertions(+), 56 deletions(-) -- 2.20.1
[Qemu-devel] [Bug 1828272] Re: 4.0 breaks keyboard autorepeat in guests with xserver
Fix has been included here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=5fff13f245cddd3bc26 ** Changed in: qemu Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1828272 Title: 4.0 breaks keyboard autorepeat in guests with xserver Status in QEMU: Fix Released Bug description: Description: In a linux/bsd guest within X, pressing and holding a key for a short time causes an endless repeat of that key in the guest. The release of the key gets ignored. Example 1: pressing and holding 'a' for a few seconds results in typing of '...' endlessly. Example 2: pressing and holding 'Backspace' for a few seconds results in deleting all your previously typed text. It doesn't happen within a VT in the guest. It also doesn't happen with guests that run windows, reactos or haiku for example. The problem goes away when disabling xorgs autorepeat function via "xset -r" in the host. Normally, this setting should not have any effect on the guest, since it has it's own autorepeat setting. So there is some conflict here. Steps to reproduce: Start any linux/bsd guest system with xserver, open a terminal, press and hold a key for a short time: Look how it gets typed endlessly (Try a few times if it doesn't happen immediately). The easiest way is to run a linux live cd, like this (Link to example iso :http://download.grml.org/grml64-full_2018.12.iso) $ qemu-system-x86_64 -enable-kvm -m 512 -net none -boot d -cdrom grml64-full_2018.12.iso Qemu version info: QEMU emulator version 4.0.0 Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers System info: Linux 5.0.13-arch1-1-ARCH #1 SMP PREEMPT Sun May 5 18:05:41 UTC 2019 x86_64 GNU/Linux To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1828272/+subscriptions
[Qemu-devel] [PATCH] nbd: Advertise multi-conn for shared read-only connections
The NBD specification defines NBD_FLAG_CAN_MULTI_CONN, which can be
advertised when the server promises cache consistency between
simultaneous clients (basically, rules that determine what FUA and
flush from one client are able to guarantee for reads from another
client). When we don't permit simultaneous clients (such as qemu-nbd
without -e), the bit makes no sense; and for writable images, we
probably have a lot more work before we can declare that actions from
one client are cache-consistent with actions from another. But for
read-only images, where flush isn't changing any data, we might as
well advertise multi-conn support. What's more, advertisement of the
bit makes it easier for clients to determine if 'qemu-nbd -e' was in
use, where a second connection will succeed rather than hang until the
first client goes away.
This patch affects qemu as server in advertising the bit. We may want
to consider patches to qemu as client to attempt parallel connections
for higher throughput by spreading the load over those connections
when a server advertises multi-conn, but for now sticking to one
connection per nbd:// BDS is okay.
See also: https://bugzilla.redhat.com/1708300
Signed-off-by: Eric Blake
---
docs/interop/nbd.txt | 1 +
include/block/nbd.h | 2 +-
blockdev-nbd.c | 2 +-
nbd/server.c | 4 +++-
qemu-nbd.c | 2 +-
5 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/docs/interop/nbd.txt b/docs/interop/nbd.txt
index fc64473e02b2..6dfec7f47647 100644
--- a/docs/interop/nbd.txt
+++ b/docs/interop/nbd.txt
@@ -53,3 +53,4 @@ the operation of that feature.
* 2.12: NBD_CMD_BLOCK_STATUS for "base:allocation"
* 3.0: NBD_OPT_STARTTLS with TLS Pre-Shared Keys (PSK),
NBD_CMD_BLOCK_STATUS for "qemu:dirty-bitmap:", NBD_CMD_CACHE
+* 4.2: NBD_FLAG_CAN_MULTI_CONN for sharable read-only exports
diff --git a/include/block/nbd.h b/include/block/nbd.h
index 7b36d672f046..991fd52a5134 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -326,7 +326,7 @@ typedef struct NBDClient NBDClient;
NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
uint64_t size, const char *name, const char *desc,
- const char *bitmap, uint16_t nbdflags,
+ const char *bitmap, uint16_t nbdflags, bool shared,
void (*close)(NBDExport *), bool writethrough,
BlockBackend *on_eject_blk, Error **errp);
void nbd_export_close(NBDExport *exp);
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index 66eebab31875..e5d228771292 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -189,7 +189,7 @@ void qmp_nbd_server_add(const char *device, bool has_name,
const char *name,
}
exp = nbd_export_new(bs, 0, len, name, NULL, bitmap,
- writable ? 0 : NBD_FLAG_READ_ONLY,
+ writable ? 0 : NBD_FLAG_READ_ONLY, true,
NULL, false, on_eject_blk, errp);
if (!exp) {
return;
diff --git a/nbd/server.c b/nbd/server.c
index a2cf085f7635..a602d85070ff 100644
--- a/nbd/server.c
+++ b/nbd/server.c
@@ -1460,7 +1460,7 @@ static void nbd_eject_notifier(Notifier *n, void *data)
NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t dev_offset,
uint64_t size, const char *name, const char *desc,
- const char *bitmap, uint16_t nbdflags,
+ const char *bitmap, uint16_t nbdflags, bool shared,
void (*close)(NBDExport *), bool writethrough,
BlockBackend *on_eject_blk, Error **errp)
{
@@ -1486,6 +1486,8 @@ NBDExport *nbd_export_new(BlockDriverState *bs, uint64_t
dev_offset,
perm = BLK_PERM_CONSISTENT_READ;
if ((nbdflags & NBD_FLAG_READ_ONLY) == 0) {
perm |= BLK_PERM_WRITE;
+} else if (shared) {
+nbdflags |= NBD_FLAG_CAN_MULTI_CONN;
}
blk = blk_new(bdrv_get_aio_context(bs), perm,
BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 049645491dab..55f5ceaf5c92 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -1173,7 +1173,7 @@ int main(int argc, char **argv)
}
export = nbd_export_new(bs, dev_offset, fd_size, export_name,
-export_description, bitmap, nbdflags,
+export_description, bitmap, nbdflags, shared > 1,
nbd_export_closed, writethrough, NULL,
_fatal);
--
2.20.1
[Qemu-devel] [PATCH v2 3/3] Update Documentation
Document the qemu command-line and qmp commands for continious replication
Signed-off-by: Lukas Straub
---
docs/COLO-FT.txt | 185 +++
1 file changed, 138 insertions(+), 47 deletions(-)
diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt
index ad24680d13..c08bfbd3a8 100644
--- a/docs/COLO-FT.txt
+++ b/docs/COLO-FT.txt
@@ -145,35 +145,64 @@ The diagram just shows the main qmp command, you can get
the detail
in test procedure.
== Test procedure ==
+Note: Here we are running both instances on the same Machine for testing,
+change the IP Addresses if you want to run it on two Hosts
+
1. Startup qemu
Primary:
-# qemu-system-x86_64 -accel kvm -m 2048 -smp 2 -qmp stdio -name primary \
- -device piix3-usb-uhci -vnc :7 \
- -device usb-tablet -netdev tap,id=hn0,vhost=off \
- -device virtio-net-pci,id=net-pci0,netdev=hn0 \
- -drive
if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
- children.0.file.filename=1.raw,\
- children.0.driver=raw -S
+# imagefolder="/mnt/vms/colo-test"
+
+# cp --reflink=auto $imagefolder/primary.qcow2 $imagefolder/primary-copy.qcow2
+
+# qemu-system-x86_64 -enable-kvm -cpu qemu64,+kvmclock -m 512 -smp 1 -qmp
stdio \
+ -vnc :0 -k de -device piix3-usb-uhci -device usb-tablet -name primary \
+ -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
+ -device rtl8139,id=e0,netdev=hn0 \
+ -chardev socket,id=mirror0,host=127.0.0.1,port=9003,server,nowait \
+ -chardev socket,id=compare1,host=127.0.0.1,port=9004,server,wait \
+ -chardev socket,id=compare0,host=127.0.0.1,port=9001,server,nowait \
+ -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \
+ -chardev socket,id=compare_out,host=127.0.0.1,port=9005,server,nowait \
+ -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \
+ -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \
+ -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \
+ -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \
+ -object iothread,id=iothread1 \
+ -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\
+outdev=compare_out0,iothread=iothread1 \
+ -drive
if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
+children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -S
+
Secondary:
-# qemu-system-x86_64 -accel kvm -m 2048 -smp 2 -qmp stdio -name secondary \
- -device piix3-usb-uhci -vnc :7 \
- -device usb-tablet -netdev tap,id=hn0,vhost=off \
- -device virtio-net-pci,id=net-pci0,netdev=hn0 \
- -drive
if=none,id=secondary-disk0,file.filename=1.raw,driver=raw,node-name=node0 \
- -drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
- file.driver=qcow2,top-id=active-disk0,\
- file.file.filename=/mnt/ramfs/active_disk.img,\
- file.backing.driver=qcow2,\
- file.backing.file.filename=/mnt/ramfs/hidden_disk.img,\
- file.backing.backing=secondary-disk0 \
- -incoming tcp:0:
+# imagefolder="/mnt/vms/colo-test"
+
+# qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G
+
+# qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G
+
+# qemu-system-x86_64 -enable-kvm -cpu qemu64,+kvmclock -m 512 -smp 1 -qmp
stdio \
+ -vnc :1 -k de -device piix3-usb-uhci -device usb-tablet -name secondary \
+ -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
+ -device rtl8139,id=e0,netdev=hn0 \
+ -chardev socket,id=red0,host=127.0.0.1,port=9003,reconnect=1 \
+ -chardev socket,id=red1,host=127.0.0.1,port=9004,reconnect=1 \
+ -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \
+ -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \
+ -object filter-rewriter,id=rew0,netdev=hn0,queue=all \
+ -drive
if=none,id=parent0,file.filename=$imagefolder/primary-copy.qcow2,driver=qcow2 \
+ -drive
if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\
+top-id=childs0,file.file.filename=$imagefolder/secondary-active.qcow2,\
+file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\
+file.backing.backing=parent0 \
+ -drive
if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
+children.0.file=childs0,children.0.driver=raw \
+ -incoming tcp:0:9998
+
2. On Secondary VM's QEMU monitor, issue command
{'execute':'qmp_capabilities'}
-{ 'execute': 'nbd-server-start',
- 'arguments': {'addr': {'type': 'inet', 'data': {'host': 'xx.xx.xx.xx',
'port': '8889'} } }
-}
-{'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0',
'writable': true } }
+{'execute': 'nbd-server-start', 'arguments': {'addr': {'type': 'inet', 'data':
{'host': '127.0.0.1', 'port': ''} } } }
+{'execute': 'nbd-server-add', 'arguments': {'device': 'parent0', 'writable':
true } }
Note:
a. The qmp command nbd-server-start and nbd-server-add
[Qemu-devel] [PATCH v2 2/3] net/filter.c: Add Options to insert filters anywhere in the filter list
To switch the Secondary to Primary, we need to insert new filters
before the filter-rewriter.
Add the options insert= and position= to be able to insert filters
anywhere in the filter list.
position should be either "head", "tail" or the id of another filter.
insert should be either "before" or "after" to specify where to
insert the new filter relative to the one specified with position.
Signed-off-by: Lukas Straub
---
include/net/filter.h | 2 ++
net/filter.c | 71 +++-
qemu-options.hx | 10 +++
3 files changed, 77 insertions(+), 6 deletions(-)
diff --git a/include/net/filter.h b/include/net/filter.h
index 49da666ac0..355c178f75 100644
--- a/include/net/filter.h
+++ b/include/net/filter.h
@@ -62,6 +62,8 @@ struct NetFilterState {
NetClientState *netdev;
NetFilterDirection direction;
bool on;
+char *position;
+bool insert_before;
QTAILQ_ENTRY(NetFilterState) next;
};
diff --git a/net/filter.c b/net/filter.c
index 28d1930db7..309fd778df 100644
--- a/net/filter.c
+++ b/net/filter.c
@@ -171,11 +171,47 @@ static void netfilter_set_status(Object *obj, const char
*str, Error **errp)
}
}
+static char *netfilter_get_position(Object *obj, Error **errp)
+{
+NetFilterState *nf = NETFILTER(obj);
+
+return g_strdup(nf->position);
+}
+
+static void netfilter_set_position(Object *obj, const char *str, Error **errp)
+{
+NetFilterState *nf = NETFILTER(obj);
+
+nf->position = g_strdup(str);
+}
+
+static char *netfilter_get_insert(Object *obj, Error **errp)
+{
+NetFilterState *nf = NETFILTER(obj);
+
+return nf->insert_before ? g_strdup("before") : g_strdup("after");
+}
+
+static void netfilter_set_insert(Object *obj, const char *str, Error **errp)
+{
+NetFilterState *nf = NETFILTER(obj);
+
+if (strcmp(str, "before") && strcmp(str, "after")) {
+error_setg(errp, "Invalid value for netfilter insert, "
+ "should be 'head' or 'tail'");
+return;
+}
+
+nf->insert_before = !strcmp(str, "before");
+}
+
static void netfilter_init(Object *obj)
{
NetFilterState *nf = NETFILTER(obj);
nf->on = true;
+nf->insert_before = false;
+nf->position = g_strdup("tail");
object_property_add_str(obj, "netdev",
netfilter_get_netdev_id, netfilter_set_netdev_id,
@@ -187,11 +223,18 @@ static void netfilter_init(Object *obj)
object_property_add_str(obj, "status",
netfilter_get_status, netfilter_set_status,
NULL);
+object_property_add_str(obj, "position",
+netfilter_get_position, netfilter_set_position,
+NULL);
+object_property_add_str(obj, "insert",
+netfilter_get_insert, netfilter_set_insert,
+NULL);
}
static void netfilter_complete(UserCreatable *uc, Error **errp)
{
NetFilterState *nf = NETFILTER(uc);
+NetFilterState *position = NULL;
NetClientState *ncs[MAX_QUEUE_NUM];
NetFilterClass *nfc = NETFILTER_GET_CLASS(uc);
int queues;
@@ -219,6 +262,20 @@ static void netfilter_complete(UserCreatable *uc, Error
**errp)
return;
}
+if (strcmp(nf->position, "head") && strcmp(nf->position, "tail")) {
+/* Search for the position to insert before/after */
+Object *container;
+Object *obj;
+
+container = object_get_objects_root();
+obj = object_resolve_path_component(container, nf->position);
+if (!obj) {
+error_setg(errp, "filter '%s' not found", nf->position);
+return;
+}
+position = NETFILTER(obj);
+}
+
nf->netdev = ncs[0];
if (nfc->setup) {
@@ -228,7 +285,18 @@ static void netfilter_complete(UserCreatable *uc, Error
**errp)
return;
}
}
-QTAILQ_INSERT_TAIL(>netdev->filters, nf, next);
+
+if (position) {
+if (nf->insert_before) {
+QTAILQ_INSERT_BEFORE(position, nf, next);
+} else {
+QTAILQ_INSERT_AFTER(>netdev->filters, position, nf, next);
+}
+} else if (!strcmp(nf->position, "head")) {
+QTAILQ_INSERT_HEAD(>netdev->filters, nf, next);
+} else if (!strcmp(nf->position, "tail")) {
+QTAILQ_INSERT_TAIL(>netdev->filters, nf, next);
+}
}
static void netfilter_finalize(Object *obj)
@@ -245,6 +313,7 @@ static void netfilter_finalize(Object *obj)
QTAILQ_REMOVE(>netdev->filters, nf, next);
}
g_free(nf->netdev_id);
+g_free(nf->position);
}
static void default_handle_event(NetFilterState *nf, int event, Error **errp)
diff --git a/qemu-options.hx b/qemu-options.hx
index 08749a3391..f0a47a0746 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -4368,7 +4368,7 @@ applications, they can do this through this parameter.
Its format is
a gnutls priority string as described at
[Qemu-devel] [PATCH v2 1/3] Replication: Ignore requests after failover
After failover the Secondary side of replication shouldn't change state, because
it now functions as our primary disk.
In replication_start, replication_do_checkpoint, replication_stop, ignore
the request if current state is BLOCK_REPLICATION_DONE (sucessful failover) or
BLOCK_REPLICATION_FAILOVER (failover in progres i.e. currently merging active
and hidden images into the base image).
Signed-off-by: Lukas Straub
---
block/replication.c | 38 +++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/block/replication.c b/block/replication.c
index 3d4dedddfc..97cc65c0cf 100644
--- a/block/replication.c
+++ b/block/replication.c
@@ -454,6 +454,17 @@ static void replication_start(ReplicationState *rs,
ReplicationMode mode,
aio_context_acquire(aio_context);
s = bs->opaque;
+if (s->stage == BLOCK_REPLICATION_DONE ||
+s->stage == BLOCK_REPLICATION_FAILOVER) {
+/*
+ * This case happens when a secondary is promoted to primary.
+ * Ignore the request because the secondary side of replication
+ * doesn't have to do anything anymore.
+ */
+aio_context_release(aio_context);
+return;
+}
+
if (s->stage != BLOCK_REPLICATION_NONE) {
error_setg(errp, "Block replication is running or done");
aio_context_release(aio_context);
@@ -529,8 +540,7 @@ static void replication_start(ReplicationState *rs,
ReplicationMode mode,
"Block device is in use by internal backup job");
top_bs = bdrv_lookup_bs(s->top_id, s->top_id, NULL);
-if (!top_bs || !bdrv_is_root_node(top_bs) ||
-!check_top_bs(top_bs, bs)) {
+if (!top_bs || !check_top_bs(top_bs, bs)) {
error_setg(errp, "No top_bs or it is invalid");
reopen_backing_file(bs, false, NULL);
aio_context_release(aio_context);
@@ -577,6 +587,17 @@ static void replication_do_checkpoint(ReplicationState
*rs, Error **errp)
aio_context_acquire(aio_context);
s = bs->opaque;
+if (s->stage == BLOCK_REPLICATION_DONE ||
+s->stage == BLOCK_REPLICATION_FAILOVER) {
+/*
+ * This case happens when a secondary was promoted to primary.
+ * Ignore the request because the secondary side of replication
+ * doesn't have to do anything anymore.
+ */
+aio_context_release(aio_context);
+return;
+}
+
if (s->mode == REPLICATION_MODE_SECONDARY) {
secondary_do_checkpoint(s, errp);
}
@@ -593,7 +614,7 @@ static void replication_get_error(ReplicationState *rs,
Error **errp)
aio_context_acquire(aio_context);
s = bs->opaque;
-if (s->stage != BLOCK_REPLICATION_RUNNING) {
+if (s->stage == BLOCK_REPLICATION_NONE) {
error_setg(errp, "Block replication is not running");
aio_context_release(aio_context);
return;
@@ -635,6 +656,17 @@ static void replication_stop(ReplicationState *rs, bool
failover, Error **errp)
aio_context_acquire(aio_context);
s = bs->opaque;
+if (s->stage == BLOCK_REPLICATION_DONE ||
+s->stage == BLOCK_REPLICATION_FAILOVER) {
+/*
+ * This case happens when a secondary was promoted to primary.
+ * Ignore the request because the secondary side of replication
+ * doesn't have to do anything anymore.
+ */
+aio_context_release(aio_context);
+return;
+}
+
if (s->stage != BLOCK_REPLICATION_RUNNING) {
error_setg(errp, "Block replication is not running");
aio_context_release(aio_context);
--
2.20.1
[Qemu-devel] [PATCH 1/3] pc: Fix error message on die-id validation
The error message for die-id range validation is incorrect. Example:
$ qemu-system-x86_64 -smp 1,sockets=6,maxcpus=6 \
-device qemu64-x86_64-cpu,socket-id=1,die-id=1,core-id=0,thread-id=0
qemu-system-x86_64: -device
qemu64-x86_64-cpu,socket-id=1,die-id=1,core-id=0,thread-id=0: \
Invalid CPU die-id: 1 must be in range 0:5
The actual range for die-id in this example is 0:0.
Fix the error message to use smp_dies and print the correct range.
Signed-off-by: Eduardo Habkost
---
hw/i386/pc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 549c437050..24b03bb49c 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2412,7 +2412,7 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
return;
} else if (cpu->die_id > pcms->smp_dies - 1) {
error_setg(errp, "Invalid CPU die-id: %u must be in range 0:%u",
- cpu->die_id, max_socket);
+ cpu->die_id, pcms->smp_dies - 1);
return;
}
if (cpu->core_id < 0) {
--
2.21.0
Re: [Qemu-devel] current QEMU can't start pc-q35-2.12 SEV guest
On Thu, Aug 15, 2019 at 12:49:58AM +, Bruce Rogers wrote:
> Hi,
>
> I ran into a case where a guest on a SEV capable host, which was
> enabled to use SEV and using an older machine type was no longer able
> to run when the QEMU version had been updated.
>
> Specifically, when the guest was installed and running under a v2.12
> QEMU, set up for SEV (ok it was v2.11 with SEV support backported, but
> the details still apply), using a command line such as follows:
>
> qemu-system-x86_64 -cpu EPYC-IBRS \
> -machine pc-q35-2.12,accel=kvm,memory-encryption=sev0 \
> -object sev-guest,id=sev0,...
>
> The guest ran fine, using SEV memory enryption.
>
> Later the version of QEMU was updated to v3.1.0, and the same guest now
> hung at boot, when using the exact same command line. (Current QEMU
> still has the same problem.)
>
> Upon investigation, I find that the handling of xlevel in
> target/i386/cpu.c relies includes an explicit detection of SEV being
> enabled and sets the cpuid_min_xlevel in the CPUX86State structure to
> 0x801F as the required minimum for SEV support. This normally is
> used to set the xlevel the guest sees, allowing it to use SEV.
>
> The compat settings for the v2.12 machine type include an xlevel value
> associated with it (0x800A). Unfortunately the processing of the
> compat settings gets conflated with the logic of handling a user
> explicitly specifying an xlevel on the command line, which is treated
> as an "override" condition, overriding the other xlevel selections
> which would otherwise be done in the QEMU cpu code.
>
> So, in the scenario I describe above, the original, working case would
> provide an cpuid xlevel value of 0x801F to the guest (correct), and
> the failing case ends up providing the value 0x800A (incorrect).
>
> It seems to me that the handling of the compat settings and the
> explicit xlevel setting by the user should be processed separately, but
> I don't see how to do that easily.
>
> How should this problem be resolved?
>
> In my case, I've added to the code which is for checking a user
> provided xlevel value, the check again for sev_enabled(), and if that's
> the case, I still apply the cpuid_min_xlevel value. This works for the
> time being, but doesn't seem to be the right solution.
>
I believe this is my fault. On commit e00516475c27 ("i386:
Enable TOPOEXT feature on AMD EPYC CPU"), I had added
xlevel=0x800A compat entries, but they were supposed to be
min-xlevel=0x800A.
Does this patch solve the problem?
---
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 549c437050..11d5a3cd3a 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -154,8 +154,8 @@ const size_t pc_compat_3_0_len =
G_N_ELEMENTS(pc_compat_3_0);
GlobalProperty pc_compat_2_12[] = {
{ TYPE_X86_CPU, "legacy-cache", "on" },
{ TYPE_X86_CPU, "topoext", "off" },
-{ "EPYC-" TYPE_X86_CPU, "xlevel", "0x800a" },
-{ "EPYC-IBPB-" TYPE_X86_CPU, "xlevel", "0x800a" },
+{ "EPYC-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
+{ "EPYC-IBPB-" TYPE_X86_CPU, "min-xlevel", "0x800a" },
};
const size_t pc_compat_2_12_len = G_N_ELEMENTS(pc_compat_2_12);
--
Eduardo
[Qemu-devel] [PULL 6/9] block/nbd: use non-blocking io channel for nbd negotiation
From: Vladimir Sementsov-Ogievskiy
No reason to use blocking channel for negotiation and we'll benefit in
further reconnect feature, as qio_channel reads and writes will do
qemu_coroutine_yield while waiting for io completion.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Message-Id: <20190618114328.55249-3-vsement...@virtuozzo.com>
Signed-off-by: Eric Blake
---
include/block/nbd.h | 3 ++-
block/nbd.c | 16 +++-
nbd/client.c| 16 +++-
qemu-nbd.c | 2 +-
4 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/include/block/nbd.h b/include/block/nbd.h
index bb9f5bc0216f..7b36d672f046 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -304,7 +304,8 @@ struct NBDExportInfo {
};
typedef struct NBDExportInfo NBDExportInfo;
-int nbd_receive_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
+int nbd_receive_negotiate(AioContext *aio_context, QIOChannel *ioc,
+ QCryptoTLSCreds *tlscreds,
const char *hostname, QIOChannel **outioc,
NBDExportInfo *info, Error **errp);
void nbd_free_export_list(NBDExportInfo *info, int count);
diff --git a/block/nbd.c b/block/nbd.c
index c16d02528b2f..3a243d9de96e 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1175,6 +1175,7 @@ static int nbd_client_connect(BlockDriverState *bs,
Error **errp)
{
BDRVNBDState *s = (BDRVNBDState *)bs->opaque;
+AioContext *aio_context = bdrv_get_aio_context(bs);
int ret;
/*
@@ -1189,15 +1190,16 @@ static int nbd_client_connect(BlockDriverState *bs,
/* NBD handshake */
trace_nbd_client_connect(export);
-qio_channel_set_blocking(QIO_CHANNEL(sioc), true, NULL);
+qio_channel_set_blocking(QIO_CHANNEL(sioc), false, NULL);
+qio_channel_attach_aio_context(QIO_CHANNEL(sioc), aio_context);
s->info.request_sizes = true;
s->info.structured_reply = true;
s->info.base_allocation = true;
s->info.x_dirty_bitmap = g_strdup(x_dirty_bitmap);
s->info.name = g_strdup(export ?: "");
-ret = nbd_receive_negotiate(QIO_CHANNEL(sioc), tlscreds, hostname,
->ioc, >info, errp);
+ret = nbd_receive_negotiate(aio_context, QIO_CHANNEL(sioc), tlscreds,
+hostname, >ioc, >info, errp);
g_free(s->info.x_dirty_bitmap);
g_free(s->info.name);
if (ret < 0) {
@@ -1231,18 +1233,14 @@ static int nbd_client_connect(BlockDriverState *bs,
object_ref(OBJECT(s->ioc));
}
-qio_channel_set_blocking(QIO_CHANNEL(sioc), false, NULL);
-qio_channel_attach_aio_context(s->ioc, bdrv_get_aio_context(bs));
-
trace_nbd_client_connect_success(export);
return 0;
fail:
/*
- * We have connected, but must fail for other reasons. The
- * connection is still blocking; send NBD_CMD_DISC as a courtesy
- * to the server.
+ * We have connected, but must fail for other reasons.
+ * Send NBD_CMD_DISC as a courtesy to the server.
*/
{
NBDRequest request = { .type = NBD_CMD_DISC };
diff --git a/nbd/client.c b/nbd/client.c
index 4de30630c738..8f524c3e3502 100644
--- a/nbd/client.c
+++ b/nbd/client.c
@@ -867,7 +867,8 @@ static int nbd_list_meta_contexts(QIOChannel *ioc,
* 2: server is newstyle, but lacks structured replies
* 3: server is newstyle and set up for structured replies
*/
-static int nbd_start_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
+static int nbd_start_negotiate(AioContext *aio_context, QIOChannel *ioc,
+ QCryptoTLSCreds *tlscreds,
const char *hostname, QIOChannel **outioc,
bool structured_reply, bool *zeroes,
Error **errp)
@@ -934,6 +935,10 @@ static int nbd_start_negotiate(QIOChannel *ioc,
QCryptoTLSCreds *tlscreds,
return -EINVAL;
}
ioc = *outioc;
+if (aio_context) {
+qio_channel_set_blocking(ioc, false, NULL);
+qio_channel_attach_aio_context(ioc, aio_context);
+}
} else {
error_setg(errp, "Server does not support STARTTLS");
return -EINVAL;
@@ -998,7 +1003,8 @@ static int nbd_negotiate_finish_oldstyle(QIOChannel *ioc,
NBDExportInfo *info,
* Returns: negative errno: failure talking to server
* 0: server is connected
*/
-int nbd_receive_negotiate(QIOChannel *ioc, QCryptoTLSCreds *tlscreds,
+int nbd_receive_negotiate(AioContext *aio_context, QIOChannel *ioc,
+ QCryptoTLSCreds *tlscreds,
const char *hostname, QIOChannel **outioc,
NBDExportInfo *info, Error **errp)
{
@@ -1009,7 +1015,7 @@ int nbd_receive_negotiate(QIOChannel *ioc,
QCryptoTLSCreds
[Qemu-devel] [PATCH 2/3] pc: Improve error message when die-id is omitted
The error message when die-id is omitted doesn't make sense:
$ qemu-system-x86_64 -smp 1,sockets=6,maxcpus=6 \
-device qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0
qemu-system-x86_64: -device
qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0: \
Invalid CPU die-id: 4294967295 must be in range 0:0
Fix it, so it will now read:
qemu-system-x86_64: -device
qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0: \
CPU die-id is not set
Signed-off-by: Eduardo Habkost
---
hw/i386/pc.c | 4
1 file changed, 4 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 24b03bb49c..fb4ac5ca90 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2410,6 +2410,10 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
error_setg(errp, "Invalid CPU socket-id: %u must be in range 0:%u",
cpu->socket_id, max_socket);
return;
+}
+if (cpu->die_id < 0) {
+error_setg(errp, "CPU die-id is not set");
+return;
} else if (cpu->die_id > pcms->smp_dies - 1) {
error_setg(errp, "Invalid CPU die-id: %u must be in range 0:%u",
cpu->die_id, pcms->smp_dies - 1);
--
2.21.0
[Qemu-devel] [PULL 9/9] block/nbd: refactor nbd connection parameters
From: Vladimir Sementsov-Ogievskiy
We'll need some connection parameters to be available all the time to
implement nbd reconnect. So, let's refactor them: define additional
parameters in BDRVNBDState, drop them from function parameters, drop
nbd_client_init and separate options parsing instead from nbd_open.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Message-Id: <20190618114328.55249-6-vsement...@virtuozzo.com>
Reviewed-by: Eric Blake
[eblake: Drop useless 'if' before object_unref]
Signed-off-by: Eric Blake
---
block/nbd.c | 121 ++--
1 file changed, 60 insertions(+), 61 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index de2a26097bf9..00b8d86783d9 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -73,9 +73,13 @@ typedef struct BDRVNBDState {
NBDReply reply;
BlockDriverState *bs;
-/* For nbd_refresh_filename() */
+/* Connection parameters */
+uint32_t reconnect_delay;
SocketAddress *saddr;
char *export, *tlscredsid;
+QCryptoTLSCreds *tlscreds;
+const char *hostname;
+char *x_dirty_bitmap;
} BDRVNBDState;
/* @ret will be used for reconnect in future */
@@ -1182,13 +1186,7 @@ static QIOChannelSocket
*nbd_establish_connection(SocketAddress *saddr,
return sioc;
}
-static int nbd_client_connect(BlockDriverState *bs,
- SocketAddress *saddr,
- const char *export,
- QCryptoTLSCreds *tlscreds,
- const char *hostname,
- const char *x_dirty_bitmap,
- Error **errp)
+static int nbd_client_connect(BlockDriverState *bs, Error **errp)
{
BDRVNBDState *s = (BDRVNBDState *)bs->opaque;
AioContext *aio_context = bdrv_get_aio_context(bs);
@@ -1198,33 +1196,33 @@ static int nbd_client_connect(BlockDriverState *bs,
* establish TCP connection, return error if it fails
* TODO: Configurable retry-until-timeout behaviour.
*/
-QIOChannelSocket *sioc = nbd_establish_connection(saddr, errp);
+QIOChannelSocket *sioc = nbd_establish_connection(s->saddr, errp);
if (!sioc) {
return -ECONNREFUSED;
}
/* NBD handshake */
-trace_nbd_client_connect(export);
+trace_nbd_client_connect(s->export);
qio_channel_set_blocking(QIO_CHANNEL(sioc), false, NULL);
qio_channel_attach_aio_context(QIO_CHANNEL(sioc), aio_context);
s->info.request_sizes = true;
s->info.structured_reply = true;
s->info.base_allocation = true;
-s->info.x_dirty_bitmap = g_strdup(x_dirty_bitmap);
-s->info.name = g_strdup(export ?: "");
-ret = nbd_receive_negotiate(aio_context, QIO_CHANNEL(sioc), tlscreds,
-hostname, >ioc, >info, errp);
+s->info.x_dirty_bitmap = g_strdup(s->x_dirty_bitmap);
+s->info.name = g_strdup(s->export ?: "");
+ret = nbd_receive_negotiate(aio_context, QIO_CHANNEL(sioc), s->tlscreds,
+s->hostname, >ioc, >info, errp);
g_free(s->info.x_dirty_bitmap);
g_free(s->info.name);
if (ret < 0) {
object_unref(OBJECT(sioc));
return ret;
}
-if (x_dirty_bitmap && !s->info.base_allocation) {
+if (s->x_dirty_bitmap && !s->info.base_allocation) {
error_setg(errp, "requested x-dirty-bitmap %s not found",
- x_dirty_bitmap);
+ s->x_dirty_bitmap);
ret = -EINVAL;
goto fail;
}
@@ -1249,7 +1247,7 @@ static int nbd_client_connect(BlockDriverState *bs,
object_ref(OBJECT(s->ioc));
}
-trace_nbd_client_connect_success(export);
+trace_nbd_client_connect_success(s->export);
return 0;
@@ -1269,34 +1267,9 @@ static int nbd_client_connect(BlockDriverState *bs,
}
}
-static int nbd_client_init(BlockDriverState *bs,
- SocketAddress *saddr,
- const char *export,
- QCryptoTLSCreds *tlscreds,
- const char *hostname,
- const char *x_dirty_bitmap,
- uint32_t reconnect_delay,
- Error **errp)
-{
-int ret;
-BDRVNBDState *s = (BDRVNBDState *)bs->opaque;
-
-s->bs = bs;
-qemu_co_mutex_init(>send_mutex);
-qemu_co_queue_init(>free_sema);
-
-ret = nbd_client_connect(bs, saddr, export, tlscreds, hostname,
- x_dirty_bitmap, errp);
-if (ret < 0) {
-return ret;
-}
-
-s->connection_co = qemu_coroutine_create(nbd_connection_entry, s);
-bdrv_inc_in_flight(bs);
-aio_co_schedule(bdrv_get_aio_context(bs), s->connection_co);
-
-return 0;
-}
+/*
+ * Parse nbd_open options
+ */
static int nbd_parse_uri(const char *filename, QDict *options)
{
@@ -1616,14 +1589,12 @@ static QemuOptsList nbd_runtime_opts = {
},
};
-static int
[Qemu-devel] [PATCH 3/3] pc: Don't make CPU properties mandatory unless necessary
We have this issue reported when using libvirt to hotplug CPUs:
https://bugzilla.redhat.com/show_bug.cgi?id=1741451
Basically, libvirt is not copying die-id from
query-hotpluggable-cpus, but die-id is now mandatory.
We could blame libvirt and say it is not following the documented
interface, because we have this buried in the QAPI schema
documentation:
> Note: currently there are 5 properties that could be present
> but management should be prepared to pass through other
> properties with device_add command to allow for future
> interface extension. This also requires the filed names to be kept in
> sync with the properties passed to -device/device_add.
But I don't think this would be reasonable from us. We can just
make QEMU more flexible and let CPU properties to be omitted when
there's no ambiguity. This will allow us to keep compatibility
with existing libvirt versions.
Test case included to ensure we don't break this again.
Cc: Peter Krempa
Signed-off-by: Eduardo Habkost
---
hw/i386/pc.c | 17 +++
tests/acceptance/pc_cpu_hotplug_props.py | 59
2 files changed, 76 insertions(+)
create mode 100644 tests/acceptance/pc_cpu_hotplug_props.py
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index fb4ac5ca90..4d773c862d 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -2403,6 +2403,23 @@ static void pc_cpu_pre_plug(HotplugHandler *hotplug_dev,
int max_socket = (ms->smp.max_cpus - 1) /
smp_threads / smp_cores / pcms->smp_dies;
+/*
+ * If there's only one possible value for a topology property,
+ * allow it to be omitted.
+ */
+if (cpu->socket_id < 0 && max_socket == 0) {
+cpu->socket_id = 0;
+}
+if (cpu->die_id < 0 && pcms->smp_dies == 1) {
+cpu->die_id = 0;
+}
+if (cpu->core_id < 0 && smp_cores == 1) {
+cpu->core_id = 0;
+}
+if (cpu->thread_id < 0 && smp_threads == 1) {
+cpu->thread_id = 0;
+}
+
if (cpu->socket_id < 0) {
error_setg(errp, "CPU socket-id is not set");
return;
diff --git a/tests/acceptance/pc_cpu_hotplug_props.py
b/tests/acceptance/pc_cpu_hotplug_props.py
new file mode 100644
index 00..2c36926214
--- /dev/null
+++ b/tests/acceptance/pc_cpu_hotplug_props.py
@@ -0,0 +1,59 @@
+#
+# Ensure CPU topology parameters may be omitted on -device
+#
+# Copyright (c) 2019 Red Hat Inc
+#
+# Author:
+# Eduardo Habkost
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2 of the License, or (at your option) any later version.
+#
+# This library is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, see
Re: [Qemu-devel] [PULL 0/9] qtest patches
On 8/15/19 8:17 PM, no-re...@patchew.org wrote: > Patchew URL: https://patchew.org/QEMU/20190815175922.3475-1-th...@redhat.com/ > > Hi, > > This series failed build test on s390x host. Please find the details below. [...] > The full log is available at > http://patchew.org/logs/20190815175922.3475-1-th...@redhat.com/testing.s390x/?type=message. The error message is not really useful and seems unrelated: make: *** [/var/tmp/patchew-tester-tmp-krxfzhwl/src/rules.mak:69: qobject/block-qdict.o] Error 1 I did not touch anything in qobject/ at all in this series, so the problem is likely something completely different? Could it be that the machine simply ran out of disk space or something similar? Thomas
[Qemu-devel] [PULL 7/9] block/nbd: move from quit to state
From: Vladimir Sementsov-Ogievskiy
To implement reconnect we need several states for the client:
CONNECTED, QUIT and two different CONNECTING states. CONNECTING states
will be added in the following patches. This patch implements CONNECTED
and QUIT.
QUIT means, that we should close the connection and fail all current
and further requests (like old quit = true).
CONNECTED means that connection is ok, we can send requests (like old
quit = false).
For receiving loop we use a comparison of the current state with QUIT,
because reconnect will be in the same loop, so it should be looping
until the end.
Opposite, for requests we use a comparison of the current state with
CONNECTED, as we don't want to send requests in future CONNECTING
states.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Reviewed-by: Eric Blake
Message-Id: <20190618114328.55249-4-vsement...@virtuozzo.com>
Signed-off-by: Eric Blake
---
block/nbd.c | 58 ++---
1 file changed, 37 insertions(+), 21 deletions(-)
diff --git a/block/nbd.c b/block/nbd.c
index 3a243d9de96e..d03b00fc30b0 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -53,6 +53,11 @@ typedef struct {
bool receiving; /* waiting for connection_co? */
} NBDClientRequest;
+typedef enum NBDClientState {
+NBD_CLIENT_CONNECTED,
+NBD_CLIENT_QUIT
+} NBDClientState;
+
typedef struct BDRVNBDState {
QIOChannelSocket *sioc; /* The master data channel */
QIOChannel *ioc; /* The current I/O channel which may differ (eg TLS) */
@@ -62,17 +67,23 @@ typedef struct BDRVNBDState {
CoQueue free_sema;
Coroutine *connection_co;
int in_flight;
+NBDClientState state;
NBDClientRequest requests[MAX_NBD_REQUESTS];
NBDReply reply;
BlockDriverState *bs;
-bool quit;
/* For nbd_refresh_filename() */
SocketAddress *saddr;
char *export, *tlscredsid;
} BDRVNBDState;
+/* @ret will be used for reconnect in future */
+static void nbd_channel_error(BDRVNBDState *s, int ret)
+{
+s->state = NBD_CLIENT_QUIT;
+}
+
static void nbd_recv_coroutines_wake_all(BDRVNBDState *s)
{
int i;
@@ -151,7 +162,7 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
int ret = 0;
Error *local_err = NULL;
-while (!s->quit) {
+while (s->state != NBD_CLIENT_QUIT) {
/*
* The NBD client can only really be considered idle when it has
* yielded from qio_channel_readv_all_eof(), waiting for data. This is
@@ -169,6 +180,7 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
error_free(local_err);
}
if (ret <= 0) {
+nbd_channel_error(s, ret ? ret : -EIO);
break;
}
@@ -183,6 +195,7 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
!s->requests[i].receiving ||
(nbd_reply_is_structured(>reply) && !s->info.structured_reply))
{
+nbd_channel_error(s, -EINVAL);
break;
}
@@ -202,7 +215,6 @@ static coroutine_fn void nbd_connection_entry(void *opaque)
qemu_coroutine_yield();
}
-s->quit = true;
nbd_recv_coroutines_wake_all(s);
bdrv_dec_in_flight(s->bs);
@@ -215,12 +227,18 @@ static int nbd_co_send_request(BlockDriverState *bs,
QEMUIOVector *qiov)
{
BDRVNBDState *s = (BDRVNBDState *)bs->opaque;
-int rc, i;
+int rc, i = -1;
qemu_co_mutex_lock(>send_mutex);
while (s->in_flight == MAX_NBD_REQUESTS) {
qemu_co_queue_wait(>free_sema, >send_mutex);
}
+
+if (s->state != NBD_CLIENT_CONNECTED) {
+rc = -EIO;
+goto err;
+}
+
s->in_flight++;
for (i = 0; i < MAX_NBD_REQUESTS; i++) {
@@ -238,16 +256,12 @@ static int nbd_co_send_request(BlockDriverState *bs,
request->handle = INDEX_TO_HANDLE(s, i);
-if (s->quit) {
-rc = -EIO;
-goto err;
-}
assert(s->ioc);
if (qiov) {
qio_channel_set_cork(s->ioc, true);
rc = nbd_send_request(s->ioc, request);
-if (rc >= 0 && !s->quit) {
+if (rc >= 0 && s->state == NBD_CLIENT_CONNECTED) {
if (qio_channel_writev_all(s->ioc, qiov->iov, qiov->niov,
NULL) < 0) {
rc = -EIO;
@@ -262,9 +276,11 @@ static int nbd_co_send_request(BlockDriverState *bs,
err:
if (rc < 0) {
-s->quit = true;
-s->requests[i].coroutine = NULL;
-s->in_flight--;
+nbd_channel_error(s, rc);
+if (i != -1) {
+s->requests[i].coroutine = NULL;
+s->in_flight--;
+}
qemu_co_queue_next(>free_sema);
}
qemu_co_mutex_unlock(>send_mutex);
@@ -556,7 +572,7 @@ static coroutine_fn int nbd_co_do_receive_one_chunk(
s->requests[i].receiving = true;
qemu_coroutine_yield();
s->requests[i].receiving = false;
-if (s->quit) {
+if (s->state !=
[Qemu-devel] [PATCH 0/3] pc: Fix die-id validation and compatibility with libvirt
Currently, if die-id is omitted on -device for CPUs, we get a very confusing error message: $ qemu-system-x86_64 -smp 1,sockets=6,maxcpus=6 \ -device qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0 qemu-system-x86_64: -device qemu64-x86_64-cpu,socket-id=1,core-id=0,thread-id=0: \ Invalid CPU die-id: 4294967295 must be in range 0:5 This has 3 problems 1) The actual range for die-id is 0:0. This is fixed by patch 1/3. 2) The user didn't specify die-id=4294967295. This is fixed by patch 2/3. 3) It breaks compatibility with libvirt because die-id was not mandatory before. This is addressed by patch 3/3. Issues #1 and #2 were reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1741151 Issue #3 was reported at: https://bugzilla.redhat.com/show_bug.cgi?id=1741451 Cc: Like Xu Cc: Peter Krempa Cc: Igor Mammedov Eduardo Habkost (3): pc: Fix error message on die-id validation pc: Improve error message when die-id is omitted pc: Don't make CPU properties mandatory unless necessary hw/i386/pc.c | 23 - tests/acceptance/pc_cpu_hotplug_props.py | 59 2 files changed, 81 insertions(+), 1 deletion(-) create mode 100644 tests/acceptance/pc_cpu_hotplug_props.py -- 2.21.0
