Bypass View does not cause issuing thread to block and does not affect
any of the cells state bit.
Read from a FIFO cell returns the value of the oldest entry.
Store to a FIFO cell changes the value of the newest entry.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
P/V Synchronized and Try Views can be used to access Semaphore cells.
Load returns current value and post-decrements the value in the cell
(until it reaches zero). Stores increment the value (until it saturates
at 0xFFFF).
P/V Synchronized View causes the issuing thread to block on read if value
is 0. P/V Try View does not block the thread, it returns 0 in this case.
Cell's Empty and Full bits are not modified.
Trap bit (i.e. Gating Storage exceptions) not implemented.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Empty/Full Synchronized and Try views can be used to access FIFO cells.
Store to the FIFO cell pushes the value into the queue, load pops the oldest
element from the queue. Cell's Full and Empty bits are automatically updated
to reflect new state of the cell.
Empty/Full Synchronized View causes the issuing thread to block when FIFO is
empty while thread is performing a read, or FIFO is full while thread is
performing a write.
Empty/Full Try View never blocks the thread. If cell is full then write is
ignored, if cell is empty then load returns 0.
Trap bit (i.e. Gating Storage exceptions) not implemented.
Store Conditional support for E/F Try View (i.e. indicate failure if FIFO
is full) not implemented.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Control view is used to access the ITC Storage Cell Tags. It never causes
the issuing thread to block.
Guest can empty the FIFO cell by setting Empty bit to 1.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Implement ITC as a single object consisting of two memory regions:
1) tag_io: ITC Configuration Tags (i.e. ITCAddressMap{0,1} registers) which
are accessible by the CPU via CACHE instruction. Also adding
MemoryRegion *itc_tag to the CPUMIPSState so that CACHE instruction will
dispatch reads/writes directly.
2) storage_io: memory-mapped ITC Storage whose address space is configurable
(i.e. enabled/remapped/resized) by writing to ITCAddressMap{0,1} registers.
ITC Storage contains FIFO and Semaphore cells. Read-only FIFO bit in the
ITC cell tag indicates the type of the cell. If the ITC Storage contains
both types of cells then FIFOs are located before Semaphores.
Since issuing thread can get blocked on the access to a cell (in E/F
Synchronized and P/V Synchronized Views) each cell has a bitmap to track
which threads are currently blocked.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Create Cluster Power Controller and add a link to the CPC MemoryRegion
in GCR. Guest can enable / map CPC to any physical address by writing to
the memory-mapped GCR_CPC_BASE register.
Set vp-start-reset property to 1 to allow only first VP to run from reset.
Others are brought up by the guest via CPC memory-mapped registers.
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Cluster Power Controller (CPC) is responsible for power management in
multiprocessing system. It provides registers to control the power and the
clock frequency of the individual elements in the system.
This patch implements only three registers that are used to control the
power state of each VP on a single core:
* VP Run is a write-only register used to set each VP to the run state
* VP Stop is a write-only register used to set each VP to the suspend state
* VP Running is a read-only register indicating the run state of each VP
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
Add initial GCR support to indicate number of VPs present in the system,
L2 bypass mode and revision number.
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
[leon.alrae@imgtec.com:
* removed GIC part,
* changed commit message,
* replaced %lx format spec. with PRIx64,
* renamed mips_gcr.{c,h} to mips_cmgcr.{c,h},
* replaced CONFIG_MIPS_GIC with CONFIG_MIPS_CPS]
Signed-off-by: Leon Alrae <leon.alrae@imgtec.com>
* Chardev fix from Marc-André
* config.status tweak from David
* Header file tweaks from Markus, myself and Veronia (Outreachy candidate)
* get_ticks_per_sec() removal from Rutuja (Outreachy candidate)
* Coverity fix from myself
* PKE implementation from myself, based on rth's XSAVE support
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAABCAAGBQJW9ErPAAoJEL/70l94x66DJfEH/A/QkMpAhrgNdyVsahzsGrzE
wx5gHFIc1nBYxyr62w4apUb5jPB7zaXu0LA7EAWDeAe0pyP8hZzLT9kJyOEDsuJu
zwKN2QeLSNMtPbnbKN0I/YQ2za2xX1V5ruhSeOJoVslUI214hgnAURaGshhQNzuZ
2CluDT9KgL5cQifAnKs5kJrwhIYShYNQB+1eDC/7wk28dd/EH+sPALIoF+rqrSmt
Zu4Mdqd+9Ns+oKOjA6br9ULq/Hzg0aDfY82J+XLVVqfF3PXQe8rTDmuMf/7jTn+M
Un7ZOcei9oZF2/9vfAfKQpDCcgD9HvOUSbgqV/ubmkPPmN/LNJzeKj0fBhrRN+Y=
=K12D
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
* Log filtering from Alex and Peter
* Chardev fix from Marc-André
* config.status tweak from David
* Header file tweaks from Markus, myself and Veronia (Outreachy candidate)
* get_ticks_per_sec() removal from Rutuja (Outreachy candidate)
* Coverity fix from myself
* PKE implementation from myself, based on rth's XSAVE support
# gpg: Signature made Thu 24 Mar 2016 20:15:11 GMT using RSA key ID 78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>"
# gpg: aka "Paolo Bonzini <pbonzini@redhat.com>"
* remotes/bonzini/tags/for-upstream: (28 commits)
target-i386: implement PKE for TCG
config.status: Pass extra parameters
char: translate from QIOChannel error to errno
exec: fix error handling in file_ram_alloc
cputlb: modernise the debug support
qemu-log: support simple pid substitution for logs
target-arm: dfilter support for in_asm
qemu-log: dfilter-ise exec, out_asm, op and opt_op
qemu-log: new option -dfilter to limit output
qemu-log: Improve the "exec" TB execution logging
qemu-log: Avoid function call for disabled qemu_log_mask logging
qemu-log: correct help text for -d cpu
tcg: pass down TranslationBlock to tcg_code_gen
util: move declarations out of qemu-common.h
Replaced get_tick_per_sec() by NANOSECONDS_PER_SECOND
hw: explicitly include qemu-common.h and cpu.h
include/crypto: Include qapi-types.h or qemu/bswap.h instead of qemu-common.h
isa: Move DMA_transfer_handler from qemu-common.h to hw/isa/isa.h
Move ParallelIOArg from qemu-common.h to sysemu/char.h
Move QEMU_ALIGN_*() from qemu-common.h to qemu/osdep.h
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Conflicts:
scripts/clean-includes
Move declarations out of qemu-common.h for functions declared in
utils/ files: e.g. include/qemu/path.h for utils/path.c.
Move inline functions out of qemu-common.h and into new files (e.g.
include/qemu/bcd.h)
Signed-off-by: Veronia Bahaa <veroniabahaa@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch replaces get_ticks_per_sec() calls with the macro
NANOSECONDS_PER_SECOND. Also, as there are no callers, get_ticks_per_sec()
is then removed. This replacement improves the readability and
understandability of code.
For example,
timer_mod(fdctrl->result_timer,
qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) + (get_ticks_per_sec() / 50));
NANOSECONDS_PER_SECOND makes it obvious that qemu_clock_get_ns
matches the unit of the expression on the right side of the plus.
Signed-off-by: Rutuja Shah <rutu.shah.26@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
qemu-common.h should only be included by .c files. Its file comment
explains why: "No header file should depend on qemu-common.h, as this
would easily lead to circular header dependencies."
hw/hw.h includes qemu-common.h, but its users generally need only
hw_error() and qemu/module.h from it. Move the former to hw/hw.h,
include the latter there, and drop the ill-advised include.
hw/misc/cbus.c now misses hw_error(), so include hw/hw.h there.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Migration with ivshmem needs to be carefully orchestrated to work.
Exactly one peer (the "master") migrates to the destination, all other
peers need to unplug (and disconnect), migrate, plug back (and
reconnect). This is sort of documented in qemu-doc.
If peers connect on the destination before migration completes, the
shared memory can get messed up. This isn't documented anywhere. Fix
that in qemu-doc.
To avoid messing up register IVPosition on migration, the server must
assign the same ID on source and destination. ivshmem-spec.txt leaves
ID assignment unspecified, however.
Amend ivshmem-spec.txt to require the first client to receive ID zero.
The example ivshmem-server complies: it always assigns the first
unused ID.
For a bit of additional safety, enforce ID zero for the master. This
does nothing when we're not using a server, because the ID is zero for
all peers then.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-40-git-send-email-armbru@redhat.com>
Move code to more sensible places. Use the opportunity to reorder and
document IVShmemState members.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-38-git-send-email-armbru@redhat.com>
ivshmem can be configured with and without interrupt capability
(a.k.a. "doorbell"). The two configurations have largely disjoint
options, which makes for a confusing (and badly checked) user
interface. Moreover, the device can't tell the guest whether its
doorbell is enabled.
Create two new device models ivshmem-plain and ivshmem-doorbell, and
deprecate the old one.
Changes from ivshmem:
* PCI revision is 1 instead of 0. The new revision is fully backwards
compatible for guests. Guests may elect to require at least
revision 1 to make sure they're not exposed to the funny "no shared
memory, yet" state.
* Property "role" replaced by "master". role=master becomes
master=on, role=peer becomes master=off. Default is off instead of
auto.
* Property "use64" is gone. The new devices always have 64 bit BARs.
Changes from ivshmem to ivshmem-plain:
* The Interrupt Pin register in PCI config space is zero (does not use
an interrupt pin) instead of one (uses INTA).
* Property "x-memdev" is renamed to "memdev".
* Properties "shm" and "size" are gone. Use property "memdev"
instead.
* Property "msi" is gone. The new device can't have MSI-X capability.
It can't interrupt anyway.
* Properties "ioeventfd" and "vectors" are gone. They're meaningless
without interrupts anyway.
Changes from ivshmem to ivshmem-doorbell:
* Property "msi" is gone. The new device always has MSI-X capability.
* Property "ioeventfd" defaults to on instead of off.
* Property "size" is gone. The new device can only map all the shared
memory received from the server.
Guests can easily find out whether the device is configured for
interrupts by checking for MSI-X capability.
Note: some code added in sub-optimal places to make the diff easier to
review. The next commit will move it to more sensible places.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-37-git-send-email-armbru@redhat.com>
In preparation of making it a qdev property.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-36-git-send-email-armbru@redhat.com>
ivshmem_realize() puts the shared memory region in a container region.
Used to be necessary to permit delayed mapping of the shared memory.
However, we recently moved to synchronous mapping, in "ivshmem:
Receive shared memory synchronously in realize()" and the commit
following it. The container is redundant since then. Drop it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1458066895-20632-33-git-send-email-armbru@redhat.com>
ivshmem has its very own code to create and map shared memory.
Replace that with an implicitly created memory backend. Reduces the
number of ways we create BAR 2 from three to two.
The memory-backend-file is currently available only with CONFIG_LINUX,
so this adds a second Linuxism to ivshmem (the other one is eventfd).
Should we ever need to make it portable to systems where
memory-backend-file can't be made to serve, we could create a
memory-backend-shmem that allocates memory with shm_open().
Bonus fix: shared memory files are now created with permissions 0655
instead of 0777.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1458066895-20632-32-git-send-email-armbru@redhat.com>
If size_t is narrower than 64 bits, passing uint64_t ivshmem_size to
mmap() truncates. Reject such sizes.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-31-git-send-email-armbru@redhat.com>
Short reads from a UNIX domain sockets are exceedingly unlikely when
the other side always sends eight bytes and we always read eight
bytes. We cope with them anyway. However, the code doing that is
rather convoluted. Dumb it down radically.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-30-git-send-email-armbru@redhat.com>
The chardev must be capable of transmitting SCM_RIGHTS ancillary
messages. We check it by comparing CharDriverState member filename to
"unix:". That's almost as brittle as it is disgusting.
When the actual transmission all happened asynchronously, this check
was all we could do in realize(), and thus better than nothing. But
now we receive at least one SCM_RIGHTS synchronously in realize(),
it's not worth its keep anymore. Drop it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-29-git-send-email-armbru@redhat.com>
The protocol specification (ivshmem-spec.txt, formerly
ivshmem_device_spec.txt) has always required the ID message to be sent
right at the beginning, and ivshmem-server has always complied. The
device, however, accepts it out of order. If an interrupt setup
arrived before it, though, it would be misinterpreted as connect
notification. Fix the latent bug by relying on the spec and
ivshmem-server's actual behavior.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-28-git-send-email-armbru@redhat.com>
This kills off the funny state described in the previous commit.
Simplify ivshmem_io_read() accordingly, and update documentation.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1458066895-20632-27-git-send-email-armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
When configured for interrupts (property "chardev" given), we receive
the shared memory from an ivshmem server. We do so asynchronously
after realize() completes, by setting up callbacks with
qemu_chr_add_handlers().
Keeping server I/O out of realize() that way avoids delays due to a
slow server. This is probably relevant only for hot plug.
However, this funny "no shared memory, yet" state of the device also
causes a raft of issues that are hard or impossible to work around:
* The guest is exposed to this state: when we enter and leave it its
shared memory contents is apruptly replaced, and device register
IVPosition changes.
This is a known issue. We document that guests should not access
the shared memory after device initialization until the IVPosition
register becomes non-negative.
For cold plug, the funny state is unlikely to be visible in
practice, because we normally receive the shared memory long before
the guest gets around to mess with the device.
For hot plug, the timing is tighter, but the relative slowness of
PCI device configuration has a good chance to hide the funny state.
In either case, guests complying with the documented procedure are
safe.
* Migration becomes racy.
If migration completes before the shared memory setup completes on
the source, shared memory contents is silently lost. Fortunately,
migration is rather unlikely to win this race.
If the shared memory's ramblock arrives at the destination before
shared memory setup completes, migration fails.
There is no known way for a management application to wait for
shared memory setup to complete.
All you can do is retry failed migration. You can improve your
chances by leaving more time between running the destination QEMU
and the migrate command.
To mitigate silent memory loss, you need to ensure the server
initializes shared memory exactly the same on source and
destination.
These issues are entirely undocumented so far.
I'd expect the server to be almost always fast enough to hide these
issues. But then rare catastrophic races are in a way the worst kind.
This is way more trouble than I'm willing to take from any device.
Kill the funny state by receiving shared memory synchronously in
realize(). If your hot plug hangs, go kill your ivshmem server.
For easier review, this commit only makes the receive synchronous, it
doesn't add the necessary error propagation. Without that, the funny
state persists. The next commit will do that, and kill it off for
real.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-26-git-send-email-armbru@redhat.com>
close_peer_eventfds() cleans up three things: ioeventfd triggers if
they exist, eventfds, and the array to store them.
Commit 98609cd (v1.2.0) fixed it not to clean up ioeventfd triggers
when they don't exist (property ioeventfd=off, which is the default).
Unfortunately, the fix also made it skip cleanup of the eventfds and
the array then. This is a memory and file descriptor leak on unplug.
Additionally, the reset of nb_eventfds is skipped. Doesn't matter on
unplug. On peer disconnect, however, this permanently wedges the
interrupt vectors used for that peer's ID. The eventfds stay behind,
but aren't connected to a peer anymore. When the ID gets recycled for
a new peer, the new peer's eventfds get assigned to vectors after the
old ones. Commonly, the device's number of vectors matches the
server's, so the new ones get dropped with a "Too many eventfd
received" message. Interrupts either don't work (common case) or go
to the wrong vector.
Fix by narrowing the conditional to just the ioeventfd trigger
cleanup.
While there, move the "invalid" peer check to the only caller where it
can actually happen, and tighten it to reject own ID.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-25-git-send-email-armbru@redhat.com>
ivshmem_read() processes server messages. These are 64 bit signed
integers. -1 is shared memory setup, 16 bit unsigned is a peer ID,
anything else is invalid.
ivshmem_read() rejects invalid negative messages right away, silently.
Invalid positive messages get rejected only in resize_peers(), and
ivshmem_read() then prints the rather cryptic message "failed to
resize peers array".
Extend the first check to cover all invalid messages, make it report
"server sent invalid message", and drop the second check.
Now resize_peers() can't fail anymore; simplify.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-23-git-send-email-armbru@redhat.com>
An interrupt is set up when the interrupt's file descriptor is
received. Each message applies to the next interrupt vector.
Therefore, each vector cannot be set up more than once.
ivshmem_add_kvm_msi_virq() half-heartedly tries not to rely on this by
doing nothing then, but that's not going to recover from this error
should it become possible in the future. watch_vector_notifier()
doesn't even try.
Simply assert what is the case, so we get alerted if we ever screw it
up.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-22-git-send-email-armbru@redhat.com>
The ivshmem device can either use MSI-X or legacy INTx for interrupts.
With MSI-X enabled, peer interrupt events trigger an MSI as they
should. But software can still raise INTx via interrupt status and
mask register in BAR 0. This is explicitly prohibited by PCI Local
Bus Specification Revision 3.0, section 6.8.3.3:
While enabled for MSI or MSI-X operation, a function is prohibited
from using its INTx# pin (if implemented) to request service (MSI,
MSI-X, and INTx# are mutually exclusive).
Fix the device model to leave INTx alone when using MSI-X.
Document that we claim to use INTx in config space even when we don't.
Unlike other devices, ivshmem does *not* use INTx when configured for
MSI-X and MSI-X isn't enabled by software.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1458066895-20632-21-git-send-email-armbru@redhat.com>
There are three predicates related to MSI-X:
* ivshmem_has_feature(s, IVSHMEM_MSI) is true unless the non-MSI-X
variant of the device is selected with msi=off.
* msix_present() is true when the device has the PCI capability MSI-X.
It's initially false, and becomes true during successful realize of
the MSI-X variant of the device. Thus, it's the same as
ivshmem_has_feature(s, IVSHMEM_MSI) for realized devices.
* msix_enabled() is true when msix_present() is true and guest software
has enabled MSI-X.
Code that differs between the non-MSI-X and the MSI-X variant of the
device needs to be guarded by ivshmem_has_feature(s, IVSHMEM_MSI) or
by msix_present(), except the latter works only for realized devices.
Code that depends on whether MSI-X is in use needs to be guarded with
msix_enabled().
Code review led me to two minor messes:
* ivshmem_vector_notify() calls msix_notify() even when
!msix_enabled(), unlike most other MSI-X-capable devices. As far as
I can tell, msix_notify() does nothing when !msix_enabled(). Add
the guard anyway.
* Most callers of ivshmem_use_msix() guard it with
ivshmem_has_feature(s, IVSHMEM_MSI). Not necessary, because
ivshmem_use_msix() does nothing when !msix_present(). That's
ivshmem's only use of msix_present(), though. Guard it
consistently, and drop the now redundant msix_present() check.
While there, rename ivshmem_use_msix() to ivshmem_msix_vector_use().
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1458066895-20632-20-git-send-email-armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
If pci_ivshmem_realize() fails after it created its migration blocker,
the blocker is left in place. Fix that by creating it last.
Likewise, if it fails after it called fifo8_create(), it leaks fifo
memory. Fix that the same way.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-18-git-send-email-armbru@redhat.com>
We reuse errp after passing it host_memory_backend_get_memory(). If
both host_memory_backend_get_memory() and the reuse set an error, the
reuse will fail the assertion in error_setv(). Fortunately,
host_memory_backend_get_memory() can't fail.
Pass it &error_abort to make our assumption explicit, and to get the
assertion failure in the right place should it become invalid.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-17-git-send-email-armbru@redhat.com>
Yes, the chardev is commonly useless after we read a bad version from
it, but destroying it is inappropriate anyway: the user created it, so
the user should be able to hold on to it as long as he likes. We
don't destroy it on other errors. Screwed up in commit 5105b1d.
Stop reading instead.
Also note QEMU's behavior in ivshmem-spec.txt.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-16-git-send-email-armbru@redhat.com>
IVShmemState member eventfd_chr is useless since commit 9940c32. Drop
it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <1458066895-20632-14-git-send-email-armbru@redhat.com>
The property channel driver now interfaces with the framebuffer device
to query and set framebuffer parameters. As a result of this, the "get
ARM RAM size" query now correctly returns the video RAM base address
(not total RAM size), and the ram-size property is no longer relevant
here.
Signed-off-by: Grégory ESTRADE <gregory.estrade@gmail.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
Message-id: 1457467526-8840-5-git-send-email-Andrew.Baumann@microsoft.com
[AB: cleanup/refactoring for upstream submission]
Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
EPIT, GPT and other i.MX timers are using "abstract" clocks among which
a CLK_IPG_HIGH clock.
On i.MX25 and i.MX31 CLK_IPG and CLK_IPG_HIGH are mapped to the same clock
but on other SOC like i.MX6 they are mapped to distinct clocks.
This patch add the CLK_IPG_HIGH to prepare for SOC where these 2 clocks are
different.
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net>
Message-id: 224bf650194760284cb40630e985867e1373276a.1456868959.git.jcd@tribudubois.net
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Most clocks supported by the CCM are useless to the qemu framework.
Only clocks related to timers (EPIT, GPT, PWM, WATCHDOG, ...) are usefull
to QEMU code.
Therefore this patch removes clock computation handling for all clocks but:
* CLK_NONE,
* CLK_IPG,
* CLK_32k
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net>
Message-id: 9e7222efb349801032e60c0f6b0fbad0e5dcf648.1456868959.git.jcd@tribudubois.net
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This way all CCM clock defines/enums are named CLK_XXX
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Jean-Christophe Dubois <jcd@tribudubois.net>
Message-id: 8537df765c1713625c7a8b9aca4c7ca60b42e0c0.1456868959.git.jcd@tribudubois.net
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
All references to mr->ram_addr are replaced by
memory_region_get_ram_addr(mr) (except for a few assertions that are
replaced with mr->ram_block).
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-Id: <1456813104-25902-5-git-send-email-famz@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
PMM pointed out that ldl_phys and stl_phys are dependent on the CPU's
endianness, whereas device model code should be independent of
it. This changes the relevant Raspberry Pi devices to explicitly call
the little-endian variants.
Signed-off-by: Andrew Baumann <Andrew.Baumann@microsoft.com>
Message-id: 1456880233-22568-1-git-send-email-Andrew.Baumann@microsoft.com
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
With this, it's easier to know if a guest uses an invalid and/or unimplemented
DMA channel.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We currently don't emulate the I2C bus provided by CUDA.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
