Peter Maydell [Tue, 16 Jan 2018 14:18:20 +0000 (14:18 +0000)]
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180116' into staging
target-arm queue:
* SDHCI: cleanups and minor bug fixes
* target/arm: minor refactor preparatory to fp16 support
* omap_ssd, ssi-sd, pl181, milkymist-memcard: reset the SD
card on controller reset (fixes migration failures)
* target/arm: Handle page table walk load failures correctly
* hw/arm/virt: Add virt-2.12 machine type
* get_phys_addr_pmsav7: Support AP=0b111 for v7M
* hw/intc/armv7m: Support byte and halfword accesses to CFSR
* remotes/pmaydell/tags/pull-target-arm-20180116: (24 commits)
sdhci: add a 'dma' property to the sysbus devices
sdhci: fix the PCI device, using the PCI address space for DMA
sdhci: Implement write method of ACMD12ERRSTS register
sdhci: fix CAPAB/MAXCURR registers, both are 64bit and read-only
sdhci: rename the SDHC_CAPAB register
sdhci: move MASK_TRNMOD with other SDHC_TRN* defines in "sd-internal.h"
sdhci: convert the DPRINT() calls into trace events
sdhci: use qemu_log_mask(UNIMP) instead of fprintf()
sdhci: refactor common sysbus/pci unrealize() into sdhci_common_unrealize()
sdhci: refactor common sysbus/pci realize() into sdhci_common_realize()
sdhci: refactor common sysbus/pci class_init() into sdhci_common_class_init()
sdhci: use DEFINE_SDHCI_COMMON_PROPERTIES() for common sysbus/pci properties
sdhci: remove dead code
sdhci: clean up includes
target/arm: Add fp16 support to vfp_expand_imm
target/arm: Split out vfp_expand_imm
hw/sd/omap_mmc: Reset SD card on controller reset
hw/sd/ssi-sd: Reset SD card on controller reset
hw/sd/milkymist-memcard: Reset SD card on controller reset
hw/sd/pl181: Reset SD card on controller reset
...
sdhci: convert the DPRINT() calls into trace events
zero-initialize ADMADescr 'dscr' in sdhci_do_adma() to avoid:
hw/sd/sdhci.c: In function ‘sdhci_do_adma’:
hw/sd/sdhci.c:714:29: error: ‘dscr.addr’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
trace_sdhci_adma("link", s->admasysaddr);
^
Peter Maydell [Tue, 16 Jan 2018 13:28:13 +0000 (13:28 +0000)]
hw/sd/omap_mmc: Reset SD card on controller reset
Since omap_mmc is still using the legacy SD card API, the SD
card created by sd_init() is not plugged into any bus. This
means that the controller has to reset it manually.
Failing to do this mostly didn't affect the guest since the
guest typically does a programmed SD card reset as part of
its SD controller driver initialization, but would mean that
migration fails because it's only in sd_reset() that we
set up the wpgrps_size field.
Peter Maydell [Tue, 16 Jan 2018 13:28:12 +0000 (13:28 +0000)]
hw/sd/ssi-sd: Reset SD card on controller reset
Since ssi-sd is still using the legacy SD card API, the SD
card created by sd_init() is not plugged into any bus. This
means that the controller has to reset it manually.
Failing to do this mostly didn't affect the guest since the
guest typically does a programmed SD card reset as part of
its SD controller driver initialization, but meant that
migration failed because it's only in sd_reset() that we
set up the wpgrps_size field.
In the case of sd-ssi, we have to implement an entire
reset function since there wasn't one previously, and
that requires a QOM cast macro that got omitted when this
device was QOMified.
Peter Maydell [Tue, 16 Jan 2018 13:28:12 +0000 (13:28 +0000)]
hw/sd/milkymist-memcard: Reset SD card on controller reset
Since milkymist-memcard is still using the legacy SD card API,
the SD card created by sd_init() is not plugged into any bus.
This means that the controller has to reset it manually.
Failing to do this mostly didn't affect the guest since the
guest typically does a programmed SD card reset as part of
its SD controller driver initialization, but meant that
migration failed because it's only in sd_reset() that we
set up the wpgrps_size field.
Peter Maydell [Tue, 16 Jan 2018 13:28:11 +0000 (13:28 +0000)]
hw/sd/pl181: Reset SD card on controller reset
Since pl181 is still using the legacy SD card API, the SD
card created by sd_init() is not plugged into any bus. This
means that the controller has to reset it manually.
Failing to do this mostly didn't affect the guest since the
guest typically does a programmed SD card reset as part of
its SD controller driver initialization, but meant that
migration failed because it's only in sd_reset() that we
set up the wpgrps_size field.
Peter Maydell [Tue, 16 Jan 2018 13:28:11 +0000 (13:28 +0000)]
target/arm: Handle page table walk load failures correctly
Instead of ignoring the response from address_space_ld*()
(indicating an attempt to read a page table descriptor from
an invalid physical address), use it to report the failure
correctly.
Since this is another couple of locations where we need to
decide the value of the ARMMMUFaultInfo ea bit based on a
MemTxResult, we factor out that operation into a helper
function.
Peter Maydell [Tue, 16 Jan 2018 13:28:10 +0000 (13:28 +0000)]
get_phys_addr_pmsav7: Support AP=0b111 for v7M
For PMSAv7, the v7A/R Arm ARM defines that setting AP to 0b111
is an UNPREDICTABLE reserved combination. However, for v7M
this value is documented as having the same behaviour as 0b110:
read-only for both privileged and unprivileged. Accept this
value on an M profile core rather than treating it as a guest
error and a no-access page.
Peter Maydell [Tue, 16 Jan 2018 13:28:09 +0000 (13:28 +0000)]
hw/intc/armv7m: Support byte and halfword accesses to CFSR
The Configurable Fault Status Register for ARMv7M and v8M is
supposed to be byte and halfword accessible, but we were only
implementing word accesses. Add support for the other access
sizes, which are used by the Zephyr RTOS.
# gpg: Signature made Mon 15 Jan 2018 11:51:00 GMT
# gpg: using RSA key 0xF487EF185872D723
# gpg: Good signature from "Juan Quintela <[email protected]>"
# gpg: aka "Juan Quintela <[email protected]>"
# Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723
* remotes/juanquintela/tags/migration/20180115: (27 commits)
migration: remove notify in fd_error
migration: remove some block_cleanup_parameters()
migration: put the finish part into a new function
migration: major cleanup for migrate iterations
migration: cleanup stats update into function
migration: use switch at the end of migration
migration: introduce migrate_calculate_complete
migration: introduce downtime_start
migration: move vm_old_running into global state
migration: split use of MigrationState.total_time
migration: remove "enable_colo" var
migration: qemu_savevm_state_cleanup() in cleanup
migration: assert colo instead of check
migration: finalize current_migration object
migration: Guard ram_bytes_remaining against early call
migration: add postcopy total blocktime into query-migrate
migration: add blocktime calculation into migration-test
migration: postcopy_blocktime documentation
migration: calculate vCPU blocktime on dst side
migration: add postcopy blocktime ctx into MigrationIncomingState
...
Peter Xu [Wed, 3 Jan 2018 12:20:15 +0000 (20:20 +0800)]
migration: put the finish part into a new function
This patch only moved the last part of migration_thread() into a new
function migration_iteration_finish() to make it much shorter. With
previous works to remove some local variables, now it's fairly easy to
do that.
Peter Xu [Wed, 3 Jan 2018 12:20:13 +0000 (20:20 +0800)]
migration: cleanup stats update into function
We have quite a few lines in migration_thread() that calculates some
statistics for the migration interations. Isolate it into a single
function to improve readability.
Peter Xu [Wed, 3 Jan 2018 12:20:12 +0000 (20:20 +0800)]
migration: use switch at the end of migration
It converts the old if clauses into switch, explicitly mentions the
possible migration states. The old nested "if"s are not clear on what
we do on different states.
Peter Xu [Wed, 3 Jan 2018 12:20:09 +0000 (20:20 +0800)]
migration: move vm_old_running into global state
Firstly, it was passed around. Let's just move it into MigrationState
just like many other variables as state of migration, renaming it to
vm_was_running.
One thing to mention is that for postcopy, we actually don't need this
knowledge at all since postcopy can't resume a VM even if it fails (we
can see that from the old code too: when we try to resume we also check
against "entered_postcopy" variable). So further we do this:
- in postcopy_start(), we don't update vm_old_running since useless
- in migration_thread(), we don't need to check entered_postcopy when
resume, since it's only used for precopy.
Comment this out too for that variable definition.
Peter Xu [Wed, 3 Jan 2018 12:20:05 +0000 (20:20 +0800)]
migration: assert colo instead of check
When reaching here if we are still "active" it means we must be in colo
state. After a quick discussion offlist, we decided to use the safer
error_report().
Finally I want to use "switch" here rather than lots of complicated if
clauses.
migration: Guard ram_bytes_remaining against early call
Calling ram_bytes_remaining during the early part of setup is unsafe
because the ram_state isn't yet initialised.
This can happen in the sequence:
migrate
migrate_cancel
info migrate
if the migrate sticks trying to connect (e.g. to an unresponsive
destination due to the connect timeout). Here 'info migrate' sees
a state of CANCELLING and so assumes the migrate has partially happened.
Alexey Perevalov [Mon, 30 Oct 2017 13:16:30 +0000 (16:16 +0300)]
migration: add postcopy total blocktime into query-migrate
Postcopy total blocktime is available on destination side only.
But query-migrate was possible only for source. This patch
adds ability to call query-migrate on destination.
To be able to see postcopy blocktime, need to request postcopy-blocktime
capability.
The query-migrate command will show following sample result:
{"return":
"postcopy-vcpu-blocktime": [115, 100],
"status": "completed",
"postcopy-blocktime": 100
}}
postcopy_vcpu_blocktime contains list, where the first item is the first
vCPU in QEMU.
This patch has a drawback, it combines states of incoming and
outgoing migration. Ongoing migration state will overwrite incoming
state. Looks like better to separate query-migrate for incoming and
outgoing migration or add parameter to indicate type of migration.
Alexey Perevalov [Mon, 30 Oct 2017 13:16:27 +0000 (16:16 +0300)]
migration: calculate vCPU blocktime on dst side
This patch provides blocktime calculation per vCPU,
as a summary and as a overlapped value for all vCPUs.
This approach was suggested by Peter Xu, as an improvements of
previous approch where QEMU kept tree with faulted page address and cpus bitmask
in it. Now QEMU is keeping array with faulted page address as value and vCPU
as index. It helps to find proper vCPU at UFFD_COPY time. Also it keeps
list for blocktime per vCPU (could be traced with page_fault_addr)
Blocktime will not calculated if postcopy_blocktime field of
MigrationIncomingState wasn't initialized.
Alexey Perevalov [Mon, 30 Oct 2017 13:16:26 +0000 (16:16 +0300)]
migration: add postcopy blocktime ctx into MigrationIncomingState
This patch adds request to kernel space for UFFD_FEATURE_THREAD_ID, in
case this feature is provided by kernel.
PostcopyBlocktimeContext is encapsulated inside postcopy-ram.c,
due to it being a postcopy-only feature.
Also it defines PostcopyBlocktimeContext's instance live time.
Information from PostcopyBlocktimeContext instance will be provided
much after postcopy migration end, instance of PostcopyBlocktimeContext
will live till QEMU exit, but part of it (vcpu_addr,
page_fault_vcpu_time) used only during calculation, will be released
when postcopy ended or failed.
To enable postcopy blocktime calculation on destination, need to
request proper compatibility (Patch for documentation will be at the
tail of the patch set).
As an example following command enable that capability, assume QEMU was
started with
-chardev socket,id=charmonitor,path=/var/lib/migrate-vm-monitor.sock
option to control it
Right now it could be used on destination side to
enable vCPU blocktime calculation for postcopy live migration.
vCPU blocktime - it's time since vCPU thread was put into
interruptible sleep, till memory page was copied and thread awake.
Laurent Vivier [Tue, 5 Dec 2017 12:27:40 +0000 (13:27 +0100)]
migration: fix analyze-migration.py script with radix table
Since commit 3a38429748 ("Add a "no HPT" encoding to HTAB migration stream")
the HTAB migration stream contains a header set to "-1", meaning there
is no HPT. Teach analyze-migration.py to ignore the section in this case.
Without this fix, the script fails with a dump from a POWER9 guest:
Traceback (most recent call last):
File "./qemu/scripts/analyze-migration.py", line 602, in <module>
dump.read(dump_memory = args.memory)
File "./qemu/scripts/analyze-migration.py", line 539, in read
section.read()
File "./qemu/scripts/analyze-migration.py", line 250, in read
self.file.readvar(n_valid * self.HASH_PTE_SIZE_64)
File "./qemu/scripts/analyze-migration.py", line 64, in readvar
raise Exception("Unexpected end of %s at 0x%x" % (self.filename, self.file.tell()))
Exception: Unexpected end of migrate.dump at 0x1d4763ba
slirp: avoid IN6_IS_ADDR_UNSPECIFIED(), rather use in6_zero()
Host: Mac OS 10.12.5
Compiler: Apple LLVM version 8.1.0 (clang-802.0.42)
slirp/ip6_icmp.c:80:38: warning: taking address of packed member 'ip_src' of class or
structure 'ip6' may result in an unaligned pointer value
[-Waddress-of-packed-member]
IN6_IS_ADDR_UNSPECIFIED(&ip->ip_src)) {
^~~~~~~~~~
/usr/include/netinet6/in6.h:238:42: note: expanded from macro 'IN6_IS_ADDR_UNSPECIFIED'
((*(const __uint32_t *)(const void *)(&(a)->s6_addr[0]) == 0) && \
^
* remotes/kraxel/tags/ui-20180112-pull-request:
sdl2: Ignore UI hotkeys after a focus change when GUI modifier is held
sdl2 uses surface relative coordinates
sdl2: Do not hide the cursor on auxilliary windows
spice: remove unused timer list
spice: remove only written event_mask field
spice: remove unused watch list
spice: remove QXLWorker interface field
ui: deprecate use of GTK 2.x in favour of 3.x series
input: fix memory leak
* remotes/kraxel/tags/vnc-20180112-pull-request:
ui: mix misleading comments & return types of VNC I/O helper methods
ui: add trace events related to VNC client throttling
ui: place a hard cap on VNC server output buffer size
ui: fix VNC client throttling when forced update is requested
ui: fix VNC client throttling when audio capture is active
ui: refactor code for determining if an update should be sent to the client
ui: correctly reset framebuffer update state after processing dirty regions
ui: introduce enum to track VNC client framebuffer update request state
ui: track how much decoded data we consumed when doing SASL encoding
ui: avoid pointless VNC updates if framebuffer isn't dirty
ui: remove redundant indentation in vnc_client_update
ui: remove unreachable code in vnc_update_client
ui: remove 'sync' parameter from vnc_update_client
vnc: fix debug spelling
sdl2: Ignore UI hotkeys after a focus change when GUI modifier is held
When SDL2 windows change focus while a key is held, the window that
receives the focus also receives a new KeyDown event, without an
autorepeat flag. This means that if a WM places the qemu console
over the main window after Ctrl-Alt-2, the console closes immediately
after opening. Then, the main window receives the KeyDown event again
and the whole process repeats.
This patch makes the SDL2 UI ignore the KeyDown events on a window that
just received the focus, if the GUI modifier was held. The ignore flag
is reset on a first KeyUp event. This effectively works around the issue
above.
Peter Maydell [Fri, 12 Jan 2018 13:08:48 +0000 (13:08 +0000)]
target/xtensa: Remove duplicate typedef of DisasContext
Some older versions of gcc complain if a typedef is defined twice:
target/xtensa/translate.c:81: error: redefinition of typedef 'DisasContext'
target/xtensa/cpu.h:339: note: previous declaration of 'DisasContext' was here
Remove the now-redundant typedef from the definition of the struct in
translate.c.
While the QIOChannel APIs for reading/writing data return ssize_t, with negative
value indicating an error, the VNC code passes this return value through the
vnc_client_io_error() method. This detects the error condition, disconnects the
client and returns 0 to indicate error. Thus all the VNC helper methods should
return size_t (unsigned), and misleading comments which refer to the possibility
of negative return values need fixing.
ui: place a hard cap on VNC server output buffer size
The previous patches fix problems with throttling of forced framebuffer updates
and audio data capture that would cause the QEMU output buffer size to grow
without bound. Those fixes are graceful in that once the client catches up with
reading data from the server, everything continues operating normally.
There is some data which the server sends to the client that is impractical to
throttle. Specifically there are various pseudo framebuffer update encodings to
inform the client of things like desktop resizes, pointer changes, audio
playback start/stop, LED state and so on. These generally only involve sending
a very small amount of data to the client, but a malicious guest might be able
to do things that trigger these changes at a very high rate. Throttling them is
not practical as missed or delayed events would cause broken behaviour for the
client.
This patch thus takes a more forceful approach of setting an absolute upper
bound on the amount of data we permit to be present in the output buffer at
any time. The previous patch set a threshold for throttling the output buffer
by allowing an amount of data equivalent to one complete framebuffer update and
one seconds worth of audio data. On top of this it allowed for one further
forced framebuffer update to be queued.
To be conservative, we thus take that throttling threshold and multiply it by
5 to form an absolute upper bound. If this bound is hit during vnc_write() we
forceably disconnect the client, refusing to queue further data. This limit is
high enough that it should never be hit unless a malicious client is trying to
exploit the sever, or the network is completely saturated preventing any sending
of data on the socket.
This completes the fix for CVE-2017-15124 started in the previous patches.
ui: fix VNC client throttling when forced update is requested
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check is disabled if the client has requested
a forced update, because we want to send these as soon as possible.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then repeatedly send full framebuffer update
requests, but never read data back from the server. This can easily make QEMU's
VNC server send buffer consume 100MB of RAM per second, until the OOM killer
starts reaping processes (hopefully the rogue QEMU process, but it might pick
others...).
To address this we make the throttling more intelligent, so we can throttle
full updates. When we get a forced update request, we keep track of exactly how
much data we put on the output buffer. We will not process a subsequent forced
update request until this data has been fully sent on the wire. We always allow
one forced update request to be in flight, regardless of what data is queued
for incremental updates or audio data. The slight complication is that we do
not initially know how much data an update will send, as this is done in the
background by the VNC job thread. So we must track the fact that the job thread
has an update pending, and not process any further updates until this job is
has been completed & put data on the output buffer.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
ui: fix VNC client throttling when audio capture is active
The VNC server must throttle data sent to the client to prevent the 'output'
buffer size growing without bound, if the client stops reading data off the
socket (either maliciously or due to stalled/slow network connection).
The current throttling is very crude because it simply checks whether the
output buffer offset is zero. This check must be disabled if audio capture is
enabled, because when streaming audio the output buffer offset will rarely be
zero due to queued audio data, and so this would starve framebuffer updates.
As a result, the VNC client can cause QEMU to allocate arbitrary amounts of RAM.
They can first start something in the guest that triggers lots of framebuffer
updates eg play a youtube video. Then enable audio capture, and simply never
read data back from the server. This can easily make QEMU's VNC server send
buffer consume 100MB of RAM per second, until the OOM killer starts reaping
processes (hopefully the rogue QEMU process, but it might pick others...).
To address this we make the throttling more intelligent, so we can throttle
when audio capture is active too. To determine how to throttle incremental
updates or audio data, we calculate a size threshold. Normally the threshold is
the approximate number of bytes associated with a single complete framebuffer
update. ie width * height * bytes per pixel. We'll send incremental updates
until we hit this threshold, at which point we'll stop sending updates until
data has been written to the wire, causing the output buffer offset to fall
back below the threshold.
If audio capture is enabled, we increase the size of the threshold to also
allow for upto 1 seconds worth of audio data samples. ie nchannels * bytes
per sample * frequency. This allows the output buffer to have a mixture of
incremental framebuffer updates and audio data queued, but once the threshold
is exceeded, audio data will be dropped and incremental updates will be
throttled.
This unbounded memory growth affects all VNC server configurations supported by
QEMU, with no workaround possible. The mitigating factor is that it can only be
triggered by a client that has authenticated with the VNC server, and who is
able to trigger a large quantity of framebuffer updates or audio samples from
the guest OS. Mostly they'll just succeed in getting the OOM killer to kill
their own QEMU process, but its possible other processes can get taken out as
collateral damage.
This is a more general variant of the similar unbounded memory usage flaw in
the websockets server, that was previously assigned CVE-2017-15268, and fixed
in 2.11 by:
ui: refactor code for determining if an update should be sent to the client
The logic for determining if it is possible to send an update to the client
will become more complicated shortly, so pull it out into a separate method
for easier extension later.
ui: correctly reset framebuffer update state after processing dirty regions
According to the RFB protocol, a client sends one or more framebuffer update
requests to the server. The server can reply with a single framebuffer update
response, that covers all previously received requests. Once the client has
read this update from the server, it may send further framebuffer update
requests to monitor future changes. The client is free to delay sending the
framebuffer update request if it needs to throttle the amount of data it is
reading from the server.
The QEMU VNC server, however, has never correctly handled the framebuffer
update requests. Once QEMU has received an update request, it will continue to
send client updates forever, even if the client hasn't asked for further
updates. This prevents the client from throttling back data it gets from the
server. This change fixes the flawed logic such that after a set of updates are
sent out, QEMU waits for a further update request before sending more data.
ui: introduce enum to track VNC client framebuffer update request state
Currently the VNC servers tracks whether a client has requested an incremental
or forced update with two boolean flags. There are only really 3 distinct
states to track, so create an enum to more accurately reflect permitted states.
ui: track how much decoded data we consumed when doing SASL encoding
When we encode data for writing with SASL, we encode the entire pending output
buffer. The subsequent write, however, may not be able to send the full encoded
data in one go though, particularly with a slow network. So we delay setting the
output buffer offset back to zero until all the SASL encoded data is sent.
Between encoding the data and completing sending of the SASL encoded data,
however, more data might have been placed on the pending output buffer. So it
is not valid to set offset back to zero. Instead we must keep track of how much
data we consumed during encoding and subtract only that amount.
With the current bug we would be throwing away some pending data without having
sent it at all. By sheer luck this did not previously cause any serious problem
because appending data to the send buffer is always an atomic action, so we
only ever throw away complete RFB protocol messages. In the case of frame buffer
updates we'd catch up fairly quickly, so no obvious problem was visible.
ui: avoid pointless VNC updates if framebuffer isn't dirty
The vnc_update_client() method checks the 'has_dirty' flag to see if there are
dirty regions that are pending to send to the client. Regardless of this flag,
if a forced update is requested, updates must be sent. For unknown reasons
though, the code also tries to sent updates if audio capture is enabled. This
makes no sense as audio capture state does not impact framebuffer contents, so
this check is removed.
Added a check for vs->disconnecting at the very start of the
vnc_update_client method. This means that the very next "if"
statement check for !vs->disconnecting always evaluates true,
and is thus redundant. This in turn means the vs->disconnecting
check at the very end of the method never evaluates true, and
is thus unreachable code.
Peter Maydell [Fri, 12 Jan 2018 09:52:58 +0000 (09:52 +0000)]
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
pc, pci, virtio: features, fixes, cleanups
A bunch of fixes, cleanus and new features all over the place.
Signed-off-by: Michael S. Tsirkin <[email protected]>
# gpg: Signature made Thu 11 Jan 2018 20:04:57 GMT
# gpg: using RSA key 0x281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <[email protected]>"
# gpg: aka "Michael S. Tsirkin <[email protected]>"
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream: (23 commits)
smbus: do not immediately complete commands
dump-guest-memory.py: fix "You can't do that without a process to debug"
virtio-pci: Don't force Subsystem Vendor ID = Vendor ID
intel_iommu: fix error param in string
intel_iommu: remove X86_IOMMU_PCI_DEVFN_MAX
vhost-user: document memory accesses
vhost-user: fix indentation in protocol specification
hw/pci-host/xilinx: QOM'ify the AXI-PCIe host bridge
hw/pci-host/piix: QOM'ify the IGD Passthrough host bridge
tests/pxe-test: Add some extra tests
tests/pxe-test: Test net booting over IPv6 in some cases
tests/pxe-test: Use table of testcases rather than open-coding
tests/pxe-test: Remove unnecessary special case test functions
virtio_error: don't invoke status callbacks
pci: Eliminate pci_find_primary_bus()
pci: Eliminate redundant PCIDevice::bus pointer
pci: Add pci_dev_bus_num() helper
pci: Move bridge data structures from pci_bus.h to pci_bridge.h
pci: Rename root bus initialization functions for clarity
tests: add test to check VirtQueue object
...
* remotes/pmaydell/tags/pull-target-arm-20180111: (26 commits)
hw/intc/arm_gic: reserved register addresses are RAZ/WI
hw/intc/arm_gicv3: Make reserved register addresses RAZ/WI
target/arm: Make disas_thumb2_insn() generate its own UNDEF exceptions
linux-user/arm/nwfpe: Check coprocessor number for FPA emulation
hw/sd/pxa2xx_mmci: add read/write() trace events
hw/timer/pxa2xx_timer: replace hw_error() -> qemu_log_mask()
imx_fec: Reserve full FSL_IMX25_FEC_SIZE page for the register file
imx_fec: Fix a typo in imx_enet_receive()
imx_fec: Use correct length for packet size
imx_fec: Add support for multiple Tx DMA rings
imx_fec: Emulate SHIFT16 in ENETx_RACC
imx_fec: Use MIN instead of explicit ternary operator
imx_fec: Use ENET_FTRL to determine truncation length
imx_fec: Move Tx frame buffer away from the stack
imx_fec: Change queue flushing heuristics
imx_fec: Refactor imx_eth_enable_rx()
imx_fec: Do not link to netdev
Virt: ACPI: fix qemu assert due to re-assigned table data address
target/arm: Fix stlxp for aarch64_be
linux-user: Activate armeb handler registration
...
Peter Maydell [Thu, 11 Jan 2018 13:25:40 +0000 (13:25 +0000)]
hw/intc/arm_gic: reserved register addresses are RAZ/WI
The GICv2 specification says that reserved register addresses
must RAZ/WI; now that we implement external abort handling
for Arm CPUs this means we must return MEMTX_OK rather than
MEMTX_ERROR, to avoid generating a spurious guest data abort.
Peter Maydell [Thu, 11 Jan 2018 13:25:40 +0000 (13:25 +0000)]
hw/intc/arm_gicv3: Make reserved register addresses RAZ/WI
The GICv3 specification says that reserved register addresses
should RAZ/WI. This means we need to return MEMTX_OK, not MEMTX_ERROR,
because now that we support generating external aborts the
latter will cause an abort on new board models.
Peter Maydell [Thu, 11 Jan 2018 13:25:40 +0000 (13:25 +0000)]
target/arm: Make disas_thumb2_insn() generate its own UNDEF exceptions
Refactor disas_thumb2_insn() so that it generates the code for raising
an UNDEF exception for invalid insns, rather than returning a flag
which the caller must check to see if it needs to generate the UNDEF
code. This brings the function in to line with the behaviour of
disas_thumb_insn() and disas_arm_insn().
Peter Maydell [Thu, 11 Jan 2018 13:25:39 +0000 (13:25 +0000)]
linux-user/arm/nwfpe: Check coprocessor number for FPA emulation
Our copy of the nwfpe code for emulating of the old FPA11 floating
point unit doesn't check the coprocessor number in the instruction
when it emulates it. This means that we might treat some
instructions which should really UNDEF as being FPA11 instructions by
accident.
The kernel's copy of the nwfpe code doesn't make this error; I suspect
the bug was noticed and fixed as part of the process of mainlining
the nwfpe code more than a decade ago.
Add a check that the coprocessor number (which is always in bits
[11:8] of the instruction) is either 1 or 2, which is where the
FPA11 lives.
Andrey Smirnov [Thu, 11 Jan 2018 13:25:38 +0000 (13:25 +0000)]
imx_fec: Reserve full FSL_IMX25_FEC_SIZE page for the register file
Some i.MX SoCs (e.g. i.MX7) have FEC registers going as far as offset
0x614, so to avoid getting aborts when accessing those on QEMU, extend
the register file to cover FSL_IMX25_FEC_SIZE(16K) of address space
instead of just 1K.
Andrey Smirnov [Thu, 11 Jan 2018 13:25:37 +0000 (13:25 +0000)]
imx_fec: Use correct length for packet size
Use 'frame_size' instead of 'len' when calling qemu_send_packet(),
failing to do so results in malformed packets send in case when that
packed is fragmented into multiple DMA transactions.
projects / qemu.git / log