This is the refresh interval used when the user is actively providing
input (moving the mouse around) vs idle. Since this refresh event is
used to create vsync, this can cause some games which use vsync for
timekeeping to advance faster when moving the mouse around or using the
keyboard. For example, in the Halo:CE main menu, when moving the mouse
around the background animation will run a little faster.
Marking all pages as always dirty has some really bad consequences for
the current NV2A emulation. The lesser of two evils for now is to leave
the pages as-is. Eventually this will be replaced by proper dirty page
tracking once HAXM supports it.
QEMU core will call this handler when a RAM block is removed (no
surprises there), but it does _not_ check to see if this handler is
non-NULL. Add a dummy handler for now.
If gpa is exactly the start address of one slot, the
old code fails to find the slot. Change to use one byte
range to find slot.
Change-Id: I169ec8f759bb211a5ea7c693c5d99f27576c2e93
Signed-off-by: Tao Wu <lepton@google.com>
* Port espes's fifo work to the split up nv2a code
This patch ports over the following commits from the XQEMU 1.x tree
(available via tag archive-xqemu-1.x) to the refactored nv2a code:
- 4d9107e8 (HEAD -> xbox, upstream/xbox) Merge branch 'fix-fifo' into xbox
- c33f4ab2 cleanups
- d3f83d93 cleanups
- faca5dd0 fix
- 7c62d7c1 fixes
- 8ad239b0 wip
- 45ed3c31 wip
- c006d5e8 wip
However, in its current form, this patch causes some regressions and
needs further investigation.
* nv2a: basic pattern object
This updates XQEMU's QEMU code base from v2.12.0 to v3.0.0. A few minor fixups were necessary due to core changes. Basic testing done on Ubuntu 18.04, macOS, and Windows.
With vga=775 on the Linux command line a first boot of the VM running
Linux works fine. After a warm reboot it crashes during Linux boot.
Before that, valgrind points out bad memory write to console
surface. The VGA code is not aware that virtio-gpu got a message
surface scanout when the display is disabled. Let's reset VGA graphic
mode when it is the case, so that a new display surface is created
when doing further VGA operations.
https://bugs.launchpad.net/qemu/+bug/1784900/
Reported-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Tested-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Message-id: 20180803153235.4134-1-marcandre.lureau@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
The data in an mbuf buffer is not necessarily at the start of the
allocated buffer. (For instance m_adj() allows data to be trimmed
from the start by just advancing the pointer and reducing the length.)
This means that the allocated buffer size (m->m_size) and the
amount of space from the m_data pointer to the end of the
buffer (M_ROOM(m)) are not necessarily the same.
Commit 864036e251 tried to change the m_inc() function from
taking the new allocated-buffer-size to taking the new room-size,
but forgot to change the initial "do we already have enough space"
check. This meant that if we were trying to extend a buffer which
had a leading gap between the buffer start and the data, we might
incorrectly decide it didn't need to be extended, and then
overrun the end of the buffer, causing memory corruption and
an eventual crash.
Change the "already big enough?" condition from checking the
argument against m->m_size to checking against M_ROOM().
This only makes a difference for the callsite in m_cat();
the other three callsites all start with a freshly allocated
mbuf from m_get(), which will have m->m_size == M_ROOM(m).
Fixes: 864036e251
Fixes: https://bugs.launchpad.net/qemu/+bug/1785670
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Message-id: 20180807114501.12370-1-peter.maydell@linaro.org
Tested-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
The instance_init function of the xtensa CPUs creates a memory region,
but does not set an owner, so the memory region is not destroyed
correctly when the CPU object is removed. This can happen when
introspecting the CPU devices, so introspecting the CPU device will
leave a dangling memory region object in the QOM tree. Make sure to
set the right owner here to fix this issue.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>
Message-id: 1532005320-17794-1-git-send-email-thuth@redhat.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
wutno