Re: [Qemu-devel] [PULL v2 0/3] linux-user fixes for -rc3
Hi, This series seems to have some coding style problems. See output below for more information: Type: series Message-id: 20180410160142.21096-1-laur...@vivier.eu Subject: [Qemu-devel] [PULL v2 0/3] linux-user fixes for -rc3 === TEST SCRIPT BEGIN === #!/bin/bash BASE=base n=1 total=$(git log --oneline $BASE.. | wc -l) failed=0 git config --local diff.renamelimit 0 git config --local diff.renames True git config --local diff.algorithm histogram commits="$(git log --format=%H --reverse $BASE..)" for c in $commits; do echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..." if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then failed=1 echo fi n=$((n+1)) done exit $failed === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 From https://github.com/patchew-project/qemu * [new tag] patchew/20180410160142.21096-1-laur...@vivier.eu -> patchew/20180410160142.21096-1-laur...@vivier.eu Switched to a new branch 'test' 3d63c01ac9 linux-user: implement HWCAP bits on MIPS 53058bad56 linux-user: add microblaze/microblazeel magic numbers in qemu-binfmt-conf.sh 871304edc3 linux-user: fix microblaze get_sp_from_cpustate() === OUTPUT BEGIN === Checking PATCH 1/3: linux-user: fix microblaze get_sp_from_cpustate()... Checking PATCH 2/3: linux-user: add microblaze/microblazeel magic numbers in qemu-binfmt-conf.sh... ERROR: line over 90 characters #24: FILE: scripts/qemu-binfmt-conf.sh:7: +sh4 sh4eb s390x aarch64 aarch64_be hppa riscv32 riscv64 xtensa xtensaeb microblaze microblazeel" WARNING: line over 80 characters #32: FILE: scripts/qemu-binfmt-conf.sh:119: +microblaze_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xba\xab' ERROR: line over 90 characters #33: FILE: scripts/qemu-binfmt-conf.sh:120: +microblaze_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff' ERROR: line over 90 characters #36: FILE: scripts/qemu-binfmt-conf.sh:123: +microblazeel_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xab\xba' ERROR: line over 90 characters #37: FILE: scripts/qemu-binfmt-conf.sh:124: +microblazeel_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff' total: 4 errors, 1 warnings, 26 lines checked Your patch has style problems, please review. If any of these errors are false positives report them to the maintainer, see CHECKPATCH in MAINTAINERS. Checking PATCH 3/3: linux-user: implement HWCAP bits on MIPS... === OUTPUT END === Test command exited with code: 1 --- Email generated automatically by Patchew [http://patchew.org/]. Please send your feedback to patchew-de...@redhat.com
[Qemu-devel] [PATCH 2/2] specs/qcow2: Clarify that compressed clusters have the COPIED bit reset
Compressed clusters are not supposed to have the COPIED bit set, but this is not made explicit in the specs, so let's document it. Signed-off-by: Alberto Garcia --- docs/interop/qcow2.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt index feb711fb6a..8e1547ded2 100644 --- a/docs/interop/qcow2.txt +++ b/docs/interop/qcow2.txt @@ -400,10 +400,10 @@ L2 table entry: 62: 0 for standard clusters 1 for compressed clusters - 63: 0 for a cluster that is unused or requires COW, 1 if its -refcount is exactly one. This information is only accurate -in L2 tables that are reachable from the active L1 -table. + 63: 0 for clusters that are unused, compressed or require COW. +1 for standard clusters whose refcount is exactly one. +This information is only accurate in L2 tables +that are reachable from the active L1 table. Standard Cluster Descriptor: -- 2.11.0
[Qemu-devel] [PULL v2 0/3] linux-user fixes for -rc3
The following changes since commit df6378eb0e6cfd58a22a1c3ff8fa4a9039f1eaa8: Merge remote-tracking branch 'remotes/kraxel/tags/ui-20180410-pull-request' into staging (2018-04-10 14:04:27 +0100) are available in the Git repository at: git://github.com/vivier/qemu.git tags/linux-user-for-2.12-pull-request for you to fetch changes up to 46a1ee4f397ffd305da95fb65dc73be49667ff6d: linux-user: implement HWCAP bits on MIPS (2018-04-10 18:00:14 +0200) Trivial fixes for microblaze v2: add HWCAP bits on MIPS James Cowgill (1): linux-user: implement HWCAP bits on MIPS Laurent Vivier (2): linux-user: fix microblaze get_sp_from_cpustate() linux-user: add microblaze/microblazeel magic numbers in qemu-binfmt-conf.sh linux-user/elfload.c | 24 linux-user/microblaze/target_signal.h | 2 +- scripts/qemu-binfmt-conf.sh | 12 ++-- 3 files changed, 35 insertions(+), 3 deletions(-) -- 2.14.3
[Qemu-devel] [PATCH 1/2] Fix error message about compressed clusters with OFLAG_COPIED
Compressed clusters are not supposed to have the COPIED bit set.
"qemu-img check" detects that and prints an error message reporting
the number of the affected host cluster. This doesn't make much sense
because compressed clusters are not aligned to host clusters, so it
would be better to report the offset instead. Plus, the calculation is
wrong and it uses the raw L2 entry as if it was simply an offset.
This patch fixes the error message and reports the offset of the
compressed cluster.
Signed-off-by: Alberto Garcia
---
block/qcow2-refcount.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/block/qcow2-refcount.c b/block/qcow2-refcount.c
index 6b8b63514a..2dc23005b7 100644
--- a/block/qcow2-refcount.c
+++ b/block/qcow2-refcount.c
@@ -1577,9 +1577,9 @@ static int check_refcounts_l2(BlockDriverState *bs,
BdrvCheckResult *res,
case QCOW2_CLUSTER_COMPRESSED:
/* Compressed clusters don't have QCOW_OFLAG_COPIED */
if (l2_entry & QCOW_OFLAG_COPIED) {
-fprintf(stderr, "ERROR: cluster %" PRId64 ": "
+fprintf(stderr, "ERROR: coffset=0x%" PRIx64 ": "
"copied flag must never be set for compressed "
-"clusters\n", l2_entry >> s->cluster_bits);
+"clusters\n", l2_entry & s->cluster_offset_mask);
l2_entry &= ~QCOW_OFLAG_COPIED;
res->corruptions++;
}
--
2.11.0
[Qemu-devel] [Bug 1754038] Re: ARM M: Systick first wrap delayed (qemu-timers/icount prb?)
Now fixed in master, commit c52e7132d7c885, and will be in 2.12.0.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1754038
Title:
ARM M: Systick first wrap delayed (qemu-timers/icount prb?)
Status in QEMU:
Fix Committed
Bug description:
When running this kind of code with qemu:
static void SysTickISR(void)
{
printf("SysTick\n");
}
void main()
{
volatile int i, j;
printf("setup timer\n");
*(uint32_t*) 0xE000E014 = 0x8F; //reload value
*(uint32_t*) 0xE000E018 = 0;//force reload
*(uint32_t*) 0xE000E010 = 7;//cpu clk + ISR + enable
for (j = 0; j < 0x100; j++) {
for (i = 0; i < 0x10; i++)
;
printf("cnt %08x -- %8x\n", *(uint32_t*) 0xE000E018,
*(uint32_t*)0xE000E010);
}
}
I get the following output (comments added after '#'):
setup timer
cnt 007a --7
cnt 006998a2 --7
cnt 00566479 --7
cnt 0043304f --7
cnt 002ffc26 --7
cnt 001cc7fd --7
cnt 000993d5 --7
cnt --7 <--- problem here, systick should wrap and raise
isr
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
cnt --7
SysTick <--- delayed isr occuring here
cnt 000986e0 --10007
SysTick
cnt 00865290 --10007 < then running fine as long as regs not
modified
cnt 00731e51 --7
cnt 005fea27 --7
cnt 004cb5ff --7
cnt 003981d6 --7
cnt 00264dad --7
cnt 00131984 --7
SysTick
cnt 008fe545 --10007
cnt 007cb106 --7
cnt 00697cdd --7
cnt 005648b4 --7
cnt 0043148b --7
cnt 002fe061 --7
cnt 001cac38 --7
cnt 00097810 --7
SysTick
cnt 008643d6 --10007
cnt 00730f97 --7
cnt 005fdb6d --7
cnt 004ca745 --7
cnt 0039731c --7
cnt 00263ef3 --7
cnt 00130aca --7
SysTick
cnt 008fd68b --10007
cnt 007ca24c --7
cnt 00696e23 --7
cnt 005639fa --7
cnt 004305d1 --7
cnt 002fd1a8 --7
cnt 001c9d7f --7
cnt 00096956 --7
SysTick
cnt 0086351d --10007
cnt 007300dd --7
cnt 005fccb4 --7
cnt 004c988c --7
cnt 00396463 --7
cnt 00263039 --7
cnt 0012fc10 --7
[...]
Command line and version:
qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -monitor stdio
-serial file:/dev/pts/6 -icount 4 -cpu cortex-m4
QEMU 2.11.50
I am compiling from git repo, head is:
commit f32408f3b472a088467474ab152be3b6285b2d7b
Author: Daniel P. Berrangé
Date: Tue Mar 6 13:43:17 2018 +
Config options:
./configure --target-list=arm-softmmu --enable-debug --disable-slirp
--enable-tcg-interpreter --disable-blobs --disable-docs --disable-guest-agent
--disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk
--disable-vnc --disable-virtfs --disable-mpath --disable-xen --disable-brlapi
--disable-curl --disable-bluez --disable-kvm --disable-hax --disable-hvf
--disable-whpx --disable-rdma --disable-vde --disable-netmap
--disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net
--disable-spice --disable-rbd --disable-libiscsi --disable-libnfs
--disable-smartcard --disable-libusb --disable-live-block-migration
--disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2
--disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2
--disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc
--disable-replication --disable-vhost-vsock --disable-opengl
--disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug
--disable-vxhs --disable-crypto-afalg --disable-vhost-user --disable-capstone
--disable-pie --extra-cflags=-mtune=native
Not working with git tag 2.10.0 (almost same config)
Working with stock qemu-arm 2.5.0 from Ubuntu 16.04.
I started investigating, though I am not familiar with qemu code and I
could see that the execution is not geting out of
qemu_tcg_rr_cpu_thread_fn() 'while' loop and timers are not triggered
because the values in cpu->icount_extra or cpu->icount_budget are not
to modified accordingly after the timer is set (host side) when the
systick register is written (target side).
To manage notifications about this bug go to:
https://bugs.launchpad.net/q
[Qemu-devel] [PULL v2 1/3] linux-user: fix microblaze get_sp_from_cpustate()
get_sigframe() uses regs[1] and this is actual SP.
Signed-off-by: Laurent Vivier
Message-Id: <20180409115212.875-1-laur...@vivier.eu>
---
linux-user/microblaze/target_signal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/microblaze/target_signal.h
b/linux-user/microblaze/target_signal.h
index de2b0f49d5..642865f12e 100644
--- a/linux-user/microblaze/target_signal.h
+++ b/linux-user/microblaze/target_signal.h
@@ -23,7 +23,7 @@ typedef struct target_sigaltstack {
static inline abi_ulong get_sp_from_cpustate(CPUMBState *state)
{
-return state->regs[14];
+return state->regs[1];
}
--
2.14.3
[Qemu-devel] [Bug 1761401] Re: ARM/Neon: vcvt rounding error
Hi Christophe -- we think that commit bd49e6027cbc207c, now in master, should have fixed this bug. Could you retry your testcase with a QEMU build including that fix? -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1761401 Title: ARM/Neon: vcvt rounding error Status in QEMU: New Bug description: Hello, While using QEMU commit 47d3b60858d90ac8a0cc3a72af7f95c96781125a (March 28, 2018), I've noticed failures in one of the GCC ARM/Neon tests. The test passes on hardware, and with QEMU-2.11.0, so it looks like a recent regression. The test builds a vector of 4 float32 with "125.9" as value, then converts them to 4 uint32_t. The expected result is 125, but we get 126 instead. Maybe it's just a matter of default rounding mode? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1761401/+subscriptions
[Qemu-devel] [Bug 1761535] Re: qemu-aarch64-static docker arm64v8/openjdk coredump
Now fixed in master, commit 7f0f4208b3a96, and will be in 2.12.0. ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1761535 Title: qemu-aarch64-static docker arm64v8/openjdk coredump Status in QEMU: Fix Committed Bug description: I am using qemu-aarch64-static to run the arm64v8/openjdk official image on my x86 machine. Using QEMU master, I immediately hit a bug which hangs the container. With Ubuntu default version qemu-aarch64 version 2.5.0 (Debian 1:2.5+dfsg-5ubuntu10.24) and qemu-aarch64 version 2.11.1 (v2.11.1-dirty) the hang does not take place. To reproduce (and get to the core dump): $ /tmp/tmptgyg3nvh/qemu-aarch64-static/qemu-aarch64-static -version qemu-aarch64 version 2.11.91 (v2.12.0-rc1-5-g47d3b60-dirty) Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers $ docker run -it -v /tmp/tmptgyg3nvh/qemu-aarch64-static:/usr/bin/qemu-aarch64-static arm64v8/openjdk /bin/bash root@bf75cf45d311:/# javac Usage: javac where possible options include: -g Generate all debugging info <...snip...> @Read options and filenames from file qemu: uncaught target signal 11 (Segmentation fault) - core dumped ...TERMINAL HANGS... To get the core dump, In a separate terminal: # snapshot the file system of the hung image $ docker commit $(docker ps -aqf "name=latest_qemu") qemu_coredump # connect with known working qemu $ docker run -t -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -i qemu_coredump /bin/bash $$ ls -lat total 10608 -rw-r--r-- 1 root root 10792960 Mar 29 18:02 qemu_bash_20180329-180251_1.core drwxrwxrwt 5 root root 4096 Mar 29 18:02 tmp To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1761535/+subscriptions
[Qemu-devel] [PATCH 0/2] Minor fixes about compressed clusters with OFLAG_COPIED
Hi, while reviewing one previous patch about data corruption and compressed clusters we discussed that the documentation doesn't clarify that L2 entries for compressed clusters are not supposed to have the OFLAG_COPIED bit set. Here's a patch to update the documentation and another one to fix the error message that "qemu-img check" produces. Regards, Berto Alberto Garcia (2): Fix error message about compressed clusters with OFLAG_COPIED specs/qcow2: Clarify that compressed clusters have the COPIED bit reset block/qcow2-refcount.c | 4 ++-- docs/interop/qcow2.txt | 8 2 files changed, 6 insertions(+), 6 deletions(-) -- 2.11.0
[Qemu-devel] [PULL v2 2/3] linux-user: add microblaze/microblazeel magic numbers in qemu-binfmt-conf.sh
Signed-off-by: Laurent Vivier
Message-Id: <20180409115212.875-2-laur...@vivier.eu>
---
scripts/qemu-binfmt-conf.sh | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
index f39ad344fc..7ab7435fbd 100755
--- a/scripts/qemu-binfmt-conf.sh
+++ b/scripts/qemu-binfmt-conf.sh
@@ -1,10 +1,10 @@
#!/bin/sh
-# enable automatic i386/ARM/M68K/MIPS/SPARC/PPC/s390/HPPA/Xtensa
+# enable automatic i386/ARM/M68K/MIPS/SPARC/PPC/s390/HPPA/Xtensa/microblaze
# program execution by the kernel
qemu_target_list="i386 i486 alpha arm armeb sparc32plus ppc ppc64 ppc64le m68k
\
mips mipsel mipsn32 mipsn32el mips64 mips64el \
-sh4 sh4eb s390x aarch64 aarch64_be hppa riscv32 riscv64 xtensa xtensaeb"
+sh4 sh4eb s390x aarch64 aarch64_be hppa riscv32 riscv64 xtensa xtensaeb
microblaze microblazeel"
i386_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00'
i386_mask='\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
@@ -116,6 +116,14 @@
xtensaeb_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\
xtensaeb_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
xtensaeb_family=xtensaeb
+microblaze_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xba\xab'
+microblaze_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
+microblaze_family=microblaze
+
+microblazeel_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xab\xba'
+microblazeel_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
+microblazeel_family=microblazeel
+
qemu_get_family() {
cpu=${HOST_ARCH:-$(uname -m)}
case "$cpu" in
--
2.14.3
[Qemu-devel] [PULL v2 3/3] linux-user: implement HWCAP bits on MIPS
From: James Cowgill
Add support for the two currently defined HWCAP bits on MIPS - R6 and
MSA.
Buglink: https://bugs.launchpad.net/qemu/+bug/1754372
Signed-off-by: James Cowgill
Reviewed-by: Laurent Vivier
Message-Id: <20180315151348.6451-1-james.cowg...@mips.com>
Signed-off-by: Laurent Vivier
---
linux-user/elfload.c | 24
1 file changed, 24 insertions(+)
diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 23e34957f9..c77ed1bb01 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -882,6 +882,30 @@ static void elf_core_copy_regs(target_elf_gregset_t *regs,
const CPUMIPSState *e
#define USE_ELF_CORE_DUMP
#define ELF_EXEC_PAGESIZE4096
+/* See arch/mips/include/uapi/asm/hwcap.h. */
+enum {
+HWCAP_MIPS_R6 = (1 << 0),
+HWCAP_MIPS_MSA = (1 << 1),
+};
+
+#define ELF_HWCAP get_elf_hwcap()
+
+static uint32_t get_elf_hwcap(void)
+{
+MIPSCPU *cpu = MIPS_CPU(thread_cpu);
+uint32_t hwcaps = 0;
+
+#define GET_FEATURE(flag, hwcap) \
+do { if (cpu->env.insn_flags & (flag)) { hwcaps |= hwcap; } } while (0)
+
+GET_FEATURE(ISA_MIPS32R6 | ISA_MIPS64R6, HWCAP_MIPS_R6);
+GET_FEATURE(ASE_MSA, HWCAP_MIPS_MSA);
+
+#undef GET_FEATURE
+
+return hwcaps;
+}
+
#endif /* TARGET_MIPS */
#ifdef TARGET_MICROBLAZE
--
2.14.3
Re: [Qemu-devel] [PULL 00/12] target-arm queue
On 10 April 2018 at 13:17, Peter Maydell wrote: > Arm patch queue for 2.12 -- a miscellaneous collection > of bug fixes. > > thanks > -- PMM > > > The following changes since commit fb4fe32d5b6290deabe752b51cc1cc2a9e8573db: > > Merge remote-tracking branch 'remotes/xtensa/tags/20180409-xtensa' into > staging (2018-04-10 10:22:45 +0100) > > are available in the Git repository at: > > git://git.linaro.org/people/pmaydell/qemu-arm.git > tags/pull-target-arm-20180410 > > for you to fetch changes up to bd49e6027cbc207c87633c7add3ebd7d3474cd35: > > fpu: Fix rounding mode for floatN_to_uintM_round_to_zero (2018-04-10 > 13:02:26 +0100) > > > target-arm queue: > * fpu: Fix rounding mode for floatN_to_uintM_round_to_zero > * tcg: Fix guest state corruption when running 64-bit Arm >guests on a 32-bit host (especially when using icount) > * linux-user/signal.c: Ensure AArch64 signal frame isn't too small > * cpus.c: ensure running CPU recalculates icount deadlines on timer expiry > * target/arm: Report unsupported MPU region sizes more clearly > * hw/arm/fsl-imx: Fix introspection problem with fsl-imx6 and fsl-imx7 > * hw/arm/allwinner-a10: Do not use nd_table in instance_init function > * hw/sd/bcm2835_sdhost: Don't raise spurious interrupts > * hw/sd/bcm2835_sdhost: Add tracepoints > * target-arm: Check undefined opcodes for SWP in A32 decoder > * hw/arm/integratorcp: Don't do things that could be fatal in the > instance_init > * hw/arm: Allow manually specified /psci node > > Applied, thanks. -- PMM
[Qemu-devel] [PULL 5/7] qemu-iotests: Remove _supported_fmt dmg
qemu-iotests doesn't support dmg, and the dmg block driver doesn't
support image creation. Two test cases declare dmg as supported, but
that's obviously wrong for both reasons. Remove the declaration.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
---
tests/qemu-iotests/183 | 2 +-
tests/qemu-iotests/194 | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/183 b/tests/qemu-iotests/183
index 20268ff7a1..c49e1ad6ef 100755
--- a/tests/qemu-iotests/183
+++ b/tests/qemu-iotests/183
@@ -43,7 +43,7 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
. ./common.filter
. ./common.qemu
-_supported_fmt qcow2 raw qed dmg quorum
+_supported_fmt qcow2 raw qed quorum
_supported_proto file
_supported_os Linux
diff --git a/tests/qemu-iotests/194 b/tests/qemu-iotests/194
index 1d4214aca3..d746ab1e21 100755
--- a/tests/qemu-iotests/194
+++ b/tests/qemu-iotests/194
@@ -21,7 +21,7 @@
import iotests
-iotests.verify_image_format(supported_fmts=['qcow2', 'qed', 'raw', 'dmg'])
+iotests.verify_image_format(supported_fmts=['qcow2', 'qed', 'raw'])
iotests.verify_platform(['linux'])
with iotests.FilePath('source.img') as source_img_path, \
--
2.13.6
[Qemu-devel] [PULL 0/7] Block layer patches for 2.12.0-rc3
The following changes since commit df6378eb0e6cfd58a22a1c3ff8fa4a9039f1eaa8: Merge remote-tracking branch 'remotes/kraxel/tags/ui-20180410-pull-request' into staging (2018-04-10 14:04:27 +0100) are available in the git repository at: git://repo.or.cz/qemu/kevin.git tags/for-upstream for you to fetch changes up to c1de5696d6a25b426432c147dfd7fb8a9eb86b89: qemu-iotests: update 185 output (2018-04-10 16:34:38 +0200) Block layer patches Kevin Wolf (2): qemu-iotests: Remove _supported_fmt dmg commit/stream: Reset delay_ns Philippe Mathieu-Daudé (1): hw/block/pflash_cfi: fix off-by-one error Stefan Hajnoczi (1): qemu-iotests: update 185 output Vladimir Sementsov-Ogievskiy (3): iotests.py: support unsupported_fmts in main() iotests.py: improve verify_image_format helper iotests: blacklist bochs and cloop for 205 and 208 block/commit.c| 2 ++ block/stream.c| 2 ++ hw/block/pflash_cfi01.c | 10 -- hw/block/pflash_cfi02.c | 9 - tests/qemu-iotests/183| 2 +- tests/qemu-iotests/185| 10 ++ tests/qemu-iotests/185.out| 12 +++- tests/qemu-iotests/194| 2 +- tests/qemu-iotests/205| 2 +- tests/qemu-iotests/208| 2 ++ tests/qemu-iotests/iotests.py | 19 ++- 11 files changed, 44 insertions(+), 28 deletions(-)
[Qemu-devel] [PULL 7/7] qemu-iotests: update 185 output
From: Stefan Hajnoczi
Commit 4486e89c219c0d1b9bd8dfa0b1dd5b0d51ff2268 ("vl: introduce
vm_shutdown()") added a bdrv_drain_all() call. As a side-effect of the
drain operation the block job iterates one more time than before. The
185 output no longer matches and the test is failing now.
It may be possible to avoid the superfluous block job iteration, but
that type of patch is not suitable late in the QEMU 2.12 release cycle.
This patch simply updates the 185 output file. The new behavior is
correct, just not optimal, so make the test pass again.
Fixes: 4486e89c219c0d1b9bd8dfa0b1dd5b0d51ff2268 ("vl: introduce vm_shutdown()")
Cc: Kevin Wolf
Cc: QingFeng Hao
Signed-off-by: Stefan Hajnoczi
Reviewed-by: QingFeng Hao
Reviewed-by: Eric Blake
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/185 | 10 ++
tests/qemu-iotests/185.out | 12 +++-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/tests/qemu-iotests/185 b/tests/qemu-iotests/185
index f5b47e4c1a..298d88d04e 100755
--- a/tests/qemu-iotests/185
+++ b/tests/qemu-iotests/185
@@ -92,9 +92,8 @@ echo === Start commit job and exit qemu ===
echo
# Note that the reference output intentionally includes the 'offset' field in
-# BLOCK_JOB_CANCELLED events for all of the following block jobs. They are
-# predictable and any change in the offsets would hint at a bug in the job
-# throttling code.
+# BLOCK_JOB_* events for all of the following block jobs. They are predictable
+# and any change in the offsets would hint at a bug in the job throttling code.
#
# In order to achieve these predictable offsets, all of the following tests
# use speed=65536. Each job will perform exactly one iteration before it has
@@ -102,11 +101,14 @@ echo
# command to be received (after receiving the command, the rest runs
# synchronously, so jobs can arbitrarily continue or complete).
#
+# Jobs present while QEMU is terminating iterate once more due to
+# bdrv_drain_all().
+#
# The buffer size for commit and streaming is 512k (waiting for 8 seconds after
# the first request), for active commit and mirror it's large enough to cover
# the full 4M, and for backup it's the qcow2 cluster size, which we know is
# 64k. As all of these are at least as large as the speed, we are sure that the
-# offset doesn't advance after the first iteration before qemu exits.
+# offset advances exactly twice before qemu exits.
_send_qemu_cmd $h \
"{ 'execute': 'block-commit',
diff --git a/tests/qemu-iotests/185.out b/tests/qemu-iotests/185.out
index 57eaf8d699..2c4b04de73 100644
--- a/tests/qemu-iotests/185.out
+++ b/tests/qemu-iotests/185.out
@@ -20,7 +20,7 @@ Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=67108864
backing_file=TEST_DIR/t.q
{"return": {}}
{"return": {}}
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"SHUTDOWN", "data": {"guest": false}}
-{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"BLOCK_JOB_CANCELLED", "data": {"device": "disk", "len": 67108864, "offset":
524288, "speed": 65536, "type": "commit"}}
+{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"BLOCK_JOB_CANCELLED", "data": {"device": "disk", "len": 67108864, "offset":
1048576, "speed": 65536, "type": "commit"}}
=== Start active commit job and exit qemu ===
@@ -28,16 +28,18 @@ Formatting 'TEST_DIR/t.qcow2', fmt=qcow2 size=67108864
backing_file=TEST_DIR/t.q
{"return": {}}
{"return": {}}
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"SHUTDOWN", "data": {"guest": false}}
-{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"BLOCK_JOB_CANCELLED", "data": {"device": "disk", "len": 4194304, "offset":
4194304, "speed": 65536, "type": "commit"}}
+{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"BLOCK_JOB_READY", "data": {"device": "disk", "len": 4194304, "offset":
4194304, "speed": 65536, "type": "commit"}}
+{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"BLOCK_JOB_COMPLETED", "data": {"device": "disk", "len": 4194304, "offset":
4194304, "speed": 65536, "type": "commit"}}
=== Start mirror job and exit qemu ===
{"return": {}}
Formatting 'TEST_DIR/t.qcow2.copy', fmt=qcow2 size=67108864 cluster_size=65536
lazy_refcounts=off refcount_bits=16
{"return": {}}
+{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"BLOCK_JOB_READY", "data": {"device": "disk", "len": 4194304, "offset":
4194304, "speed": 65536, "type": "mirror"}}
{"return": {}}
{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"SHUTDOWN", "data": {"guest": false}}
-{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"BLOCK_JOB_CANCELLED", "data": {"device": "disk", "len": 4194304, "offset":
4194304, "speed": 65536, "type": "mirror"}}
+{"timestamp": {"seconds": TIMESTAMP, "microseconds": TIMESTAMP}, "event":
"BLOCK_JOB_C
[Qemu-devel] [PULL 6/7] commit/stream: Reset delay_ns
Streaming and the commit block job only want to apply throttling when
they actually copied data instead of skipping it, so they made the
calculation of delay_ns conditional. However, delay_ns isn't reset when
skipping some sectors, so instead of not waiting, the old delay is
applied again.
Properly reset delay_ns where needed.
Signed-off-by: Kevin Wolf
Reviewed-by: Eric Blake
---
block/commit.c | 2 ++
block/stream.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/block/commit.c b/block/commit.c
index ab4fa3c3cf..1432baeef4 100644
--- a/block/commit.c
+++ b/block/commit.c
@@ -202,6 +202,8 @@ static void coroutine_fn commit_run(void *opaque)
if (copy && s->common.speed) {
delay_ns = ratelimit_calculate_delay(&s->limit, n);
+} else {
+delay_ns = 0;
}
}
diff --git a/block/stream.c b/block/stream.c
index f3b53f49e2..1a85708fcf 100644
--- a/block/stream.c
+++ b/block/stream.c
@@ -188,6 +188,8 @@ static void coroutine_fn stream_run(void *opaque)
s->common.offset += n;
if (copy && s->common.speed) {
delay_ns = ratelimit_calculate_delay(&s->limit, n);
+} else {
+delay_ns = 0;
}
}
--
2.13.6
[Qemu-devel] [PULL 2/7] hw/block/pflash_cfi: fix off-by-one error
From: Philippe Mathieu-Daudé
ASAN reported:
hw/block/pflash_cfi02.c:245:33: runtime error: index 82 out of bounds for
type 'uint8_t [82]'
Since the 'cfi_len' member is not used, remove it to keep the code safer.
Cc: qemu-sta...@nongnu.org
Reported-by: AddressSanitizer
Signed-off-by: Philippe Mathieu-Daudé
Signed-off-by: Kevin Wolf
---
hw/block/pflash_cfi01.c | 10 --
hw/block/pflash_cfi02.c | 9 -
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 1113ab1ccf..2e8284001d 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -90,7 +90,6 @@ struct pflash_t {
uint16_t ident1;
uint16_t ident2;
uint16_t ident3;
-uint8_t cfi_len;
uint8_t cfi_table[0x52];
uint64_t counter;
unsigned int writeblock_size;
@@ -153,7 +152,7 @@ static uint32_t pflash_cfi_query(pflash_t *pfl, hwaddr
offset)
boff = offset >> (ctz32(pfl->bank_width) +
ctz32(pfl->max_device_width) - ctz32(pfl->device_width));
-if (boff > pfl->cfi_len) {
+if (boff >= sizeof(pfl->cfi_table)) {
return 0;
}
/* Now we will construct the CFI response generated by a single
@@ -385,10 +384,10 @@ static uint32_t pflash_read (pflash_t *pfl, hwaddr offset,
boff = boff >> 2;
}
-if (boff > pfl->cfi_len) {
-ret = 0;
-} else {
+if (boff < sizeof(pfl->cfi_table)) {
ret = pfl->cfi_table[boff];
+} else {
+ret = 0;
}
} else {
/* If we have a read larger than the bank_width, combine multiple
@@ -791,7 +790,6 @@ static void pflash_cfi01_realize(DeviceState *dev, Error
**errp)
pfl->cmd = 0;
pfl->status = 0;
/* Hardcoded CFI table */
-pfl->cfi_len = 0x52;
/* Standard "QRY" string */
pfl->cfi_table[0x10] = 'Q';
pfl->cfi_table[0x11] = 'R';
diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
index c81ddd3a99..75d1ae1026 100644
--- a/hw/block/pflash_cfi02.c
+++ b/hw/block/pflash_cfi02.c
@@ -83,7 +83,6 @@ struct pflash_t {
uint16_t ident3;
uint16_t unlock_addr0;
uint16_t unlock_addr1;
-uint8_t cfi_len;
uint8_t cfi_table[0x52];
QEMUTimer *timer;
/* The device replicates the flash memory across its memory space. Emulate
@@ -235,10 +234,11 @@ static uint32_t pflash_read (pflash_t *pfl, hwaddr offset,
break;
case 0x98:
/* CFI query mode */
-if (boff > pfl->cfi_len)
-ret = 0;
-else
+if (boff < sizeof(pfl->cfi_table)) {
ret = pfl->cfi_table[boff];
+} else {
+ret = 0;
+}
break;
}
@@ -663,7 +663,6 @@ static void pflash_cfi02_realize(DeviceState *dev, Error
**errp)
pfl->cmd = 0;
pfl->status = 0;
/* Hardcoded CFI table (mostly from SG29 Spansion flash) */
-pfl->cfi_len = 0x52;
/* Standard "QRY" string */
pfl->cfi_table[0x10] = 'Q';
pfl->cfi_table[0x11] = 'R';
--
2.13.6
[Qemu-devel] [PULL 4/7] iotests: blacklist bochs and cloop for 205 and 208
From: Vladimir Sementsov-Ogievskiy
Blacklist these formats, as they don't support image creation, as they
say:
> ./qemu-img create -f bochs x 1m
qemu-img: x: Format driver 'bochs' does not support image creation
> ./qemu-img create -f cloop x 1m
qemu-img: x: Format driver 'cloop' does not support image creation
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/205 | 2 +-
tests/qemu-iotests/208 | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/qemu-iotests/205 b/tests/qemu-iotests/205
index e7b2eae51d..31b2f5707a 100755
--- a/tests/qemu-iotests/205
+++ b/tests/qemu-iotests/205
@@ -153,4 +153,4 @@ class TestNbdServerRemove(iotests.QMPTestCase):
if __name__ == '__main__':
-iotests.main()
+iotests.main(supported_fmts=['generic'])
diff --git a/tests/qemu-iotests/208 b/tests/qemu-iotests/208
index 18f59ada94..1e202388dc 100755
--- a/tests/qemu-iotests/208
+++ b/tests/qemu-iotests/208
@@ -22,6 +22,8 @@
import iotests
+iotests.verify_image_format(supported_fmts=['generic'])
+
with iotests.FilePath('disk.img') as disk_img_path, \
iotests.FilePath('disk-snapshot.img') as disk_snapshot_img_path, \
iotests.FilePath('nbd.sock') as nbd_sock_path, \
--
2.13.6
[Qemu-devel] [PULL 3/7] iotests.py: improve verify_image_format helper
From: Vladimir Sementsov-Ogievskiy
Support "generic" formats like in bash tests with their
_supported_fmt generic
The test, supporting "generic" formats will run if IMGFMT_GENERIC =
true, which is default, except for bochs and cloop. However, you can
use verify_image_format(['generic', 'bochs']), which will run for all
except cloop (for this moment).
Also, add an assert (we don't want set both arguments) and remove
duplication.
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/iotests.py | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index 1623257e32..97131b1f86 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -532,9 +532,17 @@ def notrun(reason):
sys.exit(0)
def verify_image_format(supported_fmts=[], unsupported_fmts=[]):
-if supported_fmts and (imgfmt not in supported_fmts):
-notrun('not suitable for this image format: %s' % imgfmt)
-if unsupported_fmts and (imgfmt in unsupported_fmts):
+assert not (supported_fmts and unsupported_fmts)
+
+if 'generic' in supported_fmts and \
+os.environ.get('IMGFMT_GENERIC', 'true') == 'true':
+# similar to
+# _supported_fmt generic
+# for bash tests
+return
+
+not_sup = supported_fmts and (imgfmt not in supported_fmts)
+if not_sup or (imgfmt in unsupported_fmts):
notrun('not suitable for this image format: %s' % imgfmt)
def verify_platform(supported_oses=['linux']):
--
2.13.6
[Qemu-devel] [PULL 1/7] iotests.py: support unsupported_fmts in main()
From: Vladimir Sementsov-Ogievskiy
Signed-off-by: Vladimir Sementsov-Ogievskiy
Signed-off-by: Kevin Wolf
---
tests/qemu-iotests/iotests.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
index b5d7945af8..1623257e32 100644
--- a/tests/qemu-iotests/iotests.py
+++ b/tests/qemu-iotests/iotests.py
@@ -553,7 +553,8 @@ def verify_quorum():
if not supports_quorum():
notrun('quorum support missing')
-def main(supported_fmts=[], supported_oses=['linux'],
supported_cache_modes=[]):
+def main(supported_fmts=[], supported_oses=['linux'], supported_cache_modes=[],
+ unsupported_fmts=[]):
'''Run tests'''
global debug
@@ -568,7 +569,7 @@ def main(supported_fmts=[], supported_oses=['linux'],
supported_cache_modes=[]):
debug = '-d' in sys.argv
verbosity = 1
-verify_image_format(supported_fmts)
+verify_image_format(supported_fmts, unsupported_fmts)
verify_platform(supported_oses)
verify_cache_mode(supported_cache_modes)
--
2.13.6
Re: [Qemu-devel] [PATCH v2] linux-user: implement HWCAP bits on MIPS
Le 10/04/2018 à 15:53, Peter Maydell a écrit : > On 15 March 2018 at 15:25, Laurent Vivier wrote: >> Le 15/03/2018 à 16:13, James Cowgill a écrit : >>> Add support for the two currently defined HWCAP bits on MIPS - R6 and >>> MSA. >>> >>> Buglink: https://bugs.launchpad.net/qemu/+bug/1754372 >>> Signed-off-by: James Cowgill >>> --- >>> v2 changes: >>> - Fix kernel hwcap.h path. >>> >>> linux-user/elfload.c | 24 >>> 1 file changed, 24 insertions(+) >>> >> >> Reviewed-by: Laurent Vivier Hi Peter, > Hi Laurent -- did this MIPS HWCAP fix get lost somewhere? I can't > see it in master or your latest pullreq. yes, I've missed it. I add it to my pull request. Thank you, Laurent
[Qemu-devel] [PULL 0/1] migration queue
From: "Dr. David Alan Gilbert" The following changes since commit df6378eb0e6cfd58a22a1c3ff8fa4a9039f1eaa8: Merge remote-tracking branch 'remotes/kraxel/tags/ui-20180410-pull-request' into staging (2018-04-10 14:04:27 +0100) are available in the Git repository at: git://github.com/dagrh/qemu.git tags/pull-migration-20180410a for you to fetch changes up to a18a73d7472e6ff5bc1e5f7fb9f7a42464295d03: Revert "migration: Don't activate block devices if using -S" (2018-04-10 15:28:42 +0100) Migration reversion pull for 2.12 One to revert after we decided it needs some more thinking. Dr. David Alan Gilbert (1): Revert "migration: Don't activate block devices if using -S" migration/migration.c | 22 +++--- 1 file changed, 7 insertions(+), 15 deletions(-)
[Qemu-devel] [PATCH 4/4] pc-bios/s390-ccw: fix non-sequential boot entries (enum)
zIPL boot menu entries can be non-sequential. Let's account
for this issue for the s390 enumerated boot menu. Since we
can no longer print a range of available entries to the
user, we have to present a list of each available entry.
An example of this menu:
s390-ccw Enumerated Boot Menu.
[0] default
[1]
[2]
[7]
[8]
[9]
[11]
[12]
Please choose:
Signed-off-by: Collin Walling
Reported-by: Vasily Gorbik
---
pc-bios/s390-ccw/bootmap.c | 12 +++-
pc-bios/s390-ccw/menu.c | 29 -
pc-bios/s390-ccw/s390-ccw.h | 2 +-
3 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index 2f79346..f9a2fb3 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -558,6 +558,8 @@ static void ipl_scsi(void)
int program_table_entries = 0;
BootMapTable *prog_table = (void *)sec;
unsigned int loadparm = get_loadparm_index();
+bool valid_entries[MAX_BOOT_ENTRIES] = {false};
+size_t i;
/* Grab the MBR */
memset(sec, FREE_SPACE_FILLER, sizeof(sec));
@@ -578,18 +580,18 @@ static void ipl_scsi(void)
read_block(mbr->pt.blockno, sec, "Error reading Program Table");
IPL_assert(magic_match(sec, ZIPL_MAGIC), "No zIPL magic in PT");
-while (program_table_entries < MAX_BOOT_ENTRIES) {
-if (!prog_table->entry[program_table_entries].scsi.blockno) {
-break;
+for (i = 0; i < MAX_BOOT_ENTRIES; i++) {
+if (prog_table->entry[i].scsi.blockno) {
+valid_entries[i] = true;
+program_table_entries++;
}
-program_table_entries++;
}
debug_print_int("program table entries", program_table_entries);
IPL_assert(program_table_entries != 0, "Empty Program Table");
if (menu_is_enabled_enum()) {
-loadparm = menu_get_enum_boot_index(program_table_entries);
+loadparm = menu_get_enum_boot_index(valid_entries);
}
debug_print_int("loadparm", loadparm);
diff --git a/pc-bios/s390-ccw/menu.c b/pc-bios/s390-ccw/menu.c
index 083405f..2f11a51 100644
--- a/pc-bios/s390-ccw/menu.c
+++ b/pc-bios/s390-ccw/menu.c
@@ -225,19 +225,30 @@ int menu_get_zipl_boot_index(const char *menu_data)
return get_boot_index(valid_entries);
}
-
-int menu_get_enum_boot_index(int entries)
+int menu_get_enum_boot_index(bool *valid_entries)
{
-char tmp[4];
+char tmp[3];
+int i;
-sclp_print("s390x Enumerated Boot Menu.\n\n");
+sclp_print("s390-ccw Enumerated Boot Menu.\n\n");
-sclp_print(uitoa(entries, tmp, sizeof(tmp)));
-sclp_print(" entries detected. Select from boot index 0 to ");
-sclp_print(uitoa(entries - 1, tmp, sizeof(tmp)));
-sclp_print(".\n\n");
+for (i = 0; i < MAX_BOOT_ENTRIES; i++) {
+if (valid_entries[i]) {
+if (i < 10) {
+sclp_print(" ");
+}
+sclp_print("[");
+sclp_print(uitoa(i, tmp, sizeof(tmp)));
+sclp_print("]");
+if (i == 0) {
+sclp_print(" default\n");
+}
+sclp_print("\n");
+}
+}
-return get_boot_index(entries);
+sclp_print("\n");
+return get_boot_index(valid_entries);
}
void menu_set_parms(uint8_t boot_menu_flag, uint32_t boot_menu_timeout)
diff --git a/pc-bios/s390-ccw/s390-ccw.h b/pc-bios/s390-ccw/s390-ccw.h
index 2c9e601..a1bdb4c 100644
--- a/pc-bios/s390-ccw/s390-ccw.h
+++ b/pc-bios/s390-ccw/s390-ccw.h
@@ -91,7 +91,7 @@ void zipl_load(void);
void menu_set_parms(uint8_t boot_menu_flag, uint32_t boot_menu_timeout);
int menu_get_zipl_boot_index(const char *menu_data);
bool menu_is_enabled_zipl(void);
-int menu_get_enum_boot_index(int entries);
+int menu_get_enum_boot_index(bool *valid_entries);
bool menu_is_enabled_enum(void);
#define MAX_BOOT_ENTRIES 31
--
2.7.4
[Qemu-devel] [PULL 1/1] Revert "migration: Don't activate block devices if using -S"
From: "Dr. David Alan Gilbert"
This reverts commit 0746a92612276aee69e66dfe6782b0f882d221d5.
Discussion with kwolf suggests this is actually an API change that
we need to gate on a capability. Push to 2.13.
Signed-off-by: Dr. David Alan Gilbert
---
migration/migration.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 58bd382730..52a5092add 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -306,21 +306,13 @@ static void process_incoming_migration_bh(void *opaque)
Error *local_err = NULL;
MigrationIncomingState *mis = opaque;
-/* Only fire up the block code now if we're going to restart the
- * VM, else 'cont' will do it.
- * This causes file locking to happen; so we don't want it to happen
- * unless we really are starting the VM.
- */
-if (autostart && (!global_state_received() ||
-global_state_get_runstate() == RUN_STATE_RUNNING)) {
-/* Make sure all file formats flush their mutable metadata.
- * If we get an error here, just don't restart the VM yet. */
-bdrv_invalidate_cache_all(&local_err);
-if (local_err) {
-error_report_err(local_err);
-local_err = NULL;
-autostart = false;
-}
+/* Make sure all file formats flush their mutable metadata.
+ * If we get an error here, just don't restart the VM yet. */
+bdrv_invalidate_cache_all(&local_err);
+if (local_err) {
+error_report_err(local_err);
+local_err = NULL;
+autostart = false;
}
/*
--
2.16.2
[Qemu-devel] [PATCH 1/4] pc-bios/s390-ccw: rename MAX_TABLE_ENTRIES to MAX_BOOT_ENTRIES
The MAX_TABLE_ENTRIES constant has a name that is too generic. As we
want to declare a limit for boot menu entries, let's rename it to a more
fitting MAX_BOOT_ENTRIES and set its value to 31 (30 boot entries and
1 default entry). Also we move it from bootmap.h to s390-ccw.h to make
it available for menu.c in a later patch.
Signed-off-by: Collin Walling
---
pc-bios/s390-ccw/bootmap.c | 6 +++---
pc-bios/s390-ccw/bootmap.h | 2 --
pc-bios/s390-ccw/s390-ccw.h | 2 ++
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/pc-bios/s390-ccw/bootmap.c b/pc-bios/s390-ccw/bootmap.c
index fc2a9fe..2f79346 100644
--- a/pc-bios/s390-ccw/bootmap.c
+++ b/pc-bios/s390-ccw/bootmap.c
@@ -290,7 +290,7 @@ static void run_eckd_boot_script(block_number_t
bmt_block_nr,
}
debug_print_int("loadparm", loadparm);
-IPL_assert(loadparm <= MAX_TABLE_ENTRIES, "loadparm value greater than"
+IPL_assert(loadparm < MAX_BOOT_ENTRIES, "loadparm value greater than"
" maximum number of boot entries allowed");
memset(sec, FREE_SPACE_FILLER, sizeof(sec));
@@ -578,7 +578,7 @@ static void ipl_scsi(void)
read_block(mbr->pt.blockno, sec, "Error reading Program Table");
IPL_assert(magic_match(sec, ZIPL_MAGIC), "No zIPL magic in PT");
-while (program_table_entries <= MAX_TABLE_ENTRIES) {
+while (program_table_entries < MAX_BOOT_ENTRIES) {
if (!prog_table->entry[program_table_entries].scsi.blockno) {
break;
}
@@ -593,7 +593,7 @@ static void ipl_scsi(void)
}
debug_print_int("loadparm", loadparm);
-IPL_assert(loadparm <= MAX_TABLE_ENTRIES, "loadparm value greater than"
+IPL_assert(loadparm < MAX_BOOT_ENTRIES, "loadparm value greater than"
" maximum number of boot entries allowed");
zipl_run(&prog_table->entry[loadparm].scsi); /* no return */
diff --git a/pc-bios/s390-ccw/bootmap.h b/pc-bios/s390-ccw/bootmap.h
index 07eb600..732c111 100644
--- a/pc-bios/s390-ccw/bootmap.h
+++ b/pc-bios/s390-ccw/bootmap.h
@@ -57,8 +57,6 @@ typedef union BootMapPointer {
ExtEckdBlockPtr xeckd;
} __attribute__ ((packed)) BootMapPointer;
-#define MAX_TABLE_ENTRIES 30
-
/* aka Program Table */
typedef struct BootMapTable {
uint8_t magic[4];
diff --git a/pc-bios/s390-ccw/s390-ccw.h b/pc-bios/s390-ccw/s390-ccw.h
index fd18da2..2c9e601 100644
--- a/pc-bios/s390-ccw/s390-ccw.h
+++ b/pc-bios/s390-ccw/s390-ccw.h
@@ -94,6 +94,8 @@ bool menu_is_enabled_zipl(void);
int menu_get_enum_boot_index(int entries);
bool menu_is_enabled_enum(void);
+#define MAX_BOOT_ENTRIES 31
+
static inline void fill_hex(char *out, unsigned char val)
{
const char hex[] = "0123456789abcdef";
--
2.7.4
[Qemu-devel] [PATCH 2/4] pc-bios/s390-ccw: fix loadparm initialization and int conversion
Rename the loadparm char array in main.c to loadparm_str and
increase the size by one byte to account for a null termination
when converting the loadparm string to an int via atoui. Also
allow the boot menu to be enabled when loadparm is set to an
empty string or a series of spaces.
Signed-off-by: Collin Walling
Reported-by: Vasily Gorbik
---
hw/s390x/ipl.c | 2 ++
pc-bios/s390-ccw/main.c | 14 +++---
2 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index fdeaec3..23b5b54 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -352,6 +352,8 @@ int s390_ipl_set_loadparm(uint8_t *loadparm)
loadparm[i] = ascii2ebcdic[(uint8_t) lp[i]];
}
+memset(loadparm + i, 0x40, 8 - i); /* fill with EBCDIC spaces */
+
g_free(lp);
return 0;
}
diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index 9d9f8cf..26f9adf 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -15,11 +15,11 @@
char stack[PAGE_SIZE * 8] __attribute__((__aligned__(PAGE_SIZE)));
static SubChannelId blk_schid = { .one = 1 };
IplParameterBlock iplb __attribute__((__aligned__(PAGE_SIZE)));
-static char loadparm[8] = { 0, 0, 0, 0, 0, 0, 0, 0 };
+static char loadparm_str[9] = { 0, 0, 0, 0, 0, 0, 0, 0, 0 };
QemuIplParameters qipl;
#define LOADPARM_PROMPT "PROMPT "
-#define LOADPARM_EMPTY ""
+#define LOADPARM_EMPTY ""
#define BOOT_MENU_FLAG_MASK (QIPL_FLAG_BM_OPTS_CMD | QIPL_FLAG_BM_OPTS_ZIPL)
/*
@@ -45,7 +45,7 @@ void panic(const char *string)
unsigned int get_loadparm_index(void)
{
-return atoui(loadparm);
+return atoui(loadparm_str);
}
static bool find_dev(Schib *schib, int dev_no)
@@ -80,13 +80,13 @@ static bool find_dev(Schib *schib, int dev_no)
static void menu_setup(void)
{
-if (memcmp(loadparm, LOADPARM_PROMPT, 8) == 0) {
+if (memcmp(loadparm_str, LOADPARM_PROMPT, 8) == 0) {
menu_set_parms(QIPL_FLAG_BM_OPTS_CMD, 0);
return;
}
/* If loadparm was set to any other value, then do not enable menu */
-if (memcmp(loadparm, LOADPARM_EMPTY, 8) != 0) {
+if (memcmp(loadparm_str, LOADPARM_EMPTY, 8) != 0) {
return;
}
@@ -116,8 +116,8 @@ static void virtio_setup(void)
*/
enable_mss_facility();
-sclp_get_loadparm_ascii(loadparm);
-memcpy(ldp + 10, loadparm, 8);
+sclp_get_loadparm_ascii(loadparm_str);
+memcpy(ldp + 10, loadparm_str, 8);
sclp_print(ldp);
memcpy(&qipl, early_qipl, sizeof(QemuIplParameters));
--
2.7.4
[Qemu-devel] [PATCH 0/4] Small fixes for s390x QEMU boot menu
These patches fix the following: - The QEMU zIPL boot menu does not allow accurate selection of non-sequential entries. - The QEMU zIPL boot menu does not have all the capabilities of the real zIPL menu (such as commandline args). We should print a different banner to reflect this. - The loadparm array in main.c can end up being not null terminated when converted to an integer via atoui. - A loadparm set to an empty string does not allow a boot menu. Collin Walling (4): pc-bios/s390-ccw: rename MAX_TABLE_ENTRIES to MAX_BOOT_ENTRIES pc-bios/s390-ccw: fix loadparm initialization and int conversion pc-bios/s390-ccw: fix non-sequential boot entries (eckd) pc-bios/s390-ccw: fix non-sequential boot entries (enum) hw/s390x/ipl.c | 2 ++ pc-bios/s390-ccw/bootmap.c | 16 ++-- pc-bios/s390-ccw/bootmap.h | 2 -- pc-bios/s390-ccw/main.c | 14 +-- pc-bios/s390-ccw/menu.c | 61 + pc-bios/s390-ccw/s390-ccw.h | 4 ++- 6 files changed, 61 insertions(+), 38 deletions(-) -- 2.7.4
[Qemu-devel] [PATCH 3/4] pc-bios/s390-ccw: fix non-sequential boot entries (eckd)
zIPL boot menu entries can be non-sequential. Let's account
for this issue for the s390 zIPL boot menu. Since this boot
menu is actually an imitation and is not completely capable
of everything the real zIPL menu can do, let's also print a
different banner to the user.
Signed-off-by: Collin Walling
Reported-by: Vasily Gorbik
---
pc-bios/s390-ccw/menu.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/pc-bios/s390-ccw/menu.c b/pc-bios/s390-ccw/menu.c
index 96eec81..083405f 100644
--- a/pc-bios/s390-ccw/menu.c
+++ b/pc-bios/s390-ccw/menu.c
@@ -158,7 +158,7 @@ static void boot_menu_prompt(bool retry)
}
}
-static int get_boot_index(int entries)
+static int get_boot_index(bool *valid_entries)
{
int boot_index;
bool retry = false;
@@ -168,7 +168,8 @@ static int get_boot_index(int entries)
boot_menu_prompt(retry);
boot_index = get_index();
retry = true;
-} while (boot_index < 0 || boot_index >= entries);
+} while (boot_index < 0 || boot_index >= MAX_BOOT_ENTRIES ||
+ !valid_entries[boot_index]);
sclp_print("\nBooting entry #");
sclp_print(uitoa(boot_index, tmp, sizeof(tmp)));
@@ -176,21 +177,28 @@ static int get_boot_index(int entries)
return boot_index;
}
-static void zipl_println(const char *data, size_t len)
+static void zipl_println(const char *data, size_t len, bool *valid_entries)
{
char buf[len + 2];
+int entry;
ebcdic_to_ascii(data, buf, len);
buf[len] = '\n';
buf[len + 1] = '\0';
sclp_print(buf);
+
+entry = buf[0] == ' ' ? atoui(buf + 1) : atoui(buf);
+valid_entries[entry] = true;
+
+if (entry == 0)
+sclp_print("\n");
}
int menu_get_zipl_boot_index(const char *menu_data)
{
size_t len;
-int entries;
+bool valid_entries[MAX_BOOT_ENTRIES] = {false};
uint16_t zipl_flag = *(uint16_t *)(menu_data - ZIPL_FLAG_OFFSET);
uint16_t zipl_timeout = *(uint16_t *)(menu_data - ZIPL_TIMEOUT_OFFSET);
@@ -202,19 +210,19 @@ int menu_get_zipl_boot_index(const char *menu_data)
timeout = zipl_timeout * 1000;
}
-/* Print and count all menu items, including the banner */
-for (entries = 0; *menu_data; entries++) {
+/* Print banner */
+sclp_print("s390-ccw zIPL Boot Menu\n\n");
+menu_data += strlen(menu_data) + 1;
+
+/* Print entries */
+while (*menu_data) {
len = strlen(menu_data);
-zipl_println(menu_data, len);
+zipl_println(menu_data, len, valid_entries);
menu_data += len + 1;
-
-if (entries < 2) {
-sclp_print("\n");
-}
}
sclp_print("\n");
-return get_boot_index(entries - 1); /* subtract 1 to exclude banner */
+return get_boot_index(valid_entries);
}
--
2.7.4
Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S
Am 10.04.2018 um 16:22 hat Dr. David Alan Gilbert geschrieben: > * Kevin Wolf (kw...@redhat.com) wrote: > > Am 10.04.2018 um 12:40 hat Dr. David Alan Gilbert geschrieben: > > > Hmm; having chatted to Jiri I'm OK with reverting it, on the condition > > > that I actually understand how this alternative would work first. > > > > > > I can't currently see how a block-inactivate would be used. > > > I also can't see how a block-activate unless it's also with the > > > change that you're asking to revert. > > > > > > Can you explain the way you see it working? > > > > The key is making the delayed activation of block devices (and probably > > delayed announcement of NICs? - you didn't answer that part) optional > > instead of making it the default. > > NIC announcments are broken in similar but slightly different ways; we > did have a series on list to help a while ago but it never got merged; > I'd like to keep that mess separate. Okay. I just thought that it would make sense to have clear migration phases that are the same for all external resources that the QEMU processes use. > > We can use Jirka's suggestion of adding a migration capability that > > enables it, or I suppose a new option to -incoming could work, too. It > > doesn't really matter what the syntax is, but the management tool must > > request it explicitly. > > A new capability is easy to gate the change in behaviour that this patch > added; I'll do that first thing for 2.13 (given today is rc3 tag it's > too late). > > However, once we turn this on, to cope with the situation of a block user > that must start prior to the 'cont' when this behaviour is active, we'd > also need the 'block-activate' command. Yes, that's right. Kevin
Re: [Qemu-devel] [PATCH v2 17/17] target/riscv: convert to TranslatorOps
On Tue, Apr 10, 2018 at 09:05:06 -0500, Eric Blake wrote:
> On 04/10/2018 07:59 AM, Emilio G. Cota wrote:
> > On Tue, Apr 10, 2018 at 11:24:37 +1000, Richard Henderson wrote:
> >> On 04/07/2018 04:20 AM, Emilio G. Cota wrote:
> >>> +next_page = (ctx->base.pc_first & TARGET_PAGE_MASK) +
> >>> TARGET_PAGE_SIZE;
> >>> +if (ctx->base.pc_next >= next_page) {
> >>
> >> This fails for the last page of the address space.
> >> Better is
> >>
> >> page_start = ctx->base.pc_first & TARGET_PAGE_MASK;
> >> if (ctx->base.pc_next - page_start >= TARGET_PAGE_SIZE) {
> >
> > Apart from the variable name change, I fail to see how this (A - B >= C)
> > is not equivalent to the above (A => B + C). What am I missing?
>
> Integer overflow. Adding TARGET_PAGE_SIZE might wrap next_page to 0,
> which changes the semantics of the conditional; while performing the
> subtraction avoids the case of overflow.
Ah indeed. Thanks.
Turns out we have this problem in other targets as well -- will fix.
E.
Re: [Qemu-devel] [PATCH for-2.12 v2] qemu-iotests: update 185 output
Am 10.04.2018 um 10:11 hat Stefan Hajnoczi geschrieben: > On Wed, Apr 04, 2018 at 06:16:12PM +0200, Max Reitz wrote: > > On 2018-04-04 17:01, Stefan Hajnoczi wrote: > > === Start mirror job and exit qemu === > > > > This seems to be independent of whether there is actually data on > > TEST_IMG (the commit source), so something doesn't seem quite right with > > the block job throttling here...? > > I've been playing around with this test failure. Let's leave it broken > (!) in QEMU 2.12 because this test has uncovered a block job ratelimit > issue that's not a regression. The fix shouldn't be rushed. Makes sense. Thanks, applied to the block branch. Kevin signature.asc Description: PGP signature
Re: [Qemu-devel] [PATCH for-2.12] make-release: add skiboot .version file
On 10 April 2018 at 15:23, Michael Roth wrote: > Quoting Peter Maydell (2018-04-10 02:31:04) >> On 10 April 2018 at 01:57, Michael Roth wrote: >> > # FIXME: The following line is a workaround for avoiding filename >> > collisions >> > # when unpacking u-boot sources on case-insensitive filesystems. Once we >> > # update to something with u-boot commit 610eec7f0 we can drop this line. >> >> Seeing this comment in the context part of this patch reminds me: >> have we updated to a u-boot that lets us drop the workaround yet? > > Not yet, we need: > > https://github.com/u-boot/u-boot/commit/610eec7f0 > > which was committed Oct 2017, but QEMU master is still using the > v2017.07 July release, via: > > https://github.com/qemu/qemu/commit/73663d71 I guess it's too late in the 2.12 release cycle to update our u-boot binary, but we should remember to do it at the start of 2.13... thanks -- PMM
[Qemu-devel] [Bug 1762707] Re: VFIO device gets DMA failures when virtio-balloon leak from highmem to lowmem
Ballooning is currently incompatible with device assignment. When the balloon is inflated (memory removed from the VM), the pages are zapped from the process without actually removing them from the vfio DMA mapping. The pages are still pinned from the previous mapping, making the balloon inflation ineffective (pages are not available for re-use). When the balloon is deflated, new (different) pages are faulted in for the previously zapped pages, but these are again not DMA mapped for the IOMMU, so now the physical memory backing a given address in the VM are different for processor and assigned device access and DMA will fail. In order to support this, QEMU would need to do more than simply zap pages from the process address space, they'd need to be unmapped from the IOMMU, but we can only do that using the original mapping size. Effectively, memory hotplug is a better solution when device assignment is involved. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1762707 Title: VFIO device gets DMA failures when virtio-balloon leak from highmem to lowmem Status in QEMU: New Bug description: Is there any known conflict between VFIO passthrough device and virtio-balloon? The VM has: 1. 4GB system memory 2. one VFIO passthrough device which supports high address memory DMA and uses GFP_HIGHUSER pages. 3. Memory balloon device with 4GB target. When setting the memory balloon target to 1GB and 4GB in loop during runtime (I used the command "virsh qemu-monitor-command debian --hmp --cmd balloon 1024"), the VFIO device DMA randomly gets failure. More clues: 1. configure 2GB system memory (no highmem) VM, no issue with similar operations 2. setting the memory balloon to higher like 8GB, no issue with similar operations I'm also trying to narrow down this issue. It's appreciated for that you guys may share some thoughts. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1762707/+subscriptions
Re: [Qemu-devel] [PATCH for-2.12] make-release: add skiboot .version file
Quoting Peter Maydell (2018-04-10 02:31:04)
> On 10 April 2018 at 01:57, Michael Roth wrote:
> > This is needed to build skiboot from tarball-distributed sources
> > since the git data the make_release.sh script relies on to generate
> > it is not available.
> >
> > Cc: qemu-sta...@nongnu.org
> > Reported-by: Michael Tokarev
> > Signed-off-by: Michael Roth
> > ---
> > scripts/make-release | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/scripts/make-release b/scripts/make-release
> > index 04fa9defdc..c14f75b12c 100755
> > --- a/scripts/make-release
> > +++ b/scripts/make-release
> > @@ -19,6 +19,7 @@ pushd ${destination}
> > git checkout "v${version}"
> > git submodule update --init
> > (cd roms/seabios && git describe --tags --long --dirty > .version)
> > +(cd roms/skiboot && ./make_version.sh > .version)
> > # FIXME: The following line is a workaround for avoiding filename
> > collisions
> > # when unpacking u-boot sources on case-insensitive filesystems. Once we
> > # update to something with u-boot commit 610eec7f0 we can drop this line.
>
> Seeing this comment in the context part of this patch reminds me:
> have we updated to a u-boot that lets us drop the workaround yet?
Not yet, we need:
https://github.com/u-boot/u-boot/commit/610eec7f0
which was committed Oct 2017, but QEMU master is still using the
v2017.07 July release, via:
https://github.com/qemu/qemu/commit/73663d71
>
> thanks
> -- PMM
>
Re: [Qemu-devel] [PATCH v2 06/17] target/mips: convert to DisasJumpType
On Tue, Apr 10, 2018 at 13:56:25 +1000, Richard Henderson wrote:
> Ok, well, there are existing bugs within the MIPS translation here, and we
> might as well fix them within this patch set.
>
> (1) The description for BS_STOP says we want to stop, but (what will become)
> mips_tr_tb_stop calls goto_tb.
>
> That's not correct, since we use that after e.g. helper_mtc0_hwrena,
> MIPS_HFLAG_HWRENA_ULR is included in tb->flags, and therefore the next TB is
> not fixed but depends on the actual value stored into hwrena.
>
> We should instead use lookup_and_goto_ptr, which does a full lookup of the
> processor state every time through.
I thought I understood what you meant here but the corresponding change
doesn't seem to work; without the change I can boot a guest in ~1m20s;
with it, boot-up gets stuck -- or at the very least, it's so slow that
I'm giving up after 3+ minutes. The change I made:
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -20339,7 +20339,7 @@ void gen_intermediate_code(CPUState *cs, struct
TranslationBlock *tb)
} else {
switch (ctx.is_jmp) {
case DISAS_STOP:
-gen_goto_tb(&ctx, 0, ctx.pc);
+tcg_gen_lookup_and_goto_ptr();
break;
So I'm afraid I don't understand what the change should be, then.
> (2) The BS_EXCP in generate_exception_err should map to DISAS_NORETURN,
> because
> we do not return after raising an exception.
>
> (3) Otherwise, the use of BS_EXCP has nothing to do with an exception; e.g.
>
> > case 0:
> > save_cpu_state(ctx, 1);
> > gen_helper_mtc0_status(cpu_env, arg);
> > /* BS_STOP isn't good enough here, hflags may have changed. */
> > gen_save_pc(ctx->pc + 4);
> > ctx->bstate = BS_EXCP;
> > rn = "Status";
> > break;
>
> where we are in fact relying on (what will become) mips_tr_tb_stop to emit
> exit_tb. It would be better to name these uses DISAS_EXIT, which would match
> e.g. target/arm.
Thanks for this -- delta with (2) and (3) below.
Emilio
---
diff --git a/target/mips/translate.c b/target/mips/translate.c
index 99ecfa1..4183ec2 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -1463,6 +1463,7 @@ typedef struct DisasContext {
#define DISAS_STOP DISAS_TARGET_0
#define DISAS_EXCP DISAS_TARGET_1
+#define DISAS_EXIT DISAS_TARGET_2
static const char * const regnames[] = {
"r0", "at", "v0", "v1", "a0", "a1", "a2", "a3",
@@ -1635,7 +1636,7 @@ static inline void generate_exception_err(DisasContext
*ctx, int excp, int err)
gen_helper_raise_exception_err(cpu_env, texcp, terr);
tcg_temp_free_i32(terr);
tcg_temp_free_i32(texcp);
-ctx->is_jmp = DISAS_EXCP;
+ctx->is_jmp = DISAS_NORETURN;
}
static inline void generate_exception(DisasContext *ctx, int excp)
@@ -5333,7 +5334,7 @@ static void gen_mfc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
after reading count. DISAS_STOP isn't sufficient, we need to
ensure we break completely out of translated code. */
gen_save_pc(ctx->pc + 4);
-ctx->is_jmp = DISAS_EXCP;
+ctx->is_jmp = DISAS_EXIT;
rn = "Count";
break;
/* 6,7 are implementation dependent */
@@ -6026,7 +6027,7 @@ static void gen_mtc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
gen_helper_mtc0_status(cpu_env, arg);
/* DISAS_STOP isn't good enough here, hflags may have changed. */
gen_save_pc(ctx->pc + 4);
-ctx->is_jmp = DISAS_EXCP;
+ctx->is_jmp = DISAS_EXIT;
rn = "Status";
break;
case 1:
@@ -6063,7 +6064,7 @@ static void gen_mtc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
* DISAS_STOP isn't sufficient, we need to ensure we break out of
* translated code to check for pending interrupts. */
gen_save_pc(ctx->pc + 4);
-ctx->is_jmp = DISAS_EXCP;
+ctx->is_jmp = DISAS_EXIT;
rn = "Cause";
break;
default:
@@ -6219,7 +6220,7 @@ static void gen_mtc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
gen_helper_mtc0_debug(cpu_env, arg); /* EJTAG support */
/* DISAS_STOP isn't good enough here, hflags may have changed. */
gen_save_pc(ctx->pc + 4);
-ctx->is_jmp = DISAS_EXCP;
+ctx->is_jmp = DISAS_EXIT;
rn = "Debug";
break;
case 1:
@@ -6401,7 +6402,7 @@ static void gen_mtc0(DisasContext *ctx, TCGv arg, int
reg, int sel)
/* DISAS_STOP isn't sufficient, we need to ensure we break out of
* translated code to check for pending interrupts. */
gen_save_pc(ctx->pc + 4);
-ctx->is_jmp = DISAS_EXCP;
+ctx->is_jmp = DISAS_EXIT;
}
return;
@@ -6685,7 +6686,7 @@ static void gen_dmfc0(Dis
Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S
* Kevin Wolf (kw...@redhat.com) wrote: > Am 10.04.2018 um 12:40 hat Dr. David Alan Gilbert geschrieben: > > * Kevin Wolf (kw...@redhat.com) wrote: > > > Am 10.04.2018 um 10:45 hat Dr. David Alan Gilbert geschrieben: > > > > * Kevin Wolf (kw...@redhat.com) wrote: > > > > > Am 10.04.2018 um 09:36 hat Jiri Denemark geschrieben: > > > > > > On Mon, Apr 09, 2018 at 15:40:03 +0200, Kevin Wolf wrote: > > > > > > > Am 09.04.2018 um 12:27 hat Dr. David Alan Gilbert geschrieben: > > > > > > > > It's a fairly hairy failure case they had; if I remember > > > > > > > > correctly it's: > > > > > > > > a) Start migration > > > > > > > > b) Migration gets to completion point > > > > > > > > c) Destination is still paused > > > > > > > > d) Libvirt is restarted on the source > > > > > > > > e) Since libvirt was restarted it fails the migration (and > > > > > > > > hence knows > > > > > > > > the destination won't be started) > > > > > > > > f) It now tries to resume the qemu on the source > > > > > > > > > > > > > > > > (f) fails because (b) caused the locks to be taken on the > > > > > > > > destination; > > > > > > > > hence this patch stops doing that. It's a case we don't really > > > > > > > > think > > > > > > > > about - i.e. that the migration has actually completed and all > > > > > > > > the data > > > > > > > > is on the destination, but libvirt decides for some other > > > > > > > > reason to > > > > > > > > abandon migration. > > > > > > > > > > > > > > If you do remember correctly, that scenario doesn't feel tricky > > > > > > > at all. > > > > > > > libvirt needs to quit the destination qemu, which will inactivate > > > > > > > the > > > > > > > images on the destination and release the lock, and then it can > > > > > > > continue > > > > > > > the source. > > > > > > > > > > > > > > In fact, this is so straightforward that I wonder what else > > > > > > > libvirt is > > > > > > > doing. Is the destination qemu only shut down after trying to > > > > > > > continue > > > > > > > the source? That would be libvirt using the wrong order of steps. > > > > > > > > > > > > There's no connection between the two libvirt daemons in the case > > > > > > we're > > > > > > talking about so they can't really synchronize the actions. The > > > > > > destination daemon will kill the new QEMU process and the source > > > > > > will > > > > > > resume the old one, but the order is completely random. > > > > > > > > > > Hm, okay... > > > > > > > > > > > > > Yes it was a 'block-activate' that I'd wondered about. One > > > > > > > > complication > > > > > > > > is that if this now under the control of the management layer > > > > > > > > then we > > > > > > > > should stop asserting when the block devices aren't in the > > > > > > > > expected > > > > > > > > state and just cleanly fail the command instead. > > > > > > > > > > > > > > Requiring an explicit 'block-activate' on the destination would > > > > > > > be an > > > > > > > incompatible change, so you would have to introduce a new option > > > > > > > for > > > > > > > that. 'block-inactivate' on the source feels a bit simpler. > > > > > > > > > > > > As I said in another email, the explicit block-activate command > > > > > > could > > > > > > depend on a migration capability similarly to how pre-switchover > > > > > > state > > > > > > works. > > > > > > > > > > Yeah, that's exactly the thing that we wouldn't need if we could use > > > > > 'block-inactivate' on the source instead. It feels a bit wrong to > > > > > design a more involved QEMU interface around the libvirt internals, > > > > > > > > It's not necessarily 'libvirt internals' - it's a case of them having to > > > > cope with recovering from failures that happen around migration; it's > > > > not an easy problem, and if they've got a way to stop both sides running > > > > at the same time that's pretty important. > > > > > > The 'libvirt internals' isn't that it needs an additional state where > > > neither source nor destination QEMU own the images, but that it has to > > > be between migration completion and image activation on the destination > > > rather than between image inactivation on the source and migration > > > completion. The latter would be much easier for qemu, but apparently it > > > doesn't work for libvirt because of how it works internally. > > > > I suspect this is actually a fundamental requirement to ensuring that we > > don't end up with a QEMU running on both sides rather than how libvirt is > > structured. > > I don't think so. In theory, both options can provide the same. If > anything, it's related specifically to the phases that Jirka described > that libvirt uses to implement migration. > > > > But as I said, I'd just implement both for symmetry and then management > > > tools can pick whatever makes their life easier. > > > > > > > > but > > > > > as long as we implement both sides for symmetry and libvirt just > > > > > happen
Re: [Qemu-devel] [RfC PATCH] Add udmabuf misc device
Hi, > Generally we try to cache mappings as much as possible. And wrt finding a > slot: Create a sufficiently sized BAR on the virgl device, just for that? Well. virtio has no concept of "bars" ... The most common virtio transport layer happens to be pci, which actually has bars. But we also have virtio-mmio (largely unused since arm got pci) and virtio-ccw (used on s390x). In any case it would be a layering violation. Figured meanwhile qemu got memfd support recently, i.e. it can be configured to back guest memory with memfd. Which makes the memfd route quite attractive. Guess I try switch udmabuf to require memfd storage as proof-of-concept. cheers, Gerd
Re: [Qemu-devel] [PULL 0/4] Ui 20180410 patches
On 10 April 2018 at 10:24, Gerd Hoffmann wrote: > The following changes since commit 915d34c5f99b0ab91517c69f54272bfdb6ca2b32: > > Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into > staging (2018-04-09 17:29:10 +0100) > > are available in the git repository at: > > git://git.kraxel.org/qemu tags/ui-20180410-pull-request > > for you to fetch changes up to c6093a05d6a84d2144bb6462cf20e907eddf8aeb: > > configure: don't warn SDL abi if disabled (2018-04-10 11:22:03 +0200) > > > configure: don't warn on old sdl/gtk versions if disabled. > keymap + gtk fixes. > > Applied, thanks. -- PMM
[Qemu-devel] [Bug 1748434] Re: Possibly wrong GICv3 behavior when secure enabled
Now fixed in master in commit a2e2d7fc46fd8be, so will be in 2.12.0. ** Changed in: qemu Status: In Progress => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1748434 Title: Possibly wrong GICv3 behavior when secure enabled Status in QEMU: Fix Committed Bug description: I an tried arm-aarch64 interrupt routing to EL3, by SCR_EL3.FIQ=1. First I am started QEMU with secure=on and GICv3 support. I programmed secure and non-secure timers and set-up appropriate interrupts.Secure timer to be GRP1_Secure and non-secure timer to be GRP1_NonSecure. ICC_PMR = 0xff. Then I switched CPU to EL1. With that setup no interrupt was delivered to PE. GIC interface showed that non secure IRQ is pending. ICC_PMR read at EL1 returns 0 (shall return value ((PMR_(el3) << 1) & 0xff) according to GIC specification. Than I tried to increase interrupt priority mask - so I set ICC_PMR = 0x7f (at EL3). Then I read at EL1 ICC_PMR=0xfe - (is shall be 0). With this setup IRQ of secure timer was taken at EL3, non secure timer didn't rise IRQ (as it is masked by PMR). I dig to qemu code and see wrong condition in file arm_gicv3_cpuif.c in function icc_pmr_read(). This behavior is opposite of ARM specification. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1748434/+subscriptions
Re: [Qemu-devel] [PATCH v2 17/17] target/riscv: convert to TranslatorOps
On 04/10/2018 07:59 AM, Emilio G. Cota wrote:
> On Tue, Apr 10, 2018 at 11:24:37 +1000, Richard Henderson wrote:
>> On 04/07/2018 04:20 AM, Emilio G. Cota wrote:
>>> +next_page = (ctx->base.pc_first & TARGET_PAGE_MASK) +
>>> TARGET_PAGE_SIZE;
>>> +if (ctx->base.pc_next >= next_page) {
>>
>> This fails for the last page of the address space.
>> Better is
>>
>> page_start = ctx->base.pc_first & TARGET_PAGE_MASK;
>> if (ctx->base.pc_next - page_start >= TARGET_PAGE_SIZE) {
>
> Apart from the variable name change, I fail to see how this (A - B >= C)
> is not equivalent to the above (A => B + C). What am I missing?
Integer overflow. Adding TARGET_PAGE_SIZE might wrap next_page to 0,
which changes the semantics of the conditional; while performing the
subtraction avoids the case of overflow.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
[Qemu-devel] [Bug 1755479] Re: Cortex M:qemu abort with optimized code and icount
This is now fixed in master (and will be in 2.12.0) with commits 0790f8686107 and 87f963be66a32453e001. ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1755479 Title: Cortex M:qemu abort with optimized code and icount Status in QEMU: Fix Committed Bug description: A basic program runs fine if compiled with flag -O0 with gcc, but triggers a qemu abort when compiled with -O1 and run with icount: "qemu: fatal: IO on conditional branch instruction" I also noticed the problem on C source like this with -O0: "int foo = *bar; bar++;" : OK "int foo = *bar++;" : FAIL (!!!) Optimized binary attached to this ticket. command line: qemu-system-arm -M lm3s6965evb -nographic -kernel hello.bin -serial file:$(tty) -icount 4 -cpu cortex-m4 (working fine without icount) version: QEMU emulator version 2.11.50 (v2.11.0-2146-gd9bbfea-dirty) Compilation options: ./configure --target-list=arm-softmmu --disable-slirp --disable-blobs --disable-docs --disable-guest-agent --disable-gnutls --disable-nettle --disable-gcrypt --disable-sdl --disable-gtk --disable-vnc --disable-virtfs --disable-mpath --disable-xen --disable-brlapi --disable-curl --disable-bluez --disable-kvm --disable-hax --disable-hvf --disable-whpx --disable-rdma --disable-vde --disable-netmap --disable-linux-aio --disable-cap-ng --disable-attr --disable-vhost-net --disable-spice --disable-rbd --disable-libiscsi --disable-libnfs --disable-smartcard --disable-libusb --disable-live-block-migration --disable-usb-redir --disable-lzo --disable-snappy --disable-bzip2 --disable-seccomp --disable-glusterfs --disable-tpm --disable-libssh2 --disable-numa --disable-libxml2 --disable-tcmalloc --disable-jemalloc --disable-replication --disable-vhost-vsock --disable-opengl --disable-virglrenderer --disable-xfsctl --disable-qom-cast-debug --disable-vxhs --disable-crypto-afalg --disable-vhost-user --disable-capstone --disable-pie --extra-cflags=-mtune=native I have also tested previous versions: - stock qemu-system-arm 2.5.0 from ubuntu 16.04: OK - git version: QEMU emulator version 2.10.0 (v2.10.2-dirty): OK - git version: QEMU emulator version 2.10.90 (v2.11.0-rc0-dirty): FAIL To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1755479/+subscriptions
[Qemu-devel] [Bug 1760262] Re: cmsdk-apb-uart doesn't appear to clear interrupt flags
Thanks for the bug report; I've submitted this patch (which is similar to but not quite the same as your fix): https://patchwork.ozlabs.org/patch/896715/ Hopefully this will get into 2.12, but we're quite close to release now so it will depend on whether we need to spin an extra release candidate for some other reason. ** Changed in: qemu Status: New => In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1760262 Title: cmsdk-apb-uart doesn't appear to clear interrupt flags Status in QEMU: In Progress Bug description: I have been writing a small operating system and using QEMU emulating the mps2-an385 board for some of my testing. During development of the uart driver I observed some odd behaviour with the TX interrupt -- writing a '1' to bit 0 of the INTCLEAR register doesn't clear the TX interrupt flag, and the interrupt fires continuously. It's possible that I have an error somewhere in my code, but after inspecting the QEMU source it does appear to be a QEMU bug. I applied the following patch and it solved my issue: From 9875839c144fa60a3772f16ae44d32685f9328aa Mon Sep 17 00:00:00 2001 From: Patrick Oppenlander Date: Sat, 31 Mar 2018 15:10:28 +1100 Subject: [PATCH] hw/char/cmsdk-apb-uart: fix clearing of interrupt flags --- hw/char/cmsdk-apb-uart.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/char/cmsdk-apb-uart.c b/hw/char/cmsdk-apb-uart.c index 1ad1e14295..64991bd9d7 100644 --- a/hw/char/cmsdk-apb-uart.c +++ b/hw/char/cmsdk-apb-uart.c @@ -274,6 +274,7 @@ static void uart_write(void *opaque, hwaddr offset, uint64_t value, * is then reflected into the intstatus value by the update function). */ s->state &= ~(value & (R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); +s->intstatus &= ~(value & ~(R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); cmsdk_apb_uart_update(s); break; case A_BAUDDIV: -- 2.16.2 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1760262/+subscriptions
[Qemu-devel] [Bug 1756519] Re: qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create
Should be fixed by 73a988d957b9142e0 (which is the patch jcmvbkbc mentions in comment #4), now in master and will be in 2.12.0. ** Changed in: qemu Status: New => Fix Committed -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1756519 Title: qemu linux-user crash in QOM path canonicalization during do_fork() call to cpu_create Status in QEMU: Fix Committed Bug description: qemu-riscv64 version 2.11.50 (v2.11.0-2491-g2bb39a657a) crashes running gcc libgomp.c/sort-1.c testsuite test case with the following message: (process:11683): GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed ** ERROR:qom/object.c:1665:object_get_canonical_path_component: code should not be reached qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x60139c16 Backtrace obtained via gdb: #0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x60139b21 in abort () at abort.c:79 #2 0x60100505 in g_assertion_message (domain=domain@entry=0x0, file=file@entry=0x60213ca1 "qom/object.c", line=line@entry=1665, func=func@entry=0x60214420 <__func__.18106> "object_get_canonical_path_component", message=message@entry=0x7fffe8000cd0 "code should not be reached") at gtestutils.c:2430 #3 0x60100586 in g_assertion_message_expr (domain=0x0, file=0x60213ca1 "qom/object.c", line=1665, func=0x60214420 <__func__.18106> "object_get_canonical_path_component", expr=) at gtestutils.c:2453 #4 0x60098334 in object_get_canonical_path_component (obj=0x7fffe81340b0) at qom/object.c:1665 #5 0x60098366 in object_get_canonical_path (obj=0x7fffe81340b0) at qom/object.c:1675 #6 0x6008e152 in device_set_realized (obj=0x7fffe81340b0, value=true, errp=0x7762fe68) at hw/core/qdev.c:874 #7 0x60098bf4 in property_set_bool (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", opaque=0x7fffe80fd140, errp=0x7762fe68) at qom/object.c:1926 #8 0x60096fee in object_property_set (obj=0x7fffe81340b0, v=0x7fffe80fd3c0, name=0x60213694 "realized", errp=0x7762fe68) at qom/object.c:1122 #9 0x60099ebd in object_property_set_qobject (obj=0x7fffe81340b0, value=0x7fffe80fd310, name=0x60213694 "realized", errp=0x7762fe68) at qom/qom-qobject.c:27 #10 0x60097274 in object_property_set_bool (obj=0x7fffe81340b0, value=true, name=0x60213694 "realized", errp=0x7762fe68) at qom/object.c:1191 #11 0x60092ec5 in cpu_create (typename=0x6250e1a0 "any-riscv-cpu") at qom/cpu.c:61 #12 0x6009301a in cpu_generic_init (typename=0x601dd58f "riscv-cpu", cpu_model=0x601dd527 "any") at qom/cpu.c:98 #13 0x6004cb61 in cpu_copy (env=0x7008cd60) at /opt/qemu/linux-user/main.c:3881 #14 0x6005b79a in do_fork (env=0x7008cd60, flags=4001536, newsp=275531880704, parent_tidptr=275531882704, newtls=275531884288, child_tidptr=275531882704) at /opt/qemu/linux-user/syscall.c:6348 #15 0x60063e56 in do_syscall (cpu_env=0x7008cd60, num=220, arg1=4001536, arg2=275531880704, arg3=275531882704, arg4=275531884288, arg5=275531882704, arg6=275531884288, arg7=0, arg8=0) at /opt/qemu/linux-user/syscall.c:10001 #16 0x6004c89f in cpu_loop (env=0x7008cd60) at /opt/qemu/linux-user/main.c:3600 #17 0x6005b68f in clone_func (arg=0x77775050) at /opt/qemu/linux-user/syscall.c:6311 #18 0x60121797 in start_thread (arg=0x77632700) at pthread_create.c:463 #19 0x6019b4fb in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Attached is a test case source code extracted from libgomp test suite. Note that it is a multi-threaded and requires 5 or more threads to fail. Number of launched threads is controlled by OMP_NUM_THREADS evironment variable, defaulting to number of hardware threads. Changing constants in the test case makes it fail with different numbers of threads. I will attach statically linked riscv64 binary executable if size limits permit. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1756519/+subscriptions
Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread
On 04/10/2018 07:49 AM, Peter Xu wrote: > cur_mon was only used in main loop so we don't really need that to be > per-thread variable. Now it's possible that we have more than one > thread to operate on it. Let's start to let it be per-thread variable. > > In case we'll create threads within a valid cur_mon setup, we'd better > let the child threads to inherit the cur_mon from parent thread too. Do > that for both posix and win32 threads. > > Signed-off-by: Peter Xu > --- > include/monitor/monitor.h | 2 +- > include/qemu/thread-win32.h | 1 + > monitor.c | 2 +- > stubs/monitor.c | 2 +- > tests/test-util-sockets.c | 2 +- > util/qemu-thread-posix.c| 6 ++ > util/qemu-thread-win32.c| 6 ++ > 7 files changed, 17 insertions(+), 4 deletions(-) > > @@ -494,6 +496,9 @@ static void *qemu_thread_start(void *args) > void *(*start_routine)(void *) = qemu_thread_args->start_routine; > void *arg = qemu_thread_args->arg; > > +/* Inherit the cur_mon pointer from father thread */ More typical as s/father/parent/ > +++ b/util/qemu-thread-win32.c > @@ -339,6 +341,9 @@ static unsigned __stdcall win32_start_routine(void *arg) > void *(*start_routine)(void *) = data->start_routine; > void *thread_arg = data->arg; > > +/* Inherit the cur_mon pointer from father thread */ > +cur_mon = data->current_monitor; Otherwise makes sense to me. I agree with your analysis that the set of existing OOB commands (just 'x-oob-test') has no direct use of cur_mon. I'm a little fuzzier on whether the OOB changes can cause cur_mon to be modified by two threads in parallel (monitor_qmp_dispatch_one() is futzing around with 'cur_mon' around the call to qmp_dispatch(), and at least qmp_human_monitor_command() is also futzing around with it; is there a case where handling qmp_human_monitor_command() in the dispatch thread in parallel with more input on the main thread could break?) Thus I'm not sure whether this is needed for 2.12 to avoid a regression. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2] linux-user: implement HWCAP bits on MIPS
On 15 March 2018 at 15:25, Laurent Vivier wrote: > Le 15/03/2018 à 16:13, James Cowgill a écrit : >> Add support for the two currently defined HWCAP bits on MIPS - R6 and >> MSA. >> >> Buglink: https://bugs.launchpad.net/qemu/+bug/1754372 >> Signed-off-by: James Cowgill >> --- >> v2 changes: >> - Fix kernel hwcap.h path. >> >> linux-user/elfload.c | 24 >> 1 file changed, 24 insertions(+) >> > > Reviewed-by: Laurent Vivier Hi Laurent -- did this MIPS HWCAP fix get lost somewhere? I can't see it in master or your latest pullreq. thanks -- PMM
[Qemu-devel] QEMU - DOS - simulate DPR-RAM
Hello, i have old DOS 6.22 Systems with a DPR (dual ported ram) at Adress d000:0 with 4kB size. Now i want to emulate this system with QEMU in Windows and want to read/write data to this DPR memoryblock from my Windows System. Can i do that? is there an option to emulate a Memoryblock at the mainmemory in a DOS emulated system ? Thanks for your help Thomas S.
Re: [Qemu-devel] [PATCH v2 1/2 for-2.12?] qapi: Parameter gl of DisplayType now accept an enum
On Tue, Apr 10, 2018 at 08:13:00AM -0500, Eric Blake wrote:
> On 04/10/2018 07:02 AM, Elie Tournier wrote:
> > Signed-off-by: Elie Tournier
> > ---
> > qapi/ui.json | 21 -
> > vl.c | 10 +-
> > 2 files changed, 25 insertions(+), 6 deletions(-)
> >
> > diff --git a/qapi/ui.json b/qapi/ui.json
> > index 5d01ad4304..c8005867e5 100644
> > --- a/qapi/ui.json
> > +++ b/qapi/ui.json
> > @@ -1019,6 +1019,25 @@
> > { 'struct' : 'DisplayGTK',
> >'data': { '*grab-on-hover' : 'bool' } }
> >
> > + ##
> > + # @DisplayGLMode:
> > + #
> > + # Display OpenGL mode.
> > + #
> > + # 'off' Disable OpenGL (default).
>
> Wrong format; this should be:
>
> # @off: Disable OpenGL (default).
Fix locally
>
> > + # 'on'Use OpenGL, pick context type automatically.
> > + # Would better be named 'auto' but is called 'on' for backward
> > + # compatibility with bool type.
>
> See below...
>
> > + # 'core' Use OpenGL with Core (desktop) Context.
> > + # 'es'Use OpenGL with ES (embedded systems) Context.
> > + #
> > + # Since: 2.13
> > + #
> > + ##
> > + { 'enum': 'DisplayGLMode',
> > + 'data': [ 'off', 'on', 'core', 'es' ] }
> > +
> > +
> > ##
> > # @DisplayType:
> > #
> > @@ -1048,7 +1067,7 @@
> >'base': { 'type' : 'DisplayType',
> > '*full-screen' : 'bool',
> > '*window-close' : 'bool',
> > -'*gl': 'bool' },
> > +'*gl': 'DisplayGLMode' },
>
> DisplayOptions was added in 2.12. This is a backwards-incompatible
> change in QMP (you CANNOT change 'bool' to 'DisplayGLMode' across
> releases, because the on-the-wire representation differs; pre-patch it
> would be "gl":true, post-patch it is "gl":"on"). So if it affects QMP,
> and we want it, this patch either HAS to go in 2.12, or we have to have
> more finesse (perhaps by using an 'alternate' type in the QAPI) so that
> it remains backwards-compatible.
>
> /me goes and looks at introspection output...
>
> You may be in luck - there is no instance of 'window-close' in the
> introspection output, which means 'DisplayType' exists only for ease of
> command-line parsing and is not currently used by QMP, so tweaks here
> are not affecting the command line.
>
> That said, you can STILL name the enum value something smarter than 'on'
> IF you make the change now, for 2.12, given that the QAPI type was only
> introduced in 2.12 (you only have to worry about backwards compatibility
> if 2.11 already parsed gl=on).
It sounds like making the change now is the best option.
So, is 'auto' a better choice than 'on' in the enum?
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc. +1-919-301-3266
> Virtualization: qemu.org | libvirt.org
>
Re: [Qemu-devel] [PATCH v2 00/17] Translation loop conversion for sh4/sparc/mips/s390x/openrisc/riscv targets
On 04/10/2018 03:40 PM, Emilio G. Cota wrote: > On Tue, Apr 10, 2018 at 15:16:19 +0200, Bastian Koppelmann wrote: >> On 04/10/2018 03:03 PM, Emilio G. Cota wrote: >>> On Tue, Apr 10, 2018 at 14:24:23 +1000, Richard Henderson wrote: On 04/10/2018 02:11 AM, Emilio G. Cota wrote: > On Mon, Apr 09, 2018 at 16:01:36 +0200, Bastian Koppelmann wrote: >> Thanks for doing this grunt work. Me and a colleague were planning to do >> this as well after converting the RISC-V frontend to decodetree. Do you >> have any plans to do this for the TriCore frontend as well? I have the >> same plan for Tricore: Convert it to decodetree, then to translation >> loop. > > I won't do any further conversions in the near future, so please go > ahead with your plans :-) In which case I won't review Emilio's final two patches for risc-v. >> >> I'm confused as well :). I don't understand why Richard is not reviewing >> the last two patch. Maybe you can clarify as well, Richard. > > I think he understood you already had patches (not yet on-list) to do the > trloop conversion for riscv, and therefore my patches should be discarded. No, I don't have patches. > [...] > > Note that the first patch in this series does change the TranslatorOps > interface, that's why I think the whole series should go > through the same tree (Richard's TCG tree, I presume). Works for me. Cheers, Bastian
[Qemu-devel] [PATCH for-2.12] hw/char/cmsdk-apb-uart.c: Correctly clear INTSTATUS bits on writes
The CMSDK APB UART INTSTATUS register bits are all write-one-to-clear. We were getting this correct for the TXO and RXO bits (which need special casing because their state lives in the STATE register), but had forgotten to handle the normal bits for RX and TX which we do store in our s->intstatus field. Perform the W1C operation on the bits in s->intstatus too. Fixes: https://bugs.launchpad.net/qemu/+bug/1760262 Cc: qemu-sta...@nongnu.org Signed-off-by: Peter Maydell --- Not a disaster if this doesn't get into 2.12, I guess. I think it's missed the rc3 boat, so if we need an rc4 for some other reason we can put it in. hw/char/cmsdk-apb-uart.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/char/cmsdk-apb-uart.c b/hw/char/cmsdk-apb-uart.c index 1ad1e14295..9c0929d8a2 100644 --- a/hw/char/cmsdk-apb-uart.c +++ b/hw/char/cmsdk-apb-uart.c @@ -274,6 +274,7 @@ static void uart_write(void *opaque, hwaddr offset, uint64_t value, * is then reflected into the intstatus value by the update function). */ s->state &= ~(value & (R_INTSTATUS_TXO_MASK | R_INTSTATUS_RXO_MASK)); +s->intstatus &= ~value; cmsdk_apb_uart_update(s); break; case A_BAUDDIV: -- 2.16.2
Re: [Qemu-devel] [PATCH v2 00/17] Translation loop conversion for sh4/sparc/mips/s390x/openrisc/riscv targets
On Tue, Apr 10, 2018 at 15:16:19 +0200, Bastian Koppelmann wrote: > On 04/10/2018 03:03 PM, Emilio G. Cota wrote: > > On Tue, Apr 10, 2018 at 14:24:23 +1000, Richard Henderson wrote: > >> On 04/10/2018 02:11 AM, Emilio G. Cota wrote: > >>> On Mon, Apr 09, 2018 at 16:01:36 +0200, Bastian Koppelmann wrote: > Thanks for doing this grunt work. Me and a colleague were planning to do > this as well after converting the RISC-V frontend to decodetree. Do you > have any plans to do this for the TriCore frontend as well? I have the > same plan for Tricore: Convert it to decodetree, then to translation > loop. > >>> > >>> I won't do any further conversions in the near future, so please go > >>> ahead with your plans :-) > >> > >> In which case I won't review Emilio's final two patches for risc-v. > > I'm confused as well :). I don't understand why Richard is not reviewing > the last two patch. Maybe you can clarify as well, Richard. I think he understood you already had patches (not yet on-list) to do the trloop conversion for riscv, and therefore my patches should be discarded. > > I might be mistaken but my impression is that Bastian would be happy taking > > these risc-v patches (w/ a minor correction, already noted) since he > > has not yet started the TranslatorOps conversion he planned. > > > > Bastian, can you please clarify? > > Sure, I can take the three RISC-V patches into my tree and send a pull > as soon as the next development cycle start. Note that the first patch in this series does change the TranslatorOps interface, that's why I think the whole series should go through the same tree (Richard's TCG tree, I presume). Thanks, E.
Re: [Qemu-devel] [PATCH 1/2] qemu-thread: always keep the posix wrapper layer
On 04/10/2018 07:49 AM, Peter Xu wrote:
> We will conditionally have a wrapper layer depending on whether the host
> has the PTHREAD_SETNAME capability. It complicates stuff. Let's just
> keep the wrapper there, meanwhile we opt out the pthread_setname_np()
> call only. The layer can be helpful in future patches to pass data from
> the parent thread to the child thread.
>
> Signed-off-by: Peter Xu
> ---
> util/qemu-thread-posix.c | 33 +
> 1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
> index b789cf32e9..3ae96210d6 100644
> --- a/util/qemu-thread-posix.c
> +++ b/util/qemu-thread-posix.c
> @@ -482,7 +482,6 @@ static void __attribute__((constructor))
> qemu_thread_atexit_init(void)
> }
>
More context:
static bool name_threads;
void qemu_thread_naming(bool enable)
{
name_threads = enable;
#ifndef CONFIG_THREAD_SETNAME_BYTHREAD
/* This is a debugging option, not fatal */
if (enable) {
fprintf(stderr, "qemu: thread naming not supported on this host\n");
}
#endif
}
>
> -#ifdef CONFIG_PTHREAD_SETNAME_NP
Why are we using CONFIG_THREAD_SETNAME_BYTHREAD in one place, and
CONFIG_PTHREAD_SETNAME_NP in another?
/me checks configure - oh:
# Hold two types of flag:
# CONFIG_THREAD_SETNAME_BYTHREAD - we've got a way of setting the name on
# a thread we have a handle to
# CONFIG_PTHREAD_SETNAME_NP - A way of doing it on a particular
# platform
even though, right now, we only either set both flags at once or leave
both clear, since we don't (yet?) have any other platform-specific ways
to do it.
> typedef struct {
> void *(*start_routine)(void *);
> void *arg;
> @@ -498,13 +497,15 @@ static void *qemu_thread_start(void *args)
> /* Attempt to set the threads name; note that this is for debug, so
> * we're not going to fail if we can't set it.
> */
> -pthread_setname_np(pthread_self(), qemu_thread_args->name);
> +#ifdef CONFIG_PTHREAD_SETNAME_NP
> +if (qemu_thread_args->name) {
> +pthread_setname_np(pthread_self(), qemu_thread_args->name);
Post-patch, this (attempts to) set the thread name if a non-NULL name is
present...
>
> -#ifdef CONFIG_PTHREAD_SETNAME_NP
> -if (name_threads) {
> -QemuThreadArgs *qemu_thread_args;
> -qemu_thread_args = g_new0(QemuThreadArgs, 1);
> -qemu_thread_args->name = g_strdup(name);
...but pre-patch, qemu_thread_args->name was left NULL unless
name_threads was true, because someone had called
qemu_thread_naming(true)...
> -qemu_thread_args->start_routine = start_routine;
> -qemu_thread_args->arg = arg;
> -
> -err = pthread_create(&thread->thread, &attr,
> - qemu_thread_start, qemu_thread_args);
> -} else
> -#endif
> -{
> -err = pthread_create(&thread->thread, &attr,
> - start_routine, arg);
> -}
> +qemu_thread_args = g_new0(QemuThreadArgs, 1);
> +qemu_thread_args->name = g_strdup(name);
...so you have changed semantics - you are now unconditionally trying to
set the thread name, instead of honoring qemu_thread_naming(). Do we
still need qemu_thread_naming() (tied to opt debug-threads)?
You need to either fix your code to remain conditional on whether
name_threads is set, or document the semantic change as intentional in
the commit message.
However, the idea for refactoring to always use the shim makes sense.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 1/2 for-2.12?] qapi: Parameter gl of DisplayType now accept an enum
> # @off: Disable OpenGL (default). > > > + # 'on'Use OpenGL, pick context type automatically. > > + # Would better be named 'auto' but is called 'on' for backward > > + # compatibility with bool type. > > See below... > DisplayOptions was added in 2.12. This is a backwards-incompatible > change in QMP (you CANNOT change 'bool' to 'DisplayGLMode' across > releases, because the on-the-wire representation differs; pre-patch it > would be "gl":true, post-patch it is "gl":"on"). So if it affects QMP, > and we want it, this patch either HAS to go in 2.12, or we have to have > more finesse (perhaps by using an 'alternate' type in the QAPI) so that > it remains backwards-compatible. > > /me goes and looks at introspection output... > > You may be in luck - there is no instance of 'window-close' in the > introspection output, which means 'DisplayType' exists only for ease of > command-line parsing and is not currently used by QMP, so tweaks here > are not affecting the command line. Yes, right now the struct is only used to store the parsed command line opts, so no effect on QMP. Plan for the future is to also parse command line options with generic qapi/json code instead of the home-grown parser, but that switch didn't happen yet. > That said, you can STILL name the enum value something smarter than 'on' > IF you make the change now, for 2.12, given that the QAPI type was only > introduced in 2.12 (you only have to worry about backwards compatibility > if 2.11 already parsed gl=on). gl=on is older, so that must continue to work. Making both "on" and "auto" work isn't a problem for our home-grown parser (aka parse_display() in vl.c). But having quirks like this makes the switch to generic parser code more difficuilt, so I'd prefer to avoid that ... cheers, Gerd
[Qemu-devel] [Bug 1761027] Re: Unexpected error: "AioContext polling is not implemented on Windows"
** Summary changed: - Unexpected error + Unexpected error: "AioContext polling is not implemented on Windows" -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1761027 Title: Unexpected error: "AioContext polling is not implemented on Windows" Status in QEMU: Fix Committed Bug description: When run it this error happens: Unexpected error in aio_context_set_poll_params() at /home/stefan/src/qemu/repo.or.cz/qemu/ar7/util/aio-win32.c:413: C:\Program Files\qemu\qemu-system-x86_64.exe: AioContext polling is not implemented on Windows This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. System: Windows 10 x64 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1761027/+subscriptions
[Qemu-devel] [PULL 1/3] iotests: fix wait_until_completed()
From: Peter Xu If there are more than one events, wait_until_completed() might return the 2nd event even if the 1st event is JOB_COMPLETED, since the for loop will continue to run even if completed is set to True. It never happened before, but it can be triggered when OOB is enabled due to the RESUME startup message. Fix that up. Signed-off-by: Peter Xu Message-Id: <20180408030542.17855-1-pet...@redhat.com> Reviewed-by: Fam Zheng Reviewed-by: Stefan Hajnoczi Signed-off-by: Eric Blake --- tests/qemu-iotests/iotests.py | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py index b5d7945af88..119c8e270a5 100644 --- a/tests/qemu-iotests/iotests.py +++ b/tests/qemu-iotests/iotests.py @@ -470,18 +470,15 @@ class QMPTestCase(unittest.TestCase): def wait_until_completed(self, drive='drive0', check_offset=True): '''Wait for a block job to finish, returning the event''' -completed = False -while not completed: +while True: for event in self.vm.get_qmp_events(wait=True): if event['event'] == 'BLOCK_JOB_COMPLETED': self.assert_qmp(event, 'data/device', drive) self.assert_qmp_absent(event, 'data/error') if check_offset: self.assert_qmp(event, 'data/offset', event['data']['len']) -completed = True - -self.assert_no_active_block_jobs() -return event +self.assert_no_active_block_jobs() +return event def wait_ready(self, drive='drive0'): '''Wait until a block job BLOCK_JOB_READY event''' -- 2.14.3
[Qemu-devel] [PULL 0/3] QAPI patches for 2018-04-10, 2.12-rc3
The following changes since commit fb4fe32d5b6290deabe752b51cc1cc2a9e8573db: Merge remote-tracking branch 'remotes/xtensa/tags/20180409-xtensa' into staging (2018-04-10 10:22:45 +0100) are available in the Git repository at: git://repo.or.cz/qemu/ericb.git tags/pull-qapi-2018-04-10 for you to fetch changes up to 951702f39c7e31530ce4ea65b11fe25ea1ea9c37: monitor: bind dispatch bh to iohandler context (2018-04-10 07:49:43 -0500) Hopefully the last of the fixes for regressions caused by OOB which could be observed even when x-oob=on is not used. qapi patches for 2018-04-10 - Peter Xu: iotests: fix wait_until_completed() - Peter Xu: iothread: workaround glib bug which hangs qmp-test - Peter Xu: monitor: bind dispatch bh to iohandler context Peter Xu (3): iotests: fix wait_until_completed() iothread: workaround glib bug which hangs qmp-test monitor: bind dispatch bh to iohandler context iothread.c| 18 ++ monitor.c | 2 +- tests/qemu-iotests/iotests.py | 9 +++-- 3 files changed, 18 insertions(+), 11 deletions(-) -- 2.14.3
[Qemu-devel] [PULL 3/3] monitor: bind dispatch bh to iohandler context
From: Peter Xu Eric Auger reported the problem days ago that OOB broke ARM when running with libvirt: http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06231.html The problem was that the monitor dispatcher bottom half was bound to qemu_aio_context now, which could be polled unexpectedly in block code. We should keep the dispatchers run in iohandler_ctx just like what we did before the Out-Of-Band series (chardev uses qio, and qio binds everything with iohandler_ctx). If without this change, QMP dispatcher might be run even before reaching main loop in block IO path, for example, in a stack like (the ARM case, "cont" command handler run even during machine init phase): #0 qmp_cont () #1 0x006bd210 in qmp_marshal_cont () #2 0x00ac05c4 in do_qmp_dispatch () #3 0x00ac07a0 in qmp_dispatch () #4 0x00472d60 in monitor_qmp_dispatch_one () #5 0x0047302c in monitor_qmp_bh_dispatcher () #6 0x00acf374 in aio_bh_call () #7 0x00acf428 in aio_bh_poll () #8 0x00ad5110 in aio_poll () #9 0x00a08ab8 in blk_prw () #10 0x00a091c4 in blk_pread () #11 0x00734f94 in pflash_cfi01_realize () #12 0x0075a3a4 in device_set_realized () #13 0x009a26cc in property_set_bool () #14 0x009a0a40 in object_property_set () #15 0x009a3a08 in object_property_set_qobject () #16 0x009a0c8c in object_property_set_bool () #17 0x00758f94 in qdev_init_nofail () #18 0x0058e190 in create_one_flash () #19 0x0058e2f4 in create_flash () #20 0x005902f0 in machvirt_init () #21 0x007635cc in machine_run_board_init () #22 0x006b135c in main () Actually the problem is more severe than that. After we switched to the qemu AIO handler it means the monitor dispatcher code can even be called with nested aio_poll(), then it can be an explicit aio_poll() inside another main loop aio_poll() which could be racy too; breaking code like TPM and 9p that use nested event loops. Switch to use the iohandler_ctx for monitor dispatchers. My sincere thanks to Eric Auger who offered great help during both debugging and verifying the problem. The ARM test was carried out by applying this patch upon QEMU 2.12.0-rc0 and problem is gone after the patch. A quick test of mine shows that after this patch applied we can pass all raw iotests even with OOB on by default. CC: Eric Blake CC: Markus Armbruster CC: Stefan Hajnoczi CC: Fam Zheng Reported-by: Eric Auger Tested-by: Eric Auger Signed-off-by: Peter Xu Message-Id: <20180410044942.17059-1-pet...@redhat.com> Reviewed-by: Eric Blake Reviewed-by: Stefan Hajnoczi Signed-off-by: Eric Blake --- monitor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/monitor.c b/monitor.c index 51f4cf480f8..39f8ee17ba7 100644 --- a/monitor.c +++ b/monitor.c @@ -4467,7 +4467,7 @@ static void monitor_iothread_init(void) * have assumption to be run on main loop thread. It would be * nice that one day we can remove this assumption in the future. */ -mon_global.qmp_dispatcher_bh = aio_bh_new(qemu_get_aio_context(), +mon_global.qmp_dispatcher_bh = aio_bh_new(iohandler_get_aio_context(), monitor_qmp_bh_dispatcher, NULL); -- 2.14.3
[Qemu-devel] [PULL 2/3] iothread: workaround glib bug which hangs qmp-test
From: Peter Xu
Free the AIO context earlier than the GMainContext (if we have) to
workaround a glib2 bug that GSource context pointer is not cleared even
if the context has already been destroyed (while it should).
The patch itself only changed the order to destroy the objects, no
functional change at all. Without this workaround, we can encounter
qmp-test hang with oob (and possibly any other use case when iothread is
used with GMainContexts):
#0 0x7f35ffe45334 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x7f35ffe405d8 in _L_lock_854 () from /lib64/libpthread.so.0
#2 0x7f35ffe404a7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x7f35fc5b9c9d in g_source_unref_internal (source=0x24f0600,
context=0x7f35f960, have_lock=0) at gmain.c:1685
#4 0x00aa6672 in aio_context_unref (ctx=0x24f0600) at
/root/qemu/util/async.c:497
#5 0x0065851c in iothread_instance_finalize (obj=0x24f0380) at
/root/qemu/iothread.c:129
#6 0x00962d79 in object_deinit (obj=0x24f0380, type=0x242e960) at
/root/qemu/qom/object.c:462
#7 0x00962e0d in object_finalize (data=0x24f0380) at
/root/qemu/qom/object.c:476
#8 0x00964146 in object_unref (obj=0x24f0380) at
/root/qemu/qom/object.c:924
#9 0x00965880 in object_finalize_child_property (obj=0x24ec640,
name=0x24efca0 "mon_iothread", opaque=0x24f0380) at /root/qemu/qom/object.c:1436
#10 0x00962c33 in object_property_del_child (obj=0x24ec640,
child=0x24f0380, errp=0x0) at /root/qemu/qom/object.c:436
#11 0x00962d26 in object_unparent (obj=0x24f0380) at
/root/qemu/qom/object.c:455
#12 0x00658f00 in iothread_destroy (iothread=0x24f0380) at
/root/qemu/iothread.c:365
#13 0x004c67a8 in monitor_cleanup () at /root/qemu/monitor.c:4663
#14 0x00669e27 in main (argc=16, argv=0x7ffc8b1ae2f8,
envp=0x7ffc8b1ae380) at /root/qemu/vl.c:4749
The glib2 bug is fixed in commit 26056558b ("gmain: allow
g_source_get_context() on destroyed sources", 2012-07-30), so the first
good version is glib2 2.33.10. But we still support building with
glib as old as 2.28, so we need the workaround.
Let's make sure we destroy the GSources first before its owner context
until we drop support for glib older than 2.33.10.
Signed-off-by: Peter Xu
Message-Id: <20180409083956.1780-1-pet...@redhat.com>
Reviewed-by: Eric Blake
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Eric Blake
---
iothread.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/iothread.c b/iothread.c
index e675c384422..aff12812576 100644
--- a/iothread.c
+++ b/iothread.c
@@ -117,16 +117,26 @@ static void iothread_instance_finalize(Object *obj)
IOThread *iothread = IOTHREAD(obj);
iothread_stop(iothread);
+/*
+ * Before glib2 2.33.10, there is a glib2 bug that GSource context
+ * pointer may not be cleared even if the context has already been
+ * destroyed (while it should). Here let's free the AIO context
+ * earlier to bypass that glib bug.
+ *
+ * We can remove this comment after the minimum supported glib2
+ * version boosts to 2.33.10. Before that, let's free the
+ * GSources first before destroying any GMainContext.
+ */
+if (iothread->ctx) {
+aio_context_unref(iothread->ctx);
+iothread->ctx = NULL;
+}
if (iothread->worker_context) {
g_main_context_unref(iothread->worker_context);
iothread->worker_context = NULL;
}
qemu_cond_destroy(&iothread->init_done_cond);
qemu_mutex_destroy(&iothread->init_done_lock);
-if (!iothread->ctx) {
-return;
-}
-aio_context_unref(iothread->ctx);
}
static void iothread_complete(UserCreatable *obj, Error **errp)
--
2.14.3
Re: [Qemu-devel] [PATCH v3 3/7] s390x/cpumodel: Set up CPU model for AP device support
On 04/06/2018 10:51 AM, Pierre Morel wrote:
On 16/03/2018 00:24, Tony Krowiak wrote:
A new CPU model feature and two new CPU model facilities are
introduced to support AP devices for a KVM guest.
CPU model features:
1. The KVM_S390_VM_CPU_FEAT_AP CPU model feature indicates that
AP facilities are installed. This feature will be enabled by
the kernel only if the AP facilities are installed on the linux
host. This feature must be turned on from userspace to access
AP devices from the KVM guest. The QEMU command line to turn
this feature looks something like this:
qemu-system-s390x ... -cpu xxx,ap=on
CPU model facilities:
1. The S390_FEAT_AP_QUERY_CONFIG_INFO feature indicates the AP Query
Configuration Information (QCI) facility is installed. This feature
will be enabled by the kernel only if the QCI is installed on
the host.
2. The S390_FEAT_AP_FACILITY_TEST feature indicates that the AP
Facility Test (APFT) facility is installed. This feature will
be enabled by the kernel only if the APFT facility is installed
on the host.
Signed-off-by: Tony Krowiak
---
target/s390x/cpu_features.c |3 +++
target/s390x/cpu_features_def.h |3 +++
target/s390x/cpu_models.c |2 ++
target/s390x/gen-features.c |3 +++
target/s390x/kvm.c |1 +
5 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index a5619f2..1abe987 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -36,8 +36,10 @@ static const S390FeatDef s390_features[] = {
FEAT_INIT("srs", S390_FEAT_TYPE_STFL, 9, "Sense-running-status
facility"),
FEAT_INIT("csske", S390_FEAT_TYPE_STFL, 10, "Conditional-SSKE
facility"),
FEAT_INIT("ctop", S390_FEAT_TYPE_STFL, 11,
"Configuration-topology facility"),
+FEAT_INIT("qci", S390_FEAT_TYPE_STFL, 12, "Query AP
Configuration facility"),
FEAT_INIT("ipter", S390_FEAT_TYPE_STFL, 13, "IPTE-range
facility"),
FEAT_INIT("nonqks", S390_FEAT_TYPE_STFL, 14, "Nonquiescing
key-setting facility"),
+FEAT_INIT("apft", S390_FEAT_TYPE_STFL, 15, "Adjunct Processor
Facilities Test facility"),
FEAT_INIT("etf2", S390_FEAT_TYPE_STFL, 16,
"Extended-translation facility 2"),
FEAT_INIT("msa-base", S390_FEAT_TYPE_STFL, 17,
"Message-security-assist facility (excluding subfunctions)"),
FEAT_INIT("ldisp", S390_FEAT_TYPE_STFL, 18, "Long-displacement
facility"),
@@ -125,6 +127,7 @@ static const S390FeatDef s390_features[] = {
FEAT_INIT("dateh2", S390_FEAT_TYPE_MISC, 0, "DAT-enhancement
facility 2"),
FEAT_INIT("cmm", S390_FEAT_TYPE_MISC, 0,
"Collaborative-memory-management facility"),
+FEAT_INIT("ap", S390_FEAT_TYPE_MISC, 0, "AP facilities installed"),
FEAT_INIT("plo-cl", S390_FEAT_TYPE_PLO, 0, "PLO Compare and
load (32 bit in general registers)"),
FEAT_INIT("plo-clg", S390_FEAT_TYPE_PLO, 1, "PLO Compare and
load (64 bit in parameter list)"),
diff --git a/target/s390x/cpu_features_def.h
b/target/s390x/cpu_features_def.h
index 7c5915c..8998b65 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -27,8 +27,10 @@ typedef enum {
S390_FEAT_SENSE_RUNNING_STATUS,
S390_FEAT_CONDITIONAL_SSKE,
S390_FEAT_CONFIGURATION_TOPOLOGY,
+S390_FEAT_AP_QUERY_CONFIG_INFO,
S390_FEAT_IPTE_RANGE,
S390_FEAT_NONQ_KEY_SETTING,
+S390_FEAT_AP_FACILITIES_TEST,
S390_FEAT_EXTENDED_TRANSLATION_2,
S390_FEAT_MSA,
S390_FEAT_LONG_DISPLACEMENT,
@@ -118,6 +120,7 @@ typedef enum {
/* Misc */
S390_FEAT_DAT_ENH_2,
S390_FEAT_CMM,
+S390_FEAT_AP,
/* PLO */
S390_FEAT_PLO_CL,
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index cf82589..7e2af09 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -769,6 +769,8 @@ static void check_consistency(const S390CPUModel
*model)
{ S390_FEAT_PRNO_TRNG_QRTCR, S390_FEAT_MSA_EXT_5 },
{ S390_FEAT_PRNO_TRNG, S390_FEAT_MSA_EXT_5 },
{ S390_FEAT_SIE_KSS, S390_FEAT_SIE_F2 },
+{ S390_FEAT_AP_QUERY_CONFIG_INFO, S390_FEAT_AP },
+{ S390_FEAT_AP_FACILITIES_TEST, S390_FEAT_AP },
};
int i;
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 0cdbc15..0d5b0f7 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -447,6 +447,9 @@ static uint16_t full_GEN12_GA1[] = {
S390_FEAT_ADAPTER_INT_SUPPRESSION,
S390_FEAT_EDAT_2,
S390_FEAT_SIDE_EFFECT_ACCESS_ESOP2,
+S390_FEAT_AP_QUERY_CONFIG_INFO,
Placing QCI feature in the full feature for z13 has for effect that:
1) it must be on the qemu command line.
Do we really want this?
QCI is always available when AP is available in the real hardware
before z13.
Are you suggesting we always set STFLE.12 for the guest whenever
AP is available and get rid of this
Re: [Qemu-devel] [PATCH v2 00/17] Translation loop conversion for sh4/sparc/mips/s390x/openrisc/riscv targets
On 04/10/2018 03:03 PM, Emilio G. Cota wrote: > On Tue, Apr 10, 2018 at 14:24:23 +1000, Richard Henderson wrote: >> On 04/10/2018 02:11 AM, Emilio G. Cota wrote: >>> On Mon, Apr 09, 2018 at 16:01:36 +0200, Bastian Koppelmann wrote: Thanks for doing this grunt work. Me and a colleague were planning to do this as well after converting the RISC-V frontend to decodetree. Do you have any plans to do this for the TriCore frontend as well? I have the same plan for Tricore: Convert it to decodetree, then to translation loop. >>> >>> I won't do any further conversions in the near future, so please go >>> ahead with your plans :-) >> >> In which case I won't review Emilio's final two patches for risc-v. I'm confused as well :). I don't understand why Richard is not reviewing the last two patch. Maybe you can clarify as well, Richard. > > I might be mistaken but my impression is that Bastian would be happy taking > these risc-v patches (w/ a minor correction, already noted) since he > has not yet started the TranslatorOps conversion he planned. > > Bastian, can you please clarify? Sure, I can take the three RISC-V patches into my tree and send a pull as soon as the next development cycle start. Cheers, Bastian
[Qemu-devel] [PATCH] timer: fix record/replay timerlist probe
Ciro Santilli reported that commit a5ed352596a8b7eb2f9acce34371b944ac3056c4
breaks the execution replay. It happens due to the probing the clock
for the new instances of iothread. Probing of the timerlists' clock
instead of using them for the deadlines calculation is critical for the replay.
However, this probing was made for the timer lists that are empty.
In record mode such lists are not used for the deadlines and corresponding
clock does not queried.
Therefore this patch disables quering the clock for the empty timerlists
and disabled clocks.
Signed-off-by: Pavel Dovgalyuk
---
util/qemu-timer.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/util/qemu-timer.c b/util/qemu-timer.c
index 2ed1bf2..e1c703c 100644
--- a/util/qemu-timer.c
+++ b/util/qemu-timer.c
@@ -587,7 +587,10 @@ int64_t timerlistgroup_deadline_ns(QEMUTimerListGroup *tlg)
} else {
/* Read clock from the replay file and
do not calculate the deadline, based on virtual clock. */
-qemu_clock_get_ns(type);
+if (atomic_read(&tlg->tl[type]->active_timers)
+&& tlg->tl[type]->clock->enabled) {
+qemu_clock_get_ns(type);
+}
}
}
}
Re: [Qemu-devel] [PATCH v2 1/2 for-2.12?] qapi: Parameter gl of DisplayType now accept an enum
On 04/10/2018 07:02 AM, Elie Tournier wrote:
> Signed-off-by: Elie Tournier
> ---
> qapi/ui.json | 21 -
> vl.c | 10 +-
> 2 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/qapi/ui.json b/qapi/ui.json
> index 5d01ad4304..c8005867e5 100644
> --- a/qapi/ui.json
> +++ b/qapi/ui.json
> @@ -1019,6 +1019,25 @@
> { 'struct' : 'DisplayGTK',
>'data': { '*grab-on-hover' : 'bool' } }
>
> + ##
> + # @DisplayGLMode:
> + #
> + # Display OpenGL mode.
> + #
> + # 'off' Disable OpenGL (default).
Wrong format; this should be:
# @off: Disable OpenGL (default).
> + # 'on'Use OpenGL, pick context type automatically.
> + # Would better be named 'auto' but is called 'on' for backward
> + # compatibility with bool type.
See below...
> + # 'core' Use OpenGL with Core (desktop) Context.
> + # 'es'Use OpenGL with ES (embedded systems) Context.
> + #
> + # Since: 2.13
> + #
> + ##
> + { 'enum': 'DisplayGLMode',
> + 'data': [ 'off', 'on', 'core', 'es' ] }
> +
> +
> ##
> # @DisplayType:
> #
> @@ -1048,7 +1067,7 @@
>'base': { 'type' : 'DisplayType',
> '*full-screen' : 'bool',
> '*window-close' : 'bool',
> -'*gl': 'bool' },
> +'*gl': 'DisplayGLMode' },
DisplayOptions was added in 2.12. This is a backwards-incompatible
change in QMP (you CANNOT change 'bool' to 'DisplayGLMode' across
releases, because the on-the-wire representation differs; pre-patch it
would be "gl":true, post-patch it is "gl":"on"). So if it affects QMP,
and we want it, this patch either HAS to go in 2.12, or we have to have
more finesse (perhaps by using an 'alternate' type in the QAPI) so that
it remains backwards-compatible.
/me goes and looks at introspection output...
You may be in luck - there is no instance of 'window-close' in the
introspection output, which means 'DisplayType' exists only for ease of
command-line parsing and is not currently used by QMP, so tweaks here
are not affecting the command line.
That said, you can STILL name the enum value something smarter than 'on'
IF you make the change now, for 2.12, given that the QAPI type was only
introduced in 2.12 (you only have to worry about backwards compatibility
if 2.11 already parsed gl=on).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PULL 0/6] Net patches
On 10 April 2018 at 04:39, Jason Wang wrote: > The following changes since commit 915d34c5f99b0ab91517c69f54272bfdb6ca2b32: > > Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into > staging (2018-04-09 17:29:10 +0100) > > are available in the git repository at: > > https://github.com/jasowang/qemu.git tags/net-pull-request > > for you to fetch changes up to 5f523530915e57a14ffb8c00e22252bfa557441c: > > e1000: Old machine types, turn new subsection off (2018-04-10 11:30:04 > +0800) > > > > A series from David that switches to use subsection instead of version > bumping for e1000 to keep migration compatibility for old > versions. This will ease the downstream maintaining. > > Please merge. > > Thanks > > > Dr. David Alan Gilbert (6): > e1000: Convert v3 fields to subsection > e1000: Dupe offload data on reading old stream > e1000: wire new subsection to property > e1000: Migrate props via a temporary structure > e1000: Choose which set of props to migrate > e1000: Old machine types, turn new subsection off > > hw/net/e1000.c | 103 > > include/hw/compat.h | 4 ++ > 2 files changed, 84 insertions(+), 23 deletions(-) Applied, thanks. -- PMM
Re: [Qemu-devel] [PATCH for-2.12] fpu: Fix rounding mode for floatN_to_uintM_round_to_zero
Richard Henderson writes:
> We incorrectly passed in the current rounding mode
> instead of float_round_to_zero.
>
> Signed-off-by: Richard Henderson
Oops,
Reviewed-by: Alex Bennée
> ---
>
> Found while runnning SVE RISU tests; it should be visible with the
> right set of inputs to AdvSIMD RISU tests.
>
>
> r~
>
> ---
> fpu/softfloat.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fpu/softfloat.c b/fpu/softfloat.c
> index 6e16284e66..b46dccc63e 100644
> --- a/fpu/softfloat.c
> +++ b/fpu/softfloat.c
> @@ -1486,8 +1486,8 @@ uint ## isz ## _t float ## fsz ## _to_uint ## isz ##
> _round_to_zero \
> (float ## fsz a, float_status *s) \
> { \
> FloatParts p = float ## fsz ## _unpack_canonical(a, s); \
> -return round_to_uint_and_pack(p, s->float_rounding_mode,\
> - UINT ## isz ## _MAX, s); \
> +return round_to_uint_and_pack(p, float_round_to_zero, \
> + UINT ## isz ## _MAX, s); \
> }
>
> FLOAT_TO_UINT(16, 16)
--
Alex Bennée
[Qemu-devel] [PULL 5/7] tests/boot-serial: Test the sam460ex board
From: Thomas Huth
We've got a U-Boot firmware for this board in our repository, and
the firmware prints some output to the serial console, so we can
check this board in the boot-serial tester, too.
Signed-off-by: Thomas Huth
Signed-off-by: David Gibson
---
tests/boot-serial-test.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tests/boot-serial-test.c b/tests/boot-serial-test.c
index 5b24cd26c1..011525d8cf 100644
--- a/tests/boot-serial-test.c
+++ b/tests/boot-serial-test.c
@@ -79,12 +79,14 @@ static testdef_t tests[] = {
{ "ppc", "40p", "-boot d", "Booting from device d" },
{ "ppc", "g3beige", "", "PowerPC,750" },
{ "ppc", "mac99", "", "PowerPC,G4" },
+{ "ppc", "sam460ex", "-m 256", "DRAM: 256 MiB" },
{ "ppc64", "ppce500", "", "U-Boot" },
{ "ppc64", "prep", "-boot e", "Booting from device e" },
{ "ppc64", "40p", "-m 192", "Memory size: 192 MB" },
{ "ppc64", "mac99", "", "PowerPC,970FX" },
{ "ppc64", "pseries", "", "Open Firmware" },
{ "ppc64", "powernv", "-cpu POWER8", "OPAL" },
+{ "ppc64", "sam460ex", "-device e1000", "8086 100e" },
{ "i386", "isapc", "-cpu qemu32 -device sga", "SGABIOS" },
{ "i386", "pc", "-device sga", "SGABIOS" },
{ "i386", "q35", "-device sga", "SGABIOS" },
--
2.14.3
Re: [Qemu-devel] [PATCH v2 00/17] Translation loop conversion for sh4/sparc/mips/s390x/openrisc/riscv targets
On Tue, Apr 10, 2018 at 14:24:23 +1000, Richard Henderson wrote: > On 04/10/2018 02:11 AM, Emilio G. Cota wrote: > > On Mon, Apr 09, 2018 at 16:01:36 +0200, Bastian Koppelmann wrote: > >> Thanks for doing this grunt work. Me and a colleague were planning to do > >> this as well after converting the RISC-V frontend to decodetree. Do you > >> have any plans to do this for the TriCore frontend as well? I have the > >> same plan for Tricore: Convert it to decodetree, then to translation loop. > > > > I won't do any further conversions in the near future, so please go > > ahead with your plans :-) > > In which case I won't review Emilio's final two patches for risc-v. I might be mistaken but my impression is that Bastian would be happy taking these risc-v patches (w/ a minor correction, already noted) since he has not yet started the TranslatorOps conversion he planned. Bastian, can you please clarify? Thanks, E.
Re: [Qemu-devel] [PATCH v2 0/2] Use SDL to create an OpenGL ES context for virglrenderer.
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180410120222.31845-1-tournier.e...@gmail.com
Subject: [Qemu-devel] [PATCH v2 0/2] Use SDL to create an OpenGL ES context for
virglrenderer.
=== TEST SCRIPT BEGIN ===
#!/bin/bash
BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
failed=1
echo
fi
n=$((n+1))
done
exit $failed
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
1e7e92e2ef..fb4fe32d5b master -> master
* [new tag]
patchew/20180410120222.31845-1-tournier.e...@gmail.com ->
patchew/20180410120222.31845-1-tournier.e...@gmail.com
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
Switched to a new branch 'test'
fa8911b71b sdl: Allow OpenGL ES context creation
6bbe6ad468 qapi: Parameter gl of DisplayType now accept an enum
=== OUTPUT BEGIN ===
Checking PATCH 1/2: qapi: Parameter gl of DisplayType now accept an enum...
Checking PATCH 2/2: sdl: Allow OpenGL ES context creation...
WARNING: line over 80 characters
#44: FILE: ui/sdl2-gl.c:143:
+if (scon->gl_mode == DISPLAYGL_MODE_ON || scon->gl_mode ==
DISPLAYGL_MODE_CORE)
ERROR: suspect code indent for conditional statements (4, 7)
#44: FILE: ui/sdl2-gl.c:143:
+if (scon->gl_mode == DISPLAYGL_MODE_ON || scon->gl_mode ==
DISPLAYGL_MODE_CORE)
+ SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK,
ERROR: suspect code indent for conditional statements (4, 7)
#47: FILE: ui/sdl2-gl.c:146:
+else if (scon->gl_mode == DISPLAYGL_MODE_ES)
+ SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK,
ERROR: suspect code indent for conditional statements (4, 7)
#58: FILE: ui/sdl2-gl.c:157:
+if (!ctx && scon->gl_mode == DISPLAYGL_MODE_ON) {
+ SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK,
total: 3 errors, 1 warnings, 59 lines checked
Your patch has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===
Test command exited with code: 1
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
[Qemu-devel] [PULL 7/7] roms/u-boot-sam460ex: Change to qemu git mirror and update
From: BALATON Zoltan Now that we have a mirror of this repo on git.qemu.org change the submodule to use that and update it to latest commit which fixes a dangling symlink and removes two big binaries that are not needed. Signed-off-by: BALATON Zoltan Signed-off-by: David Gibson --- .gitmodules | 2 +- roms/u-boot-sam460ex | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.gitmodules b/.gitmodules index c613722e3c..49e9c2e3f4 100644 --- a/.gitmodules +++ b/.gitmodules @@ -45,4 +45,4 @@ url = git://github.com/hdeller/seabios-hppa.git [submodule "roms/u-boot-sam460ex"] path = roms/u-boot-sam460ex - url = git://github.com/zbalaton/u-boot-sam460ex + url = git://git.qemu.org/u-boot-sam460ex.git diff --git a/roms/u-boot-sam460ex b/roms/u-boot-sam460ex index 119aa277f7..8ee007c421 16 --- a/roms/u-boot-sam460ex +++ b/roms/u-boot-sam460ex @@ -1 +1 @@ -Subproject commit 119aa277f74a4a2d3f7ab6c9471292308eba14e4 +Subproject commit 8ee007c4216fd6a0d760589e8405ce4494497aa0 -- 2.14.3
Re: [Qemu-devel] [PATCH v2 17/17] target/riscv: convert to TranslatorOps
On Tue, Apr 10, 2018 at 11:24:37 +1000, Richard Henderson wrote:
> On 04/07/2018 04:20 AM, Emilio G. Cota wrote:
> > +next_page = (ctx->base.pc_first & TARGET_PAGE_MASK) +
> > TARGET_PAGE_SIZE;
> > +if (ctx->base.pc_next >= next_page) {
>
> This fails for the last page of the address space.
> Better is
>
> page_start = ctx->base.pc_first & TARGET_PAGE_MASK;
> if (ctx->base.pc_next - page_start >= TARGET_PAGE_SIZE) {
Apart from the variable name change, I fail to see how this (A - B >= C)
is not equivalent to the above (A => B + C). What am I missing?
Thanks,
Emilio
[Qemu-devel] [PULL 3/7] target/ppc: Fix backwards migration of msr_mask
21b786f "PowerPC: Add TS bits into msr_mask" added the transaction states
to msr_mask for recent POWER CPUs to allow correct migration of machines
that are in certain interim transactional memory states.
This was correct, but unfortunately breaks backwards of pseries-2.7 and
earlier machine types which (stupidly) transferred the msr_mask in the
migration stream and failed if it wasn't equal on each end.
This works around the problem by masking out the new MSR bits in the
compatibility code to send the msr_mask on old machine types.
Signed-off-by: David Gibson
Reviewed-by: Greg Kurz
Tested-by: Greg Kurz
Tested-by: Lukáš Doktor
---
target/ppc/machine.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/target/ppc/machine.c b/target/ppc/machine.c
index e475206c6a..0634cdb295 100644
--- a/target/ppc/machine.c
+++ b/target/ppc/machine.c
@@ -190,7 +190,15 @@ static int cpu_pre_save(void *opaque)
/* Hacks for migration compatibility between 2.6, 2.7 & 2.8 */
if (cpu->pre_2_8_migration) {
-cpu->mig_msr_mask = env->msr_mask;
+/* Mask out bits that got added to msr_mask since the versions
+ * which stupidly included it in the migration stream. */
+target_ulong metamask = 0
+#if defined(TARGET_PPC64)
+| (1ULL << MSR_TS0)
+| (1ULL << MSR_TS1)
+#endif
+;
+cpu->mig_msr_mask = env->msr_mask & ~metamask;
cpu->mig_insns_flags = env->insns_flags & insns_compat_mask;
cpu->mig_insns_flags2 = env->insns_flags2 & insns_compat_mask2;
cpu->mig_nb_BATs = env->nb_BATs;
--
2.14.3
[Qemu-devel] [PULL 4/7] spapr: Initialize reserved areas list in FDT in H_CAS handler
From: Alexey Kardashevskiy At the moment the device tree produced by the H_CAS handler has no reserved map initialized at all which is not correct as at least one empty record is required to be present as a marker of the end. This does not cause problems now as the only consumer is SLOF which does not look at the reserved map area. However when DTC's "Improve libfdt's memory safety" changeset hits the QEMU upstream, there will be errors reported and crashes observed. This fixes the problem by adding an empty entry to the reserved map, just like create_device_tree() does already. Signed-off-by: Alexey Kardashevskiy Signed-off-by: David Gibson --- hw/ppc/spapr.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 2c0be8c898..a81570e7c8 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -865,6 +865,7 @@ int spapr_h_cas_compose_response(sPAPRMachineState *spapr, /* Create skeleton */ fdt_skel = g_malloc0(size); _FDT((fdt_create(fdt_skel, size))); +_FDT((fdt_finish_reservemap(fdt_skel))); _FDT((fdt_begin_node(fdt_skel, ""))); _FDT((fdt_end_node(fdt_skel))); _FDT((fdt_finish(fdt_skel))); -- 2.14.3
Re: [Qemu-devel] [PATCH for-2.12] commit/stream: Reset delay_ns
On 04/10/2018 03:58 AM, Kevin Wolf wrote: > Streaming and the commit block job only want to apply throttling when > they actually copied data instead of skipping it, so they made the > calculation of delay_ns conditional. However, delay_ns isn't reset when > skipping some sectors, so instead of not waiting, the old delay is > applied again. > > Properly reset delay_ns where needed. > > Signed-off-by: Kevin Wolf > --- > block/commit.c | 2 ++ > block/stream.c | 2 ++ > 2 files changed, 4 insertions(+) > Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH for-2.12] linux-user/signal.c: Ensure AArch64 signal frame isn't too small
On 9 April 2018 at 23:05, Richard Henderson wrote: > On 04/10/2018 12:07 AM, Peter Maydell wrote: >> In particular the dash shell >> would segfault if the frame wasn't as big enough. > > Ah, that was the critical difference in my failure to replicate -- the fedora > sysroot doesn't have dash. As you say, the patch matches the kernel so, > > Reviewed-by: Richard Henderson > > That said, what the hell is dash doing that relies on this? I figured out what's going on, and it's not particularly weird. The memory map at the point where we take the signal is: 40-401000 ---p 00:00 0 401000-4000801000 rw-p 00:00 0 4000801000-400081d000 r-xp 08:05 24190917 /srv/chroot/xenial-aarch64/lib/aarch64-linux-gnu/ld-2.23.so (conveniently guest_base == 0, so host and guest addresses are identical). Guest SP is 0x4000800590. Without this patch, we end up with layout.total_size == 0x480 and frame_addr == 0x4000800110. However, the range we try to lock for writing with lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0) is always sizeof struct target_rt_sigframe, which is 0x1250. So we try to lock from 0x4000800110 to 0x4000801360, which extends beyond the rw ram block and into the read-only following memory section which has ld-2.23.so in it. So this patch fixes the problem for non-SVE guests by bringing the size of the signal frame we allocate on the stack back into line with the size of the lump of memory we verify as being writable. It does suggest that there's another bug here that will only manifest if we're using SVE and end up with a larger signal frame than the default -- we will in that case do the lock_user on a lump of memory that's smaller than we're actually going to try to write to, because it won't include the extra part. Do we need to switch to using lock_user and unlock_user and passing them layout.total_size, rather than relying on the "lock size of this struct" functions? (I think this is not a bugfix required for 2.12, because nothing enables ARM_FEATURE_SVE yet, and without that feature bit we won't ever create a signal frame that's larger than sizeof(struct target_rt_sigframe).) thanks -- PMM
[Qemu-devel] [PULL 2/7] hw/misc/macio: Fix crash when listing device properties of macio device
From: Thomas Huth
The macio-newworld device can currently be used to abort QEMU unexpectedly:
$ ppc-softmmu/qemu-system-ppc -S -M ref405ep,accel=qtest -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 11, "major": 2},
"package": "build-all"}, "capabilities": []}}
{ 'execute': 'qmp_capabilities' }
{"return": {}}
{ 'execute': 'device-list-properties',
'arguments': {'typename': 'macio-newworld'}}
Unexpected error in qemu_chr_fe_init() at chardev/char-fe.c:222:
Device 'serial0' is in use
Aborted (core dumped)
qdev properties should be set during realize(), not during instance_init(),
so move the related code there to fix this problem.
Signed-off-by: Thomas Huth
Reviewed-by: Philippe Mathieu-Daudé
Acked-by: Mark Cave-Ayland
Signed-off-by: David Gibson
---
hw/misc/macio/macio.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
index 454244f59e..b74a6572b0 100644
--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -115,6 +115,13 @@ static void macio_common_realize(PCIDevice *d, Error
**errp)
memory_region_add_subregion(&s->bar, 0x16000,
sysbus_mmio_get_region(sysbus_dev, 0));
+qdev_prop_set_uint32(DEVICE(&s->escc), "disabled", 0);
+qdev_prop_set_uint32(DEVICE(&s->escc), "frequency", ESCC_CLOCK);
+qdev_prop_set_uint32(DEVICE(&s->escc), "it_shift", 4);
+qdev_prop_set_chr(DEVICE(&s->escc), "chrA", serial_hds[0]);
+qdev_prop_set_chr(DEVICE(&s->escc), "chrB", serial_hds[1]);
+qdev_prop_set_uint32(DEVICE(&s->escc), "chnBtype", escc_serial);
+qdev_prop_set_uint32(DEVICE(&s->escc), "chnAtype", escc_serial);
object_property_set_bool(OBJECT(&s->escc), true, "realized", &err);
if (err) {
error_propagate(errp, err);
@@ -341,13 +348,6 @@ static void macio_instance_init(Object *obj)
object_property_add_child(obj, "dbdma", OBJECT(&s->dbdma), NULL);
object_initialize(&s->escc, sizeof(s->escc), TYPE_ESCC);
-qdev_prop_set_uint32(DEVICE(&s->escc), "disabled", 0);
-qdev_prop_set_uint32(DEVICE(&s->escc), "frequency", ESCC_CLOCK);
-qdev_prop_set_uint32(DEVICE(&s->escc), "it_shift", 4);
-qdev_prop_set_chr(DEVICE(&s->escc), "chrA", serial_hds[0]);
-qdev_prop_set_chr(DEVICE(&s->escc), "chrB", serial_hds[1]);
-qdev_prop_set_uint32(DEVICE(&s->escc), "chnBtype", escc_serial);
-qdev_prop_set_uint32(DEVICE(&s->escc), "chnAtype", escc_serial);
qdev_set_parent_bus(DEVICE(&s->escc), sysbus_get_default());
object_property_add_child(obj, "escc", OBJECT(&s->escc), NULL);
}
--
2.14.3
[Qemu-devel] [PULL 0/7] ppc-for-2.12 queue 20180410
The following changes since commit 915d34c5f99b0ab91517c69f54272bfdb6ca2b32: Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (2018-04-09 17:29:10 +0100) are available in the Git repository at: git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180410 for you to fetch changes up to 6b3913e0858488ef3358c1683605d6894a6cadb0: roms/u-boot-sam460ex: Change to qemu git mirror and update (2018-04-10 10:05:38 +1000) ppc patch queue 2018-04-10 Here's a rather late pull request with a handful of fixes for 2.12. These have been blocked for some time, because I wasn't able to complete my usual test set due to the SCSI problem fixed in 37c5174 "scsi-disk: Don't enlarge min_io_size to max_io_size". Since we're in hard freeze, these are all bugfixes. Most are also regressions, although in one case it's only a "regression" because a longstanding bug has been exposed by a new machine type (sam460ex) in the testcases. There are also a couple of sam460ex fixes that aren't regressions since the board didn't exist before. On the flipside though, they're low risk because they only touch board specific code for a board that doesn't exist in any released version. Alexey Kardashevskiy (1): spapr: Initialize reserved areas list in FDT in H_CAS handler BALATON Zoltan (2): sam460ex: Fix timer frequency and clock multipliers roms/u-boot-sam460ex: Change to qemu git mirror and update David Gibson (2): target/ppc: Initialize lazy_tlb_flush correctly target/ppc: Fix backwards migration of msr_mask Thomas Huth (2): hw/misc/macio: Fix crash when listing device properties of macio device tests/boot-serial: Test the sam460ex board .gitmodules | 2 +- hw/misc/macio/macio.c| 14 +++--- hw/ppc/ppc440_uc.c | 3 +-- hw/ppc/sam460ex.c| 7 --- hw/ppc/spapr.c | 1 + roms/u-boot-sam460ex | 2 +- target/ppc/machine.c | 10 +- target/ppc/translate.c | 7 +++ tests/boot-serial-test.c | 2 ++ 9 files changed, 29 insertions(+), 19 deletions(-)
[Qemu-devel] [PULL 6/7] sam460ex: Fix timer frequency and clock multipliers
From: BALATON Zoltan
We only emulate timer running at CPU frequency which is what most
guests expect so set the frequency to match real hardware. This also
allows setting clock multipliers which caused slowdown previously due
to wrong timer frequency.
Signed-off-by: BALATON Zoltan
Signed-off-by: David Gibson
---
hw/ppc/ppc440_uc.c | 3 +--
hw/ppc/sam460ex.c | 7 ---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/hw/ppc/ppc440_uc.c b/hw/ppc/ppc440_uc.c
index 976ab2b5d8..e312fdba70 100644
--- a/hw/ppc/ppc440_uc.c
+++ b/hw/ppc/ppc440_uc.c
@@ -392,8 +392,7 @@ static uint32_t dcr_read_sdr(void *opaque, int dcrn)
case SDR0_CFGDATA:
switch (sdr->addr) {
case SDR0_STRP0:
-/* FIXME: Is this correct? This breaks timing in U-Boot */
-ret = 0; /*(0xb5 << 8) | (1 << 4) | 9 */
+ret = (0xb5 << 8) | (1 << 4) | 9;
break;
case SDR0_STRP1:
ret = (5 << 29) | (2 << 26) | (1 << 24);
diff --git a/hw/ppc/sam460ex.c b/hw/ppc/sam460ex.c
index 70b8e76d9c..dfff262f96 100644
--- a/hw/ppc/sam460ex.c
+++ b/hw/ppc/sam460ex.c
@@ -67,6 +67,7 @@
IRQ12 = SM502_INT
*/
+#define CPU_FREQ 115000
#define SDRAM_NR_BANKS 4
/* FIXME: See u-boot.git 8ac41e, also fix in ppc440_uc.c */
@@ -253,8 +254,8 @@ static int sam460ex_load_device_tree(hwaddr addr,
char *filename;
int fdt_size;
void *fdt;
-uint32_t tb_freq = 5000;
-uint32_t clock_freq = 5000;
+uint32_t tb_freq = CPU_FREQ;
+uint32_t clock_freq = CPU_FREQ;
filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, BINARY_DEVICE_TREE_FILE);
if (!filename) {
@@ -416,7 +417,7 @@ static void sam460ex_init(MachineState *machine)
boot_info = g_malloc0(sizeof(*boot_info));
env->load_info = boot_info;
-ppc_booke_timers_init(cpu, 5000, 0);
+ppc_booke_timers_init(cpu, CPU_FREQ, 0);
ppc_dcr_init(env, NULL, NULL);
/* PLB arbitrer */
--
2.14.3
[Qemu-devel] [PULL 1/7] target/ppc: Initialize lazy_tlb_flush correctly
ppc_tr_init_disas_context() correctly sets lazy_tlb_flush to true on certain CPU models. However, it leaves it uninitialized, instead of setting it to false on all others. It wasn't caught before now because we didn't have examples in the tests that exercised this path. However it can now be caught using clang's undefined behaviour sanitizer and the sam460ex board. Suggested-by: Peter Maydell Signed-off-by: David Gibson Reviewed-by: Thomas Huth Reviewed-by: Greg Kurz --- target/ppc/translate.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/target/ppc/translate.c b/target/ppc/translate.c index 218665b408..3457d29f8e 100644 --- a/target/ppc/translate.c +++ b/target/ppc/translate.c @@ -7237,10 +7237,9 @@ static int ppc_tr_init_disas_context(DisasContextBase *dcbase, ctx->sf_mode = msr_is_64bit(env, env->msr); ctx->has_cfar = !!(env->flags & POWERPC_FLAG_CFAR); #endif -if (env->mmu_model == POWERPC_MMU_32B || -env->mmu_model == POWERPC_MMU_601 || -(env->mmu_model & POWERPC_MMU_64B)) -ctx->lazy_tlb_flush = true; +ctx->lazy_tlb_flush = env->mmu_model == POWERPC_MMU_32B +|| env->mmu_model == POWERPC_MMU_601 +|| (env->mmu_model & POWERPC_MMU_64B); ctx->fpu_enabled = !!msr_fp; if ((env->flags & POWERPC_FLAG_SPE) && msr_spe) -- 2.14.3
[Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread
cur_mon was only used in main loop so we don't really need that to be
per-thread variable. Now it's possible that we have more than one
thread to operate on it. Let's start to let it be per-thread variable.
In case we'll create threads within a valid cur_mon setup, we'd better
let the child threads to inherit the cur_mon from parent thread too. Do
that for both posix and win32 threads.
Signed-off-by: Peter Xu
---
include/monitor/monitor.h | 2 +-
include/qemu/thread-win32.h | 1 +
monitor.c | 2 +-
stubs/monitor.c | 2 +-
tests/test-util-sockets.c | 2 +-
util/qemu-thread-posix.c| 6 ++
util/qemu-thread-win32.c| 6 ++
7 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h
index d6ab70cae2..2ef5e04b37 100644
--- a/include/monitor/monitor.h
+++ b/include/monitor/monitor.h
@@ -6,7 +6,7 @@
#include "qapi/qapi-types-misc.h"
#include "qemu/readline.h"
-extern Monitor *cur_mon;
+extern __thread Monitor *cur_mon;
/* flags for monitor_init */
/* 0x01 unused */
diff --git a/include/qemu/thread-win32.h b/include/qemu/thread-win32.h
index 3a05e3b3aa..f4d4cd96a1 100644
--- a/include/qemu/thread-win32.h
+++ b/include/qemu/thread-win32.h
@@ -39,6 +39,7 @@ typedef struct QemuThreadData QemuThreadData;
struct QemuThread {
QemuThreadData *data;
unsigned tid;
+Monitor *current_monitor;
};
/* Only valid for joinable threads. */
diff --git a/monitor.c b/monitor.c
index 51f4cf480f..5035e42364 100644
--- a/monitor.c
+++ b/monitor.c
@@ -266,7 +266,7 @@ static mon_cmd_t info_cmds[];
QmpCommandList qmp_commands, qmp_cap_negotiation_commands;
-Monitor *cur_mon;
+__thread Monitor *cur_mon;
static QEMUClockType event_clock_type = QEMU_CLOCK_REALTIME;
diff --git a/stubs/monitor.c b/stubs/monitor.c
index e018c8f594..3890771bb5 100644
--- a/stubs/monitor.c
+++ b/stubs/monitor.c
@@ -3,7 +3,7 @@
#include "qemu-common.h"
#include "monitor/monitor.h"
-Monitor *cur_mon = NULL;
+__thread Monitor *cur_mon;
int monitor_get_fd(Monitor *mon, const char *name, Error **errp)
{
diff --git a/tests/test-util-sockets.c b/tests/test-util-sockets.c
index acadd85e8f..6195a3ac36 100644
--- a/tests/test-util-sockets.c
+++ b/tests/test-util-sockets.c
@@ -69,7 +69,7 @@ int monitor_get_fd(Monitor *mon, const char *fdname, Error
**errp)
* stubs/monitor.c is defined, to make sure monitor.o is discarded
* otherwise we get duplicate syms at link time.
*/
-Monitor *cur_mon;
+__thread Monitor *cur_mon;
void monitor_init(Chardev *chr, int flags) {}
diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
index 3ae96210d6..8d13da1b09 100644
--- a/util/qemu-thread-posix.c
+++ b/util/qemu-thread-posix.c
@@ -14,6 +14,7 @@
#include "qemu/thread.h"
#include "qemu/atomic.h"
#include "qemu/notify.h"
+#include "monitor/monitor.h"
#include "trace.h"
static bool name_threads;
@@ -486,6 +487,7 @@ typedef struct {
void *(*start_routine)(void *);
void *arg;
char *name;
+Monitor *current_monitor;
} QemuThreadArgs;
static void *qemu_thread_start(void *args)
@@ -494,6 +496,9 @@ static void *qemu_thread_start(void *args)
void *(*start_routine)(void *) = qemu_thread_args->start_routine;
void *arg = qemu_thread_args->arg;
+/* Inherit the cur_mon pointer from father thread */
+cur_mon = qemu_thread_args->current_monitor;
+
/* Attempt to set the threads name; note that this is for debug, so
* we're not going to fail if we can't set it.
*/
@@ -533,6 +538,7 @@ void qemu_thread_create(QemuThread *thread, const char
*name,
qemu_thread_args->name = g_strdup(name);
qemu_thread_args->start_routine = start_routine;
qemu_thread_args->arg = arg;
+qemu_thread_args->current_monitor = cur_mon;
err = pthread_create(&thread->thread, &attr,
qemu_thread_start, qemu_thread_args);
diff --git a/util/qemu-thread-win32.c b/util/qemu-thread-win32.c
index ab60c0d557..b5197dbc78 100644
--- a/util/qemu-thread-win32.c
+++ b/util/qemu-thread-win32.c
@@ -19,6 +19,7 @@
#include "qemu-common.h"
#include "qemu/thread.h"
#include "qemu/notify.h"
+#include "monitor/monitor.h"
#include "trace.h"
#include
@@ -298,6 +299,7 @@ struct QemuThreadData {
void *arg;
short mode;
NotifierList exit;
+Monitor *current_monitor;
/* Only used for joinable threads. */
bool exited;
@@ -339,6 +341,9 @@ static unsigned __stdcall win32_start_routine(void *arg)
void *(*start_routine)(void *) = data->start_routine;
void *thread_arg = data->arg;
+/* Inherit the cur_mon pointer from father thread */
+cur_mon = data->current_monitor;
+
qemu_thread_data = data;
qemu_thread_exit(start_routine(thread_arg));
abort();
@@ -401,6 +406,7 @@ void qemu_thread_create(QemuThread *thread, const char
*name,
data->arg = arg;
data
[Qemu-devel] [PATCH 0/2] qemu-thread: allow cur_mon be per thread
This should be for 2.13. But I'd like to get early review comments too if there is any. Now cur_mon is still only be accessed by the main thread. So we don't even need per-thread cur_mon. However after more commands become OOB compatible, cur_mon can be accessed by more than main thread now. The major user should be the monitor IOThread. This series tries to let cur_mon be per-thread, so that we can be well-prepared. The first patch is a cleanup. The second patch does the idea. Any early review comments would be welcomed. Thanks, Peter Xu (2): qemu-thread: always keep the posix wrapper layer qemu-thread: let cur_mon be per-thread include/monitor/monitor.h | 2 +- include/qemu/thread-win32.h | 1 + monitor.c | 2 +- stubs/monitor.c | 2 +- tests/test-util-sockets.c | 2 +- util/qemu-thread-posix.c| 39 +++ util/qemu-thread-win32.c| 6 ++ 7 files changed, 30 insertions(+), 24 deletions(-) -- 2.14.3
[Qemu-devel] [PATCH 1/2] qemu-thread: always keep the posix wrapper layer
We will conditionally have a wrapper layer depending on whether the host
has the PTHREAD_SETNAME capability. It complicates stuff. Let's just
keep the wrapper there, meanwhile we opt out the pthread_setname_np()
call only. The layer can be helpful in future patches to pass data from
the parent thread to the child thread.
Signed-off-by: Peter Xu
---
util/qemu-thread-posix.c | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
index b789cf32e9..3ae96210d6 100644
--- a/util/qemu-thread-posix.c
+++ b/util/qemu-thread-posix.c
@@ -482,7 +482,6 @@ static void __attribute__((constructor))
qemu_thread_atexit_init(void)
}
-#ifdef CONFIG_PTHREAD_SETNAME_NP
typedef struct {
void *(*start_routine)(void *);
void *arg;
@@ -498,13 +497,15 @@ static void *qemu_thread_start(void *args)
/* Attempt to set the threads name; note that this is for debug, so
* we're not going to fail if we can't set it.
*/
-pthread_setname_np(pthread_self(), qemu_thread_args->name);
+#ifdef CONFIG_PTHREAD_SETNAME_NP
+if (qemu_thread_args->name) {
+pthread_setname_np(pthread_self(), qemu_thread_args->name);
+}
+#endif
g_free(qemu_thread_args->name);
g_free(qemu_thread_args);
return start_routine(arg);
}
-#endif
-
void qemu_thread_create(QemuThread *thread, const char *name,
void *(*start_routine)(void*),
@@ -513,6 +514,7 @@ void qemu_thread_create(QemuThread *thread, const char
*name,
sigset_t set, oldset;
int err;
pthread_attr_t attr;
+QemuThreadArgs *qemu_thread_args;
err = pthread_attr_init(&attr);
if (err) {
@@ -527,22 +529,13 @@ void qemu_thread_create(QemuThread *thread, const char
*name,
sigfillset(&set);
pthread_sigmask(SIG_SETMASK, &set, &oldset);
-#ifdef CONFIG_PTHREAD_SETNAME_NP
-if (name_threads) {
-QemuThreadArgs *qemu_thread_args;
-qemu_thread_args = g_new0(QemuThreadArgs, 1);
-qemu_thread_args->name = g_strdup(name);
-qemu_thread_args->start_routine = start_routine;
-qemu_thread_args->arg = arg;
-
-err = pthread_create(&thread->thread, &attr,
- qemu_thread_start, qemu_thread_args);
-} else
-#endif
-{
-err = pthread_create(&thread->thread, &attr,
- start_routine, arg);
-}
+qemu_thread_args = g_new0(QemuThreadArgs, 1);
+qemu_thread_args->name = g_strdup(name);
+qemu_thread_args->start_routine = start_routine;
+qemu_thread_args->arg = arg;
+
+err = pthread_create(&thread->thread, &attr,
+ qemu_thread_start, qemu_thread_args);
if (err)
error_exit(err, __func__);
--
2.14.3
Re: [Qemu-devel] [PATCH for-2.12 v2] monitor: bind dispatch bh to iohandler context
On 04/10/2018 12:01 AM, Stefan Hajnoczi wrote: > On Tue, Apr 10, 2018 at 12:49:42PM +0800, Peter Xu wrote: >> Eric Auger reported the problem days ago that OOB broke ARM when running >> with libvirt: >> >> http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06231.html >> >> The problem was that the monitor dispatcher bottom half was bound to >> qemu_aio_context now, which could be polled unexpectedly in block code. > > And TPM and 9P code, who all use nested event loops. I'll tweak the commit message to mention that. > >> We should keep the dispatchers run in iohandler_ctx just like what we >> did before the Out-Of-Band series (chardev uses qio, and qio binds >> everything with iohandler_ctx). >> >> --- >> v2: >> - enhanced commit message Thanks for that. As you are learning, the hardest part of writing a patch is often not the code itself, but figuring out the most efficient way to get reviewers to understand why the patch is important. The better you get at writing GOOD commit messages, the easier it is for your patches to be accepted! >> --- >> monitor.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/monitor.c b/monitor.c >> index 51f4cf480f..39f8ee17ba 100644 >> --- a/monitor.c >> +++ b/monitor.c >> @@ -4467,7 +4467,7 @@ static void monitor_iothread_init(void) >> * have assumption to be run on main loop thread. It would be >> * nice that one day we can remove this assumption in the future. >> */ >> -mon_global.qmp_dispatcher_bh = aio_bh_new(qemu_get_aio_context(), >> +mon_global.qmp_dispatcher_bh = aio_bh_new(iohandler_get_aio_context(), >>monitor_qmp_bh_dispatcher, >>NULL); > > Reviewed-by: Stefan Hajnoczi Reviewed-by: Eric Blake and queuing through my qapi tree, pull request for -rc3 going out shortly -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH v2 2/2] sdl: Allow OpenGL ES context creation
On Tue, Apr 10, 2018 at 01:02:22PM +0100, Elie Tournier wrote:
> Signed-off-by: Elie Tournier
> ---
> include/ui/sdl2.h | 1 +
> qemu-options.hx | 2 +-
> ui/sdl2-gl.c | 17 +++--
> ui/sdl2.c | 1 +
> vl.c | 4
> 5 files changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h
> index 51084e6320..8495795e48 100644
> --- a/include/ui/sdl2.h
> +++ b/include/ui/sdl2.h
> @@ -22,6 +22,7 @@ struct sdl2_console {
> int x, y, w, h;
> int hidden;
> int opengl;
> +DisplayGLMode gl_mode;
I'd suggest to move the "opts" global in sdl2.c to this struct instead,
then you can use scon->opts->gl.
cheers,
Gerd
Re: [Qemu-devel] [PATCH v2 1/2] qapi: Parameter gl of DisplayType now accept an enum
> -if (dpy.has_gl && dpy.gl && display_opengl == 0) {
> +if (dpy.has_gl && !dpy.gl == DISPLAYGL_MODE_OFF && display_opengl == 0) {
That should be "... && !(dpy.gl == DISPLAYGL_MODE_OFF) && ..." to work
correctly. Or just "dpy.gl != DISPLAYGL_MODE_OFF" ...
cheers,
Gerd
Re: [Qemu-devel] [PATCH] qemu-iotests: Remove _supported_fmt dmg
On 04/10/2018 03:42 AM, Kevin Wolf wrote: > qemu-iotests doesn't support dmg, and the dmg block driver doesn't > support image creation. Two test cases declare dmg as supported, but > that's obviously wrong for both reasons. Remove the declaration. > > Signed-off-by: Kevin Wolf > --- > tests/qemu-iotests/183 | 2 +- > tests/qemu-iotests/194 | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Eric Blake -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PULL 06/12] hw/arm/allwinner-a10: Do not use nd_table in instance_init function
From: Thomas Huth
The instance_init function of a device can be called at any time, even
if the device is not going to be used (i.e. not going to be realized).
So a instance_init function must not do things that could cause QEMU
to exit, like calling qemu_check_nic_model(&nd_table[0], ...) for example.
But this is what the instance_init function of the allwinner-a10 device
is currently doing - and this causes QEMU to quit unexpectedly when
you run the 'device-list-properties' QMP command for example:
$ echo "{'execute':'qmp_capabilities'}"\
"{'execute':'device-list-properties',"\
" 'arguments':{'typename':'allwinner-a10'}}" \
| arm-softmmu/qemu-system-arm -M mps2-an505,accel=qtest -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2},
"package": "build-all"}, "capabilities": []}}
{"return": {}}
Unsupported NIC model: lan9118
... and QEMU quits after printing the last line (which should not happen
just because of running 'device-list-properties' here).
And with the cubieboard, this even causes QEMU to abort():
$ echo "{'execute':'qmp_capabilities'}"\
"{'execute':'device-list-properties',"\
" 'arguments':{'typename':'allwinner-a10'}}" \
| arm-softmmu/qemu-system-arm -M cubieboard,accel=qtest -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2},
"package": "build-all"}, "capabilities": []}}
{"return": {}}
Unexpected error in error_set_from_qdev_prop_error() at
hw/core/qdev-properties.c:1095:
Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use
Aborted (core dumped)
To fix the problem we've got to move the offending code to the realize
function instead.
Signed-off-by: Thomas Huth
Message-id: 1522862420-7484-1-git-send-email-th...@redhat.com
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
hw/arm/allwinner-a10.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hw/arm/allwinner-a10.c b/hw/arm/allwinner-a10.c
index 43a3f01f45..5dbbacb7e8 100644
--- a/hw/arm/allwinner-a10.c
+++ b/hw/arm/allwinner-a10.c
@@ -38,11 +38,6 @@ static void aw_a10_init(Object *obj)
object_initialize(&s->emac, sizeof(s->emac), TYPE_AW_EMAC);
qdev_set_parent_bus(DEVICE(&s->emac), sysbus_get_default());
-/* FIXME use qdev NIC properties instead of nd_table[] */
-if (nd_table[0].used) {
-qemu_check_nic_model(&nd_table[0], TYPE_AW_EMAC);
-qdev_set_nic_properties(DEVICE(&s->emac), &nd_table[0]);
-}
object_initialize(&s->sata, sizeof(s->sata), TYPE_ALLWINNER_AHCI);
qdev_set_parent_bus(DEVICE(&s->sata), sysbus_get_default());
@@ -91,6 +86,11 @@ static void aw_a10_realize(DeviceState *dev, Error **errp)
sysbus_connect_irq(sysbusdev, 4, s->irq[67]);
sysbus_connect_irq(sysbusdev, 5, s->irq[68]);
+/* FIXME use qdev NIC properties instead of nd_table[] */
+if (nd_table[0].used) {
+qemu_check_nic_model(&nd_table[0], TYPE_AW_EMAC);
+qdev_set_nic_properties(DEVICE(&s->emac), &nd_table[0]);
+}
object_property_set_bool(OBJECT(&s->emac), true, "realized", &err);
if (err != NULL) {
error_propagate(errp, err);
@@ -118,7 +118,7 @@ static void aw_a10_class_init(ObjectClass *oc, void *data)
DeviceClass *dc = DEVICE_CLASS(oc);
dc->realize = aw_a10_realize;
-/* Reason: Uses serial_hds in realize and nd_table in instance_init */
+/* Reason: Uses serial_hds and nd_table in realize function */
dc->user_creatable = false;
}
--
2.16.2
[Qemu-devel] [PULL 01/12] hw/arm: Allow manually specified /psci node
From: Andrey Smirnov
Change the code to avoid exiting QEMU if user provided DTB contains
manually specified /psci node and skip any /psci related fixups
instead.
Fixes: 4cbca7d9b4 ("hw/arm: Move virt's PSCI DT fixup code to
arm/boot.c")
Signed-off-by: Andrey Smirnov
Reported-by: Marc Zyngier
Tested-by: Marc Zyngier
Message-id: 20180402205654.14572-1-andrew.smir...@gmail.com
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
hw/arm/boot.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 9319b12fcd..26184bcd7c 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -422,6 +422,7 @@ static void fdt_add_psci_node(void *fdt)
ARMCPU *armcpu = ARM_CPU(qemu_get_cpu(0));
const char *psci_method;
int64_t psci_conduit;
+int rc;
psci_conduit = object_property_get_int(OBJECT(armcpu),
"psci-conduit",
@@ -439,6 +440,15 @@ static void fdt_add_psci_node(void *fdt)
g_assert_not_reached();
}
+/*
+ * If /psci node is present in provided DTB, assume that no fixup
+ * is necessary and all PSCI configuration should be taken as-is
+ */
+rc = fdt_path_offset(fdt, "/psci");
+if (rc >= 0) {
+return;
+}
+
qemu_fdt_add_subnode(fdt, "/psci");
if (armcpu->psci_version == 2) {
const char comp[] = "arm,psci-0.2\0arm,psci";
--
2.16.2
Re: [Qemu-devel] [PATCH] migration: Don't activate block devices if using -S
Am 10.04.2018 um 12:40 hat Dr. David Alan Gilbert geschrieben: > * Kevin Wolf (kw...@redhat.com) wrote: > > Am 10.04.2018 um 10:45 hat Dr. David Alan Gilbert geschrieben: > > > * Kevin Wolf (kw...@redhat.com) wrote: > > > > Am 10.04.2018 um 09:36 hat Jiri Denemark geschrieben: > > > > > On Mon, Apr 09, 2018 at 15:40:03 +0200, Kevin Wolf wrote: > > > > > > Am 09.04.2018 um 12:27 hat Dr. David Alan Gilbert geschrieben: > > > > > > > It's a fairly hairy failure case they had; if I remember > > > > > > > correctly it's: > > > > > > > a) Start migration > > > > > > > b) Migration gets to completion point > > > > > > > c) Destination is still paused > > > > > > > d) Libvirt is restarted on the source > > > > > > > e) Since libvirt was restarted it fails the migration (and > > > > > > > hence knows > > > > > > > the destination won't be started) > > > > > > > f) It now tries to resume the qemu on the source > > > > > > > > > > > > > > (f) fails because (b) caused the locks to be taken on the > > > > > > > destination; > > > > > > > hence this patch stops doing that. It's a case we don't really > > > > > > > think > > > > > > > about - i.e. that the migration has actually completed and all > > > > > > > the data > > > > > > > is on the destination, but libvirt decides for some other reason > > > > > > > to > > > > > > > abandon migration. > > > > > > > > > > > > If you do remember correctly, that scenario doesn't feel tricky at > > > > > > all. > > > > > > libvirt needs to quit the destination qemu, which will inactivate > > > > > > the > > > > > > images on the destination and release the lock, and then it can > > > > > > continue > > > > > > the source. > > > > > > > > > > > > In fact, this is so straightforward that I wonder what else libvirt > > > > > > is > > > > > > doing. Is the destination qemu only shut down after trying to > > > > > > continue > > > > > > the source? That would be libvirt using the wrong order of steps. > > > > > > > > > > There's no connection between the two libvirt daemons in the case > > > > > we're > > > > > talking about so they can't really synchronize the actions. The > > > > > destination daemon will kill the new QEMU process and the source will > > > > > resume the old one, but the order is completely random. > > > > > > > > Hm, okay... > > > > > > > > > > > Yes it was a 'block-activate' that I'd wondered about. One > > > > > > > complication > > > > > > > is that if this now under the control of the management layer > > > > > > > then we > > > > > > > should stop asserting when the block devices aren't in the > > > > > > > expected > > > > > > > state and just cleanly fail the command instead. > > > > > > > > > > > > Requiring an explicit 'block-activate' on the destination would be > > > > > > an > > > > > > incompatible change, so you would have to introduce a new option for > > > > > > that. 'block-inactivate' on the source feels a bit simpler. > > > > > > > > > > As I said in another email, the explicit block-activate command could > > > > > depend on a migration capability similarly to how pre-switchover state > > > > > works. > > > > > > > > Yeah, that's exactly the thing that we wouldn't need if we could use > > > > 'block-inactivate' on the source instead. It feels a bit wrong to > > > > design a more involved QEMU interface around the libvirt internals, > > > > > > It's not necessarily 'libvirt internals' - it's a case of them having to > > > cope with recovering from failures that happen around migration; it's > > > not an easy problem, and if they've got a way to stop both sides running > > > at the same time that's pretty important. > > > > The 'libvirt internals' isn't that it needs an additional state where > > neither source nor destination QEMU own the images, but that it has to > > be between migration completion and image activation on the destination > > rather than between image inactivation on the source and migration > > completion. The latter would be much easier for qemu, but apparently it > > doesn't work for libvirt because of how it works internally. > > I suspect this is actually a fundamental requirement to ensuring that we > don't end up with a QEMU running on both sides rather than how libvirt is > structured. I don't think so. In theory, both options can provide the same. If anything, it's related specifically to the phases that Jirka described that libvirt uses to implement migration. > > But as I said, I'd just implement both for symmetry and then management > > tools can pick whatever makes their life easier. > > > > > > but > > > > as long as we implement both sides for symmetry and libvirt just happens > > > > to pick the destination side for now, I think it's okay. > > > > > > > > By the way, are block devices the only thing that need to be explicitly > > > > activated? For example, what about qemu_announce_self() for network > > > > cards, do we need to delay that, too? > > > > > > > > I
[Qemu-devel] [PULL 02/12] hw/arm/integratorcp: Don't do things that could be fatal in the instance_init
From: Thomas Huth
An instance_init function must not fail - and might be called multiple times,
e.g. during device introspection with the 'device-list-properties' QMP
command. Since the integratorcm device ignores this rule, QEMU currently
aborts in this case (though it really should not):
echo "{'execute':'qmp_capabilities'}"\
"{'execute':'device-list-properties',"\
"'arguments':{'typename':'integrator_core'}}" \
| arm-softmmu/qemu-system-arm -M integratorcp,accel=qtest -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2},
"package": "build-all"}, "capabilities": []}}
{"return": {}}
RAMBlock "integrator.flash" already registered, abort!
Aborted (core dumped)
Move the problematic code to the realize() function instead to fix this
problem.
Reviewed-by: Philippe Mathieu-Daudé
Signed-off-by: Thomas Huth
Message-id: 1522906473-11252-1-git-send-email-th...@redhat.com
Signed-off-by: Peter Maydell
---
hw/arm/integratorcp.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/hw/arm/integratorcp.c b/hw/arm/integratorcp.c
index e8303b83be..58b40efc19 100644
--- a/hw/arm/integratorcp.c
+++ b/hw/arm/integratorcp.c
@@ -266,7 +266,6 @@ static const MemoryRegionOps integratorcm_ops = {
static void integratorcm_init(Object *obj)
{
IntegratorCMState *s = INTEGRATOR_CM(obj);
-SysBusDevice *dev = SYS_BUS_DEVICE(obj);
s->cm_osc = 0x0148;
/* ??? What should the high bits of this value be? */
@@ -276,20 +275,28 @@ static void integratorcm_init(Object *obj)
s->cm_init = 0x0112;
s->cm_refcnt_offset = muldiv64(qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL), 24,
1000);
-memory_region_init_ram(&s->flash, obj, "integrator.flash", 0x10,
- &error_fatal);
-memory_region_init_io(&s->iomem, obj, &integratorcm_ops, s,
- "integratorcm", 0x0080);
-sysbus_init_mmio(dev, &s->iomem);
-
-integratorcm_do_remap(s);
/* ??? Save/restore. */
}
static void integratorcm_realize(DeviceState *d, Error **errp)
{
IntegratorCMState *s = INTEGRATOR_CM(d);
+SysBusDevice *dev = SYS_BUS_DEVICE(d);
+Error *local_err = NULL;
+
+memory_region_init_ram(&s->flash, OBJECT(d), "integrator.flash", 0x10,
+ &local_err);
+if (local_err) {
+error_propagate(errp, local_err);
+return;
+}
+
+memory_region_init_io(&s->iomem, OBJECT(d), &integratorcm_ops, s,
+ "integratorcm", 0x0080);
+sysbus_init_mmio(dev, &s->iomem);
+
+integratorcm_do_remap(s);
if (s->memsz >= 256) {
integrator_spd[31] = 64;
--
2.16.2
[Qemu-devel] [PULL 03/12] target-arm: Check undefined opcodes for SWP in A32 decoder
From: Onur Sahin
Make sure we are not treating architecturally Undefined instructions
as a SWP, by verifying the opcodes as per section A8.8.229 of ARMv7-A
specification. Bits [21:20] must be zero for this to be a SWP or SWPB.
We also choose to UNDEF for the architecturally UNPREDICTABLE case of
bits [11:8] not being zero.
Signed-off-by: Onur Sahin
[PMM: tweaked commit message]
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
target/arm/translate.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/target/arm/translate.c b/target/arm/translate.c
index fc03b5b8c8..db1ce6510a 100644
--- a/target/arm/translate.c
+++ b/target/arm/translate.c
@@ -9237,11 +9237,14 @@ static void disas_arm_insn(DisasContext *s, unsigned
int insn)
}
}
tcg_temp_free_i32(addr);
-} else {
+} else if ((insn & 0x00300f00) == 0) {
+/* 0b_0001_0x00____1001_
+* - SWP, SWPB
+*/
+
TCGv taddr;
TCGMemOp opc = s->be_data;
-/* SWP instruction */
rm = (insn) & 0xf;
if (insn & (1 << 22)) {
@@ -9259,6 +9262,8 @@ static void disas_arm_insn(DisasContext *s, unsigned int
insn)
get_mem_index(s), opc);
tcg_temp_free(taddr);
store_reg(s, rd, tmp);
+} else {
+goto illegal_op;
}
}
} else {
--
2.16.2
[Qemu-devel] [PULL 00/12] target-arm queue
Arm patch queue for 2.12 -- a miscellaneous collection of bug fixes. thanks -- PMM The following changes since commit fb4fe32d5b6290deabe752b51cc1cc2a9e8573db: Merge remote-tracking branch 'remotes/xtensa/tags/20180409-xtensa' into staging (2018-04-10 10:22:45 +0100) are available in the Git repository at: git://git.linaro.org/people/pmaydell/qemu-arm.git tags/pull-target-arm-20180410 for you to fetch changes up to bd49e6027cbc207c87633c7add3ebd7d3474cd35: fpu: Fix rounding mode for floatN_to_uintM_round_to_zero (2018-04-10 13:02:26 +0100) target-arm queue: * fpu: Fix rounding mode for floatN_to_uintM_round_to_zero * tcg: Fix guest state corruption when running 64-bit Arm guests on a 32-bit host (especially when using icount) * linux-user/signal.c: Ensure AArch64 signal frame isn't too small * cpus.c: ensure running CPU recalculates icount deadlines on timer expiry * target/arm: Report unsupported MPU region sizes more clearly * hw/arm/fsl-imx: Fix introspection problem with fsl-imx6 and fsl-imx7 * hw/arm/allwinner-a10: Do not use nd_table in instance_init function * hw/sd/bcm2835_sdhost: Don't raise spurious interrupts * hw/sd/bcm2835_sdhost: Add tracepoints * target-arm: Check undefined opcodes for SWP in A32 decoder * hw/arm/integratorcp: Don't do things that could be fatal in the instance_init * hw/arm: Allow manually specified /psci node Andrey Smirnov (1): hw/arm: Allow manually specified /psci node Onur Sahin (1): target-arm: Check undefined opcodes for SWP in A32 decoder Peter Maydell (5): hw/sd/bcm2835_sdhost: Add tracepoints hw/sd/bcm2835_sdhost: Don't raise spurious interrupts target/arm: Report unsupported MPU region sizes more clearly cpus.c: ensure running CPU recalculates icount deadlines on timer expiry linux-user/signal.c: Ensure AArch64 signal frame isn't too small Richard Henderson (2): tcg: Introduce tcg_set_insn_start_param fpu: Fix rounding mode for floatN_to_uintM_round_to_zero Thomas Huth (3): hw/arm/integratorcp: Don't do things that could be fatal in the instance_init hw/arm/allwinner-a10: Do not use nd_table in instance_init function hw/arm/fsl-imx: Fix introspection problem with fsl-imx6 and fsl-imx7 target/arm/translate.h | 2 +- tcg/tcg.h | 10 ++ cpus.c | 10 +- fpu/softfloat.c| 4 ++-- hw/arm/allwinner-a10.c | 12 +-- hw/arm/boot.c | 10 ++ hw/arm/fsl-imx6.c | 14 ++--- hw/arm/fsl-imx7.c | 13 ++-- hw/arm/integratorcp.c | 23 + hw/sd/bcm2835_sdhost.c | 54 -- linux-user/signal.c| 6 ++ target/arm/helper.c| 6 +++--- target/arm/translate.c | 9 +++-- hw/sd/trace-events | 6 ++ 14 files changed, 124 insertions(+), 55 deletions(-)
[Qemu-devel] [PULL 05/12] hw/sd/bcm2835_sdhost: Don't raise spurious interrupts
The Linux bcm2835_sdhost driver doesn't work on QEMU, because our
model raises spurious data interrupts. Our function
bcm2835_sdhost_fifo_run() will flag an interrupt any time it is
called with s->datacnt == 0, even if the host hasn't actually issued
a data read or write command yet. This means that the driver gets a
spurious data interrupt as soon as it enables IRQs and then does
something else that causes us to call the fifo_run routine, like
writing to SDHCFG, and before it does the write to SDCMD to issue the
read. The driver's IRQ handler then spins forever complaining that
there's no data and the SD controller isn't in a state where there's
going to be any data:
[ 41.040738] sdhost-bcm2835 3f202000.mmc: fsm 1, hsts
[ 41.042059] sdhost-bcm2835 3f202000.mmc: fsm 1, hsts
(continues forever).
Move the interrupt flag setting to more plausible places:
* for BUSY, raise this as soon as a BUSYWAIT command has executed
* for DATA, raise this when the FIFO has any space free (for a write)
or any data in it (for a read)
* for BLOCK, raise this when the data count is 0 and we've
actually done some reading or writing
This is pure guesswork since the documentation for this hardware is
not public, but it is sufficient to get the Linux bcm2835_sdhost
driver to work.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Gerd Hoffmann
Message-id: 20180319161556.16446-3-peter.mayd...@linaro.org
---
hw/sd/bcm2835_sdhost.c | 46 ++
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/hw/sd/bcm2835_sdhost.c b/hw/sd/bcm2835_sdhost.c
index 79f3c5ceeb..ebf3b926c2 100644
--- a/hw/sd/bcm2835_sdhost.c
+++ b/hw/sd/bcm2835_sdhost.c
@@ -137,6 +137,12 @@ static void bcm2835_sdhost_send_command(BCM2835SDHostState
*s)
}
#undef RWORD
}
+/* We never really delay commands, so if this was a 'busywait' command
+ * then we've completed it now and can raise the interrupt.
+ */
+if ((s->cmd & SDCMD_BUSYWAIT) && (s->config & SDHCFG_BUSY_IRPT_EN)) {
+s->status |= SDHSTS_BUSY_IRPT;
+}
return;
error:
@@ -187,18 +193,27 @@ static void bcm2835_sdhost_fifo_run(BCM2835SDHostState *s)
n++;
if (n == 4) {
bcm2835_sdhost_fifo_push(s, value);
+s->status |= SDHSTS_DATA_FLAG;
+if (s->config & SDHCFG_DATA_IRPT_EN) {
+s->status |= SDHSTS_SDIO_IRPT;
+}
n = 0;
value = 0;
}
}
if (n != 0) {
bcm2835_sdhost_fifo_push(s, value);
+s->status |= SDHSTS_DATA_FLAG;
}
} else { /* write */
n = 0;
while (s->datacnt > 0 && (s->fifo_len > 0 || n > 0)) {
if (n == 0) {
value = bcm2835_sdhost_fifo_pop(s);
+s->status |= SDHSTS_DATA_FLAG;
+if (s->config & SDHCFG_DATA_IRPT_EN) {
+s->status |= SDHSTS_SDIO_IRPT;
+}
n = 4;
}
n--;
@@ -207,28 +222,19 @@ static void bcm2835_sdhost_fifo_run(BCM2835SDHostState *s)
value >>= 8;
}
}
+if (s->datacnt == 0) {
+s->edm &= ~SDEDM_FSM_MASK;
+s->edm |= SDEDM_FSM_DATAMODE;
+trace_bcm2835_sdhost_edm_change("datacnt 0", s->edm);
+
+if ((s->cmd & SDCMD_WRITE_CMD) &&
+(s->config & SDHCFG_BLOCK_IRPT_EN)) {
+s->status |= SDHSTS_BLOCK_IRPT;
+}
+}
}
-if (s->datacnt == 0) {
-s->status |= SDHSTS_DATA_FLAG;
-s->edm &= ~0xf;
-s->edm |= SDEDM_FSM_DATAMODE;
-trace_bcm2835_sdhost_edm_change("datacnt 0", s->edm);
-
-if (s->config & SDHCFG_DATA_IRPT_EN) {
-s->status |= SDHSTS_SDIO_IRPT;
-}
-
-if ((s->cmd & SDCMD_BUSYWAIT) && (s->config & SDHCFG_BUSY_IRPT_EN)) {
-s->status |= SDHSTS_BUSY_IRPT;
-}
-
-if ((s->cmd & SDCMD_WRITE_CMD) && (s->config & SDHCFG_BLOCK_IRPT_EN)) {
-s->status |= SDHSTS_BLOCK_IRPT;
-}
-
-bcm2835_sdhost_update_irq(s);
-}
+bcm2835_sdhost_update_irq(s);
s->edm &= ~(0x1f << 4);
s->edm |= ((s->fifo_len & 0x1f) << 4);
--
2.16.2
[Qemu-devel] [PULL 07/12] hw/arm/fsl-imx: Fix introspection problem with fsl-imx6 and fsl-imx7
From: Thomas Huth
QEMU currently exits unexpectedly when trying to introspect the fsl-imx6
and fsl-imx7 devices on systems with many SMP CPUs:
$ echo "{'execute':'qmp_capabilities'}"\
"{'execute':'device-list-properties',"\
" 'arguments':{'typename':'fsl,imx6'}}" \
| arm-softmmu/qemu-system-arm -M virt,accel=qtest -qmp stdio -smp 8
{"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2},
"package": "build-all"}, "capabilities": []}}
{"return": {}}
fsl,imx6: Only 4 CPUs are supported (8 requested)
And:
$ echo "{'execute':'qmp_capabilities'}"\
"{'execute':'device-list-properties',"\
" 'arguments':{'typename':'fsl,imx7'}}" \
| arm-softmmu/qemu-system-arm -M raspi2,accel=qtest -qmp stdio
{"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2},
"package": "build-all"}, "capabilities": []}}
{"return": {}}
fsl,imx7: Only 2 CPUs are supported (4 requested)
This happens because these devices are doing an exit() from their
instance_init function - which should never be done since instance_init
can be called at any time for device introspection! Fix it by moving
the deadly check into the realize() function instead.
Signed-off-by: Thomas Huth
Message-id: 1522908551-14885-1-git-send-email-th...@redhat.com
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
hw/arm/fsl-imx6.c | 14 +++---
hw/arm/fsl-imx7.c | 13 +++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/hw/arm/fsl-imx6.c b/hw/arm/fsl-imx6.c
index b6ac72de27..9dfbc9a8c4 100644
--- a/hw/arm/fsl-imx6.c
+++ b/hw/arm/fsl-imx6.c
@@ -37,13 +37,7 @@ static void fsl_imx6_init(Object *obj)
char name[NAME_SIZE];
int i;
-if (smp_cpus > FSL_IMX6_NUM_CPUS) {
-error_report("%s: Only %d CPUs are supported (%d requested)",
- TYPE_FSL_IMX6, FSL_IMX6_NUM_CPUS, smp_cpus);
-exit(1);
-}
-
-for (i = 0; i < smp_cpus; i++) {
+for (i = 0; i < MIN(smp_cpus, FSL_IMX6_NUM_CPUS); i++) {
object_initialize(&s->cpu[i], sizeof(s->cpu[i]),
"cortex-a9-" TYPE_ARM_CPU);
snprintf(name, NAME_SIZE, "cpu%d", i);
@@ -119,6 +113,12 @@ static void fsl_imx6_realize(DeviceState *dev, Error
**errp)
uint16_t i;
Error *err = NULL;
+if (smp_cpus > FSL_IMX6_NUM_CPUS) {
+error_setg(errp, "%s: Only %d CPUs are supported (%d requested)",
+ TYPE_FSL_IMX6, FSL_IMX6_NUM_CPUS, smp_cpus);
+return;
+}
+
for (i = 0; i < smp_cpus; i++) {
/* On uniprocessor, the CBAR is set to 0 */
diff --git a/hw/arm/fsl-imx7.c b/hw/arm/fsl-imx7.c
index 26ef36c79a..390b4310e6 100644
--- a/hw/arm/fsl-imx7.c
+++ b/hw/arm/fsl-imx7.c
@@ -35,13 +35,8 @@ static void fsl_imx7_init(Object *obj)
char name[NAME_SIZE];
int i;
-if (smp_cpus > FSL_IMX7_NUM_CPUS) {
-error_report("%s: Only %d CPUs are supported (%d requested)",
- TYPE_FSL_IMX7, FSL_IMX7_NUM_CPUS, smp_cpus);
-exit(1);
-}
-for (i = 0; i < smp_cpus; i++) {
+for (i = 0; i < MIN(smp_cpus, FSL_IMX7_NUM_CPUS); i++) {
object_initialize(&s->cpu[i], sizeof(s->cpu[i]),
ARM_CPU_TYPE_NAME("cortex-a7"));
snprintf(name, NAME_SIZE, "cpu%d", i);
@@ -197,6 +192,12 @@ static void fsl_imx7_realize(DeviceState *dev, Error
**errp)
qemu_irq irq;
char name[NAME_SIZE];
+if (smp_cpus > FSL_IMX7_NUM_CPUS) {
+error_setg(errp, "%s: Only %d CPUs are supported (%d requested)",
+ TYPE_FSL_IMX7, FSL_IMX7_NUM_CPUS, smp_cpus);
+return;
+}
+
for (i = 0; i < smp_cpus; i++) {
o = OBJECT(&s->cpu[i]);
--
2.16.2
[Qemu-devel] [PULL 08/12] target/arm: Report unsupported MPU region sizes more clearly
Currently our PMSAv7 and ARMv7M MPU implementation cannot handle
MPU region sizes smaller than our TARGET_PAGE_SIZE. However we
report that in a slightly confusing way:
DRSR[3]: No support for MPU (sub)region alignment of 9 bits. Minimum is 10
The problem is not the alignment of the region, but its size;
tweak the error message to say so:
DRSR[3]: No support for MPU (sub)region size of 512 bytes. Minimum is 1024.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Message-id: 20180405172554.27401-1-peter.mayd...@linaro.org
---
target/arm/helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/arm/helper.c b/target/arm/helper.c
index dcb8476d9e..b14fdab140 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -9625,9 +9625,9 @@ static bool get_phys_addr_pmsav7(CPUARMState *env,
uint32_t address,
}
if (rsize < TARGET_PAGE_BITS) {
qemu_log_mask(LOG_UNIMP,
- "DRSR[%d]: No support for MPU (sub)region "
- "alignment of %" PRIu32 " bits. Minimum is %d\n",
- n, rsize, TARGET_PAGE_BITS);
+ "DRSR[%d]: No support for MPU (sub)region size
of"
+ " %" PRIu32 " bytes. Minimum is %d.\n",
+ n, (1 << rsize), TARGET_PAGE_SIZE);
continue;
}
if (srdis) {
--
2.16.2
[Qemu-devel] [PULL 12/12] fpu: Fix rounding mode for floatN_to_uintM_round_to_zero
From: Richard Henderson
We incorrectly passed in the current rounding mode
instead of float_round_to_zero.
Signed-off-by: Richard Henderson
Message-id: 20180410055912.934-1-richard.hender...@linaro.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
fpu/softfloat.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fpu/softfloat.c b/fpu/softfloat.c
index 6e16284e66..b46dccc63e 100644
--- a/fpu/softfloat.c
+++ b/fpu/softfloat.c
@@ -1486,8 +1486,8 @@ uint ## isz ## _t float ## fsz ## _to_uint ## isz ##
_round_to_zero \
(float ## fsz a, float_status *s) \
{ \
FloatParts p = float ## fsz ## _unpack_canonical(a, s); \
-return round_to_uint_and_pack(p, s->float_rounding_mode,\
- UINT ## isz ## _MAX, s); \
+return round_to_uint_and_pack(p, float_round_to_zero, \
+ UINT ## isz ## _MAX, s); \
}
FLOAT_TO_UINT(16, 16)
--
2.16.2
[Qemu-devel] [PULL 11/12] tcg: Introduce tcg_set_insn_start_param
From: Richard Henderson
The parameters for tcg_gen_insn_start are target_ulong, which may be split
into two TCGArg parameters for storage in the opcode on 32-bit hosts.
Fixes the ARM target and its direct use of tcg_set_insn_param, which would
set the wrong argument in the 64-on-32 case.
Cc: qemu-sta...@nongnu.org
Reported-by: alar...@ddci.com
Signed-off-by: Richard Henderson
Message-id: 20180410003558.2470-1-richard.hender...@linaro.org
Reviewed-by: Peter Maydell
Signed-off-by: Peter Maydell
---
target/arm/translate.h | 2 +-
tcg/tcg.h | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/target/arm/translate.h b/target/arm/translate.h
index c47febf99d..4428c98e2e 100644
--- a/target/arm/translate.h
+++ b/target/arm/translate.h
@@ -120,7 +120,7 @@ static inline void disas_set_insn_syndrome(DisasContext *s,
uint32_t syn)
/* We check and clear insn_start_idx to catch multiple updates. */
assert(s->insn_start != NULL);
-tcg_set_insn_param(s->insn_start, 2, syn);
+tcg_set_insn_start_param(s->insn_start, 2, syn);
s->insn_start = NULL;
}
diff --git a/tcg/tcg.h b/tcg/tcg.h
index 9e2d909a4a..30896ca304 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -825,6 +825,16 @@ static inline void tcg_set_insn_param(TCGOp *op, int arg,
TCGArg v)
op->args[arg] = v;
}
+static inline void tcg_set_insn_start_param(TCGOp *op, int arg, target_ulong v)
+{
+#if TARGET_LONG_BITS <= TCG_TARGET_REG_BITS
+tcg_set_insn_param(op, arg, v);
+#else
+tcg_set_insn_param(op, arg * 2, v);
+tcg_set_insn_param(op, arg * 2 + 1, v >> 32);
+#endif
+}
+
/* The last op that was emitted. */
static inline TCGOp *tcg_last_op(void)
{
--
2.16.2
[Qemu-devel] [PULL 10/12] linux-user/signal.c: Ensure AArch64 signal frame isn't too small
The AArch64 signal frame design was extended for SVE in commit
8c5931de0ac77388096d79ceb, so that instead of having a fixed setup we
now add various records to the frame, with some of them possibly
overflowing into an extra space outside the original 4K reserved
block in the target_sigcontext. However, we failed to ensure that we
always at least allocate the 4K reserved block. This is ABI, and
some userspace programs rely on it. In particular the dash shell
would segfault if the frame wasn't as big enough.
(Compare the kernel's sigframe_size() function in
arch/arm64/kernel/signal.c.)
Reported-by: Richard Henwood
Reviewed-by: Laurent Vivier
Reviewed-by: Richard Henderson
Message-id: 20180409140714.26841-1-peter.mayd...@linaro.org
Fixes: https://bugs.launchpad.net/bugs/1761535
Fixes: 8c5931de0ac77388096d79ceb
Signed-off-by: Peter Maydell
---
linux-user/signal.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/linux-user/signal.c b/linux-user/signal.c
index 046d4c8aa0..8d9e6e8410 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -1850,6 +1850,12 @@ static void target_setup_frame(int usig, struct
target_sigaction *ka,
fr_ofs = layout.total_size;
layout.total_size += sizeof(struct target_rt_frame_record);
+/* We must always provide at least the standard 4K reserved space,
+ * even if we don't use all of it (this is part of the ABI)
+ */
+layout.total_size = MAX(layout.total_size,
+sizeof(struct target_rt_sigframe));
+
frame_addr = get_sigframe(ka, env, layout.total_size);
trace_user_setup_frame(env, frame_addr);
if (!lock_user_struct(VERIFY_WRITE, frame, frame_addr, 0)) {
--
2.16.2
[Qemu-devel] [PULL 04/12] hw/sd/bcm2835_sdhost: Add tracepoints
Add some tracepoints to the bcm2835_sdhost driver, to assist
debugging.
Signed-off-by: Peter Maydell
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Gerd Hoffmann
Message-id: 20180319161556.16446-2-peter.mayd...@linaro.org
---
hw/sd/bcm2835_sdhost.c | 10 ++
hw/sd/trace-events | 6 ++
2 files changed, 16 insertions(+)
diff --git a/hw/sd/bcm2835_sdhost.c b/hw/sd/bcm2835_sdhost.c
index f7f4e656df..79f3c5ceeb 100644
--- a/hw/sd/bcm2835_sdhost.c
+++ b/hw/sd/bcm2835_sdhost.c
@@ -15,6 +15,7 @@
#include "qemu/log.h"
#include "sysemu/blockdev.h"
#include "hw/sd/bcm2835_sdhost.h"
+#include "trace.h"
#define TYPE_BCM2835_SDHOST_BUS "bcm2835-sdhost-bus"
#define BCM2835_SDHOST_BUS(obj) \
@@ -99,6 +100,7 @@ static void bcm2835_sdhost_update_irq(BCM2835SDHostState *s)
{
uint32_t irq = s->status &
(SDHSTS_BUSY_IRPT | SDHSTS_BLOCK_IRPT | SDHSTS_SDIO_IRPT);
+trace_bcm2835_sdhost_update_irq(irq);
qemu_set_irq(s->irq, !!irq);
}
@@ -211,6 +213,7 @@ static void bcm2835_sdhost_fifo_run(BCM2835SDHostState *s)
s->edm &= ~0xf;
s->edm |= SDEDM_FSM_DATAMODE;
+trace_bcm2835_sdhost_edm_change("datacnt 0", s->edm);
if (s->config & SDHCFG_DATA_IRPT_EN) {
s->status |= SDHSTS_SDIO_IRPT;
@@ -229,6 +232,7 @@ static void bcm2835_sdhost_fifo_run(BCM2835SDHostState *s)
s->edm &= ~(0x1f << 4);
s->edm |= ((s->fifo_len & 0x1f) << 4);
+trace_bcm2835_sdhost_edm_change("fifo run", s->edm);
}
static uint64_t bcm2835_sdhost_read(void *opaque, hwaddr offset,
@@ -280,6 +284,8 @@ static uint64_t bcm2835_sdhost_read(void *opaque, hwaddr
offset,
break;
}
+trace_bcm2835_sdhost_read(offset, res, size);
+
return res;
}
@@ -288,6 +294,8 @@ static void bcm2835_sdhost_write(void *opaque, hwaddr
offset,
{
BCM2835SDHostState *s = (BCM2835SDHostState *)opaque;
+trace_bcm2835_sdhost_write(offset, value, size);
+
switch (offset) {
case SDCMD:
s->cmd = value;
@@ -314,6 +322,7 @@ static void bcm2835_sdhost_write(void *opaque, hwaddr
offset,
value &= ~0xf;
}
s->edm = value;
+trace_bcm2835_sdhost_edm_change("guest register write", s->edm);
break;
case SDHCFG:
s->config = value;
@@ -390,6 +399,7 @@ static void bcm2835_sdhost_reset(DeviceState *dev)
s->cmd = 0;
s->cmdarg = 0;
s->edm = 0xc60f;
+trace_bcm2835_sdhost_edm_change("device reset", s->edm);
s->config = 0;
s->hbct = 0;
s->hblc = 0;
diff --git a/hw/sd/trace-events b/hw/sd/trace-events
index 2059ace61f..bfd1d62efc 100644
--- a/hw/sd/trace-events
+++ b/hw/sd/trace-events
@@ -1,5 +1,11 @@
# See docs/devel/tracing.txt for syntax documentation.
+# hw/sd/bcm2835_sdhost.c
+bcm2835_sdhost_read(uint64_t offset, uint64_t data, unsigned size) "offset
0x%" PRIx64 " data 0x%" PRIx64 " size %u"
+bcm2835_sdhost_write(uint64_t offset, uint64_t data, unsigned size) "offset
0x%" PRIx64 " data 0x%" PRIx64 " size %u"
+bcm2835_sdhost_edm_change(const char *why, uint32_t edm) "(%s) EDM now 0x%x"
+bcm2835_sdhost_update_irq(uint32_t irq) "IRQ bits 0x%x\n"
+
# hw/sd/core.c
sdbus_command(const char *bus_name, uint8_t cmd, uint32_t arg, uint8_t crc)
"@%s CMD%02d arg 0x%08x crc 0x%02x"
sdbus_read(const char *bus_name, uint8_t value) "@%s value 0x%02x"
--
2.16.2
[Qemu-devel] [PULL 09/12] cpus.c: ensure running CPU recalculates icount deadlines on timer expiry
When we run in TCG icount mode, we calculate the number of instructions
to execute using tcg_get_icount_limit(), which ensures that we stop
execution at the next timer deadline. However there is a bug where
currently we do not recalculate that limit if the guest reprograms
a timer so that the next deadline moves closer, and so we will
continue execution until the original limit and fire the timer
later than we should.
Fix this bug in qemu_timer_notify_cb(): if we are currently running
a VCPU in icount mode, we simply need to kick it out of the main
loop and back to tcg_cpu_exec(), where it will recalculate the
icount limit. If we are not currently running a VCPU, then we
retain the existing logic for waking up a halted CPU.
Cc: qemu-sta...@nongnu.org
Fixes: https://bugs.launchpad.net/qemu/+bug/1754038
Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
Reviewed-by: Alex Bennée
Message-id: 20180406123838.21249-1-peter.mayd...@linaro.org
---
cpus.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/cpus.c b/cpus.c
index 2e6701795b..38eba8bff3 100644
--- a/cpus.c
+++ b/cpus.c
@@ -892,11 +892,19 @@ void qemu_timer_notify_cb(void *opaque, QEMUClockType
type)
return;
}
-if (!qemu_in_vcpu_thread() && first_cpu) {
+if (qemu_in_vcpu_thread()) {
+/* A CPU is currently running; kick it back out to the
+ * tcg_cpu_exec() loop so it will recalculate its
+ * icount deadline immediately.
+ */
+qemu_cpu_kick(current_cpu);
+} else if (first_cpu) {
/* qemu_cpu_kick is not enough to kick a halted CPU out of
* qemu_tcg_wait_io_event. async_run_on_cpu, instead,
* causes cpu_thread_is_idle to return false. This way,
* handle_icount_deadline can run.
+ * If we have no CPUs at all for some reason, we don't
+ * need to do anything.
*/
async_run_on_cpu(first_cpu, do_nothing, RUN_ON_CPU_NULL);
}
--
2.16.2
Re: [Qemu-devel] [qemu RFC] qapi: add "firmware.json"
On 04/10/18 12:20, Daniel P. Berrangé wrote:
> On Sat, Apr 07, 2018 at 02:01:17AM +0200, Laszlo Ersek wrote:
>> +{ 'struct' : 'SystemFirmware',
>> + 'data' : { 'executable' : 'FirmwareFile',
>> + 'type' : 'SystemFirmwareType',
>> + 'targets': [ 'str' ],
>> + 'sysfw-map' : 'FirmwareMapping',
>> + '*nvram-slots' : [ 'NVRAMSlot' ],
>> + '*supports-uefi-secure-boot' : 'bool',
>> + '*supports-amd-sev' : 'bool',
>> + '*supports-acpi-s3' : 'bool',
>> + '*supports-acpi-s4' : 'bool' } }
>
> Elsewhere in the thread I mentioned that I think we should try to use a
> union approach to isolate which information is relevant to "flash" loader
> format and which is relevant to "memory" and "kernel". To try to illustrate
> what I mean by that I've knocked up an alternative structure. I also
> incorporated the points about features & target/machine types. I've left
> out the read/write/etc fields, but they could be put back in at the
> relevant position
I think this looks very nice; with the addition of
- "requires-smm" to "SystemFirmwareFeature":
> { 'enum' : 'SystemFirmwareFeature',
> 'data': ['acpi-s3', 'acpi-s5', 'secure-boot', 'amd-sev' ]}
- and another feature flag (perhaps in SystemFirmwareFeature, perhaps in
SystemFirmwareBinaryFlashVars) for the cmdline option "-global
driver=cfi.pflash01,property=secure,value=on",
this could be called a day as far as SeaBIOS and OVMF are concerned.
Thanks
Laszlo
[Qemu-devel] [PATCH v2 2/2] sdl: Allow OpenGL ES context creation
Signed-off-by: Elie Tournier
---
include/ui/sdl2.h | 1 +
qemu-options.hx | 2 +-
ui/sdl2-gl.c | 17 +++--
ui/sdl2.c | 1 +
vl.c | 4
5 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/include/ui/sdl2.h b/include/ui/sdl2.h
index 51084e6320..8495795e48 100644
--- a/include/ui/sdl2.h
+++ b/include/ui/sdl2.h
@@ -22,6 +22,7 @@ struct sdl2_console {
int x, y, w, h;
int hidden;
int opengl;
+DisplayGLMode gl_mode;
int updates;
int idle_counter;
int ignore_hotkeys;
diff --git a/qemu-options.hx b/qemu-options.hx
index ca4e412f2f..333dd1f1c8 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1240,7 +1240,7 @@ ETEXI
DEF("display", HAS_ARG, QEMU_OPTION_display,
"-display sdl[,frame=on|off][,alt_grab=on|off][,ctrl_grab=on|off]\n"
-"[,window_close=on|off][,gl=on|off]\n"
+"[,window_close=on|off][,gl=on|core|es|off]\n"
"-display gtk[,grab_on_hover=on|off][,gl=on|off]|\n"
"-display vnc=[,]\n"
"-display curses\n"
diff --git a/ui/sdl2-gl.c b/ui/sdl2-gl.c
index c3683e6b65..4755314afe 100644
--- a/ui/sdl2-gl.c
+++ b/ui/sdl2-gl.c
@@ -140,12 +140,25 @@ QEMUGLContext
sdl2_gl_create_context(DisplayChangeListener *dcl,
SDL_GL_MakeCurrent(scon->real_window, scon->winctx);
SDL_GL_SetAttribute(SDL_GL_SHARE_WITH_CURRENT_CONTEXT, 1);
-SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK,
-SDL_GL_CONTEXT_PROFILE_CORE);
+if (scon->gl_mode == DISPLAYGL_MODE_ON || scon->gl_mode ==
DISPLAYGL_MODE_CORE)
+ SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK,
+ SDL_GL_CONTEXT_PROFILE_CORE);
+else if (scon->gl_mode == DISPLAYGL_MODE_ES)
+ SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK,
+ SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, params->major_ver);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, params->minor_ver);
ctx = SDL_GL_CreateContext(scon->real_window);
+
+/* If SDL fail to create a GL context and we use the "on" flag,
+ * then try to fallback to GLES.
+ */
+if (!ctx && scon->gl_mode == DISPLAYGL_MODE_ON) {
+ SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK,
+ SDL_GL_CONTEXT_PROFILE_ES);
+ ctx = SDL_GL_CreateContext(scon->real_window);
+}
return (QEMUGLContext)ctx;
}
diff --git a/ui/sdl2.c b/ui/sdl2.c
index 83b917fa37..29bf8e36ad 100644
--- a/ui/sdl2.c
+++ b/ui/sdl2.c
@@ -815,6 +815,7 @@ static void sdl2_display_init(DisplayState *ds,
DisplayOptions *o)
sdl2_console[i].idx = i;
#ifdef CONFIG_OPENGL
sdl2_console[i].opengl = display_opengl;
+sdl2_console[i].gl_mode = o->gl;
sdl2_console[i].dcl.ops = display_opengl ? &dcl_gl_ops : &dcl_2d_ops;
#else
sdl2_console[i].opengl = 0;
diff --git a/vl.c b/vl.c
index 7809a15caf..5694c23742 100644
--- a/vl.c
+++ b/vl.c
@@ -2143,6 +2143,10 @@ static void parse_display(const char *p)
dpy.has_gl = true;
if (strstart(opts, "on", &nextopt)) {
dpy.gl = DISPLAYGL_MODE_ON;
+} else if (strstart(opts, "core", &nextopt)) {
+dpy.gl = DISPLAYGL_MODE_CORE;
+} else if (strstart(opts, "es", &nextopt)) {
+dpy.gl = DISPLAYGL_MODE_ES;
} else if (strstart(opts, "off", &nextopt)) {
dpy.gl = DISPLAYGL_MODE_OFF;
} else {
--
2.17.0
[Qemu-devel] [PATCH v2 1/2] qapi: Parameter gl of DisplayType now accept an enum
Signed-off-by: Elie Tournier
---
qapi/ui.json | 21 -
vl.c | 10 +-
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/qapi/ui.json b/qapi/ui.json
index 5d01ad4304..c8005867e5 100644
--- a/qapi/ui.json
+++ b/qapi/ui.json
@@ -1019,6 +1019,25 @@
{ 'struct' : 'DisplayGTK',
'data': { '*grab-on-hover' : 'bool' } }
+ ##
+ # @DisplayGLMode:
+ #
+ # Display OpenGL mode.
+ #
+ # 'off' Disable OpenGL (default).
+ # 'on'Use OpenGL, pick context type automatically.
+ # Would better be named 'auto' but is called 'on' for backward
+ # compatibility with bool type.
+ # 'core' Use OpenGL with Core (desktop) Context.
+ # 'es'Use OpenGL with ES (embedded systems) Context.
+ #
+ # Since: 2.13
+ #
+ ##
+ { 'enum': 'DisplayGLMode',
+ 'data': [ 'off', 'on', 'core', 'es' ] }
+
+
##
# @DisplayType:
#
@@ -1048,7 +1067,7 @@
'base': { 'type' : 'DisplayType',
'*full-screen' : 'bool',
'*window-close' : 'bool',
-'*gl': 'bool' },
+'*gl': 'DisplayGLMode' },
'discriminator' : 'type',
'data': { 'default': 'DisplayNoOpts',
'none' : 'DisplayNoOpts',
diff --git a/vl.c b/vl.c
index fce1fd12d8..7809a15caf 100644
--- a/vl.c
+++ b/vl.c
@@ -2142,9 +2142,9 @@ static void parse_display(const char *p)
opts = nextopt;
dpy.has_gl = true;
if (strstart(opts, "on", &nextopt)) {
-dpy.gl = true;
+dpy.gl = DISPLAYGL_MODE_ON;
} else if (strstart(opts, "off", &nextopt)) {
-dpy.gl = false;
+dpy.gl = DISPLAYGL_MODE_OFF;
} else {
goto invalid_sdl_args;
}
@@ -2185,9 +2185,9 @@ static void parse_display(const char *p)
opts = nextopt;
dpy.has_gl = true;
if (strstart(opts, "on", &nextopt)) {
-dpy.gl = true;
+dpy.gl = DISPLAYGL_MODE_ON;
} else if (strstart(opts, "off", &nextopt)) {
-dpy.gl = false;
+dpy.gl = DISPLAYGL_MODE_OFF;
} else {
goto invalid_gtk_args;
}
@@ -4343,7 +4343,7 @@ int main(int argc, char **argv, char **envp)
qemu_display_early_init(&dpy);
qemu_console_early_init();
-if (dpy.has_gl && dpy.gl && display_opengl == 0) {
+if (dpy.has_gl && !dpy.gl == DISPLAYGL_MODE_OFF && display_opengl == 0) {
#if defined(CONFIG_OPENGL)
error_report("OpenGL is not supported by the display");
#else
--
2.17.0
