Package: qemu / 1:2.12+dfsg-3


Package Version Patches format
qemu 1:2.12+dfsg-3 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
use fixed data path.patch | (download)

os-posix.c | 2 2 + 0 - 0 !
vl.c | 7 1 + 6 - 0 !
2 files changed, 3 insertions(+), 6 deletions(-)

 use fixed data dir instead of determining it at runtime
ccid card passthru fix regression in realize.patch | (download)

hw/usb/ccid-card-passthru.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch] ccid-card-passthru: fix regression in realize()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit-Id: e58d64a16abc2304c4dcb644411eb9580bf63b1e

Since cc847bfd16d894fd8c1a2ce25f31772f6cdbbc74, CCID card-passthru
fails to intialize, because it changed a debug line to an error,
probably by mistake. Change it back to a DPRINTF debug.

(solves Boxes creating VM with smartcard passthru failing to start)

Signed-off-by: Marc-André Lureau <>
ahci fix PxCI register race.patch | (download)

hw/ide/ahci.c | 13 6 + 7 - 0 !
1 file changed, 6 insertions(+), 7 deletions(-)

 ahci: fix pxci register race

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.

Signed-off-by: John Snow <>

tcg i386 Fix dup_vec in non AVX2 codepath.patch | (download)

tcg/i386/ | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 tcg/i386: fix dup_vec in non-avx2 codepath
Commit-Id: 7eb30ef0ba2eb59e7430d4848ae8d4bf4e50f768

The VPUNPCKLD* instructions are all "non-destructive source",
indicated by "NDS" in the encoding string in the x86 ISA manual.
This means that they take two source operands, one of which is
encoded in the VEX.vvvv field. We were incorrectly treating them
as if they were destructive-source and passing 0 as the 'v'
argument of tcg_out_vex_modrm(). This meant we were always
using %xmm0 as one of the source operands, causing incorrect
results if the register allocator happened to want to use
something else. For instance the input AArch64 insn:
 DUP v26.16b, w21
which becomes TCG IR ops:
 dup_vec v128,e8,tmp2,x21
 st_vec v128,e8,tmp2,env,$0xa40
was assembled to:
0x607c568c:  c4 c1 7a 7e 86 e8 00 00  vmovq    0xe8(%r14), %xmm0
0x607c5694:  00
0x607c5695:  c5 f9 60 c8              vpunpcklbw %xmm0, %xmm0, %xmm1
0x607c5699:  c5 f9 61 c9              vpunpcklwd %xmm1, %xmm0, %xmm1
0x607c569d:  c5 f9 70 c9 00           vpshufd  $0, %xmm1, %xmm1
0x607c56a2:  c4 c1 7a 7f 8e 40 0a 00  vmovdqu  %xmm1, 0xa40(%r14)
0x607c56aa:  00

when the vpunpcklwd insn should be "%xmm1, %xmm1, %xmm1".
This resulted in our incorrectly setting the output vector to
when given an input of x21 == 0000000002803200
rather than the expected all-zeroes.

Pass the correct source register number to tcg_out_vex_modrm()
for these insns.

Fixes: 770c2fc7bb70804a
Signed-off-by: Peter Maydell <>
Message-Id: <>
Signed-off-by: Richard Henderson <>