qemu tracks guest time based on vector [base_rtc, last_update], in which
last_update stands for a monotonic tick which is actually uptime of the
host.
according to rtc implementation codes of recent releases and upstream,
after
migration, the time base vector [base_rtc, last_update] isn't updated to
coordinate with the destionation host, ie. qemu doesnt update last_update
to
uptime of the destination host.
what problem have we got because of this bug? after migration, guest time
may
jump back to several days ago, that will make some critical business
applications,
such as lotus notes, malfunction.
this patch is trying to fix the problem. first, when vmsave in progress,
we
rtc_update_time to refresh time stamp in cmos array, then during
vmrestore,
we rtc_set_time to update qemu base_rtc and last_update variable according
to time
stamp in cmos array.
Signed-off-by: Junlian Bell <zhongjun@sangfor.com.cn>
Message-Id: <20160926124101.2364-1-zhongjun@sangfor.com.cn>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: David Kiarie <davidkiarie4@gmail.com>
Message-Id: <1475553808-13285-2-git-send-email-davidkiarie4@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Fix a memory leak in ide_register_restart_cb() in hw/ide/core.c and add
idebus_unrealize() in hw/ide/qdev.c to have calls to
qemu_del_vm_change_state_handler() to deal with the dangling change
state handler during hot-unplugging ide devices which might lead to a
crash.
Signed-off-by: Ashijeet Acharya <ashijeetacharya@gmail.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 1474995212-10580-1-git-send-email-ashijeetacharya@gmail.com
[Minor whitespace fix --js]
Signed-off-by: John Snow <jsnow@redhat.com>
The folder include/hw/ide/ belongs to the IDE section.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-id: 1474646996-30421-1-git-send-email-thuth@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Similar to existing fixes for IDE (87ac25fd) and ATAPI (7f951b2d), the
AIOCB must be cleared in the callback. Otherwise, we may accidentally
try to reset a dangling pointer in bdrv_aio_cancel() from a port reset.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1474575040-32079-2-git-send-email-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
ATA8-APT defines the state transitions for both a host controller and
for the hardware device during the lifecycle of a DMA transfer, in
section 9.7 "DMA command protocol."
One of the interesting tidbits here is that when a device transitions
from DDMA0 ("Prepare state") to DDMA1 ("Data_Transfer State"), it can
choose to set either BSY or DRQ to signal this transition, but not both.
as ide_sector_dma_start is the last point in our preparation process
before we begin the real data transfer process (for either AHCI or BMDMA),
this is the correct transition point for DDMA0 to DDMA1.
I have chosen !BSY && DRQ for QEMU to make the transition from DDMA0 the
most obvious.
Reported-by: Benjamin David Lunt <fys@fysnet.net>
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1470175541-19344-1-git-send-email-jsnow@redhat.com
Signed-off-by: John Snow <jsnow@redhat.com>
Explicitly state in which execution mode (user, softmmu, all) are guest
events available for tracing.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Message-id: 147456962135.11114.6146034359114598596.stgit@fimbulvetr.bsc.es
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Every time a vCPU is hot-plugged, it will "inherit" its tracing state
from the global state array. That is, if *any* existing vCPU has an
event enabled, new vCPUs will have too.
Signed-off-by: Lluís Vilanova <vilanova@ac.upc.edu>
Message-id: 147428970768.15111.7664565956870423529.stgit@fimbulvetr.bsc.es
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The trace points for hw/virtio/virtio-balloon.c were mistakenly put
in the top level trace-events file, instead of util/trace-events in
commit 270ab88f7c
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Thu Jun 16 09:39:57 2016 +0100
trace: split out trace events for hw/virtio/ directory
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1473872624-23285-5-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The trace points for hw/mem/pc-dimm.c were mistakenly put
in the hw/i386/trace-events file, instead of hw/mem/trace-events
in
commit 5eb76e480b
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Thu Jun 16 09:40:10 2016 +0100
trace: split out trace events for hw/i386/ directory
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1473872624-23285-4-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The trace points for util/qemu-coroutine*.c were mistakenly left
in the top level trace-events file, instead of util/trace-events
in
commit 492bb2dd65
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Thu Jun 16 09:39:48 2016 +0100
trace: split out trace events for util/ directory
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1473872624-23285-3-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
The trace points for util/buffer.c were mistakenly put
in the io/trace-events file, instead of util/trace-events
in
commit 892bd32ea3
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Thu Jun 16 09:39:50 2016 +0100
trace: split out trace events for io/ directory
Move all trace-events for files in the io/ directory to
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1473872624-23285-2-git-send-email-berrange@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Commit 0ed93d84ed ("linux-aio: process
completions from ioq_submit()") added an optimization that processes
completions each time ioq_submit() returns with requests in flight.
This commit introduces a "Co-routine re-entered recursively" error which
can be triggered with -drive format=qcow2,aio=native.
Fam Zheng <famz@redhat.com>, Kevin Wolf <kwolf@redhat.com>, and I
debugged the following backtrace:
(gdb) bt
#0 0x00007ffff0a046f5 in raise () at /lib64/libc.so.6
#1 0x00007ffff0a062fa in abort () at /lib64/libc.so.6
#2 0x0000555555ac0013 in qemu_coroutine_enter (co=0x5555583464d0) at util/qemu-coroutine.c:113
#3 0x0000555555a4b663 in qemu_laio_process_completions (s=s@entry=0x555557e2f7f0) at block/linux-aio.c:218
#4 0x0000555555a4b874 in ioq_submit (s=s@entry=0x555557e2f7f0) at block/linux-aio.c:331
#5 0x0000555555a4ba12 in laio_do_submit (fd=fd@entry=13, laiocb=laiocb@entry=0x555559d38ae0, offset=offset@entry=2932727808, type=type@entry=1) at block/linux-aio.c:383
#6 0x0000555555a4bbd3 in laio_co_submit (bs=<optimized out>, s=0x555557e2f7f0, fd=13, offset=2932727808, qiov=0x555559d38e20, type=1) at block/linux-aio.c:402
#7 0x0000555555a4fd23 in bdrv_driver_preadv (bs=bs@entry=0x55555663bcb0, offset=offset@entry=2932727808, bytes=bytes@entry=8192, qiov=qiov@entry=0x555559d38e20, flags=0) at block/io.c:804
#8 0x0000555555a52b34 in bdrv_aligned_preadv (bs=bs@entry=0x55555663bcb0, req=req@entry=0x555559d38d20, offset=offset@entry=2932727808, bytes=bytes@entry=8192, align=align@entry=512, qiov=qiov@entry=0x555559d38e20, flags=0) at block/io.c:1041
#9 0x0000555555a52db8 in bdrv_co_preadv (child=<optimized out>, offset=2932727808, bytes=8192, qiov=qiov@entry=0x555559d38e20, flags=flags@entry=0) at block/io.c:1133
#10 0x0000555555a29629 in qcow2_co_preadv (bs=0x555556635890, offset=6178725888, bytes=8192, qiov=0x555557527840, flags=<optimized out>) at block/qcow2.c:1509
#11 0x0000555555a4fd23 in bdrv_driver_preadv (bs=bs@entry=0x555556635890, offset=offset@entry=6178725888, bytes=bytes@entry=8192, qiov=qiov@entry=0x555557527840, flags=0) at block/io.c:804
#12 0x0000555555a52b34 in bdrv_aligned_preadv (bs=bs@entry=0x555556635890, req=req@entry=0x555559d39000, offset=offset@entry=6178725888, bytes=bytes@entry=8192, align=align@entry=1, qiov=qiov@entry=0x555557527840, flags=0) at block/io.c:1041
#13 0x0000555555a52db8 in bdrv_co_preadv (child=<optimized out>, offset=offset@entry=6178725888, bytes=bytes@entry=8192, qiov=qiov@entry=0x555557527840, flags=flags@entry=0) at block/io.c:1133
#14 0x0000555555a4515a in blk_co_preadv (blk=0x5555566356d0, offset=6178725888, bytes=8192, qiov=0x555557527840, flags=0) at block/block-backend.c:783
#15 0x0000555555a45266 in blk_aio_read_entry (opaque=0x5555577025e0) at block/block-backend.c:991
#16 0x0000555555ac0cfa in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:78
It turned out that re-entrant ioq_submit() and completion processing
between three requests caused this error. The following check is not
sufficient to prevent recursively entering coroutines:
if (laiocb->co != qemu_coroutine_self()) {
qemu_coroutine_enter(laiocb->co);
}
As the following coroutine backtrace shows, not just the current
coroutine (self) can be entered. There might also be other coroutines
that are currently entered and transferred control due to the qcow2 lock
(CoMutex):
(gdb) qemu coroutine 0x5555583464d0
#0 0x0000555555ac0c90 in qemu_coroutine_switch (from_=from_@entry=0x5555583464d0, to_=to_@entry=0x5555572f9890, action=action@entry=COROUTINE_ENTER) at util/coroutine-ucontext.c:175
#1 0x0000555555abfe54 in qemu_coroutine_enter (co=0x5555572f9890) at util/qemu-coroutine.c:117
#2 0x0000555555ac031c in qemu_co_queue_run_restart (co=co@entry=0x5555583462c0) at util/qemu-coroutine-lock.c:60
#3 0x0000555555abfe5e in qemu_coroutine_enter (co=0x5555583462c0) at util/qemu-coroutine.c:119
#4 0x0000555555a4b663 in qemu_laio_process_completions (s=s@entry=0x555557e2f7f0) at block/linux-aio.c:218
#5 0x0000555555a4b874 in ioq_submit (s=s@entry=0x555557e2f7f0) at block/linux-aio.c:331
#6 0x0000555555a4ba12 in laio_do_submit (fd=fd@entry=13, laiocb=laiocb@entry=0x55555a338b40, offset=offset@entry=2911477760, type=type@entry=1) at block/linux-aio.c:383
#7 0x0000555555a4bbd3 in laio_co_submit (bs=<optimized out>, s=0x555557e2f7f0, fd=13, offset=2911477760, qiov=0x55555a338e80, type=1) at block/linux-aio.c:402
#8 0x0000555555a4fd23 in bdrv_driver_preadv (bs=bs@entry=0x55555663bcb0, offset=offset@entry=2911477760, bytes=bytes@entry=8192, qiov=qiov@entry=0x55555a338e80, flags=0) at block/io.c:804
#9 0x0000555555a52b34 in bdrv_aligned_preadv (bs=bs@entry=0x55555663bcb0, req=req@entry=0x55555a338d80, offset=offset@entry=2911477760, bytes=bytes@entry=8192, align=align@entry=512, qiov=qiov@entry=0x55555a338e80, flags=0) at block/io.c:1041
#10 0x0000555555a52db8 in bdrv_co_preadv (child=<optimized out>, offset=2911477760, bytes=8192, qiov=qiov@entry=0x55555a338e80, flags=flags@entry=0) at block/io.c:1133
#11 0x0000555555a29629 in qcow2_co_preadv (bs=0x555556635890, offset=6157475840, bytes=8192, qiov=0x5555575df720, flags=<optimized out>) at block/qcow2.c:1509
#12 0x0000555555a4fd23 in bdrv_driver_preadv (bs=bs@entry=0x555556635890, offset=offset@entry=6157475840, bytes=bytes@entry=8192, qiov=qiov@entry=0x5555575df720, flags=0) at block/io.c:804
#13 0x0000555555a52b34 in bdrv_aligned_preadv (bs=bs@entry=0x555556635890, req=req@entry=0x55555a339060, offset=offset@entry=6157475840, bytes=bytes@entry=8192, align=align@entry=1, qiov=qiov@entry=0x5555575df720, flags=0) at block/io.c:1041
#14 0x0000555555a52db8 in bdrv_co_preadv (child=<optimized out>, offset=offset@entry=6157475840, bytes=bytes@entry=8192, qiov=qiov@entry=0x5555575df720, flags=flags@entry=0) at block/io.c:1133
#15 0x0000555555a4515a in blk_co_preadv (blk=0x5555566356d0, offset=6157475840, bytes=8192, qiov=0x5555575df720, flags=0) at block/block-backend.c:783
#16 0x0000555555a45266 in blk_aio_read_entry (opaque=0x555557231aa0) at block/block-backend.c:991
#17 0x0000555555ac0cfa in coroutine_trampoline (i0=<optimized out>, i1=<optimized out>) at util/coroutine-ucontext.c:78
Use the new qemu_coroutine_entered() function instead of comparing
against qemu_coroutine_self(). This is correct because:
1. If a coroutine is not entered then it must have yielded to wait for
I/O completion. It is therefore safe to enter.
2. If a coroutine is entered then it must be in
ioq_submit()/qemu_laio_process_completions() because otherwise it
would be yielded while waiting for I/O completion. Therefore it will
check laio->ret and return from ioq_submit() instead of yielding,
i.e. it's guaranteed not to hang.
Reported-by: Fam Zheng <famz@redhat.com>
Tested-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Message-id: 1474989516-18255-4-git-send-email-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
See the doc comments for a description of this new coroutine API.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Message-id: 1474989516-18255-2-git-send-email-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This fixes problems with translated set 1, where most make code were wrong.
This fixes problems with set 3 for extended keys (like arrows) and lot of other keys.
Added a FIXME for set 3, where most keys must not (by default) deliver a break code.
Detailed list of changes on untranslated set 2:
- change of ALTGR break code from 0xe4 to 0xf0 0x08
- change of ALTGR_R break code from 0xe0 0xe4 to 0xe0 0xf0 0x08
- change of F7 make code from 0x02 to 0x83
- change of F7 break code from 0xf0 0x02 to 0xf0 0x83
- change of PRINT make code from 0xe0 0x7c to 0xe0 0x12 0xe0 0x7c
- change of PRINT break code from 0xe0 0xf0 0x7c to 0xe0 0xf0 0x7c 0xe0 0xf0 0x12
- change of PAUSE key: new make code = old make code + old break code, no more break code
- change on RO break code from 0xf3 to 0xf0 0x51
- change on KP_COMMA break code from 0xfe to 0xf0 0x6d
Detailed list of changes on translated set 2 (the most commonly used):
- change of PRINT make code from 0xe0 0x37 to 0xe0 0x2a 0xe0 0x37
- change of PRINT break code from 0xe0 0xb7 to 0xe0 0xb7 0xe0 0xaa
- change of PAUSE key: new make code = old make code + old break code, no more break code
Reference:
http://www.computer-engineering.org/ps2keyboard/scancodes1.htmlhttp://www.computer-engineering.org/ps2keyboard/scancodes2.htmlhttp://www.computer-engineering.org/ps2keyboard/scancodes3.html
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-id: 1473969987-5890-5-git-send-email-hpoussin@reactos.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Change ps2_put_keycode to get an untranslated scancode, which is translated if needed.
As qemu_input_key_value_to_scancode() gives translated scancodes, untranslate them
in ps2_keyboard_event first before giving them to ps2_put_keycode.
Results are not changed, except for some keys in translated set 3.
Translation table is available at
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-id: 1473969987-5890-4-git-send-email-hpoussin@reactos.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When getting scancode, current scancode must be preceded from reply ack.
When setting scancode, we must reject invalid scancodes.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Message-id: 1473969987-5890-3-git-send-email-hpoussin@reactos.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When enabling the sanitizer build it will complain about control
reaching a non-void function. Normally the compiler should detect that
there is only one possible exit given a static VNC_SERVER_FB_BYTES.
As we always expect a static VNC_SERVER_FB_BYTES I've added a compile
time assert and just called the sub-function directly.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This switches over spice (in opengl mode) to render DisplaySurface
updates into a opengl texture, using the helper functions in
ui/console-gl.c. With this patch applied spice (with gl=on) will
stop using qxl rendering ops, it will use dma-buf passing all the
time, i.e. for bios/bootloader (before virtio-gpu driver is loaded)
too.
This should improve performance even using spice (with gl=on) with
non-accelerated stdvga because we stop squeezing all display updates
through a unix/tcp socket and basically using a shared memory transport
instead.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-id: 1474617028-3979-3-git-send-email-kraxel@redhat.com
Keep track of gl_block state (added in bba19b8 console: block rendering
until client is done) in QemuConsole and allow to query it. This way
we can avoid state inconsistencies in case different code paths make use
of this.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 1474617028-3979-2-git-send-email-kraxel@redhat.com
virtio-gpu does a set-scanout at each frame (it might be a driver
regression). qemu_console_resize() recreate a surface even if the size
didn't change, and this shows up in profiling reports because the
surface is cleared. With this patch, I get a +15-20% glmark2
improvement.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 20160826094711.14470-1-marcandre.lureau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
"vq->desc[i].addr" is a 64bit value,
so write it with writeq(), not writew().
struct vring_desc {
__virtio64 addr;
__virtio32 len;
__virtio16 flags;
__virtio16 next;
};
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Message-id: 1474903450-9605-1-git-send-email-lvivier@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
if iothread->ctx is set to NULL, aio_context_unref triggers the assertion:
g_source_unref: assertion 'source != NULL' failed.
The patch fixes it.
Signed-off-by: Lin Ma <lma@suse.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 20160926052958.10716-1-lma@suse.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
As epoll whether enabled or not is a global setting, we can just
check it only once rather than checking it with every node iteration.
Through this we can avoid a lot of checks when epoll is not enabled.
Signed-off-by: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Reviewed-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Message-id: 1473851019-7005-3-git-send-email-baiyaowei@cmss.chinamobile.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Obviously, we should write to '@target'.
Signed-off-by: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Reviewed-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 1473851019-7005-2-git-send-email-baiyaowei@cmss.chinamobile.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Add a test for the newly implemented ADDC instruction in the v17 CRIS
CPU.
Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
In the CRIS v17 CPU an ADDC (add with carry) instruction has been added
compared to the v10 instruction set.
Assembler syntax:
ADDC [Rs],Rd
ADDC [Rs+],Rd
Size: Dword
Description:
The source data is added together with the carry flag to the
destination register. The size of the operation is dword.
Operation:
Rd += s + C-flag;
Flags affected:
S R P U I X N Z V C
- - - - - 0 * * * *
Instruction format: ADDC [Rs],Rd
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|Destination(Rd)| 1 0 0 1 1 0 1 0 | Source(Rs) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Instruction format: ADDC [Rs+],Rd
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|Destination(Rd)| 1 1 0 1 1 0 1 0 | Source(Rs) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
[EI: Shorten 80+ lines]
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Use the correct register names for v10 and don't dump support function
registers for pre-v32.
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Hans-Peter Nilsson <hp@axis.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
This test, borrowed from the GDB simulator test suite, checks that every
syscall increments the time returned by gettimeofday() by exactly 1 ms.
This is not guaranteed or even desirable on QEMU so remove this test.
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
This test, borrowed from the GDB simulator test suite, is meant to test
the GDB simulator's --sysroot feature and always fails in QEMU. Remove
it. openpf3 tests the same sequence of system calls (without assuming
the precence of --sysroot).
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Add the appropriate register constraints for the inline asm for the
write and exit system calls. Without the correct constraints for the
write() function, correct failure messages are not printed succesfully
on newer version of GCC.
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
The CRIS tests expect that functions marked inline are always inline.
With newer versions of GCC, building them results warnings like the
following and spurious failures when they are run.
In file included from tests/tcg/cris/check_moveq.c:5:0:
tests/tcg/cris/crisutils.h:66:20: warning: inlining failed in call to
'cris_tst_cc.constprop.0': call is unlikely and code size would grow [-Winline]
tests/tcg/cris/check_moveq.c:28:13: warning: called from here [-Winline]
Use the always_inline attribute when building them to fix this.
Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Signed-off-by: Rabin Vincent <rabinv@axis.com>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
Copy data operated on during request from/to local buffers to/from
the grant references.
Before grant copy operation local buffers must be allocated what is
done by calling ioreq_init_copy_buffers. For the 'read' operation,
first, the qemu device invokes the read operation on local buffers
and on the completion grant copy is called and buffers are freed.
For the 'write' operation grant copy is performed before invoking
write by qemu device.
A new value 'feature_grant_copy' is added to recognize when the
grant copy operation is supported by a guest.
Signed-off-by: Paulina Szubarczyk <paulinaszubarczyk@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJX6tIeAAoJECgHk2+YTcWm1HMQAJQfxCT4nHpiRC6Shl/cfobU
1WMeHNzwfIq6PGIZZW+6QntLD5qyvk4hP8i3k71qAN9YciFdtjw4YD1v6tKd/pTz
YDL+NVIwflKU4yxvmUY2X/ZqD40zeBd1RhOBdlt1clKZDkRNvBi7TL8oX3daEi02
0cLsUzVIL3FtrxZCnF5QVEydH0mA5lCBA/qNQOeJmZf1sPBgwzPe/2AxJ8UBYtdT
djBE07C0iLWFNc21mIph1ejONTqswgZT78Mjk7y4YCQ0wXYTdz1vzLVPur9e1hUE
OOJLOKMqs1tn5qbUTJGpmNgOlyF2VTScEciyiBdARwWKww3W3cP/u38obo74NH79
FuY5V8hK673Y7zyt6CxMfQT/2txddOcDakMwSNBPb14BssbyPbknzhw6ff2iGIab
N+h7+jxZHlR9ZQGSuftEy9HALRkMw30jJvJQDXrzA0ASpyil+cJ6fltCznYaLhTy
m5qU5f63T8XS3j2mNwQmf2OEfAnKA4nthQhMZSzXRiNeQwaDJ9j63dljlIjQcdUb
I1VgjpKcBK/Cd+UnRZov96Ovak6m59Tcvu2Y3HYXmKJ/CyAnADC58gxOQBJeliOD
PMFTpeCe5/0tWCTlqYv989F5uoUMbY5LSL+1WM0nDZ63YXtSIM82lIMZA9HBhJDN
hQ35XM4z7WD5q/8+BCzg
=upBR
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into staging
x86 and machine queue, 2016-09-27
# gpg: Signature made Tue 27 Sep 2016 21:10:06 BST
# gpg: using RSA key 0x2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/x86-pull-request:
sysbus: Remove ignored return value of FindSysbusDeviceFunc
target-i386: Remove has_msr_* global vars for KVM features
target-i386: Clear KVM CPUID features if KVM is disabled
target-i386: Remove has_msr_hv_tsc global variable
target-i386: Remove has_msr_hv_apic global variable
target-i386: Remove has_msr_mtrr global variable
target-i386: Move xsave component mask to features array
target-i386: xsave: Calculate set of xsave components on realize
target-i386: xsave: Helper function to calculate xsave area size
target-i386: xsave: Simplify CPUID[0xD,0].{EAX,EDX} calculation
target-i386: xsave: Calculate enabled components only once
target-i386: Don't try to enable PT State xsave component
target-i386: Move feature name arrays inside FeatureWordInfo
linux-user: remove #define smp_{cores, threads}
target-i386: Enable CPUID[0x8000000A] if SVM is enabled
target-i386: Automatically set level/xlevel/xlevel2 when needed
tests: Test CPUID level handling for old machines
tests: Add test code for CPUID level/xlevel handling
target-i386: Add a marker to end of the region zeroed on reset
target-i386: Remove unused X86CPUDefinition::xlevel2 field
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Functions of type FindSysbusDeviceFunc currently return an integer.
However, this return value is always ignored by the caller in
find_sysbus_device().
This changes the function type to return void, to avoid confusion over
the function semantics.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The global variables are not necessary because we can check KVM
feature flags in X86CPU directly.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
This will ensure all checks for features[FEAT_KVM] in the code
will be correct in case the KVM CPUID leaf is completely
disabled.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The global variable is not necessary because we can check
cpu->hyperv_time directly.
We just need to ensure cpu->hyperv_time will be cleared if the
feature is not really being exposed to the guest due to missing
KVM_CAP_HYPERV_TIME capability.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Junlian Bell