[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 5892b5: memfd: fix configure test
|
From: |
GitHub |
|
Subject: |
[Qemu-commits] [qemu/qemu] 5892b5: memfd: fix configure test |
|
Date: |
Wed, 27 Jun 2018 09:56:11 -0700 |
Branch: refs/heads/stable-2.11
Home: https://github.com/qemu/qemu
Commit: 5892b5a9e3189205f37257c71fe41bdc3569d441
https://github.com/qemu/qemu/commit/5892b5a9e3189205f37257c71fe41bdc3569d441
Author: Paolo Bonzini <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M configure
M util/memfd.c
Log Message:
-----------
memfd: fix configure test
Recent glibc added memfd_create in sys/mman.h. This conflicts with
the definition in util/memfd.c:
/builddir/build/BUILD/qemu-2.11.0-rc1/util/memfd.c:40:12: error: static
declaration of memfd_create follows non-static declaration
Fix the configure test, and remove the sys/memfd.h inclusion since the
file actually does not exist---it is a typo in the memfd_create(2) man
page.
Cc: Marc-André Lureau <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 75e5b70e6b5dcc4f2219992d7cffa462aa406af0)
Signed-off-by: Greg Kurz <address@hidden>
Commit: 0a30cae50a2f9d316c69ae1559b0a2b222de54e7
https://github.com/qemu/qemu/commit/0a30cae50a2f9d316c69ae1559b0a2b222de54e7
Author: Gerd Hoffmann <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M configure
Log Message:
-----------
sdl: workaround bug in sdl 2.0.8 headers
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892087
Signed-off-by: Gerd Hoffmann <address@hidden>
Reviewed-by: Daniel P. Berrangé <address@hidden>
Message-id: address@hidden
(cherry picked from commit 2ca5c43091324a68772dc348cdf157c63888c168)
Signed-off-by: Greg Kurz <address@hidden>
Commit: ad484114d18d7d82cee83f870825cb395339d071
https://github.com/qemu/qemu/commit/ad484114d18d7d82cee83f870825cb395339d071
Author: David Gibson <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: Allow some cases where we can't set VSMT mode in the kernel
At present if we require a vsmt mode that's not equal to the kernel's
default, and the kernel doesn't let us change it (e.g. because it's an old
kernel without support) then we always fail.
But in fact we can cope with the kernel having a different vsmt as long as
a) it's >= the actual number of vthreads/vcore (so that guest threads
that are supposed to be on the same core act like it)
b) it's a submultiple of the requested vsmt mode (so that guest threads
spaced by the vsmt value will act like they're on different cores)
Allowing this case gives us a bit more freedom to adjust the vsmt behaviour
without breaking existing cases.
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Tested-by: Greg Kurz <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit 1f20f2e0ee61d91abff4e86ed1cda1b5244647d3)
Signed-off-by: Greg Kurz <address@hidden>
Commit: af65bce4095aa1791a696d5f54020bb145d24dd0
https://github.com/qemu/qemu/commit/af65bce4095aa1791a696d5f54020bb145d24dd0
Author: David Gibson <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: Adjust default VSMT value for better migration compatibility
fa98fbfc "PC: KVM: Support machine option to set VSMT mode" introduced the
"vsmt" parameter for the pseries machine type, which controls the spacing
of the vcpu ids of thread 0 for each virtual core. This was done to bring
some consistency and stability to how that was done, while still allowing
backwards compatibility for migration and otherwise.
The default value we used for vsmt was set to the max of the host's
advertised default number of threads and the number of vthreads per vcore
in the guest. This was done to continue running without extra parameters
on older KVM versions which don't allow the VSMT value to be changed.
Unfortunately, even that smaller than before leakage of host configuration
into guest visible configuration still breaks things. Specifically a guest
with 4 (or less) vthread/vcore will get a different vsmt value when
running on a POWER8 (vsmt==8) and POWER9 (vsmt==4) host. That means the
vcpu ids don't line up so you can't migrate between them, though you should
be able to.
Long term we really want to make vsmt == smp_threads for sufficiently
new machine types. However, that means that qemu will then require a
sufficiently recent KVM (one which supports changing VSMT) - that's still
not widely enough deployed to be really comfortable to do.
In the meantime we need some default that will work as often as
possible. This patch changes that default to 8 in all circumstances.
This does change guest visible behaviour (including for existing
machine versions) for many cases - just not the most common/important
case.
Following is case by case justification for why this is still the least
worst option. Note that any of the old behaviours can still be duplicated
after this patch, it's just that it requires manual intervention by
setting the vsmt property on the command line.
KVM HV on POWER8 host:
This is the overwhelmingly common case in production setups, and is
unchanged by design. POWER8 hosts will advertise a default VSMT mode
of 8, and > 8 vthreads/vcore isn't permitted
KVM HV on POWER7 host:
Will break, but POWER7s allowing KVM were never released to the public.
KVM HV on POWER9 host:
Not yet released to the public, breaking this now will reduce other
breakage later.
KVM HV on PowerPC 970:
Will theoretically break it, but it was barely supported to begin with
and already required various user visible hacks to work. Also so old
that I just don't care.
TCG:
This is the nastiest one; it means migration of TCG guests (without
manual vsmt setting) will break. Since TCG is rarely used in production
I think this is worth it for the other benefits. It does also remove
one more barrier to TCG<->KVM migration which could be interesting for
debugging applications.
KVM PR:
As with TCG, this will break migration of existing configurations,
without adding extra manual vsmt options. As with TCG, it is rare in
production so I think the benefits outweigh breakages.
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Reviewed-by: Jose Ricardo Ziviani <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
(cherry picked from commit 8904e5a75005fe579c28806003892d8ae4a27dfa)
Signed-off-by: Greg Kurz <address@hidden>
Commit: c30b366d00a6c56a58b3d71ed7746d62b8aa82cd
https://github.com/qemu/qemu/commit/c30b366d00a6c56a58b3d71ed7746d62b8aa82cd
Author: Laurent Vivier <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: set vsmt to MAX(8, smp_threads)
We ignore silently the value of smp_threads when we set
the default VSMT value, and if smp_threads is greater than VSMT
kernel is going into trouble later.
Fixes: 8904e5a750
("spapr: Adjust default VSMT value for better migration compatibility")
Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 4ad64cbd0c3f9df15be5f7d1c920285551e802ca)
Signed-off-by: Greg Kurz <address@hidden>
Commit: cc86c467587bae3c742a7294fac64cb5d5588854
https://github.com/qemu/qemu/commit/cc86c467587bae3c742a7294fac64cb5d5588854
Author: Greg Kurz <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: use spapr->vsmt to compute VCPU ids
Since the introduction of VSMT in 2.11, the spacing of VCPU ids
between cores is controllable through a machine property instead
of being only dictated by the SMT mode of the host:
cpu->vcpu_id = (cc->core_id * spapr->vsmt / smp_threads) + i
Until recently, the machine code would try to change the SMT mode
of the host to be equal to VSMT or exit. This allowed the rest of
the code to assume that kvmppc_smt_threads() == spapr->vsmt is
always true.
Recent commit "8904e5a75005 spapr: Adjust default VSMT value for
better migration compatibility" relaxed the rule. If the VSMT
mode cannot be set in KVM for some reasons, but the requested
CPU topology is compatible with the current SMT mode, then we
let the guest run with kvmppc_smt_threads() != spapr->vsmt.
This breaks quite a few places in the code, in particular when
calculating DRC indexes.
This is what happens on a POWER host with subcores-per-core=2 (ie,
supports up to SMT4) when passing the following topology:
-smp threads=4,maxcpus=16 \
-device host-spapr-cpu-core,core-id=4,id=core1 \
-device host-spapr-cpu-core,core-id=8,id=core2
qemu-system-ppc64: warning: Failed to set KVM's VSMT mode to 8 (errno -22)
This is expected since KVM is limited to SMT4, but the guest is started
anyway because this topology can run on SMT4 even with a VSMT8 spacing.
But when we look at the DT, things get nastier:
cpus {
...
ibm,drc-indexes = <0x4 0x10000000 0x10000004 0x10000008 0x1000000c>;
This means that we have the following association:
CPU core device | DRC | VCPU id
-----------------+------------+---------
boot core | 0x10000000 | 0
core1 | 0x10000004 | 4
core2 | 0x10000008 | 8
core3 | 0x1000000c | 12
But since the spacing of VCPU ids is 8, the DRC for core1 points to a
VCPU that doesn't exist, the DRC for core2 points to the first VCPU of
core1 and and so on...
...
PowerPC,address@hidden {
...
ibm,my-drc-index = <0x10000000>;
...
};
PowerPC,address@hidden {
...
ibm,my-drc-index = <0x10000008>;
...
};
PowerPC,address@hidden {
...
No ibm,my-drc-index property for this core since 0x10000010 doesn't
exist in ibm,drc-indexes above.
...
};
};
...
interrupt-controller {
...
ibm,interrupt-server-ranges = <0x0 0x10>;
With a spacing of 8, the highest VCPU id for the given topology should be:
16 * 8 / 4 = 32 and not 16
...
linux,phandle = <0x7e7323b8>;
interrupt-controller;
};
And CPU hot-plug/unplug is broken:
(qemu) device_del core1
pseries-hotplug-cpu: Cannot find CPU (drc index 10000004) to remove
(qemu) device_del core2
cpu 4 (hwid 8) Ready to die...
cpu 5 (hwid 9) Ready to die...
cpu 6 (hwid 10) Ready to die...
cpu 7 (hwid 11) Ready to die...
These are the VCPU ids of core1 actually
(qemu) device_add host-spapr-cpu-core,core-id=12,id=core3
(qemu) device_del core3
pseries-hotplug-cpu: Cannot find CPU (drc index 1000000c) to remove
This patches all the code in hw/ppc/spapr.c to assume the VSMT
spacing when manipulating VCPU ids.
Fixes: 8904e5a75005
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 72194664c8a16b67865eb95054f984dd169cfa86)
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Commit: a8074a58951b04ed40d824dd837d7771ba7f08cb
https://github.com/qemu/qemu/commit/a8074a58951b04ed40d824dd837d7771ba7f08cb
Author: Greg Kurz <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
M hw/ppc/spapr_cpu_core.c
M include/hw/ppc/spapr.h
Log Message:
-----------
spapr: move VCPU calculation to core machine code
The VCPU ids are currently computed and assigned to each individual
CPU threads in spapr_cpu_core_realize(). But the numbering logic
of VCPU ids is actually a machine-level concept, and many places
in hw/ppc/spapr.c also have to compute VCPU ids out of CPU indexes.
The current formula used in spapr_cpu_core_realize() is:
vcpu_id = (cc->core_id * spapr->vsmt / smp_threads) + i
where:
cc->core_id is a multiple of smp_threads
cpu_index = cc->core_id + i
0 <= i < smp_threads
So we have:
cpu_index % smp_threads == i
cc->core_id / smp_threads == cpu_index / smp_threads
hence:
vcpu_id =
(cpu_index / smp_threads) * spapr->vsmt + cpu_index % smp_threads;
This formula was used before VSMT at the time VCPU ids where computed
at the target emulation level. It has the advantage of being useable
to derive a VPCU id out of a CPU index only. It is fitted for all the
places where the machine code has to compute a VCPU id.
This patch introduces an accessor to set the VCPU id in a PowerPCCPU object
using the above formula. It is a first step to consolidate all the VCPU id
logic in a single place.
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 648edb64751ea0e550f36302fa66f9f11e480824)
Signed-off-by: Greg Kurz <address@hidden>
Commit: 8c0ec3c3989f059ab34a1c603f080e410e18eb29
https://github.com/qemu/qemu/commit/8c0ec3c3989f059ab34a1c603f080e410e18eb29
Author: David Gibson <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
M target/ppc/compat.c
M target/ppc/cpu.h
Log Message:
-----------
target/ppc: Clarify compat mode max_threads value
We recently had some discussions that were sidetracked for a while, because
nearly everyone misapprehended the purpose of the 'max_threads' field in
the compatiblity modes table. It's all about guest expectations, not host
expectations or support (that's handled elsewhere).
In an attempt to avoid a repeat of that confusion, rename the field to
'max_vthreads' and add an explanatory comment.
Signed-off-by: David Gibson <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Reviewed-by: Greg Kurz <address@hidden>
Reviewed-by: Jose Ricardo Ziviani <address@hidden>
(cherry picked from commit abbc124753896f72e3715813ea20dd1924202ff0)
Signed-off-by: Greg Kurz <address@hidden>
Commit: 094706e69f12398c3ad5221c2cfc85410508d00c
https://github.com/qemu/qemu/commit/094706e69f12398c3ad5221c2cfc85410508d00c
Author: Greg Kurz <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
M include/hw/ppc/spapr.h
Log Message:
-----------
spapr: rename spapr_vcpu_id() to spapr_get_vcpu_id()
The spapr_vcpu_id() function is an accessor actually. Let's rename it
for symmetry with the recently added spapr_set_vcpu_id() helper.
The motivation behind this is that a later patch will consolidate
the VCPU id formula in a function and spapr_vcpu_id looks like an
appropriate name.
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 14bb4486c819ea797a151b3e0fe53d6f5c7b3fc5)
Signed-off-by: Greg Kurz <address@hidden>
Commit: e676038e606eb3daddd5bd18f7896921e3bc1e7d
https://github.com/qemu/qemu/commit/e676038e606eb3daddd5bd18f7896921e3bc1e7d
Author: Greg Kurz <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: consolidate the VCPU id numbering logic in a single place
Several places in the code need to calculate a VCPU id:
(cpu_index / smp_threads) * spapr->vsmt + cpu_index % smp_threads
(core_id / smp_threads) * spapr->vsmt (1 user)
index * spapr->vsmt (2 users)
or guess that the VCPU id of a given VCPU is the first thread of a virtual
core:
index % spapr->vsmt != 0
Even if the numbering logic isn't that complex, it is rather fragile to
have these assumptions open-coded in several places. FWIW this was
proved with recent issues related to VSMT.
This patch moves the VCPU id formula to a single function to be called
everywhere the code needs to compute one. It also adds an helper to
guess if a VCPU is the first thread of a VCORE.
Signed-off-by: Greg Kurz <address@hidden>
[dwg: Rename spapr_is_vcore() to spapr_is_thread0_in_vcore() for clarity]
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 5d0fb1508e2d279da74ef4a103e8def9b52c6304)
Signed-off-by: Greg Kurz <address@hidden>
Commit: 184da186db4630c95ce18fea94374350b3d9408e
https://github.com/qemu/qemu/commit/184da186db4630c95ce18fea94374350b3d9408e
Author: Greg Kurz <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: fix missing CPU core nodes in DT when running with TCG
Commit 5d0fb1508e2d "spapr: consolidate the VCPU id numbering logic
in a single place" introduced a helper to detect thread0 of a virtual
core based on its VCPU id. This is used to create CPU core nodes in
the DT, but it is broken in TCG.
$ qemu-system-ppc64 -nographic -accel tcg -machine dumpdtb=dtb.bin \
-smp cores=16,maxcpus=16,threads=1
$ dtc -f -O dts dtb.bin | grep POWER8
PowerPC,address@hidden {
PowerPC,address@hidden {
instead of the expected 16 cores that we get with KVM:
$ dtc -f -O dts dtb.bin | grep POWER8
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
PowerPC,address@hidden {
This happens because spapr_get_vcpu_id() maps VCPU ids to
cs->cpu_index in TCG mode. This confuses the code in
spapr_is_thread0_in_vcore(), since it assumes thread0 VCPU
ids to have a spapr->vsmt spacing.
spapr_get_vcpu_id(cpu) % spapr->vsmt == 0
Actually, there's no real reason to expose cs->cpu_index instead
of the VCPU id, since we also generate it with TCG. Also we already
set it explicitly in spapr_set_vcpu_id(), so there's no real reason
either to call kvm_arch_vcpu_id() with KVM.
This patch unifies spapr_get_vcpu_id() to always return the computed
VCPU id both in TCG and KVM. This is one step forward towards KVM<->TCG
migration.
Fixes: 5d0fb1508e2d
Reported-by: Cédric Le Goater <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit b1a568c1c2192f090536b8ac76d135ce1f46a0ee)
Signed-off-by: Greg Kurz <address@hidden>
Commit: 72cc467aabd1a2a51baa9406aa331b3142997f18
https://github.com/qemu/qemu/commit/72cc467aabd1a2a51baa9406aa331b3142997f18
Author: Greg Kurz <address@hidden>
Date: 2018-05-22 (Tue, 22 May 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: register dummy ICPs later
Some older machine types create more ICPs than needed. We hence
need to register up to xics_max_server_number() dummy ICPs to
accomodate the migration of these machine types.
Recent VSMT rework changed xics_max_server_number() to return
DIV_ROUND_UP(max_cpus * spapr->vsmt, smp_threads)
instead of
DIV_ROUND_UP(max_cpus * kvmppc_smt_threads(), smp_threads);
The change is okay but it requires spapr->vsmt to be set, which
isn't the case with the current code. This causes the formula to
return zero and we don't create dummy ICPs. This breaks migration
of older guests as reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=1549087
The dummy ICP workaround doesn't really have a dependency on XICS
itself. But it does depend on proper VCPU id numbering and it must
be applied before creating vCPUs (ie, creating real ICPs). So this
patch moves the workaround to spapr_init_cpus(), which already
assumes VSMT to be set.
Fixes: 72194664c8a1 ("spapr: use spapr->vsmt to compute VCPU ids")
Reported-by: Lukas Doktor <address@hidden>
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 72fdd4de8e5fdc1a6078e000835fb54592a3fe97)
Signed-off-by: Greg Kurz <address@hidden>
Commit: 82c5191f9c820a9500fa29904e96067b1c394dfc
https://github.com/qemu/qemu/commit/82c5191f9c820a9500fa29904e96067b1c394dfc
Author: Murilo Opsfelder Araujo <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block/ssh.c
Log Message:
-----------
block/ssh: fix possible segmentation fault when .desc is not null-terminated
This patch prevents a possible segmentation fault when .desc members are checked
against NULL.
The ssh_runtime_opts was added by commit
8a6a80896d6af03b8ee0c17cdf37219eca2588a7 ("block/ssh: Use QemuOpts for runtime
options").
This fix was inspired by
http://lists.nongnu.org/archive/html/qemu-devel/2018-01/msg00883.html.
Fixes: 8a6a80896d6af03b8ee0c17cdf37219eca2588a7 ("block/ssh: Use QemuOpts for
runtime options")
Cc: Max Reitz <address@hidden>
Cc: Eric Blake <address@hidden>
Signed-off-by: Murilo Opsfelder Araujo <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit fbd5c4c0db47e578e3fdd88a0ebc4314a1ed3d42)
Signed-off-by: Michael Roth <address@hidden>
Commit: c3c44a4fb00513f9a25090bc872bb145255509de
https://github.com/qemu/qemu/commit/c3c44a4fb00513f9a25090bc872bb145255509de
Author: Laszlo Ersek <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/pci-bridge/i82801b11.c
Log Message:
-----------
pci-bridge/i82801b11: clear bridge registers on platform reset
The "i82801b11-bridge" device model is a descendant of "base-pci-bridge"
(TYPE_PCI_BRIDGE). However, unlike other similar devices, such as
- pci-bridge,
- pcie-pci-bridge,
- PCIE Root Port,
- xio3130 switch upstream and downstream ports,
- dec-21154-p2p-bridge,
- pbm-bridge,
- xilinx-pcie-root,
"i82801b11-bridge" does not clear the bridge specific registers at
platform reset.
This is a problem because devices on "i82801b11-bridge" continue to
respond to config space cycles after platform reset, when addressed with
the bus number that was previously programmed into the secondary bus
number register of "i82801b11-bridge". This error breaks OVMF's search for
extra (PXB) root buses, for example.
The device class reset method for "i82801b11-bridge" is currently NULL;
set it directly to pci_bridge_reset(), like the last three bridge models
in the above listing do.
Cc: "Michael S. Tsirkin" <address@hidden>
Cc: Marcel Apfelbaum <address@hidden>
Cc: address@hidden
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1541839
Signed-off-by: Laszlo Ersek <address@hidden>
Reviewed-by: Marcel Apfelbaum <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit ed247f40db84c8bd4bb7d10948702cd47cc4d5ae)
Signed-off-by: Michael Roth <address@hidden>
Commit: b940928fa06d766ff354e7d7d204587b5b8d78fe
https://github.com/qemu/qemu/commit/b940928fa06d766ff354e7d7d204587b5b8d78fe
Author: Tiwei Bie <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/virtio/virtio-balloon.c
Log Message:
-----------
virtio-balloon: unref the memory region before continuing
Signed-off-by: Tiwei Bie <address@hidden>
Cc: address@hidden
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit b86107ab43b804e899a226fe287e34ab8acef596)
Signed-off-by: Michael Roth <address@hidden>
Commit: 327d4645a02a9625b3c21da26970f5ae2d9aa75f
https://github.com/qemu/qemu/commit/327d4645a02a9625b3c21da26970f5ae2d9aa75f
Author: Greg Kurz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/ppc/spapr.c
M tests/boot-serial-test.c
M tests/migration-test.c
M tests/prom-env-test.c
M tests/pxe-test.c
Log Message:
-----------
spapr: make pseries-2.11 the default machine type
The spapr capability framework was introduced in QEMU 2.12. It allows
to have an explicit control on how host features are exposed to the
guest. This is especially needed to handle migration between hetero-
geneous hosts (eg, POWER8 to POWER9). It is also used to expose fixes/
workarounds against speculative execution vulnerabilities to guests.
The framework was hence backported to QEMU 2.11.1, especially these
commits:
0fac4aa93074 spapr: Add pseries-2.12 machine type
9070f408f491 spapr: Treat Hardware Transactional Memory (HTM) as an
optional capability
0fac4aa93074 has the confusing effect of making pseries-2.12 the default
machine type for QEMU 2.11.1, instead of the expected pseries-2.11. This
patch changes the default machine back to pseries-2.11.
Unfortunately, 9070f408f491 enforces the HTM capability for pseries-2.11
to be enabled by default, ie, when not passing cap-htm on the command
line. This breaks several 'make check' testcases that run qemu-system-ppc64
with TCG.
The only sane way to fix this is to adapt the impacted testcases so that
they all pass cap-htm=off in this case. This patch does that as well.
Signed-off-by: Greg Kurz <address@hidden>
Reviewed-by: David Gibson <address@hidden>
Signed-off-by: Michael Roth <address@hidden>
Commit: 0430aa089cb5614549f4c3897035a57a7d4afdc2
https://github.com/qemu/qemu/commit/0430aa089cb5614549f4c3897035a57a7d4afdc2
Author: Eric Blake <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block/nbd-client.c
M block/nbd.c
Log Message:
-----------
nbd: Honor server's advertised minimum block size
Commit 79ba8c98 (v2.7) changed the setting of request_alignment
to occur only during bdrv_refresh_limits(), rather than at at
bdrv_open() time; but at the time, NBD was unaffected, because
it still used sector-based callbacks, so the block layer
defaulted NBD to use 512 request_alignment.
Later, commit 70c4fb26 (also v2.7) changed NBD to use byte-based
callbacks, without setting request_alignment. This resulted in
NBD using request_alignment of 1, which works great when the
server supports it (as is the case for qemu-nbd), but falls apart
miserably if the server requires alignment (but only if qemu
actually sends a sub-sector request; qemu-io can do it, but
most qemu operations still perform on sectors or larger).
Even later, the NBD protocol was updated to document that clients
should learn the server's minimum alignment during NBD_OPT_GO;
and recommended that clients should assume a minimum size of 512
unless the server understands NBD_OPT_GO and replied with a smaller
size. Commit 081dd1fe (v2.10) attempted to do that, by assigning
request_alignment to whatever was learned from the server; but
it has two flaws: the assignment is done during bdrv_open() so
it gets unconditionally wiped out back to 1 during any later
bdrv_refresh_limits(); and the code is not using a default of 512
when the server did not report a minimum size.
Fix these issues by moving the assignment to request_alignment
to the right function, and by using a sane default when the
server does not advertise a minimum size.
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy<address@hidden>
(cherry picked from commit fd8d372dd36e839568a718684914d9960d8b1ebd)
Signed-off-by: Michael Roth <address@hidden>
Commit: 6f36bd3969353c0a47fd71bb6713a24ebce940eb
https://github.com/qemu/qemu/commit/6f36bd3969353c0a47fd71bb6713a24ebce940eb
Author: Alberto Garcia <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M docs/interop/qcow2.txt
Log Message:
-----------
specs/qcow2: Fix documentation of the compressed cluster descriptor
This patch fixes several mistakes in the documentation of the
compressed cluster descriptor:
1) the documentation claims that the cluster descriptor contains the
number of sectors used to store the compressed data, but what it
actually contains is the number of sectors *minus one* or, in other
words, the number of additional sectors after the first one.
2) the width of the fields is incorrectly specified. The number of bits
used by each field is
x = 62 - (cluster_bits - 8) for the offset field
y = (cluster_bits - 8) for the size field
So the offset field's location is [0, x-1], not [0, x] as stated.
3) the size field does not contain the size of the compressed data,
but rather the number of sectors where that data is stored. The
compressed data starts at the exact point specified in the offset
field and ends when there's enough data to produce a cluster of
decompressed data. Both points can be in the middle of a sector,
allowing several compressed clusters to be stored next to one
another, sharing sectors if necessary.
Cc: address@hidden
Signed-off-by: Alberto Garcia <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 156b46ded3853dfc6b34c5afae019ff61798491b)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4f81878152ac50743e94365a68e4204db71362b2
https://github.com/qemu/qemu/commit/4f81878152ac50743e94365a68e4204db71362b2
Author: Kevin Wolf <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block/rbd.c
Log Message:
-----------
rbd: Fix use after free in qemu_rbd_set_keypairs() error path
If we want to include the invalid option name in the error message, we
can't free the string earlier than that.
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
(cherry picked from commit 71c87815f9e0386b6f3e22942adc956fd603c82f)
Signed-off-by: Michael Roth <address@hidden>
Commit: e2fc495b4a8378d9bde17d0bc7293b5c66c4970b
https://github.com/qemu/qemu/commit/e2fc495b4a8378d9bde17d0bc7293b5c66c4970b
Author: Stefan Berger <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/tpm/tpm_emulator.c
Log Message:
-----------
tpm: Set the flags of the CMD_INIT command to 0
The flags of the CMD_INIT control channel command were not
initialized properly. Fix this and set to 0.
Signed-off-by: Stefan Berger <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
(cherry picked from commit 302705876492a39f568035ce346e2c9176f5665e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1f4637953e29bd01360dbb97ee2312e8e72f2a9d
https://github.com/qemu/qemu/commit/1f4637953e29bd01360dbb97ee2312e8e72f2a9d
Author: Mark Cave-Ayland <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/core/loader.c
Log Message:
-----------
loader: don't perform overlapping address check for memory region ROM images
All memory region ROM images have a base address of 0 which causes the
overlapping
address check to fail if more than one memory region ROM image is present, or an
existing ROM image is loaded at address 0.
Make sure that we ignore the overlapping address check in
rom_check_and_register_reset() if this is a memory region ROM image. In
particular
this fixes the "rom: requested regions overlap" error on startup when trying to
run qemu-system-sparc with a -kernel image since commit 7497638642: "tcx:
switch to
load_image_mr() and remove prom_addr hack".
Suggested-by: Peter Maydell <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Mark Cave-Ayland <address@hidden>
(cherry picked from commit ca316c11526a1bc221fb542bdce6bac7238dde69)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2ac88347fa354e4bd4057be1dbf498cfa70304ff
https://github.com/qemu/qemu/commit/2ac88347fa354e4bd4057be1dbf498cfa70304ff
Author: Max Filippov <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/xtensa/translate.c
Log Message:
-----------
target/xtensa: dump correct physical registers
xtensa_cpu_dump_state outputs CPU physical registers as is, without
synchronization from current window. That may result in different values
printed for the current window and corresponding physical registers.
Synchronize physical registers from window before dumping.
Cc: address@hidden
Signed-off-by: Max Filippov <address@hidden>
(cherry picked from commit b55b1afda942306e4e40420aced1524bd83ba16d)
Conflicts:
target/xtensa/translate.c
* drop context dependencies
Signed-off-by: Michael Roth <address@hidden>
Commit: 1801fabd9b287e2c0a1fe50bc6c6039c9eb17820
https://github.com/qemu/qemu/commit/1801fabd9b287e2c0a1fe50bc6c6039c9eb17820
Author: Max Filippov <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M include/exec/cpu-all.h
M include/exec/cpu_ldst.h
M linux-user/mmap.c
M linux-user/syscall.c
Log Message:
-----------
linux-user: fix mmap/munmap/mprotect/mremap/shmat
In linux-user QEMU that runs for a target with TARGET_ABI_BITS bigger
than L1_MAP_ADDR_SPACE_BITS an assertion in page_set_flags fires when
mmap, munmap, mprotect, mremap or shmat is called for an address outside
the guest address space. mmap and mprotect should return ENOMEM in such
case.
Change definition of GUEST_ADDR_MAX to always be the last valid guest
address. Account for this change in open_self_maps.
Add macro guest_addr_valid that verifies if the guest address is valid.
Add function guest_range_valid that verifies if address range is within
guest address space and does not wrap around. Use that macro in
mmap/munmap/mprotect/mremap/shmat for error checking.
Cc: address@hidden
Cc: Riku Voipio <address@hidden>
Cc: Laurent Vivier <address@hidden>
Signed-off-by: Max Filippov <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>
(cherry picked from commit ebf9a3630c911d0cfc9c20f7cafe9ba4f88cf583)
Signed-off-by: Michael Roth <address@hidden>
Commit: 8fc971ed1b44f7910a5ee928acccb3a70156c237
https://github.com/qemu/qemu/commit/8fc971ed1b44f7910a5ee928acccb3a70156c237
Author: Max Filippov <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M linux-user/syscall.c
Log Message:
-----------
linux-user: fix assertion in shmdt
shmdt fails to call mmap_lock/mmap_unlock around page_set_flags,
resulting in the following assertion:
page_set_flags: Assertion `have_mmap_lock()' failed.
Wrap shmdt internals into mmap_lock/mmap_unlock.
Cc: address@hidden
Cc: Riku Voipio <address@hidden>
Cc: Laurent Vivier <address@hidden>
Signed-off-by: Max Filippov <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>
(cherry picked from commit 3c5f6a5f888729f9fbc64211298f7c3e2fb42b64)
Signed-off-by: Michael Roth <address@hidden>
Commit: e1f5a04d17d88ee490408766dfdaa814ab91895f
https://github.com/qemu/qemu/commit/e1f5a04d17d88ee490408766dfdaa814ab91895f
Author: Max Filippov <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M linux-user/mmap.c
Log Message:
-----------
linux-user: fix target_mprotect/target_munmap error return values
target_mprotect/target_munmap return value goes through get_errno at the
call site, thus the functions must either set errno to host error code
and return -1 or return negative guest error code. Do the latter.
Cc: address@hidden
Cc: Riku Voipio <address@hidden>
Cc: Laurent Vivier <address@hidden>
Signed-off-by: Max Filippov <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>
(cherry picked from commit 78cf339039c325b336442f1d7f3ccc531b22c4a0)
Signed-off-by: Michael Roth <address@hidden>
Commit: 499211829d4bb85aab018dfe2c42d9e9881c3690
https://github.com/qemu/qemu/commit/499211829d4bb85aab018dfe2c42d9e9881c3690
Author: KONRAD Frederic <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/sparc/translate.c
Log Message:
-----------
sparc: fix leon3 casa instruction when MMU is disabled
Since the commit af7a06bac7d3abb2da48ef3277d2a415772d2ae8:
`casa [..](10), .., ..` (and probably others alternate space instructions)
triggers a data access exception when the MMU is disabled.
When we enter get_asi(...) dc->mem_idx is set to MMU_PHYS_IDX when the MMU
is disabled. Just keep mem_idx unchanged in this case so we passthrough the
MMU when it is disabled.
Signed-off-by: KONRAD Frederic <address@hidden>
Signed-off-by: Mark Cave-Ayland <address@hidden>
(cherry picked from commit 6e10f37c86068e35151f982c976a85f1bec07ef2)
Signed-off-by: Michael Roth <address@hidden>
Commit: 8e8b73992c18f7a4b9aba80eca791b9c1c0267d8
https://github.com/qemu/qemu/commit/8e8b73992c18f7a4b9aba80eca791b9c1c0267d8
Author: Paolo Bonzini <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/intc/openpic_kvm.c
Log Message:
-----------
openpic_kvm: drop address_space_to_flatview call
The MemoryListener is registered on address_space_memory, there is
not much to assert. This currently works because the callback
is invoked only once when the listener is registered, but section->fv
is the _new_ FlatView, not the old one on later calls and that
would break.
This confines address_space_to_flatview to exec.c and memory.c.
Acked-by: David Gibson <address@hidden>
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 80d2b933f9fe3e53d4f76a45a1bc1a0175669468)
Signed-off-by: Michael Roth <address@hidden>
Commit: ac25a3257ffcf563ffb47f5c4a6b2b2804bea9d0
https://github.com/qemu/qemu/commit/ac25a3257ffcf563ffb47f5c4a6b2b2804bea9d0
Author: Paolo Bonzini <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M include/exec/memory-internal.h
M include/exec/memory.h
M memory.c
Log Message:
-----------
memory: inline some performance-sensitive accessors
These accessors are called from inlined functions, and the call sequence
is much more expensive than just inlining the access. Move the
struct declaration to memory-internal.h so that exec.c and memory.c
can both use an inline function.
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 785a507ec78bbda1c346f3d3593e5a58b62e73ef)
Signed-off-by: Michael Roth <address@hidden>
Commit: df04d1f16ae58a4eee0f64476667f2fd6c1d6d30
https://github.com/qemu/qemu/commit/df04d1f16ae58a4eee0f64476667f2fd6c1d6d30
Author: Paolo Bonzini <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M exec.c
Log Message:
-----------
address_space_write: address_space_to_flatview needs RCU lock
address_space_write is calling address_space_to_flatview but it can
be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock
pair up from flatview_write to address_space_write.
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 4c6ebbb364aa6f42c5d8e83e932e967eb83f0e44)
Signed-off-by: Michael Roth <address@hidden>
Commit: f77c23120237b9e47607fc06531a4e2b40818e45
https://github.com/qemu/qemu/commit/f77c23120237b9e47607fc06531a4e2b40818e45
Author: Paolo Bonzini <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M exec.c
M include/exec/memory.h
Log Message:
-----------
address_space_read: address_space_to_flatview needs RCU lock
address_space_read is calling address_space_to_flatview but it can
be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock
pair up from flatview_read_full to address_space_read's constant size
fast path and address_space_read_full.
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit b2a44fcad74f1cc7a6786d38eba7db12ab2352ba)
Signed-off-by: Michael Roth <address@hidden>
Commit: fa876bc97a9d6f95c73db56587c64380aa282fe4
https://github.com/qemu/qemu/commit/fa876bc97a9d6f95c73db56587c64380aa282fe4
Author: Paolo Bonzini <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M exec.c
Log Message:
-----------
address_space_access_valid: address_space_to_flatview needs RCU lock
address_space_access_valid is calling address_space_to_flatview but it can
be called outside the RCU lock. To fix it, push the rcu_read_lock/unlock
pair up from flatview_access_valid to address_space_access_valid.
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 11e732a5ed46903f997985bed4c3767ca28a7eb6)
Signed-off-by: Michael Roth <address@hidden>
Commit: a7f4d8a105756a4ed9aa48a3853d4cba04bcfad7
https://github.com/qemu/qemu/commit/a7f4d8a105756a4ed9aa48a3853d4cba04bcfad7
Author: Paolo Bonzini <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M exec.c
Log Message:
-----------
address_space_map: address_space_to_flatview needs RCU lock
address_space_map is calling address_space_to_flatview but it can
be called outside the RCU lock. The function itself is calling
rcu_read_lock/rcu_read_unlock, just in the wrong place, so the
fix is easy.
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit ad0c60fa572d4050255b698ecdb67294dd4c0125)
Signed-off-by: Michael Roth <address@hidden>
Commit: aedaf01f8c8197823a21e76481c8e4de5cf257d3
https://github.com/qemu/qemu/commit/aedaf01f8c8197823a21e76481c8e4de5cf257d3
Author: Paolo Bonzini <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M exec.c
Log Message:
-----------
address_space_rw: address_space_to_flatview needs RCU lock
address_space_rw is calling address_space_to_flatview but it can
be called outside the RCU lock. To fix it, transform flatview_rw
into address_space_rw, since flatview_rw is otherwise unused.
Reviewed-by: Alexey Kardashevskiy <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit db84fd973eba3f1e121416dcab73a4e8a60f2526)
Signed-off-by: Michael Roth <address@hidden>
Commit: cebb7fea7cf10b347b8a76448788779ad32e63f8
https://github.com/qemu/qemu/commit/cebb7fea7cf10b347b8a76448788779ad32e63f8
Author: Paolo Bonzini <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M exec.c
Log Message:
-----------
memory: fix flatview_access_valid RCU read lock/unlock imbalance
Fixes: 11e732a5ed46903f997985bed4c3767ca28a7eb6
Reported-by: Cornelia Huck <address@hidden>
Reported-by: luigi burdo <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
Tested-by: Cornelia Huck <address@hidden>
Tested-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit b39b61e410022f96ceb53d4381d25cba5126ac44)
Signed-off-by: Michael Roth <address@hidden>
Commit: ab2dfe8d17c3f0c5788c4d52d1265eb6bcb65550
https://github.com/qemu/qemu/commit/ab2dfe8d17c3f0c5788c4d52d1265eb6bcb65550
Author: Peter Lieven <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M migration/block.c
Log Message:
-----------
migration/block: reset dirty bitmap before read in bulk phase
Reset the dirty bitmap before reading to make sure we don't miss
any new data.
Cc: address@hidden
Signed-off-by: Peter Lieven <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Juan Quintela <address@hidden>
Signed-off-by: Dr. David Alan Gilbert <address@hidden>
(cherry picked from commit 86b124bc76bd7137d0fb20696c4e349571b8533d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 059a6962b2f8cc2560af82e66235b36304b53350
https://github.com/qemu/qemu/commit/059a6962b2f8cc2560af82e66235b36304b53350
Author: Jack Schwartz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/multiboot.c
Log Message:
-----------
multiboot: bss_end_addr can be zero
The multiboot spec (https://www.gnu.org/software/grub/manual/multiboot/),
section 3.1.3, allows for bss_end_addr to be zero.
A zero bss_end_addr signifies there is no .bss section.
Suggested-by: Daniel Kiper <address@hidden>
Signed-off-by: Jack Schwartz <address@hidden>
Reviewed-by: Daniel Kiper <address@hidden>
Reviewed-by: Prasad J Pandit <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 2a8fcd119eb7c6bb3837fc3669eb1b2dfb31daf8)
Signed-off-by: Michael Roth <address@hidden>
Commit: a030730621f9e3bd78ec97435aaa14048c86bb9c
https://github.com/qemu/qemu/commit/a030730621f9e3bd78ec97435aaa14048c86bb9c
Author: Jack Schwartz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/multiboot.c
Log Message:
-----------
multiboot: Remove unused variables from multiboot.c
Remove unused variables: mh_mode_type, mh_width, mh_height, mh_depth
Signed-off-by: Jack Schwartz <address@hidden>
Reviewed-by: Daniel Kiper <address@hidden>
Reviewed-by: Prasad J Pandit <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 7a2e43cc96fd017883973caf9ee076ae23a3bebd)
Signed-off-by: Michael Roth <address@hidden>
Commit: ddf965ef9d8a74794c129b7e9849e835606bd08e
https://github.com/qemu/qemu/commit/ddf965ef9d8a74794c129b7e9849e835606bd08e
Author: Jack Schwartz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/multiboot.c
Log Message:
-----------
multiboot: Use header names when displaying fields
Refer to field names when displaying fields in printf and debug statements.
Signed-off-by: Jack Schwartz <address@hidden>
Reviewed-by: Daniel Kiper <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit ce5eb6dc4dc5652f7e360a1db817f1d5dafab90f)
Signed-off-by: Michael Roth <address@hidden>
Commit: bbdcfd2dbcf447233aabb6768fe05e3861171665
https://github.com/qemu/qemu/commit/bbdcfd2dbcf447233aabb6768fe05e3861171665
Author: Jack Schwartz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/multiboot.c
Log Message:
-----------
multiboot: fprintf(stderr...) -> error_report()
Change all fprintf(stderr...) calls in hw/i386/multiboot.c to call
error_report() instead, including the mb_debug macro. Remove the "\n"
from strings passed to all modified calls, since error_report() appends
one.
Signed-off-by: Jack Schwartz <address@hidden>
Reviewed-by: Daniel Kiper <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 4b9006a41ea8818f2385ae5228e07f211bb4a33d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 31b0eb0dad3daef6cd9eef74bc107cb3367450e7
https://github.com/qemu/qemu/commit/31b0eb0dad3daef6cd9eef74bc107cb3367450e7
Author: Kevin Wolf <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/multiboot.c
Log Message:
-----------
multiboot: Reject kernels exceeding the address space
The code path where mh_load_end_addr is non-zero in the Multiboot
header checks that mh_load_end_addr >= mh_load_addr and so
mb_load_size is checked. However, mb_load_size is not checked when
calculated from the file size, when mh_load_end_addr is 0.
If the kernel binary size is larger than can fit in the address space
after load_addr, we ended up with a kernel_size that is smaller than
load_size, which means that we read the file into a too small buffer.
Add a check to reject kernel files with such Multiboot headers.
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Jack Schwartz <address@hidden>
(cherry picked from commit b17a9054a0652a1481be48a6729e972abf02412f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 32ccaed1ae047d5d71b2d74b4cb8212e643f7d27
https://github.com/qemu/qemu/commit/32ccaed1ae047d5d71b2d74b4cb8212e643f7d27
Author: Kevin Wolf <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/multiboot.c
Log Message:
-----------
multiboot: Check validity of mh_header_addr
I couldn't find a case where this prevents something bad from happening
that isn't already caught by other checks, but let's err on the safe
side and check that mh_header_addr is as expected.
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Jack Schwartz <address@hidden>
(cherry picked from commit dbf2dce7aabb7723542bd182175904846d70b0f9)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2392a86d2da12923754febe17d372b403fe3dcbe
https://github.com/qemu/qemu/commit/2392a86d2da12923754febe17d372b403fe3dcbe
Author: Kevin Wolf <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tests/multiboot/run_test.sh
Log Message:
-----------
tests/multiboot: Test exit code for every qemu run
Testing the exit code only once after a whole group of tests has
completed is not enough, it catches errors only in the very last qemu
invocation. We need to have the check after each qemu run.
The logging and diff with the reference output is still done once per
group to keep things more managable. This is not a problem because the
log file accumulates the output of all runs.
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Jack Schwartz <address@hidden>
(cherry picked from commit 49713c413a65ab4b02124aabe83f8539cc6ece5e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 678a75b8b58954af8bfd3830b60154213e1f7e37
https://github.com/qemu/qemu/commit/678a75b8b58954af8bfd3830b60154213e1f7e37
Author: Kevin Wolf <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tests/multiboot/Makefile
A tests/multiboot/aout_kludge.S
A tests/multiboot/aout_kludge.out
M tests/multiboot/run_test.sh
Log Message:
-----------
tests/multiboot: Add tests for the a.out kludge
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Jack Schwartz <address@hidden>
(cherry picked from commit 1c8c426fb44bf5b3ffbcad1b00c7def4b89b03ec)
Signed-off-by: Michael Roth <address@hidden>
Commit: 7c22c5a3a75fd767d8ebfd6abfbbee1a2bc962ee
https://github.com/qemu/qemu/commit/7c22c5a3a75fd767d8ebfd6abfbbee1a2bc962ee
Author: Kevin Wolf <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
A tests/multiboot/.gitignore
Log Message:
-----------
tests/multiboot: Add .gitignore
Signed-off-by: Kevin Wolf <address@hidden>
Reviewed-by: Jack Schwartz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
(cherry picked from commit e2679395d598bd40770c22a793c0152576ac211f)
Signed-off-by: Michael Roth <address@hidden>
Commit: a053477b7c6e5094247986de3aa2f0aa139cbb42
https://github.com/qemu/qemu/commit/a053477b7c6e5094247986de3aa2f0aa139cbb42
Author: Victor Kamensky <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/arm/translate-a64.c
Log Message:
-----------
arm/translate-a64: treat DISAS_UPDATE as variant of DISAS_EXIT
In OE project 4.15 linux kernel boot hang was observed under
single cpu aarch64 qemu. Kernel code was in a loop waiting for
vtimer arrival, spinning in TC generated blocks, while interrupt
was pending unprocessed. This happened because when qemu tried to
handle vtimer interrupt target had interrupts disabled, as
result flag indicating TCG exit, cpu->icount_decr.u16.high,
was cleared but arm_cpu_exec_interrupt function did not call
arm_cpu_do_interrupt to process interrupt. Later when target
reenabled interrupts, it happened without exit into main loop, so
following code that waited for result of interrupt execution
run in infinite loop.
To solve the problem instructions that operate on CPU sys state
(i.e enable/disable interrupt), and marked as DISAS_UPDATE,
should be considered as DISAS_EXIT variant, and should be
forced to exit back to main loop so qemu will have a chance
processing pending CPU state updates, including pending
interrupts.
This change brings consistency with how DISAS_UPDATE is treated
in aarch32 case.
CC: Peter Maydell <address@hidden>
CC: Alex Bennée <address@hidden>
CC: address@hidden
Suggested-by: Peter Maydell <address@hidden>
Signed-off-by: Victor Kamensky <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit a75a52d62418dafe462be4fe30485501d1010bb9)
Signed-off-by: Michael Roth <address@hidden>
Commit: db9c0d907e0121321e51c762bdc9e6b75ff57618
https://github.com/qemu/qemu/commit/db9c0d907e0121321e51c762bdc9e6b75ff57618
Author: Greg Kurz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/net/virtio-net.c
M include/net/net.h
M net/net.c
Log Message:
-----------
virtio_net: flush uncompleted TX on reset
If the backend could not transmit a packet right away for some reason,
the packet is queued for asynchronous sending. The corresponding vq
element is tracked in the async_tx.elem field of the VirtIONetQueue,
for later freeing when the transmission is complete.
If a reset happens before completion, virtio_net_tx_complete() will push
async_tx.elem back to the guest anyway, and we end up with the inuse flag
of the vq being equal to -1. The next call to virtqueue_pop() is then
likely to fail with "Virtqueue size exceeded".
This can be reproduced easily by starting a guest with an hubport backend
that is not connected to a functional network, eg,
-device virtio-net-pci,netdev=hub0 -netdev hubport,id=hub0,hubid=0
and no other -netdev hubport,hubid=0 on the command line.
The appropriate fix is to ensure that such an asynchronous transmission
cannot survive a device reset. So for all queues, we first try to send
the packet again, and eventually we purge it if the backend still could
not deliver it.
CC: address@hidden
Reported-by: R. Nageswara Sastry <address@hidden>
Buglink: https://github.com/open-power-host-os/qemu/issues/37
Signed-off-by: Greg Kurz <address@hidden>
Tested-by: R. Nageswara Sastry <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit 94b52958b77a2a040564cf7ed716d3a9545d94e5)
Signed-off-by: Michael Roth <address@hidden>
Commit: 332969a64dde88c6ed6319a8d909c2de94966282
https://github.com/qemu/qemu/commit/332969a64dde88c6ed6319a8d909c2de94966282
Author: Michal Privoznik <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M scsi/qemu-pr-helper.c
Log Message:
-----------
qemu-pr-helper: Actually allow users to specify pidfile
Due to wrong specification of arguments to getopt_long() any
attempt to set pidfile resulted in:
1) the default to be leaked
2) the @pidfile variable to be set to NULL (because optarg is
NULL without this patch).
Signed-off-by: Michal Privoznik <address@hidden>
Message-Id: <address@hidden>
Cc: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit f8e1a989644f22ba2f7afb0e13b6ce2309ea9503)
Signed-off-by: Michael Roth <address@hidden>
Commit: d315353bed0ee4f4a505b8c5fdf24dc63659ae92
https://github.com/qemu/qemu/commit/d315353bed0ee4f4a505b8c5fdf24dc63659ae92
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block/file-posix.c
Log Message:
-----------
block/file-posix: Fix fully preallocated truncate
Storing the lseek() result in an int results in it overflowing when the
file is at least 2 GB big. Then, we have a 50 % chance of the result
being "negative" and thus thinking an error occurred when actually
everything went just fine.
So we should use the correct type for storing the result: off_t.
Reported-by: Daniel P. Berrange <address@hidden>
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1549231
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 82b45e0a0b824787bd79ce3f6453eaa2afddd138)
Signed-off-by: Michael Roth <address@hidden>
Commit: c793a0debd54ac9e39b71a7e2f23b1d73e1ad040
https://github.com/qemu/qemu/commit/c793a0debd54ac9e39b71a7e2f23b1d73e1ad040
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tests/qemu-iotests/106
M tests/qemu-iotests/106.out
Log Message:
-----------
iotests: Test preallocated truncate of 2G image
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Daniel P. Berrangé <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 733d1dce0f3c8ab7b79a173f6482781d3718f844)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5aac5f6aeed01944e1b6acd03296a32b6c64570b
https://github.com/qemu/qemu/commit/5aac5f6aeed01944e1b6acd03296a32b6c64570b
Author: Richard Henderson <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tcg/tcg-opc.h
Log Message:
-----------
tcg: Mark muluh_i64 and mulsh_i64 as 64-bit ops
Failure to do so results in the tcg optimizer sign-extending
any constant fold from 32-bits. This turns out to be visible
in the RISC-V testsuite using a host that emits these opcodes
(e.g. any non-x86_64).
Reported-by: Michael Clark <address@hidden>
Reviewed-by: Emilio G. Cota <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Richard Henderson <address@hidden>
(cherry picked from commit f2f1dde75160cac6ede330f3db50dc817d01a2d6)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2b73d5d34800f5ce1b51fd9a70a51abf0077ce03
https://github.com/qemu/qemu/commit/2b73d5d34800f5ce1b51fd9a70a51abf0077ce03
Author: Alexandro Sanchez Bach <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/i386/translate.c
Log Message:
-----------
target/i386: Fix andn instruction
In commit 7073fbada733c8d10992f00772c9b9299d740e9b, the `andn` instruction
was implemented via `tcg_gen_andc` but passes the operands in the wrong
order:
- X86 defines `andn dest,src1,src2` as: dest = ~src1 & src2
- TCG defines `andc dest,src1,src2` as: dest = src1 & ~src2
The following simple test shows the issue:
#include <stdio.h>
#include <stdint.h>
int main(void) {
uint32_t ret = 0;
__asm (
"mov $0xFF00, %%ecx\n"
"mov $0x0F0F, %%eax\n"
"andn %%ecx, %%eax, %%ecx\n"
"mov %%ecx, %0\n"
: "=r" (ret));
printf("%08X\n", ret);
return 0;
}
This patch fixes the problem by simply swapping the order of the two last
arguments in `tcg_gen_andc_tl`.
Reported-by: Alexandro Sanchez Bach <address@hidden>
Signed-off-by: Alexandro Sanchez Bach <address@hidden>
Cc: address@hidden
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 5cd10051c2e02b7a86eae49919d6c65a87dbea46)
Signed-off-by: Michael Roth <address@hidden>
Commit: bb8d4bb3ccc419cface945dc5300ccddbe01f651
https://github.com/qemu/qemu/commit/bb8d4bb3ccc419cface945dc5300ccddbe01f651
Author: Greg Kurz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M exec.c
Log Message:
-----------
exec: fix memory leak in find_max_supported_pagesize()
The string returned by object_property_get_str() is dynamically allocated.
Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 72a841d2a403b56ff894fa007b172dc9bcb3dae8)
Signed-off-by: Michael Roth <address@hidden>
Commit: 12fc0de2ab398d6cc379b5ff15895aa7e6a19fe6
https://github.com/qemu/qemu/commit/12fc0de2ab398d6cc379b5ff15895aa7e6a19fe6
Author: Kevin Wolf <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block/gluster.c
Log Message:
-----------
gluster: Fix blockdev-add with server.N.type=unix
The legacy command line interface gets the socket path from an option
called 'socket'. QAPI in contract uses SocketAddress, where the
corresponding option is called 'path'.
Fix the gluster block driver to accept both 'socket' and 'path', with
'path' being the preferred syntax.
https://bugzilla.redhat.com/show_bug.cgi?id=1545155
Cc: address@hidden
Signed-off-by: Kevin Wolf <address@hidden>
Message-id: address@hidden
Signed-off-by: Jeff Cody <address@hidden>
(cherry picked from commit 9dae635afa98f83688806861cefe77ff1b4d76a8)
Signed-off-by: Michael Roth <address@hidden>
Commit: 28895d021eccdaa6f9fa910ed232adf50f4afa58
https://github.com/qemu/qemu/commit/28895d021eccdaa6f9fa910ed232adf50f4afa58
Author: Peter Maydell <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M cpus.c
Log Message:
-----------
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: address@hidden
Fixes: https://bugs.launchpad.net/qemu/+bug/1754038
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Message-id: address@hidden
(cherry picked from commit c52e7132d7c885841500f5277f7305f62767fe1d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 8999a5945fb9fbb35f41d4bdc80cd36616d05421
https://github.com/qemu/qemu/commit/8999a5945fb9fbb35f41d4bdc80cd36616d05421
Author: Greg Kurz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/vfio/ccw.c
Log Message:
-----------
vfio-ccw: fix memory leaks in vfio_ccw_realize()
If the subchannel is already attached or if vfio_get_device() fails, the
code jumps to the 'out_device_err' label and doesn't free the string it
has just allocated.
The code should be reworked so that vcdev->vdev.name only gets set when
the device has been attached, and freed when it is about to be detached.
This could be achieved with the addition of a vfio_ccw_get_device()
function that would be the counterpart of vfio_put_device(). But this is
a more elaborate cleanup that should be done in a follow-up. For now,
let's just add calls to g_free() on the buggy error paths.
Signed-off-by: Greg Kurz <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit be4d026f645eb31078e08d431c93a898b895024e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 44633a272b58cd03eecddd6c224e73f2a52e7ca1
https://github.com/qemu/qemu/commit/44633a272b58cd03eecddd6c224e73f2a52e7ca1
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/block/pflash_cfi01.c
M hw/block/pflash_cfi02.c
Log Message:
-----------
hw/block/pflash_cfi: fix off-by-one error
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: address@hidden
Reported-by: AddressSanitizer
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit 07c13a71721d9f8c690b66752964e254af247475)
Signed-off-by: Michael Roth <address@hidden>
Commit: b17ed3e1d2746ae88863a074b4a1cb3a6b80fae8
https://github.com/qemu/qemu/commit/b17ed3e1d2746ae88863a074b4a1cb3a6b80fae8
Author: Richard Henderson <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/arm/translate.h
M tcg/tcg.h
Log Message:
-----------
tcg: Introduce tcg_set_insn_start_param
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: address@hidden
Reported-by: address@hidden
Signed-off-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 9743cd5736263e90d312b2c33bd739ffe1eae70d)
Conflicts:
target/arm/translate.h
tcg/tcg.h
* rework to avoid functional dependency on 15fa08f
Signed-off-by: Michael Roth <address@hidden>
Commit: 0580c63b4fbf11d32a607efed8afaf7eee6a679e
https://github.com/qemu/qemu/commit/0580c63b4fbf11d32a607efed8afaf7eee6a679e
Author: Peter Maydell <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/char/cmsdk-apb-uart.c
Log Message:
-----------
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: address@hidden
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Message-id: address@hidden
(cherry picked from commit 6670b494fdb23f74ecd9be3d952c007f64e268f1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5648a81dd246d570af45800e9ef7eba045ca5204
https://github.com/qemu/qemu/commit/5648a81dd246d570af45800e9ef7eba045ca5204
Author: Geert Uytterhoeven <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M device_tree.c
Log Message:
-----------
device_tree: Increase FDT_MAX_SIZE to 1 MiB
It is not uncommon for a contemporary FDT to be larger than 64 KiB,
leading to failures loading the device tree from sysfs:
qemu-system-aarch64: qemu_fdt_setprop: Couldn't set ...: FDT_ERR_NOSPACE
Hence increase the limit to 1 MiB, like on PPC.
For reference, the largest arm64 DTB created from the Linux sources is
ca. 75 KiB large (100 KiB when built with symbols/fixup support).
Cc: address@hidden
Signed-off-by: Geert Uytterhoeven <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 14ec3cbd7c1e31dca4d23f028100c8f43e156573)
Signed-off-by: Michael Roth <address@hidden>
Commit: f3f01bab82608541a5f60fe04fce737832db5d56
https://github.com/qemu/qemu/commit/f3f01bab82608541a5f60fe04fce737832db5d56
Author: Jason Andryuk <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/usb/dev-smartcard-reader.c
Log Message:
-----------
ccid: Fix dwProtocols advertisement of T=0
Commit d7d218ef02d87c637d20d64da8f575d434ff6f78 attempted to change
dwProtocols to only advertise support for T=0 and not T=1. The change
was incorrect as it changed 0x00000003 to 0x00010000.
lsusb -v in a linux guest shows:
"dwProtocols 65536 (Invalid values detected)", though the
smart card could still be accessed. Windows 7 does not detect inserted
smart cards and logs the the following Error in the Event Logs:
Source: Smart Card Service
Event ID: 610
Smart Card Reader 'QEMU QEMU USB CCID 0' rejected IOCTL SET_PROTOCOL:
Incorrect function. If this error persists, your smart card or reader
may not be functioning correctly
Command Header: 03 00 00 00
Setting to 0x00000001 fixes the Windows issue.
Signed-off-by: Jason Andryuk <address@hidden>
Message-id: address@hidden
Cc: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 0ee86bb6c5beb6498488850104f7557c376d0bef)
Signed-off-by: Michael Roth <address@hidden>
Commit: 955b77f56e3ce585569168c60fff2d5cb0f82e00
https://github.com/qemu/qemu/commit/955b77f56e3ce585569168c60fff2d5cb0f82e00
Author: Eric Blake <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M nbd/client.c
Log Message:
-----------
nbd/client: Fix error messages during NBD_INFO_BLOCK_SIZE
A missing space makes for poor error messages, and sizes can't
go negative. Also, we missed diagnosing a server that sends
a maximum block size less than the minimum.
Fixes: 081dd1fe
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Vladimir Sementsov-Ogievskiy <address@hidden>
(cherry picked from commit e475d108f1b3d3163f0affea67cdedbe5fc9752b)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0304f75f61dfc1838904e9efc77646f0032b7467
https://github.com/qemu/qemu/commit/0304f75f61dfc1838904e9efc77646f0032b7467
Author: Viktor Mihajlovski <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M pc-bios/s390-ccw/bootmap.c
M pc-bios/s390-ccw/iplb.h
Log Message:
-----------
s390: Do not pass inofficial IPL type to the guest
IPL over a virtio-scsi device requires special handling not
available in the real architecture. For this purpose the IPL
type 0xFF has been chosen as means of communication between
QEMU and the pc-bios. However, a guest OS could be confused
by seeing an unknown IPL type.
This change sets the IPL parameter type to 0x02 (CCW) to prevent
this. Pre-existing Linux has looked up the IPL parameters only in
the case of FCP IPL. This means that the behavior should stay
the same even if Linux checks for the IPL type unconditionally.
Signed-off-by: Viktor Mihajlovski <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Christian Borntraeger <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit e8c7ef288abb05b741a95418ee2de85c1071e0db)
Signed-off-by: Michael Roth <address@hidden>
Commit: 834a846eee9588ac672cb504677490c28b597871
https://github.com/qemu/qemu/commit/834a846eee9588ac672cb504677490c28b597871
Author: Cornelia Huck <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M pc-bios/s390-ccw/iplb.h
Log Message:
-----------
s390-ccw: force diag 308 subcode to unsigned long
We currently pass an integer as the subcode parameter. However,
the upper bits of the register containing the subcode need to
be 0, which is not guaranteed unless we explicitly specify the
subcode to be an unsigned long value.
Fixes: d046c51dad3 ("pc-bios/s390-ccw: Get device address via diag 308/6")
Cc: address@hidden
Signed-off-by: Cornelia Huck <address@hidden>
Acked-by: Christian Borntraeger <address@hidden>
Tested-by: Thomas Huth <address@hidden>
Signed-off-by: Thomas Huth <address@hidden>
(cherry picked from commit 63d8b5ace31c1e1f3996fe4cd551d6d377594d5a)
Signed-off-by: Michael Roth <address@hidden>
Commit: a27d261fe2305855bac3eafc94b5b2a5b16f0743
https://github.com/qemu/qemu/commit/a27d261fe2305855bac3eafc94b5b2a5b16f0743
Author: Henry Wertz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tcg/arm/tcg-target.inc.c
Log Message:
-----------
tcg/arm: Fix memory barrier encoding
I found with qemu 2.11.x or newer that I would get an illegal instruction
error running some Intel binaries on my ARM chromebook. On investigation,
I found it was quitting on memory barriers.
qemu instruction:
mb $0x31
was translating as:
0x604050cc: 5bf07ff5 blpl #0x600250a8
After patch it gives:
0x604050cc: f57ff05b dmb ish
In short, I found INSN_DMB_ISH (memory barrier for ARMv7) appeared to be
correct based on online docs, but due to some endian-related shenanigans it
had to be byte-swapped to suit qemu; it appears INSN_DMB_MCR (memory
barrier for ARMv6) also should be byte swapped (and this patch does so).
I have not checked for correctness of aarch64's barrier instruction.
Cc: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Henry Wertz <address@hidden>
Signed-off-by: Richard Henderson <address@hidden>
(cherry picked from commit 3f814b803797c007abfe5c4041de754e01723031)
Signed-off-by: Michael Roth <address@hidden>
Commit: 67bacd5be4ae28d0ae844faf8ff8b1b48917f9c4
https://github.com/qemu/qemu/commit/67bacd5be4ae28d0ae844faf8ff8b1b48917f9c4
Author: Peter Maydell <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Implement v8M VLLDM and VLSTM
For v8M the instructions VLLDM and VLSTM support lazy saving
and restoring of the secure floating-point registers. Even
if the floating point extension is not implemented, these
instructions must act as NOPs in Secure state, so they can
be used as part of the secure-to-nonsecure call sequence.
Fixes: https://bugs.launchpad.net/qemu/+bug/1768295
Cc: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
(cherry picked from commit b1e5336a9899016c53d59eba53ebf6abcc21995c)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0ab2f8e36df0636015e440e5d2c63cbf6b2ff3eb
https://github.com/qemu/qemu/commit/0ab2f8e36df0636015e440e5d2c63cbf6b2ff3eb
Author: Greg Kurz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/ppc/machine.c
Log Message:
-----------
target/ppc: always set PPC_MEM_TLBIE in pre 2.8 migration hack
The pseries-2.7 and older machine types require CPUPPCState::insns_flags
to be strictly equal between source and destination. This checking is
abusive and breaks migration of KVM guests when the host CPU models
are different, even if they are compatible enough to allow the guest
to run transparently. This buggy behaviour was fixed for pseries-2.8
and we added some hacks to allow backward migration of older machine
types. These hacks assume that the CPU belongs to the POWER8 family,
which was true for most KVM based setup we cared about at the time.
But now POWER9 systems are coming, and backward migration of pre 2.8
guests running in POWER8 architected mode from a POWER9 host to a
POWER8 host is broken:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'cpu'
qemu-system-ppc64: load of migration failed: Invalid argument
This happens because POWER9 doesn't set PPC_MEM_TLBIE in insns_flags,
while POWER8 does. Let's force PPC_MEM_TLBIE in the migration hack to
fix the issue. This is an acceptable hack because these old machine
types only support CPU models that do set PPC_MEM_TLBIE.
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit bce009645b9f1d59195518e35747c8ea30f985f7)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1378cb9db5ab3cebc1dcb26eea62fa21490dcdec
https://github.com/qemu/qemu/commit/1378cb9db5ab3cebc1dcb26eea62fa21490dcdec
Author: Greg Kurz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/ppc/spapr.c
Log Message:
-----------
spapr: don't advertise radix GTSE if max-compat-cpu < power9
On a POWER9 host, if a guest runs in pre POWER9 compat mode, it necessarily
uses the hash MMU mode. In this case, we shouldn't advertise radix GTSE in
the ibm,arch-vec-5-platform-support DT property as the current code does.
The first reason is that it doesn't make sense, and the second one is that
causes the CAS-negotiated options subsection to be migrated. This breaks
backward migration to QEMU 2.7 and older versions on POWER8 hosts:
qemu-system-ppc64: error while loading state for instance 0x0 of device
'spapr'
qemu-system-ppc64: load of migration failed: No such file or directory
This patch hence initialize CPUs a bit earlier so that we can check the
requested compat mode, and don't set OV5_MMU_RADIX_GTSE for power8 and
older.
Signed-off-by: Greg Kurz <address@hidden>
Signed-off-by: David Gibson <address@hidden>
(cherry picked from commit 0550b1206a91d66051a21441a02c4ff126b531fe)
Signed-off-by: Michael Roth <address@hidden>
Commit: ecd54d6670e1672579dec578eae8a99b5d19f046
https://github.com/qemu/qemu/commit/ecd54d6670e1672579dec578eae8a99b5d19f046
Author: Gerd Hoffmann <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/display/qxl-render.c
Log Message:
-----------
qxl: fix local renderer crash
Make sure we only ask the spice local renderer for display updates in
case we have a valid primary surface. Without that spice is confused
and throws errors in case a display update request (triggered by
screendump for example) happens in parallel to a mode switch and hits
the race window where the old primary surface is gone and the new isn't
establisted yet.
Cc: address@hidden
Fixes: https://bugzilla.redhat.com//show_bug.cgi?id=1567733
Signed-off-by: Gerd Hoffmann <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
(cherry picked from commit 5bd5c27c7d284d01477c5cc022ce22438c46bf9f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 088a22455b6ea2a36e4e0a9bde14f85570c4e76a
https://github.com/qemu/qemu/commit/088a22455b6ea2a36e4e0a9bde14f85570c4e76a
Author: Olaf Hering <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M configure
Log Message:
-----------
configure: recognize more rpmbuild macros
Extend the list of recognized, but ignored options from rpms %configure
macro. This fixes build on hosts running SUSE Linux.
Cc: address@hidden
Signed-off-by: Olaf Hering <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 181ce1d05c6d4f1c80f0e7ebb41e489c2b541edf)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1bec53c6f4c967318e1cb52f501f1fb704305bd1
https://github.com/qemu/qemu/commit/1bec53c6f4c967318e1cb52f501f1fb704305bd1
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M qemu-img.c
Log Message:
-----------
qemu-img: Resolve relative backing paths in rebase
Currently, rebase interprets a relative path for the new backing image
as follows:
(1) Open the new backing image with the given relative path (thus relative to
qemu-img's working directory).
(2) Write it directly into the overlay's backing path field (thus
relative to the overlay).
If the overlay is not in qemu-img's working directory, both will be
different interpretations, which may either lead to an error somewhere
(either rebase fails because it cannot open the new backing image, or
your overlay becomes unusable because its backing path does not point to
a file), or, even worse, it may result in your rebase being performed
for a different backing file than what your overlay will point to after
the rebase.
Fix this by interpreting the target backing path as relative to the
overlay, like qemu-img does everywhere else.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1569835
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit d16699b64671466b42079c45b89127aeea1ca565)
Signed-off-by: Michael Roth <address@hidden>
Commit: 324bef41d3a4956757531971e7e886aa0e6a632c
https://github.com/qemu/qemu/commit/324bef41d3a4956757531971e7e886aa0e6a632c
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tests/qemu-iotests/024
M tests/qemu-iotests/024.out
Log Message:
-----------
iotests: Add test for rebasing with relative paths
Signed-off-by: Max Reitz <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 28036a7f7044fddb79819e3c8fcb4ae5605c60e0)
Signed-off-by: Michael Roth <address@hidden>
Commit: dbacc54944dcba8c016ae85ab32a5012f536cdca
https://github.com/qemu/qemu/commit/dbacc54944dcba8c016ae85ab32a5012f536cdca
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M qemu-io.c
Log Message:
-----------
qemu-io: Use purely string blockdev options
Currently, qemu-io only uses string-valued blockdev options (as all are
converted directly from QemuOpts) -- with one exception: -U adds the
force-share option as a boolean. This in itself is already a bit
questionable, but a real issue is that it also assumes the value already
existing in the options QDict would be a boolean, which is wrong.
That has the following effect:
$ ./qemu-io -r -U --image-opts \
driver=file,filename=/dev/null,force-share=off
[1] 15200 segmentation fault (core dumped) ./qemu-io -r -U
--image-opts driver=file,filename=/dev/null,force-share=off
Since @opts is converted from QemuOpts, the value must be a string, and
we have to compare it as such. Consequently, it makes sense to also set
it as a string instead of a boolean.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 2a01c01f9ecb43af4c0a85fe6adc429ffc9c31b5)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5704f53ca9feef4efd7bf783f24533e4e12fa352
https://github.com/qemu/qemu/commit/5704f53ca9feef4efd7bf783f24533e4e12fa352
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M qemu-img.c
Log Message:
-----------
qemu-img: Use only string options in img_open_opts
img_open_opts() takes a QemuOpts and converts them to a QDict, so all
values therein are strings. Then it may try to call qdict_get_bool(),
however, which will fail with a segmentation fault every time:
$ ./qemu-img info -U --image-opts \
driver=file,filename=/dev/null,force-share=off
[1] 27869 segmentation fault (core dumped) ./qemu-img info -U
--image-opts driver=file,filename=/dev/null,force-share=off
Fix this by using qdict_get_str() and comparing the value as a string.
Also, when adding a force-share value to the QDict, add it as a string
so it fits the rest of the dict.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 4615f87832d2fcb7a544bedeece2741bf8c21f94)
Signed-off-by: Michael Roth <address@hidden>
Commit: 15fb5dbf9014305ee1aae98c5d1326f701c8628d
https://github.com/qemu/qemu/commit/15fb5dbf9014305ee1aae98c5d1326f701c8628d
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tests/qemu-iotests/153
M tests/qemu-iotests/153.out
Log Message:
-----------
iotests: Add test for -U/force-share conflicts
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit 4e7d73c5fbd97e55ffe5af02f24d1f7dbe3bbf20)
Signed-off-by: Michael Roth <address@hidden>
Commit: 979e7ea7ebf86e40c97c62aa3aa2f4a4611e6697
https://github.com/qemu/qemu/commit/979e7ea7ebf86e40c97c62aa3aa2f4a4611e6697
Author: Michael Walle <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/lm32/op_helper.c
Log Message:
-----------
lm32: take BQL before writing IP/IM register
Writing to these registers may raise an interrupt request. Actually,
this prevents the milkymist board from starting.
Cc: address@hidden
Signed-off-by: Michael Walle <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
(cherry picked from commit 81e9cbd0ca1131012b058df6804b1f626a6b730c)
Signed-off-by: Michael Roth <address@hidden>
Commit: 720db5deeb852b61e40007989c1390295ceece32
https://github.com/qemu/qemu/commit/720db5deeb852b61e40007989c1390295ceece32
Author: Fam Zheng <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block/raw-format.c
Log Message:
-----------
raw: Check byte range uniformly
We don't verify the request range against s->size in the I/O callbacks
except for raw_co_pwritev. This is inconsistent (especially for
raw_co_pwrite_zeroes and raw_co_pdiscard), so fix them, in the meanwhile
make the helper reusable by the coming new callbacks.
Note that in most cases the block layer already verifies the request
byte range against our reported image length, before invoking the driver
callbacks. The exception is during image creating, after
blk_set_allow_write_beyond_eof(blk, true) is called. But in that case,
the requests are not directly from the user or guest. So there is no
visible behavior change in adding the check code.
The int64_t -> uint64_t inconsistency, as shown by the type casting, is
pre-existing due to the interface.
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Fam Zheng <address@hidden>
Message-id: address@hidden
Signed-off-by: Stefan Hajnoczi <address@hidden>
(cherry picked from commit 384455385248762e74a080978f18f0c8f74757fe)
Signed-off-by: Michael Roth <address@hidden>
Commit: 435a31ff9a3e3e881e4e07e3eae6c758bee0054b
https://github.com/qemu/qemu/commit/435a31ff9a3e3e881e4e07e3eae6c758bee0054b
Author: Cornelia Huck <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/s390x/css.c
Log Message:
-----------
s390x/css: disabled subchannels cannot be status pending
The 3270 code will try to post an attention interrupt when the
3270 emulator (e.g. x3270) attaches. If the guest has not yet
enabled the subchannel for the 3270 device, we will present a spurious
cc 1 (status pending) when it uses msch on it later on, e.g. when
trying to enable the subchannel.
To fix this, just don't do anything in css_conditional_io_interrupt()
if the subchannel is not enabled. The 3270 code will work fine with
that, and the other user of this function (virtio-ccw) never
attempts to post an interrupt for a disabled device to begin with.
CC: address@hidden
Reported-by: Thomas Huth <address@hidden>
Tested-by: Thomas Huth <address@hidden>
Acked-by: Christian Borntraeger <address@hidden>
Acked-by: Halil Pasic <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 6e9c893ecd00afd5344c35d0d0ded50eaa0938f6)
Signed-off-by: Michael Roth <address@hidden>
Commit: ce4e7b03a79eb56228e97a6858d85ac5006947f3
https://github.com/qemu/qemu/commit/ce4e7b03a79eb56228e97a6858d85ac5006947f3
Author: Thomas Huth <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M pc-bios/s390-ccw/cio.h
Log Message:
-----------
pc-bios/s390-ccw: struct tpi_info must be declared as aligned(4)
I've run into a compilation error today with the current version of GCC 8:
In file included from s390-ccw.h:49,
from main.c:12:
cio.h:128:1: error: alignment 1 of 'struct tpi_info' is less than 4
[-Werror=packed-not-aligned]
} __attribute__ ((packed));
^
cc1: all warnings being treated as errors
Since the struct tpi_info contains an element ("struct subchannel_id schid")
which is marked as aligned(4), we've got to mark the struct tpi_info as
aligned(4), too.
CC: address@hidden
Signed-off-by: Thomas Huth <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Cornelia Huck <address@hidden>
Acked-by: Christian Borntraeger <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit a6e4385dea94850d7b06b0542e7960c1063fdabd)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0db89523a6f43c2d1f7a5a6bef23e564bb59b0ec
https://github.com/qemu/qemu/commit/0db89523a6f43c2d1f7a5a6bef23e564bb59b0ec
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M include/hw/qdev-core.h
Log Message:
-----------
qdev: rename typedef qdev_resetfn() -> DeviceReset()
following the DeviceRealize and DeviceUnrealize typedefs,
this unify a bit the new QOM API.
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit b850f664a1dbbc1ea27bef12cd251ee5da0bfe05)
*prereq for 0c53057adb
Signed-off-by: Michael Roth <address@hidden>
Commit: 18f59bbc7609d7c430ea389a3a3782dec27d1f05
https://github.com/qemu/qemu/commit/18f59bbc7609d7c430ea389a3a3782dec27d1f05
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/core/qdev.c
M include/hw/qdev-core.h
Log Message:
-----------
qdev: add helpers to be more explicit when using abstract QOM parent functions
QOM API learning curve is quite hard, in particular when devices inherit from
abstract parent.
To be more explicit about when a device class change the parent hooks, add few
helpers hoping a device class_init() will be easier to understand.
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>
(cherry picked from commit 46795cf2e2f643ace9454822022ba8b1e9c0cf61)
*prereq for 0c53057adb
Signed-off-by: Michael Roth <address@hidden>
Commit: f7f5398dc76685a33e4effe477bf12aaf5fc8bc8
https://github.com/qemu/qemu/commit/f7f5398dc76685a33e4effe477bf12aaf5fc8bc8
Author: Nia Alarie <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/s390x/virtio-ccw.c
M hw/s390x/virtio-ccw.h
Log Message:
-----------
s390x/virtio: Convert virtio-ccw from *_exit to *_unrealize
Signed-off-by: Nia Alarie <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 24118af846868bb22e573be206c63e684ba9846a)
*prereq for 0c53057adb
Signed-off-by: Michael Roth <address@hidden>
Commit: b2ca60262720c6e12ff776b62bd8880f4edd9c7d
https://github.com/qemu/qemu/commit/b2ca60262720c6e12ff776b62bd8880f4edd9c7d
Author: Cornelia Huck <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/s390x/virtio-ccw.c
Log Message:
-----------
virtio-ccw: common reset handler
All the different virtio ccw devices use the same reset handler,
so let's move setting it into the base virtio ccw device class.
CC: address@hidden
Reviewed-by: Thomas Huth <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
Reviewed-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 0c53057adb04d254bc09511880670c92ab185fc6)
Signed-off-by: Michael Roth <address@hidden>
Commit: b68ef5920a110f394350763950fd85f3d467ebfa
https://github.com/qemu/qemu/commit/b68ef5920a110f394350763950fd85f3d467ebfa
Author: Cornelia Huck <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/s390x/ccw-device.c
M hw/s390x/virtio-ccw.c
M hw/s390x/virtio-ccw.h
Log Message:
-----------
s390x/ccw: make sure all ccw devices are properly reset
Thomas reported that the subchannel for a 3270 device that ended up
in a broken state (status pending even though not enabled) did not
get out of that state even after a reboot (which involves a subsytem
reset). The reason for this is that the 3270 device did not define
a reset handler.
Let's fix this by introducing a base reset handler (set up for all
ccw devices) that resets the subchannel and have virtio-ccw call
its virtio-specific reset procedure in addition to that.
CC: address@hidden
Reported-by: Thomas Huth <address@hidden>
Suggested-by: Christian Borntraeger <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Tested-by: Thomas Huth <address@hidden>
Acked-by: Christian Borntraeger <address@hidden>
Reviewed-by: Halil Pasic <address@hidden>
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit 838fb84f83c84f00d15b1bede5e080b495644458)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2e70085eb73434d6462354930c5630c2d0c92ff3
https://github.com/qemu/qemu/commit/2e70085eb73434d6462354930c5630c2d0c92ff3
Author: Michal Privoznik <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M ui/console.c
Log Message:
-----------
console: Avoid segfault in screendump
After f771c5440e04626f1 it is possible to select device and
head which to take screendump from. And even though we check if
provided head number falls within range, it may still happen that
the console has no surface yet leading to SIGSEGV:
qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 \
-qmp stdio \
-device virtio-vga,id=video0,max_outputs=4
{"execute":"qmp_capabilities"}
{"execute":"screendump", "arguments":{"filename":"/tmp/screen.ppm",
"device":"video0", "head":1}}
Segmentation fault
#0 0x00005628249dda88 in ppm_save (filename=0x56282826cbc0 "/tmp/screen.ppm",
ds=0x0, errp=0x7fff52a6fae0) at ui/console.c:304
#1 0x00005628249ddd9b in qmp_screendump (filename=0x56282826cbc0
"/tmp/screen.ppm", has_device=true, device=0x5628276902d0 "video0",
has_head=true, head=1, errp=0x7fff52a6fae0) at ui/console.c:375
#2 0x00005628247740df in qmp_marshal_screendump (args=0x562828265e00,
ret=0x7fff52a6fb68, errp=0x7fff52a6fb60) at qapi/qapi-commands-ui.c:110
Here, @ds from frame #0 (or @surface from frame #1) is
dereferenced at the very beginning of ppm_save(). And because
it's NULL crash happens.
Signed-off-by: Michal Privoznik <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 08d9864fa4e0c616e076ca8b225d39a7ecb189af)
Signed-off-by: Michael Roth <address@hidden>
Commit: 7128bcb2216b2d7ea39e2374952f43b9e51461b2
https://github.com/qemu/qemu/commit/7128bcb2216b2d7ea39e2374952f43b9e51461b2
Author: Jan Kiszka <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/intc/arm_gicv3_cpuif.c
Log Message:
-----------
hw/intc/arm_gicv3: Fix APxR<n> register dispatching
There was a nasty flip in identifying which register group an access is
targeting. The issue caused spuriously raised priorities of the guest
when handing CPUs over in the Jailhouse hypervisor.
Cc: address@hidden
Signed-off-by: Jan Kiszka <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 887aae10f6150dfdc71c45d7588e8efe6c144019)
Signed-off-by: Michael Roth <address@hidden>
Commit: d45364e6d4b7125c9d2abac6f63eec509316195f
https://github.com/qemu/qemu/commit/d45364e6d4b7125c9d2abac6f63eec509316195f
Author: Prasad Singamsetty <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
M hw/i386/intel_iommu_internal.h
M include/hw/i386/intel_iommu.h
Log Message:
-----------
intel-iommu: Redefine macros to enable supporting 48 bit address width
The current implementation of Intel IOMMU code only supports 39 bits
host/iova address width so number of macros use hard coded values based
on that. This patch is to redefine them so they can be used with
variable address widths. This patch doesn't add any new functionality
but enables adding support for 48 bit address width.
Signed-off-by: Prasad Singamsetty <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 92e5d85e8345a22e87eda940ffe0f6422eb45360)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0b250250b7e7298e0001faf76015da4b03b6b1b3
https://github.com/qemu/qemu/commit/0b250250b7e7298e0001faf76015da4b03b6b1b3
Author: Prasad Singamsetty <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/acpi-build.c
M hw/i386/intel_iommu.c
M hw/i386/intel_iommu_internal.h
M include/hw/i386/intel_iommu.h
Log Message:
-----------
intel-iommu: Extend address width to 48 bits
The current implementation of Intel IOMMU code only supports 39 bits
iova address width. This patch provides a new parameter (x-aw-bits)
for intel-iommu to extend its address width to 48 bits but keeping the
default the same (39 bits). The reason for not changing the default
is to avoid potential compatibility problems with live migration of
intel-iommu enabled QEMU guest. The only valid values for 'x-aw-bits'
parameter are 39 and 48.
After enabling larger address width (48), we should be able to map
larger iova addresses in the guest. For example, a QEMU guest that
is configured with large memory ( >=1TB ). To check whether 48 bits
aw is enabled, we can grep in the guest dmesg output with line:
"DMAR: Host address width 48".
Signed-off-by: Prasad Singamsetty <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 37f51384ae05bd50f83308339dbffa3e78404874)
Signed-off-by: Michael Roth <address@hidden>
Commit: 6c403b72b48f01b51d56332ba9e346a1d96fc179
https://github.com/qemu/qemu/commit/6c403b72b48f01b51d56332ba9e346a1d96fc179
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
Log Message:
-----------
intel-iommu: send PSI always even if across PDEs
SECURITY IMPLICATION: without this patch, any guest with both assigned
device and a vIOMMU might encounter stale IO page mappings even if guest
has already unmapped the page, which may lead to guest memory
corruption. The stale mappings will only be limited to the guest's own
memory range, so it should not affect the host memory or other guests on
the host.
During IOVA page table walking, there is a special case when the PSI
covers one whole PDE (Page Directory Entry, which contains 512 Page
Table Entries) or more. In the past, we skip that entry and we don't
notify the IOMMU notifiers. This is not correct. We should send UNMAP
notification to registered UNMAP notifiers in this case.
For UNMAP only notifiers, this might cause IOTLBs cached in the devices
even if they were already invalid. For MAP/UNMAP notifiers like
vfio-pci, this will cause stale page mappings.
This special case doesn't trigger often, but it is very easy to be
triggered by nested device assignments, since in that case we'll
possibly map the whole L2 guest RAM region into the device's IOVA
address space (several GBs at least), which is far bigger than normal
kernel driver usages of the device (tens of MBs normally).
Without this patch applied to L1 QEMU, nested device assignment to L2
guests will dump some errors like:
qemu-system-x86_64: VFIO_MAP_DMA: -17
qemu-system-x86_64: vfio_dma_map(0x557305420c30, 0xad000, 0x1000,
0x7f89a920d000) = -17 (File exists)
CC: QEMU Stable <address@hidden>
Acked-by: Jason Wang <address@hidden>
[peterx: rewrite the commit message]
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 36d2d52bdb45f5b753a61fdaf0fe7891f1f5b61d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 99fc962b62f6419f09e2d09670e176359da06ce7
https://github.com/qemu/qemu/commit/99fc962b62f6419f09e2d09670e176359da06ce7
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
M include/hw/i386/intel_iommu.h
Log Message:
-----------
intel-iommu: remove IntelIOMMUNotifierNode
That is not really necessary. Removing that node struct and put the
list entry directly into VTDAddressSpace. It simplfies the code a lot.
Since at it, rename the old notifiers_list into vtd_as_with_notifiers.
CC: QEMU Stable <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit b4a4ba0d68f50f218ee3957b6638dbee32a5eeef)
Signed-off-by: Michael Roth <address@hidden>
Commit: 3585497e8669fae18b59bd6a6ee7954289015447
https://github.com/qemu/qemu/commit/3585497e8669fae18b59bd6a6ee7954289015447
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
M include/hw/i386/intel_iommu.h
Log Message:
-----------
intel-iommu: add iommu lock
SECURITY IMPLICATION: this patch fixes a potential race when multiple
threads access the IOMMU IOTLB cache.
Add a per-iommu big lock to protect IOMMU status. Currently the only
thing to be protected is the IOTLB/context cache, since that can be
accessed even without BQL, e.g., in IO dataplane.
Note that we don't need to protect device page tables since that's fully
controlled by the guest kernel. However there is still possibility that
malicious drivers will program the device to not obey the rule. In that
case QEMU can't really do anything useful, instead the guest itself will
be responsible for all uncertainties.
CC: QEMU Stable <address@hidden>
Reported-by: Fam Zheng <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 1d9efa73e12ddf361ea997c2d532cc4afa6674d1)
Signed-off-by: Michael Roth <address@hidden>
Commit: 21962e6958b7e7e1001786e7f4e79eda33d93502
https://github.com/qemu/qemu/commit/21962e6958b7e7e1001786e7f4e79eda33d93502
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
M include/hw/i386/intel_iommu.h
Log Message:
-----------
intel-iommu: only do page walk for MAP notifiers
For UNMAP-only IOMMU notifiers, we don't need to walk the page tables.
Fasten that procedure by skipping the page table walk. That should
boost performance for UNMAP-only notifiers like vhost.
CC: QEMU Stable <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 4f8a62a933a79094e44bc1b16b63bb23e62d67b4)
Signed-off-by: Michael Roth <address@hidden>
Commit: 04e0e116283ac153fde7cf85d889a469e28325ea
https://github.com/qemu/qemu/commit/04e0e116283ac153fde7cf85d889a469e28325ea
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
Log Message:
-----------
intel-iommu: introduce vtd_page_walk_info
During the recursive page walking of IOVA page tables, some stack
variables are constant variables and never changed during the whole page
walking procedure. Isolate them into a struct so that we don't need to
pass those contants down the stack every time and multiple times.
CC: QEMU Stable <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit fe215b0cbb8c1f4b4af0a64aa5c02042080dd537)
Signed-off-by: Michael Roth <address@hidden>
Commit: e8aa1dc8166ee652acf8c2101856c072a81ebe63
https://github.com/qemu/qemu/commit/e8aa1dc8166ee652acf8c2101856c072a81ebe63
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
Log Message:
-----------
intel-iommu: pass in address space when page walk
We pass in the VTDAddressSpace too. It'll be used in the follow up
patches.
CC: QEMU Stable <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 2f764fa87d2a81812b313dd6d998e10126292653)
Signed-off-by: Michael Roth <address@hidden>
Commit: e2c44fc58065c870f5d4e7e2a0f37a359060ec08
https://github.com/qemu/qemu/commit/e2c44fc58065c870f5d4e7e2a0f37a359060ec08
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
M hw/i386/trace-events
Log Message:
-----------
intel-iommu: trace domain id during page walk
This patch only modifies the trace points.
Previously we were tracing page walk levels. They are redundant since
we have page mask (size) already. Now we trace something much more
useful which is the domain ID of the page walking. That can be very
useful when we trace more than one devices on the same system, so that
we can know which map is for which domain.
CC: QEMU Stable <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit d118c06ebbee2d23ddf873cae4a809311aa61310)
Signed-off-by: Michael Roth <address@hidden>
Commit: bdb6f9b6bc9b8e8f41a98e949521dd33b6c0d7d9
https://github.com/qemu/qemu/commit/bdb6f9b6bc9b8e8f41a98e949521dd33b6c0d7d9
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M MAINTAINERS
A include/qemu/iova-tree.h
M util/Makefile.objs
A util/iova-tree.c
Log Message:
-----------
util: implement simple iova tree
Introduce a simplest iova tree implementation based on GTree.
CC: QEMU Stable <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit eecf5eedbdc0fc04f39abcf3afeedfbf21b25ca4)
Conflicts:
util/Makefile.objs
* drop context dep
Signed-off-by: Michael Roth <address@hidden>
Commit: 8da7a171c0a27f8b634001bec76953fc59b78cbc
https://github.com/qemu/qemu/commit/8da7a171c0a27f8b634001bec76953fc59b78cbc
Author: Peter Xu <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/i386/intel_iommu.c
M hw/i386/trace-events
M include/hw/i386/intel_iommu.h
Log Message:
-----------
intel-iommu: rework the page walk logic
This patch fixes a potential small window that the DMA page table might
be incomplete or invalid when the guest sends domain/context
invalidations to a device. This can cause random DMA errors for
assigned devices.
This is a major change to the VT-d shadow page walking logic. It
includes but is not limited to:
- For each VTDAddressSpace, now we maintain what IOVA ranges we have
mapped and what we have not. With that information, now we only send
MAP or UNMAP when necessary. Say, we don't send MAP notifies if we
know we have already mapped the range, meanwhile we don't send UNMAP
notifies if we know we never mapped the range at all.
- Introduce vtd_sync_shadow_page_table[_range] APIs so that we can call
in any places to resync the shadow page table for a device.
- When we receive domain/context invalidation, we should not really run
the replay logic, instead we use the new sync shadow page table API to
resync the whole shadow page table without unmapping the whole
region. After this change, we'll only do the page walk once for each
domain invalidations (before this, it can be multiple, depending on
number of notifiers per address space).
While at it, the page walking logic is also refactored to be simpler.
CC: QEMU Stable <address@hidden>
Reported-by: Jintack Lim <address@hidden>
Tested-by: Jintack Lim <address@hidden>
Signed-off-by: Peter Xu <address@hidden>
Reviewed-by: Michael S. Tsirkin <address@hidden>
Signed-off-by: Michael S. Tsirkin <address@hidden>
(cherry picked from commit 63b88968f139b6a77f2f81e6f1eedf70c0170a85)
Signed-off-by: Michael Roth <address@hidden>
Commit: e55c6b67955b926f4113211c0d1f6cab0e6bb4f9
https://github.com/qemu/qemu/commit/e55c6b67955b926f4113211c0d1f6cab0e6bb4f9
Author: Shannon Zhao <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/intc/arm_gicv3_kvm.c
Log Message:
-----------
arm_gicv3_kvm: increase clroffset accordingly
It forgot to increase clroffset during the loop. So it only clear the
first 4 bytes.
Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920
Cc: address@hidden
Signed-off-by: Shannon Zhao <address@hidden>
Reviewed-by: Eric Auger <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 34ffacae085914fce54590ea84bae9c6ad95e2a4)
Signed-off-by: Michael Roth <address@hidden>
Commit: 16238325f1b6249ba58d44825d254f2becb1b838
https://github.com/qemu/qemu/commit/16238325f1b6249ba58d44825d254f2becb1b838
Author: John Thomson <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/usb/host-libusb.c
Log Message:
-----------
Fix libusb-1.0.22 deprecated libusb_set_debug with libusb_set_option
libusb-1.0.22 marked libusb_set_debug deprecated
it is replaced with
libusb_set_option(libusb_context, LIBUSB_OPTION_LOG_LEVEL, libusb_log_level);
details here:
https://github.com/libusb/libusb/commit/539f22e2fd916558d11ab9a66f10f461c5593168
Warning here:
CC hw/usb/host-libusb.o
/builds/xen/src/qemu-xen/hw/usb/host-libusb.c: In function 'usb_host_init':
/builds/xen/src/qemu-xen/hw/usb/host-libusb.c:250:5: error: 'libusb_set_debug'
is deprecated: Use libusb_set_option instead [-Werror=deprecated-declarations]
libusb_set_debug(ctx, loglevel);
^~~~~~~~~~~~~~~~
In file included from /builds/xen/src/qemu-xen/hw/usb/host-libusb.c:40:0:
/usr/include/libusb-1.0/libusb.h:1300:18: note: declared here
void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make: *** [/builds/xen/src/qemu-xen/rules.mak:66: hw/usb/host-libusb.o] Error 1
make: Leaving directory '/builds/xen/src/xen/tools/qemu-xen-build'
Signed-off-by: John Thomson <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 9d8fa0df49af16a208fa961c2968fba4daffcc07)
Signed-off-by: Michael Roth <address@hidden>
Commit: deabb454dc39d633fcd4c6951079f1d7581a6720
https://github.com/qemu/qemu/commit/deabb454dc39d633fcd4c6951079f1d7581a6720
Author: John Snow <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
ahci: fix PxCI register race
Fixes: https://bugs.launchpad.net/qemu/+bug/1769189
AHCI presently signals completion prior to the PxCI register being
cleared to indicate completion. If a guest driver attempts to issue
a new command in its IRQ handler, it might be surprised to learn there
is still a command pending.
In the case of Windows 10's boot driver, it will actually poll the IRQ
register hoping to find out when the command is done running -- which
will never happen, as there isn't a command running.
Fix this: clear PxCI in ahci_cmd_done and not in the asynchronous BH.
Because it now runs synchronously, we don't need to check if the command
is actually done by spying on the ATA registers. We know it's done.
CC: qemu-stable <address@hidden>
Reported-by: François Guerraz <address@hidden>
Tested-by: Bruce Rogers <address@hidden>
Signed-off-by: John Snow <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Message-id: address@hidden
Signed-off-by: John Snow <address@hidden>
(cherry picked from commit 5694c7eacce6b263ad7497cc1bb76aad746cfd4e)
Signed-off-by: Michael Roth <address@hidden>
Commit: 5d639531b7f6814c79c992f3753be6e8b34acb6f
https://github.com/qemu/qemu/commit/5d639531b7f6814c79c992f3753be6e8b34acb6f
Author: Shannon Zhao <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/intc/arm_gicv3_common.c
M hw/intc/arm_gicv3_kvm.c
M include/hw/intc/arm_gicv3_common.h
Log Message:
-----------
arm_gicv3_kvm: kvm_dist_get/put: skip the registers banked by GICR
While we skip the GIC_INTERNAL irqs, we don't change the register offset
accordingly. This will overlap the GICR registers value and leave the
last GIC_INTERNAL irq's registers out of update.
Fix this by skipping the registers banked by GICR.
Also for migration compatibility if the migration source (old version
qemu) doesn't send gicd_no_migration_shift_bug = 1 to destination, then
we shift the data of PPI to get the right data for SPI.
Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920
Cc: address@hidden
Reviewed-by: Eric Auger <address@hidden>
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Shannon Zhao <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 910e204841954b95c051b2ee49ab0f5c735ff93c)
Signed-off-by: Michael Roth <address@hidden>
Commit: 62891cad12cbc50127df0e077485f7ded84307ab
https://github.com/qemu/qemu/commit/62891cad12cbc50127df0e077485f7ded84307ab
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block.c
M include/block/block.h
Log Message:
-----------
block: Make bdrv_is_writable() public
This is a useful function for the whole block layer, so make it public.
At the same time, users outside of block.c probably do not need to make
use of the reopen functionality, so rename the current function to
bdrv_is_writable_after_reopen() create a new bdrv_is_writable() function
that just passes NULL to it for the reopen queue.
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit cc022140972f8b6ac3973c12ccf9dd6b1d2fd200)
Signed-off-by: Michael Roth <address@hidden>
Commit: f91f44fcd137a8892b9e814d957244f791d96f2c
https://github.com/qemu/qemu/commit/f91f44fcd137a8892b9e814d957244f791d96f2c
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block/qcow2.c
Log Message:
-----------
qcow2: Do not mark inactive images corrupt
When signaling a corruption on a read-only image, qcow2 already makes
fatal events non-fatal (i.e., they will not result in the image being
closed, and the image header's corrupt flag will not be set). This is
necessary because we cannot set the corrupt flag on read-only images,
and it is possible because further corruption of read-only images is
impossible.
Inactive images are effectively read-only, too, so we should do the same
for them. bdrv_is_writable() can tell us whether an image can actually
be written to, so use its result instead of !bs->read_only.
(Otherwise, the assert(!(bs->open_flags & BDRV_O_INACTIVE)) in
bdrv_co_pwritev() will fail, crashing qemu.)
Cc: address@hidden
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Reviewed-by: John Snow <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit ddf3b47ef4b5ed0bf6558d4c2c8ae130b8d8a580)
Signed-off-by: Michael Roth <address@hidden>
Commit: f647a4fc444aa218fefbac5b82f504180775dc0f
https://github.com/qemu/qemu/commit/f647a4fc444aa218fefbac5b82f504180775dc0f
Author: Max Reitz <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tests/qemu-iotests/060
M tests/qemu-iotests/060.out
Log Message:
-----------
iotests: Add case for a corrupted inactive image
Reviewed-by: John Snow <address@hidden>
Tested-by: Jeff Cody <address@hidden>
Reviewed-by: Jeff Cody <address@hidden>
Signed-off-by: Max Reitz <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit c50abd175a88cd41c2c08339de91f6f6e4a7b162)
Signed-off-by: Michael Roth <address@hidden>
Commit: d80b60fc2433cc934533f594bfa4e2b6c6103ba3
https://github.com/qemu/qemu/commit/d80b60fc2433cc934533f594bfa4e2b6c6103ba3
Author: Alberto Garcia <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M block/throttle.c
Log Message:
-----------
throttle: Fix crash on reopen
The throttle block filter can be reopened, and with this it is
possible to change the throttle group that the filter belongs to.
The way the code does that is the following:
- On throttle_reopen_prepare(): create a new ThrottleGroupMember
and attach it to the new throttle group.
- On throttle_reopen_commit(): detach the old ThrottleGroupMember,
delete it and replace it with the new one.
The problem with this is that by replacing the ThrottleGroupMember the
previous value of io_limits_disabled is lost, causing an assertion
failure in throttle_co_drain_end().
This problem can be reproduced by reopening a throttle node:
$QEMU -monitor stdio
-object throttle-group,id=tg0,x-iops-total=1000 \
-blockdev node-name=hd0,driver=qcow2,file.driver=file,file.filename=hd.qcow2
\
-blockdev
node-name=root,driver=throttle,throttle-group=tg0,file=hd0,read-only=on
(qemu) block_stream root
block/throttle.c:214: throttle_co_drain_end: Assertion
`tgm->io_limits_disabled' failed.
Since we only want to change the throttle group on reopen there's no
need to create a ThrottleGroupMember and discard the old one. It's
easier if we simply detach it from its current group and attach it to
the new one.
Signed-off-by: Alberto Garcia <address@hidden>
Message-id: address@hidden
Signed-off-by: Max Reitz <address@hidden>
(cherry picked from commit bc33c047d1ec0b35c9cd8be62bcefae2da28654f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 84cfae0b6f232c8ac8aaa37ead01ed49c5d32dfd
https://github.com/qemu/qemu/commit/84cfae0b6f232c8ac8aaa37ead01ed49c5d32dfd
Author: Gerd Hoffmann <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/display/vga.c
Log Message:
-----------
vga: fix region calculation
Typically the scanline length and the line offset are identical. But
in case they are not our calculation for region_end is incorrect. Using
line_offset is fine for all scanlines, except the last one where we have
to use the actual scanline length.
Fixes: CVE-2018-7550
Reported-by: Ross Lagerwall <address@hidden>
Signed-off-by: Gerd Hoffmann <address@hidden>
Reviewed-by: Prasad J Pandit <address@hidden>
Tested-by: Ross Lagerwall <address@hidden>
Message-id: address@hidden
(cherry picked from commit 7cdc61becd095b64a786b2625f321624e7111f3d)
Signed-off-by: Michael Roth <address@hidden>
Commit: 4ce0b750a20a055736b073fa7dff3eba6f6e3b73
https://github.com/qemu/qemu/commit/4ce0b750a20a055736b073fa7dff3eba6f6e3b73
Author: Daniel P. Berrangé <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/i386/cpu.c
M target/i386/cpu.h
Log Message:
-----------
i386: define the 'ssbd' CPUID feature bit (CVE-2018-3639)
New microcode introduces the "Speculative Store Bypass Disable"
CPUID feature bit. This needs to be exposed to guest OS to allow
them to protect against CVE-2018-3639.
Signed-off-by: Daniel P. Berrangé <address@hidden>
Reviewed-by: Konrad Rzeszutek Wilk <address@hidden>
Signed-off-by: Konrad Rzeszutek Wilk <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit d19d1f965904a533998739698020ff4ee8a103da)
Signed-off-by: Michael Roth <address@hidden>
Commit: 73521f60f4ecb48d168021b193fe2e52fb0eea9a
https://github.com/qemu/qemu/commit/73521f60f4ecb48d168021b193fe2e52fb0eea9a
Author: Konrad Rzeszutek Wilk <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/i386/cpu.h
M target/i386/kvm.c
M target/i386/machine.c
Log Message:
-----------
i386: Define the Virt SSBD MSR and handling of it (CVE-2018-3639)
"Some AMD processors only support a non-architectural means of enabling
speculative store bypass disable (SSBD). To allow a simplified view of
this to a guest, an architectural definition has been created through a new
CPUID bit, 0x80000008_EBX[25], and a new MSR, 0xc001011f. With this, a
hypervisor can virtualize the existence of this definition and provide an
architectural method for using SSBD to a guest.
Add the new CPUID feature, the new MSR and update the existing SSBD
support to use this MSR when present." (from x86/speculation: Add virtualized
speculative store bypass disable support in Linux).
Signed-off-by: Konrad Rzeszutek Wilk <address@hidden>
Reviewed-by: Daniel P. Berrangé <address@hidden>
Signed-off-by: Daniel P. Berrangé <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit cfeea0c021db6234c154dbc723730e81553924ff)
Conflicts:
target/i386/kvm.c
target/i386/machine.c
* drop context dep on b77146e9a
Signed-off-by: Michael Roth <address@hidden>
Commit: afa43eb63ee4f60c0370aec5aad9d11c585409cb
https://github.com/qemu/qemu/commit/afa43eb63ee4f60c0370aec5aad9d11c585409cb
Author: Konrad Rzeszutek Wilk <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386: define the AMD 'virt-ssbd' CPUID feature bit (CVE-2018-3639)
AMD Zen expose the Intel equivalant to Speculative Store Bypass Disable
via the 0x80000008_EBX[25] CPUID feature bit.
This needs to be exposed to guest OS to allow them to protect
against CVE-2018-3639.
Signed-off-by: Konrad Rzeszutek Wilk <address@hidden>
Reviewed-by: Daniel P. Berrangé <address@hidden>
Signed-off-by: Daniel P. Berrangé <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit 403503b162ffc33fb64cfefdf7b880acf41772cd)
Signed-off-by: Michael Roth <address@hidden>
Commit: f4e93bbd2e50f3762bd98a2422ef647e6a29df6b
https://github.com/qemu/qemu/commit/f4e93bbd2e50f3762bd98a2422ef647e6a29df6b
Author: Brijesh Singh <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M net/tap.c
Log Message:
-----------
tap: set vhostfd passed from qemu cli to non-blocking
A guest boot hangs while probing the network interface when
iommu_platform=on is used.
The following qemu cli hangs without this patch:
# $QEMU \
-netdev tap,fd=3,id=hostnet0,vhost=on,vhostfd=4 3<>/dev/tap67
4<>/dev/host-net \
-device
virtio-net-pci,netdev=hostnet0,id=net0,iommu_platform=on,disable-legacy=on \
...
Commit: c471ad0e9bd46 (vhost_net: device IOTLB support) took care of
setting vhostfd to non-blocking when QEMU opens /dev/host-net but if
the fd is passed from qemu cli then we need to ensure that fd is set
to non-blocking.
Fixes: c471ad0e9bd46 ("vhost_net: device IOTLB support")
Cc: address@hidden
Cc: Michael S. Tsirkin <address@hidden>
Cc: Jason Wang <address@hidden>
Signed-off-by: Brijesh Singh <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit d542800d1edc62f63f8a29cfa6bdd1a9536ae11c)
Signed-off-by: Michael Roth <address@hidden>
Commit: d8a919ffc7d9a195537cf4d12afa52e12babaf7f
https://github.com/qemu/qemu/commit/d8a919ffc7d9a195537cf4d12afa52e12babaf7f
Author: linzhecheng <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M net/vhost-user.c
Log Message:
-----------
vhost-user: delete net client if necessary
As qemu_new_net_client create new ncs but error happens later,
ncs will be left in global net_clients list and we can't use them any
more, so we need to cleanup them.
Cc: address@hidden
Signed-off-by: linzhecheng <address@hidden>
Signed-off-by: Jason Wang <address@hidden>
(cherry picked from commit c67daf4a24442d1bb404a11a6a54dc45ea10f234)
Conflicts:
net/vhost-user.c
* drop functional dep on 4d0cf552
Signed-off-by: Michael Roth <address@hidden>
Commit: 9c5a8433cee3f03ecd67de0046c41ed9b01d1993
https://github.com/qemu/qemu/commit/9c5a8433cee3f03ecd67de0046c41ed9b01d1993
Author: Eric Blake <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M qemu-img.c
Log Message:
-----------
qemu-img: Fix assert when mapping unaligned raw file
Commit a290f085 exposed a latent bug in qemu-img map introduced
during the conversion of block status to be byte-based. Earlier in
commit 5e344dd8, the internal interface get_block_status() switched
to take byte-based parameters, but still called a sector-based
block layer function; as such, rounding was added in the lone
caller to obey the contract. However, commit 237d78f8 changed
get_block_status() to truly be byte-based, at which point rounding
to sector boundaries can result in calling bdrv_block_status() with
'bytes == 0' (a coding error) when the boundary between data and a
hole falls mid-sector (true for the past-EOF implicit hole present
in POSIX files). Fix things by removing the rounding that is now
no longer necessary.
See also https://bugzilla.redhat.com/1589738
Fixes: 237d78f8
Reported-by: Dan Kenigsberg <address@hidden>
Reported-by: Nir Soffer <address@hidden>
Reported-by: Maor Lipchuk <address@hidden>
CC: address@hidden
Signed-off-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit e0b371ed5e2db079051139136fd0478728b6a58f)
Signed-off-by: Michael Roth <address@hidden>
Commit: 99e051b2904f7c1dbf451725494f5d39fba4519d
https://github.com/qemu/qemu/commit/99e051b2904f7c1dbf451725494f5d39fba4519d
Author: Eric Blake <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
A tests/qemu-iotests/221
A tests/qemu-iotests/221.out
M tests/qemu-iotests/group
Log Message:
-----------
iotests: Add test 221 to catch qemu-img map regression
Although qemu-img creates aligned files (by rounding up), it
must also gracefully handle files that are not sector-aligned.
Test that the bug fixed in the previous patch does not recur.
It's a bit annoying that we can see the (implicit) hole past
the end of the file on to the next sector boundary, so if we
ever reach the point where we report a byte-accurate size rather
than our current behavior of always rounding up, this test will
probably need a slight modification.
Signed-off-by: Eric Blake <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>
(cherry picked from commit c6a9d2f6f9bc0c163b3a3073126464a2446bad5f)
Conflicts:
tests/qemu-iotests/group
* drop context dep on tests not present in 2.11
Signed-off-by: Michael Roth <address@hidden>
Commit: 6622e948976c02eff20c174a2d3b5517fe00afca
https://github.com/qemu/qemu/commit/6622e948976c02eff20c174a2d3b5517fe00afca
Author: Shannon Zhao <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/intc/arm_gicv3_kvm.c
Log Message:
-----------
arm_gicv3_kvm: kvm_dist_get/put_priority: skip the registers banked by
GICR_IPRIORITYR
While for_each_dist_irq_reg loop starts from GIC_INTERNAL, it forgot to
offset the date array and index. This will overlap the GICR registers
value and leave the last GIC_INTERNAL irq's registers out of update.
Fixes: 367b9f527becdd20ddf116e17a3c0c2bbc486920
Cc: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Reviewed-by: Eric Auger <address@hidden>
Signed-off-by: Shannon Zhao <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 1dcf3675196a1cec616ce71b067d9498590a60a6)
Signed-off-by: Michael Roth <address@hidden>
Commit: 8bbb76e05023bfa64e197475a072e599d046b3ba
https://github.com/qemu/qemu/commit/8bbb76e05023bfa64e197475a072e599d046b3ba
Author: Daniel P. Berrange <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M scripts/qapi.py
Log Message:
-----------
qapi: ensure stable sort ordering when checking QAPI entities
Some early python 3.x versions will have different default
ordering when calling the 'values()' method on a dict, compared
to python 2.x and later 3.x versions. Explicitly sort the items
to get a stable ordering.
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Signed-off-by: Daniel P. Berrange <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
(cherry picked from commit f7a5376d4b667cf6c83c1d640e32d22456d7b5ee)
Signed-off-by: Michael Roth <address@hidden>
Commit: 2ab0ce6e8d94471ef4add86321fab7b476f82fac
https://github.com/qemu/qemu/commit/2ab0ce6e8d94471ef4add86321fab7b476f82fac
Author: Daniel P. Berrangé <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M tests/test-crypto-tlssession.c
M tests/test-io-channel-tls.c
Log Message:
-----------
crypto: ensure we use a predictable TLS priority setting
The TLS test cert generation relies on a fixed set of algorithms that are
only usable under GNUTLS' default priority setting. When building QEMU
with a custom distro specific priority setting, this can cause the TLS
tests to fail. By forcing the tests to always use "NORMAL" priority we
can make them more robust.
Reviewed-by: Eric Blake <address@hidden>
Signed-off-by: Daniel P. Berrangé <address@hidden>
(cherry picked from commit 057ad0b46992e3ec4ce29b9103162aa3c683f347)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0f04a8bba607b8deac44cae6dc387671c34a6cb3
https://github.com/qemu/qemu/commit/0f04a8bba607b8deac44cae6dc387671c34a6cb3
Author: Christian Borntraeger <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390-ccw-virtio: allow for systems larger that 7.999TB
KVM does not allow memory regions > KVM_MEM_MAX_NR_PAGES, basically
limiting the memory per slot to 8TB-4k. As memory slots on s390/kvm must
be a multiple of 1MB we need start a new memory region if we cross
8TB-1M.
With that (and optimistic overcommitment in the kernel) I was able to
start a 24TB guest on a 1TB system.
Signed-off-by: Christian Borntraeger <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: David Hildenbrand <address@hidden>
[CH: 1UL -> 1ULL in KVM_MEM_MAX_NR_PAGES; build fix on 32 bit hosts]
Signed-off-by: Cornelia Huck <address@hidden>
(cherry picked from commit bb223055b9b327ec66e1f6d2fbaebaee0b8f3dbe)
Signed-off-by: Michael Roth <address@hidden>
Commit: a36591fa622a92134d11b3d05746c3c55f638966
https://github.com/qemu/qemu/commit/a36591fa622a92134d11b3d05746c3c55f638966
Author: Marc-André Lureau <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/tpm/tpm_passthrough.c
Log Message:
-----------
tpm-passthrough: don't save guessed cancel_path in options
The value is later unneeded, and may leak if the free visitor doesn't
consider it since has_cancel_path is false. And for consistency with
"path" it shouldn't be returned in get_tpm_options().
Signed-off-by: Marc-André Lureau <address@hidden>
Reviewed-by: Stefan Berger <address@hidden>
Signed-off-by: Stefan Berger <address@hidden>
(cherry picked from commit 69c07db04625cb243db6e8a0ac0a8e3973dd961a)
Signed-off-by: Michael Roth <address@hidden>
Commit: 1e13e7d93b93885d8a27fd18ec8a4b865a70e2ea
https://github.com/qemu/qemu/commit/1e13e7d93b93885d8a27fd18ec8a4b865a70e2ea
Author: Marc-André Lureau <address@hidden>
Date: 2018-06-20 (Wed, 20 Jun 2018)
Changed paths:
M hw/tpm/tpm_passthrough.c
Log Message:
-----------
tpm: lookup cancel path under tpm device class
Since Linux commit 313d21eeab9282e, tpm devices have their own device
class "tpm" and the cancel path must be looked up under
/sys/class/tpm/ instead of /sys/class/misc/.
Signed-off-by: Marc-André Lureau <address@hidden>
Reviewed-by: Stefan Berger <address@hidden>
Signed-off-by: Stefan Berger <address@hidden>
(cherry picked from commit 05b71fb207ab7f016e067bd2a40fc0804362eb74)
Signed-off-by: Michael Roth <address@hidden>
Commit: 728d6c602ea9fc9cfc4a2fcafb2553a1f4f400b6
https://github.com/qemu/qemu/commit/728d6c602ea9fc9cfc4a2fcafb2553a1f4f400b6
Author: Cornelia Huck <address@hidden>
Date: 2018-06-21 (Thu, 21 Jun 2018)
Changed paths:
M pc-bios/s390-ccw.img
Log Message:
-----------
pc-bios/s390-ccw.img: update image for stable
Contains the following commits:
- s390: Do not pass inofficial IPL type to the guest
- s390-ccw: force diag 308 subcode to unsigned long
- pc-bios/s390-ccw: struct tpi_info must be declared as aligned(4)
Signed-off-by: Cornelia Huck <address@hidden>
Commit: a8e4217b0c4899621ce09669c46d008e2bcfeed4
https://github.com/qemu/qemu/commit/a8e4217b0c4899621ce09669c46d008e2bcfeed4
Author: Michael Roth <address@hidden>
Date: 2018-06-21 (Thu, 21 Jun 2018)
Changed paths:
M pc-bios/s390-ccw.img
Log Message:
-----------
Merge tag 'tags/s390x-20180621-211-stable' into stable-2.11-staging
update s390-ccw.img for stable
Signed-off-by: Michael Roth <address@hidden>
Commit: 9e4fa091eeb29e2363712c886cc1e9ad78631887
https://github.com/qemu/qemu/commit/9e4fa091eeb29e2363712c886cc1e9ad78631887
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2018-06-21 (Thu, 21 Jun 2018)
Changed paths:
M gdbstub.c
Log Message:
-----------
gdbstub: fix off-by-one in gdb_handle_packet()
memtohex() adds an extra trailing NUL character.
Reported-by: AddressSanitizer
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>
(cherry picked from commit 9005774b27b6aa5e1c99d80bd59d5d048c2f7077)
Signed-off-by: Michael Roth <address@hidden>
Commit: 17e3fcbc51eddf06f50d59fb96a21a3298b25cd3
https://github.com/qemu/qemu/commit/17e3fcbc51eddf06f50d59fb96a21a3298b25cd3
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2018-06-21 (Thu, 21 Jun 2018)
Changed paths:
M hw/usb/redirect.c
Log Message:
-----------
usb: correctly handle Zero Length Packets
USB Specification Revision 2.0, §5.5.3:
The Data stage of a control transfer from an endpoint to the host is complete
when the endpoint does one of the following:
• Has transferred exactly the amount of data specified during the Setup stage
• Transfers a packet with a payload size less than wMaxPacketSize or
transfers a zero-length packet"
hw/usb/redirect.c:802:9: warning: Declared variable-length array (VLA) has zero
size
uint8_t buf[size];
^~~~~~~~~~~ ~~~~
Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit bf78fb1c1b61a819a47f7a1dbecf9934b9f32a0d)
Signed-off-by: Michael Roth <address@hidden>
Commit: aba59705d963b79f5732f2265fa2175654b61db8
https://github.com/qemu/qemu/commit/aba59705d963b79f5732f2265fa2175654b61db8
Author: Philippe Mathieu-Daudé <address@hidden>
Date: 2018-06-21 (Thu, 21 Jun 2018)
Changed paths:
M hw/usb/dev-mtp.c
Log Message:
-----------
usb/dev-mtp: Fix use of uninitialized values
This fixes:
hw/usb/dev-mtp.c:971:5: warning: 4th function call argument is an
uninitialized value
trace_usb_mtp_op_get_partial_object(s->dev.addr, o->handle, o->path,
c->argv[1], c->argv[2]);
^~~~~~~~~~
and:
hw/usb/dev-mtp.c:981:12: warning: Assigned value is garbage or undefined
offset = c->argv[1];
^ ~~~~~~~~~~
Reported-by: Clang Static Analyzer
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>
(cherry picked from commit 62713a2e50f653162387451034f1a2490e87be88)
Signed-off-by: Michael Roth <address@hidden>
Commit: 0982a56a551556c704dc15752dabf57b4be1c640
https://github.com/qemu/qemu/commit/0982a56a551556c704dc15752dabf57b4be1c640
Author: Michael Roth <address@hidden>
Date: 2018-06-26 (Tue, 26 Jun 2018)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 2.11.2 release
Signed-off-by: Michael Roth <address@hidden>
Compare: https://github.com/qemu/qemu/compare/7c1beb52ed86...0982a56a5515
**NOTE:** This service been marked for deprecation:
https://developer.github.com/changes/2018-04-25-github-services-deprecation/
Functionality will be removed from GitHub.com on January 31st, 2019.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 5892b5: memfd: fix configure test,
GitHub <=